From w3c-dist-auth-request@listhub.w3.org Fri Dec 2 05:15:07 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F2321F98DB for ; Fri, 2 Dec 2011 05:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.036 X-Spam-Level: X-Spam-Status: No, score=-7.036 tagged_above=-999 required=5 tests=[AWL=3.563, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhZp3HXDvBQy for ; Fri, 2 Dec 2011 05:15:07 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id EA01621F9894 for ; Fri, 2 Dec 2011 05:15:06 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RWSvj-0001qz-Ux for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2011 13:13:31 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RWSvi-0001q5-SD for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2011 13:13:31 +0000 Received: from mailout-de.gmx.net ([213.165.64.22]) by aji.keio.w3.org with smtp (Exim 4.72) (envelope-from ) id 1RWSva-0000KY-7P for w3c-dist-auth@w3.org; Fri, 02 Dec 2011 13:13:30 +0000 Received: (qmail invoked by alias); 02 Dec 2011 13:12:47 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 02 Dec 2011 14:12:47 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19BvdBGOmRBGSsadVrL+EqZEBiBdyZQYoX0yaqRws SdG3EEK3VuHxzV Message-ID: <4ED8CEBA.9030400@gmx.de> Date: Fri, 02 Dec 2011 14:12:26 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: WebDAV References: <20111201234141.15491.6177.idtracker@ietfa.amsl.com> In-Reply-To: <20111201234141.15491.6177.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111201234141.15491.6177.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.22; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 X-W3C-Scan-Sig: aji.keio.w3.org 1RWSva-0000KY-7P a84614d71c428c5c7fdb3f72e42f7d5f X-Original-To: w3c-dist-auth@w3.org Subject: Fwd: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13352 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 02 Dec 2011 13:13:31 +0000 (FYI) -------- Original Message -------- Subject: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Date: Thu, 01 Dec 2011 15:41:41 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Collection Synchronization for WebDAV' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at . The file can be obtained via http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From busiycho@21cn.com Sun Dec 4 03:13:05 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548F021F877F for ; Sun, 4 Dec 2011 03:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.8 X-Spam-Level: *** X-Spam-Status: No, score=3.8 tagged_above=-999 required=5 tests=[BAYES_99=3.5, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4vWXYVCm3zA for ; Sun, 4 Dec 2011 03:13:05 -0800 (PST) Received: from 21cn.com (smtpfree.forptr.21cn.com [59.36.102.63]) by ietfa.amsl.com (Postfix) with ESMTP id 102B021F858C for ; Sun, 4 Dec 2011 03:13:05 -0800 (PST) HMM_SOURCE_IP:10.27.2.13:59833.616581772 HMM_ATTACHE_NUM:0000 HMM_SOURCE_TYPE:SMTP Received: from rdmhtx (unknown [10.27.2.13]) by 21cn.com (HERMES) with ESMTP id 636F42A7585; Sun, 4 Dec 2011 19:13:02 +0800 (CST) Received: from rdmhtx ([113.90.25.142]) by 21CN(Yuwen filter gate 10.27.2.13) with ESMTP id 1322997179.5589 for webcracker@yeah.net ; Sun Dec 4 19:13:04 2011 0/X-Brightmail-Tracker:AAAAAA== 1/X-Total-Score: 0: X-FILTER-SCORE: to=, score=<1322997184pIIIIIkII0IIGIk0GZAQWcIIIIIIIIfIIfIIffggPPbb> Reply-To: Message-ID: <922C3FCAC93569E186557D8E4B06E14E@rdmhtx> From: =?utf-8?B?5byg55Sf?= To: , , , Subject: 2011-12-4 Date: Sun, 4 Dec 2011 19:12:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Disposition-Notification-To: xtay131415@163.com X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 ICAgDQoNCiAgICAgICAgICAzLi4u5Y2O5oSP56iO5Yqh5YWs5Y+45LiT5Lia5Luj55CG5YWo5Zu9 5ZCE55yB5biCPD7mma4t6YCaLeeoji3lmIwsPD4NCg0KICDngrnmlbDlupUs6aqM6K+B5peg6Zeu 6aKY5ZCO5LuY5qy+LDEwMCXmlL7lv4Mu5aaC5pyJ6ZyA5Y+v5p2l55S15rS96LCILi4uDQoNCiAg 5bygYFI6MS4zLjQuMi44LjYuNi45LjUuNS45ICAgIFFROjkgMCA4IDEgOSA5IDUgOCA4DQoNCg0K DQoNCg0K From w3c-dist-auth-request@listhub.w3.org Tue Dec 13 13:53:15 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ADA11E80A3 for ; Tue, 13 Dec 2011 13:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.041 X-Spam-Level: X-Spam-Status: No, score=-7.041 tagged_above=-999 required=5 tests=[AWL=3.258, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+ygPas18bgg for ; Tue, 13 Dec 2011 13:53:15 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 51FC111E809B for ; Tue, 13 Dec 2011 13:53:15 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RaaGD-00069n-F4 for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2011 21:51:41 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RaaGB-00068z-CR for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2011 21:51:39 +0000 Received: from mailout-de.gmx.net ([213.165.64.23]) by aji.keio.w3.org with smtp (Exim 4.72) (envelope-from ) id 1RaaG7-00043e-6q for w3c-dist-auth@w3.org; Tue, 13 Dec 2011 21:51:38 +0000 Received: (qmail invoked by alias); 13 Dec 2011 21:51:01 -0000 Received: from p3EE279D1.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.121.209] by mail.gmx.net (mp031) with SMTP; 13 Dec 2011 22:51:01 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+GdKlTKMeGMCUiK/GQgQuTdBzHpne9fVIy21kdqt JRgQ2zrSvbSbwY Message-ID: <4EE7C8BE.9030503@gmx.de> Date: Tue, 13 Dec 2011 22:50:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Werner_Donn=E9?= CC: Cyrus Daboo , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org, IETF Discussion References: <2D7356DA1153057D7AE554D8@caldav.corp.apple.com> <0296DA16-10E8-47A9-959D-2B9681BEAB36@pincette.biz> <4C0DEDC8.1090200@gmx.de> In-Reply-To: <4C0DEDC8.1090200@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.23; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 X-W3C-Scan-Sig: aji.keio.w3.org 1RaaG7-00043e-6q 915b685105c1886e7209f7dd04ec4028 X-Original-To: w3c-dist-auth@w3.org Subject: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13353 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 13 Dec 2011 21:51:41 +0000 On 2010-06-08 09:14, Julian Reschke wrote: > On 07.06.2010 17:11, Werner Donné wrote: >> Hi, >> >> I don't see why Depth:infinity should be ruled out from the start. You >> can let the server decide if the performance penalty is too high or >> not. A server with a relational system underneath it, for example, can >> do this with one query. >> >> I don't agree with the "bubble up" principle. A collection changes >> when its member set changes. Changing a resource that is referred to >> by one of the members doesn't affect the collection, whether that >> resource is a collection or not. I think the "bubble up" principal is >> not consistent with the "getlastmodified" property. It is also not >> needed if Depth:infinity is supported. >> >> Best regards, >> >> Werner. > > Agreed. > > In particular: defining a report works by defining it for Depth: 0. The > semantics for Depth: 1 and Depth: infinity follow by the definition in > RFC 3253. > > It's probably *really* time to pull the definition of REPORT out of RFC > 3253 and place it into a separate spec, including more rationale, > recommendations for defining new reports, and examples. > > Best regards, Julian It seems to me that this issue was never addressed. As defined right now, the way REPORT is used doesn't seem to be compatible with the definition of REPORT in RFC 3253, and the definition of the Depth: header field in RFC 4918. Unless I'm missing something, this will be a problem for any implementation that tries to implement the sync report based on a generic WebDAV reporting framework. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Tue Dec 13 15:19:00 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C3911E80A4 for ; Tue, 13 Dec 2011 15:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=2.287, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhxIbYApJZuK for ; Tue, 13 Dec 2011 15:18:59 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7D311E809B for ; Tue, 13 Dec 2011 15:18:59 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RabbZ-0008Ui-Jx for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2011 23:17:49 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RabbY-0008Tp-AF for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2011 23:17:48 +0000 Received: from mailout-de.gmx.net ([213.165.64.23]) by aji.keio.w3.org with smtp (Exim 4.72) (envelope-from ) id 1RabbS-0006s9-TF for w3c-dist-auth@w3.org; Tue, 13 Dec 2011 23:17:47 +0000 Received: (qmail invoked by alias); 13 Dec 2011 23:10:30 -0000 Received: from p3EE279D1.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.121.209] by mail.gmx.net (mp055) with SMTP; 14 Dec 2011 00:10:30 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/f8lVH/S7f1i1aMPZomZTC6VNXLE/KHNY/3A8/2c DYA7Sms91rGMQP Message-ID: <4EE7DB63.4030900@gmx.de> Date: Wed, 14 Dec 2011 00:10:27 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ietf@ietf.org CC: WebDAV References: <20111201234141.15491.6177.idtracker@ietfa.amsl.com> In-Reply-To: <20111201234141.15491.6177.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.23; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 X-W3C-Scan-Sig: aji.keio.w3.org 1RabbS-0006s9-TF 57dcb8267ecdce31dfbd482837ca1653 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13354 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 13 Dec 2011 23:17:49 +0000 On 2011-12-02 00:41, The IESG wrote: > ... Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. -> Expand acronyms on first use. Typically, the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all member URIs that are currently in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required. I think it would be more consistent with other specs not to send an empty token, but to send *no* token. As an alternative, the client might choose to do its first synchronization using some other mechanism on the collection (e.g. some other form of batch resource information retrieval such as PROPFIND, SEARCH [RFC5323] , or specialized REPORTs such as those defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav]) The CardDAV reference will need to be updated... To implement the behavior for this report a server needs to keep track of changes to any member URIs and their mapped resources in a collection (as defined in Section 3 of [RFC4918]). This includes Actually, RFC 4918 defines "member URL"; maybe worth adjusting or pointing out it's the same. Marshalling: The request URI MUST identify a collection. The request body MUST be a DAV:sync-collection XML element (see Section 6.1), which MUST contain one DAV:sync-token XML element, and one DAV:prop XML element, and MAY contain a DAV:limit XML element. The request MUST include a Depth header with a value of "1" or "infinity". This report definition is in conflict with the definition of the REPORT method in RFC 3253 (). Essentially, a report is applied to just the request URI (depth: 0 or no depth header field), the request URI and it's internal members (1) or all descendants (infinity). A report definition should define the response for the case of Depth: 0. The format for the other cases follows directly from RFC 3253: "If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource." (Note that I have complained about this a long time ago, ). To fix this, the report would need to define Depth: 0 processing on a collection to mean the changes just on that collection (which means membership changes, but not changes to member resources), and the other modes would then follow based on RFC 3253. It doesn't seem to be possible to make this change in a way that doesn't break existing implementations, as RFC 3253 requires the report response format to be well-formed XML (thus only one root element), and that format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. Optimally, this should be fixed. If this can't be fixed I'd argue that the spec should be published as Informational, and that it should include an explanation of the incompatibilty (essentially requiring servers to special-case this report in case they already use a generic WebDAV REPORT framework). The response body for a successful request MUST be a DAV: multistatus XML element, which MUST contain one DAV:sync-token Maybe s/one/a single/ ... Preconditions: (DAV:valid-sync-token): The DAV:sync-token element value MUST be a valid token previously returned by the server. A token can become invalid as the result of being "out of date" (out of the range of change history maintained by the server), or for other reasons (e.g. collection deleted, then recreated, access control changes, etc...). Does the sync-token need to originate from the same collection? 3.3. Depth behavior Servers MUST support both Depth:1 and Depth:infinity behavior with the DAV:sync-collection report. Clients MUST include either a Depth:1 or Depth:infinity request header with the DAV:sync-collection report. See above; this contradicts the base definition of REPORT. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be mentioned that this only works well with resources that are not content-negotiated. For example, consider a server that records changes using a monotonically increasing integer to represent a "revision number" and uses that quantity as the DAV:sync-token value (appropriately encoded as a URI). Assume the last DAV:sync-token used by the client was "http://example.com/sync/10", and since then 15 additional changes have occurred. If the client executes a DAV:sync-collection request with a DAV:sync-token of "http://example.com/sync/10", without a limit the server would return 15 DAV:response elements and a DAV: Why 15? Is the assumption that any change to the server causes exactly one resource to change? What if there were 15 changes to the same resource? Why do we have DAV: prefixes on some of the DTD elements? From w3c-dist-auth-request@listhub.w3.org Tue Dec 13 23:31:25 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5153B1F0C47 for ; Tue, 13 Dec 2011 23:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7dCXuuh4UIE for ; Tue, 13 Dec 2011 23:31:24 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 90C151F0C38 for ; Tue, 13 Dec 2011 23:31:24 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RajHy-00022s-HC for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 07:30:06 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RajHu-0001o3-Ds for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 07:30:02 +0000 Received: from [2404:130:0:10::82:0] (helo=mail.morphoss.com) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1RajHn-0004c0-Fr for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 07:30:01 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.morphoss.com (Postfix) with ESMTP id B39893C54D; Wed, 14 Dec 2011 20:29:25 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at mail.morphoss.com Received: from mail.morphoss.com ([127.0.0.1]) by localhost (hoppy.mcmillan.net.nz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DyNPZxXFtFWr; Wed, 14 Dec 2011 20:29:20 +1300 (NZDT) Received: from [192.168.55.25] (home.mcmillan.net.nz [202.160.48.75]) (Authenticated sender: andrew@mail.morphoss.com) by mail.morphoss.com (Postfix) with ESMTPSA id 7B02D20447; Wed, 14 Dec 2011 20:29:20 +1300 (NZDT) Message-ID: <1323847753.6059.41.camel@dave.home.mcmillan.net.nz> From: Andrew McMillan Reply-To: andrew@morphoss.com To: Cyrus Daboo Cc: w3c-dist-auth@w3.org Date: Wed, 14 Dec 2011 20:29:13 +1300 In-Reply-To: References: Organization: Morphoss Ltd Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-qmW/o3+REwmiv5hLQw+j" X-Mailer: Evolution 3.0.3-2 Mime-Version: 1.0 Received-SPF: pass client-ip=2404:130:0:10::82:0; envelope-from=andrew@morphoss.com; helo=mail.morphoss.com X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001 X-W3C-Scan-Sig: aji.keio.w3.org 1RajHn-0004c0-Fr 882a5d6f56c5df3bff41f003644a21b9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV sync last call Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13355 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 07:30:06 +0000 --=-qmW/o3+REwmiv5hLQw+j Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2011-08-30 at 09:38 -0400, Cyrus Daboo wrote: > Hi folks, > The authors believe the WebDAv Sync document=20 > () is ready to= =20 > go to the IESG for consideration of publishing as an RFC. We'd like to ge= t=20 > final reviews from this list along with a list of existing or planned=20 > implementations of this draft to include as supporting documentation for= =20 > the IESG. Please review and provide feedback, thanks. Hi Cyrus, There are a couple of things that have come up for me recently in relation to this draft. I'll spell them out here, but I'm happy enough with the draft as it stands, and I would rather see this approved than for my issues (or maybe "wild ideas" might be a better term :-) to disrupt the process. (1) invalid sync token error When I send a token which is invalid I receive an error response. This is not particularly useful to me in my client. I (somehow) got an invalid sync token - maybe it expired - but there's probably no useful interaction with the user that I can take as a result. I just have to fall back to a full re-sync. It seems to me that it would be more useful to treat this case the same as if no sync token were supplied, perhaps also supplying additional information that the sync token was (expired|invalid|...) within the response. DAViCal was in fact doing this (without error information) until I recently corrected the error. (2) long polling When I make a sync request I would sometimes like to be able to indicate to the server that it is acceptable for it to treat my request as a "long poll", so that the server would hold my connection open until a change occurred within the hierarchy of the request. For a server to do this, I think that it would be advantageous for the old sync token to be provided within the request headers, rather than within the XML payload of the request. I believe that doing this would make server processing easier, since all necessary data for deciding whether changes have occurred (URL, Depth, Token) would be in the headers. There's nothing I can see in the current spec which would actually preclude implementation of the report as a long poll, but if one were to actually do that it might be less than ideal for some clients. On the other hand if the possibility is available in a "soft" way as an optional implementation then a client hoping for support could easily be written to work just fine with an non-supporting installation. For example if the client indicated a long poll response was acceptable simply by including a "Sync-Token" header containing the old token, an unknowing implementation would simply respond, as at present. A knowing implementation could hold responding until something changed. The client written to support this would want to know that this was a long poll, so it could immediately re-request, so the server could also indicate this by providing the sync token back as a header. Cheers, Andrew. --=20 ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN There is no snooze button on a cat who wants breakfast. ------------------------------------------------------------------------ --=-qmW/o3+REwmiv5hLQw+j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABCAAGBQJO6FBJAAoJEOr8/r+P646/qQcP+wbxM1Rme/lRrIX7RcpdNZaf 8x3XNaKNxYLtxvPov52yynfeFMuqF5kXokOX0Hc0kSQqR+Mf7ofUAG5soNF9Vgn3 cu0eFcLFTBe56w9b4oNKVQMFbtU7XHqNMUTOzXWB8UH7l48VmPNcSSLlusWk43yn ZXOji91zrRNPWEgIREV9NMJ8+fj0toLZi/A05Huocs2cDLJBz8r3/v5Vi8N1Gchv DyCuSXsmTcFWJQolF34uB7K3ubbCfYdM402GiY9uyB97JcEoQwtUNVUS+mR2f8Eo vt7DyKzv1QNcf4kQ4Xyx9szthvUpa7wBDVA+f6g1i/IEHEVyLGWH1uV5BKKZ34MV wnsro4mgovkNBHOUq7FYXXa0oHN7y+3wQmfVE74RdeVbk9pZQFbF6tdOQsUV6KWe SF5p3ccAQOUj7MScbG7duGxJ8y3QnuWKHsyJDpQRtR7Dx4rtOgpLMwNeEtrzBvCX pXakhiUqbgg3hDel2rLA9871KKf0cQUD8Q+0b4abjzkJjJxvv5jukY0EIWJlWN5N vUEec9s1q0EiQIxK4/JUwgdIFcU7lXynvoLZeIM/sXsArVG3xxCLnvfv8LwPkAcV dck7eUyzDFGd9hOZyBK9uxEUi8xEM/1Uar3iGR5dOi0ADmWAP7yyerI+rHoqj6U1 9irjfgR7bYLWgtgqp7OA =5puB -----END PGP SIGNATURE----- --=-qmW/o3+REwmiv5hLQw+j-- From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 00:56:34 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA3E21F86B3 for ; Wed, 14 Dec 2011 00:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.666 X-Spam-Level: X-Spam-Status: No, score=-7.666 tagged_above=-999 required=5 tests=[AWL=2.933, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqW78jeh73DJ for ; Wed, 14 Dec 2011 00:56:34 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E033321F86A1 for ; Wed, 14 Dec 2011 00:56:33 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RakcY-0007vd-Q8 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 08:55:26 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RakcX-0007ur-P7 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 08:55:25 +0000 Received: from mailout-de.gmx.net ([213.165.64.23]) by maggie.w3.org with smtp (Exim 4.72) (envelope-from ) id 1RakcU-00034n-M3 for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 08:55:25 +0000 Received: (qmail invoked by alias); 14 Dec 2011 08:54:54 -0000 Received: from p3EE279D1.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.121.209] by mail.gmx.net (mp027) with SMTP; 14 Dec 2011 09:54:54 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/uJLRjVSbuHAPI+qSJJ4xJ+ljn88K5UoSc+btDLG pUYfubgWOpH4Aq Message-ID: <4EE86457.8060100@gmx.de> Date: Wed, 14 Dec 2011 09:54:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: andrew@morphoss.com CC: Cyrus Daboo , w3c-dist-auth@w3.org References: <1323847753.6059.41.camel@dave.home.mcmillan.net.nz> In-Reply-To: <1323847753.6059.41.camel@dave.home.mcmillan.net.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.23; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1RakcU-00034n-M3 11b4624fc127f4934eacc3f639c53386 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV sync last call Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13356 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 08:55:26 +0000 On 2011-12-14 08:29, Andrew McMillan wrote: > ... > (2) long polling > > When I make a sync request I would sometimes like to be able to indicate > to the server that it is acceptable for it to treat my request as a > "long poll", so that the server would hold my connection open until a > change occurred within the hierarchy of the request. > > For a server to do this, I think that it would be advantageous for the > old sync token to be provided within the request headers, rather than > within the XML payload of the request. I believe that doing this would > make server processing easier, since all necessary data for deciding > whether changes have occurred (URL, Depth, Token) would be in the > headers. > ... How does this help? The request body fur the REPORT is sufficiently small to be inspected right away, no? The important part for the ability to stream the change events is that the new sync token is last in the response body, and the sync spec got that right... (Mentioning this because I'm using Atom for a similar use case in JCR, and that suffers from the ETag having to be sent out first, with libraries and server frameworks having no support for trailers). Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 01:30:58 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6783721F8B24 for ; Wed, 14 Dec 2011 01:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQocjSavzEEa for ; Wed, 14 Dec 2011 01:30:57 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C77E521F8B26 for ; Wed, 14 Dec 2011 01:30:57 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RalAL-0008R9-Db for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 09:30:21 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RalAK-0008Mf-37 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 09:30:20 +0000 Received: from [2404:130:0:10::82:0] (helo=mail.morphoss.com) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1RalAH-0000uJ-Hv for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 09:30:19 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.morphoss.com (Postfix) with ESMTP id 9A37F20449; Wed, 14 Dec 2011 22:29:49 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at mail.morphoss.com Received: from mail.morphoss.com ([127.0.0.1]) by localhost (hoppy.mcmillan.net.nz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pGZ8kxQLEIvt; Wed, 14 Dec 2011 22:29:43 +1300 (NZDT) Received: from [192.168.55.25] (home.mcmillan.net.nz [202.160.48.75]) (Authenticated sender: andrew@mail.morphoss.com) by mail.morphoss.com (Postfix) with ESMTPSA id 924F020447; Wed, 14 Dec 2011 22:29:43 +1300 (NZDT) Message-ID: <1323854982.6059.52.camel@dave.home.mcmillan.net.nz> From: Andrew McMillan Reply-To: andrew@morphoss.com To: Julian Reschke Cc: Cyrus Daboo , w3c-dist-auth@w3.org Date: Wed, 14 Dec 2011 22:29:42 +1300 In-Reply-To: <4EE86457.8060100@gmx.de> References: <1323847753.6059.41.camel@dave.home.mcmillan.net.nz> <4EE86457.8060100@gmx.de> Organization: Morphoss Ltd Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-IuH76+M5FAgKAulT/qy5" X-Mailer: Evolution 3.0.3-2 Mime-Version: 1.0 Received-SPF: pass client-ip=2404:130:0:10::82:0; envelope-from=andrew@morphoss.com; helo=mail.morphoss.com X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001 X-W3C-Scan-Sig: aji.keio.w3.org 1RalAH-0000uJ-Hv c9c320a70feec8c54ac003a5c74ea93c X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV sync last call Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13357 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 09:30:21 +0000 --=-IuH76+M5FAgKAulT/qy5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2011-12-14 at 09:54 +0100, Julian Reschke wrote: > On 2011-12-14 08:29, Andrew McMillan wrote: > > ... > > (2) long polling > > > > When I make a sync request I would sometimes like to be able to indicat= e > > to the server that it is acceptable for it to treat my request as a > > "long poll", so that the server would hold my connection open until a > > change occurred within the hierarchy of the request. > > > > For a server to do this, I think that it would be advantageous for the > > old sync token to be provided within the request headers, rather than > > within the XML payload of the request. I believe that doing this would > > make server processing easier, since all necessary data for deciding > > whether changes have occurred (URL, Depth, Token) would be in the > > headers. > > ... >=20 > How does this help? The request body fur the REPORT is sufficiently=20 > small to be inspected right away, no? >=20 > The important part for the ability to stream the change events is that= =20 > the new sync token is last in the response body, and the sync spec got= =20 > that right... >=20 > (Mentioning this because I'm using Atom for a similar use case in JCR,= =20 > and that suffers from the ETag having to be sent out first, with=20 > libraries and server frameworks having no support for trailers). Yes, those are good points. Regards, Andrew. --=20 ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN This fortune is inoperative. Please try another. ------------------------------------------------------------------------ --=-IuH76+M5FAgKAulT/qy5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABCAAGBQJO6GyGAAoJEOr8/r+P646/Z1oP/1+6Q0NbPQovCly7Pn0A+lHB VBYbhOJJnBsgPySVRFFmt7z7PkubccPfYSA7t2oaePbqQdiDdn6h70zxDSC+tK/b CVoWtDm7Wa73b70Bpz2CkGHfo/yAxvdnXLwy//To9VJnZU7M2xO7ct6yf+8QErK8 DLrkjiw32/fISgIS99nCCvQ9lqD9AzOtMswqKoQGKFRgVj1DqkIVzwA6BOFbwOQy g45/mO8oB6skeUfYkhECkcPjHQZ4PlOS5WVOZ6xgwboftMeV3drgqcEpuTNnrAdp 452VCwGwoAsvAQVkINw11lk+ud0vjAcVtMY7M1oIXqdedYV8ld+h9alTdVx4dKgQ 5N3MhBKqrHydjB0oLMQxlGLC3xrS4nStqlvLoIwIEulKHZ6J08dM8ZEMLB4MFFyU 5dJ0KU90t4fBjdiR/njQt6T+ynD7mUSQiG4luC7qFe4BKJYVed2vh4aZX4FR1jXa nh1szeDXO4etlLfYqRjETgYo+kwV8yAFvoR+6V2Pz3yplI6Eox9Qg8Wb/HQCeyWz hbKoZIOsAzEz6FsTGZX4ccdKkTS4PuVRNGlZdw17n/xhW8rcHV0Iy8E+P6EEfMsF aHi6D9QREbtHrO74B2BIHxJ/d0gE37CcsCtnlMKf/kJNJ/y2IJClwuyT2++vBCoS B35j309WHqanxFD7deRV =UUta -----END PGP SIGNATURE----- --=-IuH76+M5FAgKAulT/qy5-- From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 07:09:05 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDAA21F8B39 for ; Wed, 14 Dec 2011 07:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=3.400, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbu2YU37lg53 for ; Wed, 14 Dec 2011 07:09:04 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8308221F8B0F for ; Wed, 14 Dec 2011 07:09:04 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RaqPw-0000jn-MC for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 15:06:48 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RaqPu-0000iL-Hx for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 15:06:46 +0000 Received: from daboo.name ([173.13.55.49]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1RaqPt-0007kk-02 for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 15:06:46 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2BCAC1E5454C; Wed, 14 Dec 2011 10:03:57 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ap2yE2ggMvw; Wed, 14 Dec 2011 10:03:55 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id CCFC51E5453D; Wed, 14 Dec 2011 10:03:54 -0500 (EST) Date: Wed, 14 Dec 2011 10:03:51 -0500 From: Cyrus Daboo To: andrew@morphoss.com cc: w3c-dist-auth@w3.org Message-ID: <6D974159022CAA5DEA5FC072@caldav.corp.apple.com> In-Reply-To: <1323847753.6059.41.camel@dave.home.mcmillan.net.nz> References: <1323847753.6059.41.camel@dave.home.mcmillan.net.nz> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2380 Received-SPF: none client-ip=173.13.55.49; envelope-from=cyrus@daboo.name; helo=daboo.name X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.482 X-W3C-Scan-Sig: maggie.w3.org 1RaqPt-0007kk-02 197452ad44c4e2d7b4d0539acc266c66 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV sync last call Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13358 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 15:06:48 +0000 Hi Andrew, --On December 14, 2011 8:29:13 PM +1300 Andrew McMillan wrote: > (1) invalid sync token error > > When I send a token which is invalid I receive an error response. This > is not particularly useful to me in my client. I (somehow) got an > invalid sync token - maybe it expired - but there's probably no useful > interaction with the user that I can take as a result. I just have to > fall back to a full re-sync. It seems to me that it would be more > useful to treat this case the same as if no sync token were supplied, > perhaps also supplying additional information that the sync token was > (expired|invalid|...) within the response. > > DAViCal was in fact doing this (without error information) until I > recently corrected the error. I would prefer to keep invalid vs no sync-token behavior separate. My rationale is that when an invalid token is presented, and the server is going to force the client to go back to a full sync, it is imperative that the client know that since it will either have to purge its current cache prior to a full sync, or treat the full sync results in a significantly different way than it would if it were an incremental sync. Now one way to achieve that would be as you describe, with the addition of some indication from the server that it fell back to a full sync so the client can change from incremental to full behavior. We don't have such an indication now, and I would be reluctant to add one. The other issue here is that a client may want to do full syncs differently from incremental. e.g., if the collection is known to be very large, the client may not want to get all the resource data in a single full sync response, instead opting to use the DAV:limit option to "batch" the full sync results. With your approach, the server would return the full set of data (unless the client had uses limit for incremental). Also, I know that CalDAV clients doing time-range based sync'ing have special logic that means they often don't use sync report for a full sync. At this point I prefer the two-step process as it gives clients the flexibility to choose how and when a full sync is initiated. I don't think it is all that big a burden on clients and the extra roundtrip is reasonable given that this is an edge case that should not occur very frequently. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 07:18:39 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF10321F856F for ; Wed, 14 Dec 2011 07:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.732 X-Spam-Level: X-Spam-Status: No, score=-7.732 tagged_above=-999 required=5 tests=[AWL=2.867, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoZ3dc8uWxPF for ; Wed, 14 Dec 2011 07:18:39 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0915D21F8540 for ; Wed, 14 Dec 2011 07:18:39 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Raqae-0004nV-S7 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 15:17:52 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Raqae-0004mO-9n for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 15:17:52 +0000 Received: from daboo.name ([173.13.55.49]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1Raqac-0008AP-SH for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 15:17:52 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2E4F21E547E9; Wed, 14 Dec 2011 10:17:30 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXK8+Pe6r4kj; Wed, 14 Dec 2011 10:17:28 -0500 (EST) Received: from [17.45.162.181] (unknown [17.45.162.181]) by daboo.name (Postfix) with ESMTPSA id EB6B71E547DC; Wed, 14 Dec 2011 10:17:27 -0500 (EST) Date: Wed, 14 Dec 2011 10:17:25 -0500 From: Cyrus Daboo To: andrew@morphoss.com cc: w3c-dist-auth@w3.org Message-ID: <7502C22F2A5BB943B3D223B0@cyrus.local> In-Reply-To: <1323847753.6059.41.camel@dave.home.mcmillan.net.nz> References: <1323847753.6059.41.camel@dave.home.mcmillan.net.nz> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=713 Received-SPF: none client-ip=173.13.55.49; envelope-from=cyrus@daboo.name; helo=daboo.name X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.482 X-W3C-Scan-Sig: maggie.w3.org 1Raqac-0008AP-SH 5b4caa3d0810eafac6d1e200f8a3e555 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV sync last call Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13359 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 15:17:52 +0000 Hi Andrew, --On December 14, 2011 8:29:13 PM +1300 Andrew McMillan wrote: > (2) long polling > > When I make a sync request I would sometimes like to be able to indicate > to the server that it is acceptable for it to treat my request as a > "long poll", so that the server would hold my connection open until a > change occurred within the hierarchy of the request. I think a long polling option should be implemented as an extension to WebDAV sync. The issue with long polling right now is that there is no agreed upon standard way of doing that. I'd rather wait for a standards based approach to be defined - but WebDAV sync itself should not be blocked on that. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 08:10:37 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC1021F8BF6 for ; Wed, 14 Dec 2011 08:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB6j8reFe9IA for ; Wed, 14 Dec 2011 08:10:35 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0900021F8BEE for ; Wed, 14 Dec 2011 08:10:14 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RarOF-0001yA-7t for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 16:09:07 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RarOE-0001xM-78 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 16:09:06 +0000 Received: from daboo.name ([173.13.55.49]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1RarOB-0001Dx-7o for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 16:09:05 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8686F1E55207; Wed, 14 Dec 2011 11:06:20 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ia6n6npdm93; Wed, 14 Dec 2011 11:06:19 -0500 (EST) Received: from [17.45.162.181] (unknown [17.45.162.181]) by daboo.name (Postfix) with ESMTPSA id AAE281E551FC; Wed, 14 Dec 2011 11:06:17 -0500 (EST) Date: Wed, 14 Dec 2011 11:06:21 -0500 From: Cyrus Daboo To: Julian Reschke , ietf@ietf.org cc: WebDAV Message-ID: <1F36B3D7066D9669ECFC947D@cyrus.local> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=9176 Received-SPF: none client-ip=173.13.55.49; envelope-from=cyrus@daboo.name; helo=daboo.name X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.482 X-W3C-Scan-Sig: maggie.w3.org 1RarOB-0001Dx-7o 940da57db7eb7b9ab0ab2b822bad2947 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13360 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 16:09:07 +0000 Hi Julian, --On December 14, 2011 12:10:27 AM +0100 Julian Reschke wrote: > On 2011-12-02 00:41, The IESG wrote: >> ... > > Abstract > > This specification defines an extension to WebDAV that allows > efficient synchronization of the contents of a WebDAV collection. > > -> Expand acronyms on first use. Really, doesn't everyone know what WebDAV is by now :-) In any case fixed in my working copy. > > Typically, the first time a client connects to the server it will > need to be informed of the entire state of the collection (i.e., a > full list of all member URIs that are currently in the collection). > That is done by the client sending an empty token value to the > server. This indicates to the server that a full listing is > required. > > I think it would be more consistent with other specs not to send an empty > token, but to send *no* token. Existing implementations expect an empty sync-token element. I don't really see much difference either way on this, so would prefer to leave it as-is. > As an alternative, the client might choose to do its first > synchronization using some other mechanism on the collection (e.g. > some other form of batch resource information retrieval such as > PROPFIND, SEARCH [RFC5323] , or specialized REPORTs such as those > defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav]) > > The CardDAV reference will need to be updated... Already fixed that one in my working copy. > To implement the behavior for this report a server needs to keep > track of changes to any member URIs and their mapped resources in a > collection (as defined in Section 3 of [RFC4918]). This includes > > Actually, RFC 4918 defines "member URL"; maybe worth adjusting or > pointing out it's the same. Will make that change in my working copy. BTW "member URI" does appear in 4918 in two places... > Marshalling: > > The request URI MUST identify a collection. The request body MUST > be a DAV:sync-collection XML element (see Section 6.1), which MUST > contain one DAV:sync-token XML element, and one DAV:prop XML > element, and MAY contain a DAV:limit XML element. > > The request MUST include a Depth header with a value of "1" or > "infinity". > > This report definition is in conflict with the definition of the REPORT > method in RFC 3253 > (). > > Essentially, a report is applied to just the request URI (depth: 0 or no > depth header field), the request URI and it's internal members (1) or all > descendants (infinity). > > A report definition should define the response for the case of Depth: 0. > The format for the other cases follows directly from RFC 3253: > > "If a Depth request header is included, the response MUST be a 207 > Multi-Status. The request MUST be applied separately to the collection > itself and to all members of the collection that satisfy the Depth value. > The DAV:prop element of a DAV:response for a given resource MUST contain > the requested report for that resource." > > (Note that I have complained about this a long time ago, > ). > > To fix this, the report would need to define Depth: 0 processing on a > collection to mean the changes just on that collection (which means > membership changes, but not changes to member resources), and the other > modes would then follow based on RFC 3253. > > It doesn't seem to be possible to make this change in a way that doesn't > break existing implementations, as RFC 3253 requires the report response > format to be well-formed XML (thus only one root element), and that > format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. > > Optimally, this should be fixed. If this can't be fixed I'd argue that > the spec should be published as Informational, and that it should include > an explanation of the incompatibilty (essentially requiring servers to > special-case this report in case they already use a generic WebDAV REPORT > framework). I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. Given that I feel the sync report is vital for WebDAV operations, for in particular CalDAV and CardDAV, I want to ensure this draft proceeds as a standard, not informational. If you feel strongly about this use of Depth, in spite of my comments above, then I would be willing to make some changes, provided we also include a statement on backwards compatibility (i.e., in an appendix state that clients/servers MAY use/accept the old Depth approach). If we do that we would need to proceed as follows: state that sync report can only be used with Depth:0, add a new request header to define the scope of the sync (e.g. Sync-Depth with values 1 and infinite). If we require Sync-Depth to be present, then we have a means for servers to detect old clients and handle Depth in a backwards compatible manner. > The response body for a successful request MUST be a DAV: > multistatus XML element, which MUST contain one DAV:sync-token > > Maybe s/one/a single/ Not sure why - "one DAV:xxx" is used in several places and I think is pretty clear. > ... > > Preconditions: > > (DAV:valid-sync-token): The DAV:sync-token element value MUST be a > valid token previously returned by the server. A token can become > invalid as the result of being "out of date" (out of the range of > change history maintained by the server), or for other reasons > (e.g. collection deleted, then recreated, access control changes, > etc...). > > Does the sync-token need to originate from the same collection? Yes of course. Perhaps changing the first sentence to: The DAV:sync-token element value MUST be a valid token previously returned by the server for a synchronization report executed on the same request-URI. > > 3.3. Depth behavior > > Servers MUST support both Depth:1 and Depth:infinity behavior with > the DAV:sync-collection report. Clients MUST include either a > Depth:1 or Depth:infinity request header with the DAV:sync-collection > report. > > See above; this contradicts the base definition of REPORT. As stated above, I really don't think this is a contradiction of 3253. > In the case where a mapping between a member URI and the target > collection was removed, then a new mapping with the same URI created, > the member URI MUST be reported as changed and MUST NOT be reported > as removed. > > The client could tell that this happened if the DAV:resourceid property > was included. > > A member URI MUST be reported as changed if its mapped resource's > entity tag value (defined in Section 3.11 of [RFC2616]) has changed > since the request sync-token was generated. > > It should be mentioned that this only works well with resources that are > not content-negotiated. Unless the content negotiation was done as part of the original full sync request? > For example, consider a server that records changes using a > monotonically increasing integer to represent a "revision number" and > uses that quantity as the DAV:sync-token value (appropriately encoded > as a URI). Assume the last DAV:sync-token used by the client was > "http://example.com/sync/10", and since then 15 additional changes > have occurred. If the client executes a DAV:sync-collection request > with a DAV:sync-token of "http://example.com/sync/10", without a > limit the server would return 15 DAV:response elements and a DAV: > > Why 15? Is the assumption that any change to the server causes exactly > one resource to change? What if there were 15 changes to the same > resource? OK, I will clarify the example to imply that the 15 changes are for separate resources. Proposed change: From: and since then 15 additional changes have occurred To: and since then 15 additional changes to different resources have occurred > > sync-token?) > > > > > > > Why do we have DAV: prefixes on some of the DTD elements? > > I haver removed the DAV: prefix in the actual definitions, but kept them in the comments. OK? -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 08:30:24 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932FF21F8C26 for ; Wed, 14 Dec 2011 08:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.755 X-Spam-Level: X-Spam-Status: No, score=-7.755 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMRuWmazXGs5 for ; Wed, 14 Dec 2011 08:30:23 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 81C4021F86EE for ; Wed, 14 Dec 2011 08:30:23 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RariM-0007YG-FT for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 16:29:54 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RariL-0007XS-Om for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 16:29:53 +0000 Received: from mailout-de.gmx.net ([213.165.64.23]) by maggie.w3.org with smtp (Exim 4.72) (envelope-from ) id 1RariF-0001qa-FR for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 16:29:50 +0000 Received: (qmail invoked by alias); 14 Dec 2011 16:29:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 14 Dec 2011 17:29:19 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19tpCN6ii9t7EPoqxqnicee8Yesy/RRLdz2ik12cs WaO4aLWM3iyAWH Message-ID: <4EE8CEDC.9090105@gmx.de> Date: Wed, 14 Dec 2011 17:29:16 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Cyrus Daboo CC: ietf@ietf.org, WebDAV References: <1F36B3D7066D9669ECFC947D@cyrus.local> In-Reply-To: <1F36B3D7066D9669ECFC947D@cyrus.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.23; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1RariF-0001qa-FR 036d0e9b37eb933e76476cb67600be13 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13361 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 16:29:54 +0000 On 2011-12-14 17:06, Cyrus Daboo wrote: > Hi Julian, > > --On December 14, 2011 12:10:27 AM +0100 Julian Reschke > wrote: > >> On 2011-12-02 00:41, The IESG wrote: >>> ... >> >> Abstract >> >> This specification defines an extension to WebDAV that allows >> efficient synchronization of the contents of a WebDAV collection. >> >> -> Expand acronyms on first use. > > Really, doesn't everyone know what WebDAV is by now :-) In any case > fixed in my working copy. Just being "pro-active" :-). The less happens ion AUTH48, the better. >> Typically, the first time a client connects to the server it will >> need to be informed of the entire state of the collection (i.e., a >> full list of all member URIs that are currently in the collection). >> That is done by the client sending an empty token value to the >> server. This indicates to the server that a full listing is >> required. >> >> I think it would be more consistent with other specs not to send an empty >> token, but to send *no* token. > > Existing implementations expect an empty sync-token element. I don't > really see much difference either way on this, so would prefer to leave > it as-is. Would be interesting to know how they treat missing sync tokens. > ... >> Actually, RFC 4918 defines "member URL"; maybe worth adjusting or >> pointing out it's the same. > > Will make that change in my working copy. BTW "member URI" does appear > in 4918 in two places... Errata, errata! >> Marshalling: >> >> The request URI MUST identify a collection. The request body MUST >> be a DAV:sync-collection XML element (see Section 6.1), which MUST >> contain one DAV:sync-token XML element, and one DAV:prop XML >> element, and MAY contain a DAV:limit XML element. >> >> The request MUST include a Depth header with a value of "1" or >> "infinity". >> >> This report definition is in conflict with the definition of the REPORT >> method in RFC 3253 >> (). >> >> Essentially, a report is applied to just the request URI (depth: 0 or no >> depth header field), the request URI and it's internal members (1) or all >> descendants (infinity). >> >> A report definition should define the response for the case of Depth: 0. >> The format for the other cases follows directly from RFC 3253: >> >> "If a Depth request header is included, the response MUST be a 207 >> Multi-Status. The request MUST be applied separately to the collection >> itself and to all members of the collection that satisfy the Depth value. >> The DAV:prop element of a DAV:response for a given resource MUST contain >> the requested report for that resource." >> >> (Note that I have complained about this a long time ago, >> ). >> >> >> To fix this, the report would need to define Depth: 0 processing on a >> collection to mean the changes just on that collection (which means >> membership changes, but not changes to member resources), and the other >> modes would then follow based on RFC 3253. >> >> It doesn't seem to be possible to make this change in a way that doesn't >> break existing implementations, as RFC 3253 requires the report response >> format to be well-formed XML (thus only one root element), and that >> format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. >> >> Optimally, this should be fixed. If this can't be fixed I'd argue that >> the spec should be published as Informational, and that it should include >> an explanation of the incompatibilty (essentially requiring servers to >> special-case this report in case they already use a generic WebDAV REPORT >> framework). > > I am not convinced the use of Depth in sync report is violating the > definition in 3253. In some ways it is a matter of how you look at the It does. RFC 3253 defines the response format for Depth 0, and then states how the format for Depth > 0 is derived from that; essentially by packaging into . This means that reports that do not support Depth 0 can not be defined. It also means that a report that uses for Depth 0, and which supports depths > 0, will have to packages inside . > sync. Your viewpoint is that the report asks the collection for its > changes - in that case, yes, Depth:0 would apply. The other view is that > the report asks each of the child resources to list their change status, > in which case Depth:1 and Depth:infinity also makes sense. Which > viewpoint is taken probably depends on actual implementation rather than > any perceived protocol restrictions. What Depth 0 means is just a matter of definition. If you want to make Depth 0 mean "request-URI and all of it's direct members", that's fine. It just will give funny results when you use it with other Depths *and* follow the RFC 3253 definition in these cases. > Given that I feel the sync report is vital for WebDAV operations, for in > particular CalDAV and CardDAV, I want to ensure this draft proceeds as a > standard, not informational. If you feel strongly about this use of > Depth, in spite of my comments above, then I would be willing to make > some changes, provided we also include a statement on backwards > compatibility (i.e., in an appendix state that clients/servers MAY > use/accept the old Depth approach). If we do that we would need to > proceed as follows: state that sync report can only be used with > Depth:0, add a new request header to define the scope of the sync (e.g. > Sync-Depth with values 1 and infinite). If we require Sync-Depth to be > present, then we have a means for servers to detect old clients and > handle Depth in a backwards compatible manner. Not happy having to add a new header field just for that. A simpler approach might be to just assign a different report name, and then allow all depths. >> The response body for a successful request MUST be a DAV: >> multistatus XML element, which MUST contain one DAV:sync-token >> >> Maybe s/one/a single/ > > Not sure why - "one DAV:xxx" is used in several places and I think is > pretty clear. I was confused for a moment because I read it to be one token per response element. >> ... >> >> Preconditions: >> >> (DAV:valid-sync-token): The DAV:sync-token element value MUST be a >> valid token previously returned by the server. A token can become >> invalid as the result of being "out of date" (out of the range of >> change history maintained by the server), or for other reasons >> (e.g. collection deleted, then recreated, access control changes, >> etc...). >> >> Does the sync-token need to originate from the same collection? > > Yes of course. Perhaps changing the first sentence to: > > The DAV:sync-token element value MUST be a valid token previously > returned by the server for a synchronization report executed on the same > request-URI. +1 (I was asking because in many cases the token will be the same everywhere, and clients might think this is always the case) > ... >> In the case where a mapping between a member URI and the target >> collection was removed, then a new mapping with the same URI created, >> the member URI MUST be reported as changed and MUST NOT be reported >> as removed. >> >> The client could tell that this happened if the DAV:resourceid property >> was included. >> >> A member URI MUST be reported as changed if its mapped resource's >> entity tag value (defined in Section 3.11 of [RFC2616]) has changed >> since the request sync-token was generated. >> >> It should be mentioned that this only works well with resources that are >> not content-negotiated. > > Unless the content negotiation was done as part of the original full > sync request? How would that work? For instance, the common case for Conneg is using Accept:, but Accept: on REPORT specifies the expected media type for the REPORT response. Yes, that's a problem with WebDAV in general. >> For example, consider a server that records changes using a >> monotonically increasing integer to represent a "revision number" and >> uses that quantity as the DAV:sync-token value (appropriately encoded >> as a URI). Assume the last DAV:sync-token used by the client was >> "http://example.com/sync/10", and since then 15 additional changes >> have occurred. If the client executes a DAV:sync-collection request >> with a DAV:sync-token of "http://example.com/sync/10", without a >> limit the server would return 15 DAV:response elements and a DAV: >> >> Why 15? Is the assumption that any change to the server causes exactly >> one resource to change? What if there were 15 changes to the same >> resource? > > OK, I will clarify the example to imply that the 15 changes are for > separate resources. Proposed change: > > From: and since then 15 additional changes have occurred > To: and since then 15 additional changes to different resources have > occurred +1 >> > sync-token?) > >> >> >> >> >> >> Why do we have DAV: prefixes on some of the DTD elements? >> >> > > I haver removed the DAV: prefix in the actual > definitions, but kept them in the comments. OK? OK. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 09:03:37 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1EA21F84C1 for ; Wed, 14 Dec 2011 09:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdQ9IWysbkjF for ; Wed, 14 Dec 2011 09:03:36 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEDE21F84B5 for ; Wed, 14 Dec 2011 09:03:32 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RasEK-0005Kq-9r for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 17:02:56 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RasEJ-0005Ja-4p for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 17:02:55 +0000 Received: from smtp.andrew.cmu.edu ([128.2.11.61]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1RasEE-0003Cf-Nq for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 17:02:55 +0000 Received: from ksm-t3400.murch.local (cpe-76-180-146-99.buffalo.res.rr.com [76.180.146.99]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id pBEH1blS009135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Dec 2011 12:01:38 -0500 Message-ID: <4EE8D671.9040607@andrew.cmu.edu> Date: Wed, 14 Dec 2011 12:01:37 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Cyrus Daboo CC: Julian Reschke , ietf@ietf.org, WebDAV References: <1F36B3D7066D9669ECFC947D@cyrus.local> In-Reply-To: <1F36B3D7066D9669ECFC947D@cyrus.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.18.170322 X-SMTP-Spam-Clean: 8% ( BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1500_1599 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, CHILD_EX_X3 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_MEDIA_2_BODY 0, __CP_NAME_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RATWARE_X_MAILER_CS_B 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __USER_AGENT 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.61 Received-SPF: none client-ip=128.2.11.61; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.482 X-W3C-Scan-Sig: maggie.w3.org 1RasEE-0003Cf-Nq 1d3a41c91d8d8696ae2cc493a8359f30 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13362 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 17:02:56 +0000 Cyrus Daboo wrote: > I am not convinced the use of Depth in sync report is violating the > definition in 3253. In some ways it is a matter of how you look at the > sync. Your viewpoint is that the report asks the collection for its > changes - in that case, yes, Depth:0 would apply. The other view is that > the report asks each of the child resources to list their change status, > in which case Depth:1 and Depth:infinity also makes sense. Which > viewpoint is taken probably depends on actual implementation rather than > any perceived protocol restrictions. My $.02: I look the sync report as a filtered query for properties (e.g. CALDAV:calendar-query), with the filter being "only give me a DAV:response if the resource has been changed/removed since the specified sync-token". A Depth of 1 or infinity gives us exactly what is specified in the draft. A Depth of 0 refers to the collection itself, and assuming it exists, the DAV:multistatus response may or may not include a single DAV:response element, depending on whether the server maintains an entity tag on the collection which changes with its membership. In either case, the sync-token is returned per the extended grammar in 6.3. So, a sync-collection report with a depth of 0 might simply return the following: http://example.com/ns/sync/1234 Does this make sense, or is my logic completely convoluted? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 09:20:42 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BBD1F0C47 for ; Wed, 14 Dec 2011 09:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.402 X-Spam-Level: X-Spam-Status: No, score=-8.402 tagged_above=-999 required=5 tests=[AWL=1.597, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPm9jWVmDwU6 for ; Wed, 14 Dec 2011 09:20:41 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F1E5921F8BE5 for ; Wed, 14 Dec 2011 09:20:40 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RasUl-00077q-3N for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 17:19:55 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RasUk-00076x-73 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 17:19:54 +0000 Received: from mailout-de.gmx.net ([213.165.64.22]) by aji.keio.w3.org with smtp (Exim 4.72) (envelope-from ) id 1RasUg-00027Y-NG for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 17:19:53 +0000 Received: (qmail invoked by alias); 14 Dec 2011 17:19:17 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 14 Dec 2011 18:19:17 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/tlMR/OB/trMgLEeZhJer7WvwP6cHxI6qDGEK+DB SYRxQWcL16Pr8k Message-ID: <4EE8DA8F.4020808@gmx.de> Date: Wed, 14 Dec 2011 18:19:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ken Murchison CC: Cyrus Daboo , ietf@ietf.org, WebDAV References: <1F36B3D7066D9669ECFC947D@cyrus.local> <4EE8D671.9040607@andrew.cmu.edu> In-Reply-To: <4EE8D671.9040607@andrew.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.22; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: aji.keio.w3.org 1RasUg-00027Y-NG 41b56a257ad7aded6960ccbb314a21c4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13363 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 17:19:55 +0000 On 2011-12-14 18:01, Ken Murchison wrote: > Cyrus Daboo wrote: > >> I am not convinced the use of Depth in sync report is violating the >> definition in 3253. In some ways it is a matter of how you look at the >> sync. Your viewpoint is that the report asks the collection for its >> changes - in that case, yes, Depth:0 would apply. The other view is >> that the report asks each of the child resources to list their change >> status, in which case Depth:1 and Depth:infinity also makes sense. >> Which viewpoint is taken probably depends on actual implementation >> rather than any perceived protocol restrictions. > > My $.02: > > I look the sync report as a filtered query for properties (e.g. > CALDAV:calendar-query), with the filter being "only give me a > DAV:response if the resource has been changed/removed since the > specified sync-token". > > A Depth of 1 or infinity gives us exactly what is specified in the draft. > > A Depth of 0 refers to the collection itself, and assuming it exists, > the DAV:multistatus response may or may not include a single > DAV:response element, depending on whether the server maintains an > entity tag on the collection which changes with its membership. In > either case, the sync-token is returned per the extended grammar in 6.3. > > So, a sync-collection report with a depth of 0 might simply return the > following: > > > http://example.com/ns/sync/1234 > > > > Does this make sense, or is my logic completely convoluted? If this was designed from scratch, it wouldn't be using multistatus, but would include the properties of the collection (if changed). ... other collection props the report asked for ... <http://example.com/ns/sync/1234 From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 09:28:48 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20E121F8B62 for ; Wed, 14 Dec 2011 09:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.942 X-Spam-Level: X-Spam-Status: No, score=-6.942 tagged_above=-999 required=5 tests=[AWL=1.857, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OESiD8LRy7uL for ; Wed, 14 Dec 2011 09:28:47 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15521F8B56 for ; Wed, 14 Dec 2011 09:28:47 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Rascz-00011x-Jv for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 17:28:25 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Rascy-00010p-LK for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 17:28:25 +0000 Received: from daboo.name ([173.13.55.49]) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1Rascu-0002Zk-PZ for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 17:28:23 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AABF31E55F49; Wed, 14 Dec 2011 12:27:51 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1NkBOv1puHg; Wed, 14 Dec 2011 12:27:50 -0500 (EST) Received: from [17.45.162.181] (unknown [17.45.162.181]) by daboo.name (Postfix) with ESMTPSA id 845FC1E55F3E; Wed, 14 Dec 2011 12:27:49 -0500 (EST) Date: Wed, 14 Dec 2011 12:27:59 -0500 From: Cyrus Daboo To: Julian Reschke cc: ietf@ietf.org, WebDAV Message-ID: <017C07CDCBE6162D356E84A5@cyrus.local> In-Reply-To: <4EE8CEDC.9090105@gmx.de> References: <1F36B3D7066D9669ECFC947D@cyrus.local> <4EE8CEDC.9090105@gmx.de> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=4871 Received-SPF: none client-ip=173.13.55.49; envelope-from=cyrus@daboo.name; helo=daboo.name X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.482 X-W3C-Scan-Sig: aji.keio.w3.org 1Rascu-0002Zk-PZ 48fe0b7a1eaf0400c9171584cb833e13 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13364 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 17:28:25 +0000 Hi Julian, --On December 14, 2011 5:29:16 PM +0100 Julian Reschke wrote: >> I am not convinced the use of Depth in sync report is violating the >> definition in 3253. In some ways it is a matter of how you look at the > > It does. > > RFC 3253 defines the response format for Depth 0, and then states how the > format for Depth > 0 is derived from that; essentially by packaging into > . > > This means that reports that do not support Depth 0 can not be defined. > > It also means that a report that uses for Depth 0, and > which supports depths > 0, will have to packages inside > . Well I don't consider the text there very clear at all. In fact I think it is very much tailored to the 3253 use cases and not flexible enough for other general purpose use of REPORT. It states this: The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. Which implies "packaging" of multistatus within the DAV:prop element, which seems completely wrong to me. >> sync. Your viewpoint is that the report asks the collection for its >> changes - in that case, yes, Depth:0 would apply. The other view is that >> the report asks each of the child resources to list their change status, >> in which case Depth:1 and Depth:infinity also makes sense. Which >> viewpoint is taken probably depends on actual implementation rather than >> any perceived protocol restrictions. > > What Depth 0 means is just a matter of definition. If you want to make > Depth 0 mean "request-URI and all of it's direct members", that's fine. > It just will give funny results when you use it with other Depths *and* > follow the RFC 3253 definition in these cases. So would it hurt to allow this spec to override the 3253 "nested multistatus" requirement in the interests of generating a compact response specific to this type of report? >> Given that I feel the sync report is vital for WebDAV operations, for in >> particular CalDAV and CardDAV, I want to ensure this draft proceeds as a >> standard, not informational. If you feel strongly about this use of >> Depth, in spite of my comments above, then I would be willing to make >> some changes, provided we also include a statement on backwards >> compatibility (i.e., in an appendix state that clients/servers MAY >> use/accept the old Depth approach). If we do that we would need to >> proceed as follows: state that sync report can only be used with >> Depth:0, add a new request header to define the scope of the sync (e.g. >> Sync-Depth with values 1 and infinite). If we require Sync-Depth to be >> present, then we have a means for servers to detect old clients and >> handle Depth in a backwards compatible manner. > > Not happy having to add a new header field just for that. A simpler > approach might be to just assign a different report name, and then allow > all depths. I think if you insist on requiring Depth => nested multistatus, then we either add a new header or perhaps a element inside the request body (and that would also be reasonable in terms of being able to support backwards compatibility). At this point I would prefer the later as being least disruptive to existing implementations. >>> In the case where a mapping between a member URI and the target >>> collection was removed, then a new mapping with the same URI created, >>> the member URI MUST be reported as changed and MUST NOT be reported >>> as removed. >>> >>> The client could tell that this happened if the DAV:resourceid property >>> was included. >>> >>> A member URI MUST be reported as changed if its mapped resource's >>> entity tag value (defined in Section 3.11 of [RFC2616]) has changed >>> since the request sync-token was generated. >>> >>> It should be mentioned that this only works well with resources that are >>> not content-negotiated. >> >> Unless the content negotiation was done as part of the original full >> sync request? > > How would that work? > > For instance, the common case for Conneg is using Accept:, but Accept: on > REPORT specifies the expected media type for the REPORT response. > > Yes, that's a problem with WebDAV in general. OK, so we should probably punt on per-resource content-negotiation within the report itself (though I could see us wanting to support that in the future, in which case it would probably be done through extensions elements in the request body). So what do we need to do to address this? State that the etags returned in the report are always for the non-content-negotiated representation of each child resource? I think that is already implied by the definition of DAV:getetag, so perhaps we should state that we are referring to that value, which is the non-content negotiated entity tag. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 09:32:54 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B906C11E80A1 for ; Wed, 14 Dec 2011 09:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.666 X-Spam-Level: X-Spam-Status: No, score=-8.666 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX9+wZW0V3kb for ; Wed, 14 Dec 2011 09:32:54 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3B29111E8089 for ; Wed, 14 Dec 2011 09:32:54 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Rash1-0004WJ-Eo for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 17:32:35 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Rash0-0004VX-LH for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 17:32:34 +0000 Received: from smtp.andrew.cmu.edu ([128.2.11.96]) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1Rasgv-0002mK-SY for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 17:32:33 +0000 Received: from ksm-t3400.murch.local (cpe-76-180-146-99.buffalo.res.rr.com [76.180.146.99]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id pBEHTIAu016990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Dec 2011 12:29:19 -0500 Message-ID: <4EE8DCEE.6020602@andrew.cmu.edu> Date: Wed, 14 Dec 2011 12:29:18 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Julian Reschke CC: Cyrus Daboo , ietf@ietf.org, WebDAV References: <1F36B3D7066D9669ECFC947D@cyrus.local> <4EE8D671.9040607@andrew.cmu.edu> <4EE8DA8F.4020808@gmx.de> In-Reply-To: <4EE8DA8F.4020808@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.4.9.4220 X-SMTP-Spam-Clean: 8% ( BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, CHILD_EX_X3 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_MEDIA_2_BODY 0, __CP_NAME_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __USER_AGENT 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.96 Received-SPF: none client-ip=128.2.11.96; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.482 X-W3C-Scan-Sig: aji.keio.w3.org 1Rasgv-0002mK-SY 528433920d78fa4c4f94b2c8f92a335b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13365 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 17:32:35 +0000 Julian Reschke wrote: > On 2011-12-14 18:01, Ken Murchison wrote: >> Cyrus Daboo wrote: >> >>> I am not convinced the use of Depth in sync report is violating the >>> definition in 3253. In some ways it is a matter of how you look at the >>> sync. Your viewpoint is that the report asks the collection for its >>> changes - in that case, yes, Depth:0 would apply. The other view is >>> that the report asks each of the child resources to list their change >>> status, in which case Depth:1 and Depth:infinity also makes sense. >>> Which viewpoint is taken probably depends on actual implementation >>> rather than any perceived protocol restrictions. >> >> My $.02: >> >> I look the sync report as a filtered query for properties (e.g. >> CALDAV:calendar-query), with the filter being "only give me a >> DAV:response if the resource has been changed/removed since the >> specified sync-token". >> >> A Depth of 1 or infinity gives us exactly what is specified in the draft. >> >> A Depth of 0 refers to the collection itself, and assuming it exists, >> the DAV:multistatus response may or may not include a single >> DAV:response element, depending on whether the server maintains an >> entity tag on the collection which changes with its membership. In >> either case, the sync-token is returned per the extended grammar in 6.3. >> >> So, a sync-collection report with a depth of 0 might simply return the >> following: >> >> >> http://example.com/ns/sync/1234 >> >> >> >> Does this make sense, or is my logic completely convoluted? > > If this was designed from scratch, it wouldn't be using multistatus, but > would include the properties of the collection (if changed). > > > ... other collection props the report asked for ... > <http://example.com/ns/sync/1234 > I don't necessarily see a problem with sync report using multistatus, but perhaps the sync-token should be returned in a prop response element for the collection rather than as an added element of multistatus. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 09:35:45 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E940F21F8B9C for ; Wed, 14 Dec 2011 09:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.91 X-Spam-Level: X-Spam-Status: No, score=-7.91 tagged_above=-999 required=5 tests=[AWL=2.689, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG6+69qvT3vC for ; Wed, 14 Dec 2011 09:35:45 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 74D1121F8BB3 for ; Wed, 14 Dec 2011 09:35:45 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Rasjj-0004q5-QR for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 17:35:23 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Rasjj-0004pI-1k for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 17:35:23 +0000 Received: from daboo.name ([173.13.55.49]) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1Rasjf-0002tD-2F for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 17:35:22 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id CD1821E5608E; Wed, 14 Dec 2011 12:34:52 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiiGwFA9OKA1; Wed, 14 Dec 2011 12:34:50 -0500 (EST) Received: from [17.45.162.181] (unknown [17.45.162.181]) by daboo.name (Postfix) with ESMTPSA id 4429E1E56081; Wed, 14 Dec 2011 12:34:48 -0500 (EST) Date: Wed, 14 Dec 2011 12:34:59 -0500 From: Cyrus Daboo To: Ken Murchison , Julian Reschke cc: ietf@ietf.org, WebDAV Message-ID: <169B41A30301EBED00F8C6FD@cyrus.local> In-Reply-To: <4EE8DCEE.6020602@andrew.cmu.edu> References: <1F36B3D7066D9669ECFC947D@cyrus.local> <4EE8D671.9040607@andrew.cmu.edu> <4EE8DA8F.4020808@gmx.de> <4EE8DCEE.6020602@andrew.cmu.edu> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=669 Received-SPF: none client-ip=173.13.55.49; envelope-from=cyrus@daboo.name; helo=daboo.name X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.482 X-W3C-Scan-Sig: aji.keio.w3.org 1Rasjf-0002tD-2F 6e108c0b24bf75ffa5d3d1bd895eb1df X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13366 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 17:35:23 +0000 Hi Ken, --On December 14, 2011 12:29:18 PM -0500 Ken Murchison wrote: >> >> ... other collection props the report asked for ... >> <http://example.com/ns/sync/1234 >> > > I don't necessarily see a problem with sync report using multistatus, but > perhaps the sync-token should be returned in a prop response element for > the collection rather than as an added element of multistatus. That won't work when the "limiting/truncation" option is used as the multistatus response for the collection indicates an overall status error, rather than using propstat. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 09:50:45 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FDC1F0C5F for ; Wed, 14 Dec 2011 09:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.817 X-Spam-Level: X-Spam-Status: No, score=-7.817 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HI-y7CddtfyM for ; Wed, 14 Dec 2011 09:50:44 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4CE1F0C5B for ; Wed, 14 Dec 2011 09:50:44 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Rasy9-0000wl-LY for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 17:50:17 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Rasy9-0000vy-2V for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 17:50:17 +0000 Received: from mailout-de.gmx.net ([213.165.64.23]) by maggie.w3.org with smtp (Exim 4.72) (envelope-from ) id 1Rasy7-0005VX-H3 for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 17:50:17 +0000 Received: (qmail invoked by alias); 14 Dec 2011 17:43:09 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 14 Dec 2011 18:43:09 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19E1DpUsLNEbNjHyXgr2RZ7WA4snFZvVT84og8lRs m0sxJcYGcLRbjZ Message-ID: <4EE8E02A.40208@gmx.de> Date: Wed, 14 Dec 2011 18:43:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Cyrus Daboo CC: ietf@ietf.org, WebDAV References: <1F36B3D7066D9669ECFC947D@cyrus.local> <4EE8CEDC.9090105@gmx.de> <017C07CDCBE6162D356E84A5@cyrus.local> In-Reply-To: <017C07CDCBE6162D356E84A5@cyrus.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.23; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1Rasy7-0005VX-H3 86da3210e0d2791b5d4e3867c3731ece X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13367 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 17:50:17 +0000 On 2011-12-14 18:27, Cyrus Daboo wrote: > Hi Julian, > > --On December 14, 2011 5:29:16 PM +0100 Julian Reschke > wrote: > >>> I am not convinced the use of Depth in sync report is violating the >>> definition in 3253. In some ways it is a matter of how you look at the >> >> It does. >> >> RFC 3253 defines the response format for Depth 0, and then states how the >> format for Depth > 0 is derived from that; essentially by packaging into >> . >> >> This means that reports that do not support Depth 0 can not be defined. >> >> It also means that a report that uses for Depth 0, and >> which supports depths > 0, will have to packages inside >> . > > Well I don't consider the text there very clear at all. In fact I think > it is very much tailored to the 3253 use cases and not flexible enough > for other general purpose use of REPORT. It states this: > > The DAV:prop element of a DAV:response > for a given resource MUST contain the requested report for that > resource. It states what it states :-) > Which implies "packaging" of multistatus within the DAV:prop element, > which seems completely wrong to me. No, you only need to package inside in case the response to the Depth: 0 request uses . >>> sync. Your viewpoint is that the report asks the collection for its >>> changes - in that case, yes, Depth:0 would apply. The other view is that >>> the report asks each of the child resources to list their change status, >>> in which case Depth:1 and Depth:infinity also makes sense. Which >>> viewpoint is taken probably depends on actual implementation rather than >>> any perceived protocol restrictions. >> >> What Depth 0 means is just a matter of definition. If you want to make >> Depth 0 mean "request-URI and all of it's direct members", that's fine. >> It just will give funny results when you use it with other Depths *and* >> follow the RFC 3253 definition in these cases. > > So would it hurt to allow this spec to override the 3253 "nested > multistatus" requirement in the interests of generating a compact > response specific to this type of report? I think so, because it defeats WebDAV stacks from executing reports consistently. (And, I assure you, I have written a framework in the past that did exactly that, otherwise I probably wouldn't have noticed the problem). >>> Given that I feel the sync report is vital for WebDAV operations, for in >>> particular CalDAV and CardDAV, I want to ensure this draft proceeds as a >>> standard, not informational. If you feel strongly about this use of >>> Depth, in spite of my comments above, then I would be willing to make >>> some changes, provided we also include a statement on backwards >>> compatibility (i.e., in an appendix state that clients/servers MAY >>> use/accept the old Depth approach). If we do that we would need to >>> proceed as follows: state that sync report can only be used with >>> Depth:0, add a new request header to define the scope of the sync (e.g. >>> Sync-Depth with values 1 and infinite). If we require Sync-Depth to be >>> present, then we have a means for servers to detect old clients and >>> handle Depth in a backwards compatible manner. >> >> Not happy having to add a new header field just for that. A simpler >> approach might be to just assign a different report name, and then allow >> all depths. > > I think if you insist on requiring Depth => nested multistatus, then we > either add a new header or perhaps a element inside the request > body (and that would also be reasonable in terms of being able to > support backwards compatibility). At this point I would prefer the later > as being least disruptive to existing implementations. Yes, a new child element of the request body () works for me. >>>> In the case where a mapping between a member URI and the target >>>> collection was removed, then a new mapping with the same URI created, >>>> the member URI MUST be reported as changed and MUST NOT be reported >>>> as removed. >>>> >>>> The client could tell that this happened if the DAV:resourceid property >>>> was included. >>>> >>>> A member URI MUST be reported as changed if its mapped resource's >>>> entity tag value (defined in Section 3.11 of [RFC2616]) has changed >>>> since the request sync-token was generated. >>>> >>>> It should be mentioned that this only works well with resources that >>>> are >>>> not content-negotiated. >>> >>> Unless the content negotiation was done as part of the original full >>> sync request? >> >> How would that work? >> >> For instance, the common case for Conneg is using Accept:, but Accept: on >> REPORT specifies the expected media type for the REPORT response. >> >> Yes, that's a problem with WebDAV in general. > > OK, so we should probably punt on per-resource content-negotiation > within the report itself (though I could see us wanting to support that > in the future, in which case it would probably be done through > extensions elements in the request body). > > So what do we need to do to address this? State that the etags returned > in the report are always for the non-content-negotiated representation > of each child resource? I think that is already implied by the > definition of DAV:getetag, so perhaps we should state that we are > referring to that value, which is the non-content negotiated entity tag. Yes, REPORT and PROPFIND should be consistent. Let's solve this puzzle another day. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 15:30:19 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8D11F0C4B for ; Wed, 14 Dec 2011 15:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.465 X-Spam-Level: X-Spam-Status: No, score=-8.465 tagged_above=-999 required=5 tests=[AWL=1.534, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rspIgcEWM6jl for ; Wed, 14 Dec 2011 15:30:19 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEE81F0C47 for ; Wed, 14 Dec 2011 15:30:19 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RayFi-0001Vc-4l for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2011 23:28:46 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RayFf-0001Ul-T0 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2011 23:28:43 +0000 Received: from mailout-de.gmx.net ([213.165.64.22]) by maggie.w3.org with smtp (Exim 4.72) (envelope-from ) id 1RayFe-0006wq-3h for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 23:28:43 +0000 Received: (qmail invoked by alias); 14 Dec 2011 23:28:15 -0000 Received: from p5DCC3B75.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.59.117] by mail.gmx.net (mp024) with SMTP; 15 Dec 2011 00:28:15 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX189Cmptets9JsVmrxIHaA51vjs0cZ/ZsOkJ7S2Dxs WusepTcM+2vzSp Message-ID: <4EE930FF.8070701@gmx.de> Date: Thu, 15 Dec 2011 00:27:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Cyrus Daboo CC: Ken Murchison , ietf@ietf.org, WebDAV References: <1F36B3D7066D9669ECFC947D@cyrus.local> <4EE8D671.9040607@andrew.cmu.edu> <4EE8DA8F.4020808@gmx.de> <4EE8DCEE.6020602@andrew.cmu.edu> <169B41A30301EBED00F8C6FD@cyrus.local> In-Reply-To: <169B41A30301EBED00F8C6FD@cyrus.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.22; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1RayFe-0006wq-3h b2a82f6b683abf8e89d777a0e7f20bbc X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13368 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 14 Dec 2011 23:28:46 +0000 On 2011-12-14 18:34, Cyrus Daboo wrote: > Hi Ken, > > --On December 14, 2011 12:29:18 PM -0500 Ken Murchison > wrote: > >>> >>> ... other collection props the report asked for ... >>> <http://example.com/ns/sync/1234 >>> >> >> I don't necessarily see a problem with sync report using multistatus, but >> perhaps the sync-token should be returned in a prop response element for >> the collection rather than as an added element of multistatus. > > That won't work when the "limiting/truncation" option is used as the > multistatus response for the collection indicates an overall status > error, rather than using propstat. OK, so it would need to be part of the sync-result (and the other props be included with a DAV:prop container). Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Wed Dec 14 16:21:51 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AAA21F8AD1 for ; Wed, 14 Dec 2011 16:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.584 X-Spam-Level: X-Spam-Status: No, score=-7.584 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln1I7C1YalaM for ; Wed, 14 Dec 2011 16:21:51 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F1C1F21F8ABD for ; Wed, 14 Dec 2011 16:21:50 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Raz4T-0001yk-Ot for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2011 00:21:13 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Raz4R-0001xl-0i for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2011 00:21:11 +0000 Received: from fich.unl.edu.ar ([190.122.240.170]) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1Raz4M-0000Hd-RO for w3c-dist-auth@w3.org; Thu, 15 Dec 2011 00:21:10 +0000 Received: from localhost ([127.0.0.1]) by fich.unl.edu.ar (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits)) for w3c-dist-auth@w3.org; Wed, 14 Dec 2011 21:18:22 -0300 Message-ID: <74AD90A6360A45549965F59C1EC5ED7C@Javier2> From: "Javier Godoy" To: Date: Wed, 14 Dec 2011 21:17:32 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Received-SPF: pass client-ip=190.122.240.170; envelope-from=rjgodoy@fich.unl.edu.ar; helo=fich.unl.edu.ar X-W3C-Hub-Spam-Status: No, score=-0.8 X-W3C-Hub-Spam-Report: BAYES_05=-0.5, RP_MATCHES_RCVD=-2.482, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757 X-W3C-Scan-Sig: aji.keio.w3.org 1Raz4M-0000Hd-RO e4f917a5d13695e6a21aff5d61a84e8a X-Original-To: w3c-dist-auth@w3.org Subject: About COPY Overwrite:T Depth:0 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13369 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 15 Dec 2011 00:21:13 +0000 RFC 4918 section 9.8.4 defines overwrite with Depth:infinity (When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY), but the exact meaning of an overwrite copy with Depth:0 is not defined. I would like to know what is the expected behavior of a COPY with Overwrite:T and Depth:0? i.e. whether /dst/bar exists or not, after the following methods are executed in order: MKCOL /src MKCOL /src/foo MKCOL /dst MKCOL /dst/bar COPY /src to /dst with Depth:0 and Overwrite:F >From RFC 4918, section 9.8.3: A COPY of "Depth: 0" only instructs that the collection and its properties, but not resources identified by its internal member URLs, are to be copied. The Litmus test suite (v0.13) does not check this behavior. There is a fork of Litmus that expects the resource to exists after the Depth:0 copy (test depth_zero_copy in http://github.com/tolsen/litmus/), but the test suite of PerlDAV v0.45 takes the opposite approach (test 6_dav_copy_move.t). What is the correct interpretation? Best Regards Javier From w3c-dist-auth-request@listhub.w3.org Thu Dec 15 00:49:38 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0C121F85D1 for ; Thu, 15 Dec 2011 00:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.878 X-Spam-Level: X-Spam-Status: No, score=-7.878 tagged_above=-999 required=5 tests=[AWL=2.122, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU3ZjI2iMWJm for ; Thu, 15 Dec 2011 00:49:38 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5F70C21F85C7 for ; Thu, 15 Dec 2011 00:49:38 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Rb6zA-0005rY-FR for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2011 08:48:16 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Rb6z6-0005pN-7i for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2011 08:48:12 +0000 Received: from acsinet15.oracle.com ([141.146.126.227]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1Rb6z2-00082g-Vb for w3c-dist-auth@w3.org; Thu, 15 Dec 2011 08:48:11 +0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBF8lTNg027823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Dec 2011 08:47:30 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBF8lRle018332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Dec 2011 08:47:27 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBF8lPx8008537; Thu, 15 Dec 2011 02:47:26 -0600 Received: from [192.168.1.100] (/89.157.166.32) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Dec 2011 00:47:25 -0800 Message-ID: <4EE9B41B.2060206@oracle.com> Date: Thu, 15 Dec 2011 09:47:23 +0100 From: Arnaud Quillaud Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Cyrus Daboo CC: Julian Reschke , ietf@ietf.org, WebDAV References: <1F36B3D7066D9669ECFC947D@cyrus.local> <4EE8CEDC.9090105@gmx.de> <017C07CDCBE6162D356E84A5@cyrus.local> In-Reply-To: <017C07CDCBE6162D356E84A5@cyrus.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4EE9B422.018B,ss=1,re=0.000,fgs=0 Received-SPF: none client-ip=141.146.126.227; envelope-from=arnaud.quillaud@oracle.com; helo=acsinet15.oracle.com X-W3C-Hub-Spam-Status: No, score=-4.2 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.31 X-W3C-Scan-Sig: maggie.w3.org 1Rb6z2-00082g-Vb e4489ad0b9bbe54bcab7dfcdb18c7287 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13370 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 15 Dec 2011 08:48:16 +0000 On 14/12/2011 18:27, Cyrus Daboo wrote: >>>> >>>> A member URI MUST be reported as changed if its mapped resource's >>>> entity tag value (defined in Section 3.11 of [RFC2616]) has changed >>>> since the request sync-token was generated. >>>> >>>> It should be mentioned that this only works well with resources >>>> that are >>>> not content-negotiated. >>> >>> Unless the content negotiation was done as part of the original full >>> sync request? >> >> How would that work? >> >> For instance, the common case for Conneg is using Accept:, but >> Accept: on >> REPORT specifies the expected media type for the REPORT response. >> >> Yes, that's a problem with WebDAV in general. > > OK, so we should probably punt on per-resource content-negotiation > within the report itself (though I could see us wanting to support > that in the future, in which case it would probably be done through > extensions elements in the request body). > > So what do we need to do to address this? State that the etags > returned in the report are always for the non-content-negotiated > representation of each child resource? I think that is already implied > by the definition of DAV:getetag, so perhaps we should state that we > are referring to that value, which is the non-content negotiated > entity tag. In the text above, we are only talking about a change of value, not about a specific value. Are there really a lot of cases where the non-content negotiated etag would not change while a content negotiated one would ? Unless that is a common scenario, I would not clobber the text with this additional statement. The opposite case (non content-negotiated changes while content negotiated does not) is even less problematic as it would just result in a false positive for clients using content negotiation. Arnaud From ana@lopar.hr Sat Dec 17 23:52:07 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650E221F845F for ; Sat, 17 Dec 2011 23:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.572 X-Spam-Level: **** X-Spam-Status: No, score=4.572 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Txdzk1OMHTEh for ; Sat, 17 Dec 2011 23:52:07 -0800 (PST) Received: from server.super-sat.org (server.super-sat.org [87.117.253.240]) by ietfa.amsl.com (Postfix) with ESMTP id 495D221F845E for ; Sat, 17 Dec 2011 23:52:05 -0800 (PST) Received: from [220.248.174.29] (port=3166 helo=um) by server.super-sat.org with esmtpa (Exim 4.69) (envelope-from ) id 1RcBWB-0002z9-P1; Sun, 18 Dec 2011 07:50:50 +0000 Reply-To: <284325049@qq.com> Message-ID: From: =?utf-8?B?54+g5rW36IGU6aG65ZWG6LS45pyJ6ZmQ5YWs5Y+4?= To: Subject: =?utf-8?B?a3Vm4oCc5rW35YWz5LiJ5aSn6LSo55aR4oCd6Kej5p6Q5LiO55aR6Zq+5bqU5a+5LXI=?= =?utf-8?B?a3c=?= Date: Sun, 18 Dec 2011 15:51:33 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0204_0154F487.18F7FEF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.super-sat.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lopar.hr This is a multi-part message in MIME format. ------=_NextPart_000_0204_0154F487.18F7FEF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_038F_0154F487.18F7FEF0" ------=_NextPart_001_038F_0154F487.18F7FEF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCc5ZCE5L2N77yM6K+35YWB6K645oiR5p2l5YGa5Liq5aSn6IOG55qE54yc5oOz77yB5oiR5Lus 5aaC5p6c5piv6L+Z576k5YaS6Zmp6ICF5Lit55qE5aS04oCU4oCU6YKj5Liq5biM54m55YuS55qE 6K+d77yB5qC55o2u5oiR5Lus55qE6LCD5p+l57uT5p6c5p2l55yL77yB4oCdDQrotKjnlpHkuIDv vJrotKjnlpHov5vlh7rlj6PotKfnianllYblk4HnvJbnoIHlvZLnsbvvvIzmgI7kuYjlip7vvJ8N Cui0qOeWkeS6jO+8mui0qOeWkeS8geS4mui/m+WHuuWPo+WVhuWTgeS7t+agvOeUs+aKpe+8jOaA juS5iOWKnu+8nw0K6LSo55aR5LiJ77ya5rW35YWz6LSo55aR5LyB5Lia6L+b5Ye65Y+j5pWw6YeP 55Sz5oql5LiN5a6e77yM5oCO5LmI5Yqe77yfDQrnm7gg5YWzIOeWkSDpmr4g5aaCIOS9lSDlupQg 5a+5IOWwvSDlnKgg6ZmEIOS7tiDlhoUh ------=_NextPart_001_038F_0154F487.18F7FEF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0 Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRl bnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTkwMTkiPjwvSEVBRD4NCjxCT0RZPg0KPFA+PEZPTlQgY29s b3I9d2hpdGUgc2l6ZT0xPuKAnOWQhOS9je+8jOivt+WFgeiuuOaIkeadpeWBmuS4quWkp+iDhuea hOeMnOaDs++8geaIkeS7rOWmguaenOaYr+i/mee+pOWGkumZqeiAheS4reeahOWktOKAlOKAlOmC o+S4quW4jOeJueWLkueahOivne+8geagueaNruaIkeS7rOeahOiwg+afpee7k+aenOadpeeci++8 geKAnTwvRk9OVD48L1A+DQo8UD48Rk9OVCBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogeWVsbG93 Ij7otKjnlpHkuIDvvJrotKjnlpHov5vlh7rlj6PotKfnianllYblk4HnvJbnoIHlvZLnsbvvvIzm gI7kuYjlip7vvJ88L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6 IGFxdWEiPui0qOeWkeS6jO+8mui0qOeWkeS8geS4mui/m+WHuuWPo+WVhuWTgeS7t+agvOeUs+aK pe+8jOaAjuS5iOWKnu+8nzwvRk9OVD48L1A+DQo8UD48Rk9OVCBzdHlsZT0iQkFDS0dST1VORC1D T0xPUjogbGltZSI+6LSo55aR5LiJ77ya5rW35YWz6LSo55aR5LyB5Lia6L+b5Ye65Y+j5pWw6YeP 55Sz5oql5LiN5a6e77yM5oCO5LmI5Yqe77yfPC9GT05UPjwvUD4NCjxQPjxGT05UIGNvbG9yPWJs YWNrPjxTVFJPTkc+55u4IOWFsyDnlpEg6Zq+IDxGT05UIGNvbG9yPXJlZD7lpoIg5L2VIOW6lCDl r7k8L0ZPTlQ+IOWwvSDlnKgg6ZmEIOS7tiANCuWGhSE8L1NUUk9ORz48L0ZPTlQ+PC9QPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_001_038F_0154F487.18F7FEF0-- ------=_NextPart_000_0204_0154F487.18F7FEF0 Content-Type: application/vnd.ms-excel; name="=?utf-8?B?4oCc5rW3zrTlhbMu5LiJLuWkpy7otKjOtOeWkeKAneinoy7mnpDkuI4u55u4LuWFs86055aRLumavi7lupQu5a+5zrTnrZYu55WlLnhscw==?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?B?4oCc5rW3zrTlhbMu5LiJLuWkpy7otKjOtOeWkeKAneinoy7mnpDkuI4u55u4LuWFs86055aRLumavi7lupQu5a+5zrTnrZYu55WlLnhscw==?=" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOwAAAAAAAAAA EAAA/v///wAAAAD+////AAAAADoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAIggzQfJwAAABgMAAOEAAgCwBMEAAgAAAOIAAABcAHAAAgAAICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQIA AQC6AQ8ADAAAVGhpc1dvcmtib29rnAACAA4AGQACAAAAEgACAAAAEwACAAAArwECAAAAvAECAAAA PQASAOABeAA5IbIROAAAAAAAAQBYAkAAAgAAAI0AAgAAACIAAgAAAA4AAgABALcBAgAAANoAAgAA ADEAFADwAAAA/3+QAQAAAACG5QIBi1tTTzEAFADwAAAA/3+QAQAAAACG5QIBi1tTTzEAFADwAAAA /3+QAQAAAACG5QIBi1tTTzEAFADwAAAA/3+QAQAAAACG5QIBi1tTTzEAFAC0AAAA/3+QAQAAAACG 5QIBi1tTTzEAFADwAAAACgCQAQAAAACG5QIBi1tTTzEAFADwAAEACgC8AgAAAACG5QIBi1tTTx4E KwAFABMAASIA5f8iACMALAAjACMAMAA7ACIA5f8iAFwALQAjACwAIwAjADAAHgQ1AAYAGAABIgDl /yIAIwAsACMAIwAwADsAWwBSAGUAZABdACIA5f8iAFwALQAjACwAIwAjADAAHgQ3AAcAGQABIgDl /yIAIwAsACMAIwAwAC4AMAAwADsAIgDl/yIAXAAtACMALAAjACMAMAAuADAAMAAeBEEACAAeAAEi AOX/IgAjACwAIwAjADAALgAwADAAOwBbAFIAZQBkAF0AIgDl/yIAXAAtACMALAAjACMAMAAuADAA MAAeBGkAKgAyAAFfACAAIgDl/yIAKgAgACMALAAjACMAMABfACAAOwBfACAAIgDl/yIAKgAgAFwA LQAjACwAIwAjADAAXwAgADsAXwAgACIA5f8iACoAIAAiAC0AIgBfACAAOwBfACAAQABfACAAHgQu ACkAKQAAXyAqICMsIyMwXyA7XyAqIFwtIywjIzBfIDtfICogIi0iXyA7XyBAXyAeBHkALAA6AAFf ACAAIgDl/yIAKgAgACMALAAjACMAMAAuADAAMABfACAAOwBfACAAIgDl/yIAKgAgAFwALQAjACwA IwAjADAALgAwADAAXwAgADsAXwAgACIA5f8iACoAIAAiAC0AIgA/AD8AXwAgADsAXwAgAEAAXwAg AB4ENgArADEAAF8gKiAjLCMjMC4wMF8gO18gKiBcLSMsIyMwLjAwXyA7XyAqICItIj8/XyA7XyBA XyAeBBoAFwAVAABcJCMsIyMwXyk7XChcJCMsIyMwXCkeBB8AGAAaAABcJCMsIyMwXyk7W1JlZF1c KFwkIywjIzBcKR4EIAAZABsAAFwkIywjIzAuMDBfKTtcKFwkIywjIzAuMDBcKR4EJQAaACAAAFwk IywjIzAuMDBfKTtbUmVkXVwoXCQjLCMjMC4wMFwp4AAUAAAAAAD1/yAAAAAAAAAAAAAAAMAg4AAU AAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAA AMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQA AAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAAB ACAAAAAAAAAAAAAAAMAg4AAUAAEACQD1/yAAAPgAAAAAAAAAAMAg4AAUAAEALAD1/yAAAPgAAAAA AAAAAMAg4AAUAAEAKgD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAKwD1/yAAAPgAAAAAAAAAAMAg4AAU AAEAKQD1/yAAAPgAAAAAAAAAAMAg4AAUAAYAAAABACAAAAgAAAAAAAAAAMAg4AAUAAcAAAABACAA AAgAAAAAAAAAAMAg4AAUAAAAAAABACAAAEAAAAAAAAAABA0gkwIEABCABf+TAgQAAIAA/5MCBAAR gAT/kwIEABKAB/+TAgQAE4AD/5MCBAAUgAb/YAECAAEAhQAOALwwAAAAAAYAU2hlZXQxjAAEAFYA VgDBAQgAwQEAAIA4AQD8AB8g1QAAANIAAAAmAAEgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgABwgd21zUQlOJ1kojZF1HSDjiZBnDk74dnNRkXW+lpRe+VtWe2V1LgAB/osLejmN KHUa/zIAOAAwADAAQ1EvALpOLwAyAClZDP/CU6BS+04PYQBOKVkxADUAMAAwAENRLwC6Tgj/BVPs YkSNmWU5jQEwSFMQmcpTCk4LTkhTNoO5cEl7Cf8rAAH+iwt6+VthjBr/24/6UeNTAU8aTjtgz34G dAEwaXJBbQEwIo2hUgEw24/6UeNTATClYnNRATDHkS2N2JqnfqF7BnS6TlhULAD6V0JcGk6hUrpO WFRJey4AARAwVID7fLllD18RMCgAMAA3ADUANQApAC0ANgAxADIAOAAyADUANwAxACAAIAAgAC8A IAAgACgAMAAyADEAKQAtADUAMQA4ADcAMwA3ADAAOAAgACAAIAAvACAANQABEDDlXSAAXE8gAFEA IAARMCAAMQAwADcAOAA4ADYAMQAxADEAOAAgACAAIAAgACAAIAAgAEUATQBhAGkAbAA6AGMAaABp AG4AYQBzAHkAcAB4AEAAZgBvAHgAbQBhAGkAbAAuAGMAbwBtACgAAWEiYSJhImEiYSJhImEiYSJh ImEiYSJhImEiYSJhImEiYSJhImEiYSJhImEiYSJhImEiYSJhImEiYSJhImEiYSJhImEiYSJhImEi YSJhImEiBwAB/osgAAt6IADMgCAAb2YqAAEgACAAIAAgAI+WQHd3bXNRBlJ7fBqQc1E5ZWmXhHYN Tq1lqGPbjwz/AGfRjwz/KFdoUf1WBFRzUTpTCWcnWc+RAU8aTquId21zUeVOHCDbj/pR41MoAAEn jWlyRlXBVBZ/AXhSX3t8HSABMBwg24/6UeNTRlXBVPdOPGgdIAEwHCDbj/pR41NwZc+RHSAzdaVi DU6eWzpOMXVJe22Q11N3bXNRKI2RdSgAAYxUBFlafwz/dlEtTg1OT04JZ4WNJ1mLV4ltFlkBTxpO DP8NTsVOcV/NVAFPGk6EdmNrOF4akHNRATBEjdGRaFRsj4xU+lHjUwCQDnoM/9iPDgAB+VsBTxpO hHbhT4mKSXsgkBBiJU7NkXFfzVQCMCgAARwgKI2RdduP+lHjUyeNaXJGVcFUFn8BeFJfe3wdIAEw HCAojZF1AU8aTtuP+lHjU0ZVwVT3TjxoM3WlYh0gATAcICAAKI2RdQFPGk7bj/pRKAAB41NwZc+R M3WlYg1OnlsdINmPHCB3bXNRCU4nWSiNkXUdIAz/dlGeWw1OxU4vZgFPGk4njWlyGpDHj8ePC3ot Tr6Wpl4nWQEw3Y/Eic6YaZYoAAHUa4OP2JqEduBRKk5zUS6VuXAM//lbd21zUV9ODFQ3aHdRCWcR YxhiDP+wcwlnhHbVbItfxIkDg6FsCWf5WzN1pWINTp5bhHaaW0lOATCEZygAARBiATAnYCiNATCB ifZOSXtaUPpRxlFueIR2THWaWwz/2Y9fTvxb9IGGTihXnlv1jc1kXE8tTvlbDFQATipO7pWYmAz/ DU4MVIR2O05TTwEwKAABDU4MVIR2c1E6UwEwDFQATndtc1ENTgxUhHZMgP2A6JDolRp184EMVABO Z2LVbAWADU4MVIR29mUfZxpPCWcNTgxUhHYGdOOJjFQEWQZ0034DAAGcZwIwIAApAAEgACAAIAA6 Ti5eqVLbj/pR41MBTxpO44mzUbd+QX4NWUJnhHYzdaViDU6eW9mPKk7kTrpONFm8dYR2vpaYmBv/ DFT2ZQz/y07NfoxUB2P8WwFPKQABGk6CWVVPKVIodUZVwVRSX3t8gGLnXduPTIgIVNVsf5AOen+Q wYueWyh1uWXVbBv/IAB5cj5OnlJkayFr+Veti+1zDP8akMePsouIY4Bi510BMAwAAUhoi0/jiZBn ATDjiVR7kXW+lvBW0WACMAQAAf6LC3onWbJ+AwABLHsATilZFgABLHsATuiQBlIa/4JZVU9/kE1R HCB3bXNRCU4nWSiNkXUdIDN1pWINTp5bH/8BAAAgFgABKI2RdQBOGv8ojZF124/6UeNTJ41pckZV wVQWfwF4Ul97fAz/DmBITp5SH/8cAAExAAEwMpanY1Jfe3wojZF1AjABTxpOxV97mKhSAWCMY+Fj hHZGVcFUUl97fLBlP2VWe4xUgGLnXRwAATIAATCCWVVP618fkJpbTU8BTxpO6oGrjoR2RlXBVFJf e3zOmGmW5U7KU9uPTIjOmGmWS22Xex//IQABMwABMNCPKHVXAEMATwBSX3t8xImaWwEw1k79VlJf e3yzUZpbDP8QYp9S7k9jay1O/VZ3bXNRUl97fKSLmltIaItPFAABNAABMIJZVU+UXvlbRlXBVFJf e3xcTxpOFV/RU4R21WyLX86YaZYf/xYAASiNkXWMThr/KI2RdQFPGk7bj/pR41NGVcFU9048aDN1 pWIM/w5gSE6eUh//HQABMQABMBqQc1HHjwt6LU7XUzBSd21zUaFb904ojZF1DP/FX3uYSFFMiPNg MFKEdlZ7ZXXKU5ReKHUf/yEAATIAATCCWVVPCFQGdMSJf5CbTwCXzFO5ZUtO9JWEdnNRVIBzUft8 ATB5coprc1H7fPlbd21zUaFb906EdnFfzVQf/xoAATMAATCCWVVPxlFueAR1K1IcIHlyuItDZ39P KHU5jR0gL2YmVJReoYtlUYxbDnr3TjxoH/8RAAE0AAEwd21zUSiNkXVwTrllT1OpUjmNKHUM/4JZ VU+eUh//KQABNQABMKBS5V04jRNmJ41pcgj/EGLBVAEwmWX2TgEwi2sha8FUATC5j9KJmWVJewn/ hVEAlXdtc1GhW/dOhHZ5crlwylOCgg56JgB/kGmWVntldSMAATYAATCgUuVdOI0TZieNaXII/xBi wVQBMJll9k4BMItrIWvBVAEwuY/SiZllSXsJ/w1Z+lHjU/dOPGjli4JZVU8zdaViH/8YAAEojZF1 CU4a/3dtc1EojZF1AU8aTtuP+lHjU3Blz5EzdaViDU6eWwz/DmBITp5SH/8UAAExAAEwd21zUYJZ VU+ki5pbAU8aTtuP+lHjU3Blz5EzdaViDU6eWx//IQABMgABMNuP+lHjU/pRsHPtd6JuxYgM/w5U 7X4JZ+BRzXlliFFluWUPXx//DmBITlpQTWIvZolbaFEBMNF5ZluEdh//IgABMwABMKBS5V04jRNm Io2hUg1Oc15hiIR2xV82cSdg5U7KUyaNoVIxWWGIDlSEdmWIUWVWe2V1jFR3UVNPnlu9Zbll1WwV AAEse4xO6JAGUhr/AGewZUZVwVRSX3t8gGLnXQ5OCFTVbH+QDnoBMH+QwYsPAAEATgEw24/6UeNT RlXBVFJfe3zNZFxPgGLnXeOJkGciAAHNkYGJ0GM6eRr/HCAEVEyIGk7BVA1UxIkDgydgM3WlYh0g BlwQYjpOd21zUQtOAE4qTtF2oXuEds2Rw1+MVM2RuXACMBcAASAAIAAgACAAIAAgACAAIAAgACAA IADudk1S6JAGUgFPGk5jayhX1Yu5cC1OAjARAAExAAEwMgAwADEAMQB0XkZVwVRSX3t8zZG5cD9l VnvjiZBnJgABMgABMLBzTIh3bXNRRlXBVFJfe3zLeEZVOmc2UoR2On93lidgDP+CWVVPbnieWwln SGWEdtCPKHV9WUZVwVRSX3t8y3hGVTpnNlIf/xcAATMAATDqVJtOL2YoV9uPTIhGVcFUUl97fMeP C3otTu9Tx5EodYR21WyLX51PbmMZAAE0AAEwJ2uOf9FTvo/9VrZbd21zUUZVwVRSX3t8iU6ui4R2 44mzURSQhF/KUx9QdJInYBsAATUAATAcTn+JuWWHZRZT7l0CX/lbd21zUduP+lHjU0ZVwVRSX3t8 hHZxX81UylOCWVVPxIl/kBsAATYAATBMiBpOB2jGURZipn6aWw5OCjBPUwOMNlKmXuhsypELMKdO H3UGUmdr5YuCWVVP44mzURgAATcAATB3bXNR+VvokAZSe4/lXadOwVSEdlJfe3wdYO+NylN2Uc1k XE+AYudd44mQZxcAATgAATDbj/pR41M6Z2hW9pbokPZOhHZSX3t8HWDvjcpTdlHNZFxPgGLnXeOJ kGccAAE5AAEwd21zUflbxH4IVDpnaFaMVBpZn1L9gDpnxH6EdlJfe3wdYO+NylOwc0yIhHbNZFxP uWXVbB8AATEAMAABMAFPGk74dnNRuk5YVIJZVU8HUp5bCWdIZYR20I8odUZVwVRSX3t8v08pUhqQ c1EBMIKCpn4QYixnEQABjE4BMNuP+lHjU0ZVwVRSX3t8gGLnXQ5OCFTVbH+QDnogABMAATEAATCC WVVPM3X3ixhP4GCEdoJmmlsOeodzjFRGVcFUFn8BeCAAEwABMgABMNuP+lHjUwFPGk6CWVVPlF75 W3dtc1GEdjBP904ojZF1IAAVAAEzAAEwYE8aT6tO11N3bXNR24/6UeNTRlXBVISYUl97fIR2xIma WxdUIAAXAAE0AAEwDmA3aClSKHV3bXNR+VtGVcFUUl97fIR2TIg/ZcGImlsIVNVsf5AOeiAAHAAB NQABMA5gN2gpUih1HCBGVcFUpWKMmrZyAWAdIA5OHCBGVcFUUl97fIBi510dIAhU1Wx/kA56IAAc AAE2AAEwDmA3aClSKHUcIEZVwVSEdhNOKHUnYB0gDk4cIEZVwVSEdhqQKHUnYB0gCFTVbH+QDnog ABgAATcAATAOYDdoKVIodRwgE04odfaW9k4dIA5OHCAakCh19pb2Th0gCFTVbH+QDnogAB8AATgA ATAOYDdoKVIodRwgGE/gYJ9Tp04wVwdoxlEdIA5OHCBelxhP4GCfU6dOMFcHaMZRHSAIVNVsf5AO eiAAEQABCU4BMNuP+lHjU0ZVwVRSX3t8gGLnXQ5OCFTVbH+QwYsgABAAATEAATD5WxZZOI0TZqF7 NlKEdu52hHYBMEtitWsCMCAAGAABMgABMLiL71PBiw5OuIvvU8GL9k7KU3dtc1HRdqF7wYv2Tgln wE5ITg1ODFQXVCAAEgABMwABMHdtc1EvZg5gN2hMdZpbHCA6ZzV1p07BVB0ghHYCMCAADQABNAAB MLiL71PBi/ZOhHbVbItfD2FJTgIwIAAUAAE1AAEwDmA3aClSKHUcIEZVwVQQYgZSHSDEiX+QOI0T ZqF7NlICMCAAEgABNgABMA5gN2gpUih1HCClYoyatnIBYB0gCFTVbH+QwYsCMCAAEgABNwABMA5g N2gpUih1HCCgUuVd8W2mXh0gCFTVbH+QwYsCMCAAGAABOAABMA5gN2gpUih1d21zUUyIP2XBiJpb xIl/kBwg4GXBizBSJ40dIM6YaZYCMCAAGQABOQABMA5gN2gpUih1M3XJiwEwDVmuiwEwyYu8i1Fl Tm0cIOBlwYswUieNHSBMiDpOAjADAAEse4xOKVkeAAF3bXNReXKKa9F2oXs6U99XhHYBTxpO0I9c T55bGGLKU4JZVU8JZ0hlKVIodXdtc1F5copr0Xahez9lVnsMAAEATgEwd21zUXlymlvRdqF7OlPf V/CPxIsNAAExAAEwd21zUXlyimvRdqF7OlPfV4R2LGcojRQAATIAATB3bXNReXKKa9F2oXs6U99X hHYwVzpT7l0CX4xUzWRcT55b9Y0YAAEzAAEwcV/NVHdtc1F5copr0XahezpT31fQj0yIhHZ2UdZO 6JDolT9lVnuMVNVsxIkPAAE0AAEwd21zUXlyimvRdqF7OlPfV4R20VNVXLllEVQYAAE1AAEwAU8a ToJZVU/Qjyh1fVl3bXNReXKKa9F2oXs6U99XhHb4dnNRGE/gYD9lVnsFAAGMTgEw3U8OejpTCwAB MQABMN1PDno6U4R2J2AojYxUn1L9gBQAATIAATAJZ3NR3U8OejpThHZ3bXNRP2VWe4xU+HaUXoR2 GE/gYKpjvWUWAAEzAAEwCWdzUd1PDno6U4R2dlHWTuiQ6JU/ZVZ7jFT4dpRehHYYT+BgqmO9ZRQA ATQAATABTxpOlF6CWVVPKVIodYxUlF75W91PDno6U4R2+HZzUT9lVnsRAAE1AAEw3U8OejpTP2VW e/lbAU8aTtCPJYSEdilSCl8GUpBnDwABNgABMN1PDno6U9uP+lE6UyeNaXKEdtF2oXueUtVsCQAB NwABMLt5g1gAkA56hHYsZyiNEAABOAABMN1PDno6UyeNaXKEdtuP+lHjU0FtC3oOTq9zgoIRAAE5 AAEw3U8OejpThHY/ZVZ7cI0RVIxUKmdlZ9FTVVy5ZRFUBwABCU4BMPpR41OgUuVdOlMNAAExAAEw +lHjU6BS5V06U4R2J2AojQ5On1L9gBYAATIAATAJZ3NR+lHjU6BS5V06U4R2d21zUT9lVnuMVPh2 lF6EdhhP4GCqY71lGAABMwABMAlnc1H6UeNToFLlXTpThHZ2UdZO6JDolT9lVnuMVPh2lF6EdhhP 4GCqY71lFgABNAABMAFPGk6UXoJZVU8pUih1jFSUXvlb+lHjU6BS5V06U4R2+HZzUT9lVnsTAAE1 AAEw+lHjU6BS5V06Uz9lVnv5WwFPGk7QjyWEhHYpUgpfBlKQZwwAATYAATD6UeNToFLlXTpTJ41p coR20XahexIAATcAATD6UeNToFLlXTpTJ41pcoR224/6UeNTQW0Leg5Or3OCghEAATgAATD6UeNT oFLlXTpThHY/ZVZ7cI0RVIxU0VNVXIuNv1IQAAE5AAEw3U8OejpTDk76UeNToFLlXTpThHYYT6NS 1GuDjwgAAdtWATDdTw56aXJBbe1WOlMMAAExAAEwaXJBbe1WOlOEdidgKI0OTp9S/YAZAAEyAAEw aXJBbe1WOlOFUQFPGk6EdnlyimuhewZ0IWoPXw5Od21zUQBnsGXtVjpTxIkDgxUAATMAATAJZ3NR aXJBbe1WOlOEdndtc1E/ZVZ7jFT4dpRehHYYT+BgqmO9ZRQAATQAATAJZ3NRaXJBbe1WOlOEdv1W Dno/ZVZ7jFQWWaF7P2VWexhPv1IWAAE1AAEwaXJBbe1WOlOEdnZR1k74dnNR6JDolT9lVnuMVDBX uWU/ZVZ7GE+/UhUAATYAATABTxpOlF6CWVVPKVIodYxUlF75W2lyQW3tVjpThHb4dnNRP2VWexIA ATcAATBpckFt7VY6Uz9lVnv5WwFPGk7QjyWEhHYpUgpfBlKQZxEAATgAATBpckFt7VY6UyeNaXLR dqF7Dk7tVjpTAU8aTqF7BnQRAAE5AAEwaXJBbe1WOlMnjWlyhHbbj/pR41NBbQt6Dk6vc4KCEQAB MQAwAAEwaXJBbe1WOlOEdj9lVntwjRFUjFTRU1Vci42/UhYAATEAMQABMDpTL25UgKhSjFQ6Uy9u VICoUvlbAU8aTtCPJYTNZFxPhHZxX81UDAABMQAyAAEwa1EvblSAqFIOTuiNOlNcTxpOGgABMQAz AAEwaXJBbe1WOlMOTt1PDno6U4xU+lHjU6BS5V06U9CPJYQaTqFSjFQpUgpf1GuDjxoAATEANAAB MGlyQW3tVjpTDk7dTw56OlOMVPpR41OgUuVdOlOEduiNOlNcTxpOzWRcT0FtC3oOAAExADUAATBp ckFt7VY6Uw5Ou3m4XBpOoVLNZFxPDgABMQA2AAEwaXJBbe1WOlMOTv1WRZZ/kA56zWRcTwwAAZRO ATDdTw56aXJBbS1Ow19BAAEwQgCLVw4AATEAATDdTw56aXJBbS1Ow1+EdidgKI0OTp9S/YAXAAEy AAEwCWdzUd1PDnppckFtLU7DX4R2d21zUT9lVnuMVPh2lF6EdhhP4GCqY71lGQABMwABMAlnc1Hd Tw56aXJBbS1Ow1+EdnZR1k7okOiVP2VWe4xU+HaUXoR2GE/gYKpjvWUXAAE0AAEwAU8aTpRegllV TylSKHWMVJRe+VvdTw56aXJBbS1Ow1+Edvh2c1E/ZVZ7FAABNQABMN1PDnppckFtLU7DXz9lVnv5 WwFPGk7QjyWEhHYpUgpfBlKQZw0AATYAATDdTw56aXJBbS1Ow18njWlyhHbRdqF7EwABNwABMN1P DnppckFtLU7DXyeNaXKEdtuP+lHjU0FtC3oOTq9zgoISAAE4AAEw3U8OemlyQW0tTsNfhHY/ZVZ7 cI0RVIxU0VNVXIuNv1IXAAE5AAEw3U8OemlyQW0tTsNfDk7dTw56OlOMVPpR41OgUuVdOlOEdhhP o1LUa4OPHQABMQAwAAEw3U8OemlyQW0tTsNfQQCLVw5OQgCLV4R2Al8MVAZSkGeMVAFPGk6EdpRe +VvNZFxPgGLnXRUAATEAMQABMN1PDnppckFtLU7DX4R26I06U1xPGk6MVJRe6GwPYYR27pWYmAgA AW1RATAJTidZ3U8Oei9uOlMIAAExAAEwCU4nWd1PDnovbjpTGQABMgABMN1PDnovbjpTKFc/ZVZ7 Dk4YT+BgqmO9ZQpODk7dTw56aXJBbe1WOlOEdtRrg48OAAEzAAEw3U8Oei9uOlOEdhpOoVKUXoJZ VU/NZFxPEwABNAABMAFPGk6CWVVPCWdIZSlSKHXdTw56L246U4R2BFR5mD9lVnsKAAEDTgEwoFLl XTiNE2Z3bXNR0XahexAAATEAATCgUuVdOI0TZndtc1HRdqF7hHYnYCiNjFSfUv2AFgABMgABMKBS 5V04jRNmd21zUdF2oXuEdvh2lF4YT+BgP2VWe4xUP2VWe3CNEVQPAAEzAAEwoFLlXTiNE2aEdg56 NmUYT+BgP2VWewZSkGcSAAE0AAEw24+ZZaBS5V0OTmVnmWWgUuVdhHYpUg561GuDjwZSkGcIAAE1 AAEwoFLlXTiNE2Zsj4tXCgABNgABMKBS5V04jRNmQW0LegZSkGcOAAE3AAEwoFLlXTiNE2aEdlVT F4DEiRlSjFShWzhoFQABOAABMKBS5V04jRNmCU4QXnNeYYgOTndtc1GgUuVdOI0TZhBeoVKhewZ0 DAABOQABMLt5uFzNZFxPLU6EdqBS5V04jRNmCwABa1EBMPFtoFLlXdN+bI93bXNR0XahewoAATEA ATDxbaBS5V3TfmyPhHYnYCiNGQABMgABMHdtc1H5W/FtoFLlXdN+bI+EdsSJA4OhewZ0jFQNTgxU c1E6U6F7BnSEdu5dAl8eAAEzAAEw8W2gUuVd035sj4R2Dno2ZT9lVnsKToR2MFe5ZSdg7l0CX4xU 4FZkawyA/Fv0gYR2035sj86YaZYNAAE0AAEw8W2gUuVd035sj4R2QW0Leg5Or3OCggwAATUAATDx baBS5V3TfmyPDk4IVAZ0f5AOegcAATYAATCZmS9uAE7lZThuDgABNwABMPFtoFLlXdN+bI8OTmly QW3tVjpTzWRcTw0AATgAATC7ebhczWRcTy1OhHbxbaBS5V3TfmyPDgABXU4BMHdtc1F5copr0Xah ezpT31c/ZVZ7dGUIVA4AATEAATB3bXNReXKKa9F2oXs6U99XP2VWe3RlCFQNAAEyAAEw6I06U1xP Gk50ZQhUDk7ojS9uVICoUhAAATMAATBeXDBXM3WlYgz/41O4XIyaPmWEdtWLuXDQj0yIEQABNAAB MAFPGk6UXoJZVU+UXvlbeXKKa9F2oXs6U99XdGUIVBMAAUFTATDdTw56aXJBbS1OhHa7ebhczWRc T4xU/VZFln+QDnrNZFxPGwABMQABMAFPGk6UXoJZVU8GXN1PDnppckFt0I8lhA5O/VZFln+QDnoB MLt5uFzNZFxP+HbTfghUDQABMgABMLt5uFzRkY2HGk6hUoxUDno2ZRpOoVILAAEzAAEwu3m4XM1k XE8OTkSNp05sj/t5CwABNAABMLt5uFw4jRNmhHbNZFxPgGLnXRcAATUAATC7ebhcOI0TZs1kXE/H jwt6LU6EdpF1vpYEWQZ0jFSUXn+QTVGEdu6VmJgeAAE2AAEwu3m4XM1kXE8OTt1PDnppckFtCP95 citSL2ZpckFt7VY6U4xU3U8Oei9uOlMJ/4R2CWdIZdN+CFQVAAE3AAEwc1FUgKROE2YGUpBnDk7E iX+QAU8aTtCPJYQtToR2c1FUgKROE2YNAAE4AAEwd20WWc9+JYQOTv1WRZZ/kA56eXsSUg0AATkA ATCCWVVPlF75W/1WRZbNU3+QDnqqY71lDAABMQAwAAEw/VZFln+QDnpWe2V1jFSAYuddEAABMQAx AAEwSGiLTwZSkGf9VkWWf5AOeoR2DU4MVEtitWsRAAExADIAATD9VkWWf5AOeg5O3U8OemlyQW2E dtN+CFTQjyh1JAABQVMATgEwSGiLTwZSkGcNTgxUJ2AojYR2AU8aToJZVU8JZ0hlKVIodXdtc1F5 copr0XahezpT31eEdj9lVnuMVBhP4GCqY71lHgABMQABMNuP+lHjUziNE2ZsUfhTgllVTylSKHV3 bXNReXKKa9F2oXs6U99XP2VWe4xU3U8OemlyQW0/ZVZ7LAABMgABMP1WRZZpckFtAU8aTnlyK1Iv Zix7CU65ZS8ALHvbVrllm0+UXv6UAU8aToJZVU8pUih1d21zUXlyimvRdqF7OlPfVz9lVnuMVN1P DnppckFtP2VWex8AATMAATAATiyCOI0TZh91p04BTxpOgllVTylSKHV3bXNReXKKa9F2oXs6U99X P2VWe4xU3U8OemlyQW0/ZVZ7HQABNAABMKBS5V04jRNmAU8aToJZVU8pUih1d21zUXlyimvRdqF7 OlPfVz9lVnuMVN1PDnppckFtP2VWexsAATUAATAJTkSNAU8aToJZVU8pUih1d21zUXlyimvRdqF7 OlPfVz9lVnuMVN1PDnppckFtP2VWexEAATYAATBsj4JTGk6hUi1OhHbdTw56aXJBbYR2CFQGdNCP KHUWAAE3AAEwAU8aToJZVU8GXN1PDnppckFtDk53bRZZPABrCAEaTqFS249MiAlnSGXTfghUBAAB sosIXstOzX4rAAFIliAAVXggAAGACF4M/8xTVXjrWCgAjn/9VmyazJFwUSdZZltNAEIAQQABMFdT AF8nWWZbz35ObWZbVXjrWCkADP8BdxZZz344jYVTOI0TZn6Y7pUM/ycAAZmZL279VkWWz35ObaF7 BnRmW2KWolunXllliGMM/5mZL244jRNmw0/bjxpPGk9YVAz/CjCkfC9uLU4PXAFPGk44jRNmuotb VwswO06yiycAAbpOS04ATgz//mb7ThZOTHUV/xD/EP86X4R2LU79Vq58uWzfmMFU24/6UeNTxpbi VmxR+FPbj/pR41NtUeiQ6JB/lQz/LU6ufMaW4lZ7migAAZmZL24BMKBS/2InWUZVoVI7Tp5SDP/g YBRcbmYoAI5/KQAKTndtCWdQlmxR+FNXUzpTz34GdIxU0I8lhDtg0XYBMPFtM1fQZ1eEDVRGVaFS KAABqFTiiwlnUJZsUfhTO2DPfgZ0ATCZmS9uSQBCAFQA/VZFlkZVoVKoVOKLCWdQlmxR+FP9VkWW OI0TZpaZLV6oVOKLCF4M/xxOrE44TgBO/H4oAAEIVEZVPnl/iRdTOlMCXjpXO2DRdgEw4HN3bQFa m3Pzd7lsvosHWduP+lHjU2xR+FM7YM9+BnQM/xpZdF5lZ0hRDlQoVwpOd20BMBdTrE4BMCcAAXFc HE4BMFltX2wBMF9sz4IBMNtW3V1JezBXPk5MiIZOFv8Q/xD/Glk6V/1WRZY4jRNmE06YmLKLp14M /zpO0Y9+drZbAU8aTlpQx48TTicAAeiVhVGtixZifpjulQ1noVIM/9dTMFIBTxpOjFRmW1hUhHZ/ XttsfVnEiwz/SJZIUR91d1EJZ4Fn8W2aU4R2BnS6i+V3xouMVJ5b9Y3PficAAYyaDP8vZnhRi1eE dp5bGGI+bbKLCF4M/xL/EP8aWXRehHYWWTiNGk6hUqF7BnTPfoyaDP95citSKFcEWQZ0Flk4jRpO oVKRdb6W7pWYmCcAAbllYpcJZ+xyMFKEdsGJ44mMVIBi510M/3dRCWc0Wp9xhHYaTqFSgGL9gIxU gWdzT4R27YsAimiIvo/9gJtSDP/5W/1WRZY4jRNmL2ftiycAAQlngWe+fG54hHYGdOOJDP8MVPZl SJZIUR912I8GXCBPiGOIXxpZG1IgkCdgATC5jxh/J2CEds1kXE9LYtVsDk7DX5dfDFQnWbZbpE5B bRQAAYxUBlKrTgz/z2sha/2Q5E5mW1hUD2G5cipnPVwM/wWDXlh/mABfAjA1AAH3iwZc5U4LTqVi DVRoiIVRuVtrWJlR0VNFAC0AbQBhAGkAbADzgWMAaABpAG4AYQBzAHkAcAB4AEAAZgBvAHgAbQBh AGkAbAAuAGMAbwBtAAz/EWLsTgZcLHsATvZl9JUOTqhgVID7fAH/EgABIAAgACAAIAAgACAAIAAg ACAApWIgACAADVQAMN5WIAAgAGdiGgABwlOgUv6LmJga/wowHCB3bXNRCU4nWSiNkXUdIOOJkGcO Tvh2c1GRdb6WlF75W1Z7ZXULMC8AAfZl9JUa/18AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBf AF8AXwBfAF8AXwBfAF8AXwBfAAAwADAwV7lwGv9fAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwAAMAAw ADBHAAHCUxpPVVNNTw1U8Hka/18AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwAgAEUAbQBhAGkAbAAa/18AXwBfAF8AXwBf AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8ARQABVID7fLpOGv9fAF8AXwBfAF8AXwBf AF8AXwBfAF8AXwBfAF8AXwAgADV13Ysa/18AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A XwBfAF8AXwBfACAAIE8fdxr/XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBf AF8AAgABIAAAMEkAAcJToFJmW1hUGv9fAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBf AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8ABgAAICAgICAgEAAB 2E4+a7llD18a/6ElsHPRkQAwoSUvZWh5ADChJWyPEF4dAAG6TnBlGv9fAF8AXwBfAF8AXwC6TiAA IAAgAMJTGk85jSh1Gv9xUaGLGv9fAF8AXwBfAF8AXwBDUSAAAgABB1nobCAAATEALgA2ZTBSNY34 U6ViDVThT29gDlQM/xFi7E4GXCx7AE72ZfSVjFQ1jfhTwlMaT1SA+3y6TtuPTIhueKSLG/8mAAEy AC4AKFcAX/6LTVIATmhUDP8RYuxOCWcTTrpO2X41jfhT0VMBkMJToFL5V62LhHZueKSL/VEM/wpO YpcJZ/lXrYulYjBSB2MVXwz/EAABIAAgAOVOylPmi8Z+hHYKTv6LMFdAV4xU742/fv5WG/8zAAH2 ZfSVMFe5cBr/MgAwADEAMQB0XjEAMgAIZzEANQAtADEANgDlZSgACk53bSkAIAAgACAAIAAgACAA IAAgACAAIAAyADAAMQAxAHReMQAyAAhnMgA3AC0AMgA4AOVlKADxbTNXKQASAAEaT6FSxH7Hfhr/ +osdYO9RAU8aTqF7BnSoVOKLCWdQlmxR+FP/ANoACAA7BwAADAAAAMkJAACaAgAALQwAAP4EAABC DQAAEwYAAAgPAADZBwAA7BAAAL0JAACMEgAAXQsAACwUAAD9DAAAwhUAAJMOAAAIFwAA2Q8AADwY AAANEQAAYBkAADESAAB8GgAATRMAAJIbAABjFAAA3BwAAK0VAAAMHgAA3RYAAGwfAAA9GAAAkCAA AGEZAACgIQAAcRoAAKgiAAB5GwAAsCMAAIEcAADyJAAAwx0AAJgmAABpHwAAbSgAABsBAAD7KgAA qQMAAHctAAAlBgAAMS8AAN8HAABjCBUAYwgAAAAAAAAAAAAAFQAAAAQAAAACCgAAAAkIEAAABhAA iCDNB8nAAAAGAwAACwIwAAAAAAACAAAA9AAAAAYzAAC8NgAA5DoAADg/AAB4QwAAlkcAALJLAACk TwAAnFEAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAAACsA AgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAB0BgQACAMEEFAAAABUAAACDAAIAAACEAAIAAABN AG4BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQQABNwAkAADLwAAAQAJAAAAAABkAAEAAQDIAAEAAQDIAAEAAABMAGUAdAB0 AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd2lk bRAAAAABAAAAAAAAAAAAAAD+AAAAAQAAAAAAAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoQAiAAkAZAABAAEAAQACAMgAyAAAAAAAAADgPwAA AAAAAOA/AQBVAAIACAAAAg4AAgAAAPQAAAABAAoAAAAIAhAAAgABAAkAHQEAAAAAAAEPAAgCEAAF AAEACQAdAQAAAAAAAQ8ACAIQAAYAAQAJAB0BAAAAAAABDwAIAhAABwABAAkAHQEAAAAAAAEPAAgC EAAIAAEACQAdAQAAAAAAAQ8ACAIQAAkAAQAJAB0BAAAAAAABDwAIAhAACgABAAkAHQEAAAAAAAEP AAgCEAALAAEACQAdAQAAAAAAAQ8ACAIQAAwAAQAJAB0BAAAAAAABDwAIAhAADgABAAkAHQEAAAAA AAEPAAgCEAAPAAEACQAdAQAAAAAAAQ8ACAIQABAAAQACAB0BAAAAAAABDwAIAhAAEQABAAIAHQEA AAAAAAEPAAgCEAATAAEAAgAdAQAAAAAAAQ8ACAIQABQAAQACAB0BAAAAAAABDwAIAhAAFQABAAIA HQEAAAAAAAEPAAgCEAAWAAEAAgAdAQAAAAAAAQ8ACAIQABcAAQACAB0BAAAAAAABDwAIAhAAGAAB AAIAHQEAAAAAAAEPAAgCEAAaAAEAAgAdAQAAAAAAAQ8ACAIQABsAAQACAB0BAAAAAAABDwAIAhAA HAABAAIAHQEAAAAAAAEPAAgCEAAdAAEAAgAdAQAAAAAAAQ8ACAIQAB4AAQACAB0BAAAAAAABDwAI AhAAIAABAAYAHQEAAAAAAAEPAAgCEAAhAAEABgAdAQAAAAAAAQ8A/QAKAAIAAQAPAAAAAAD9AAoA BQABABYA0AAAAL4AFAAFAAIAFgAWABYAFgAWABYAFgAIAP0ACgAGAAEADwABAAAA/QAKAAcAAQAP AAIAAAD9AAoACAABAA8A0QAAAP0ACgAJAAEADwADAAAA/QAKAAoAAQAPAAQAAAD9AAoACwABAA8A BQAAAP0ACgAMAAEADwAGAAAA/QAKAA4AAQAPAAcAAAD9AAoADwABAA8ACAAAAP0ACgAQAAEADwAJ AAAA/QAKABEAAQAPAAoAAAD9AAoAEwABAA8ACwAAAP0ACgAUAAEADwAMAAAA/QAKABUAAQAPAA0A AAD9AAoAFgABAA8ADgAAAP0ACgAXAAEADwAPAAAA/QAKABgAAQAPABAAAAD9AAoAGgABAA8AEQAA AP0ACgAbAAEADwASAAAA/QAKABwAAQAPABMAAAD9AAoAHQABAA8ABQAAAP0ACgAeAAEADwAUAAAA /QAKACAAAQAXABUAAAD9AAoAIQABABUAFgAAAL4ADgAhAAIAFQAVABUAFQAFANcAOACeAwAA9AEO ACYADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAAgCEAAiAAEA BgAdAQAAAAAAAQ8ACAIQACMAAQAGAB0BAAAAAAABDwAIAhAAJAABAAYAHQEAAAAAAAEPAAgCEAAl AAEABgAdAQAAAAAAAQ8ACAIQACYAAQAGAB0BAAAAAAABDwAIAhAAJwABAAYAHQEAAAAAAAEPAAgC EAApAAEABgAdAQAAAAAAAQ8ACAIQACoAAQAGAB0BAAAAAAABDwAIAhAAKwABAAYAHQEAAAAAAAEP AAgCEAAsAAEABgAdAQAAAAAAAQ8ACAIQAC0AAQAGAB0BAAAAAAABDwAIAhAALgABAAYAHQEAAAAA AAEPAAgCEAAvAAEABgAdAQAAAAAAAQ8ACAIQADEAAQAGAB0BAAAAAAABDwAIAhAAMgABAAYAHQEA AAAAAAEPAAgCEAAzAAEABgAdAQAAAAAAAQ8ACAIQADQAAQAGAB0BAAAAAAABDwAIAhAANgABAAYA HQEAAAAAAAEPAAgCEAA3AAEABgAdAQAAAAAAAQ8ACAIQADgAAQAGAB0BAAAAAAABDwAIAhAAOQAB AAYAHQEAAAAAAAEPAAgCEAA6AAEABgAdAQAAAAAAAQ8ACAIQADsAAQAGAB0BAAAAAAABDwAIAhAA PAABAAYAHQEAAAAAAAEPAAgCEAA9AAEABgAdAQAAAAAAAQ8ACAIQAD4AAQAGAB0BAAAAAAABDwAI AhAAPwABAAYAHQEAAAAAAAEPAAgCEABAAAEAAgAdAQAAAAAAAQ8ACAIQAEEAAQACAB0BAAAAAAAB DwD9AAoAIgABAA8AFwAAAP0ACgAjAAEADwAYAAAA/QAKACQAAQAPABkAAAD9AAoAJQABAA8AGgAA AP0ACgAmAAEADwAbAAAA/QAKACcAAQAPABwAAAD9AAoAKQABAA8AHQAAAP0ACgAqAAEADwAeAAAA /QAKACsAAQAPAB8AAAD9AAoALAABAA8AIAAAAP0ACgAtAAEADwAhAAAA/QAKAC4AAQAPACIAAAD9 AAoALwABAA8AIwAAAP0ACgAxAAEADwAkAAAA/QAKADIAAQAPACUAAAD9AAoAMwABAA8AJgAAAP0A CgA0AAEADwAnAAAA/QAKADYAAQAVACgAAAC+AA4ANgACABUAFQAVABUABQD9AAoANwABAA8AKQAA AP0ACgA4AAEADwAqAAAA/QAKADkAAQAPACsAAAD9AAoAOgABAA8ALAAAAP0ACgA7AAEADwAtAAAA /QAKADwAAQAPAC4AAAD9AAoAPQABAA8ALwAAAP0ACgA+AAEADwAwAAAA/QAKAD8AAQAPADEAAAD9 AAoAQAABAA8AMgAAAP0ACgBBAAEADwAzAAAA1wA+AOwDAAAwAg4ADgAOAA4ADgAOAA4ADgAOAA4A DgAOAA4ADgAOAA4ADgAgAA4ADgAOAA4ADgAOAA4ADgAOAA4ACAIQAEIAAQACAB0BAAAAAAABDwAI AhAAQwABAAIAHQEAAAAAAAEPAAgCEABEAAEAAgAdAQAAAAAAAQ8ACAIQAEUAAQACAB0BAAAAAAAB DwAIAhAARgABAAIAHQEAAAAAAAEPAAgCEABHAAEAAgAdAQAAAAAAAQ8ACAIQAEgAAQACAB0BAAAA AAABDwAIAhAASQABAAIAHQEAAAAAAAEPAAgCEABKAAEAAgAdAQAAAAAAAQ8ACAIQAEsAAQACAB0B AAAAAAABDwAIAhAATAABAAIAHQEAAAAAAAEPAAgCEABNAAEAAgAdAQAAAAAAAQ8ACAIQAE4AAQAC AB0BAAAAAAABDwAIAhAATwABAAIAHQEAAAAAAAEPAAgCEABQAAEACAAdAQAAAAAAAQ8ACAIQAFEA AQAIAB0BAAAAAAABDwAIAhAAUgABAAgAHQEAAAAAAAEPAAgCEABTAAEACAAdAQAAAAAAAQ8ACAIQ AFQAAQAIAB0BAAAAAAABDwAIAhAAVQABAAgAHQEAAAAAAAEPAAgCEABWAAEACAAdAQAAAAAAAQ8A CAIQAFgAAQAIAB0BAAAAAAABDwAIAhAAWQABAAgAHQEAAAAAAAEPAAgCEABaAAEACAAdAQAAAAAA AQ8ACAIQAFsAAQAIAB0BAAAAAAABDwAIAhAAXAABAAgAHQEAAAAAAAEPAAgCEABdAAEACAAdAQAA AAAAAQ8ACAIQAF4AAQAIAB0BAAAAAAABDwAIAhAAXwABAAgAHQEAAAAAAAEPAAgCEABhAAEAAgAd AQAAAAAAAQ8A/QAKAEIAAQAPADQAAAD9AAoAQwABAA8ANQAAAP0ACgBEAAEADwA2AAAA/QAKAEUA AQAPADcAAAD9AAoARgABAA8AOAAAAP0ACgBHAAEADwA5AAAA/QAKAEgAAQAPADoAAAD9AAoASQAB AA8AOwAAAP0ACgBKAAEADwA8AAAA/QAKAEsAAQAPAD0AAAD9AAoATAABAA8APgAAAP0ACgBNAAEA DwA/AAAA/QAKAE4AAQAPAEAAAAD9AAoATwABAA8AQQAAAP0ACgBQAAEADwBCAAAA/QAKAFEAAQAP AEMAAAD9AAoAUgABAA8ARAAAAP0ACgBTAAEADwBFAAAA/QAKAFQAAQAPAEYAAAD9AAoAVQABAA8A RwAAAP0ACgBWAAEADwBIAAAA/QAKAFgAAQAXAEkAAAD9AAoAWQABABUASgAAAL4AEgBZAAIAFQAV ABUAFQAVABUABwD9AAoAWgABAA8ASwAAAP0ACgBbAAEADwBMAAAA/QAKAFwAAQAPAE0AAAD9AAoA XQABAA8ATgAAAP0ACgBeAAEADwBPAAAA/QAKAF8AAQAPAFAAAAD9AAoAYQABAA8AUQAAANcAQAAS BAAARAIOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOACQADgAOAA4A DgAOAA4ACAIQAGIAAQACAB0BAAAAAAABDwAIAhAAYwABAAIAHQEAAAAAAAEPAAgCEABkAAEAAgAd AQAAAAAAAQ8ACAIQAGUAAQACAB0BAAAAAAABDwAIAhAAZgABAAIAHQEAAAAAAAEPAAgCEABnAAEA AgAdAQAAAAAAAQ8ACAIQAGgAAQACAB0BAAAAAAABDwAIAhAAaQABAAIAHQEAAAAAAAEPAAgCEABq AAEAAgAdAQAAAAAAAQ8ACAIQAGwAAQACAB0BAAAAAAABDwAIAhAAbQABAAIAHQEAAAAAAAEPAAgC EABuAAEAAgAdAQAAAAAAAQ8ACAIQAG8AAQACAB0BAAAAAAABDwAIAhAAcAABAAIAHQEAAAAAAAEP AAgCEABxAAEAAgAdAQAAAAAAAQ8ACAIQAHIAAQACAB0BAAAAAAABDwAIAhAAcwABAAIAHQEAAAAA AAEPAAgCEAB0AAEAAgAdAQAAAAAAAQ8ACAIQAHUAAQACAB0BAAAAAAABDwAIAhAAdwABAAIAHQEA AAAAAAEPAAgCEAB4AAEAAgAdAQAAAAAAAQ8ACAIQAHkAAQACAB0BAAAAAAABDwAIAhAAegABAAIA HQEAAAAAAAEPAAgCEAB7AAEAAgAdAQAAAAAAAQ8ACAIQAHwAAQACAB0BAAAAAAABDwAIAhAAfQAB AAIAHQEAAAAAAAEPAAgCEAB+AAEAAgAdAQAAAAAAAQ8ACAIQAH8AAQACAB0BAAAAAAABDwAIAhAA gAABAAIAHQEAAAAAAAEPAAgCEACBAAEAAgAdAQAAAAAAAQ8A/QAKAGIAAQAPAFIAAAD9AAoAYwAB AA8AUwAAAP0ACgBkAAEADwBUAAAA/QAKAGUAAQAPAFUAAAD9AAoAZgABAA8AVgAAAP0ACgBnAAEA DwBXAAAA/QAKAGgAAQAPAFgAAAD9AAoAaQABAA8AWQAAAP0ACgBqAAEADwBaAAAA/QAKAGwAAQAP AFsAAAD9AAoAbQABAA8AXAAAAP0ACgBuAAEADwBdAAAA/QAKAG8AAQAPAF4AAAD9AAoAcAABAA8A XwAAAP0ACgBxAAEADwBgAAAA/QAKAHIAAQAPAGEAAAD9AAoAcwABAA8AYgAAAP0ACgB0AAEADwBj AAAA/QAKAHUAAQAPAGQAAAD9AAoAdwABAA8AZQAAAP0ACgB4AAEADwBmAAAA/QAKAHkAAQAPAGcA AAD9AAoAegABAA8AaAAAAP0ACgB7AAEADwBpAAAA/QAKAHwAAQAPAGoAAAD9AAoAfQABAA8AawAA AP0ACgB+AAEADwBsAAAA/QAKAH8AAQAPAG0AAAD9AAoAgAABAA8AbgAAAP0ACgCBAAEADwBvAAAA 1wBAAPwDAABEAg4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAO AA4ADgAOAA4ADgAIAhAAggABAAIAHQEAAAAAAAEPAAgCEACDAAEAAgAdAQAAAAAAAQ8ACAIQAIQA AQACAB0BAAAAAAABDwAIAhAAhQABAAIAHQEAAAAAAAEPAAgCEACGAAEAAgAdAQAAAAAAAQ8ACAIQ AIcAAQACAB0BAAAAAAABDwAIAhAAiQABAAIAHQEAAAAAAAEPAAgCEACKAAEAAgAdAQAAAAAAAQ8A CAIQAIsAAQACAB0BAAAAAAABDwAIAhAAjAABAAIAHQEAAAAAAAEPAAgCEACNAAEAAgAdAQAAAAAA AQ8ACAIQAI4AAQACAB0BAAAAAAABDwAIAhAAjwABAAIAHQEAAAAAAAEPAAgCEACQAAEAAgAdAQAA AAAAAQ8ACAIQAJEAAQACAB0BAAAAAAABDwAIAhAAkgABAAIAHQEAAAAAAAEPAAgCEACTAAEAAgAd AQAAAAAAAQ8ACAIQAJQAAQACAB0BAAAAAAABDwAIAhAAlgABAAIAHQEAAAAAAAEPAAgCEACXAAEA AgAdAQAAAAAAAQ8ACAIQAJgAAQACAB0BAAAAAAABDwAIAhAAmQABAAIAHQEAAAAAAAEPAAgCEACa AAEAAgAdAQAAAAAAAQ8ACAIQAJwAAQACAB0BAAAAAAABDwAIAhAAnQABAAIAHQEAAAAAAAEPAAgC EACeAAEAAgAdAQAAAAAAAQ8ACAIQAJ8AAQACAB0BAAAAAAABDwAIAhAAoAABAAIAHQEAAAAAAAEP AAgCEAChAAEAAgAdAQAAAAAAAQ8A/QAKAIIAAQAPAHAAAAD9AAoAgwABAA8AcQAAAP0ACgCEAAEA DwByAAAA/QAKAIUAAQAPAHMAAAD9AAoAhgABAA8AdAAAAP0ACgCHAAEADwB1AAAA/QAKAIkAAQAP AHYAAAD9AAoAigABAA8AdwAAAP0ACgCLAAEADwB4AAAA/QAKAIwAAQAPAHkAAAD9AAoAjQABAA8A egAAAP0ACgCOAAEADwB7AAAA/QAKAI8AAQAPAHwAAAD9AAoAkAABAA8AfQAAAP0ACgCRAAEADwB+ AAAA/QAKAJIAAQAPAH8AAAD9AAoAkwABAA8AgAAAAP0ACgCUAAEADwCBAAAA/QAKAJYAAQAPAIIA AAD9AAoAlwABAA8AgwAAAP0ACgCYAAEADwCEAAAA/QAKAJkAAQAPAIUAAAD9AAoAmgABAA8AhgAA AP0ACgCcAAEADwCHAAAA/QAKAJ0AAQAPAIgAAAD9AAoAngABAA8AiQAAAP0ACgCfAAEADwCKAAAA /QAKAKAAAQAPAIsAAAD9AAoAoQABAA8AjAAAANcAPgDaAwAAMAIOAA4ADgAOAA4ADgAOAA4ADgAO AA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAAgCEACiAAEAAgAdAQAAAAAAAQ8A CAIQAKMAAQACAB0BAAAAAAABDwAIAhAApAABAAIAHQEAAAAAAAEPAAgCEAClAAEAAgAdAQAAAAAA AQ8ACAIQAKcAAQACAB0BAAAAAAABDwAIAhAAqAABAAIAHQEAAAAAAAEPAAgCEACpAAEAAgAdAQAA AAAAAQ8ACAIQAKoAAQACAB0BAAAAAAABDwAIAhAAqwABAAIAHQEAAAAAAAEPAAgCEACsAAEAAgAd AQAAAAAAAQ8ACAIQAK0AAQACAB0BAAAAAAABDwAIAhAArgABAAIAHQEAAAAAAAEPAAgCEACvAAEA AgAdAQAAAAAAAQ8ACAIQALEAAQACAB0BAAAAAAABDwAIAhAAsgABAAIAHQEAAAAAAAEPAAgCEACz AAEAAgAdAQAAAAAAAQ8ACAIQALQAAQACAB0BAAAAAAABDwAIAhAAtQABAAIAHQEAAAAAAAEPAAgC EAC3AAEAAgAdAQAAAAAAAQ8ACAIQALgAAQACAB0BAAAAAAABDwAIAhAAuQABAAIAHQEAAAAAAAEP AAgCEAC6AAEAAgAdAQAAAAAAAQ8ACAIQALsAAQACAB0BAAAAAAABDwAIAhAAvAABAAIAHQEAAAAA AAEPAAgCEAC9AAEAAgAdAQAAAAAAAQ8ACAIQAL4AAQACAB0BAAAAAAABDwAIAhAAvwABAAIAHQEA AAAAAAEPAAgCEADAAAEAAgAdAQAAAAAAAQ8ACAIQAMEAAQACAB0BAAAAAAABDwD9AAoAogABAA8A jQAAAP0ACgCjAAEADwCOAAAA/QAKAKQAAQAPAI8AAAD9AAoApQABAA8AkAAAAP0ACgCnAAEADwCR AAAA/QAKAKgAAQAPAJIAAAD9AAoAqQABAA8AkwAAAP0ACgCqAAEADwCUAAAA/QAKAKsAAQAPAJUA AAD9AAoArAABAA8AlgAAAP0ACgCtAAEADwCXAAAA/QAKAK4AAQAPAJgAAAD9AAoArwABAA8AmQAA AP0ACgCxAAEADwCaAAAA/QAKALIAAQAPAJsAAAD9AAoAswABAA8AnAAAAP0ACgC0AAEADwCdAAAA /QAKALUAAQAPAJ4AAAD9AAoAtwABAA8AnwAAAP0ACgC4AAEADwCgAAAA/QAKALkAAQAPAKEAAAD9 AAoAugABAA8AogAAAP0ACgC7AAEADwCjAAAA/QAKALwAAQAPAKQAAAD9AAoAvQABAA8ApQAAAP0A CgC+AAEADwCmAAAA/QAKAL8AAQAPAKcAAAD9AAoAwAABAA8AqAAAAP0ACgDBAAEADwCpAAAA1wA+ ANoDAAAwAg4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4A DgAOAA4ACAIQAMIAAQACAB0BAAAAAAABDwAIAhAAwwABAAIAHQEAAAAAAAEPAAgCEADFAAEAAgAd AQAAAAAAAQ8ACAIQAMYAAQACAB0BAAAAAAABDwAIAhAAxwABAAIAHQEAAAAAAAEPAAgCEADIAAEA AgAdAQAAAAAAAQ8ACAIQAMkAAQACAB0BAAAAAAABDwAIAhAAygABAAIAHQEAAAAAAAEPAAgCEADL AAEAAgAdAQAAAAAAAQ8ACAIQAMwAAQACAB0BAAAAAAABDwAIAhAAzQABAAIAHQEAAAAAAAEPAAgC EADPAAEAAgAdAQAAAAAAAQ8ACAIQANAAAQAKAB0BAAAAAAABDwAIAhAA0QABAAoAHQEAAAAAAAEP AAgCEADSAAEACgAdAQAAAAAAAQ8ACAIQANMAAQAKAB0BAAAAAAABDwAIAhAA1AABAAoAHQEAAAAA AAEPAAgCEADVAAEACgAdAQAAAAAAAQ8ACAIQANYAAQAKAB0BAAAAAAABDwAIAhAA1wABAAoAHQEA AAAAAAEPAAgCEADYAAEACgAdAQAAAAAAAQ8ACAIQANkAAQAKAB0BAAAAAAABDwAIAhAA2gABAAoA HQEAAAAAAAEPAAgCEADbAAEACgAdAQAAAAAAAQ8ACAIQANwAAQAKAB0BAAAAAAABDwAIAhAA3gAB AAoAHQEAAAAAAAEPAAgCEADgAAEAAgAdAQAAAAAAAQ8A/QAKAMIAAQAPAKoAAAD9AAoAwwABAA8A qwAAAP0ACgDFAAEADwCsAAAA/QAKAMYAAQAPAK0AAAD9AAoAxwABAA8ArgAAAP0ACgDIAAEADwCv AAAA/QAKAMkAAQAPALAAAAD9AAoAygABAA8AsQAAAP0ACgDLAAEADwCyAAAA/QAKAMwAAQAPALMA AAD9AAoAzQABAA8ABQAAAP0ACgDPAAEADwC0AAAA/QAKANAAAQAPALUAAAD9AAoA0QABAA8AtgAA AP0ACgDSAAEADwC3AAAA/QAKANMAAQAPALgAAAD9AAoA1AABAA8AuQAAAP0ACgDVAAEADwC6AAAA /QAKANYAAQAPALsAAAD9AAoA1wABAA8AvAAAAP0ACgDYAAEADwC9AAAA/QAKANkAAQAPAL4AAAD9 AAoA2gABAA8AvwAAAP0ACgDbAAEADwDAAAAA/QAKANwAAQAPAAUAAAD9AAoA3gABABUAwQAAAL4A FgDeAAIAFQAVABUAFQAVABUAFQAVAAkA/QAKAOAAAQAPAMIAAADXADoAsAMAAAgCDgAOAA4ADgAO AA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAoAAgCEADiAAEAAgAdAQAA AAAAAQ8ACAIQAOQAAQACAB0BAAAAAAABDwAIAhAA5gABAAIAHQEAAAAAAAEPAAgCEADoAAEAAgAd AQAAAAAAAQ8ACAIQAOkAAQACAB0BAAAAAAABDwAIAhAA6gABAAIAHQEAAAAAAAEPAAgCEADrAAEA AgAdAQAAAAAAAQ8ACAIQAOwAAQACAB0BAAAAAAABDwAIAhAA7gABAAIAHQEAAAAAAAEPAAgCEADw AAEAAgAdAQAAAAAAAQ8ACAIQAPEAAQACAB0BAAAAAAABDwAIAhAA8gABAAIAHQEAAAAAAAEPAAgC EADzAAEAAgAdAQAAAAAAAQ8A/QAKAOIAAQAPAMMAAAD9AAoA5AABAA8AxAAAAP0ACgDmAAEADwDF AAAA/QAKAOgAAQAPAMYAAAD9AAoA6QABAA8AxwAAAP0ACgDqAAEADwDIAAAA/QAKAOsAAQAPAMkA AAD9AAoA7AABAA8AygAAAP0ACgDuAAEADwDLAAAA/QAKAPAAAQAPAMwAAAD9AAoA8QABAA8AzQAA AP0ACgDyAAEADwDOAAAA/QAKAPMAAQAPAM8AAADXAB4AugEAAPAADgAOAA4ADgAOAA4ADgAOAA4A DgAOAA4APgISALQGAAAAAEAAAAAAAAAAAAAAAB0ADwAD3AAOAAAAAQDcANwADg7vAAYABQA3AAAA ugEJAAYAAFNoZWV0MQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez 2TAAAACYAAAABwAAAAEAAABAAAAABAAAAEgAAAAIAAAAVAAAABIAAABgAAAADAAAAHgAAAANAAAA hAAAABMAAACQAAAAAgAAAKgDAAAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAAEAAAAE1pY3Jv c29mdCBFeGNlbABAAAAAAJkcMrrruwFAAAAAAKcz2BSwzAEDAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAwAAA AAkAAAABAAAAUAAAAA8AAABYAAAAFwAAAGQAAAALAAAAbAAAABAAAAB0AAAAEwAAAHwAAAAWAAAA hAAAAA0AAACMAAAADAAAAJ8AAAACAAAAqAMAAB4AAAAEAAAAAAAAAAMAAAAPJwsACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAcAAABTaGVldDEADBAAAAIAAAAeAAAABwAA ALmk1/ex7QADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA/v///ysAAAAs AAAALQAAAC4AAAAvAAAAMAAAADEAAAD+////MwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAAP7/ ///9/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////UgBv AG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABYABQH//////////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAAAAAAAAAAD+ ////AAAAAAAAAABXAG8AcgBrAGIAbwBvAGsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAACUgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAAMAAAD/////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyAAAAABAAAAAAAAA= ------=_NextPart_000_0204_0154F487.18F7FEF0-- From w3c-dist-auth-request@listhub.w3.org Sun Dec 18 13:14:15 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D129221F8ABD for ; Sun, 18 Dec 2011 13:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwebXxWDbb3P for ; Sun, 18 Dec 2011 13:14:15 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 558A721F8A7A for ; Sun, 18 Dec 2011 13:14:15 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RcO20-0001RA-Mw for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2011 21:12:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RcO1z-0001PA-IZ for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2011 21:12:27 +0000 Received: from moutng.kundenserver.de ([212.227.17.8]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1RcO1v-0003vM-4k for w3c-dist-auth@w3.org; Sun, 18 Dec 2011 21:12:24 +0000 Received: from ginster.fritz.box (dtmd-4d0529bd.pool.mediaWays.net [77.5.41.189]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0M9AGP-1RQbFx2OWT-00CSFf; Sun, 18 Dec 2011 22:11:56 +0100 Date: Sun, 18 Dec 2011 22:11:47 +0100 From: Werner Baumann To: w3c-dist-auth@w3.org Message-ID: <20111218221147.5e6dd5ca@ginster.fritz.box> In-Reply-To: <74AD90A6360A45549965F59C1EC5ED7C@Javier2> References: <74AD90A6360A45549965F59C1EC5ED7C@Javier2> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:S41VfyDDDdYZGpmYKgYU5EHRYv7Ewz8EojZW5S2Npje hLUGrvhrmELYppnAyucyLzXdMX5ad+7eWWbkoTMcdH3esegB09 QU5pRVK3KLbW9qez1uiPl1LFo9aetKFPxi+b1sorSRurQZfTFX DsO1U57S8f6HhSY6Ax2r8eCNPVU4JM7M8TIYkaeYdyvbdN3z7v Dl8HVA8oIIt3ehgtq6chDVaaru+hxfuQYeQtu1LUiGR+ObsLUM Sc2dniHkususlfRkUZXLXoSqKQHpkMz1MnO/p1mo+LdWcgsxU1 hfFOQIv/pTdxz5ns987LAgn2nd2z7Qqe3nBuFT/KXYieTVxQY8 aRYxIE+t5/EzmL5F8o/YnRnXbIKYEJYm/J7vTYkit Received-SPF: none client-ip=212.227.17.8; envelope-from=werner.baumann@onlinehome.de; helo=moutng.kundenserver.de X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1RcO1v-0003vM-4k c019dd4374bc75e6e513fb7a477cc212 X-Original-To: w3c-dist-auth@w3.org Subject: Re: About COPY Overwrite:T Depth:0 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13371 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 18 Dec 2011 21:12:28 +0000 Copy with Depth: 0 is one of the fancy ideas of RFC 4918 that was never seriously defined, just as Collection is mostly undefined. Copy - with or without Overwrite - of collections only makes sense with Depths: infinity. Depth 0 or 1 will work when the depth of the tree is 0 or 1 in which case you could use Depth infinity as well. Otherwise you will get orphaned members or mappings to non-existent members. Or you create a copy of a collection that isn't a copy because it has a different list of direct members. Cheers Werner From w3c-dist-auth-request@listhub.w3.org Sun Dec 18 13:59:55 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D0421F8B0F for ; Sun, 18 Dec 2011 13:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMvKP-+GOdrk for ; Sun, 18 Dec 2011 13:59:54 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AE8D121F8AFC for ; Sun, 18 Dec 2011 13:59:54 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RcOl7-0007uT-4a for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2011 21:59:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RcOl6-0007tc-8L for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2011 21:59:04 +0000 Received: from mailout-de.gmx.net ([213.165.64.22]) by lisa.w3.org with smtp (Exim 4.72) (envelope-from ) id 1RcOl3-0004gz-3I for w3c-dist-auth@w3.org; Sun, 18 Dec 2011 21:59:02 +0000 Received: (qmail invoked by alias); 18 Dec 2011 21:58:34 -0000 Received: from p3EE2691F.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.105.31] by mail.gmx.net (mp070) with SMTP; 18 Dec 2011 22:58:34 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19wwKMx8dBwZFP6jVriGyv1lkz+IK3opHkWFFV+fy sc63CPCauTNy78 Message-ID: <4EEE6207.4000006@gmx.de> Date: Sun, 18 Dec 2011 22:58:31 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: <74AD90A6360A45549965F59C1EC5ED7C@Javier2> <20111218221147.5e6dd5ca@ginster.fritz.box> In-Reply-To: <20111218221147.5e6dd5ca@ginster.fritz.box> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass client-ip=213.165.64.22; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1RcOl3-0004gz-3I f540ed2e7b63276df6b0ca8b18b71451 X-Original-To: w3c-dist-auth@w3.org Subject: Re: About COPY Overwrite:T Depth:0 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13372 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 18 Dec 2011 21:59:05 +0000 On 2011-12-18 22:11, Werner Baumann wrote: > Copy with Depth: 0 is one of the fancy ideas of RFC 4918 that was never > seriously defined, just as Collection is mostly undefined. Well, it's seriously defined, but maybe it needs to be clarified. WRT collections: what exactly is the problem? > Copy - with or without Overwrite - of collections only makes sense with > Depths: infinity. Depth 0 or 1 will work when the depth of the tree is > 0 or 1 in which case you could use Depth infinity as well. Otherwise Depth: 1 isn't defined in 4918. > you will get orphaned members or mappings to non-existent members. Or > you create a copy of a collection that isn't a copy because it has a > different list of direct members. I'm losing you. The spec says: "A COPY of "Depth: 0" only instructs that the collection and its properties, but not resources identified by its internal member URLs, are to be copied." The problem I can see is that if you read this literally, you'd copy the bindings to the member resources, which is unlikely to be intended. Sounds like an erratum to me. Do you see other problems? Best regards, Julian From ferra@prumandg.co.uk Tue Dec 20 17:47:37 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96C21F849E for ; Tue, 20 Dec 2011 17:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.901 X-Spam-Level: X-Spam-Status: No, score=-73.901 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2QbA4h9tUk4 for ; Tue, 20 Dec 2011 17:47:37 -0800 (PST) Received: from mail.dokatech.com.ar (mail.dokatech.com.ar [200.61.42.145]) by ietfa.amsl.com (Postfix) with SMTP id 7B8DA21F849D for ; Tue, 20 Dec 2011 17:47:34 -0800 (PST) Date: Tue, 20 Dec 2011 23:42:27 -0400 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: ferra Reply-To: To: Subject: webdav-archive - you're a good man? Message-Id: <40469-16302-VQMIR-AIMSO-SMSROCD-CZCXMR-84321814-u9wwshyryv138a@e-dialog.com> X-Mail-From: RRO6D-ODTIU-QICUZ-TVAMQATT-VSOACD-90593057-yx33adftuf4nj@hearst.bounce.ed10.net X-Match: hearst.bounce.ed10.net X-RCPT-To: X-Mailer: EDMAIL R6.00.02 X-Loop: e-dialog Good Morning My dear. I read your ad in our International Dating Club. My name is Tanya, and I'm 33, my height is 174 cm. I graduated from Institute in 2008 and am working as an teacher. I interested in mountaineering, surfing and home-making. I'm independent, don't smoke or drink. I liked your photos and Waiting for letters from you. Go to my acc- http://bayub32ajaa1.page.tl Kisses and Hugs! From w3c-dist-auth-request@listhub.w3.org Wed Dec 21 03:20:12 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31F421F8531 for ; Wed, 21 Dec 2011 03:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r98Wj-zD1Kl for ; Wed, 21 Dec 2011 03:20:12 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F37F421F852E for ; Wed, 21 Dec 2011 03:20:11 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RdKBs-0006zf-AK for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2011 11:18:32 +0000 Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RdKBq-0006ys-V5 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2011 11:18:31 +0000 Received: from fich.unl.edu.ar ([190.122.240.170]) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1RdKBn-0005UF-7W for w3c-dist-auth@w3.org; Wed, 21 Dec 2011 11:18:29 +0000 Received: from localhost ([127.0.0.1]) by fich.unl.edu.ar (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits)); Wed, 21 Dec 2011 08:17:31 -0300 Message-ID: <123F84E10DF14F98BE54CD2206A14A19@Javier2> From: "Javier Godoy" To: "Julian Reschke" , "Werner Baumann" Cc: References: <74AD90A6360A45549965F59C1EC5ED7C@Javier2> <20111218221147.5e6dd5ca@ginster.fritz.box> <4EEE6207.4000006@gmx.de> Date: Wed, 21 Dec 2011 08:14:19 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Received-SPF: pass client-ip=190.122.240.170; envelope-from=rjgodoy@fich.unl.edu.ar; helo=fich.unl.edu.ar X-W3C-Hub-Spam-Status: No, score=-4.1 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439 X-W3C-Scan-Sig: aji.keio.w3.org 1RdKBn-0005UF-7W 742de0768594e5bdef7bb97a87e0cc92 X-Original-To: w3c-dist-auth@w3.org Subject: Re: About COPY Overwrite:T Depth:0 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13373 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 21 Dec 2011 11:18:32 +0000 On 2011-12-18 18:58, Julian Reschke wrote: > On 2011-12-18 22:11, Werner Baumann wrote: > > Copy with Depth: 0 is one of the fancy ideas of RFC 4918 that was never > > seriously defined, just as Collection is mostly undefined. > > The spec says: > > "A COPY of "Depth: 0" only instructs that the collection and its > properties, but not resources identified by its internal member URLs, are to > be copied." > > The problem I can see is that if you read this literally, you'd copy the > bindings to the member resources, which is unlikely to be intended. Sounds > like an erratum to me. > > Do you see other problems? It follows that the requirement in Section 9.8.4 does not hold if Depth is 0: "when a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY." I agree it looks like an erratum. Best Regards Javier From w3c-dist-auth-request@listhub.w3.org Wed Dec 21 04:21:00 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6175E21F8AF1 for ; Wed, 21 Dec 2011 04:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zdv6csmRgacN for ; Wed, 21 Dec 2011 04:20:59 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 41FE221F8AEA for ; Wed, 21 Dec 2011 04:20:55 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1RdL9H-0002Sh-3F for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2011 12:19:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RdL9F-0002RE-U1 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2011 12:19:53 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=donbot.greenbytes.de) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1RdL9E-0003if-2r for w3c-dist-auth@w3.org; Wed, 21 Dec 2011 12:19:53 +0000 Received: from robotsanta.fritz.box (unknown [217.91.35.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id DBFC2C4C0E7; Wed, 21 Dec 2011 13:19:27 +0100 (CET) Message-ID: <4EF1CED2.5050809@greenbytes.de> Date: Wed, 21 Dec 2011 13:19:30 +0100 From: Manfred Baedke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Javier Godoy CC: Julian Reschke , Werner Baumann , w3c-dist-auth@w3.org References: <74AD90A6360A45549965F59C1EC5ED7C@Javier2> <20111218221147.5e6dd5ca@ginster.fritz.box> <4EEE6207.4000006@gmx.de> <123F84E10DF14F98BE54CD2206A14A19@Javier2> In-Reply-To: <123F84E10DF14F98BE54CD2206A14A19@Javier2> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=217.91.35.233; envelope-from=manfred.baedke@greenbytes.de; helo=donbot.greenbytes.de X-W3C-Hub-Spam-Status: No, score=-4.5 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.6, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1RdL9E-0003if-2r b5e582d4c4a8e480740391f7acd55025 X-Original-To: w3c-dist-auth@w3.org Subject: Re: About COPY Overwrite:T Depth:0 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13374 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 21 Dec 2011 12:19:55 +0000 On 21.12.11 12:14, Javier Godoy wrote: > On 2011-12-18 18:58, Julian Reschke wrote: > >> On 2011-12-18 22:11, Werner Baumann wrote: >> > Copy with Depth: 0 is one of the fancy ideas of RFC 4918 that was=20 >> never >> > seriously defined, just as Collection is mostly undefined. >> >> The spec says: >> >> "A COPY of "Depth: 0" only instructs that the collection and its >> properties, but not resources identified by its internal member URLs,=20 >> are to >> be copied." >> >> The problem I can see is that if you read this literally, you'd copy t= he >> bindings to the member resources, which is unlikely to be intended.=20 >> Sounds >> like an erratum to me. >> >> Do you see other problems? > > It follows that the requirement in Section 9.8.4 does not hold if=20 > Depth is 0: > "when a collection is overwritten, the membership of the destination > collection after the successful COPY request MUST be the same=20 > membership as > the source collection immediately before the COPY." > Not necessarily. I think this is intented to prevent a non-empty=20 collection from being overridden by an empty collection. The COPY with=20 Depth:0 must fail then. Regards, Manfred --=20 Manfred Baedke bytes GmbH Hafenweg 16 D-48155 M=C2=9Fnster Germany Amtsgericht M=C2=9Fnster: HRB5782 From sunsunahxf@yahoo.cn Wed Dec 21 08:14:30 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0645D21F8A57 for ; Wed, 21 Dec 2011 08:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.954 X-Spam-Level: *** X-Spam-Status: No, score=3.954 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACYC6He4C3XG for ; Wed, 21 Dec 2011 08:14:29 -0800 (PST) Received: from nm19-vm7.bullet.mail.sg3.yahoo.com (nm19-vm7.bullet.mail.sg3.yahoo.com [106.10.149.118]) by ietfa.amsl.com (Postfix) with SMTP id AEAD221F8A4E for ; Wed, 21 Dec 2011 08:14:28 -0800 (PST) Received: from [106.10.166.115] by nm19.bullet.mail.sg3.yahoo.com with NNFMP; 21 Dec 2011 16:14:25 -0000 Received: from [203.209.250.222] by tm4.bullet.mail.sg3.yahoo.com with NNFMP; 21 Dec 2011 16:14:24 -0000 Received: from [119.42.242.156] by t1.bullet.mail.cnh.yahoo.com with NNFMP; 21 Dec 2011 16:14:23 -0000 Received: from [127.0.0.1] by omp1003.mail.cnh.yahoo.com with NNFMP; 21 Dec 2011 16:14:23 -0000 X-Yahoo-Newman-Id: 763945.57071.bm@omp1003.mail.cnh.yahoo.com Received: (qmail 57095 invoked from network); 21 Dec 2011 16:14:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.cn; s=s1024; t=1324484063; bh=V1ZwuZUzbbIPRDHd9WOsfRnoCSGhFJzQOCnj3zuCZOw=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE; b=NUI+/JM99SjqAD/B2bGVDH0bUgyWJX/B0cufRQyPCE4YszIfOC7CvsZJdUsLfvN0u7hQy38XZH9iwjPO79VXmvJVtleNUEp8SNEFPzH+VdK5TZRyxGzZ9quT0M+uaIm5qeF5Zf6VNXXIBmOBL35NYcZlS/BRpEy8RYNgfddrzvo= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kG69R2UVM1nrgtduadCy0qm6G_CuS7u72tfCi5qvnJ7QUi5 lH0zJzrPEHUgBphTGI1qJZ1HHjPV5bebn2ipTDqkloMBrHg6H0.McxvxC4a8 uIbMYRkAEnE.J48eb7Ep8TniW3.1N1sQYhgZk.ugpvoGz7IKLXcCIy3GXsO1 6oaFNb9yuN9RydJCFTAqIf9x7V2650kI9rAlhmbQ_rExuehu6xOLTBcGlyCm YAWGeYe599948r0zA_ttT_jERrGj4lJXI0N0br_i3SDz.8t5qpELqBk0az5i rNt7xEiwBru8fJVIWaVlEORYU7MZm_8vb3yOAQ79LsydTAl5ZQrdrz.ax8RK hoRZR9r4_QEsbPxBzD9WmSQ-- X-Yahoo-SMTP: 54Rb8b2swBAzfP61RKqp7Ok7CRS5nXN5yjZbTAoKviY- Received: from nvyx (sunsunahxf@59.35.189.190 with login) by smtp106.mail.cnb.yahoo.com with SMTP; 22 Dec 2011 00:14:21 +0800 CST Message-ID: <9A7DC14BA0338FFE4A96ACAD1E39EC81@nvyx> From: "bgvlxkw" To: Subject: =?utf-8?B?6ZW/5pyf5pyJ5pWI?= Date: Thu, 22 Dec 2011 00:13:26 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0C66_01FA6130.1E4B9220" X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 ------=_NextPart_000_0C66_01FA6130.1E4B9220 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0041_01FA6130.1E4B9220" ------=_NextPart_001_0041_01FA6130.1E4B9220 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQogICBiZ3ZseGt3DQogICAyMDExLTEyLTIyDQo= ------=_NextPart_001_0041_01FA6130.1E4B9220 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPg0KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPg0KDQo8 aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04IiAvPg0KPC9oZWFkPg0KDQo8Ym9keT4NCg0KPHA+ICAgYmd2bHhrdzxi ciAvPg0KICAgMjAxMS0xMi0yMg0KPC9wPg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------=_NextPart_001_0041_01FA6130.1E4B9220-- ------=_NextPart_000_0C66_01FA6130.1E4B9220 Content-Type: image/gif; name=xw.gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=xw.gif R0lGODdh2AFEAXcAACwAAAAA2AFEAYeAAACXAACvAACAAEiXAEiAAHSXAHSvAEiXSEjESADYdACA SJyAdL/snEj/v3SXnN+vv//Y/7//35z//7/E3//Y/////9/s//////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABH9/D9VmMBGIX/B1YAAAEA AAAAAAD/CQRH9+j/BRgAAAAAA/8AABAAFA1H+Bz73zn/AlAAAAgAAQAAAAAAAAAAAAj/AlCjB0AA AQhH+YT7SG7/AlAAAAgAAQAAAAAABKAAAAABGIX/CE7/BRj/CQT/CmxH+Pz/BRj/AlAAABf/BRTv W3AAAAAAALjvoJbvoFkBGIUFCZAAAAAAAURlAAAAAgblLYhH+gBH+NAAAkbvf2zvhFAFIisAAFRH +cBH+MzvhIEFIisAAFRH+cBH+gBH+ZhGpGwFIisAAFRH+cBAY7ZGoVlH+ahGpG1H+ZgFCZAAAAA/ D9gAABAAAABH+SD7QnoAAAAAAdgAAUQAB2AgAAHvb1/zQGAFCZAAAAABAADvbh1AXQVAV5ystNBA RTZAVtmS5QFAXJ1GnMNH+hSstNBAVx9GnGEFIitGuZJGubV2IShGub0FCZAAAAA/D9istdA/D9hH +hxGqToAAAAAAABH+cBH+ihGqURH+hxH+lustQAAAAEAAAAAAdgAAUQABYgYAAFlAAAAACgAAdgA AUQYAAEAAAAHACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIitH+qBGxI5H+kMAAAFG qalGxMoAABW/qHgAAAH+UCAAAAAAAAEAAAEAAAcAIAAAAAAAAAAAAAEAAAEAGAAAAAAAAAAAAAAA AAAAAAAAAABAXMBH+qxAXM9H+qQAABW/qHgAAAG/qHhH+sRhKV5H+tBAXHFH+sS/qHgI/wAxCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jT ql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gza97M ubPnz6BDix5NurTp06hTq17NurXr17Bjy55Nu7bt27hz697Nu7fv38CDCx9O3CgAh8eLK+eZPHlC 5wCiS3e+vPpK6NOlE6S+3br36wK5Y//gLn789/Mno5sPbzA79fLr0cvPqH79cfHNux+EP78/cvvs xRfgewjx59+BBbIH3UAEjueedgwiKCFECy4YoIDwGTjhhhcKuF1+Ee7H4YgY1RdieySmGCGIJ7bo oYsqbnhfiCya1yCKMY6oHn4XNmdhjkAW9KCQNL7YYZBIGqlkkkw26eSTUEYp5ZRUVmnllVhmqeWW XHbp5ZdghinmmGSWaeaZaKap5ppstunmm3DGKedd9Wkokp3x4bkkkTDhqeeeeZJkYkr4/Rkejwk+ 96B7e0Go4HMwHrrooHwu9COORwq5KKSZSjqppYD+SammA7Y36XQMkXfqqA9ZmGFDjt7/2GOnfBoq V4MZ1tjqh5+KSOuhvwb6a50Taahrd3oaeyJ/soJaaaLFFgmts6VWip2pp/qFK7S20prssr4226uv gHK76qvlhtoiusHqR+Sn3YILIKYKIWqtu/Jeqlezz76YrZIG/nitg+dOa3Chm6pbL74GPzskvd/S 62G3jProaKQMZkfwxeea6CrGt3ZMnsSperqqtPYxW6vI/abLMMn6Ddwwrxdz2q63/cbbI4Ts2izu zQX3xW+krNr8Mo4fG+0yuR9SSPOx8koq4qtDi6wy0xNXdB+xAFvKNc6VbeuuqtgxmunIU6/oNcPj Ri21ybGOPaDMWaeN9NEOw5rowzoL/wt1qDMOvXHR/wrtMYZN42svwhpjq/bC+paHNrCKY3ojiAHr vafglZeM9Yw3+1wtzI8PLjnnhtVcdLuLe44i3eTqKvDCtMudcazKun41yB36efDoErkKOumPlv46 74N9HWzVDyssOrWyu503to2Xa+f1iUucOd4tH4m51kXufrfx77potdDINmyv9OTHTi3b7J9Nsr7h L4l99i8fO/n7K24Ku9eg2977hncv3yWPcjUqm+pqRzzb+cuBpYKaAiklwIxFUGkwG5Xk6sa97uWO cqmi3/qet8EOzu4vG5zg/xJUwdsFTX7syhWqQAiqstFwdS3kFd4GVULNdZCDimrZ/v9qx6LosUpW fUMLAfHXQx9iMHgzo6AGscY/GoJMfJ8LYtd29bSElchsoRtdhZh4uOIh71YMdArhAFPGJ3JkdXZz If6uOKc62vGOeMyjHvfIxz768Y+ADKQgB0nIQhrykIhMpCIXychGOvKRkIykJCdJSUMmMXitM1oO r3ZJOZqOih3p2dLcqL5QQk8jkdPefkTVvQaybCed5KKpdjY9bgFvViUC3umqh0ke/i6XcPNlKy0S sL9B0YJW5KEoFaUdMPrNc7FECRw3kitPGo9ZqAqgptrmtHmdbYjRap7JTBevaX7SRhfpGASJWaup efGM6DSjAzV4MuZss2bgW+Xbjhf/zPwtEXHA/N7IUPefmKXvlsd04goLipzCRUSFHBsm60qXSfmJ USd8+6EsD9o7FwYunhNzZj2LxbN1JS2d5GzmNUvyHo2ZE5TT6qRLowZOV3KUbCM9aTTvhLJRkjKk cRNonrJZQI1qToKzBKZBmfnSECbso9RkaBh1h87h1cmZEk3pAq030pyc1Kcz66Y241nEdmq1b5jj JTKbWqBmipSoU92mB9UaV6PCNKEWm5v5ftpAeB7lq7Espjgfl5/JDZagDb2q+YqIz43ujn7dRGgA VaozP73yoR4lKkRJeb57Eo6bOAEsfdLYKa6lFa6LBW1BfbSsnx1za1gdWBIvF65H/1X2Jaz0Hl/D 6iC7BqWsraWIAEUIXMNm1SATEIDIClCBeUG1i45K7nIrkEDRDU+6HWOusGA0pBlh91zaNdS4vruq 8EJ3bFj1LfesChX2Bjdaz8PQc1PZT+g2drW21SQ7OTfG2e6MZyWtqnAjq17HAZG+dz0rPt2bWdXa BImojG8TXQvELcL3e/rd7zsJtt1wNo6CngIpZjfqVwPX978z7GvnLJeunUpzqClmK/EKS8Sc7XWH A76gKP3Lr7j1lMT50zF8gQzWG6/LyMddp24l7JNrXc6/PkPXCJ+7ZBWzMGX7tOiQlXfkH+utqUIt 50M3zM4V19RWInzXhAsMnp66eP/HUyRQoWaF0/T68FItLd+QGzxCDhPYoayFbBVdx2amRrSrt92f MmdX05m4uFV5tnJpu4zjOy1zJI8esVUz3WZKry2f+pxxJUdN6lKb+tSoTrWqV83qVrv61bCOtaxn Teta2/rWuM61rnfN6177+tep67NG57xn8aZ4xTlGNklbusa2vnCUmRbzpytN4EJLNSw+Xl4IPZrs CWZ2gPVqmzDrejsdDrq2exssUKVoZ4hWc5V4dvaxx6m/8wZTnJvlitgMPWeVlpm2CW40Bt0tYy17 dlzP9mZrNYtkGGb1fghNJuQUjkPSrpPTTVZx7gQ9Yml19sN0zZ74bpvkDxYXtdz/rRbj5u1NbJJZ 2CIu4Vc3Z/HBOVcrFQs5+05oZf8Ny7rWCrAVlQ1poe9WpytLL3ubWGUbqTWGLuVlGVU2xmpLNGkY 70m8D37sNl5aaf/kZtW5i+8pljllT1d3woHL563Je94EpLAQKU1ssCc04B7Xt/KELee2q3egLK6y 2ZcqcwfXuMNDv6Tbf87RyFa9zmmvbqg/68UYx9aEed/KjgB6tIp+3b5j9fvTOooslDe927hs3y7V DluRju/jM43e56hMbAVecdwfPOdTyZ2UTbOc6dv9fBZJj3ieG9fgRfZs6tGu84Yu/9uIhyeNK3xk FTLxXuQUPLhJyHukxB1gL48f/7QBfu/j95bz6Jev1A04z5STtOVJvehSayx7iCFOhq4/vfg9rWd5 YqW6l1ZRRpJbPDdMWydnFVNLvcN+xBdkbZd/u2c29BVbfbduYASA26dK7sNAnNQ+WVGBh2c7obc0 wuN77wRZCAZCgSNwacQ8dvZDrIVseYU2ued2jbY+/6SA9hZ4SMZJY5V1sORlIIVgS2dXYoNFozc+ 8GNBSxRpGThpHhQ/VIZ+GKY2EKdwYCOCLYhSTaiD+RJxVYF08sd5mzd003Zcj9V4NtVgcxRTUShZ RDeFzGZ07xWC1KdlbId8DbdWpPJx2AeEGJV6bLd1wWdt3vNKSOiBv/RnGWRu4P9iXFcldfNHdiEH YqCHKMYHeLYUU81nd474gesWhCoBiBbHdLnHNCzYfck2dzh1fvOTcDwFbLI4i7RYi7Z4i7iYi7q4 i7zYi774i8AYjMI4jMRYjMZ4jMiYjMq4jLqYiBPlEYjVfM7IjBgzjQjUiVw3VDt4bt5ScLsIfMhD iHcmhM8XcBbjjQchAQbQXAPRANExABRAEBIQANHBAAThjtEBAff4jvEoEORljwKBj/AoEA7wIPqI AQLZjwHJjwahjuxIJT5nP6dUYoU4cvC2YeAYEcmlXQGpXQ4wkBjgAAtwARiQXADZAANZkAepAAM5 jwcpAQSgkAPBkvHoksglACf/6ZEg2QA6KZMb+ZBZUoX1c3DpB0BdVZQNyIATUZAAwJHJ9QACYQEJ YI9SCZUdWQFSCZAYoAD2+JTtOJIhyZED4ZUBCZb3qF1kmZUlKQBWqZYEGR1iCZGEN0tI5XQsZ4f4 V3H894ASUZAP4ABxORBqCZMyGZVTOZP2+JEKqZgIqZUDwZgECZICMY9WWRBuSRBu6ZeACZRy+UyJ k2Yx53gwKEGF83sZsZkHgZLxCJgRoFwAUJmqGZIAoI+QKZv6qAAIIB1WWZsqSRAKEJgBKZntKJxh yZlyOXMCQ4NIaWjrBU4QNncYgZoEwZRW6Y7adZlMCZI2uZAQkFxmqQBQuZ0I/zmbY8mWBkGdBYGe 6QmcnalLioN1f8eX5WeJDaiHS8meUjmSsUmQ2vWbzUWZAkGTGDCP5LmezSWgBHqQIUmcgpkAZtmg D1qcWjJ1DXc45yhj4mhmz4mHbwUR0nme8MiTD+mS4imiAQqXEXAAhTmgAbCSKKqiMxmh6cmgtSmh WOJe9baEy5luHAcgq6d2PWgoH1oQLvmhhMmbDOqQDRmTDbmO/mieCSGeAyGlQ9qeAmcskgcr/sZ4 WEiFPKiKNiqem5lcCrqZYgqcDTCSZ2qcaUqSLKqgb/qYzLWm08meUOKEEskp3ydLY2dmpNV3iiak YqkAYFmVZUmShrqV2gWgJv8Zmf3IlTMJlY26oItJnISKqAlglZeKAYkqp8Z5p0XFWwRHMT+maAP3 mR36EEOqANIBp0z5mr6pm+XJkDPZqrMKAMJpogXBqvkYq71qoFVyioqIWFwUaSC4Ofl3h9S4W9Co rMm3rNAardI6rdRardZ6rdiardq6rdzard76reAaruI6ruRaruZ6rujqH+g4VdI2kajIjWbVYk5E Pf/ijT3ao8M2jkTmgG/ErG2YYFTxo3RlfaQSfQVrhwfrivSadtqYhEQINFzKUMWETMzaZyWoly2I VqLHhBRIsPZ1keqWcTAlgJ4Hr/t3pZgXfTpFfvTkUHHFceO2sPflnAmIYi7/m4rbtl6nJ4D6l5RD 4YzWd3n7J2KbCFCAprMzVT5CuXyZhIJ8CilHSzqCI4auJIEodWLPp4lZu5wbChRA+6WqolUbiH0N 24XDt4FWq00rh3Aok5HzJzNs5WAxCLLlKK8ee7VJNUSDqIVuSJEyIVhACjfXl4WJh0umVTXlJ3LA Aqhm2KUyq3Mbt3lShLVQaGKbOLAhW4WK1ysec3m0t1jhZnhehZfxd2U7l5wUCof86rT9dX9nJWl3 h24K63+h+4KWJXRhC537RDH3pYbgl18d2LdgyhIR01ZiS3dzFLND6C8sCLM2931qW7uUF7LPCJoX OnjvqU6GW33z07b5dFgK/4a8oWaGXSuyINs8Zmt/lYuCFqpn4fdzrWuFtEuxz9pXeZhkiRtHl5sv h8Vo/2Zjn3iJCWtNXvpb14Zhf9N6ZSe4/WeJzUtH8ZtfRHtTUUU7zpt9/3u+OzJDoNl/EyxWQqsg MYReYgt52HgTSlk3F9o5I0xVi/iA1YOjSguGDDaflegsF3xmEPuy7kdtfquETTeFTMuDa/bDMXGF S5bAFNtD7IdFxfs6HPyuA6iIJQdNZUh6etthOLg39ZlSxss24kW5H9OyrJe5RKd1gzZQSryAX8pk OsqNRehLEdyzNHV0MbtvugWfhNc6PdaIgZK7X5bFfoN7q9vDXWy+Uqu0zf9Wd1urYF2Hv1RHwtrY uXlcxJXrbOo7N+v3QFnDbCalel6WuxHlfFlMfkNMtlNmiH1CRdA7h+1rOZeFWS6rs/QreXi8aI8I wML1yMpKvYO3xRCjTMn7veQDc6/LdfQ5lEShvIZssiy1iiZxRD+1ri3BaTj7EcRac3zXeUacrt78 zeAczuI8zuRczuZ8zuiczuq8zuzczu78zvAcz/I8z/SMaVZHaCQYn9d2wEf1w8KawnkUxtBHl+yq z/PKzxvHOwSnPjX4gmsi0HWrV1gKi7EcM2SWxBp8xV98RthLr0MrJp11XsZkWo61r6X0dvg6huYi jRt7yvXLJb2bdyPNZzX/FEbJcoFWbMZEedD08WF0dCYajW5CzIc8TCHU28yzZ5RXPNH927k3LGB+ BrAw/cFziVT3i8y+bMzyhD0LdYjEhY4pyIYKDdSOy4aCtqc8DbX2i7OvzMplrcl3KT0yR1bOPKER fXOIe5T6fNH0yzrHepE+asFXJ9btpMDNNibJycWh2b1OpdOcTNAGCL04HNh66tCeKbD4Sooykn0L dkFEo3FT/KdVBHHG5NkK88CDvdj+CpGCnI026NaCvdaW/djcV7sGa9GdCFU56KN8rdkpopQ1zK9j C4P2C9qFONmZk8x5G3HT94xkDc2w3djYOHOMPXEfTVaf5azwN7sFPCcafTva++w8Uc1P89s/1AM5 /EVn0OS4zS3efITEL80//4zPsStVaMaB+FvP+r3f/N3f/v3fAB7gAj7gBF7gBn7gCJ7gCr7gDN7g Dv7gEB7hEj7hFF7hFn7hGJ7hGr7hHN7hHv7hIB7iIj7iJF7iJn7iKJ7iKr7iLN7iLv7i/h0QADs= ------=_NextPart_000_0C66_01FA6130.1E4B9220-- From webdav-archive@ietf.org Fri Dec 23 13:20:26 2011 Return-Path: X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4924921F8B1E for ; Fri, 23 Dec 2011 13:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+dGrZLyZi3L for ; Fri, 23 Dec 2011 13:20:25 -0800 (PST) Received: from 201-246-222-65.baf.movistar.cl (201-246-222-65.baf.movistar.cl [201.246.222.65]) by ietfa.amsl.com (Postfix) with SMTP id C42A721F8B1B for ; Fri, 23 Dec 2011 13:20:24 -0800 (PST) Message-ID: <20111223224508.2570.qmail@201-246-222-65.baf.movistar.cl> To: Subject: webdav-archive@ietf.org Sales Today -37% From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Fri, 23 Dec 2011 13:20:24 -0800 (PST)
Click here!