From nobody Tue Dec 1 01:44:41 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D6B1B3982 for ; Tue, 1 Dec 2015 01:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzPPWRXMvKnF for ; Tue, 1 Dec 2015 01:44:38 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 519D91B39FC for ; Tue, 1 Dec 2015 01:44:37 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygCn0AWYbF1W8fUBAA--.6663S2; Tue, 01 Dec 2015 17:47:04 +0800 (CST) Date: Tue, 1 Dec 2015 17:44:29 +0800 From: "Fei Song" To: "Gihan Dias" , storagesync References: , <565CFFAB.3000005@cse.mrt.ac.lk> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120117442875955320@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygCn0AWYbF1W8fUBAA--.6663S2 X-Coremail-Antispam: 1UD129KBjvdXoW7JFWxCw4fCFy8JF4fJry8AFb_yoWxAwc_CF yFyF48Gr1UGr4UKw42yFy7CrnxXF4Ygr1UJ34UJr4UZrWavr4DtrnrGrW7Z3WrX34rJ3s8 AryrGr1rGr15GjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbx8YjsxI4VW7JwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWxJr0_ GcWl84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0 cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8Jw ACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1l c2xSY4AK67AK6r4fMxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6x AIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x0zRnNV DUUUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] New version of draft-dejong-remotestorage Internet-Draft available X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 09:44:40 -0000 SGkgR2loYW4sDQoNClRoZXJlIGlzIG5vICJXZWJEQVYiIGluIHRoaXMgZHJhZnQuDQpidXQgdGhl IHNvbHV0aW9uIGxvb2tzIHByZXR0eSBpbnRlcmVzdGluZy4NCg0KDQotLS0tLS0tLS0tLS0tLQ0K RmVpIFNvbmcNCj5PbiAyMDE1LTEyLTAxID8/Lj8uIDI6NTQsIE1pY2hpZWwgZGUgSm9uZyB3cm90 ZToNCj4+IEZZSTogDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UtMDYudHh0DQo+Pg0KPj4gUmVhY3Rpb25zIHdlbGNvbWUh IDopDQo+TWljaGllbCwNCj4NCj5Tb3JyeSBmb3IgdGhlIG5ld2JpZSBxdWVzdGlvbiwgYnV0IEkg Zm91bmQgaXQgZGlmZmljdWx0IHRvIGZpZ3VyZSBvdXQgDQo+d2h5IHRoaXMgY2Fubm90IGJlIGhh bmRsZWQgYnkgV2ViREFWLg0KPkNvdWxkIHlvdSBwb2ludCBtZSBhdCBhIGRvY3VtZW50IGV4cGxh aW5pbmcgdGhlIGRpZmZlcmVuY2VzPw0KPg0KPlRoYW5rcywNCj4NCj5HaWhhbg0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMg bWFpbGluZyBsaXN0DQo+U3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5j From nobody Tue Dec 1 13:14:10 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790001B3B10 for ; Tue, 1 Dec 2015 13:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdr6kXfethYo for ; Tue, 1 Dec 2015 13:14:06 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458AB1B3B0A for ; Tue, 1 Dec 2015 13:14:06 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9CA09202D0 for ; Tue, 1 Dec 2015 16:14:05 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute3.internal (MEProxy); Tue, 01 Dec 2015 16:14:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=JPqBXmOP5LPJS1fFFbQuSnuS5lU=; b=o4QwRD irxh1ycmsV+JnxcYZs2ZF8h15d8u7iQ9X5qaDsnH0gbikyuxQKJT0yUAesfIVtnT yGIzWqGn/f94sT3ugfgOnqU79a3pXaV7znvB+ZBoi+L1xsWsi95fcDMh3FVDX/wk AYac/jWaNZdvO4vVQz24aqohDk9iqdFk4fTto= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=JPqBXmOP5LPJS1f FFbQuSnuS5lU=; b=Af06ZU3VNj+RQngNs1MFVh6eloIvuOM27uqqiabokM2lkOW YHKLZkIkmhdSIlz9/LvmpNNtmp4tQxlEM/EbihG1QF75SPMmjVJDWL6WQPAiJ/iZ cdmf4ufFAWaH0Wpc7afV+BVjTIA0KBNxQT8wJdU2/y80aO3aHBIU4Fq3RuUE= Received: by web2.nyi.internal (Postfix, from userid 99) id 6C5CC5401FE; Tue, 1 Dec 2015 16:14:05 -0500 (EST) Message-Id: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> X-Sasl-Enc: tTqB/4YQ+BhnlvxSDQOz2qdMfZHWU5OI7T3CyZ3WXvzw 1449004445 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: storagesync@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 In-Reply-To: References: Date: Tue, 01 Dec 2015 22:14:05 +0100 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 21:14:08 -0000 Hi, from my point of view the remoteStorage project addresses a subset of the use cases of the WebDAV specification. The main difference I can observe is that the specification is built on REST instead of XML-based communication. I personally like much more REST than WebDAV because it is more developer friendly and it is faster to develop. Maybe the remoteStorage API becomes the next WebDAV :) However, the remoteStorage API does not provide a way of synchronising data, this task is delegated to the developers. Is there a plan to provide such feature based on the outcome of this draft? BTW, I want to introduce ClawIO (http://clawio.github.io), a research project to benchmark different synchronisation protocols against different data backends with special attention to provide a common sync API. A common API for different sync protocols is being created based on the architecture specified in this draft (control and data servers) and the one from the CERN EOS project (management, disk and queue servers). The Phase I has implemented the ownCloud Sync Protocol and Phase II will implement the SeaFile Sync Protocol. The choice of these protocols among others is because they are really opposed to each other in terms of syncing (delta vs non-delta, state-based vs log/event/git-based sync =E2=80=A6), so finding a common app= roach is more challenging. Providing a base specification/architecture to measure the feasibility of this draft is one of the objectives of the project. I believe that the work being done here and in ClawIO are supplementary to each other and I think mutual collaboration could be beneficial for both sides. Also, if there is interest, the remoteStorage API can be added to ClawIO. Best regards, Hugo Gonzalez Labrador On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: > Send Storagesync mailing list submissions to > storagesync@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/storagesync > or, via email, send a message with subject or body 'help' to > storagesync-request@ietf.org >=20 > You can reach the person managing the list at > storagesync-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Storagesync digest..." > Today's Topics: >=20 > 1. New version of draft-dejong-remotestorage Internet-Draft > available (Michiel de Jong) > 2. Re: New version of draft-dejong-remotestorage Internet-Draft > available (Gihan Dias) > 3. Re: New version of draft-dejong-remotestorage Internet-Draft > available (Fei Song) > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > Email had 3 attachments: > + [Storagesync] New version of draft-dejong-remotestorage=20=20=20=20=20= =20 > Internet-Draft available > 2k (message/rfc822) > + Re: [Storagesync] New version of draft-dejong-remotestorage > Internet-Draft available > 1k (message/rfc822) > + Re: [Storagesync] New version of draft-dejong-remotestorage > Internet-Draft available > 2k (message/rfc822) From nobody Tue Dec 1 16:15:13 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215BB1A8AAD for ; Tue, 1 Dec 2015 16:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYcWrjAO0oLI for ; Tue, 1 Dec 2015 16:15:10 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 245751A89F5 for ; Tue, 1 Dec 2015 16:15:08 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygAnpAaDOF5W3O4CAA--.9301S2; Wed, 02 Dec 2015 08:17:07 +0800 (CST) Date: Wed, 2 Dec 2015 08:14:31 +0800 From: "Fei Song" To: "Gihan Dias" , storagesync References: , <565CFFAB.3000005@cse.mrt.ac.lk> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201512020814310620372@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygAnpAaDOF5W3O4CAA--.9301S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYr7k0a2IF6F1UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0I7IYx2IY 6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aV CY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAq x4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6x CaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC 0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_twCF04k20xvY0x0EwIxGrwC20s026c02F40E14 v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkG c2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r4j6FyUMIIF0xvEx4A2jsIE14v26r1j6r4U MIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73Uj IFyTuYvj4RJ8n5DUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] New version of draft-dejong-remotestorage Internet-Draft available X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 00:15:12 -0000 KzENCg0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5PbiAyMDE1LTEyLTAxID8/Lj8uIDI6 NTQsIE1pY2hpZWwgZGUgSm9uZyB3cm90ZToNCj4+IEZZSTogDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UtMDYudHh0DQo+ Pg0KPj4gUmVhY3Rpb25zIHdlbGNvbWUhIDopDQo+TWljaGllbCwNCj4NCj5Tb3JyeSBmb3IgdGhl IG5ld2JpZSBxdWVzdGlvbiwgYnV0IEkgZm91bmQgaXQgZGlmZmljdWx0IHRvIGZpZ3VyZSBvdXQg DQo+d2h5IHRoaXMgY2Fubm90IGJlIGhhbmRsZWQgYnkgV2ViREFWLg0KPkNvdWxkIHlvdSBwb2lu dCBtZSBhdCBhIGRvY3VtZW50IGV4cGxhaW5pbmcgdGhlIGRpZmZlcmVuY2VzPw0KPg0KPlRoYW5r cywNCj4NCj5HaWhhbg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+U3RvcmFnZXN5bmNAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5j From nobody Tue Dec 1 18:09:57 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961A61B30F8 for ; Tue, 1 Dec 2015 18:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsrG71yDOu_X for ; Tue, 1 Dec 2015 18:09:54 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id B54EF1B30C7 for ; Tue, 1 Dec 2015 18:09:53 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygCXIHKJU15WNBQDAA--.9111S2; Wed, 02 Dec 2015 10:12:26 +0800 (CST) Date: Wed, 2 Dec 2015 10:09:49 +0800 From: "Fei Song" To: "Michiel de Jong" , storagesync References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201512021009490006833@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygCXIHKJU15WNBQDAA--.9111S2 X-Coremail-Antispam: 1UD129KBjvJXoWrZryUJF43CFWkAF18Xw1UJrb_yoW8JF1xpF 4ayw1SkFs5Jws3ArZruw4xZF47X3sYgFWUKasrK348Z3W5AF9YgF1Skry09FZrJr9xXryq vF1Y939xZwn8ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkEb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8JwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jwjj kUUUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] New version of draft-dejong-remotestorage Internet-Draft available X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 02:09:55 -0000 SGkgTWljaGllbCwNCg0KSSBoYWQgcmVhZCB0aGUgZHJhZnQgcXVpY2tseS4gVGhlIGRyYWZ0IGlz IHZlcnkgdGhvdWdodGZ1bC4gVGhlIGJhc2ljIGZ1bmN0aW9uYWwgZWxlbWVudHMgYXJlIHNlbGVj dGVkIHJlYXNvbmFibHkuIE1hbnkgZGV0YWlscyBhcmUgYWxzbyBwcmVzZW50ZWQgY2xlYXJseS4N Cg0KSGVyZSBhcmUgc29tZSBjb21tZW50czoNCg0KMS4JVGhlIHVzYWdlIG9mIKGwYmVhcmVyIHRv a2Vuc6GxIChTZWMuIDkpIGlzIG5vdCBxdWl0ZSBjbGVhciBmb3IgbWUuIE1vcmUgZGV0YWlscyB3 aWxsIGJlIGhlbHBmdWwuDQoyLglJdCBzZWVtcyB0aGF0IHRoZXJlIGlzIG5vIHNlcnZlci10by1j bGllbnQgY29tbWFuZHMuIEkgdGhpbmsgaXQgaXMgdXNlZnVsLCBlc3BlY2lhbGx5IGZvciBjb2xs YWJvcmF0aXZlIHdvcmsuDQozLglGb3IgdGhlIGRhdGEgc3luY2hyb25pemluZyAocG9pbnRlZCBi eSBIdWdvIEdvbnphbGV6IExhYnJhZG9yIGluIHByZXZpb3VzIGVtYWlsKSwgSSB0aGluayBzaW5j ZSB0aGUgZHJhZnQgaGFzIGEgc2NoZW1lIHRvIGF2b2lkIHVubmVjZXNzYXJ5IGZvbGRlciBjaGFu Z2VzIHRyaWdnZXIgYnkgaW5kaXZpZHVhbCBkb2N1bWVudCAoU2VjLiAxMyBEaXN0cmlidXRlZCB2 ZXJzaW9uaW5nKS4gSXQgd291bGQgYmUgcG9zc2libGUgdG8gYWRkIG5ldyBtZWNoYW5pc20gdG8g ZG8gdGhlIHN5bmNocm9uaXphdGlvbi4gT3IgdGhlIGF1dGhvciBkaWQgbm90IHdhbnQgdG8gZG8g dGhhdD8NCjQuCUlzIGl0IGJ1aWx0IG9uIFJFU1QgaW5zdGVhZCBvZiBYTUwtYmFzZWQgY29tbXVu aWNhdGlvbj8NCjUuCVNldmVyYWwgdHlwb3M6IEluIHRoZSBJbnRyb2R1Y3Rpb24gcGFydCwgobBU aGUgYWN0aW9ucyB0aGUgaW50ZXJmYWNlIGV4cG9zZXMgYXJlobEuDQoNCg0KDQotLS0tLS0tLS0t LS0tLQ0KRmVpIFNvbmcNCj5GWUk6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlLTA2LnR4dA0KPg0KPlJlYWN0aW9ucyB3ZWxj b21lISA6KQ0KPg0KPlNlZSBodHRwczovL3JlbW90ZXN0b3JhZ2UuaW8vIGZvciBtb3JlIGluZm8g YWJvdXQgdGhlIHJlbW90ZVN0b3JhZ2UNCj5wcm9qZWN0LCBhbmQgaHR0cHM6Ly9naXRodWIuY29t L3JlbW90ZXN0b3JhZ2Uvc3BlYy9pc3N1ZXMgZm9yIGRpc2N1c3Npb25zDQo+YXJvdW5kIHRoZSBj b250ZW50cyBvZiB0aGlzIGludGVybmV0LWRyYWZ0Lg0KPg0KPkNoZWVycywNCj5NaWNoaWVsLg0K Pg== From nobody Tue Dec 1 18:59:04 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD011B31B6 for ; Tue, 1 Dec 2015 18:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_TD1oszOPFV for ; Tue, 1 Dec 2015 18:59:00 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 142B71B31B5 for ; Tue, 1 Dec 2015 18:58:59 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygBHqBEFX15WjicDAA--.8804S2; Wed, 02 Dec 2015 11:01:25 +0800 (CST) Date: Wed, 2 Dec 2015 10:58:56 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201512021058557812287@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygBHqBEFX15WjicDAA--.8804S2 X-Coremail-Antispam: 1UD129KBjvJXoWxKr4fGrWfuF18uw17trW7CFg_yoW7ur1UpF ZxK3WkKFWkJrWxCwn2qry29r10vrykJrW7Xrn8Jr4xJrZ0gFy3tF1Iyr4ruFyUGrWfGr1j qF1Y9ay3A3Z8AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUyK hFDUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 02:59:02 -0000 SSBhZGQgdGhpcyBpbnRvICJyZWNlbnQgaXNzdWVzIGRpc2N1c3NlZCIuIEhlcmUgaXMgdGhlIGxh dGVzdCB2ZXJzaW9uOg0KIA0KMS4gVGhlIGRlc2lnbiB0YXJnZXRzIG9mIFdlYkRBViwgcnN5bmMg YW5kIG90aGVyIGV4aXN0aW5nIGFwcHJvYWNoZXM/DQoyLiBUaGUgcG90ZW50aWFsIHVzZSBjYXNl cyBvZiBJU1MsIHN1Y2ggYXMgY2xpZW50L3NlcnZlciwgZ2l0LWxpa2UgcGF0dGVybiwgc3ZuLCBl dGMuDQozLiBUaGUgZWZmaWNpZW5jeSBpbXByb3ZlbWVudHMgbWlnaHQgYmUgdGhlIHNlY29uZCBn b2FsIGZvciBzdGFuZGFyZGl6aW5nIElTUyBwcm90b2NvbA0KNC4gQ09SUyBoZWFkZXJzIG9uIHN0 b3JhZ2Ugc3luYyBBUElzDQo1LiBXaGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzogYSBzeW5jIHBy b3RvY29sIG9yIGEgZ2VuZXJhbGl6ZWQgQVBJDQo2LiBTb21lIHJlbGF0ZWQgb3JnYW5pemF0aW9u cywgZXZlbnRzLCBwcm9qZWN0cywgZXRjLjogR0VBTlQgY29tbXVuaXR5LCBPcGVuQ2xvdWRNZXNo LCBvd25DbG91ZCwgQ1MzLCByZW1vdGVTdG9yYWdlLCBDbGF3SU8NCg0KDQoNCi0tLS0tLS0tLS0t LS0tDQpGZWkgU29uZw0KPjIwMTUtMTEtMjYgMTE6MjggR01UKzA4OjAwIEZlaSBTb25nIDxmc29u Z0BianR1LmVkdS5jbj46DQo+DQo+PiBCVFcsIEJhc2VkIG9uIHRoZSBsYXN0IHNlbnRlbmNlIG9m IGxhc3QgZW1haWw6IlRoZSBpbnRlbnRpb24gb2YgdGhpcw0KPj4gbWVzc2FnZSBpcyB0byBpbnZl c3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMNCj4+IHB1 cnBvc2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIg d2UgbmVlZCBuZXcNCj4+IHByb3RvY29scyINCj4+DQo+PiBUaGUgb3V0Y29tZSBoZS9zaGUgd2Fu dGVkIG1pZ2h0IGJlIGp1c3QgdGhlIGxpbmtzIGxpa2UNCj4+IGh0dHA6Ly9jczMuZXRoei5jaC9w cm9ncmFtLmh0bWwgOikNCj4+DQo+SW4gYW5vdGhlciB3b3JkLCBJIHRoaW5rIHdoYXQgSSB3YW50 IGZpbmFsbHkgbWlnaHQgYmUgYSBkaXNjdXNzaW9uIGFib3V0DQo+IldoYXQgaXMgbmVlZGVkIGZv ciB0aGUgSVNTOiBhIHN5bmMgcHJvdG9jb2wgb3IgYSBnZW5lcmFsaXplZCBBUEkiLiBTb3JyeQ0K PmZvciB0aGUgcG9vciBleHByZXNzaW9uIDogKQ0KPg0KPlJlZ2FyZHMsDQo+TGluaHVpDQo+DQo+ Pg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tDQo+PiBGZWkgU29uZw0KPj4gPkhlbGxvLA0KPj4gPg0K Pj4gPldoYXQga2luZCBvZiBvdXRjb21lIGFyZSB5b3UgbG9va2luZyBmb3Igd2l0aCB0aGlzIGFu YWx5c2lzPyBTb21lDQo+PiByZXNlYXJjaCBpbiB0aGlzIGFyZWEgaGFzIGFscmVhZHkgYmVlbiBk b25lIG9yIGlzIGJlaW5nIGRvbmUgYXMgd2Ugc3BlYWsNCj4+ID4NCj4+ID5lLmcuICJBIHN0dWR5 IG9mIGRlbHRhLXN5bmMgYW5kIG90aGVyIG9wdGltaXNhdGlvbiBpbiBIVFRQL1dlYmRhdg0KPj4g c3luY2hvbmlzYXRpb24gcHJvdG9jb2xzIg0KPj4gPg0KPj4gPnNlZSAiVGVjaG5vbG9neSBhbmQg UmVzZWFyY2giOg0KPj4gPg0KPj4gPmh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwNCj4+ ID4NCj4+ID5JdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBzZWUgaWYgdGhlcmUgaXMgYSBwb3Rl bnRpYWwgZm9yIGNvbGxhYm9yYXRpb24uDQo+PiBPciBtYXliZSB3ZSBhbHJlYWR5IGhhdmUgc29t ZSBpbmZvcm1hdGlvbiB5b3UgYXJlIGxvb2tpbmcgZm9yLg0KPj4gPg0KPj4gPkJlc3QgcmVnYXJk cywNCj4+ID4NCj4+ID5KYWt1YiBNb3NjaWNraQ0KPj4gPg0KPj4gPqGqDQo+PiA+DQo+PiA+DQo+ PiA+T24gMjUgTm92IDIwMTUsIGF0IDExOjQ1LCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWls LmNvbTxtYWlsdG86DQo+PiBsaC5zdW5saW5oQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4gPg0KPj4g PkhpIGFsbCwNCj4+ID4NCj4+ID5BcyBJIG1lbnRpb25lZCBiZWZvcmUsIEkgdGhpbmsgdGhlIGRl dmVsb3BlcnMgY291bGQgYmVuZWZpdCBmcm9tIHRoZSBJRVRGDQo+PiBzdGFuZGFyZHMuIFRoZSBv d25DbG91ZCAoaHR0cHM6Ly9vd25jbG91ZC5vcmcvKSBpcyBqdXN0IGFuIGV4YW1wbGUuIEl0IGlz DQo+PiBkZXZlbG9wZWQgZm9yIHRob3NlIHdobyBkbyBub3QgdHJ1c3QgY29tbWVyY2lhbCBzdG9y YWdlIHNlcnZpY2VzIGFuZCB3YW50DQo+PiB0byBidWlsZCB0aGVpciBvd24gbmV0d29yay1iYXNl ZCBzdG9yYWdlIHNlcnZpY2VzLiBUaGUgb3duQ2xvdWQgaXMgdXNpbmcNCj4+IFdlYkRBViAoUkZD NDkxOCkgdG8gYWNoaWV2ZSB0aGUgZGF0YSBzeW5jLiBJTU8sIHRoZSBXZWJEQVYgaXMgZGVzaWdu ZWQgZm9yDQo+PiBkaXN0cmlidXRlZCB3b3JrIGJ1dCBub3QgZm9yIHRoZSBzeW5jLiBUaHVzLCBJ IG1hZGUgc29tZSBwcmVsaW1pbmFyeQ0KPj4gaW52ZXN0aWdhdGlvbnMgb24gaG93IHRoZSBvd25D bG91ZCB1c2VzIFdlYkRBViBmb3Igc3luYyBwdXJwb3Nlcy4gQSBicmllZg0KPj4gc3VtbWFyeSBv ZiB3aGF0IEkndmUgZm91bmQgaXMgaW4gdGhlIGZvbGxvd2luZywgcGxlYXNlIGNvcnJlY3QgbWUg aWYgSSBhbQ0KPj4gd3JvbmcuDQo+PiA+DQo+PiA+SSBpbnN0YWxsZWQgdGhlIG93bkNsb3VkIHNl cnZlciAodjguMi4xKSBvbiB0aGUgQ2VudE9TNywgYW5kIHRoZSBjbGllbnQNCj4+IGlzIGEgZGVz a3RvcCBjbGllbnQgb24gV2luZG93cy4NCj4+ID4NCj4+ID4xLiBUbyBmaW5kIHdoZXRoZXIgdGhl cmUgaXMgYSBjaGFuZ2UgdG8gdGhlIHN5bmNlZCBkaXJlY3RvcnksIHRoZSBjbGllbnQNCj4+IGNv bnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2VydmVyIGF0IHJlZ3VsYXIgaW50ZXJ2 YWxzIChhcm91bmQgMzQNCj4+IHNlY29uZHMgdW5kZXIgbXkgb2JzZXJ2YXRpb24pLiBUaGUgc2Vy dmVyIHdpbGwgcmVzcG9uZCBhIDIwNyBNdWx0aS1TdGF0dXMNCj4+IFJlc3BvbnNlIHRvIHRlbGwg d2hldGhlciB0aGUgbWFpbiBkaXJlY3RvcnkgaGFzIGJlZW4gY2hhbmdlZC4gVG8gcGVyZm9ybQ0K Pj4gdGhpcyByZWd1bGFyIGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29u bmVjdGlvbiB0byBzZW5kIHRoZQ0KPj4gUFJPUEZJTkQsIHRoZSBzZXJ2ZXIgd2lsbCBjbG9zZSB0 aGUgZXhpc3RpbmcgVENQIGNvbm5lY3Rpb24gYWZ0ZXINCj4+IHJlc3BvbmRpbmcgdGhlIDIwNyBN dWx0aS1TdGF0dXMgUmVzcG9uc2UuIEZvciB0aGUgbmV4dCBjaGVjaywgdGhlIGNsaWVudA0KPj4g d2lsbCBvcGVuIGFub3RoZXIgbmV3IFRDUCBjb25uZWN0aW9uLg0KPj4gPg0KPj4gPjIuIEV2ZXJ5 IHRpbWUgYWRkaW5nIChvciBjcmVhdGluZykgYSBuZXcgZmlsZSB0byB0aGUgbG9jYWwgZm9sZGVy LCB0aGUNCj4+IGNsaWVudCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gKGlmIHRoZXJl IGlzIG5vIGNvbm5lY3Rpb24gZXhpc3RpbmcpDQo+PiB0byBzZW5kIHRoZSBmaWxlIGFzYXAuIFRo ZSBjbGllbnQgd2lsbCBmaXJzdCBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQNCj4+IG91 dCB3aGljaCBzdWItZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQuIEFuZCB0aGVuIGl0IHNlbmRz IHRoZSBmaWxlIHVzaW5nDQo+PiBQVVQuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjAxIENy ZWF0ZWQgUmVzcG9uc2UgYW5kIHRoZW4gdGVybWluYXRlIHRoZQ0KPj4gY29ubmVjdGlvbi4gQ3Vy cmVudGx5LCBJIGhhdmVuJ3QgZm91bmQgYW55IGFwcGxpY2F0aW9uIGxheWVyIGNodW5raW5nLCBh bGwNCj4+IHRoZSBzZWdtZW50YXRpb24gYXJlIHBlcmZvcm1lZCBieSBUQ1AuDQo+PiA+DQo+PiA+ My4gRXZlcnkgdGltZSBJIGRlbGV0ZSAob3IgcmVuYW1lKSBhIGZpbGUgbG9jYWxseSwgdGhlIGNs aWVudCB3aWxsIGFsc28NCj4+IG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gdG8gc2VuZCBzZXZl cmFsIFBST1BGSU5EcyB0byBmaW5kIG91dCB3aGljaCBmaWxlDQo+PiBoYXMgYmVlbiByZW1vdmVk IChvciByZW5hbWVkKS4gVGhlbiBpdCB3aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4gVGhlDQo+ PiBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA0IE5vIENvbnRlbnQgUmVzcG9uc2UgKG9yIDIwMSBD cmVhdGVkIFJlc3BvbnNlKSBhbmQNCj4+IHRoZW4gdGVybWluYXRlIHRoZSBjb25uZWN0aW9uLg0K Pj4gPg0KPj4gPjQuIEkgb3BlbiBhIGZpbGUgYW5kIGZyZXF1ZW50bHkgZWRpdCBhbmQgc2F2ZSBp dCAoYWN0dWFsbHkgdGhpcyBpcyB3aGF0IEkNCj4+IHVzdWFsbHkgZG8gd2l0aCB0aGUgRHJvcGJv eCkuIFRoZSBjbGllbnQgd2lsbCBzZW5kIHRoZSB3aG9sZSBmaWxlIHRvIHRoZQ0KPj4gc2VydmVy IGV2ZXJ5IHRpbWUgSSBzYXZlIHRoZSBmaWxlLg0KPj4gPg0KPj4gPlRvIHN1bW1hcml6ZSwgaXQg c2VlbXMgdGhhdCB0aGUgb3duQ2xvdWQgbWFrZXMgaGVhdmlseSB1c2Ugb2YgUFJPUEZJTkQgdG8N Cj4+IGFjaGlldmUgdGhlIHN5bmMgcHJvY2Vzcy4gRWFjaCBzeW5jIG9wZXJhdGlvbiAoZS5nLiB1 cGxvYWQsIG1vZGlmeSBhbmQNCj4+IGV0Yy4pIHdpbGwgc3RhcnQgd2l0aCBzZW5kaW5nIG9uZSBv ciBtb3JlIFBST1BGSU5Ecy4gQW5kIGN1cnJlbnRseSwgaWYgSQ0KPj4gYWRkIGEgZmlsZSB0byB0 aGUgc2VydmVyIChkaXJlY3RseSBmcm9tIHRoZSBzZXJ2ZXIgc2lkZSB2aWEgd2ViIGludGVyZmFj ZSksDQo+PiB0aGUgY2xpZW50IGNhbm5vdCBmaW5kIHRoZSBjaGFuZ2UuIEkgbmVlZCB0byBpbnRl cnJ1cHQgdGhlIHN5bmMgYW5kIHJlY292ZXINCj4+IGl0IHRvIG1ha2UgdGhlIGNsaWVudCBiZSBh d2FyZSBvZiB0aGUgY2hhbmdlIGFuZCBkb3dubG9hZCB0aGUgbmV3bHkgYWRkZWQNCj4+IGZpbGUu IEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgY2F1c2VkIGJ5IHRoZSBzeW5jIG1lY2hhbmlz bSBvciBhbg0KPj4gaW1wcm9wZXIgc2VydmVyIGNvbmZpZ3VyYXRpb24uIEkgbmVlZCB0byBpbnZl c3RpZ2F0ZSB0aGlzIGZ1cnRoZXIgYW5kIGFsc28NCj4+IGhvdyB0aGUgb3duQ2xvdWQgd29ya3Mg Zm9yIG11bHRpcGxlIGNsaWVudHMgKG9yIGRldmljZXMpLg0KPj4gPg0KPj4gPkZvciBJU1MsIEkg dGhpbmsgb3duQ2xvdWQgaGFzIGRlbW9uc3RyYXRlZCB0byBzb21lIGV4dGVudCB0aGF0IHNpbWls YXINCj4+IElFVEYgcHJvdG9jb2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3llZC4gVGhl IGludGVudGlvbiBvZiB0aGlzDQo+PiBtZXNzYWdlIGlzIHRvIGludmVzdGlnYXRlIHRoZSBjdXJy ZW50IHN0YXRlIG9mIHVzaW5nIFdlYkRBViBmb3Igc3luYw0KPj4gcHVycG9zZXMgdG8gc2VlIHdo YXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldw0KPj4g cHJvdG9jb2xzLg0KPj4gPg0KPj4gPkNvbW1lbnRzIGFyZSB3ZWxjb21lIDogKQ0KPj4gPg0KPj4g PlJlZ2FyZHMsDQo+PiA+TGluaHVpDQo+PiA+DQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5TdG9yYWdlc3luYyBtYWlsaW5nIGxp c3QNCj4+ID5TdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+ DQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0K Pj4gPg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+DQo+ From nobody Tue Dec 1 19:00:23 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434EC1B2BEC for ; Tue, 1 Dec 2015 19:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8je7fYjhi7h for ; Tue, 1 Dec 2015 19:00:20 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 250D31B2BDF for ; Tue, 1 Dec 2015 19:00:19 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygBHxAZgX15W7CgDAA--.9875S2; Wed, 02 Dec 2015 11:02:56 +0800 (CST) Date: Wed, 2 Dec 2015 11:00:20 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201512021100204377288@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygBHxAZgX15W7CgDAA--.9875S2 X-Coremail-Antispam: 1UD129KBjvJXoWxKr4fGrWfuF18uw17trW7CFg_yoW7ur1UpF ZxK3WkKFWkJrWxCwn2qry29r10vrykJrW7Xrn8Jr4xJrZ0gFy3tF1Iyr4ruFyUGrWfGr1j qF1Y9ay3A3Z8AFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkKb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv 6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU5APED UUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 03:00:22 -0000 SSBhZGQgdGhpcyBpbnRvICJyZWNlbnQgaXNzdWVzIGRpc2N1c3NlZCIuIEhlcmUgaXMgdGhlIGxh dGVzdCB2ZXJzaW9uOg0KIA0KMS4gVGhlIGRlc2lnbiB0YXJnZXRzIG9mIFdlYkRBViwgcnN5bmMg YW5kIG90aGVyIGV4aXN0aW5nIGFwcHJvYWNoZXM/DQoyLiBUaGUgcG90ZW50aWFsIHVzZSBjYXNl cyBvZiBJU1MsIHN1Y2ggYXMgY2xpZW50L3NlcnZlciwgZ2l0LWxpa2UgcGF0dGVybiwgc3ZuLCBl dGMuDQozLiBUaGUgZWZmaWNpZW5jeSBpbXByb3ZlbWVudHMgbWlnaHQgYmUgdGhlIHNlY29uZCBn b2FsIGZvciBzdGFuZGFyZGl6aW5nIElTUyBwcm90b2NvbA0KNC4gQ09SUyBoZWFkZXJzIG9uIHN0 b3JhZ2Ugc3luYyBBUElzDQo1LiBXaGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzogYSBzeW5jIHBy b3RvY29sIG9yIGEgZ2VuZXJhbGl6ZWQgQVBJDQo2LiBTb21lIHJlbGF0ZWQgb3JnYW5pemF0aW9u cywgZXZlbnRzLCBwcm9qZWN0cywgZXRjLjogR0VBTlQgY29tbXVuaXR5LCBPcGVuQ2xvdWRNZXNo LCBvd25DbG91ZCwgQ1MzLCByZW1vdGVTdG9yYWdlLCBDbGF3SU8NCg0KDQoNCi0tLS0tLS0tLS0t LS0tDQpGZWkgU29uZw0KPjIwMTUtMTEtMjYgMTE6MjggR01UKzA4OjAwIEZlaSBTb25nIDxmc29u Z0BianR1LmVkdS5jbj46DQo+DQo+PiBCVFcsIEJhc2VkIG9uIHRoZSBsYXN0IHNlbnRlbmNlIG9m IGxhc3QgZW1haWw6IlRoZSBpbnRlbnRpb24gb2YgdGhpcw0KPj4gbWVzc2FnZSBpcyB0byBpbnZl c3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMNCj4+IHB1 cnBvc2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIg d2UgbmVlZCBuZXcNCj4+IHByb3RvY29scyINCj4+DQo+PiBUaGUgb3V0Y29tZSBoZS9zaGUgd2Fu dGVkIG1pZ2h0IGJlIGp1c3QgdGhlIGxpbmtzIGxpa2UNCj4+IGh0dHA6Ly9jczMuZXRoei5jaC9w cm9ncmFtLmh0bWwgOikNCj4+DQo+SW4gYW5vdGhlciB3b3JkLCBJIHRoaW5rIHdoYXQgSSB3YW50 IGZpbmFsbHkgbWlnaHQgYmUgYSBkaXNjdXNzaW9uIGFib3V0DQo+IldoYXQgaXMgbmVlZGVkIGZv ciB0aGUgSVNTOiBhIHN5bmMgcHJvdG9jb2wgb3IgYSBnZW5lcmFsaXplZCBBUEkiLiBTb3JyeQ0K PmZvciB0aGUgcG9vciBleHByZXNzaW9uIDogKQ0KPg0KPlJlZ2FyZHMsDQo+TGluaHVpDQo+DQo+ Pg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tDQo+PiBGZWkgU29uZw0KPj4gPkhlbGxvLA0KPj4gPg0K Pj4gPldoYXQga2luZCBvZiBvdXRjb21lIGFyZSB5b3UgbG9va2luZyBmb3Igd2l0aCB0aGlzIGFu YWx5c2lzPyBTb21lDQo+PiByZXNlYXJjaCBpbiB0aGlzIGFyZWEgaGFzIGFscmVhZHkgYmVlbiBk b25lIG9yIGlzIGJlaW5nIGRvbmUgYXMgd2Ugc3BlYWsNCj4+ID4NCj4+ID5lLmcuICJBIHN0dWR5 IG9mIGRlbHRhLXN5bmMgYW5kIG90aGVyIG9wdGltaXNhdGlvbiBpbiBIVFRQL1dlYmRhdg0KPj4g c3luY2hvbmlzYXRpb24gcHJvdG9jb2xzIg0KPj4gPg0KPj4gPnNlZSAiVGVjaG5vbG9neSBhbmQg UmVzZWFyY2giOg0KPj4gPg0KPj4gPmh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwNCj4+ ID4NCj4+ID5JdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBzZWUgaWYgdGhlcmUgaXMgYSBwb3Rl bnRpYWwgZm9yIGNvbGxhYm9yYXRpb24uDQo+PiBPciBtYXliZSB3ZSBhbHJlYWR5IGhhdmUgc29t ZSBpbmZvcm1hdGlvbiB5b3UgYXJlIGxvb2tpbmcgZm9yLg0KPj4gPg0KPj4gPkJlc3QgcmVnYXJk cywNCj4+ID4NCj4+ID5KYWt1YiBNb3NjaWNraQ0KPj4gPg0KPj4gPqGqDQo+PiA+DQo+PiA+DQo+ PiA+T24gMjUgTm92IDIwMTUsIGF0IDExOjQ1LCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWls LmNvbTxtYWlsdG86DQo+PiBsaC5zdW5saW5oQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4gPg0KPj4g PkhpIGFsbCwNCj4+ID4NCj4+ID5BcyBJIG1lbnRpb25lZCBiZWZvcmUsIEkgdGhpbmsgdGhlIGRl dmVsb3BlcnMgY291bGQgYmVuZWZpdCBmcm9tIHRoZSBJRVRGDQo+PiBzdGFuZGFyZHMuIFRoZSBv d25DbG91ZCAoaHR0cHM6Ly9vd25jbG91ZC5vcmcvKSBpcyBqdXN0IGFuIGV4YW1wbGUuIEl0IGlz DQo+PiBkZXZlbG9wZWQgZm9yIHRob3NlIHdobyBkbyBub3QgdHJ1c3QgY29tbWVyY2lhbCBzdG9y YWdlIHNlcnZpY2VzIGFuZCB3YW50DQo+PiB0byBidWlsZCB0aGVpciBvd24gbmV0d29yay1iYXNl ZCBzdG9yYWdlIHNlcnZpY2VzLiBUaGUgb3duQ2xvdWQgaXMgdXNpbmcNCj4+IFdlYkRBViAoUkZD NDkxOCkgdG8gYWNoaWV2ZSB0aGUgZGF0YSBzeW5jLiBJTU8sIHRoZSBXZWJEQVYgaXMgZGVzaWdu ZWQgZm9yDQo+PiBkaXN0cmlidXRlZCB3b3JrIGJ1dCBub3QgZm9yIHRoZSBzeW5jLiBUaHVzLCBJ IG1hZGUgc29tZSBwcmVsaW1pbmFyeQ0KPj4gaW52ZXN0aWdhdGlvbnMgb24gaG93IHRoZSBvd25D bG91ZCB1c2VzIFdlYkRBViBmb3Igc3luYyBwdXJwb3Nlcy4gQSBicmllZg0KPj4gc3VtbWFyeSBv ZiB3aGF0IEkndmUgZm91bmQgaXMgaW4gdGhlIGZvbGxvd2luZywgcGxlYXNlIGNvcnJlY3QgbWUg aWYgSSBhbQ0KPj4gd3JvbmcuDQo+PiA+DQo+PiA+SSBpbnN0YWxsZWQgdGhlIG93bkNsb3VkIHNl cnZlciAodjguMi4xKSBvbiB0aGUgQ2VudE9TNywgYW5kIHRoZSBjbGllbnQNCj4+IGlzIGEgZGVz a3RvcCBjbGllbnQgb24gV2luZG93cy4NCj4+ID4NCj4+ID4xLiBUbyBmaW5kIHdoZXRoZXIgdGhl cmUgaXMgYSBjaGFuZ2UgdG8gdGhlIHN5bmNlZCBkaXJlY3RvcnksIHRoZSBjbGllbnQNCj4+IGNv bnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2VydmVyIGF0IHJlZ3VsYXIgaW50ZXJ2 YWxzIChhcm91bmQgMzQNCj4+IHNlY29uZHMgdW5kZXIgbXkgb2JzZXJ2YXRpb24pLiBUaGUgc2Vy dmVyIHdpbGwgcmVzcG9uZCBhIDIwNyBNdWx0aS1TdGF0dXMNCj4+IFJlc3BvbnNlIHRvIHRlbGwg d2hldGhlciB0aGUgbWFpbiBkaXJlY3RvcnkgaGFzIGJlZW4gY2hhbmdlZC4gVG8gcGVyZm9ybQ0K Pj4gdGhpcyByZWd1bGFyIGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29u bmVjdGlvbiB0byBzZW5kIHRoZQ0KPj4gUFJPUEZJTkQsIHRoZSBzZXJ2ZXIgd2lsbCBjbG9zZSB0 aGUgZXhpc3RpbmcgVENQIGNvbm5lY3Rpb24gYWZ0ZXINCj4+IHJlc3BvbmRpbmcgdGhlIDIwNyBN dWx0aS1TdGF0dXMgUmVzcG9uc2UuIEZvciB0aGUgbmV4dCBjaGVjaywgdGhlIGNsaWVudA0KPj4g d2lsbCBvcGVuIGFub3RoZXIgbmV3IFRDUCBjb25uZWN0aW9uLg0KPj4gPg0KPj4gPjIuIEV2ZXJ5 IHRpbWUgYWRkaW5nIChvciBjcmVhdGluZykgYSBuZXcgZmlsZSB0byB0aGUgbG9jYWwgZm9sZGVy LCB0aGUNCj4+IGNsaWVudCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gKGlmIHRoZXJl IGlzIG5vIGNvbm5lY3Rpb24gZXhpc3RpbmcpDQo+PiB0byBzZW5kIHRoZSBmaWxlIGFzYXAuIFRo ZSBjbGllbnQgd2lsbCBmaXJzdCBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQNCj4+IG91 dCB3aGljaCBzdWItZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQuIEFuZCB0aGVuIGl0IHNlbmRz IHRoZSBmaWxlIHVzaW5nDQo+PiBQVVQuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjAxIENy ZWF0ZWQgUmVzcG9uc2UgYW5kIHRoZW4gdGVybWluYXRlIHRoZQ0KPj4gY29ubmVjdGlvbi4gQ3Vy cmVudGx5LCBJIGhhdmVuJ3QgZm91bmQgYW55IGFwcGxpY2F0aW9uIGxheWVyIGNodW5raW5nLCBh bGwNCj4+IHRoZSBzZWdtZW50YXRpb24gYXJlIHBlcmZvcm1lZCBieSBUQ1AuDQo+PiA+DQo+PiA+ My4gRXZlcnkgdGltZSBJIGRlbGV0ZSAob3IgcmVuYW1lKSBhIGZpbGUgbG9jYWxseSwgdGhlIGNs aWVudCB3aWxsIGFsc28NCj4+IG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gdG8gc2VuZCBzZXZl cmFsIFBST1BGSU5EcyB0byBmaW5kIG91dCB3aGljaCBmaWxlDQo+PiBoYXMgYmVlbiByZW1vdmVk IChvciByZW5hbWVkKS4gVGhlbiBpdCB3aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4gVGhlDQo+ PiBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA0IE5vIENvbnRlbnQgUmVzcG9uc2UgKG9yIDIwMSBD cmVhdGVkIFJlc3BvbnNlKSBhbmQNCj4+IHRoZW4gdGVybWluYXRlIHRoZSBjb25uZWN0aW9uLg0K Pj4gPg0KPj4gPjQuIEkgb3BlbiBhIGZpbGUgYW5kIGZyZXF1ZW50bHkgZWRpdCBhbmQgc2F2ZSBp dCAoYWN0dWFsbHkgdGhpcyBpcyB3aGF0IEkNCj4+IHVzdWFsbHkgZG8gd2l0aCB0aGUgRHJvcGJv eCkuIFRoZSBjbGllbnQgd2lsbCBzZW5kIHRoZSB3aG9sZSBmaWxlIHRvIHRoZQ0KPj4gc2VydmVy IGV2ZXJ5IHRpbWUgSSBzYXZlIHRoZSBmaWxlLg0KPj4gPg0KPj4gPlRvIHN1bW1hcml6ZSwgaXQg c2VlbXMgdGhhdCB0aGUgb3duQ2xvdWQgbWFrZXMgaGVhdmlseSB1c2Ugb2YgUFJPUEZJTkQgdG8N Cj4+IGFjaGlldmUgdGhlIHN5bmMgcHJvY2Vzcy4gRWFjaCBzeW5jIG9wZXJhdGlvbiAoZS5nLiB1 cGxvYWQsIG1vZGlmeSBhbmQNCj4+IGV0Yy4pIHdpbGwgc3RhcnQgd2l0aCBzZW5kaW5nIG9uZSBv ciBtb3JlIFBST1BGSU5Ecy4gQW5kIGN1cnJlbnRseSwgaWYgSQ0KPj4gYWRkIGEgZmlsZSB0byB0 aGUgc2VydmVyIChkaXJlY3RseSBmcm9tIHRoZSBzZXJ2ZXIgc2lkZSB2aWEgd2ViIGludGVyZmFj ZSksDQo+PiB0aGUgY2xpZW50IGNhbm5vdCBmaW5kIHRoZSBjaGFuZ2UuIEkgbmVlZCB0byBpbnRl cnJ1cHQgdGhlIHN5bmMgYW5kIHJlY292ZXINCj4+IGl0IHRvIG1ha2UgdGhlIGNsaWVudCBiZSBh d2FyZSBvZiB0aGUgY2hhbmdlIGFuZCBkb3dubG9hZCB0aGUgbmV3bHkgYWRkZWQNCj4+IGZpbGUu IEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgY2F1c2VkIGJ5IHRoZSBzeW5jIG1lY2hhbmlz bSBvciBhbg0KPj4gaW1wcm9wZXIgc2VydmVyIGNvbmZpZ3VyYXRpb24uIEkgbmVlZCB0byBpbnZl c3RpZ2F0ZSB0aGlzIGZ1cnRoZXIgYW5kIGFsc28NCj4+IGhvdyB0aGUgb3duQ2xvdWQgd29ya3Mg Zm9yIG11bHRpcGxlIGNsaWVudHMgKG9yIGRldmljZXMpLg0KPj4gPg0KPj4gPkZvciBJU1MsIEkg dGhpbmsgb3duQ2xvdWQgaGFzIGRlbW9uc3RyYXRlZCB0byBzb21lIGV4dGVudCB0aGF0IHNpbWls YXINCj4+IElFVEYgcHJvdG9jb2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3llZC4gVGhl IGludGVudGlvbiBvZiB0aGlzDQo+PiBtZXNzYWdlIGlzIHRvIGludmVzdGlnYXRlIHRoZSBjdXJy ZW50IHN0YXRlIG9mIHVzaW5nIFdlYkRBViBmb3Igc3luYw0KPj4gcHVycG9zZXMgdG8gc2VlIHdo YXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldw0KPj4g cHJvdG9jb2xzLg0KPj4gPg0KPj4gPkNvbW1lbnRzIGFyZSB3ZWxjb21lIDogKQ0KPj4gPg0KPj4g PlJlZ2FyZHMsDQo+PiA+TGluaHVpDQo+PiA+DQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5TdG9yYWdlc3luYyBtYWlsaW5nIGxp c3QNCj4+ID5TdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+ DQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0K Pj4gPg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+DQo+ From nobody Tue Dec 1 19:07:27 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8DD1B31D3 for ; Tue, 1 Dec 2015 19:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc3YIuiPI14i for ; Tue, 1 Dec 2015 19:07:23 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 35D571B31D2 for ; Tue, 1 Dec 2015 19:07:22 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygC33wT_YF5WVSsDAA--.4052S2; Wed, 02 Dec 2015 11:09:51 +0800 (CST) Date: Wed, 2 Dec 2015 11:07:15 +0800 From: "Fei Song" To: "Jakub Moscicki" References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <03A07C3E-9B3B-4886-9131-2CAF0A7B3F85@cern.ch>, <9A7E1A04-8C4A-40BE-933D-6814ACDB135C@cern.ch> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201512021107151258829@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygC33wT_YF5WVSsDAA--.4052S2 X-Coremail-Antispam: 1UD129KBjvJXoW3JF48ArW3urykCrWfCr4DJwb_yoW3tr47pF 43K3W8KFykJr4xCwn7tr1I9r10vFWkJrW3Jrn8JryxArZ8WFyIqFyxtr4ruFy7GrZ3Gr1j qr4F9FZxC3Z8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1Y6r17McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUyL FxUUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync Subject: Re: [Storagesync] Some preliminary investigations on ownCloud X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 03:07:25 -0000 SGkgSmFrdWIsDQoNCkkgbm90aWNlIHRoYXQgdGhpcyBpcyBhICJTcGVjaWFsIFNlY3Rpb24iLCAN CmFueSBkZWFkbGluZSBmb3IgaXQ/IG9yIGl0IHdpbGwgYmUgYXZhaWxhYmxlIGZvciBhIGxvbmcg dGltZT8NCg0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5CVFcsIGhlcmUgaXMgdGhlIHB1 YmxpYyBDRlAgZm9yIEZHQ1M6IGh0dHA6Ly9jczMuZXRoei5jaC9wdWJsaWNhdGlvbnMuaHRtbA0K Pg0KPkJlc3QgcmVnYXJkcywNCj4NCj5KYWt1YiBNb3NjaWNraQ0KPg0KPqGqDQo+DQo+T24gMjYg Tm92IDIwMTUsIGF0IDA0OjI5LCBKYWt1YiBNb3NjaWNraSA8SmFrdWIuTW9zY2lja2lAY2Vybi5j aDxtYWlsdG86SmFrdWIuTW9zY2lja2lAY2Vybi5jaD4+IHdyb3RlOg0KPg0KPjIwMTUtMTEtMjYg MTE6MjggR01UKzA4OjAwIEZlaSBTb25nIDxmc29uZ0BianR1LmVkdS5jbjxtYWlsdG86ZnNvbmdA Ymp0dS5lZHUuY24+PjoNCj5CVFcsIEJhc2VkIG9uIHRoZSBsYXN0IHNlbnRlbmNlIG9mIGxhc3Qg ZW1haWw6IlRoZSBpbnRlbnRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHRvIGludmVzdGlnYXRlIHRo ZSBjdXJyZW50IHN0YXRlIG9mIHVzaW5nIFdlYkRBViBmb3Igc3luYyBwdXJwb3NlcyB0byBzZWUg d2hhdCBuZWVkcyB0byBiZSBpbXByb3ZlZCBoZXJlIGFuZCB3aGV0aGVyIHdlIG5lZWQgbmV3IHBy b3RvY29scyINCj4NCj5UaGUgb3V0Y29tZSBoZS9zaGUgd2FudGVkIG1pZ2h0IGJlIGp1c3QgdGhl IGxpbmtzIGxpa2UgaHR0cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbCA6KQ0KPkluIGFub3Ro ZXIgd29yZCwgSSB0aGluayB3aGF0IEkgd2FudCBmaW5hbGx5IG1pZ2h0IGJlIGEgZGlzY3Vzc2lv biBhYm91dCAiV2hhdCBpcyBuZWVkZWQgZm9yIHRoZSBJU1M6IGEgc3luYyBwcm90b2NvbCBvciBh IGdlbmVyYWxpemVkIEFQSSIuIFNvcnJ5IGZvciB0aGUgcG9vciBleHByZXNzaW9uIDogKQ0KPg0K PkkgdGhpbmsgdGhpcyBpcyBhIHJlbGV2YW50IHF1ZXN0aW9uIGluZGVlZCAod2VsbCwgYWN0dWFs bHkgYWxzbyBpZiB0aGVyZSBpcyBhbnkgc3RhbmRhcmQgbmVlZGVkIGF0IGFsbCBpbiB0aGUgZmly c3QgcGxhY2UpLiBCeSB0aGUgZ2VuZXJhbGl6ZWQgQVBJIGRvIHlvdSBtZWFuIGEgSFRUUC1zdHls ZSBBUEkgKGxpa2UgUkVTVCk/IEluIHRoYXQgY2FzZSB5b3UgbWF5IGNvbnNpZGVyIFdlYkRBViBx dWl0ZSBjbG9zZSBhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgcHJvdG9jb2wgYW5kIHRo ZSBBUEkgYmx1cnMgZm9yIHByYWN0aWNhbCBwdXJwb3Nlcy4NCj4NCj5XaGlsZSBJIGFncmVlIHRo YXQgV2ViREFWIG1heSBoYXZlIGRpc2FkdmFudGFnZXMgdGhlcmUgaXMgYSBnb29kIG51bWJlciBv ZiBpbnN0YWxsYXRpb25zIHVzaW5nIHRoaXMgYWxyZWFkeSBpbiBvdXIgY29tbXVuaXR5IChyZXNl YXJjaCBsYWJzIG1haW5seSBpbiwgYnV0IG5vdCBsaW1pdGVkIHRvLCBFdXJvcGUpLiBJIHRoaW5r IHRoZSBpbnRlcmVzdGluZyBwb2ludCBhYm91dCBXZWJEQVYvSFRUUCBpcyBleHRlbnNpYmlsaXR5 IGFuZCBtYXliZSBpdCBpcyB3b3J0aCBpcyB0aGF0IHRoZXNlIGV4dGVuc2lvbnMgZ28gYnkgYSCh sHN0YW5kYXJkobEuIEhvd2V2ZXIsIHlvdSBzaG91bGQgY29uc2lkZXIgdGhhdCBmb3IgcmVhc29u YWJseSBlZmZpY2llbnQgc3luYyBzY2VuYXJpbyB0aGUgc2VydmVyIHNob3VsZCBhbHNvIGV4aGli aXQgY2VydGFpbiBiZWhhdmlvdXIuIFRoYXQgaXMsIGluIGNhc2Ugb2Ygb3duY2xvdWQgZm9yIGV4 YW1wbGUsIGEgc2VydmVyIHNob3VsZCBiZSBhYmxlIHRvIGVmZmljaWVudGx5IHByb3BhZ2F0ZSB0 aGUgRVRBRyBjaGFuZ2VzIHVwIHRoZSBkaXJlY3RvcnkgdHJlZSAobGlrZSB0aGUgTWVya2xlIFRy ZWUpIHNvIHRoYXQgdGhlIGNsaWVudCBtYXkgdXNlIHByb3BmaW5kIGVmZmljaWVudGx5LiBUaGlz IGlzIG5vdCBhIGhhcmQgc3BlYyByZXF1aXJlbWVudCBidXQgb3RoZXJ3aXNlIHByb3BmaW5kaW5n IHRoZSBlbnRpcmUgcmVtb3RlIHRyZWUgZWFjaCB0aW1lIHdvdWxkIGJlIGltcHJhY3RpY2FsbHkg aW5lZmZpY2llbnQuIFNvIHRoaXMgcmVhbGx5IGdvZXMgYSBsaXR0bGUgYml0IGJleW9uZCBqdXN0 IGFuIEFQSS4NCj4NCj5Zb3Ugc2hvdWxkIGFsc28gY29uc2lkZXIgdGhhdCB0aGUgT3BlbkNsb3Vk TWVzaCAodW5kZXIgR0VBTlQgdW1icmVsbGEpIGlzIGFuIGluaXRpYXRpdmUgd2l0aCB0aGUgaW50 ZW50IGlzIHRvIG1ha2UgY3Jvc3Mtc2VydmljZSBzaGFyaW5nIHZlcnkgZWFzeS4gVGhlc2Ugc2hh cmVzIG1heSBhbHNvIGJlIHN5bmNocm9uaXplZCBhdXRvbWF0aWNhbGx5LiBJIGN1cnJlbnRseSBo YXZlIG5vIGV2aWRlbmNlLCBob3dldmVyLCB0aGF0IG90aGVyIHNvZnR3YXJlIHByb3ZpZGVycyB3 aXRoIHRoZSBleGNlcHRpb24gb2Ygb3duY2xvdWQgYXJlIGludGVyZXN0ZWQgaW4gZGV2ZWxvcGlu ZyBzdWNoIHN0YW5kYXJkLiBJZiB0aGVyZSBpcyBubyBib3R0b20gdXAgaW50ZXJlc3QgZnJvbSB0 aGUgdXNlcnMgdGhlbiBpdCB3b26hr3QgaGFwcGVuIChpbiBteSBvcGluaW9uKS4NCj4NCj5XaXRo IHRoZSBsaW5rIEkgd2FudGVkIHRvIHBvaW50IHlvdSB0byB0aGUgZmFjdCB0aGF0IHdoYXQgeW91 IGRpc2N1c3MgaW4gdGhpcyBtYWlsaW5nIGxpc3Qgd2lsbCBiZSBhbHNvIGRpc2N1c3NlZCBhdCB0 aGUgdXBjb21pbmcgQ1MzIGV2ZW50IEkgbGlua2VkIGluLiBUaGUgaW50ZW50IGlzIHRvIGRvIHRo aXMgZGlzY3Vzc2luZyB0b2dldGhlciBiZXR3ZWVuIHNlcnZpY2UgcHJvdmlkZXJzLCBkZXZlbG9w ZXJzIGFuZCByZXNlYXJjaGVycyB0b2dldGhlciChqiBzbyB0aGF0IGl0IGRvZXMgbm90IG9ubHkg ZW5kIHVwIGFzIGFuIGFjYWRlbWljIGV4ZXJjaXNlIGJ1dCBiYWNrZWQgdXAgYnkgYSBjcml0aWNh bCBtYXNzIGlmIHRoZXJlIGlzIHNvbWUgcG90ZW50aWFsIGluIHN0YW5kYXJkaXNhdGlvbiwgYXQg bGVhc3QgaW4gb3VyIGNvbW11bml0eS4gSSBob3BlIHRoaXMgY291bGQgYmUgb2YgaW50ZXJlc3Qg dG8gSUVURiBjb21tdW5pdHksIGFzIG1lbnRpb25lZCBvbiB0aGUgcHJvZ3JhbSBwYWdlLg0KPg0K PlNlbGVjdGVkIHBhcGVycyB3aWxsIGJlIHB1Ymxpc2hlZCBpbiBGR0NTIGFmdGVyIHRoZSBldmVu dCwgc28gcGxlYXNlIHN0YW5kIGJ5LCBvciBhdHRlbmQgdGhlIGV2ZW50IGlmIHlvdSB3YW50IHRv IGJlIHBhcnQgb2YgdGhpcyBkaXNjdXNzaW9uIGhlcmUuIEJUVy4gdGhlIGFic3RyYWN0IHN1Ym1p c3Npb24gZGVhZGxpbmUgaXMgcGFzdCBidXQgb25lIGV4Y2VwdGlvbmFsbHkgZ29vZCBjb250cmli dXRpb24gY291bGQgc3RpbGwgcG9zc2libHkgYmUgYWNjb21tb2RhdGVkIGlmIHN1Ym1pdHRlZCBy YXBpZGx5Lg0KPg0KPkkgd291bGQgYmUgbm9uZXRoZWxlc3MgaGFwcHkgdG8gY29udGludWUgY29u dHJpYnV0aW5nIHRvIHRoZSBkaXNjdXNzaW9uIGluIHRoaXMgbWFpbGluZyBsaXN0Lg0KPg0KPkJl c3QgcmVnYXJkcywNCj4NCj5KYWt1YiBNb3NjaWNraQ0KPg0KPi0tDQo+DQo+DQo+UmVnYXJkcywN Cj5MaW5odWkNCj4NCj4NCj4tLS0tLS0tLS0tLS0tLQ0KPkZlaSBTb25nDQo+PkhlbGxvLA0KPj4N Cj4+V2hhdCBraW5kIG9mIG91dGNvbWUgYXJlIHlvdSBsb29raW5nIGZvciB3aXRoIHRoaXMgYW5h bHlzaXM/IFNvbWUgcmVzZWFyY2ggaW4gdGhpcyBhcmVhIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBv ciBpcyBiZWluZyBkb25lIGFzIHdlIHNwZWFrDQo+Pg0KPj5lLmcuICJBIHN0dWR5IG9mIGRlbHRh LXN5bmMgYW5kIG90aGVyIG9wdGltaXNhdGlvbiBpbiBIVFRQL1dlYmRhdiBzeW5jaG9uaXNhdGlv biBwcm90b2NvbHMiDQo+Pg0KPj5zZWUgIlRlY2hub2xvZ3kgYW5kIFJlc2VhcmNoIjoNCj4+DQo+ Pmh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwNCj4+DQo+Pkl0IHdvdWxkIGJlIGludGVy ZXN0aW5nIHRvIHNlZSBpZiB0aGVyZSBpcyBhIHBvdGVudGlhbCBmb3IgY29sbGFib3JhdGlvbi4g T3IgbWF5YmUgd2UgYWxyZWFkeSBoYXZlIHNvbWUgaW5mb3JtYXRpb24geW91IGFyZSBsb29raW5n IGZvci4NCj4+DQo+PkJlc3QgcmVnYXJkcywNCj4+DQo+Pkpha3ViIE1vc2NpY2tpDQo+Pg0KPj6h qg0KPj4NCj4+DQo+Pk9uIDI1IE5vdiAyMDE1LCBhdCAxMTo0NSwgTGluaHVpIFN1biA8bGguc3Vu bGluaEBnbWFpbC5jb208bWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tPjxtYWlsdG86bGguc3Vu bGluaEBnbWFpbC5jb208bWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tPj4+IHdyb3RlOg0KPj4N Cj4+SGkgYWxsLA0KPj4NCj4+QXMgSSBtZW50aW9uZWQgYmVmb3JlLCBJIHRoaW5rIHRoZSBkZXZl bG9wZXJzIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgSUVURiBzdGFuZGFyZHMuIFRoZSBvd25DbG91 ZCAoaHR0cHM6Ly9vd25jbG91ZC5vcmcvKSBpcyBqdXN0IGFuIGV4YW1wbGUuIEl0IGlzIGRldmVs b3BlZCBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB0cnVzdCBjb21tZXJjaWFsIHN0b3JhZ2Ugc2Vydmlj ZXMgYW5kIHdhbnQgdG8gYnVpbGQgdGhlaXIgb3duIG5ldHdvcmstYmFzZWQgc3RvcmFnZSBzZXJ2 aWNlcy4gVGhlIG93bkNsb3VkIGlzIHVzaW5nIFdlYkRBViAoUkZDNDkxOCkgdG8gYWNoaWV2ZSB0 aGUgZGF0YSBzeW5jLiBJTU8sIHRoZSBXZWJEQVYgaXMgZGVzaWduZWQgZm9yIGRpc3RyaWJ1dGVk IHdvcmsgYnV0IG5vdCBmb3IgdGhlIHN5bmMuIFRodXMsIEkgbWFkZSBzb21lIHByZWxpbWluYXJ5 IGludmVzdGlnYXRpb25zIG9uIGhvdyB0aGUgb3duQ2xvdWQgdXNlcyBXZWJEQVYgZm9yIHN5bmMg cHVycG9zZXMuIEEgYnJpZWYgc3VtbWFyeSBvZiB3aGF0IEkndmUgZm91bmQgaXMgaW4gdGhlIGZv bGxvd2luZywgcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy4NCj4+DQo+PkkgaW5zdGFs bGVkIHRoZSBvd25DbG91ZCBzZXJ2ZXIgKHY4LjIuMSkgb24gdGhlIENlbnRPUzcsIGFuZCB0aGUg Y2xpZW50IGlzIGEgZGVza3RvcCBjbGllbnQgb24gV2luZG93cy4NCj4+DQo+PjEuIFRvIGZpbmQg d2hldGhlciB0aGVyZSBpcyBhIGNoYW5nZSB0byB0aGUgc3luY2VkIGRpcmVjdG9yeSwgdGhlIGNs aWVudCBjb250aW51b3VzbHkgc2VuZHMgUFJPUEZJTkQgdG8gdGhlIHNlcnZlciBhdCByZWd1bGFy IGludGVydmFscyAoYXJvdW5kIDM0IHNlY29uZHMgdW5kZXIgbXkgb2JzZXJ2YXRpb24pLiBUaGUg c2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwNyBNdWx0aS1TdGF0dXMgUmVzcG9uc2UgdG8gdGVsbCB3 aGV0aGVyIHRoZSBtYWluIGRpcmVjdG9yeSBoYXMgYmVlbiBjaGFuZ2VkLiBUbyBwZXJmb3JtIHRo aXMgcmVndWxhciBjaGVjaywgdGhlIGNsaWVudCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rp b24gdG8gc2VuZCB0aGUgUFJPUEZJTkQsIHRoZSBzZXJ2ZXIgd2lsbCBjbG9zZSB0aGUgZXhpc3Rp bmcgVENQIGNvbm5lY3Rpb24gYWZ0ZXIgcmVzcG9uZGluZyB0aGUgMjA3IE11bHRpLVN0YXR1cyBS ZXNwb25zZS4gRm9yIHRoZSBuZXh0IGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhbm90aGVy IG5ldyBUQ1AgY29ubmVjdGlvbi4NCj4+DQo+PjIuIEV2ZXJ5IHRpbWUgYWRkaW5nIChvciBjcmVh dGluZykgYSBuZXcgZmlsZSB0byB0aGUgbG9jYWwgZm9sZGVyLCB0aGUgY2xpZW50IHdpbGwgb3Bl biBhIG5ldyBUQ1AgY29ubmVjdGlvbiAoaWYgdGhlcmUgaXMgbm8gY29ubmVjdGlvbiBleGlzdGlu ZykgdG8gc2VuZCB0aGUgZmlsZSBhc2FwLiBUaGUgY2xpZW50IHdpbGwgZmlyc3Qgc2VuZCBzZXZl cmFsIFBST1BGSU5EcyB0byBmaW5kIG91dCB3aGljaCBzdWItZGlyZWN0b3J5IGhhcyBiZWVuIGNo YW5nZWQuIEFuZCB0aGVuIGl0IHNlbmRzIHRoZSBmaWxlIHVzaW5nIFBVVC4gVGhlIHNlcnZlciB3 aWxsIHJlc3BvbmQgYSAyMDEgQ3JlYXRlZCBSZXNwb25zZSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhl IGNvbm5lY3Rpb24uIEN1cnJlbnRseSwgSSBoYXZlbid0IGZvdW5kIGFueSBhcHBsaWNhdGlvbiBs YXllciBjaHVua2luZywgYWxsIHRoZSBzZWdtZW50YXRpb24gYXJlIHBlcmZvcm1lZCBieSBUQ1Au DQo+Pg0KPj4zLiBFdmVyeSB0aW1lIEkgZGVsZXRlIChvciByZW5hbWUpIGEgZmlsZSBsb2NhbGx5 LCB0aGUgY2xpZW50IHdpbGwgYWxzbyBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIHRvIHNlbmQg c2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZCBvdXQgd2hpY2ggZmlsZSBoYXMgYmVlbiByZW1vdmVk IChvciByZW5hbWVkKS4gVGhlbiBpdCB3aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4gVGhlIHNl cnZlciB3aWxsIHJlc3BvbmQgYSAyMDQgTm8gQ29udGVudCBSZXNwb25zZSAob3IgMjAxIENyZWF0 ZWQgUmVzcG9uc2UpIGFuZCB0aGVuIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4NCj4+DQo+PjQu IEkgb3BlbiBhIGZpbGUgYW5kIGZyZXF1ZW50bHkgZWRpdCBhbmQgc2F2ZSBpdCAoYWN0dWFsbHkg dGhpcyBpcyB3aGF0IEkgdXN1YWxseSBkbyB3aXRoIHRoZSBEcm9wYm94KS4gVGhlIGNsaWVudCB3 aWxsIHNlbmQgdGhlIHdob2xlIGZpbGUgdG8gdGhlIHNlcnZlciBldmVyeSB0aW1lIEkgc2F2ZSB0 aGUgZmlsZS4NCj4+DQo+PlRvIHN1bW1hcml6ZSwgaXQgc2VlbXMgdGhhdCB0aGUgb3duQ2xvdWQg bWFrZXMgaGVhdmlseSB1c2Ugb2YgUFJPUEZJTkQgdG8gYWNoaWV2ZSB0aGUgc3luYyBwcm9jZXNz LiBFYWNoIHN5bmMgb3BlcmF0aW9uIChlLmcuIHVwbG9hZCwgbW9kaWZ5IGFuZCBldGMuKSB3aWxs IHN0YXJ0IHdpdGggc2VuZGluZyBvbmUgb3IgbW9yZSBQUk9QRklORHMuIEFuZCBjdXJyZW50bHks IGlmIEkgYWRkIGEgZmlsZSB0byB0aGUgc2VydmVyIChkaXJlY3RseSBmcm9tIHRoZSBzZXJ2ZXIg c2lkZSB2aWEgd2ViIGludGVyZmFjZSksIHRoZSBjbGllbnQgY2Fubm90IGZpbmQgdGhlIGNoYW5n ZS4gSSBuZWVkIHRvIGludGVycnVwdCB0aGUgc3luYyBhbmQgcmVjb3ZlciBpdCB0byBtYWtlIHRo ZSBjbGllbnQgYmUgYXdhcmUgb2YgdGhlIGNoYW5nZSBhbmQgZG93bmxvYWQgdGhlIG5ld2x5IGFk ZGVkIGZpbGUuIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgY2F1c2VkIGJ5IHRoZSBzeW5j IG1lY2hhbmlzbSBvciBhbiBpbXByb3BlciBzZXJ2ZXIgY29uZmlndXJhdGlvbi4gSSBuZWVkIHRv IGludmVzdGlnYXRlIHRoaXMgZnVydGhlciBhbmQgYWxzbyBob3cgdGhlIG93bkNsb3VkIHdvcmtz IGZvciBtdWx0aXBsZSBjbGllbnRzIChvciBkZXZpY2VzKS4NCj4+DQo+PkZvciBJU1MsIEkgdGhp bmsgb3duQ2xvdWQgaGFzIGRlbW9uc3RyYXRlZCB0byBzb21lIGV4dGVudCB0aGF0IHNpbWlsYXIg SUVURiBwcm90b2NvbHMgY291bGQgYmUgZGVwbG95ZWQgYW5kIGVtcGxveWVkLiBUaGUgaW50ZW50 aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyB0byBpbnZlc3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBv ZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUg aW1wcm92ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldyBwcm90b2NvbHMuDQo+Pg0KPj5D b21tZW50cyBhcmUgd2VsY29tZSA6ICkNCj4+DQo+PlJlZ2FyZHMsDQo+Pkxpbmh1aQ0KPj4NCj4+ DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PlN0 b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPj5TdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3Rv cmFnZXN5bmNAaWV0Zi5vcmc+PG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3Rv cmFnZXN5bmNAaWV0Zi5vcmc+Pg0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N0b3JhZ2VzeW5jDQo+Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+U3RvcmFnZXN5bmNAaWV0 Zi5vcmc8bWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4NCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0K PlN0b3JhZ2VzeW5jQGlldGYub3JnPG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZz4NCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+ From nobody Tue Dec 1 23:20:54 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384C11B33E9 for ; Tue, 1 Dec 2015 23:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy7qJ29sspjP for ; Tue, 1 Dec 2015 23:20:51 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15061B33E7 for ; Tue, 1 Dec 2015 23:20:50 -0800 (PST) Received: by wmec201 with SMTP id c201so239238695wme.0 for ; Tue, 01 Dec 2015 23:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uGXQrcR70M5wdSDuP9xeqgN/PJCMOhElwBh/XYMPlAw=; b=VCuGZF1M/z8rZZXhLxQ1n8g6oYtforbHZF0zxs6PdEAt/KtktUUQOmJtd0w19PE6+o ph0GOpO9mVVBPos4lc9UMcsiZBrS37z2Q/DwAt/rHekBzE0UXOJD8b+bAQr59TnAYTJO fBO2amAnDHlbItx23pp+nJDhLoFwgu2FR/9NkvcA+/cJDEiEhiMaovJ5ahfLu+KyXUsK I2P21F2BZLEpG/crYJ94j90m+FhnkF5K6Gi6G15LzJaJf77ddSWdWTheBOKnO2/guAtb WHqtFlCoLh1oiiY1iChHgKPjHEc1IA2H+nanw6h4cgWCqXeeRmu0qy5OVbFleYWk+dFV UEyA== X-Received: by 10.28.89.137 with SMTP id n131mr43621466wmb.9.1449040849464; Tue, 01 Dec 2015 23:20:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Tue, 1 Dec 2015 23:20:30 -0800 (PST) In-Reply-To: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> From: Linhui Sun Date: Wed, 2 Dec 2015 15:20:30 +0800 Message-ID: To: =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Content-Type: multipart/alternative; boundary=001a1140cdb818f1a10525e51d0d Archived-At: Cc: storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 07:20:53 -0000 --001a1140cdb818f1a10525e51d0d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > Hi, > > from my point of view the remoteStorage project addresses a subset of > the use cases of the WebDAV specification. > > The main difference I can observe is that the specification is built on > REST instead of XML-based communication. > I personally like much more REST than WebDAV because it is more > developer friendly and it is faster to develop. > Maybe the remoteStorage API becomes the next WebDAV :) > > However, the remoteStorage API does not provide a way of synchronising > data, this task is delegated to the developers. > Is there a plan to provide such feature based on the outcome of this > draft? > I'm a little bit confused why you say the remoteStorage does not provide that. Is that because remoteStorage does not perform like a typical sync services (e.g. dropbox...) or you are saying something else? > > BTW, I want to introduce ClawIO (http://clawio.github.io), a research > project to benchmark different synchronisation protocols against > different data backends with special attention to provide a common sync > API. > > A common API for different sync protocols is being created based on the > architecture specified in this draft (control and data servers) and the > I cannot find a distributed architecture in this draft. It seems that they handle metadata and content data together, just like a normal web service. Regards, Linhui > one from the CERN EOS project (management, disk and queue servers). > > The Phase I has implemented the ownCloud Sync Protocol and Phase II will > implement the SeaFile Sync Protocol. > The choice of these protocols among others is because they are really > opposed to each other in terms of syncing (delta vs non-delta, > state-based vs log/event/git-based sync =E2=80=A6), so finding a common a= pproach > is more challenging. > > Providing a base specification/architecture to measure the feasibility > of this draft is one of the objectives of the project. > > I believe that the work being done here and in ClawIO are supplementary > to each other and I think mutual collaboration could be beneficial for > both sides. > > Also, if there is interest, the remoteStorage API can be added to > ClawIO. > > Best regards, > > Hugo Gonzalez Labrador > > On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: > > Send Storagesync mailing list submissions to > > storagesync@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/storagesync > > or, via email, send a message with subject or body 'help' to > > storagesync-request@ietf.org > > > > You can reach the person managing the list at > > storagesync-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Storagesync digest..." > > Today's Topics: > > > > 1. New version of draft-dejong-remotestorage Internet-Draft > > available (Michiel de Jong) > > 2. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Gihan Dias) > > 3. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Fei Song) > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > > Email had 3 attachments: > > + [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 1k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > --001a1140cdb818f1a10525e51d0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador &= lt;ietf@hugo.lab= kode.com>:
Hi,

from my point of view the remoteStorage project addresses a subset of
the use cases of the=C2=A0 WebDAV specification.

The main difference I can observe is that the specification is built on
REST instead of XML-based communication.

I personally like much more REST than WebDAV because it is more
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)

However, the remoteStorage API does not provide a way of synchronising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of this
draft?
I'm a little bit confused why you say the r= emoteStorage does not provide that. Is that because remoteStorage does not = perform like a typical sync services (e.g. dropbox...) or you are saying so= mething else?

BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against
different data backends with special attention to provide a common sync
API.

A common API for different sync protocols is being created based on the
architecture specified in this draft (control and data servers) and the
=
I cannot find a distributed architecture in this draft. I= t seems that they handle metadata and content data together, just like a no= rmal web service.

Regards,
Linhui
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> one from the CERN EOS project (management, disk and queue servers).

The Phase I has implemented the ownCloud Sync Protocol and Phase II will implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a common app= roach
is more challenging.

Providing a base specification/architecture to measure the feasibility
of this draft is one of the objectives of the project.

I believe that the work being done here and in ClawIO are supplementary
to each other and I think mutual collaboration could be beneficial for
both sides.

Also, if there is interest, the remoteStorage API can be added to
ClawIO.

Best regards,

Hugo Gonzalez Labrador

On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org= /mailman/listinfo/storagesync
> or, via email, send a message with subject or body 'help' to >=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific > than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 =C2=A0= Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Internet= -Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Internet= -Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Storagesync@= ietf.org
> https://www.ietf.org/mailman/listinfo/storages= ync
> Email had 3 attachments:
> + [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>=C2=A0 =C2=A02k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>=C2=A0 =C2=A01k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>=C2=A0 =C2=A02k (message/rfc822)

_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync

--001a1140cdb818f1a10525e51d0d-- From nobody Tue Dec 1 23:59:58 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB35D1A1BAA for ; Tue, 1 Dec 2015 23:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjFE_Fl5455e for ; Tue, 1 Dec 2015 23:59:54 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3FE1A0AFE for ; Tue, 1 Dec 2015 23:59:54 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygD32VKMpV5Wj5cDAA--.4080S2; Wed, 02 Dec 2015 16:02:20 +0800 (CST) Date: Wed, 2 Dec 2015 15:59:43 +0800 From: "Fei Song" To: "Linhui Sun" , =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120215594300046911@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygD32VKMpV5Wj5cDAA--.4080S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAr48AF1DAF43tr4xZr4rAFb_yoWrArW5pF W7Ja1fKF4kJr4rCwn7ZF1Iva10vr92gr47J3Z0qw1xJ3s8XF9akr12kr1ruFZrJr15Gr1j vr1Y9F13urZ8XFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_GFyl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU0 c4S7UUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 07:59:56 -0000 SGkgYWxsDQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+SGkNCj4NCj4yMDE1LTEyLTAy IDU6MTQgR01UKzA4OjAwIEh1Z28gR29ueqiibGV6IExhYnJhZG9yIDxpZXRmQGh1Z28ubGFia29k ZS5jb20+Og0KPg0KPj4gSGksDQo+Pg0KPj4gZnJvbSBteSBwb2ludCBvZiB2aWV3IHRoZSByZW1v dGVTdG9yYWdlIHByb2plY3QgYWRkcmVzc2VzIGEgc3Vic2V0IG9mDQo+PiB0aGUgdXNlIGNhc2Vz IG9mIHRoZSAgV2ViREFWIHNwZWNpZmljYXRpb24uDQo+Pg0KPj4gVGhlIG1haW4gZGlmZmVyZW5j ZSBJIGNhbiBvYnNlcnZlIGlzIHRoYXQgdGhlIHNwZWNpZmljYXRpb24gaXMgYnVpbHQgb24NCj4+ IFJFU1QgaW5zdGVhZCBvZiBYTUwtYmFzZWQgY29tbXVuaWNhdGlvbi4NCj4NCj4NCj4+IEkgcGVy c29uYWxseSBsaWtlIG11Y2ggbW9yZSBSRVNUIHRoYW4gV2ViREFWIGJlY2F1c2UgaXQgaXMgbW9y ZQ0KPj4gZGV2ZWxvcGVyIGZyaWVuZGx5IGFuZCBpdCBpcyBmYXN0ZXIgdG8gZGV2ZWxvcC4NCj4+ ICBNYXliZSB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgYmVjb21lcyB0aGUgbmV4dCBXZWJEQVYgOikN Cj4+DQo+PiBIb3dldmVyLCB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgZG9lcyBub3QgcHJvdmlkZSBh IHdheSBvZiBzeW5jaHJvbmlzaW5nDQo+PiBkYXRhLCB0aGlzIHRhc2sgaXMgZGVsZWdhdGVkIHRv IHRoZSBkZXZlbG9wZXJzLg0KPj4gSXMgdGhlcmUgYSBwbGFuIHRvIHByb3ZpZGUgc3VjaCBmZWF0 dXJlIGJhc2VkIG9uIHRoZSBvdXRjb21lIG9mIHRoaXMNCj4+IGRyYWZ0Pw0KPj4NCj5JJ20gYSBs aXR0bGUgYml0IGNvbmZ1c2VkIHdoeSB5b3Ugc2F5IHRoZSByZW1vdGVTdG9yYWdlIGRvZXMgbm90 IHByb3ZpZGUNCj50aGF0LiBJcyB0aGF0IGJlY2F1c2UgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBw ZXJmb3JtIGxpa2UgYSB0eXBpY2FsIHN5bmMNCj5zZXJ2aWNlcyAoZS5nLiBkcm9wYm94Li4uKSBv ciB5b3UgYXJlIHNheWluZyBzb21ldGhpbmcgZWxzZT8NCj4NCj4+DQo+PiBCVFcsIEkgd2FudCB0 byBpbnRyb2R1Y2UgQ2xhd0lPIChodHRwOi8vY2xhd2lvLmdpdGh1Yi5pbyksIGEgcmVzZWFyY2gN Cj4+IHByb2plY3QgdG8gYmVuY2htYXJrIGRpZmZlcmVudCBzeW5jaHJvbmlzYXRpb24gcHJvdG9j b2xzIGFnYWluc3QNCj4+IGRpZmZlcmVudCBkYXRhIGJhY2tlbmRzIHdpdGggc3BlY2lhbCBhdHRl bnRpb24gdG8gcHJvdmlkZSBhIGNvbW1vbiBzeW5jDQo+PiBBUEkuDQo+Pg0KPj4gQSBjb21tb24g QVBJIGZvciBkaWZmZXJlbnQgc3luYyBwcm90b2NvbHMgaXMgYmVpbmcgY3JlYXRlZCBiYXNlZCBv biB0aGUNCj4+IGFyY2hpdGVjdHVyZSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdCAoY29udHJvbCBh bmQgZGF0YSBzZXJ2ZXJzKSBhbmQgdGhlDQo+Pg0KPkkgY2Fubm90IGZpbmQgYSBkaXN0cmlidXRl ZCBhcmNoaXRlY3R1cmUgaW4gdGhpcyBkcmFmdC4gSXQgc2VlbXMgdGhhdCB0aGV5DQo+aGFuZGxl IG1ldGFkYXRhIGFuZCBjb250ZW50IGRhdGEgdG9nZXRoZXIsIGp1c3QgbGlrZSBhIG5vcm1hbCB3 ZWIgc2VydmljZS4NCg0KSXMgaXQgYW5vdGhlciBkcmFmdCByZWxhdGVkIHdpdGggQ2xhd0lPPyBO b3QgcmVtb3RlU3RvcmFnZT8NCg0KDQo+DQo+UmVnYXJkcywNCj5MaW5odWkNCj4NCj4+IG9uZSBm cm9tIHRoZSBDRVJOIEVPUyBwcm9qZWN0IChtYW5hZ2VtZW50LCBkaXNrIGFuZCBxdWV1ZSBzZXJ2 ZXJzKS4NCj4+DQo+PiBUaGUgUGhhc2UgSSBoYXMgaW1wbGVtZW50ZWQgdGhlIG93bkNsb3VkIFN5 bmMgUHJvdG9jb2wgYW5kIFBoYXNlIElJIHdpbGwNCj4+IGltcGxlbWVudCB0aGUgU2VhRmlsZSBT eW5jIFByb3RvY29sLg0KPj4gVGhlIGNob2ljZSBvZiB0aGVzZSBwcm90b2NvbHMgYW1vbmcgb3Ro ZXJzIGlzIGJlY2F1c2UgdGhleSBhcmUgcmVhbGx5DQo+PiBvcHBvc2VkIHRvIGVhY2ggb3RoZXIg aW4gdGVybXMgb2Ygc3luY2luZyAoZGVsdGEgdnMgbm9uLWRlbHRhLA0KPj4gc3RhdGUtYmFzZWQg dnMgbG9nL2V2ZW50L2dpdC1iYXNlZCBzeW5jIKGtKSwgc28gZmluZGluZyBhIGNvbW1vbiBhcHBy b2FjaA0KPj4gaXMgbW9yZSBjaGFsbGVuZ2luZy4NCj4+DQo+PiBQcm92aWRpbmcgYSBiYXNlIHNw ZWNpZmljYXRpb24vYXJjaGl0ZWN0dXJlIHRvIG1lYXN1cmUgdGhlIGZlYXNpYmlsaXR5DQo+PiBv ZiB0aGlzIGRyYWZ0IGlzIG9uZSBvZiB0aGUgb2JqZWN0aXZlcyBvZiB0aGUgcHJvamVjdC4NCj4+ DQo+PiBJIGJlbGlldmUgdGhhdCB0aGUgd29yayBiZWluZyBkb25lIGhlcmUgYW5kIGluIENsYXdJ TyBhcmUgc3VwcGxlbWVudGFyeQ0KPj4gdG8gZWFjaCBvdGhlciBhbmQgSSB0aGluayBtdXR1YWwg Y29sbGFib3JhdGlvbiBjb3VsZCBiZSBiZW5lZmljaWFsIGZvcg0KPj4gYm90aCBzaWRlcy4NCj4+ DQo+PiBBbHNvLCBpZiB0aGVyZSBpcyBpbnRlcmVzdCwgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGNh biBiZSBhZGRlZCB0bw0KPj4gQ2xhd0lPLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBI dWdvIEdvbnphbGV6IExhYnJhZG9yDQo+Pg0KPj4gT24gVHVlLCBEZWMgMSwgMjAxNSwgYXQgMDk6 MDAgUE0sIHN0b3JhZ2VzeW5jLXJlcXVlc3RAaWV0Zi5vcmcgd3JvdGU6DQo+PiA+IFNlbmQgU3Rv cmFnZXN5bmMgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQo+PiA+ICAgICAgIHN0b3JhZ2Vz eW5jQGlldGYub3JnDQo+PiA+DQo+PiA+IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEg dGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KPj4gPiAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+PiA+IG9yLCB2aWEgZW1haWwsIHNlbmQg YSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KPj4gPiAgICAgICBzdG9y YWdlc3luYy1yZXF1ZXN0QGlldGYub3JnDQo+PiA+DQo+PiA+IFlvdSBjYW4gcmVhY2ggdGhlIHBl cnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KPj4gPiAgICAgICBzdG9yYWdlc3luYy1vd25lckBp ZXRmLm9yZw0KPj4gPg0KPj4gPiBXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1Ympl Y3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQo+PiA+IHRoYW4gIlJlOiBDb250ZW50cyBv ZiBTdG9yYWdlc3luYyBkaWdlc3QuLi4iDQo+PiA+IFRvZGF5J3MgVG9waWNzOg0KPj4gPg0KPj4g PiAgICAxLiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSAgICBJbnRl cm5ldC1EcmFmdA0KPj4gPiAgICAgICBhdmFpbGFibGUgKE1pY2hpZWwgZGUgSm9uZykNCj4+ID4g ICAgMi4gUmU6IE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlIEludGVy bmV0LURyYWZ0DQo+PiA+ICAgICAgIGF2YWlsYWJsZSAoR2loYW4gRGlhcykNCj4+ID4gICAgMy4g UmU6IE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlIEludGVybmV0LURy YWZ0DQo+PiA+ICAgICAgIGF2YWlsYWJsZSAoRmVpIFNvbmcpDQo+PiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+IFN0b3JhZ2VzeW5jIG1haWxp bmcgbGlzdA0KPj4gPiBTdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+PiA+IEVtYWlsIGhhZCAzIGF0dGFj aG1lbnRzOg0KPj4gPiArIFtTdG9yYWdlc3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25n LXJlbW90ZXN0b3JhZ2UNCj4+ID4gSW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxlDQo+PiA+ICAgMmsg KG1lc3NhZ2UvcmZjODIyKQ0KPj4gPiArIFJlOiBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9m IGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlDQo+PiA+IEludGVybmV0LURyYWZ0IGF2YWlsYWJs ZQ0KPj4gPiAgIDFrIChtZXNzYWdlL3JmYzgyMikNCj4+ID4gKyBSZTogW1N0b3JhZ2VzeW5jXSBO ZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZQ0KPj4gPiBJbnRlcm5ldC1E cmFmdCBhdmFpbGFibGUNCj4+ID4gICAyayAobWVzc2FnZS9yZmM4MjIpDQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFN0b3JhZ2VzeW5j IG1haWxpbmcgbGlzdA0KPj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+DQo+ From nobody Wed Dec 2 01:56:19 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5121A6FF6 for ; Wed, 2 Dec 2015 01:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYAxN5AWvH0e for ; Wed, 2 Dec 2015 01:56:15 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA5F1A6FCA for ; Wed, 2 Dec 2015 01:56:15 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D8CEB2092F for ; Wed, 2 Dec 2015 04:56:14 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute2.internal (MEProxy); Wed, 02 Dec 2015 04:56:14 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=fgechsPR5diyd9VrRlYlyu9u3T4=; b=W4cjNZ x+Anz1KSWToWy//0wc54W525PeM8i2IKgVb2cwzHWHkOZOuXfFxbNJQCugfhLdtd NxbqKB2fHzb6oaT0+AZ395uJurzcX2biJyLY/2aq115Nn546FvLBBOoR/lWOM9AO pvp9ZN3KfFJ5fNCJPT5b7BKuZEnU1WEhXno5I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=fgechsPR5diyd9V rRlYlyu9u3T4=; b=cpVUo/N0ju3y3nmnSNPbCQtnWXueyYu3Mpwh5o45qxcudkw mZSoScx493nPe9bZ44CnI3YwwDqV2rbDpWBU+l3wE8OaIxmkcWEHAMiTT+PS5u8z l7qAmeGSww3L1vpZ0vaVIFaANd9fK8KFTHINzFYaiF3ec6HByAxXRMaUrMp8= Received: by web1.nyi.internal (Postfix, from userid 99) id 9ACE2AEF315; Wed, 2 Dec 2015 04:56:14 -0500 (EST) Message-Id: <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> X-Sasl-Enc: RQ5drXDnx9e667HT6rT8A23tWXOV9SD1h+U0vspjJ2k2 1449050174 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: Linhui Sun MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_144905017436679101"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> Date: Wed, 02 Dec 2015 10:56:14 +0100 Archived-At: Cc: storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 09:56:18 -0000 This is a multi-part message in MIME format. --_----------=_144905017436679101 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: > Hi > > 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador > : >> Hi, >> >> from my point of view the remoteStorage project addresses a subset of >> the use cases of the=C2=A0 WebDAV specification. >> >> The main difference I can observe is that the specification is built on >> REST instead of XML-based communication. >> >> I personally like much more REST than WebDAV because it is more >> developer friendly and it is faster to develop. >> Maybe the remoteStorage API becomes the next WebDAV :) >> >> However, the remoteStorage API does not provide a way of synchronising >> data, this task is delegated to the developers. >> Is there a plan to provide such feature based on the outcome of this >> draft? > I'm a little bit confused why you say the remoteStorage does not > provide that. Is that because remoteStorage does not perform like > a typical sync services (e.g. dropbox...) or you are saying > something else? Yes, because it does not offer synchronisation capabilities. >> >> BTW, I want to introduce ClawIO (http://clawio.github.io), a research >> project to benchmark different synchronisation protocols against >> different data backends with special attention to provide a common sync >> API. >> >> A common API for different sync protocols is being created based on the >> architecture specified in this draft (control and data servers) and the > I cannot find a distributed architecture in this draft. It seems that > they handle metadata and content data together, just like a normal web > service. ClawIO is fully distributed. Every logical unit is a different server than be scaled out. Data and Metadata channels are independent from each other and reside on different servers. > Regards, Linhui >> one from the CERN EOS project (management, disk and queue servers). >> >> The Phase I has implemented the ownCloud Sync Protocol and Phase II will >> implement the SeaFile Sync Protocol. >> The choice of these protocols among others is because they are really >> opposed to each other in terms of syncing (delta vs non-delta, >> state-based vs log/event/git-based sync =E2=80=A6), so finding a common app= roach >> is more challenging. >> >> Providing a base specification/architecture to measure the feasibility >> of this draft is one of the objectives of the project. >> >> I believe that the work being done here and in ClawIO are supplementary >> to each other and I think mutual collaboration could be beneficial for >> both sides. >> >> Also, if there is interest, the remoteStorage API can be added to >> ClawIO. >> >> Best regards, >> >> Hugo Gonzalez Labrador >> >> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: >> > Send Storagesync mailing list submissions to >> >storagesync@ietf.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> >https://www.ietf.org/mailman/listinfo/storagesync >> > or, via email, send a message with subject or body 'help' to >> >storagesync-request@ietf.org >> > >> > You can reach the person managing the list at >> >storagesync-owner@ietf.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of Storagesync digest..." >> > Today's Topics: >> > >> >1. New version of draft-dejong-remotestorage=C2=A0 =C2=A0 Internet-Draft >> >available (Michiel de Jong) >> >2. Re: New version of draft-dejong-remotestorage Internet-Draft >> >available (Gihan Dias) >> >3. Re: New version of draft-dejong-remotestorage Internet-Draft >> >available (Fei Song) >> > _______________________________________________ >> > Storagesync mailing list >> > Storagesync@ietf.org >> > https://www.ietf.org/mailman/listinfo/storagesync >> > Email had 3 attachments: >> > + [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> >2k (message/rfc822) >> > + Re: [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> >1k (message/rfc822) >> > + Re: [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> >2k (message/rfc822) >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync --_----------=_144905017436679101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
 
 
 
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
 
Hi,
 
from my point of view the remoteStorage project addresses a subset of
the use cases of the  WebDAV specification.
 
The main difference I can observe is that the specification is built on
=
REST instead of XML-based communication.
 
I personally like much more REST than WebDAV because it is more
developer friendly and it is faster to develop.
 Maybe the remoteStorage API becomes the next WebDAV :)
 
However, the remoteStorage API does not provide a way of synchronising
<= /div>
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of this
draft?
I'm a little bit confused why you say the remoteStorage d= oes not provide that. Is that because remoteStorage does not perform like a= typical sync services (e.g. dropbox...) or you are saying something else?<= br>
Yes, because it does not offer synchronisation capabiliti= es.
 
BTW, I want to introduce ClawIO (http:/= /clawio.github.io), a research
project to benchmark different synchronisation protocols against
different data backends with special attention to provide a common sync
=
API.
 
A common API for different sync protocols is being created based on the
=
architecture specified in this draft (control and data servers) and the
=
I cannot find a distributed architecture in this draft. I= t seems that they handle metadata and content data together, just like a no= rmal web service.
 
ClawIO is fully distributed. Every logical unit is a different server = than be scaled out. Data and Metadata channels are independent from each ot= her and reside on different servers.
 
Regards,
Linhui
one from the CERN EOS project= (management, disk and queue servers).
 
The Phase I has implemented the ownCloud Sync Protocol and Phase II will
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a common app= roach
is more challenging.
 
Providing a base specification/architecture to measure the feasibility
<= /div>
of this draft is one of the objectives of the project.
 
I believe that the work being done here and in ClawIO are supplementary
=
to each other and I think mutual collaboration could be beneficial for
<= /div>
both sides.
 
Also, if there is interest, the remoteStorage API can be added to
ClawIO.
 
Best regards,
 
Hugo Gonzalez Labrador
 
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
>
> You can reach the person managing the list at
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>    1. New version of draft-dejong-remotestorage   = Internet-Draft
>       available (Michiel de Jong)
>    2. Re: New version of draft-dejong-remotestorage Internet= -Draft
>       available (Gihan Dias)
>    3. Re: New version of draft-dejong-remotestorage Internet= -Draft
>       available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Storagesync@ietf.org
> Email had 3 attachments:
> + [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   2k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   1k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   2k (message/rfc822)
 
_______________________________________________
Storagesync mailing list
 
--_----------=_144905017436679101-- From nobody Wed Dec 2 02:19:09 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21C61A86EF for ; Wed, 2 Dec 2015 02:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22rXGFmmYQ7A for ; Wed, 2 Dec 2015 02:19:03 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CFD1A86EB for ; Wed, 2 Dec 2015 02:19:03 -0800 (PST) Received: by qgec40 with SMTP id c40so28703812qge.2 for ; Wed, 02 Dec 2015 02:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=6tdpQmWISn7KEIhZdzILuu+XUy7YcN9Cj7yFcVTFRYs=; b=ggCb/6Lb0ZxbOmVBBvhWxX5/eABR3fz6khQiCciE6tBv5Ql8HlPqqUsZHSX+uZ45uc Pir9LgRTABrig4WJg1qs2aWYdLQiOzHyTGkT+/p7Vi6CRcXPNG/nTc834qv1gqQ07azJ Fx61l8qRtw1HytFx8fw7f5XedXfEs5wZHic6rgKIu3I80A4TMYCsLThjt8a4kz9RY6dN 4qjLe54oq1lDi7MnAmRdRT9El4FKap6Bt15fyoCfP/sB8AjmfDy3MI0FgTo+50Zkdi8d agthCLMml6MMASWL8gIXK1ijGgUoPZO0dC6cLv97Cguwh0KdfOeqxANAwgQh2u9sJm0+ Dthw== X-Received: by 10.140.84.40 with SMTP id k37mr2827541qgd.33.1449051542240; Wed, 02 Dec 2015 02:19:02 -0800 (PST) Received: from [127.0.0.1] (ec2-54-210-254-173.compute-1.amazonaws.com. [54.210.254.173]) by smtp.gmail.com with ESMTPSA id s65sm888834qhb.39.2015.12.02.02.19.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 02:19:01 -0800 (PST) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14490515408020.22574428305961192" From: Linhui Sun To: =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= In-Reply-To: <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> Date: Wed, 02 Dec 2015 18:18:49 +0800 X-Cm-Message-Id: 1449051540717108df696ade6fa5ec1fae4c35dae591bdb9565ec594af1e51601210454 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0NDkwNTE1MjkwMDAiLCJjIiwiMTUxOTM5MTI5MTk2ODkzMDAyMCIsInYiLDFd X-Mailer: CloudMagic Message-Id: <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> MIME-Version: 1.0 Archived-At: Cc: storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 10:19:06 -0000 ------sinikael-?=_1-14490515408020.22574428305961192 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez= Labrador wrote: On Wed, Dec 2, 2015, at 08:20 AM, = Linhui Sun wrote: Hi 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador = < ietf@hugo.labkode.com [ietf@hugo.labkode.com] > : Hi, from my point of view the remoteStorage project addresses a subset of the use cases of the WebDAV specification. The main difference I can = observe is that the specification is built on REST instead of XML-based = communication. I personally like much more REST than WebDAV because it is = more developer friendly and it is faster to develop. Maybe the remoteStorage API becomes the next WebDAV :) However, the remoteStorage API does not provide a way of synchronising data, this task is delegated to the developers. Is there a plan to provide = such feature based on the outcome of this draft? I'm a little bit confused = why you say the remoteStorage does not provide that. Is that because remoteStorage does not perform like a typical sync services (e.g. dropbox...) or you are saying something else? Yes, because it does not offer synchronisation capabilities. Got it. And = What I am wondering is that do we need to include those capabilities in a base specifications. Since it is hard to standardize the capabilities like dedup or delta. Maybe a better way is to define those in = a separate specification, something like extensions. For a base document, = we just need to define how to perform sync operations. BTW, I want to = introduce ClawIO ( [http://clawio.github.io] http://clawio.github.io = [http://clawio.github.io] ), a research project to benchmark different = synchronisation protocols against different data backends with special = attention to provide a common sync API. A common API for different sync = protocols is being created based on the architecture specified in this = draft (control and data servers) and the I cannot find a distributed = architecture in this draft. It seems that they handle metadata and content = data together, just like a normal web service. ClawIO is fully distributed.= Every logical unit is a different server than be scaled out. Data and = Metadata channels are independent from each other and reside on different servers. That is widely employed in popular sync = services. And that is also beneficial to privacy to some extent. But in the= context of sync in browser (which is mainly considered in the = remoteStorage), I don't know whether this is reasonable. But I think we = should deploy distributed architecture although it will make things = complicated. Regards, Linhui Regards, Linhui one from the CERN EOS project = (management, disk and queue servers). The Phase I has implemented the = ownCloud Sync Protocol and Phase II will implement the SeaFile Sync = Protocol. The choice of these protocols among others is because they are = really opposed to each other in terms of syncing (delta vs non-delta, state-based vs log/event/git-based sync =E2=80=A6), so finding a common = approach is more challenging. Providing a base specification/architecture = to measure the feasibility of this draft is one of the objectives of the = project. I believe that the work being done here and in ClawIO are = supplementary to each other and I think mutual collaboration could be = beneficial for both sides. Also, if there is interest, the remoteStorage = API can be added to ClawIO. Best regards, Hugo Gonzalez Labrador On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org = [storagesync-request@ietf.org] wrote: > Send Storagesync mailing list = submissions to > storagesync@ietf.org [storagesync@ietf.org] > > To subscribe or unsubscribe via the World Wide Web, visit > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.= org/mailman/listinfo/storagesync [https://www.ietf.org/mailman/listinfo/sto= ragesync] > or, via email, send a message with subject or body 'help' to > storagesync-request@ietf.org [storagesync-request@ietf.org] > > You can reach the person managing the list at > storagesync-owner@ietf.= org [storagesync-owner@ietf.org] > > When replying, please edit your = Subject line so it is more specific > than "Re: Contents of Storagesync = digest..." > Today's Topics: > > 1. New version of draft-dejong-remotestora= ge Internet-Draft > available (Michiel de Jong) > 2. Re: New version of = draft-dejong-remotestorage Internet-Draft > available (Gihan Dias) > 3. Re: New version of draft-dejong-remotestorage Internet-Draft > available (Fei Song) > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org [Storagesync@ietf.org] > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.= org/mailman/listinfo/storagesync [https://www.ietf.org/mailman/listinfo/sto= ragesync] > Email had 3 attachments: > + [Storagesync] New version of = draft-dejong-remotestorage > Internet-Draft available > 2k (message/rfc822) > + Re: [Storagesync] New version of draft-dejong-remotestorage > Internet-Draft available > 1k (message/rfc822) > + Re: [Storagesync] New = version of draft-dejong-remotestorage > Internet-Draft available > 2k (message/rfc822) _______________________________________________ Storagesync mailing list Storagesync@ietf.org [Storagesync@ietf.org] [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.= org/mailman/listinfo/storagesync [https://www.ietf.org/mailman/listinfo/sto= ragesync] ------sinikael-?=_1-14490515408020.22574428305961192 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi

On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 = at 17:56, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> = wrote:
 
 
 
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
 
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.= com>:
Hi= ,
 
from my point of view the remoteStorage= project addresses a subset of
the use cases of the  = WebDAV specification.
 
The main difference I can observe is that the specification is built = on
REST instead of XML-based communication.
 
I personally like much more REST than WebDAV because it is more
developer friendly and it is faster to develop.
 Maybe the remoteStorage API becomes the next WebDAV :)
 
However, the remoteStorage API does not provide a = way of synchronising
data, this task is delegated to the = developers.
Is there a plan to provide such feature based = on the outcome of this
draft?
I'm a little bit confused why you say the remoteStorage = does not provide that. Is that because remoteStorage does not perform like = a typical sync services (e.g. dropbox...) or you are saying something else?=
Yes, because it does not = offer synchronisation capabilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification, something like extensions. For a= base document, we just need to define how to perform sync operations.=
 
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against
different data backends with special attention to provide a common = sync
API.
 
A common API for different sync protocols is being created based on = the
architecture specified in this draft (control and data = servers) and the
I cannot find a distributed = architecture in this draft. It seems that they handle metadata and content = data together, just like a normal web service.
 
ClawIO is fully distributed. = Every logical unit is a different server than be scaled out. Data and = Metadata channels are independent from each other and reside on different = servers.
That is = widely employed in popular sync services. And that is also beneficial to = privacy to some extent. But in the context of sync in browser (which is = mainly considered in the remoteStorage), I don't know whether this is = reasonable. But I think we should deploy distributed architecture although = it will make things complicated.

Regards,
L= inhui 

 
Regards,=
Linhui
one from the CERN EOS project (management, disk and queue servers).=
 
The Phase I has implemented the ownCloud= Sync Protocol and Phase II will
implement the SeaFile Sync= Protocol.
The choice of these protocols among others is = because they are really
opposed to each other in terms of = syncing (delta vs non-delta,
state-based vs = log/event/git-based sync =E2=80=A6), so finding a common approach
is more challenging.
 
Providing a base specification/architecture to measure the = feasibility
of this draft is one of the objectives of the = project.
 
I believe that the work being = done here and in ClawIO are supplementary
to each other and I think mutual collaboration could be beneficial = for
both sides.
 
Also, if there is interest, the remoteStorage API can be added to
ClawIO.
 
Best regards,
 
Hugo Gonzalez Labrador
 
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with = subject or body 'help' to
>       storagesync-request@ietf.= org
>
> You can reach the person = managing the list at
>
> When replying, please = edit your Subject line so it is more specific
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>    1. New version of draft-dejong-remotestorage   = Internet-Draft
>       available = (Michiel de Jong)
>    2. Re: New version of = draft-dejong-remotestorage Internet-Draft
>       available (Gihan Dias)
>    3. Re: New version of draft-dejong-remotestorage = Internet-Draft
>       available = (Fei Song)
> ___________________________________________= ____
> Storagesync mailing list
> Email had 3 attachments:
> + [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   2k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   1k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   2k (message/rfc822)
 
_______________________________________________
Storagesync mailing list
 
= =20 ------sinikael-?=_1-14490515408020.22574428305961192-- From nobody Wed Dec 2 02:28:53 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384ED1A8725 for ; Wed, 2 Dec 2015 02:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3fPTmD94gUJ for ; Wed, 2 Dec 2015 02:28:49 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E591A8726 for ; Wed, 2 Dec 2015 02:28:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 955062091D for ; Wed, 2 Dec 2015 05:28:48 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Wed, 02 Dec 2015 05:28:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=/pp4CUGkX2fm+277tX827B5L/CI=; b=g8LqxR AHEIHoVfeJkX9j5MxnJt3Xp4R1sGK7StKixDFiK6f26aq2R6oUoV7GcFH0tSrR8N O0770QHVoS8KlgZiH7fmFP/NPLkvdLg46aeFWfXpuUZisvt3VLAtpe0n1GTILWyK sbmpdlnGxa1V8lJ3PbGCvAc0CZejgUofs8294= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=/pp4CUGkX2fm+27 7tX827B5L/CI=; b=SGf7OpxthCEJy32UdA4aBWZN62F2P+G60GSFxnN/IwXZZoG vaKm7sPgd32scY4aX/zwSaqMzYwzMm9sPsLYT3u22QH51LdGxMpf1kMeBomEzeHy gxPP9cigDS0wv6Pnf86IziH0MElVDOgs5/wKzmWRK+xck/jGGWpisjHrQlhY= Received: by web1.nyi.internal (Postfix, from userid 99) id 3B30FAE6821; Wed, 2 Dec 2015 05:28:48 -0500 (EST) Message-Id: <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> X-Sasl-Enc: +Dig7BQitAVrc3hVNq2Jv4rad1H3JVVqM6OhOzI+6zrX 1449052128 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: Linhui Sun MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_144905212836747941"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 In-Reply-To: <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> Date: Wed, 02 Dec 2015 11:28:48 +0100 Archived-At: Cc: storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 10:28:52 -0000 This is a multi-part message in MIME format. --_----------=_144905212836747941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: > Hi > > On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez = Labrador > wrote: >> >> >> >> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >>> Hi >>> >>> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >>> : >>>> Hi, >>>> >>>> from my point of view the remoteStorage project addresses a subset >>>> of the use cases of the=C2=A0 WebDAV specification. >>>> >>>> The main difference I can observe is that the specification is >>>> built on REST instead of XML-based communication. >>>> >>>> I personally like much more REST than WebDAV because it is more >>>> developer friendly and it is faster to develop.=C2=A0Maybe the >>>> remoteStorage API becomes the next WebDAV :) >>>> >>>> However, the remoteStorage API does not provide a way of >>>> synchronising data, this task is delegated to the developers. Is >>>> there a plan to provide such feature based on the outcome of this >>>> draft? >>> I'm a little bit confused why you say the remoteStorage does not >>> provide that. Is that because remoteStorage does not perform like >>> a typical sync services (e.g. dropbox...) or you are saying >>> something else? >> Yes, because it does not offer synchronisation capabilities. > Got it. And What I am wondering is that do we need to include those > capabilities in a base specifications. Since it is hard to standardize > the capabilities like dedup or delta. Maybe a better way is to define > those in a separate specification, something like extensions. For a > base document, we just need to define how to perform sync operations. Yes, I agree that may be an extension of this draft could handle the synchronisation part. >> >>>> >>>> BTW, I want to introduce ClawIO (http://clawio.github.io), a >>>> research project to benchmark different synchronisation protocols >>>> against different data backends with special attention to provide a >>>> common sync API. >>>> >>>> A common API for different sync protocols is being created based on >>>> the architecture specified in this draft (control and data servers) >>>> and the >>> I cannot find a distributed architecture in this draft. It seems >>> that they handle metadata and content data together, just like a >>> normal web service. >> >> ClawIO is fully distributed. Every logical unit is a different server >> than be scaled out. Data and Metadata channels are independent from >> each other and reside on different servers. > That is widely employed in popular sync services. And that is also > beneficial to privacy to some extent. But in the context of sync in > browser (which is mainly considered in the remoteStorage), I don't > know whether this is reasonable. But I think we should deploy > distributed architecture although it will make things complicated. Of course, the remoteStorage is targeted to browsers, so syncing does not make too much sense in this case. With the rise of Linux container micro-service based architectures, the deployment of =C2=A0such highly complex systems should become easier and faster. Best, Hugo > Regards, Linhui >> >> >>> Regards, Linhui >>>> one from the CERN EOS project (management, disk and queue servers). >>>> >>>> The Phase I has implemented the ownCloud Sync Protocol and Phase II >>>> will implement the SeaFile Sync Protocol. The choice of these >>>> protocols among others is because they are really opposed to each >>>> other in terms of syncing (delta vs non-delta, state-based vs log/even= t/git- >>>> based sync =E2=80=A6), so finding a common approach is more challengin= g. >>>> >>>> Providing a base specification/architecture to measure the >>>> feasibility of this draft is one of the objectives of the project. >>>> >>>> I believe that the work being done here and in ClawIO are >>>> supplementary to each other and I think mutual collaboration could >>>> be beneficial for both sides. >>>> >>>> Also, if there is interest, the remoteStorage API can be added to >>>> ClawIO. >>>> >>>> Best regards, >>>> >>>> Hugo Gonzalez Labrador >>>> >>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org >>>> wrote: >>>> > Send Storagesync mailing list submissions to >>>> > storagesync@ietf.org >>>> > >>>> > To subscribe or unsubscribe via the World Wide Web, visit >>>> > https://www.ietf.org/mailman/listinfo/storagesync or, via email, >>>> > send a message with subject or body 'help' to=C2=A0 =C2=A0 =C2=A0 = =C2=A0storagesync- >>>> > request@ietf.org >>>> > >>>> > You can reach the person managing the list at=C2=A0 =C2=A0 =C2=A0 = =C2=A0storagesync- >>>> > owner@ietf.org >>>> > >>>> > When replying, please edit your Subject line so it is more >>>> > specific than "Re: Contents of Storagesync digest..." Today's >>>> > Topics: >>>> > >>>> >1. New version of draft-dejong-remotestorage=C2=A0 =C2=A0 Internet-Dr= aft >>>> >available (Michiel de Jong)=C2=A0 =C2=A0 2. Re: New version of draft-= dejong- >>>> >remotestorage Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gih= an Dias)=C2=A0 =C2=A0 3. >>>> >Re: New version of draft-dejong-remotestorage Internet-Draft >>>> >available (Fei Song) >>>> > _______________________________________________ >>>> > Storagesync mailing list Storagesync@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/storagesync Email had 3 >>>> > attachments: >>>> > + [Storagesync] New version of draft-dejong-remotestorage Internet- >>>> > Draft available=C2=A0 =C2=A02k (message/rfc822) >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage Intern= et- >>>> > Draft available=C2=A0 =C2=A01k (message/rfc822) >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage Intern= et- >>>> > Draft available=C2=A0 =C2=A02k (message/rfc822) >>>> >>>> _______________________________________________ >>>> Storagesync mailing list Storagesync@ietf.org >>>> https://www.ietf.org/mailman/listinfo/storagesync >> --_----------=_144905212836747941 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
 
 
 
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
 
On =E5=91=A8=E4=B8=89, 12=E6= =9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode= .com> wrote:
 
 
 
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
 
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com= >:
Hi,
 
from my point of view the remoteStorage project addresses a subset of<= br>
the use cases of the  WebDAV specification.
 
The main difference I can observe is that the specification is built o= n
REST instead of XML-based communication.
 
I personally like much more REST than WebDAV because it is more
developer friendly and it is faster to develop.
 Maybe the remoteStorage API becomes the next WebDAV :)
 
However, the remoteStorage API does not provide a way of synchronising=
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of this
draft?
I'm a little bit confused why you say the remoteStorage d= oes not provide that. Is that because remoteStorage does not perform like a= typical sync services (e.g. dropbox...) or you are saying something else?<= br>
Yes, because it does not offer synchronisation capabiliti= es.
Got it. And What I am wondering is that do we need to inc= lude those capabilities in a base specifications. Since it is hard to stand= ardize the capabilities like dedup or delta. Maybe a better way is to defin= e those in a separate specification, something like extensions. For a base = document, we just need to define how to perform sync operations.
 
Yes, I agree that may be an extension of this draft could handle the = synchronisation part.
 
 
 
BTW, I want to introduce ClawIO (<= /a>http://clawio.github.io), a rese= arch
project to benchmark different synchronisation protocols against
different data backends with special attention to provide a common syn= c
API.
 
A common API for different sync protocols is being created based on th= e
architecture specified in this draft (control and data servers) and th= e
I cannot find a distributed architecture in this draft. I= t seems that they handle metadata and content data together, just like a no= rmal web service.
 
ClawIO is fully distributed. Every logical unit is a different server = than be scaled out. Data and Metadata channels are independent from each ot= her and reside on different servers.
That is widely employed in popular sync services. And tha= t is also beneficial to privacy to some extent. But in the context of sync = in browser (which is mainly considered in the remoteStorage), I don't know = whether this is reasonable. But I think we should deploy distributed archit= ecture although it will make things complicated.
 
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of  such highly complex systems should become easier and = faster.
 
Best,
 
Hugo
 
Regards,
Linhui 
 
 
Regards,
Linhui
one from the CERN EOS project= (management, disk and queue servers).
 
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
 
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
 
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
 
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
 
Best regards,
 
Hugo Gonzalez Labrador
 
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://www.ietf.org/mailman/listinfo/storagesync
> or, via email, send a message with subject or body 'help' to
<= /div>
>
> You can reach the person managing the list at
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>    1. New version of draft-dejong-remotestorage  &= nbsp; Internet-Draft
>       available (Michiel de Jong)
>    2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>       available (Gihan Dias)
>    3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>       available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
> + [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   2k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
>   1k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
>   2k (message/rfc822)
 
_______________________________________________
Storagesync mailing list
 
 
--_----------=_144905212836747941-- From nobody Wed Dec 2 04:30:53 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EC41A8961 for ; Wed, 2 Dec 2015 04:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB5w8tWn9K0N for ; Wed, 2 Dec 2015 04:30:47 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0351A8960 for ; Wed, 2 Dec 2015 04:30:47 -0800 (PST) Received: by igcto18 with SMTP id to18so30098524igc.0 for ; Wed, 02 Dec 2015 04:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nuWPaDCufwsYZakiXw+Y8mF1Kx11bKJXp1z6ARk63TY=; b=e7M0VHXSPhWhMxVHVVIgK8ZeBS/9dViTFyIfk1UU5VmZUIXAWqQdnlpE7En1lm1Vau n1+hASrmCyJr+Z+lMWq9KeTWvNNMiS94n61haNki058+pzch2rtbRIyNh5tX6oo8S4we +/9z79XF9AHg1VY0HDjq5IB0TKYHyW2m5Sq9+vga1n/VdRHQy8gKZWcCQ3cgeosnkc3s bEXh26O0yG75uFwIlGDR8sqNQvyHqRiX52Q9ouuy5HnogLjTQU/8Ssi+sirOwGrdnx/p eY4xZ7MDxfQOZhDh2csqCFCiI5m813RU83i8TLCD1JAUl2H3SQxGinsEhsdcU6BFv39M nzdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nuWPaDCufwsYZakiXw+Y8mF1Kx11bKJXp1z6ARk63TY=; b=HChjyK1rV9SELBXVIPgliBNc78igoBB72GuwpSEy69CWviMxFxgol9sIcfeoJvheve q3iwo4nhwpFUENAE6pz5MOL4ut+C3fASY6djevNM86UYXpgBmjsI6OVeRvuu8CN+xVV6 Pga650k4ijLoNMXniQMiXcZMe2f1ibStEOpfy1GbpLY1qMTCE/v8It/hpm/UZUb1fP/Q c53K8lriMTF9+1GDfUsfEsW0ZqNVcLPhy3SbLjVdRkbTglmnOsDrzMJrc9YrNG88YoxV xf3Ne7wps3x+Vh3zvogBVj7+lCKWXnH/Fn9Ps/ecxdbPxpBsxiq7IMfJHuEagSxvxU53 g7QA== X-Gm-Message-State: ALoCoQnU+iJWgcpdldr6D7MAgCQnPBivzQlMoTIk357ktB1WaybBBFtFG62pajmf9cao5eA1USB8 MIME-Version: 1.0 X-Received: by 10.50.61.232 with SMTP id t8mr29970938igr.16.1449059446458; Wed, 02 Dec 2015 04:30:46 -0800 (PST) Received: by 10.107.137.68 with HTTP; Wed, 2 Dec 2015 04:30:46 -0800 (PST) In-Reply-To: <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> Date: Wed, 2 Dec 2015 13:30:46 +0100 Message-ID: From: Michiel de Jong To: =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Content-Type: multipart/alternative; boundary=047d7bdc05e89178bb0525e971cb Archived-At: Cc: Linhui Sun , storagesync , fkooman@tuxed.net Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 12:30:52 -0000 --047d7bdc05e89178bb0525e971cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all! Thanks for all your reactions to the remoteStorage Internet-Draft. We get the question about WebDAV a lot, in the next version we should add a remark about it in the intro. The folder descriptions returned when you GET a URL that ends with a / are indeed a deviation from the XML returned by WebDAV server, and this is just because nowadays JSON is easier to use than XML for developers, both client-side and server-side. The fact that we don't require servers to support WebDAV's custom verbs like PROPPATCH etc. is for three reasons: 1) it's a lot of work to implement this without using an existing WebDAV library 2) in practice, a lot of WebDAV servers get it wrong, or don't implement all of WebDAV. It's very annoying for client implementers to have to deal with servers that e.g. chose not to implement LOCK and UNLOCK. 3) we don't really need all these advanced features on top of standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple folder description format, is enough for most applications. Other than that, the remoteStorage Internet-Draft specifies a *lot* more than just how each HTTP verb should behave: * requiring support for OAuth implicit-grant flow * requiring ETag support and nested versioning (i.e. the folder's ETag changes if anything within that folder changes) * requiring CORS headers * requiring a WebFinger announcement for service discovery It would be easy to add these three things on top of WebDAV, instead of putting them on top of our minimal GET/PUT/DELETE API definition. In fact, we could probably separate it into two Internet-Drafts: one for the 'RESTful folders' API which is our simplification of WebDAV, and a second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful folders' or whatever other HTTP-based API you want. On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < ietf@hugo.labkode.com> wrote: > > > > On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: > > Hi > > On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez L= abrador > wrote: > > > > > On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: > > Hi > > 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > Hi, > > from my point of view the remoteStorage project addresses a subset of > the use cases of the WebDAV specification. > > The main difference I can observe is that the specification is built on > REST instead of XML-based communication. > > > I personally like much more REST than WebDAV because it is more > developer friendly and it is faster to develop. > Maybe the remoteStorage API becomes the next WebDAV :) > > However, the remoteStorage API does not provide a way of synchronising > data, this task is delegated to the developers. > Is there a plan to provide such feature based on the outcome of this > draft? > > I'm a little bit confused why you say the remoteStorage does not provide > that. Is that because remoteStorage does not perform like a typical sync > services (e.g. dropbox...) or you are saying something else? > > Yes, because it does not offer synchronisation capabilities. > > Got it. And What I am wondering is that do we need to include those > capabilities in a base specifications. Since it is hard to standardize th= e > capabilities like dedup or delta. Maybe a better way is to define those i= n > a separate specification, > > Thanks for giving these examples - so by 'synchronisation capabilities' you mean 1) deduplication and 2) delta updates? Anything else or is that an exhaustive list? > something like extensions. For a base document, we just need to define ho= w > to perform sync operations. > > > Yes, I agree that may be an extension of this draft could handle the > synchronisation part. > > Our Internet-Draft is heavily focused on the world wide web, whose URLs are not content-addressable, we can't change that. So that architecture is not very friendly to deduplication, compared to for instance BitTorrent. As you already said, developers can still dedupe on the server-side when storing blobs to disk, and can also dedupe on the client side before creating the resources the client uploads. As far as I know, delta updates are not supported by the ETag system - you cannot do a range request to find out if certain bytes within a document have changed. However, the folder system we define does encourage you, for instance when you develop a To Do List app, put each task on its own document, and then query the folder to see which of them changed, instead of putting them all in one big document and retrieving the whole document each time. Cheers, Michiel. > > > BTW, I want to introduce ClawIO ( > http://clawio.github.io), a research > project to benchmark different synchronisation protocols against > different data backends with special attention to provide a common sync > API. > > A common API for different sync protocols is being created based on the > architecture specified in this draft (control and data servers) and the > > I cannot find a distributed architecture in this draft. It seems that the= y > handle metadata and content data together, just like a normal web service= . > > > ClawIO is fully distributed. Every logical unit is a different server tha= n > be scaled out. Data and Metadata channels are independent from each other > and reside on different servers. > > That is widely employed in popular sync services. And that is also > beneficial to privacy to some extent. But in the context of sync in brows= er > (which is mainly considered in the remoteStorage), I don't know whether > this is reasonable. But I think we should deploy distributed architecture > although it will make things complicated. > > > Of course, the remoteStorage is targeted to browsers, so syncing does not > make too much sense in this case. > With the rise of Linux container micro-service based architectures, the > deployment of such highly complex systems should become easier and faste= r. > > Best, > > Hugo > > > Regards, > Linhui > > > > > Regards, > Linhui > > one from the CERN EOS project (management, disk and queue servers). > > The Phase I has implemented the ownCloud Sync Protocol and Phase II will > implement the SeaFile Sync Protocol. > The choice of these protocols among others is because they are really > opposed to each other in terms of syncing (delta vs non-delta, > state-based vs log/event/git-based sync =E2=80=A6), so finding a common a= pproach > is more challenging. > > Providing a base specification/architecture to measure the feasibility > of this draft is one of the objectives of the project. > > I believe that the work being done here and in ClawIO are supplementary > to each other and I think mutual collaboration could be beneficial for > both sides. > > Also, if there is interest, the remoteStorage API can be added to > ClawIO. > > Best regards, > > Hugo Gonzalez Labrador > > On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: > > Send Storagesync mailing list submissions to > > storagesync@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/storagesync > > or, via email, send a message with subject or body 'help' to > > storagesync-request@ietf.org > > > > You can reach the person managing the list at > > storagesync-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Storagesync digest..." > > Today's Topics: > > > > 1. New version of draft-dejong-remotestorage Internet-Draft > > available (Michiel de Jong) > > 2. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Gihan Dias) > > 3. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Fei Song) > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > Email had 3 attachments: > > + [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 1k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > --047d7bdc05e89178bb0525e971cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all!

Thanks for all your reactions to the remoteStorage I= nternet-Draft.

We get the question about WebDAV a lot, in the = next version we should add a remark about it in the intro. The folder descr= iptions returned when you GET a URL that ends with a / are indeed a deviati= on from the XML returned by WebDAV server, and this is just because nowaday= s JSON is easier to use than XML for developers, both client-side and serve= r-side.

The fact that we don't require servers to support = WebDAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an existing Web= DAV library
2) in practice, a lot of WebDAV servers get it wrong, = or don't implement all of WebDAV. It's very annoying for client imp= lementers to have to deal with servers that e.g. chose not to implement LOC= K and UNLOCK.
3) we don't really need all these advanced featu= res on top of standard HTTP, just supporting GET/PUT/DELETE for resources, = and adding a simple folder description format, is enough for most applicati= ons.

Other than that, the remoteStorage Internet-Draft specifi= es a *lot* more than just how each HTTP verb should behave:
* requ= iring support for OAuth implicit-grant flow
* requiring ETag = support and nested versioning (i.e. the folder's ETag changes if anythi= ng within that folder changes)
* requiring CORS headers
*= requiring a WebFinger announcement for service discovery

It w= ould be easy to add these three things on top of WebDAV, instead of putting= them on top of our minimal GET/PUT/DELETE API definition. In fact, we coul= d probably separate it into two Internet-Drafts: one for the 'RESTful f= olders' API which is our simplification of WebDAV, and a second one for= OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful folders= ' or whatever other HTTP-based API you want.

On Wed, Dec 2, 2015 at 11:28 AM, H= ugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote= :
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
On =E5=91=A8=E4=B8=89, 12=E6=9C= =88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:=
<= div>
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subset of<= br>
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is built o= n
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchronising=
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of this
draft?
I'm a little bit confused why you say the remoteStora= ge does not provide that. Is that because remoteStorage does not perform li= ke a typical sync services (e.g. dropbox...) or you are saying something el= se?
Yes, because it does not offer synchronisation capabiliti= es.
Got it. And What I am wondering is that do we need to inc= lude those capabilities in a base specifications. Since it is hard to stand= ardize the capabilities like dedup or delta. Maybe a better way is to defin= e those in a separate specification,
<= /span>

Thanks for giving these exampl= es - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) del= ta=20 updates? Anything else or is that an exhaustive list?
something like extensions. For a base document, we just need to = define how to perform sync operations.
=C2=A0
Yes, I agree that may be an extension of this draft could hand= le the synchronisation part.
=C2=A0

Our Internet-Draft is h= eavily focused on the world wide web, whose URLs are not content-addressabl= e, we can't change that. So that architecture is not very friendly to d= eduplication, compared to for instance BitTorrent. As you already said, dev= elopers can still dedupe on the server-side when storing blobs to disk, and= can also dedupe on the client side before creating the resources the clien= t uploads.

As far as I know, delta updates are not suppor= ted by the ETag system - you cannot do a range request to find out if certa= in bytes within a document have changed. However, the folder system we defi= ne does encourage you, for instance when you develop a To Do List app, put = each task on its own document, and then query the folder to see which of th= em changed, instead of putting them all in one big document and retrieving = the whole document each time.


Cheers,
M= ichiel.

= =C2=A0
=C2= =A0
BTW, I want to introduce ClawIO (= http://clawio.github.io), a research
project to benchmark different synchronisation protocols against
different data backends with special attention to provide a common syn= c
API.
=C2=A0
A common API for different sync protocols is being created based on th= e
architecture specified in this draft (control and data servers) and th= e
I cannot find a distributed architecture in this draft. I= t seems that they handle metadata and content data together, just like a no= rmal web service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different server = than be scaled out. Data and Metadata channels are independent from each ot= her and reside on different servers.
That is widely employed in popular sync services. And tha= t is also beneficial to privacy to some extent. But in the context of sync = in browser (which is mainly considered in the remoteStorage), I don't k= now whether this is reasonable. But I think we should deploy distributed ar= chitecture although it will make things complicated.
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncin= g does not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=
=C2=A0
Hugo
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (management,= disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0

--047d7bdc05e89178bb0525e971cb-- From nobody Wed Dec 2 04:43:45 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97E01A897A for ; Wed, 2 Dec 2015 04:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXg8S3vVhwhM for ; Wed, 2 Dec 2015 04:43:39 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665651A896D for ; Wed, 2 Dec 2015 04:43:39 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AF66C20668 for ; Wed, 2 Dec 2015 07:43:38 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute3.internal (MEProxy); Wed, 02 Dec 2015 07:43:38 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=0zDUFcm5WRTfC86y8Nd9xNfzIrs=; b=YJWaJa y3wWFWHor2DOKks1I+TTwXXTrupzKJDP8F+Jr4w0j29VneU+rD7JQcrLLZpsu1yB z7OTye6o7IS0DyNY+iYk9f2dyWE9/xp3XncZ4y8MDFI4aVFQi90igM0wwB474aK5 WCzhqFcEb+R1tMJy3WanO7fY0Wd+sl+jGVN7U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=0zDUFcm5WRTfC86 y8Nd9xNfzIrs=; b=LBI1/WXkP3/kmN5itFfl9LirFYugB12YRsbwDjs2bE1oj6l D1l246+9W1SbEW4Xr6zZQOC8LaRfyKM7E44Xl5M0jvfOGHKUFX77obOEQ/V/8XGD oqfUhUW0NI/Qji94OZJ3kTKwjBI5L8R5eDuekbNPNYD1B1ZVm+XbKSlWoVnk= Received: by web1.nyi.internal (Postfix, from userid 99) id 69256AEFB3D; Wed, 2 Dec 2015 07:43:38 -0500 (EST) Message-Id: <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> X-Sasl-Enc: ZdJ0GRw9QmpW5NpGZ50j9o5vj9eVLD8MDKmtEnrWrD24 1449060218 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: Michiel de Jong MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_144906021837212311"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> Date: Wed, 02 Dec 2015 13:43:38 +0100 Archived-At: Cc: Linhui Sun , storagesync , fkooman@tuxed.net Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 12:43:43 -0000 This is a multi-part message in MIME format. --_----------=_144906021837212311 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: > Hi all! Thanks for all your reactions to the remoteStorage Internet- > Draft. > > We get the question about WebDAV a lot, in the next version we > should add a remark about it in the intro. The folder descriptions > returned when you GET a URL that ends with a / are indeed a > deviation from the XML returned by WebDAV server, and this is just > because nowadays JSON is easier to use than XML for developers, both > client-side and server-side. I totally agree here, this was going to happen soon or later and it is really appreciated. > The fact that we don't require servers to support WebDAV's custom > verbs like PROPPATCH etc. is for three reasons: > 1) it's a lot of work to implement this without using an existing > WebDAV library > 2) in practice, a lot of WebDAV servers get it wrong, or don't > implement all of WebDAV. It's very annoying for client implementers > to have to deal with servers that e.g. chose not to implement LOCK > and UNLOCK. > 3) we don't really need all these advanced features on top of standard > HTTP, just supporting GET/PUT/DELETE for resources, and adding a > simple folder description format, is enough for most applications. > > Other than that, the remoteStorage Internet-Draft specifies a *lot* > more than just how each HTTP verb should behave: > * requiring support for OAuth implicit-grant flow > * requiring ETag support and nested versioning (i.e. the folder's ETag > changes if anything within that folder changes) > * requiring CORS headers > * requiring a WebFinger announcement for service discovery It would be > easy to add these three things on top of WebDAV, instead of putting > them on top of our minimal GET/PUT/DELETE API definition. In fact, > we could probably separate it into two Internet-Drafts: one for the > 'RESTful folders' API which is our simplification of WebDAV, and a > second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or > 'RESTful folders' or whatever other HTTP-based API you want. There is one requirement that all synchronisers need to handle: moving resources. In this spec the alternative of a WebDAV MOVE is not specified. It is true that a MOVE could be replaced with a DELETE + UPLOAD but that is not acceptable in most cases due to the inefficiency of such operation (cpu, bandwidth consumption ...) Is there a plan to support such basic feature? >From the current remoteStorage spec, the ownCloud sync protocol can be implemented. The missing bit is tracking those remote moves. Cheers > On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador > wrote: >> __ >> >> >> >> >> On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: >>> Hi >>> >>> On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1le= z Labrador >>> wrote: >>>> >>>> >>>> >>>> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >>>>> Hi >>>>> >>>>> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >>>>> : >>>>>> Hi, >>>>>> >>>>>> from my point of view the remoteStorage project addresses a >>>>>> subset of the use cases of the=C2=A0 WebDAV specification. >>>>>> >>>>>> The main difference I can observe is that the specification is >>>>>> built on REST instead of XML-based communication. >>>>>> >>>>>> I personally like much more REST than WebDAV because it is more >>>>>> developer friendly and it is faster to develop.=C2=A0Maybe the >>>>>> remoteStorage API becomes the next WebDAV :) >>>>>> >>>>>> However, the remoteStorage API does not provide a way of >>>>>> synchronising data, this task is delegated to the developers. Is >>>>>> there a plan to provide such feature based on the outcome of this >>>>>> draft? >>>>> I'm a little bit confused why you say the remoteStorage does not >>>>> provide that. Is that because remoteStorage does not perform like >>>>> a typical sync services (e.g. dropbox...) or you are saying >>>>> something else? >>>> Yes, because it does not offer synchronisation capabilities. >>> Got it. And What I am wondering is that do we need to include those >>> capabilities in a base specifications. Since it is hard to >>> standardize the capabilities like dedup or delta. Maybe a better way >>> is to define those in a separate specification, >> > > Thanks for giving these examples - so by 'synchronisation capabilities' you mean 1) deduplication and 2) delta updates? Anything else or is that an exhaustive list? >> >>> something like extensions. For a base document, we just need to >>> define how to perform sync operations. >> >> >> Yes, I agree that may be an extension of this draft could handle the >> synchronisation part. >> >> >> > > Our Internet-Draft is heavily focused on the world wide web, whose > URLs are not content-addressable, we can't change that. So that > architecture is not very friendly to deduplication, compared to for > instance BitTorrent. As you already said, developers can still dedupe > on the server-side when storing blobs to disk, and can also dedupe on > the client side before creating the resources the client uploads. As > far as I know, delta updates are not supported by the ETag system - > you cannot do a range request to find out if certain bytes within a > document have changed. However, the folder system we define does > encourage you, for instance when you develop a To Do List app, put > each task on its own document, and then query the folder to see which > of them changed, instead of putting them all in one big document and > retrieving the whole document each time. > > Cheers, Michiel. > >> >>>> >>>>>> >>>>>> BTW, I want to introduce ClawIO (http://clawio.github.io), a >>>>>> research project to benchmark different synchronisation protocols >>>>>> against different data backends with special attention to provide >>>>>> a common sync API. >>>>>> >>>>>> A common API for different sync protocols is being created based >>>>>> on the architecture specified in this draft (control and data >>>>>> servers) and the >>>>> I cannot find a distributed architecture in this draft. It seems >>>>> that they handle metadata and content data together, just like a >>>>> normal web service. >>>> >>>> ClawIO is fully distributed. Every logical unit is a different >>>> server than be scaled out. Data and Metadata channels are >>>> independent from each other and reside on different servers. >>> That is widely employed in popular sync services. And that is also >>> beneficial to privacy to some extent. But in the context of sync in >>> browser (which is mainly considered in the remoteStorage), I don't >>> know whether this is reasonable. But I think we should deploy >>> distributed architecture although it will make things complicated. >> >> >> Of course, the remoteStorage is targeted to browsers, so syncing does >> not make too much sense in this case. With the rise of Linux >> container micro-service based architectures, the deployment of =C2=A0such >> highly complex systems should become easier and faster. >> >> Best, >> >> >> Hugo >> >> >>> Regards, Linhui >>>> >>>> >>>>> Regards, Linhui >>>>>> one from the CERN EOS project (management, disk and queue >>>>>> servers). >>>>>> >>>>>> The Phase I has implemented the ownCloud Sync Protocol and Phase >>>>>> II will implement the SeaFile Sync Protocol. The choice of these >>>>>> protocols among others is because they are really opposed to each >>>>>> other in terms of syncing (delta vs non-delta, state-based vs log/ev= ent/git- >>>>>> based sync =E2=80=A6), so finding a common approach is more challeng= ing. >>>>>> >>>>>> Providing a base specification/architecture to measure the >>>>>> feasibility of this draft is one of the objectives of the >>>>>> project. >>>>>> >>>>>> I believe that the work being done here and in ClawIO are >>>>>> supplementary to each other and I think mutual collaboration >>>>>> could be beneficial for both sides. >>>>>> >>>>>> Also, if there is interest, the remoteStorage API can be added to >>>>>> ClawIO. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Hugo Gonzalez Labrador >>>>>> >>>>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org >>>>>> wrote: >>>>>> > Send Storagesync mailing list submissions to >>>>>> > storagesync@ietf.org >>>>>> > >>>>>> > To subscribe or unsubscribe via the World Wide Web, visit >>>>>> > https://www.ietf.org/mailman/listinfo/storagesync or, via >>>>>> > email, send a message with subject or body 'help' to=C2=A0 =C2=A0 = =C2=A0 =C2=A0storagesync- >>>>>> > request@ietf.org >>>>>> > >>>>>> > You can reach the person managing the list at=C2=A0 =C2=A0 =C2=A0 = =C2=A0storagesync- >>>>>> > owner@ietf.org >>>>>> > >>>>>> > When replying, please edit your Subject line so it is more >>>>>> > specific than "Re: Contents of Storagesync digest..." Today's >>>>>> > Topics: >>>>>> > >>>>>> >1. New version of draft-dejong-remotestorage=C2=A0 =C2=A0 Internet-= Draft >>>>>> >available (Michiel de Jong)=C2=A0 =C2=A0 2. Re: New version of draf= t-dejong- >>>>>> >remotestorage Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0available (G= ihan Dias)=C2=A0 =C2=A0 3. >>>>>> >Re: New version of draft-dejong-remotestorage Internet-Draft >>>>>> >available (Fei Song) >>>>>> > _______________________________________________ >>>>>> > Storagesync mailing list Storagesync@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/storagesync Email had 3 >>>>>> > attachments: >>>>>> > + [Storagesync] New version of draft-dejong-remotestorage Internet- >>>>>> > Draft available=C2=A0 =C2=A02k (message/rfc822) >>>>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>>>>> > Internet-Draft available=C2=A0 =C2=A01k (message/rfc822) >>>>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>>>>> > Internet-Draft available=C2=A0 =C2=A02k (message/rfc822) >>>>>> >>>>>> _______________________________________________ >>>>>> Storagesync mailing list Storagesync@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> >> --_----------=_144906021837212311 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
 
 
 
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draft.
=
 
We get the question about WebDAV a lot, in the next version we should = add a remark about it in the intro. The folder descriptions returned when y= ou GET a URL that ends with a / are indeed a deviation from the XML returne= d by WebDAV server, and this is just because nowadays JSON is easier to use= than XML for developers, both client-side and server-side.
 
I totally agree here, this was going to happen soon or later and it is= really appreciated.
 
The fact that we don't require servers to support WebDAV'= s custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an existing WebD= AV library
2) in practice, a lot of WebDAV servers get it wrong, or don't impleme= nt all of WebDAV. It's very annoying for client implementers to have to dea= l with servers that e.g. chose not to implement LOCK and UNLOCK.
3) we don't really need all these advanced features on top of standard= HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple fo= lder description format, is enough for most applications.
 
Other than that, the remoteStorage Internet-Draft specifies a *lot* mo= re than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder's ETag= changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, instead o= f putting them on top of our minimal GET/PUT/DELETE API definition. In fact= , we could probably separate it into two Internet-Drafts: one for the 'REST= ful folders' API which is our simplification of WebDAV, and a second one fo= r OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful folders' o= r whatever other HTTP-based API you want.
 
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.=  
 
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
 
Is there a plan to support such basic feature?
 
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
 
Cheers
 
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrot= e:

 
 
 
 
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
 
On =E5=91=A8=E4=B8=89, 1= 2=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:
=
 
 
 
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
 
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode= .com>:
Hi,
 
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the  WebDAV specification.
 
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
 
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
 Maybe the remoteStorage API becomes the next WebDAV :)
 
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remoteSto= rage does not provide that. Is that because remoteStorage does not perform = like a typical sync services (e.g. dropbox...) or you are saying something = else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
 
 
Thanks for giving these examples - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) delta=20 updates? Anything else or is that an exhaustive list?
 
something like exte= nsions. For a base document, we just need to define how to perform sync ope= rations.
 
 
Yes, I agree that may be an extension of this draft could handle the = synchronisation part.
 
 
 
 
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that architect= ure is not very friendly to deduplication, compared to for instance BitTorr= ent. As you already said, developers can still dedupe on the server-side wh= en storing blobs to disk, and can also dedupe on the client side before cre= ating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
 
Cheers,
Michiel.
 
 
 
 
BTW, I want to introduce ClawIO (http://clawio.github.io), = a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
 
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
 
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don't= know whether this is reasonable. But I think we should deploy distributed = architecture although it will make things complicated.
 
 
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of  such highly complex systems should become easier and = faster.
 
Best,<= /span>
 
 
Hugo
 
 
Regards,
Linhui 
 
 
Regards,
Linhui
one from the CERN EOS project= (management, disk and queue servers).
 
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
 
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
 
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
 
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
 
Best regards,
 
Hugo Gonzalez Labrador
 
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://www.ietf.org/mailman/listinfo/storagesync
> or, via email, send a message with subject or body 'help' to
<= /div>
>
> You can reach the person managing the list at
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>    1. New version of draft-dejong-remotestorage  &= nbsp; Internet-Draft
>       available (Michiel de Jong)
>    2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>       available (Gihan Dias)
>    3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>       available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
> + [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   2k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
>   1k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
>   2k (message/rfc822)
 
_______________________________________________
Storagesync mailing list
 
 
 
--_----------=_144906021837212311-- From nobody Wed Dec 2 04:59:41 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7351F1A8A0F for ; Wed, 2 Dec 2015 04:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC74EQRNVZfK for ; Wed, 2 Dec 2015 04:59:35 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693771A89F2 for ; Wed, 2 Dec 2015 04:59:31 -0800 (PST) Received: by wmec201 with SMTP id c201so251952086wme.0 for ; Wed, 02 Dec 2015 04:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fKtRzw98VzC+nJcAkVw2X7BsamsPDUwxFHdUHz5UJgQ=; b=ONKIMrneiueagm+3KuiBmM4mZgo7Yk+jzAV20Sgo58+V2FJQeFInNJX7RPKagg9Y5i hDuJsLrQGXcTdjZZJqMIexJpj58k7zgy49FFzhrK3DDJB10gVPMshgJLy3OJbCJwIKJN DRnPyrbVFSgk0XzA1bMGZqQA66ll7H5AwdmhgoBqH9cdBudw7yFBtchBbFK6Z1wdFqi+ UuDaitjCLug3zq+FM9ItM8qYAtnzGUWplzqlefOsOW0Hkx2CFvKfp6dRDwu8f1b83I56 /Qb5WCohHBX0DSSZo1uSoYOrN/WESqDmlIiGo+Xg7SgSW9SSoPzz7Q8/cIZIuH3Plc+n hGrQ== X-Received: by 10.194.172.2 with SMTP id ay2mr1866969wjc.137.1449061169996; Wed, 02 Dec 2015 04:59:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 2 Dec 2015 04:59:10 -0800 (PST) In-Reply-To: <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> From: Linhui Sun Date: Wed, 2 Dec 2015 20:59:10 +0800 Message-ID: To: =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Content-Type: multipart/alternative; boundary=089e013c62144ba8fb0525e9d831 Archived-At: Cc: storagesync , Michiel de Jong , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 12:59:39 -0000 --089e013c62144ba8fb0525e9d831 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > > > On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: > > Hi all! > Thanks for all your reactions to the remoteStorage Internet-Draft. > > We get the question about WebDAV a lot, in the next version we should add > a remark about it in the intro. The folder descriptions returned when you > GET a URL that ends with a / are indeed a deviation from the XML returned > by WebDAV server, and this is just because nowadays JSON is easier to use > than XML for developers, both client-side and server-side. > > > I totally agree here, this was going to happen soon or later and it is > really appreciated. > > > The fact that we don't require servers to support WebDAV's custom verbs > like PROPPATCH etc. is for three reasons: > 1) it's a lot of work to implement this without using an existing WebDAV > library > 2) in practice, a lot of WebDAV servers get it wrong, or don't implement > all of WebDAV. It's very annoying for client implementers to have to deal > with servers that e.g. chose not to implement LOCK and UNLOCK. > 3) we don't really need all these advanced features on top of standard > HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple > folder description format, is enough for most applications. > > Other than that, the remoteStorage Internet-Draft specifies a *lot* more > than just how each HTTP verb should behave: > * requiring support for OAuth implicit-grant flow > * requiring ETag support and nested versioning (i.e. the folder's ETag > changes if anything within that folder changes) > * requiring CORS headers > * requiring a WebFinger announcement for service discovery > It would be easy to add these three things on top of WebDAV, instead of > putting them on top of our minimal GET/PUT/DELETE API definition. In fact= , > we could probably separate it into two Internet-Drafts: one for the > 'RESTful folders' API which is our simplification of WebDAV, and a second > one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful > folders' or whatever other HTTP-based API you want. > > > There is one requirement that all synchronisers need to handle: moving > resources. In this spec the alternative of a WebDAV MOVE is not specified= . > > It is true that a MOVE could be replaced with a DELETE + UPLOAD but that > is not acceptable in most cases due to the inefficiency of such operation > (cpu, bandwidth consumption ...) > > Is there a plan to support such basic feature? > > From the current remoteStorage spec, the ownCloud sync protocol can be > implemented. The missing bit is tracking those remote moves. > I agree with Hugo that MOVE is useful, sometimes if you just rename a file it will be perfect. But the question I have is that whether we need to make two documents? Multiple choices is not good for standardization. In my view, webdav is something that we need to have a very clear decision on whether to consider it or not. Regards, Linhui > > Cheers > > > On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < > ietf@hugo.labkode.com> wrote: > > > > > > > On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: > > Hi > > On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez L= abrador > wrote: > > > > > On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: > > Hi > > 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > Hi, > > from my point of view the remoteStorage project addresses a subset of > the use cases of the WebDAV specification. > > The main difference I can observe is that the specification is built on > REST instead of XML-based communication. > > > I personally like much more REST than WebDAV because it is more > developer friendly and it is faster to develop. > Maybe the remoteStorage API becomes the next WebDAV :) > > However, the remoteStorage API does not provide a way of synchronising > data, this task is delegated to the developers. > Is there a plan to provide such feature based on the outcome of this > draft? > > I'm a little bit confused why you say the remoteStorage does not provide > that. Is that because remoteStorage does not perform like a typical sync > services (e.g. dropbox...) or you are saying something else? > > Yes, because it does not offer synchronisation capabilities. > > Got it. And What I am wondering is that do we need to include those > capabilities in a base specifications. Since it is hard to standardize th= e > capabilities like dedup or delta. Maybe a better way is to define those i= n > a separate specification, > > > > > Thanks for giving these examples - so by 'synchronisation capabilities' > you mean 1) deduplication and 2) delta updates? Anything else or is that = an > exhaustive list? > > > > something like extensions. For a base document, we just need to define ho= w > to perform sync operations. > > > > Yes, I agree that may be an extension of this draft could handle the > synchronisation part. > > > > > > Our Internet-Draft is heavily focused on the world wide web, whose URLs > are not content-addressable, we can't change that. So that architecture i= s > not very friendly to deduplication, compared to for instance BitTorrent. = As > you already said, developers can still dedupe on the server-side when > storing blobs to disk, and can also dedupe on the client side before > creating the resources the client uploads. > As far as I know, delta updates are not supported by the ETag system - yo= u > cannot do a range request to find out if certain bytes within a document > have changed. However, the folder system we define does encourage you, fo= r > instance when you develop a To Do List app, put each task on its own > document, and then query the folder to see which of them changed, instead > of putting them all in one big document and retrieving the whole document > each time. > > Cheers, > Michiel. > > > > > > > > BTW, I want to introduce ClawIO ( > http://clawio.github.io), a research > project to benchmark different synchronisation protocols against > different data backends with special attention to provide a common sync > API. > > A common API for different sync protocols is being created based on the > architecture specified in this draft (control and data servers) and the > > I cannot find a distributed architecture in this draft. It seems that the= y > handle metadata and content data together, just like a normal web service= . > > > ClawIO is fully distributed. Every logical unit is a different server tha= n > be scaled out. Data and Metadata channels are independent from each other > and reside on different servers. > > That is widely employed in popular sync services. And that is also > beneficial to privacy to some extent. But in the context of sync in brows= er > (which is mainly considered in the remoteStorage), I don't know whether > this is reasonable. But I think we should deploy distributed architecture > although it will make things complicated. > > > > Of course, the remoteStorage is targeted to browsers, so syncing does not > make too much sense in this case. > With the rise of Linux container micro-service based architectures, the > deployment of such highly complex systems should become easier and faste= r. > > Best, > > > Hugo > > > > Regards, > Linhui > > > > > Regards, > Linhui > > one from the CERN EOS project (management, disk and queue servers). > > The Phase I has implemented the ownCloud Sync Protocol and Phase II will > implement the SeaFile Sync Protocol. > The choice of these protocols among others is because they are really > opposed to each other in terms of syncing (delta vs non-delta, > state-based vs log/event/git-based sync =E2=80=A6), so finding a common a= pproach > is more challenging. > > Providing a base specification/architecture to measure the feasibility > of this draft is one of the objectives of the project. > > I believe that the work being done here and in ClawIO are supplementary > to each other and I think mutual collaboration could be beneficial for > both sides. > > Also, if there is interest, the remoteStorage API can be added to > ClawIO. > > Best regards, > > Hugo Gonzalez Labrador > > On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: > > Send Storagesync mailing list submissions to > > storagesync@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/storagesync > > or, via email, send a message with subject or body 'help' to > > storagesync-request@ietf.org > > > > You can reach the person managing the list at > > storagesync-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Storagesync digest..." > > Today's Topics: > > > > 1. New version of draft-dejong-remotestorage Internet-Draft > > available (Michiel de Jong) > > 2. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Gihan Dias) > > 3. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Fei Song) > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > Email had 3 attachments: > > + [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 1k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > --089e013c62144ba8fb0525e9d831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.= labkode.com>:
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draft.
=
=C2=A0
We get the question about WebDAV a lot, in the next version we should = add a remark about it in the intro. The folder descriptions returned when y= ou GET a URL that ends with a / are indeed a deviation from the XML returne= d by WebDAV server, and this is just because nowadays JSON is easier to use= than XML for developers, both client-side and server-side.
=C2=A0
I totally agree here, this was going to happen soon or later an= d it is really appreciated.
=C2=A0
The fact that we don't require servers to support Web= DAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an existing = WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don't imp= lement all of WebDAV. It's very annoying for client implementers to hav= e to deal with servers that e.g. chose not to implement LOCK and UNLOCK.
3) we don't really need all these advanced features on top of stan= dard HTTP, just supporting GET/PUT/DELETE for resources, and adding a simpl= e folder description format, is enough for most applications.
=C2=A0
Other than that, the remoteStorage Internet-Draft specifies a *lot* mo= re than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder's = ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, instead o= f putting them on top of our minimal GET/PUT/DELETE API definition. In fact= , we could probably separate it into two Internet-Drafts: one for the '= RESTful folders' API which is our simplification of WebDAV, and a secon= d one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTfu= l folders' or whatever other HTTP-based API you want.
=C2=A0
There is one requirement that all synchronisers need to handle:= moving resources. In this spec the alternative of a WebDAV MOVE is not spe= cified.=C2=A0
=C2=A0
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
=C2=A0
Is there a plan to support such basic feature?
=C2=A0
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you= just rename a file it will be perfect. But the question I have is that whe= ther we need to make two documents? Multiple choices is not good for standa= rdization. In my view, webdav is something that we need to have a very clea= r decision on whether to consider it or not.

Regar= ds,
Linhui
=C2=A0
Cheers
=C2=A0
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remot= eStorage does not provide that. Is that because remoteStorage does not perf= orm like a typical sync services (e.g. dropbox...) or you are saying someth= ing else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
=C2=A0
=C2=A0
Thanks for giving these examples - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) del= ta=20 updates? Anything else or is that an exhaustive list?
=C2=A0
something like extens= ions. For a base document, we just need to define how to perform sync opera= tions.
=C2=A0
=C2=A0
Yes, I agree that may be an extension of this draft could handle the = synchronisation part.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that archi= tecture is not very friendly to deduplication, compared to for instance Bit= Torrent. As you already said, developers can still dedupe on the server-sid= e when storing blobs to disk, and can also dedupe on the client side before= creating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
=C2=A0
Cheers,
Michiel.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
=C2=A0
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don&#= 39;t know whether this is reasonable. But I think we should deploy distribu= ted architecture although it will make things complicated.
=C2=A0
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=C2=A0
=C2=A0
Hugo
=C2=A0
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (m= anagement, disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0
=C2=A0

--089e013c62144ba8fb0525e9d831-- From nobody Wed Dec 2 05:03:44 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2BC1A8A06 for ; Wed, 2 Dec 2015 05:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Syz-ixdNely9 for ; Wed, 2 Dec 2015 05:03:38 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B3F1A8A1C for ; Wed, 2 Dec 2015 05:03:38 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A82B120453 for ; Wed, 2 Dec 2015 08:03:37 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute4.internal (MEProxy); Wed, 02 Dec 2015 08:03:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=VJQQ79ZHQNKsCE9dQsUPeR2HYKA=; b=sEjEcb Uu7z5UjbuhaMvQj+k//zD8eFbnAIDDGZZ9MF8yT4HBfH7mT+TYN3zRT4DdfD8oxe nvzjb0n/7iE5txlzQyCxs74mhjed/myE58NLyKuFfl6HWJV+8CNIeRlSXZZMg/Zk YTKShONJN4cRO9FGVzjtqZev4btw2v2H0velU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=VJQQ79ZHQNKsCE9 dQsUPeR2HYKA=; b=ujAIBMNQznwfBOi9m2/HEMSJHMwVRBUI0QsFfIIO4Fgpkf+ TWLbAhtv2D+VmLM7fJWv8PVT4+lLQ+ORswDRolo61/8UNe6E8CzSUhw45B+9rTo9 +mHEWVTyB7q3IznPKHqUMVct3lsmlSvvABjaqD6mSaDgXZh9nopBtra5qiC8= Received: by web1.nyi.internal (Postfix, from userid 99) id 5E6E6AEFBA1; Wed, 2 Dec 2015 08:03:37 -0500 (EST) Message-Id: <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> X-Sasl-Enc: qqTOheeNMz+69527WhGGiXY9K8iQKQiskl8JqsqRcG6M 1449061417 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: Linhui Sun MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_144906141737297620"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 Date: Wed, 02 Dec 2015 14:03:37 +0100 In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> Archived-At: Cc: storagesync , Michiel de Jong , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 13:03:42 -0000 This is a multi-part message in MIME format. --_----------=_144906141737297620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I propose to come up with a list of advantages and disadvantages of using WebDAV and compare them against a JSON/REST based approach, like remoteStorage. Does it sound good ? On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: > > > 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador > : >> __ >> >> >> >> >> On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: >>> Hi all! Thanks for all your reactions to the remoteStorage Internet- >>> Draft. >>> >>> We get the question about WebDAV a lot, in the next version we >>> should add a remark about it in the intro. The folder descriptions >>> returned when you GET a URL that ends with a / are indeed a >>> deviation from the XML returned by WebDAV server, and this is just >>> because nowadays JSON is easier to use than XML for developers, both >>> client-side and server-side. >> >> >> I totally agree here, this was going to happen soon or later and it >> is really appreciated. >> >> >>> The fact that we don't require servers to support WebDAV's custom >>> verbs like PROPPATCH etc. is for three reasons: >>> 1) it's a lot of work to implement this without using an existing >>> WebDAV library >>> 2) in practice, a lot of WebDAV servers get it wrong, or don't >>> implement all of WebDAV. It's very annoying for client >>> implementers to have to deal with servers that e.g. chose not to >>> implement LOCK and UNLOCK. >>> 3) we don't really need all these advanced features on top of >>> standard HTTP, just supporting GET/PUT/DELETE for resources, and >>> adding a simple folder description format, is enough for most >>> applications. >>> >>> Other than that, the remoteStorage Internet-Draft specifies a *lot* >>> more than just how each HTTP verb should behave: >>> * requiring support for OAuth implicit-grant flow >>> * requiring ETag support and nested versioning (i.e. the folder's >>> ETag changes if anything within that folder changes) >>> * requiring CORS headers >>> * requiring a WebFinger announcement for service discovery It would >>> be easy to add these three things on top of WebDAV, instead of >>> putting them on top of our minimal GET/PUT/DELETE API definition. >>> In fact, we could probably separate it into two Internet-Drafts: >>> one for the 'RESTful folders' API which is our simplification of >>> WebDAV, and a second one for OAuth/ETags/CORS/WebFinger on top of >>> either WebDAV or 'RESTful folders' or whatever other HTTP-based >>> API you want. >> >> >> There is one requirement that all synchronisers need to handle: >> moving resources. In this spec the alternative of a WebDAV MOVE is >> not specified. >> >> It is true that a MOVE could be replaced with a DELETE + UPLOAD but >> that is not acceptable in most cases due to the inefficiency of such >> operation (cpu, bandwidth consumption ...) >> >> Is there a plan to support such basic feature? >> >> From the current remoteStorage spec, the ownCloud sync protocol can >> be implemented. The missing bit is tracking those remote moves. > I agree with Hugo that MOVE is useful, sometimes if you just rename a > file it will be perfect. But the question I have is that whether we > need to make two documents? Multiple choices is not good for > standardization. In my view, webdav is something that we need to have > a very clear decision on whether to consider it or not. > > Regards, Linhui >> >> >> Cheers >> >>> On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador >>> wrote: >>>> __ >>>> >>>> >>>> >>>> >>>> On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: >>>>> Hi >>>>> >>>>> On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1= lez Labrador >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >>>>>>> Hi >>>>>>> >>>>>>> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >>>>>>> : >>>>>>>> Hi, >>>>>>>> >>>>>>>> from my point of view the remoteStorage project addresses a >>>>>>>> subset of the use cases of the=C2=A0 WebDAV specification. >>>>>>>> >>>>>>>> The main difference I can observe is that the specification is >>>>>>>> built on REST instead of XML-based communication. >>>>>>>> >>>>>>>> I personally like much more REST than WebDAV because it is more >>>>>>>> developer friendly and it is faster to develop.=C2=A0Maybe the >>>>>>>> remoteStorage API becomes the next WebDAV :) >>>>>>>> >>>>>>>> However, the remoteStorage API does not provide a way of >>>>>>>> synchronising data, this task is delegated to the developers. >>>>>>>> Is there a plan to provide such feature based on the outcome of >>>>>>>> this draft? >>>>>>> I'm a little bit confused why you say the remoteStorage does not >>>>>>> provide that. Is that because remoteStorage does not perform >>>>>>> like a typical sync services (e.g. dropbox...) or you are saying >>>>>>> something else? >>>>>> Yes, because it does not offer synchronisation capabilities. >>>>> Got it. And What I am wondering is that do we need to include >>>>> those capabilities in a base specifications. Since it is hard to >>>>> standardize the capabilities like dedup or delta. Maybe a better >>>>> way is to define those in a separate specification, >>>> >>> >>> Thanks for giving these examples - so by 'synchronisation capabilities' you mean 1) deduplication and 2) delta updates? Anything else or is that an exhaustive list? >>>> >>>>> something like extensions. For a base document, we just need to >>>>> define how to perform sync operations. >>>> >>>> >>>> Yes, I agree that may be an extension of this draft could handle >>>> the synchronisation part. >>>> >>>> >>>> >>> >>> Our Internet-Draft is heavily focused on the world wide web, whose >>> URLs are not content-addressable, we can't change that. So that >>> architecture is not very friendly to deduplication, compared to for >>> instance BitTorrent. As you already said, developers can still >>> dedupe on the server-side when storing blobs to disk, and can also >>> dedupe on the client side before creating the resources the client >>> uploads. As far as I know, delta updates are not supported by the >>> ETag system - you cannot do a range request to find out if certain >>> bytes within a document have changed. However, the folder system we >>> define does encourage you, for instance when you develop a To Do >>> List app, put each task on its own document, and then query the >>> folder to see which of them changed, instead of putting them all in >>> one big document and retrieving the whole document each time. >>> >>> Cheers, Michiel. >>> >>>> >>>>>> >>>>>>>> >>>>>>>> BTW, I want to introduce ClawIO (http://clawio.github.io), a >>>>>>>> research project to benchmark different synchronisation >>>>>>>> protocols against different data backends with special >>>>>>>> attention to provide a common sync API. >>>>>>>> >>>>>>>> A common API for different sync protocols is being created >>>>>>>> based on the architecture specified in this draft (control and >>>>>>>> data servers) and the >>>>>>> I cannot find a distributed architecture in this draft. It seems >>>>>>> that they handle metadata and content data together, just like a >>>>>>> normal web service. >>>>>> >>>>>> ClawIO is fully distributed. Every logical unit is a different >>>>>> server than be scaled out. Data and Metadata channels are >>>>>> independent from each other and reside on different servers. >>>>> That is widely employed in popular sync services. And that is also >>>>> beneficial to privacy to some extent. But in the context of sync >>>>> in browser (which is mainly considered in the remoteStorage), I >>>>> don't know whether this is reasonable. But I think we should >>>>> deploy distributed architecture although it will make things >>>>> complicated. >>>> >>>> >>>> Of course, the remoteStorage is targeted to browsers, so syncing >>>> does not make too much sense in this case. With the rise of Linux >>>> container micro-service based architectures, the deployment of >>>> such highly complex systems should become easier and faster. >>>> >>>> Best, >>>> >>>> >>>> Hugo >>>> >>>> >>>>> Regards, Linhui >>>>>> >>>>>> >>>>>>> Regards, Linhui >>>>>>>> one from the CERN EOS project (management, disk and queue >>>>>>>> servers). >>>>>>>> >>>>>>>> The Phase I has implemented the ownCloud Sync Protocol and >>>>>>>> Phase II will implement the SeaFile Sync Protocol. The choice >>>>>>>> of these protocols among others is because they are really >>>>>>>> opposed to each other in terms of syncing (delta vs non-delta, >>>>>>>> state-based vs log/event/git-based sync =E2=80=A6), so finding a c= ommon >>>>>>>> approach is more challenging. >>>>>>>> >>>>>>>> Providing a base specification/architecture to measure the >>>>>>>> feasibility of this draft is one of the objectives of the >>>>>>>> project. >>>>>>>> >>>>>>>> I believe that the work being done here and in ClawIO are >>>>>>>> supplementary to each other and I think mutual collaboration >>>>>>>> could be beneficial for both sides. >>>>>>>> >>>>>>>> Also, if there is interest, the remoteStorage API can be added >>>>>>>> to ClawIO. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Hugo Gonzalez Labrador >>>>>>>> >>>>>>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org >>>>>>>> wrote: >>>>>>>> > Send Storagesync mailing list submissions to >>>>>>>> > storagesync@ietf.org >>>>>>>> > >>>>>>>> > To subscribe or unsubscribe via the World Wide Web, visit >>>>>>>> > https://www.ietf.org/mailman/listinfo/storagesync or, via >>>>>>>> > email, send a message with subject or body 'help' to >>>>>>>> > storagesync-request@ietf.org >>>>>>>> > >>>>>>>> > You can reach the person managing the list at=C2=A0 =C2=A0 =C2= =A0 =C2=A0storagesync- >>>>>>>> > owner@ietf.org >>>>>>>> > >>>>>>>> > When replying, please edit your Subject line so it is more >>>>>>>> > specific than "Re: Contents of Storagesync digest..." Today's >>>>>>>> > Topics: >>>>>>>> > >>>>>>>> >1. New version of draft-dejong-remotestorage=C2=A0 =C2=A0 Interne= t-Draft >>>>>>>> >available (Michiel de Jong)=C2=A0 =C2=A0 2. Re: New version of dr= aft-dejong- >>>>>>>> >remotestorage Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0available = (Gihan Dias) >>>>>>>> >3. Re: New version of draft-dejong-remotestorage Internet- >>>>>>>> >Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song) >>>>>>>> > _______________________________________________ >>>>>>>> > Storagesync mailing list Storagesync@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/storagesync Email had 3 >>>>>>>> > attachments: >>>>>>>> > + [Storagesync] New version of draft-dejong-remotestorage Intern= et- >>>>>>>> > Draft available=C2=A0 =C2=A02k (message/rfc822) >>>>>>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>>>>>>> > Internet-Draft available=C2=A0 =C2=A01k (message/rfc822) >>>>>>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>>>>>>> > Internet-Draft available=C2=A0 =C2=A02k (message/rfc822) >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Storagesync mailing list Storagesync@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>>> >>>> >> --_----------=_144906141737297620 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I propose to come up with a list of advantages and disadvantages= of using WebDAV and compare them against a JSON/REST based approach, like = remoteStorage.
 
Does it sound good ?
 
 
On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote:
 
 
2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com= >:

 
 
 
 
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:<= br>
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draf= t.
 
We get the question about WebDAV a lot, in the next version we s= hould add a remark about it in the intro. The folder descriptions returned = when you GET a URL that ends with a / are indeed a deviation from the XML r= eturned by WebDAV server, and this is just because nowadays JSON is easier = to use than XML for developers, both client-side and server-side.
 
 
I totally agree here, this was going to happen soon or later and it is= really appreciated.
 
 
The fact that we don't require servers to support W= ebDAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an existin= g WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don't i= mplement all of WebDAV. It's very annoying for client implementers to have = to deal with servers that e.g. chose not to implement LOCK and UNLOCK.
3) we don't really need all these advanced features on top of st= andard HTTP, just supporting GET/PUT/DELETE for resources, and adding a sim= ple folder description format, is enough for most applications.
<= /div>
 
Other than that, the remoteStorage Internet-Draft specifies a *l= ot* more than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder'= s ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, ins= tead of putting them on top of our minimal GET/PUT/DELETE API definition. I= n fact, we could probably separate it into two Internet-Drafts: one for the= 'RESTful folders' API which is our simplification of WebDAV, and a second = one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful fold= ers' or whatever other HTTP-based API you want.
 
 
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.=  
 
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
 
Is there a plan to support such basic feature?
 
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you j= ust rename a file it will be perfect. But the question I have is that wheth= er we need to make two documents? Multiple choices is not good for standard= ization. In my view, webdav is something that we need to have a very clear = decision on whether to consider it or not.
 
Regards,
Linhui
 
 
Cheers
 
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrot= e:

 
 
 
 
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
 
On =E5=91=A8=E4=B8=89, 1= 2=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:
=
 
 
 
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
 
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode= .com>:
Hi,
 
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the  WebDAV specification.
 
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
 
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
 Maybe the remoteStorage API becomes the next WebDAV :)
 
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remoteSto= rage does not provide that. Is that because remoteStorage does not perform = like a typical sync services (e.g. dropbox...) or you are saying something = else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
 
 
Thanks for giving these examples - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) delta=20 updates? Anything else or is that an exhaustive list?
 
something like exte= nsions. For a base document, we just need to define how to perform sync ope= rations.
 
 
Yes, I agree that may be an extension of this draft could handle the = synchronisation part.
 
 
 
 
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that architect= ure is not very friendly to deduplication, compared to for instance BitTorr= ent. As you already said, developers can still dedupe on the server-side wh= en storing blobs to disk, and can also dedupe on the client side before cre= ating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
 
Cheers,
Michiel.
 
 
 
 
BTW, I want to introduce ClawIO (http://clawio.github.io), = a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
 
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
 
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don't= know whether this is reasonable. But I think we should deploy distributed = architecture although it will make things complicated.
 
 
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of  such highly complex systems should become easier and = faster.
 
Best,<= /span>
 
 
Hugo
 
 
Regards,
Linhui 
 
 
Regards,
Linhui
one from the CERN EOS project= (management, disk and queue servers).
 
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
 
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
 
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
 
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
 
Best regards,
 
Hugo Gonzalez Labrador
 
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://www.ietf.org/mailman/listinfo/storagesync
> or, via email, send a message with subject or body 'help' to
<= /div>
>
> You can reach the person managing the list at
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>    1. New version of draft-dejong-remotestorage  &= nbsp; Internet-Draft
>       available (Michiel de Jong)
>    2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>       available (Gihan Dias)
>    3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>       available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
> + [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   2k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
>   1k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
>   2k (message/rfc822)
 
_______________________________________________
Storagesync mailing list
 
 
 
 
--_----------=_144906141737297620-- From nobody Wed Dec 2 05:33:16 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9051A8ADC for ; Wed, 2 Dec 2015 05:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0DrIfRd9qX6 for ; Wed, 2 Dec 2015 05:33:08 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C0C1A8AD4 for ; Wed, 2 Dec 2015 05:32:54 -0800 (PST) Received: by wmuu63 with SMTP id u63so214955518wmu.0 for ; Wed, 02 Dec 2015 05:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j8pZThNxggvY5zwpKd51AaRmkvp3CpqOBHffohYHBto=; b=DifnbHzdCjzOyvS16SzvbQf0m9apiwGE+Orsyp78p6mWzANzNyF84jQuHMGhSJYh3b 46b9u8A/+dbG4rCzA/nCSIDkcJlCB+K0GQL4TkV/uaxQkfH8rr3GsT1MMhY+1iV+2nkT QVmJ8sxoVZ1/mI8eUpqiX5lBzDvQXQKyipxDqlYyZWwYhLEJsnIRmzF2hPOVuJlRE96V Z/CqOIKJBDAM9fTBHeuDr/9O54CQKe+2hIKIpInVaGsullbcywIAkyAO26ZVxi+uDrTf Dy2Ock8yL9IUO5QjyIiYlYr+sy2h+Gi9OHXIE674bC/nWoA9QkWy/PCdCmVsfVtTsFQT Q5Bw== X-Received: by 10.28.141.140 with SMTP id p134mr45171686wmd.6.1449063172598; Wed, 02 Dec 2015 05:32:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 2 Dec 2015 05:32:33 -0800 (PST) In-Reply-To: <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> From: Linhui Sun Date: Wed, 2 Dec 2015 21:32:33 +0800 Message-ID: To: =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Content-Type: multipart/alternative; boundary=001a1146a0b0a8f34f0525ea4f1e Archived-At: Cc: storagesync , Michiel de Jong , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 13:33:12 -0000 --001a1146a0b0a8f34f0525ea4f1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's cool for me, a separate section for this might make sense. Another thing is do we need to include an application-layer chunking here (not just for a browser sync), since if we want to further extend other capabilities it is essential. Regards, Linhui 2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > I propose to come up with a list of advantages and disadvantages of using > WebDAV and compare them against a JSON/REST based approach, like > remoteStorage. > > Does it sound good ? > > > On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: > > > > 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > > > > > > On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: > > Hi all! > Thanks for all your reactions to the remoteStorage Internet-Draft. > > We get the question about WebDAV a lot, in the next version we should add > a remark about it in the intro. The folder descriptions returned when you > GET a URL that ends with a / are indeed a deviation from the XML returned > by WebDAV server, and this is just because nowadays JSON is easier to use > than XML for developers, both client-side and server-side. > > > > I totally agree here, this was going to happen soon or later and it is > really appreciated. > > > > The fact that we don't require servers to support WebDAV's custom verbs > like PROPPATCH etc. is for three reasons: > 1) it's a lot of work to implement this without using an existing WebDAV > library > 2) in practice, a lot of WebDAV servers get it wrong, or don't implement > all of WebDAV. It's very annoying for client implementers to have to deal > with servers that e.g. chose not to implement LOCK and UNLOCK. > 3) we don't really need all these advanced features on top of standard > HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple > folder description format, is enough for most applications. > > Other than that, the remoteStorage Internet-Draft specifies a *lot* more > than just how each HTTP verb should behave: > * requiring support for OAuth implicit-grant flow > * requiring ETag support and nested versioning (i.e. the folder's ETag > changes if anything within that folder changes) > * requiring CORS headers > * requiring a WebFinger announcement for service discovery > It would be easy to add these three things on top of WebDAV, instead of > putting them on top of our minimal GET/PUT/DELETE API definition. In fact= , > we could probably separate it into two Internet-Drafts: one for the > 'RESTful folders' API which is our simplification of WebDAV, and a second > one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful > folders' or whatever other HTTP-based API you want. > > > > There is one requirement that all synchronisers need to handle: moving > resources. In this spec the alternative of a WebDAV MOVE is not specified= . > > It is true that a MOVE could be replaced with a DELETE + UPLOAD but that > is not acceptable in most cases due to the inefficiency of such operation > (cpu, bandwidth consumption ...) > > Is there a plan to support such basic feature? > > From the current remoteStorage spec, the ownCloud sync protocol can be > implemented. The missing bit is tracking those remote moves. > > I agree with Hugo that MOVE is useful, sometimes if you just rename a fil= e > it will be perfect. But the question I have is that whether we need to ma= ke > two documents? Multiple choices is not good for standardization. In my > view, webdav is something that we need to have a very clear decision on > whether to consider it or not. > > Regards, > Linhui > > > > Cheers > > > On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < > ietf@hugo.labkode.com> wrote: > > > > > > > On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: > > Hi > > On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez L= abrador > wrote: > > > > > On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: > > Hi > > 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > Hi, > > from my point of view the remoteStorage project addresses a subset of > the use cases of the WebDAV specification. > > The main difference I can observe is that the specification is built on > REST instead of XML-based communication. > > > I personally like much more REST than WebDAV because it is more > developer friendly and it is faster to develop. > Maybe the remoteStorage API becomes the next WebDAV :) > > However, the remoteStorage API does not provide a way of synchronising > data, this task is delegated to the developers. > Is there a plan to provide such feature based on the outcome of this > draft? > > I'm a little bit confused why you say the remoteStorage does not provide > that. Is that because remoteStorage does not perform like a typical sync > services (e.g. dropbox...) or you are saying something else? > > Yes, because it does not offer synchronisation capabilities. > > Got it. And What I am wondering is that do we need to include those > capabilities in a base specifications. Since it is hard to standardize th= e > capabilities like dedup or delta. Maybe a better way is to define those i= n > a separate specification, > > > > > Thanks for giving these examples - so by 'synchronisation capabilities' > you mean 1) deduplication and 2) delta updates? Anything else or is that = an > exhaustive list? > > > > something like extensions. For a base document, we just need to define ho= w > to perform sync operations. > > > > Yes, I agree that may be an extension of this draft could handle the > synchronisation part. > > > > > > Our Internet-Draft is heavily focused on the world wide web, whose URLs > are not content-addressable, we can't change that. So that architecture i= s > not very friendly to deduplication, compared to for instance BitTorrent. = As > you already said, developers can still dedupe on the server-side when > storing blobs to disk, and can also dedupe on the client side before > creating the resources the client uploads. > As far as I know, delta updates are not supported by the ETag system - yo= u > cannot do a range request to find out if certain bytes within a document > have changed. However, the folder system we define does encourage you, fo= r > instance when you develop a To Do List app, put each task on its own > document, and then query the folder to see which of them changed, instead > of putting them all in one big document and retrieving the whole document > each time. > > Cheers, > Michiel. > > > > > > > > BTW, I want to introduce ClawIO ( > http://clawio.github.io), a research > project to benchmark different synchronisation protocols against > different data backends with special attention to provide a common sync > API. > > A common API for different sync protocols is being created based on the > architecture specified in this draft (control and data servers) and the > > I cannot find a distributed architecture in this draft. It seems that the= y > handle metadata and content data together, just like a normal web service= . > > > ClawIO is fully distributed. Every logical unit is a different server tha= n > be scaled out. Data and Metadata channels are independent from each other > and reside on different servers. > > That is widely employed in popular sync services. And that is also > beneficial to privacy to some extent. But in the context of sync in brows= er > (which is mainly considered in the remoteStorage), I don't know whether > this is reasonable. But I think we should deploy distributed architecture > although it will make things complicated. > > > > Of course, the remoteStorage is targeted to browsers, so syncing does not > make too much sense in this case. > With the rise of Linux container micro-service based architectures, the > deployment of such highly complex systems should become easier and faste= r. > > Best, > > > Hugo > > > > Regards, > Linhui > > > > > Regards, > Linhui > > one from the CERN EOS project (management, disk and queue servers). > > The Phase I has implemented the ownCloud Sync Protocol and Phase II will > implement the SeaFile Sync Protocol. > The choice of these protocols among others is because they are really > opposed to each other in terms of syncing (delta vs non-delta, > state-based vs log/event/git-based sync =E2=80=A6), so finding a common a= pproach > is more challenging. > > Providing a base specification/architecture to measure the feasibility > of this draft is one of the objectives of the project. > > I believe that the work being done here and in ClawIO are supplementary > to each other and I think mutual collaboration could be beneficial for > both sides. > > Also, if there is interest, the remoteStorage API can be added to > ClawIO. > > Best regards, > > Hugo Gonzalez Labrador > > On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: > > Send Storagesync mailing list submissions to > > storagesync@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/storagesync > > or, via email, send a message with subject or body 'help' to > > storagesync-request@ietf.org > > > > You can reach the person managing the list at > > storagesync-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Storagesync digest..." > > Today's Topics: > > > > 1. New version of draft-dejong-remotestorage Internet-Draft > > available (Michiel de Jong) > > 2. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Gihan Dias) > > 3. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Fei Song) > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > Email had 3 attachments: > > + [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 1k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > > > --001a1146a0b0a8f34f0525ea4f1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's cool for me, a separate section for this might = make sense.

Another thing is do we need to include an ap= plication-layer chunking here (not just for a browser sync), since if we wa= nt to further extend other capabilities it is essential.

=
Regards,
Linhui
=
2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1le= z Labrador <ietf@hugo.labkode.com>:
I propose to come up with a list of advantages and disadvantages = of using WebDAV and compare them against a JSON/REST based approach, like r= emoteStorage.
=C2=A0
Does it sound good ?
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote:
=C2=A0
=C2=A0
2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:<= br>
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draf= t.
=C2=A0
We get the question about WebDAV a lot, in the next version we s= hould add a remark about it in the intro. The folder descriptions returned = when you GET a URL that ends with a / are indeed a deviation from the XML r= eturned by WebDAV server, and this is just because nowadays JSON is easier = to use than XML for developers, both client-side and server-side.
=C2=A0
=C2=A0
I totally agree here, this was going to happen soon or later and it is= really appreciated.
=C2=A0
=C2=A0
The fact that we don't require servers to suppo= rt WebDAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an exi= sting WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don'= ;t implement all of WebDAV. It's very annoying for client implementers = to have to deal with servers that e.g. chose not to implement LOCK and UNLO= CK.
3) we don't really need all these advanced features on top o= f standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a= simple folder description format, is enough for most applications.<= br>
=C2=A0
Other than that, the remoteStorage Internet-Draft specifies a *l= ot* more than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder&= #39;s ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, ins= tead of putting them on top of our minimal GET/PUT/DELETE API definition. I= n fact, we could probably separate it into two Internet-Drafts: one for the= 'RESTful folders' API which is our simplification of WebDAV, and a= second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or '= RESTful folders' or whatever other HTTP-based API you want.
<= /div>
=C2=A0
=C2=A0
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.= =C2=A0
=C2=A0
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
=C2=A0
Is there a plan to support such basic feature?
=C2=A0
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you j= ust rename a file it will be perfect. But the question I have is that wheth= er we need to make two documents? Multiple choices is not good for standard= ization. In my view, webdav is something that we need to have a very clear = decision on whether to consider it or not.
=C2=A0
Regards,
Linhui
=C2=A0
=C2=A0
Cheers
=C2=A0
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remot= eStorage does not provide that. Is that because remoteStorage does not perf= orm like a typical sync services (e.g. dropbox...) or you are saying someth= ing else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
=C2=A0
=C2=A0
Thanks for giving these examples - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) del= ta=20 updates? Anything else or is that an exhaustive list?
=C2=A0
something like extens= ions. For a base document, we just need to define how to perform sync opera= tions.
=C2=A0
=C2=A0
Yes, I agree that may be an extension of this draft could handle the = synchronisation part.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that archi= tecture is not very friendly to deduplication, compared to for instance Bit= Torrent. As you already said, developers can still dedupe on the server-sid= e when storing blobs to disk, and can also dedupe on the client side before= creating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
=C2=A0
Cheers,
Michiel.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
=C2=A0
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don&#= 39;t know whether this is reasonable. But I think we should deploy distribu= ted architecture although it will make things complicated.
=C2=A0
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=C2=A0
=C2=A0
Hugo
=C2=A0
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (m= anagement, disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0
=C2=A0
=C2=A0

--001a1146a0b0a8f34f0525ea4f1e-- From nobody Wed Dec 2 06:05:34 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63571A9046 for ; Wed, 2 Dec 2015 06:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBuSQC-pSs3f for ; Wed, 2 Dec 2015 06:05:27 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664511A9045 for ; Wed, 2 Dec 2015 06:05:25 -0800 (PST) Received: by iouu10 with SMTP id u10so47239161iou.0 for ; Wed, 02 Dec 2015 06:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u/bLoqu5bQyGRWpRZhOIXLIHXaB/Gyj4IGj7G+sklc4=; b=nLvHkpVy6hDvhgwN7pUSQj0bT3fzkvejpBxPuThv7a7rCV6X2xaqE4QHvr3/ZXHcVP EAqUho6lLj7z0l8LLW1RZQPECPgF3D12iDCt+FL8wWrffxuDdhm1AUR082MiF+Ofhi9t LaYtzCSB02UtNDwES7wgzjT+uSIBOIo4WkXqieBYYSyLxLv8iMpcSgJn5StR87Ric2jt dDiqReOFhlrrCeyyOYXeKNtQczoWAu94NmQS1O/yUitMa11FV/uxFul70Z69VfBH2xSs yF5Hn8rC7ourrG7LgkIptqa+Yy8xsFA/6lSV/bquXrPtag/IDsSmka5HHy/4YusRUbdk /92A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u/bLoqu5bQyGRWpRZhOIXLIHXaB/Gyj4IGj7G+sklc4=; b=VaGRZubE3SSR6u546UV9qgABov1zvVfWHvUJDcHSqdfqWRfxCJ9e5JJcGdmBGDKySR aEqoCXtAfR8ofKPdODro1PT0JklatpqwldxPeZGyNDXYsJ+fnzhbxHo/cHJ391gmLxpi brMNstlSSLsfWEOtCDzrNOUxq+VKwI8AQ474YHtaYtKFWF0H4npygc7qDFRzYNf1p9jS Aaf9w/mbB276v29pUhZpR+WqgcCeuBav35ze9VqkH3T78sZ6J2SSmXQhGWb+SiTaZBcm QbI3XGXG3xWVJHVeffCTqLWMCvQkrqJp0NcwxNqHLSw34ATZhFegbB6hlT5GXYNLlK1o FjHg== X-Gm-Message-State: ALoCoQm1bkOl3s5sphclPdZm803C2BGt+U7RwMboXCo5L9Wo+vyOkZcVNux+w7Ua7L8x0oAnFraW MIME-Version: 1.0 X-Received: by 10.107.170.27 with SMTP id t27mr3605602ioe.128.1449065124583; Wed, 02 Dec 2015 06:05:24 -0800 (PST) Received: by 10.107.137.68 with HTTP; Wed, 2 Dec 2015 06:05:24 -0800 (PST) In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> Date: Wed, 2 Dec 2015 15:05:24 +0100 Message-ID: From: Michiel de Jong To: Linhui Sun Content-Type: multipart/alternative; boundary=001a114256bc01f7f80525eac4fc Archived-At: Cc: storagesync , fkooman , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 14:05:33 -0000 --001a114256bc01f7f80525eac4fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cool! I created https://github.com/remotestorage/spec/issues/137 about the need for MOVE verb. Application-level chunking is partially supported by HTTP itself through `Content-Range` headers (although it's not clear whether these are allowed on PUT requests as well as on GET requests, see https://github.com/remotestorage/spec/issues/131). The problem is that HTTP defines versioning at the document level, you cannot ask a server to produce or check an ETag for a specific byte-range of a document, only for the entire document. A comparison document sounds good! See also http://www.servicedenuages.fr/en/generic-storage-ecosystem. Cheers, Michiel. On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun wrote: > That's cool for me, a separate section for this might make sense. > > Another thing is do we need to include an application-layer chunking here > (not just for a browser sync), since if we want to further extend other > capabilities it is essential. > > Regards, > Linhui > > 2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > >> I propose to come up with a list of advantages and disadvantages of usin= g >> WebDAV and compare them against a JSON/REST based approach, like >> remoteStorage. >> >> Does it sound good ? >> >> >> On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: >> >> >> >> 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >> : >> >> >> >> >> >> >> On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: >> >> Hi all! >> Thanks for all your reactions to the remoteStorage Internet-Draft. >> >> We get the question about WebDAV a lot, in the next version we should ad= d >> a remark about it in the intro. The folder descriptions returned when yo= u >> GET a URL that ends with a / are indeed a deviation from the XML returne= d >> by WebDAV server, and this is just because nowadays JSON is easier to us= e >> than XML for developers, both client-side and server-side. >> >> >> >> I totally agree here, this was going to happen soon or later and it is >> really appreciated. >> >> >> >> The fact that we don't require servers to support WebDAV's custom verbs >> like PROPPATCH etc. is for three reasons: >> 1) it's a lot of work to implement this without using an existing WebDAV >> library >> 2) in practice, a lot of WebDAV servers get it wrong, or don't implement >> all of WebDAV. It's very annoying for client implementers to have to dea= l >> with servers that e.g. chose not to implement LOCK and UNLOCK. >> 3) we don't really need all these advanced features on top of standard >> HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple >> folder description format, is enough for most applications. >> >> Other than that, the remoteStorage Internet-Draft specifies a *lot* more >> than just how each HTTP verb should behave: >> * requiring support for OAuth implicit-grant flow >> * requiring ETag support and nested versioning (i.e. the folder's ETag >> changes if anything within that folder changes) >> * requiring CORS headers >> * requiring a WebFinger announcement for service discovery >> It would be easy to add these three things on top of WebDAV, instead of >> putting them on top of our minimal GET/PUT/DELETE API definition. In fac= t, >> we could probably separate it into two Internet-Drafts: one for the >> 'RESTful folders' API which is our simplification of WebDAV, and a secon= d >> one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful >> folders' or whatever other HTTP-based API you want. >> >> >> >> There is one requirement that all synchronisers need to handle: moving >> resources. In this spec the alternative of a WebDAV MOVE is not specifie= d. >> >> It is true that a MOVE could be replaced with a DELETE + UPLOAD but that >> is not acceptable in most cases due to the inefficiency of such operatio= n >> (cpu, bandwidth consumption ...) >> >> Is there a plan to support such basic feature? >> >> From the current remoteStorage spec, the ownCloud sync protocol can be >> implemented. The missing bit is tracking those remote moves. >> >> I agree with Hugo that MOVE is useful, sometimes if you just rename a >> file it will be perfect. But the question I have is that whether we need= to >> make two documents? Multiple choices is not good for standardization. In= my >> view, webdav is something that we need to have a very clear decision on >> whether to consider it or not. >> >> Regards, >> Linhui >> >> >> >> Cheers >> >> >> On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < >> ietf@hugo.labkode.com> wrote: >> >> >> >> >> >> >> On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: >> >> Hi >> >> On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez = Labrador < >> ietf@hugo.labkode.com> wrote: >> >> >> >> >> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >> >> Hi >> >> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : >> >> Hi, >> >> from my point of view the remoteStorage project addresses a subset of >> the use cases of the WebDAV specification. >> >> The main difference I can observe is that the specification is built on >> REST instead of XML-based communication. >> >> >> I personally like much more REST than WebDAV because it is more >> developer friendly and it is faster to develop. >> Maybe the remoteStorage API becomes the next WebDAV :) >> >> However, the remoteStorage API does not provide a way of synchronising >> data, this task is delegated to the developers. >> Is there a plan to provide such feature based on the outcome of this >> draft? >> >> I'm a little bit confused why you say the remoteStorage does not provide >> that. Is that because remoteStorage does not perform like a typical sync >> services (e.g. dropbox...) or you are saying something else? >> >> Yes, because it does not offer synchronisation capabilities. >> >> Got it. And What I am wondering is that do we need to include those >> capabilities in a base specifications. Since it is hard to standardize t= he >> capabilities like dedup or delta. Maybe a better way is to define those = in >> a separate specification, >> >> >> >> >> Thanks for giving these examples - so by 'synchronisation capabilities' >> you mean 1) deduplication and 2) delta updates? Anything else or is that= an >> exhaustive list? >> >> >> >> something like extensions. For a base document, we just need to define >> how to perform sync operations. >> >> >> >> Yes, I agree that may be an extension of this draft could handle the >> synchronisation part. >> >> >> >> >> >> Our Internet-Draft is heavily focused on the world wide web, whose URLs >> are not content-addressable, we can't change that. So that architecture = is >> not very friendly to deduplication, compared to for instance BitTorrent.= As >> you already said, developers can still dedupe on the server-side when >> storing blobs to disk, and can also dedupe on the client side before >> creating the resources the client uploads. >> As far as I know, delta updates are not supported by the ETag system - >> you cannot do a range request to find out if certain bytes within a >> document have changed. However, the folder system we define does encoura= ge >> you, for instance when you develop a To Do List app, put each task on it= s >> own document, and then query the folder to see which of them changed, >> instead of putting them all in one big document and retrieving the whole >> document each time. >> >> Cheers, >> Michiel. >> >> >> >> >> >> >> >> BTW, I want to introduce ClawIO ( >> http://clawio.github.io), a research >> project to benchmark different synchronisation protocols against >> different data backends with special attention to provide a common sync >> API. >> >> A common API for different sync protocols is being created based on the >> architecture specified in this draft (control and data servers) and the >> >> I cannot find a distributed architecture in this draft. It seems that >> they handle metadata and content data together, just like a normal web >> service. >> >> >> ClawIO is fully distributed. Every logical unit is a different server >> than be scaled out. Data and Metadata channels are independent from each >> other and reside on different servers. >> >> That is widely employed in popular sync services. And that is also >> beneficial to privacy to some extent. But in the context of sync in brow= ser >> (which is mainly considered in the remoteStorage), I don't know whether >> this is reasonable. But I think we should deploy distributed architectur= e >> although it will make things complicated. >> >> >> >> Of course, the remoteStorage is targeted to browsers, so syncing does no= t >> make too much sense in this case. >> With the rise of Linux container micro-service based architectures, the >> deployment of such highly complex systems should become easier and fast= er. >> >> Best, >> >> >> Hugo >> >> >> >> Regards, >> Linhui >> >> >> >> >> Regards, >> Linhui >> >> one from the CERN EOS project (management, disk and queue servers). >> >> The Phase I has implemented the ownCloud Sync Protocol and Phase II will >> implement the SeaFile Sync Protocol. >> The choice of these protocols among others is because they are really >> opposed to each other in terms of syncing (delta vs non-delta, >> state-based vs log/event/git-based sync =E2=80=A6), so finding a common = approach >> is more challenging. >> >> Providing a base specification/architecture to measure the feasibility >> of this draft is one of the objectives of the project. >> >> I believe that the work being done here and in ClawIO are supplementary >> to each other and I think mutual collaboration could be beneficial for >> both sides. >> >> Also, if there is interest, the remoteStorage API can be added to >> ClawIO. >> >> Best regards, >> >> Hugo Gonzalez Labrador >> >> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: >> > Send Storagesync mailing list submissions to >> > storagesync@ietf.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > >> https://www.ietf.org/mailman/listinfo/storagesync >> > or, via email, send a message with subject or body 'help' to >> > storagesync-request@ietf.org >> > >> > You can reach the person managing the list at >> > storagesync-owner@ietf.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of Storagesync digest..." >> > Today's Topics: >> > >> > 1. New version of draft-dejong-remotestorage Internet-Draft >> > available (Michiel de Jong) >> > 2. Re: New version of draft-dejong-remotestorage Internet-Draft >> > available (Gihan Dias) >> > 3. Re: New version of draft-dejong-remotestorage Internet-Draft >> > available (Fei Song) >> > _______________________________________________ >> > Storagesync mailing list >> > Storagesync@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/storagesync >> > Email had 3 attachments: >> > + [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> > 2k (message/rfc822) >> > + Re: [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> > 1k (message/rfc822) >> > + Re: [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> > 2k (message/rfc822) >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> >> https://www.ietf.org/mailman/listinfo/storagesync >> >> >> >> >> >> >> >> >> > > --001a114256bc01f7f80525eac4fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cool! I created https://github.com/remotestorage/spe= c/issues/137 about the need for=C2=A0 MOVE verb.

Applicati= on-level chunking is partially supported by HTTP itself through `Content-Ra= nge` headers (although it's not clear whether these are allowed on PUT = requests as well as on GET requests, see https://github.com/remotestorage/spec/issues/131= ). The problem is that HTTP defines versioning at the document level, y= ou cannot ask a server to produce or check an ETag for a specific byte-rang= e of a document, only for the entire document.

A comparison do= cument sounds good! See also http://www.servicedenuages.fr/en/generic-storage-e= cosystem.


Cheers,
Michiel.


On Wed, Dec 2, 2015 at= 2:32 PM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
That's cool for me, a sepa= rate section for this might make sense.

Another thing is= do we need to include an application-layer chunking here (not just for a b= rowser sync), since if we want to further extend other capabilities it is e= ssential.

Regards,
Linhui

2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labra= dor <ietf@hugo.labkode.com>:
I propose to come up with a list of advantages and disadvantages = of using WebDAV and compare them against a JSON/REST based approach, like r= emoteStorage.
=C2=A0
Does it sound good ?
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote:
=C2=A0
=C2=A0
2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:<= br>
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draf= t.
=C2=A0
We get the question about WebDAV a lot, in the next version we s= hould add a remark about it in the intro. The folder descriptions returned = when you GET a URL that ends with a / are indeed a deviation from the XML r= eturned by WebDAV server, and this is just because nowadays JSON is easier = to use than XML for developers, both client-side and server-side.
=C2=A0
=C2=A0
I totally agree here, this was going to happen soon or later and it is= really appreciated.
=C2=A0
=C2=A0
The fact that we don't require servers to suppo= rt WebDAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an exi= sting WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don'= ;t implement all of WebDAV. It's very annoying for client implementers = to have to deal with servers that e.g. chose not to implement LOCK and UNLO= CK.
3) we don't really need all these advanced features on top o= f standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a= simple folder description format, is enough for most applications.<= br>
=C2=A0
Other than that, the remoteStorage Internet-Draft specifies a *l= ot* more than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder&= #39;s ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, ins= tead of putting them on top of our minimal GET/PUT/DELETE API definition. I= n fact, we could probably separate it into two Internet-Drafts: one for the= 'RESTful folders' API which is our simplification of WebDAV, and a= second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or '= RESTful folders' or whatever other HTTP-based API you want.
<= /div>
=C2=A0
=C2=A0
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.= =C2=A0
=C2=A0
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
=C2=A0
Is there a plan to support such basic feature?
=C2=A0
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you j= ust rename a file it will be perfect. But the question I have is that wheth= er we need to make two documents? Multiple choices is not good for standard= ization. In my view, webdav is something that we need to have a very clear = decision on whether to consider it or not.
=C2=A0
Regards,
Linhui
=C2=A0
=C2=A0
Cheers
=C2=A0
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remot= eStorage does not provide that. Is that because remoteStorage does not perf= orm like a typical sync services (e.g. dropbox...) or you are saying someth= ing else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
=C2=A0
=C2=A0
Thanks for giving these examples - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) del= ta=20 updates? Anything else or is that an exhaustive list?
=C2=A0
something like extens= ions. For a base document, we just need to define how to perform sync opera= tions.
=C2=A0
=C2=A0
Yes, I agree that may be an extension of this draft could handle the = synchronisation part.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that archi= tecture is not very friendly to deduplication, compared to for instance Bit= Torrent. As you already said, developers can still dedupe on the server-sid= e when storing blobs to disk, and can also dedupe on the client side before= creating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
=C2=A0
Cheers,
Michiel.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
=C2=A0
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don&#= 39;t know whether this is reasonable. But I think we should deploy distribu= ted architecture although it will make things complicated.
=C2=A0
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=C2=A0
=C2=A0
Hugo
=C2=A0
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (m= anagement, disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0
=C2=A0
=C2=A0


--001a114256bc01f7f80525eac4fc-- From nobody Wed Dec 2 06:30:26 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7F31A9075 for ; Wed, 2 Dec 2015 06:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vpHK55BXFkx for ; Wed, 2 Dec 2015 06:30:18 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1701A9040 for ; Wed, 2 Dec 2015 06:30:17 -0800 (PST) Received: by wmvv187 with SMTP id v187so257664546wmv.1 for ; Wed, 02 Dec 2015 06:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1C2JutME6xB256djh+aiz+raMdAKAw1tuCRt1VP52KQ=; b=sGc73+zstnGSoAz9l3b7L3eF4fKIJSPcTbSITjpc0yyJg776JXRU2kSmh/PPu9RCSH bu0JEDwLhSn+YNvZN/G9NmN2hAeu02FFlN+dVSAj0kj8rDbjXDC9XJIqVejozzvmX1ae YcYU1d9Wc0BCFiyR/jQBut+mE6Fy5BG+MpLrI9omcnbxOcP+XCZiaXdFAhDN440mePX4 5QUlfYkzt5PNKa+VVsNs2rsWLLn8WV3voi5rcV/JnYUZzGlbo/oSxfLFlIgAOcHvlCkY j1R+jj1ElxguadDXiohwAfQd94nyHrbb5PdioVKg2UhnQAyOPwiJuGsQXxjmafi6lOh3 0jzQ== X-Received: by 10.28.89.137 with SMTP id n131mr46561877wmb.9.1449066616359; Wed, 02 Dec 2015 06:30:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 2 Dec 2015 06:29:56 -0800 (PST) In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> From: Linhui Sun Date: Wed, 2 Dec 2015 22:29:56 +0800 Message-ID: To: Michiel de Jong Content-Type: multipart/alternative; boundary=001a1140cdb8ec90b80525eb1c8b Archived-At: Cc: storagesync , fkooman , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 14:30:24 -0000 --001a1140cdb8ec90b80525eb1c8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi 2015-12-02 22:05 GMT+08:00 Michiel de Jong : > Cool! I created https://github.com/remotestorage/spec/issues/137 about > the need for MOVE verb. > > Application-level chunking is partially supported by HTTP itself through > `Content-Range` headers (although it's not clear whether these are allowe= d > on PUT requests as well as on GET requests, see > https://github.com/remotestorage/spec/issues/131). The problem is that > HTTP defines versioning at the document level, you cannot ask a server to > produce or check an ETag for a specific byte-range of a document, only fo= r > the entire document. > Actually what I'm saying is a chunking before transmitting (using http), in this way, they are treated as individual documents from the standpoint of http. But I don't know whether this is appropriate for remoteStorage, just a comment. Regards, Linhui > > A comparison document sounds good! See also > http://www.servicedenuages.fr/en/generic-storage-ecosystem. > > > Cheers, > Michiel. > > > On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun wrote: > >> That's cool for me, a separate section for this might make sense. >> >> Another thing is do we need to include an application-layer chunking her= e >> (not just for a browser sync), since if we want to further extend other >> capabilities it is essential. >> >> Regards, >> Linhui >> >> 2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >> : >> >>> I propose to come up with a list of advantages and disadvantages of >>> using WebDAV and compare them against a JSON/REST based approach, like >>> remoteStorage. >>> >>> Does it sound good ? >>> >>> >>> On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: >>> >>> >>> >>> 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >> >: >>> >>> >>> >>> >>> >>> >>> On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: >>> >>> Hi all! >>> Thanks for all your reactions to the remoteStorage Internet-Draft. >>> >>> We get the question about WebDAV a lot, in the next version we should >>> add a remark about it in the intro. The folder descriptions returned wh= en >>> you GET a URL that ends with a / are indeed a deviation from the XML >>> returned by WebDAV server, and this is just because nowadays JSON is ea= sier >>> to use than XML for developers, both client-side and server-side. >>> >>> >>> >>> I totally agree here, this was going to happen soon or later and it is >>> really appreciated. >>> >>> >>> >>> The fact that we don't require servers to support WebDAV's custom verbs >>> like PROPPATCH etc. is for three reasons: >>> 1) it's a lot of work to implement this without using an existing WebDA= V >>> library >>> 2) in practice, a lot of WebDAV servers get it wrong, or don't implemen= t >>> all of WebDAV. It's very annoying for client implementers to have to de= al >>> with servers that e.g. chose not to implement LOCK and UNLOCK. >>> 3) we don't really need all these advanced features on top of standard >>> HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple >>> folder description format, is enough for most applications. >>> >>> Other than that, the remoteStorage Internet-Draft specifies a *lot* mor= e >>> than just how each HTTP verb should behave: >>> * requiring support for OAuth implicit-grant flow >>> * requiring ETag support and nested versioning (i.e. the folder's ETag >>> changes if anything within that folder changes) >>> * requiring CORS headers >>> * requiring a WebFinger announcement for service discovery >>> It would be easy to add these three things on top of WebDAV, instead of >>> putting them on top of our minimal GET/PUT/DELETE API definition. In fa= ct, >>> we could probably separate it into two Internet-Drafts: one for the >>> 'RESTful folders' API which is our simplification of WebDAV, and a seco= nd >>> one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful >>> folders' or whatever other HTTP-based API you want. >>> >>> >>> >>> There is one requirement that all synchronisers need to handle: moving >>> resources. In this spec the alternative of a WebDAV MOVE is not specifi= ed. >>> >>> It is true that a MOVE could be replaced with a DELETE + UPLOAD but tha= t >>> is not acceptable in most cases due to the inefficiency of such operati= on >>> (cpu, bandwidth consumption ...) >>> >>> Is there a plan to support such basic feature? >>> >>> From the current remoteStorage spec, the ownCloud sync protocol can be >>> implemented. The missing bit is tracking those remote moves. >>> >>> I agree with Hugo that MOVE is useful, sometimes if you just rename a >>> file it will be perfect. But the question I have is that whether we nee= d to >>> make two documents? Multiple choices is not good for standardization. I= n my >>> view, webdav is something that we need to have a very clear decision on >>> whether to consider it or not. >>> >>> Regards, >>> Linhui >>> >>> >>> >>> Cheers >>> >>> >>> On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < >>> ietf@hugo.labkode.com> wrote: >>> >>> >>> >>> >>> >>> >>> On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: >>> >>> Hi >>> >>> On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez= Labrador < >>> ietf@hugo.labkode.com> wrote: >>> >>> >>> >>> >>> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >>> >>> Hi >>> >>> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >>> : >>> >>> Hi, >>> >>> from my point of view the remoteStorage project addresses a subset of >>> the use cases of the WebDAV specification. >>> >>> The main difference I can observe is that the specification is built on >>> REST instead of XML-based communication. >>> >>> >>> I personally like much more REST than WebDAV because it is more >>> developer friendly and it is faster to develop. >>> Maybe the remoteStorage API becomes the next WebDAV :) >>> >>> However, the remoteStorage API does not provide a way of synchronising >>> data, this task is delegated to the developers. >>> Is there a plan to provide such feature based on the outcome of this >>> draft? >>> >>> I'm a little bit confused why you say the remoteStorage does not provid= e >>> that. Is that because remoteStorage does not perform like a typical syn= c >>> services (e.g. dropbox...) or you are saying something else? >>> >>> Yes, because it does not offer synchronisation capabilities. >>> >>> Got it. And What I am wondering is that do we need to include those >>> capabilities in a base specifications. Since it is hard to standardize = the >>> capabilities like dedup or delta. Maybe a better way is to define those= in >>> a separate specification, >>> >>> >>> >>> >>> Thanks for giving these examples - so by 'synchronisation capabilities' >>> you mean 1) deduplication and 2) delta updates? Anything else or is tha= t an >>> exhaustive list? >>> >>> >>> >>> something like extensions. For a base document, we just need to define >>> how to perform sync operations. >>> >>> >>> >>> Yes, I agree that may be an extension of this draft could handle the >>> synchronisation part. >>> >>> >>> >>> >>> >>> Our Internet-Draft is heavily focused on the world wide web, whose URLs >>> are not content-addressable, we can't change that. So that architecture= is >>> not very friendly to deduplication, compared to for instance BitTorrent= . As >>> you already said, developers can still dedupe on the server-side when >>> storing blobs to disk, and can also dedupe on the client side before >>> creating the resources the client uploads. >>> As far as I know, delta updates are not supported by the ETag system - >>> you cannot do a range request to find out if certain bytes within a >>> document have changed. However, the folder system we define does encour= age >>> you, for instance when you develop a To Do List app, put each task on i= ts >>> own document, and then query the folder to see which of them changed, >>> instead of putting them all in one big document and retrieving the whol= e >>> document each time. >>> >>> Cheers, >>> Michiel. >>> >>> >>> >>> >>> >>> >>> >>> BTW, I want to introduce ClawIO ( >>> http://clawio.github.io), a research >>> project to benchmark different synchronisation protocols against >>> different data backends with special attention to provide a common sync >>> API. >>> >>> A common API for different sync protocols is being created based on the >>> architecture specified in this draft (control and data servers) and the >>> >>> I cannot find a distributed architecture in this draft. It seems that >>> they handle metadata and content data together, just like a normal web >>> service. >>> >>> >>> ClawIO is fully distributed. Every logical unit is a different server >>> than be scaled out. Data and Metadata channels are independent from eac= h >>> other and reside on different servers. >>> >>> That is widely employed in popular sync services. And that is also >>> beneficial to privacy to some extent. But in the context of sync in bro= wser >>> (which is mainly considered in the remoteStorage), I don't know whether >>> this is reasonable. But I think we should deploy distributed architectu= re >>> although it will make things complicated. >>> >>> >>> >>> Of course, the remoteStorage is targeted to browsers, so syncing does >>> not make too much sense in this case. >>> With the rise of Linux container micro-service based architectures, the >>> deployment of such highly complex systems should become easier and fas= ter. >>> >>> Best, >>> >>> >>> Hugo >>> >>> >>> >>> Regards, >>> Linhui >>> >>> >>> >>> >>> Regards, >>> Linhui >>> >>> one from the CERN EOS project (management, disk and queue servers). >>> >>> The Phase I has implemented the ownCloud Sync Protocol and Phase II wil= l >>> implement the SeaFile Sync Protocol. >>> The choice of these protocols among others is because they are really >>> opposed to each other in terms of syncing (delta vs non-delta, >>> state-based vs log/event/git-based sync =E2=80=A6), so finding a common= approach >>> is more challenging. >>> >>> Providing a base specification/architecture to measure the feasibility >>> of this draft is one of the objectives of the project. >>> >>> I believe that the work being done here and in ClawIO are supplementary >>> to each other and I think mutual collaboration could be beneficial for >>> both sides. >>> >>> Also, if there is interest, the remoteStorage API can be added to >>> ClawIO. >>> >>> Best regards, >>> >>> Hugo Gonzalez Labrador >>> >>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: >>> > Send Storagesync mailing list submissions to >>> > storagesync@ietf.org >>> > >>> > To subscribe or unsubscribe via the World Wide Web, visit >>> > >>> https://www.ietf.org/mailman/listinfo/storagesync >>> > or, via email, send a message with subject or body 'help' to >>> > storagesync-request@ietf.org >>> > >>> > You can reach the person managing the list at >>> > storagesync-owner@ietf.org >>> > >>> > When replying, please edit your Subject line so it is more specific >>> > than "Re: Contents of Storagesync digest..." >>> > Today's Topics: >>> > >>> > 1. New version of draft-dejong-remotestorage Internet-Draft >>> > available (Michiel de Jong) >>> > 2. Re: New version of draft-dejong-remotestorage Internet-Draft >>> > available (Gihan Dias) >>> > 3. Re: New version of draft-dejong-remotestorage Internet-Draft >>> > available (Fei Song) >>> > _______________________________________________ >>> > Storagesync mailing list >>> > Storagesync@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/storagesync >>> > Email had 3 attachments: >>> > + [Storagesync] New version of draft-dejong-remotestorage >>> > Internet-Draft available >>> > 2k (message/rfc822) >>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>> > Internet-Draft available >>> > 1k (message/rfc822) >>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>> > Internet-Draft available >>> > 2k (message/rfc822) >>> >>> _______________________________________________ >>> Storagesync mailing list >>> Storagesync@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/storagesync >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> > --001a1140cdb8ec90b80525eb1c8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

2015-12-02 22:05 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com= >:
<= div>
Cool! I created https://github.com/remotestorage/spec/issues/1= 37 about the need for=C2=A0 MOVE verb.

Application-level c= hunking is partially supported by HTTP itself through `Content-Range` heade= rs (although it's not clear whether these are allowed on PUT requests a= s well as on GET requests, see https://github.com/remotestorage/spec/is= sues/131). The problem is that HTTP defines versioning at the document = level, you cannot ask a server to produce or check an ETag for a specific b= yte-range of a document, only for the entire document.
Actually what I'm saying is a chunking before = transmitting (using http), in this way, they are treated as individual docu= ments from the standpoint of http. But I don't know whether this is app= ropriate for remoteStorage, just a comment.

Regard= s,
Linhui

A comparison document sounds good! See also http://www.servicedenuages.fr/en/generic-storage-ecosystem.
<= br>
Cheers,
Michiel.

<= div class=3D"h5">

= On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun <lh.sunlinh@gmail.com>= ; wrote:
That'= ;s cool for me, a separate section for this might make sense.

Another thing is do we need to include an application-layer chunking = here (not just for a browser sync), since if we want to further extend othe= r capabilities it is essential.

Regards,
L= inhui

2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:
=
I propose to come up with a list of advantages and disadvantages = of using WebDAV and compare them against a JSON/REST based approach, like r= emoteStorage.
=C2=A0
Does it sound good ?
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote:
=C2=A0
=C2=A0
2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:<= br>
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draf= t.
=C2=A0
We get the question about WebDAV a lot, in the next version we s= hould add a remark about it in the intro. The folder descriptions returned = when you GET a URL that ends with a / are indeed a deviation from the XML r= eturned by WebDAV server, and this is just because nowadays JSON is easier = to use than XML for developers, both client-side and server-side.
=C2=A0
=C2=A0
I totally agree here, this was going to happen soon or later and it is= really appreciated.
=C2=A0
=C2=A0
The fact that we don't require servers to suppo= rt WebDAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an exi= sting WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don'= ;t implement all of WebDAV. It's very annoying for client implementers = to have to deal with servers that e.g. chose not to implement LOCK and UNLO= CK.
3) we don't really need all these advanced features on top o= f standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a= simple folder description format, is enough for most applications.<= br>
=C2=A0
Other than that, the remoteStorage Internet-Draft specifies a *l= ot* more than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder&= #39;s ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, ins= tead of putting them on top of our minimal GET/PUT/DELETE API definition. I= n fact, we could probably separate it into two Internet-Drafts: one for the= 'RESTful folders' API which is our simplification of WebDAV, and a= second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or '= RESTful folders' or whatever other HTTP-based API you want.
<= /div>
=C2=A0
=C2=A0
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.= =C2=A0
=C2=A0
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
=C2=A0
Is there a plan to support such basic feature?
=C2=A0
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you j= ust rename a file it will be perfect. But the question I have is that wheth= er we need to make two documents? Multiple choices is not good for standard= ization. In my view, webdav is something that we need to have a very clear = decision on whether to consider it or not.
=C2=A0
Regards,
Linhui
=C2=A0
=C2=A0
Cheers
=C2=A0
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remot= eStorage does not provide that. Is that because remoteStorage does not perf= orm like a typical sync services (e.g. dropbox...) or you are saying someth= ing else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
=C2=A0
=C2=A0
Thanks for giving these examples - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) del= ta=20 updates? Anything else or is that an exhaustive list?
=C2=A0
something like extens= ions. For a base document, we just need to define how to perform sync opera= tions.
=C2=A0
=C2=A0
Yes, I agree that may be an extension of this draft could handle the = synchronisation part.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that archi= tecture is not very friendly to deduplication, compared to for instance Bit= Torrent. As you already said, developers can still dedupe on the server-sid= e when storing blobs to disk, and can also dedupe on the client side before= creating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
=C2=A0
Cheers,
Michiel.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
=C2=A0
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don&#= 39;t know whether this is reasonable. But I think we should deploy distribu= ted architecture although it will make things complicated.
=C2=A0
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=C2=A0
=C2=A0
Hugo
=C2=A0
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (m= anagement, disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0
=C2=A0
=C2=A0



--001a1140cdb8ec90b80525eb1c8b-- From nobody Wed Dec 2 07:05:51 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72B81A92E3 for ; Wed, 2 Dec 2015 07:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfJ4Z5Iv3ShB for ; Wed, 2 Dec 2015 07:05:44 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5121A9301 for ; Wed, 2 Dec 2015 07:05:44 -0800 (PST) Received: by igcto18 with SMTP id to18so33285641igc.0 for ; Wed, 02 Dec 2015 07:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=27LYvEsWsCmRDNt8yWqHddVfsgCfWRfUlnIjTgyTDuc=; b=kwxFQIPSzro4qoxHpQnZarw90Ip72s9E4+5bDhqhmRCmM2ShQi5sLnDgHGBezGneJW tDNrUXCb0xQPNpmPIjp3FQWeZZmrolC/TiJgM/noRKtgm1LBFbk1lhUb++Ic5rDi15nZ 12fTI1YNI4RWll60gXH2LleDcLvFi8FNcAHeWc3nRMXAxuzrAr8qOf+R8FOWco09IpJV 65ejiP6N/3sdMTw9g87Mxu1/2QTfZOm6qKghgS5Vc0EmgJwfEBAZ/JzJw7bhv4NYuxMJ SmKjGHETvusY6j++cElXyppKogVOBKll0wX2nGki2YW9fCIzZfZ248Xt5lw6FwvDLO0x fOjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=27LYvEsWsCmRDNt8yWqHddVfsgCfWRfUlnIjTgyTDuc=; b=TtLOtfDOx09gRUv6N9n/WHlzCrp1PD6MuOQ+x6zhuJfIWim5d686aIacb9mkHtRNdx a1n2s3XTmuH3dCWjIp7ZLs9Kb8K4F+WotZMcB7Zfyz5ZLBnllmjoeUjgTq0wEmvNvlrY 3i6Rj4OrOeecTLZoXsFfgY1ox/11yCbHVfONxjIvBjyNji90qJXJYNasEnvT1MXBz7gS LiQepjFOzrIOmBQolO0RfaV30EvRBcVuRCQXluGmp1ssT8u5mGtFYGYI5XH8C74Sn4gP 2Csc/n4RjWJR2Bifx7gi1p3M2cGAbZC1BH/Si/Lk1ovSj4ziKGk3vLuROnqPOfMyJuq/ Mo8Q== X-Gm-Message-State: ALoCoQkb5tTQEBBtGmfJH2+4K5PH0wWgcPYVA1X/cOesv9QbyDePeJoFbQ5Hkun78ywyvpbxc4V6 MIME-Version: 1.0 X-Received: by 10.50.57.84 with SMTP id g20mr30788699igq.44.1449068743572; Wed, 02 Dec 2015 07:05:43 -0800 (PST) Received: by 10.107.137.68 with HTTP; Wed, 2 Dec 2015 07:05:43 -0800 (PST) In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> Date: Wed, 2 Dec 2015 16:05:43 +0100 Message-ID: From: Michiel de Jong To: Linhui Sun Content-Type: multipart/alternative; boundary=047d7bdc12eab770ca0525eb9bcd Archived-At: Cc: storagesync , fkooman , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 15:05:50 -0000 --047d7bdc12eab770ca0525eb9bcd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah sure, that's entirely appropriate, remoteStorage treats both the Content-Type header value and the actual body of a document as opaque strings of bytes. It doesn't "care" if you use it to store only data blocks that are chunks of something else. For instance, you could have a folder on a user's storage that contains only inode-like JSON-documents, which list the URLs of binary documents that make up 1Kb blocks of the actual data. Nice for deduping, delta updates, and also renaming files without reuploading their content. But yeah, the argument is that *how* to create and manage these chunks, is then still left up to the application developer (or to another spec on top of the remoteStorage spec). Cheers, Michiel. On Wed, Dec 2, 2015 at 3:29 PM, Linhui Sun wrote: > Hi > > 2015-12-02 22:05 GMT+08:00 Michiel de Jong : > >> Cool! I created https://github.com/remotestorage/spec/issues/137 about >> the need for MOVE verb. >> >> Application-level chunking is partially supported by HTTP itself through >> `Content-Range` headers (although it's not clear whether these are allow= ed >> on PUT requests as well as on GET requests, see >> https://github.com/remotestorage/spec/issues/131). The problem is that >> HTTP defines versioning at the document level, you cannot ask a server t= o >> produce or check an ETag for a specific byte-range of a document, only f= or >> the entire document. >> > Actually what I'm saying is a chunking before transmitting (using http), > in this way, they are treated as individual documents from the standpoint > of http. But I don't know whether this is appropriate for remoteStorage, > just a comment. > > Regards, > Linhui > >> >> A comparison document sounds good! See also >> http://www.servicedenuages.fr/en/generic-storage-ecosystem. >> >> >> Cheers, >> Michiel. >> >> >> On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun wrote: >> >>> That's cool for me, a separate section for this might make sense. >>> >>> Another thing is do we need to include an application-layer chunking >>> here (not just for a browser sync), since if we want to further extend >>> other capabilities it is essential. >>> >>> Regards, >>> Linhui >>> >>> 2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >> >: >>> >>>> I propose to come up with a list of advantages and disadvantages of >>>> using WebDAV and compare them against a JSON/REST based approach, like >>>> remoteStorage. >>>> >>>> Does it sound good ? >>>> >>>> >>>> On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: >>>> >>>> >>>> >>>> 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador < >>>> ietf@hugo.labkode.com>: >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: >>>> >>>> Hi all! >>>> Thanks for all your reactions to the remoteStorage Internet-Draft. >>>> >>>> We get the question about WebDAV a lot, in the next version we should >>>> add a remark about it in the intro. The folder descriptions returned w= hen >>>> you GET a URL that ends with a / are indeed a deviation from the XML >>>> returned by WebDAV server, and this is just because nowadays JSON is e= asier >>>> to use than XML for developers, both client-side and server-side. >>>> >>>> >>>> >>>> I totally agree here, this was going to happen soon or later and it is >>>> really appreciated. >>>> >>>> >>>> >>>> The fact that we don't require servers to support WebDAV's custom verb= s >>>> like PROPPATCH etc. is for three reasons: >>>> 1) it's a lot of work to implement this without using an existing >>>> WebDAV library >>>> 2) in practice, a lot of WebDAV servers get it wrong, or don't >>>> implement all of WebDAV. It's very annoying for client implementers to= have >>>> to deal with servers that e.g. chose not to implement LOCK and UNLOCK. >>>> 3) we don't really need all these advanced features on top of standard >>>> HTTP, just supporting GET/PUT/DELETE for resources, and adding a simpl= e >>>> folder description format, is enough for most applications. >>>> >>>> Other than that, the remoteStorage Internet-Draft specifies a *lot* >>>> more than just how each HTTP verb should behave: >>>> * requiring support for OAuth implicit-grant flow >>>> * requiring ETag support and nested versioning (i.e. the folder's ETag >>>> changes if anything within that folder changes) >>>> * requiring CORS headers >>>> * requiring a WebFinger announcement for service discovery >>>> It would be easy to add these three things on top of WebDAV, instead o= f >>>> putting them on top of our minimal GET/PUT/DELETE API definition. In f= act, >>>> we could probably separate it into two Internet-Drafts: one for the >>>> 'RESTful folders' API which is our simplification of WebDAV, and a sec= ond >>>> one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful >>>> folders' or whatever other HTTP-based API you want. >>>> >>>> >>>> >>>> There is one requirement that all synchronisers need to handle: moving >>>> resources. In this spec the alternative of a WebDAV MOVE is not specif= ied. >>>> >>>> It is true that a MOVE could be replaced with a DELETE + UPLOAD but >>>> that is not acceptable in most cases due to the inefficiency of such >>>> operation (cpu, bandwidth consumption ...) >>>> >>>> Is there a plan to support such basic feature? >>>> >>>> From the current remoteStorage spec, the ownCloud sync protocol can be >>>> implemented. The missing bit is tracking those remote moves. >>>> >>>> I agree with Hugo that MOVE is useful, sometimes if you just rename a >>>> file it will be perfect. But the question I have is that whether we ne= ed to >>>> make two documents? Multiple choices is not good for standardization. = In my >>>> view, webdav is something that we need to have a very clear decision o= n >>>> whether to consider it or not. >>>> >>>> Regards, >>>> Linhui >>>> >>>> >>>> >>>> Cheers >>>> >>>> >>>> On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < >>>> ietf@hugo.labkode.com> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: >>>> >>>> Hi >>>> >>>> On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1le= z Labrador < >>>> ietf@hugo.labkode.com> wrote: >>>> >>>> >>>> >>>> >>>> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >>>> >>>> Hi >>>> >>>> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >>> >: >>>> >>>> Hi, >>>> >>>> from my point of view the remoteStorage project addresses a subset of >>>> the use cases of the WebDAV specification. >>>> >>>> The main difference I can observe is that the specification is built o= n >>>> REST instead of XML-based communication. >>>> >>>> >>>> I personally like much more REST than WebDAV because it is more >>>> developer friendly and it is faster to develop. >>>> Maybe the remoteStorage API becomes the next WebDAV :) >>>> >>>> However, the remoteStorage API does not provide a way of synchronising >>>> data, this task is delegated to the developers. >>>> Is there a plan to provide such feature based on the outcome of this >>>> draft? >>>> >>>> I'm a little bit confused why you say the remoteStorage does not >>>> provide that. Is that because remoteStorage does not perform like a ty= pical >>>> sync services (e.g. dropbox...) or you are saying something else? >>>> >>>> Yes, because it does not offer synchronisation capabilities. >>>> >>>> Got it. And What I am wondering is that do we need to include those >>>> capabilities in a base specifications. Since it is hard to standardize= the >>>> capabilities like dedup or delta. Maybe a better way is to define thos= e in >>>> a separate specification, >>>> >>>> >>>> >>>> >>>> Thanks for giving these examples - so by 'synchronisation capabilities= ' >>>> you mean 1) deduplication and 2) delta updates? Anything else or is th= at an >>>> exhaustive list? >>>> >>>> >>>> >>>> something like extensions. For a base document, we just need to define >>>> how to perform sync operations. >>>> >>>> >>>> >>>> Yes, I agree that may be an extension of this draft could handle the >>>> synchronisation part. >>>> >>>> >>>> >>>> >>>> >>>> Our Internet-Draft is heavily focused on the world wide web, whose URL= s >>>> are not content-addressable, we can't change that. So that architectur= e is >>>> not very friendly to deduplication, compared to for instance BitTorren= t. As >>>> you already said, developers can still dedupe on the server-side when >>>> storing blobs to disk, and can also dedupe on the client side before >>>> creating the resources the client uploads. >>>> As far as I know, delta updates are not supported by the ETag system - >>>> you cannot do a range request to find out if certain bytes within a >>>> document have changed. However, the folder system we define does encou= rage >>>> you, for instance when you develop a To Do List app, put each task on = its >>>> own document, and then query the folder to see which of them changed, >>>> instead of putting them all in one big document and retrieving the who= le >>>> document each time. >>>> >>>> Cheers, >>>> Michiel. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> BTW, I want to introduce ClawIO ( >>>> http://clawio.github.io), a research >>>> project to benchmark different synchronisation protocols against >>>> different data backends with special attention to provide a common syn= c >>>> API. >>>> >>>> A common API for different sync protocols is being created based on th= e >>>> architecture specified in this draft (control and data servers) and th= e >>>> >>>> I cannot find a distributed architecture in this draft. It seems that >>>> they handle metadata and content data together, just like a normal web >>>> service. >>>> >>>> >>>> ClawIO is fully distributed. Every logical unit is a different server >>>> than be scaled out. Data and Metadata channels are independent from ea= ch >>>> other and reside on different servers. >>>> >>>> That is widely employed in popular sync services. And that is also >>>> beneficial to privacy to some extent. But in the context of sync in br= owser >>>> (which is mainly considered in the remoteStorage), I don't know whethe= r >>>> this is reasonable. But I think we should deploy distributed architect= ure >>>> although it will make things complicated. >>>> >>>> >>>> >>>> Of course, the remoteStorage is targeted to browsers, so syncing does >>>> not make too much sense in this case. >>>> With the rise of Linux container micro-service based architectures, th= e >>>> deployment of such highly complex systems should become easier and fa= ster. >>>> >>>> Best, >>>> >>>> >>>> Hugo >>>> >>>> >>>> >>>> Regards, >>>> Linhui >>>> >>>> >>>> >>>> >>>> Regards, >>>> Linhui >>>> >>>> one from the CERN EOS project (management, disk and queue servers). >>>> >>>> The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll >>>> implement the SeaFile Sync Protocol. >>>> The choice of these protocols among others is because they are really >>>> opposed to each other in terms of syncing (delta vs non-delta, >>>> state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach >>>> is more challenging. >>>> >>>> Providing a base specification/architecture to measure the feasibility >>>> of this draft is one of the objectives of the project. >>>> >>>> I believe that the work being done here and in ClawIO are supplementar= y >>>> to each other and I think mutual collaboration could be beneficial for >>>> both sides. >>>> >>>> Also, if there is interest, the remoteStorage API can be added to >>>> ClawIO. >>>> >>>> Best regards, >>>> >>>> Hugo Gonzalez Labrador >>>> >>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: >>>> > Send Storagesync mailing list submissions to >>>> > storagesync@ietf.org >>>> > >>>> > To subscribe or unsubscribe via the World Wide Web, visit >>>> > >>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> > or, via email, send a message with subject or body 'help' to >>>> > storagesync-request@ietf.org >>>> > >>>> > You can reach the person managing the list at >>>> > storagesync-owner@ietf.org >>>> > >>>> > When replying, please edit your Subject line so it is more specific >>>> > than "Re: Contents of Storagesync digest..." >>>> > Today's Topics: >>>> > >>>> > 1. New version of draft-dejong-remotestorage Internet-Draft >>>> > available (Michiel de Jong) >>>> > 2. Re: New version of draft-dejong-remotestorage Internet-Draft >>>> > available (Gihan Dias) >>>> > 3. Re: New version of draft-dejong-remotestorage Internet-Draft >>>> > available (Fei Song) >>>> > _______________________________________________ >>>> > Storagesync mailing list >>>> > Storagesync@ietf.org >>>> > >>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> > Email had 3 attachments: >>>> > + [Storagesync] New version of draft-dejong-remotestorage >>>> > Internet-Draft available >>>> > 2k (message/rfc822) >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>>> > Internet-Draft available >>>> > 1k (message/rfc822) >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>>> > Internet-Draft available >>>> > 2k (message/rfc822) >>>> >>>> _______________________________________________ >>>> Storagesync mailing list >>>> Storagesync@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/storagesync >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > --047d7bdc12eab770ca0525eb9bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah sure, that's entirely appropriate, r= emoteStorage treats both the Content-Type header value and the actual body = of a document as opaque strings of bytes. It doesn't "care" i= f you use it to store only data blocks that are chunks of something else.
For instance, you could have a folder on a user's stor= age that contains only inode-like JSON-documents, which list the URLs of bi= nary documents that make up 1Kb blocks of the actual data. Nice for dedupin= g, delta updates, and also renaming files without reuploading their content= .

But yeah, the argument is that *how* to create an= d manage these chunks, is then still left up to the application developer (= or to another spec on top of the remoteStorage spec).


Chee= rs,
Michiel.

On Wed, Dec 2, 2015 at 3:29 PM, Linhui Sun = <lh.sunlinh@gm= ail.com> wrote:
Hi

2015-12-02 22:05 GMT+08:00 Michiel de Jong <mbdejong@mozilla.co= m>:
<= div>
Cool! I created https://github.com/remotestorage/spec/iss= ues/137 about the need for=C2=A0 MOVE verb.

Application-le= vel chunking is partially supported by HTTP itself through `Content-Range` = headers (although it's not clear whether these are allowed on PUT reque= sts as well as on GET requests, see https://github.com/remotestorage/sp= ec/issues/131). The problem is that HTTP defines versioning at the docu= ment level, you cannot ask a server to produce or check an ETag for a speci= fic byte-range of a document, only for the entire document.
=
Actually what I'm saying is a chun= king before transmitting (using http), in this way, they are treated as ind= ividual documents from the standpoint of http. But I don't know whether= this is appropriate for remoteStorage, just a comment.

Regards,
Linhui

A comparison docu= ment sounds good! See also http://www.servicedenuages.fr/en/g= eneric-storage-ecosystem.


Cheers,
Michiel.

On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
That= 's cool for me, a separate section for this might make sense.

<= /div>
Another thing is do we need to include an application-layer chunk= ing here (not just for a browser sync), since if we want to further extend = other capabilities it is essential.

Regards,
Linhui

2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador = <ietf@hugo.labkode.com>:
I propose to come up with a list of advantages and disadvantages = of using WebDAV and compare them against a JSON/REST based approach, like r= emoteStorage.
=C2=A0
Does it sound good ?
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote:
=C2=A0
=C2=A0
2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:<= br>
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draf= t.
=C2=A0
We get the question about WebDAV a lot, in the next version we s= hould add a remark about it in the intro. The folder descriptions returned = when you GET a URL that ends with a / are indeed a deviation from the XML r= eturned by WebDAV server, and this is just because nowadays JSON is easier = to use than XML for developers, both client-side and server-side.
=C2=A0
=C2=A0
I totally agree here, this was going to happen soon or later and it is= really appreciated.
=C2=A0
=C2=A0
The fact that we don't require servers to suppo= rt WebDAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an exi= sting WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don'= ;t implement all of WebDAV. It's very annoying for client implementers = to have to deal with servers that e.g. chose not to implement LOCK and UNLO= CK.
3) we don't really need all these advanced features on top o= f standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a= simple folder description format, is enough for most applications.<= br>
=C2=A0
Other than that, the remoteStorage Internet-Draft specifies a *l= ot* more than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder&= #39;s ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, ins= tead of putting them on top of our minimal GET/PUT/DELETE API definition. I= n fact, we could probably separate it into two Internet-Drafts: one for the= 'RESTful folders' API which is our simplification of WebDAV, and a= second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or '= RESTful folders' or whatever other HTTP-based API you want.
<= /div>
=C2=A0
=C2=A0
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.= =C2=A0
=C2=A0
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
=C2=A0
Is there a plan to support such basic feature?
=C2=A0
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you j= ust rename a file it will be perfect. But the question I have is that wheth= er we need to make two documents? Multiple choices is not good for standard= ization. In my view, webdav is something that we need to have a very clear = decision on whether to consider it or not.
=C2=A0
Regards,
Linhui
=C2=A0
=C2=A0
Cheers
=C2=A0
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remot= eStorage does not provide that. Is that because remoteStorage does not perf= orm like a typical sync services (e.g. dropbox...) or you are saying someth= ing else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
=C2=A0
=C2=A0
Thanks for giving these examples - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) del= ta=20 updates? Anything else or is that an exhaustive list?
=C2=A0
something like extens= ions. For a base document, we just need to define how to perform sync opera= tions.
=C2=A0
=C2=A0
Yes, I agree that may be an extension of this draft could handle the = synchronisation part.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that archi= tecture is not very friendly to deduplication, compared to for instance Bit= Torrent. As you already said, developers can still dedupe on the server-sid= e when storing blobs to disk, and can also dedupe on the client side before= creating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
=C2=A0
Cheers,
Michiel.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
=C2=A0
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don&#= 39;t know whether this is reasonable. But I think we should deploy distribu= ted architecture although it will make things complicated.
=C2=A0
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=C2=A0
=C2=A0
Hugo
=C2=A0
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (m= anagement, disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0
=C2=A0
=C2=A0




--047d7bdc12eab770ca0525eb9bcd-- From nobody Wed Dec 2 07:37:16 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F263A1A90D1 for ; Wed, 2 Dec 2015 07:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuSlzdcHimQN for ; Wed, 2 Dec 2015 07:37:09 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0C81A90D0 for ; Wed, 2 Dec 2015 07:37:08 -0800 (PST) Received: by qgec40 with SMTP id c40so35560083qge.2 for ; Wed, 02 Dec 2015 07:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=0iAnDs3F+QcfMdRsig4OEFFGZQgY2B9DZHHGVNOmP3c=; b=Qe5h/rSvj8H715q0p7Tl5FPDFzgd+v+RmyEejrtbfHuCRzDxDLtuK4HFo8o7UWVoJq +bmCCay2ZYEqwhPSSSDU9hsM97nsNyBWb+jo1noOLcEUVbRoG/gufqfgXFbaEZ2VL9Vm MutCaSsquQ6BF3GMmALrMZ6j7uCEaoAsdG/9gJ4QPz7AJbwt+1LLJLB0YhPRHbI00Xci yDZoegkEBbrhwXNregjiq78imsHmrcduKFiwQVbEqu6ZFGWvgmyMU2bl+m8qGIov/IC6 fCtDWkgasrVr+d9N2Z12eIDXHdPjOWcDlG3sS6exYcMaFNmO4ei7G1QysSZ6AQTPL8AE xNeA== X-Received: by 10.140.27.238 with SMTP id 101mr4770353qgx.4.1449070627746; Wed, 02 Dec 2015 07:37:07 -0800 (PST) Received: from [127.0.0.1] (ec2-52-70-63-168.compute-1.amazonaws.com. [52.70.63.168]) by smtp.gmail.com with ESMTPSA id z65sm1399175qhb.22.2015.12.02.07.37.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 07:37:06 -0800 (PST) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14490706262430.07383038755506277" From: Linhui Sun To: Michiel de Jong In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> Date: Wed, 02 Dec 2015 23:36:58 +0800 X-Cm-Message-Id: 1449070626120761df696ade6fa5ec1fae4c35dae591bdb9565f10221d86a248836388 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0NDkwNzA2MTgwMDAiLCJjIiwiMTUxOTM5MTI5MTk2ODkzMDAyMCIsInYiLDFd X-Mailer: CloudMagic Message-Id: <1449070626419-021b1ac3-2a56d9db-c17be220@gmail.com> MIME-Version: 1.0 Archived-At: Cc: storagesync , fkooman , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 15:37:14 -0000 ------sinikael-?=_1-14490706262430.07383038755506277 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sounds reasonable! How to perform this chunking and how to manage chunks = should be left for the higher level. Thanks for that : ) On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 23:05, Michiel de Jong = wrote: Ah sure, that's entirely appropriate, = remoteStorage treats both the Content-Type header value and the actual body= of a document as opaque strings of bytes. It doesn't "care" if you use it = to store only data blocks that are chunks of something else. For instance, you could have a folder on a user's storage that contains = only inode-like JSON-documents, which list the URLs of binary documents = that make up 1Kb blocks of the actual data. Nice for deduping, delta = updates, and also renaming files without reuploading their content. But yeah, the argument is that *how* to create and manage these chunks, is = then still left up to the application developer (or to another spec on top = of the remoteStorage spec). Cheers, Michiel. On Wed, Dec 2, 2015 at 3:29= PM, Linhui Sun < lh.sunlinh@gmail.com [lh.sunlinh@gmail.com] > wrote: Hi 2015-12-02 22:05 GMT+08:00 Michiel de Jong < mbdejong@mozilla.com = [mbdejong@mozilla.com] > : Cool! I created [https://github.= com/remotestorage/spec/issues/137] https://github.com/remotestorage/spec/is= sues/137 [https://github.com/remotestorage/spec/issues/137] about the need = for MOVE verb. Application-level chunking is partially supported by HTTP = itself through `Content-Range` headers (although it's not clear whether = these are allowed on PUT requests as well as on GET requests, see = [https://github.com/remotestorage/spec/issues/131] https://github.= com/remotestorage/spec/issues/131 [https://github.com/remotestorage/spec/is= sues/131] ). The problem is that HTTP defines versioning at the document = level, you cannot ask a server to produce or check an ETag for a specific = byte-range of a document, only for the entire document. Actually what I'm saying is a chunking before transmitting (using http), in= this way, they are treated as individual documents from the standpoint of = http. But I don't know whether this is appropriate for remoteStorage, just = a comment. Regards, Linhui A comparison document sounds good! See also = [http://www.servicedenuages.fr/en/generic-storage-ecosystem] http://www.= servicedenuages.fr/en/generic-storage-ecosystem [http://www.servicedenuages= .fr/en/generic-storage-ecosystem] . Cheers, Michiel. On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun < lh.sunlinh@gmail.com [lh.= sunlinh@gmail.com] > wrote: That's cool for me, a separate section for this= might make sense. Another thing is do we need to include an = application-layer chunking here (not just for a browser sync), since if we = want to further extend other capabilities it is essential. Regards, Linhui 2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador < ietf@hugo.labkode.= com [ietf@hugo.labkode.com] > : I propose to come up with a list of = advantages and disadvantages of using WebDAV and compare them against a = JSON/REST based approach, like remoteStorage. Does it sound good ? On Wed, = Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: 2015-12-02 20:43 GMT+08:00 Hugo= Gonz=C3=A1lez Labrador < ietf@hugo.labkode.com [ietf@hugo.labkode.com] > : On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: Hi all! Thanks for all your reactions to the remoteStorage Internet-Draft. We get the question about WebDAV a lot, in the next version we should add a remark about it in the intro. The folder descriptions returned when you GET= a URL that ends with a / are indeed a deviation from the XML returned by = WebDAV server, and this is just because nowadays JSON is easier to use than= XML for developers, both client-side and server-side. I totally agree here, this was going to happen soon or later and it is = really appreciated. The fact that we don't require servers to support = WebDAV's custom verbs like PROPPATCH etc. is for three reasons: 1) it's a lot of work to implement this without using an existing WebDAV = library 2) in practice, a lot of WebDAV servers get it wrong, or don't = implement all of WebDAV. It's very annoying for client implementers to have= to deal with servers that e.g. chose not to implement LOCK and UNLOCK. 3) we don't really need all these advanced features on top of standard HTTP= , just supporting GET/PUT/DELETE for resources, and adding a simple folder description format, is enough for most applications. Other than that, the remoteStorage Internet-Draft specifies a *lot* more = than just how each HTTP verb should behave: * requiring support for OAuth = implicit-grant flow * requiring ETag support and nested versioning (i.e. = the folder's ETag changes if anything within that folder changes) * requiring CORS headers * requiring a WebFinger announcement for service = discovery It would be easy to add these three things on top of WebDAV, = instead of putting them on top of our minimal GET/PUT/DELETE API definition= . In fact, we could probably separate it into two Internet-Drafts: one for = the 'RESTful folders' API which is our simplification of WebDAV, and a = second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or = 'RESTful folders' or whatever other HTTP-based API you want. There is one requirement that all synchronisers need to handle: moving resources. In this spec the alternative of a WebDAV MOVE is not specified. It is true that a MOVE could be replaced with a DELETE + UPLOAD but that is= not acceptable in most cases due to the inefficiency of such operation = (cpu, bandwidth consumption ...) Is there a plan to support such basic = feature? >From the current remoteStorage spec, the ownCloud sync protocol = can be implemented. The missing bit is tracking those remote moves. I agree with Hugo that MOVE is useful, sometimes if you just rename a file = it will be perfect. But the question I have is that whether we need to make= two documents? Multiple choices is not good for standardization. In my = view, webdav is something that we need to have a very clear decision on = whether to consider it or not. Regards, Linhui Cheers On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < ietf@hugo.= labkode.com [ietf@hugo.labkode.com] > wrote: On Wed, Dec 2, 2015, at 11:18= AM, Linhui Sun wrote: Hi On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at = 17:56, Hugo Gonz=C3=A1lez Labrador < ietf@hugo.labkode.com [ietf@hugo.= labkode.com] > wrote: On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: Hi 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador < ietf@hugo.= labkode.com [ietf@hugo.labkode.com] > : Hi, from my point of view the = remoteStorage project addresses a subset of the use cases of the WebDAV = specification. The main difference I can observe is that the specification = is built on REST instead of XML-based communication. I personally like much more REST than WebDAV because it is more developer friendly and it is faster to develop. Maybe the remoteStorage API= becomes the next WebDAV :) However, the remoteStorage API does not provide= a way of synchronising data, this task is delegated to the developers. Is there a plan to provide such feature based on the outcome of this draft? I'm a little bit confused why you say the remoteStorage does not provide = that. Is that because remoteStorage does not perform like a typical sync = services (e.g. dropbox...) or you are saying something else? Yes, because it does not offer synchronisation capabilities. Got it. And What I am wondering is that do we need to include those = capabilities in a base specifications. Since it is hard to standardize the = capabilities like dedup or delta. Maybe a better way is to define those in = a separate specification, Thanks for giving these examples - so by = 'synchronisation capabilities' you mean 1) deduplication and 2) delta = updates? Anything else or is that an exhaustive list? something like extensions. For a base document, we just need to define how = to perform sync operations. Yes, I agree that may be an extension of this = draft could handle the synchronisation part. Our Internet-Draft is heavily = focused on the world wide web, whose URLs are not content-addressable, we = can't change that. So that architecture is not very friendly to deduplication, compared to for instance BitTorrent. As you = already said, developers can still dedupe on the server-side when storing = blobs to disk, and can also dedupe on the client side before creating the = resources the client uploads. As far as I know, delta updates are not = supported by the ETag system - you cannot do a range request to find out if= certain bytes within a document have changed. However, the folder system = we define does encourage you, for instance when you develop a To Do List = app, put each task on its own document, and then query the folder to see = which of them changed, instead of putting them all in one big document and retrieving the whole document each time. Cheers, Michiel. BTW, I want to introduce ClawIO ( [http://clawio.github.io] = [http://clawio.github.io] http://clawio.github.io [http://clawio.github.io]= ), a research project to benchmark different synchronisation protocols = against different data backends with special attention to provide a common = sync API. A common API for different sync protocols is being created based = on the architecture specified in this draft (control and data servers) and = the I cannot find a distributed architecture in this draft. It seems that = they handle metadata and content data together, just like a normal web = service. ClawIO is fully distributed. Every logical unit is a different = server than be scaled out. Data and Metadata channels are independent from = each other and reside on different servers. That is widely employed in = popular sync services. And that is also beneficial to privacy to some extent. But in the context of sync in browser (which is = mainly considered in the remoteStorage), I don't know whether this is = reasonable. But I think we should deploy distributed architecture although = it will make things complicated. Of course, the remoteStorage is targeted = to browsers, so syncing does not make too much sense in this case. With the rise of Linux container micro-service based architectures, the deployment of such highly complex systems should become easier and faster. Best, Hugo Regards, Linhui Regards, Linhui one from the CERN EOS project = (management, disk and queue servers). The Phase I has implemented the = ownCloud Sync Protocol and Phase II will implement the SeaFile Sync = Protocol. The choice of these protocols among others is because they are = really opposed to each other in terms of syncing (delta vs non-delta, state-based vs log/event/git-based sync =E2=80=A6), so finding a common = approach is more challenging. Providing a base specification/architecture = to measure the feasibility of this draft is one of the objectives of the = project. I believe that the work being done here and in ClawIO are = supplementary to each other and I think mutual collaboration could be = beneficial for both sides. Also, if there is interest, the remoteStorage = API can be added to ClawIO. Best regards, Hugo Gonzalez Labrador On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org = [storagesync-request@ietf.org] wrote: > Send Storagesync mailing list = submissions to > storagesync@ietf.org [storagesync@ietf.org] > > To subscribe or unsubscribe via the World Wide Web, visit > [https://www.ietf.org/mailman/listinfo/storagesync] [https://www.ietf.= org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/sto= ragesync [https://www.ietf.org/mailman/listinfo/storagesync] > or, via email, send a message with subject or body 'help' to > storagesync-request@ietf.org [storagesync-request@ietf.org] > > You can reach the person managing the list at > storagesync-owner@ietf.= org [storagesync-owner@ietf.org] > > When replying, please edit your = Subject line so it is more specific > than "Re: Contents of Storagesync = digest..." > Today's Topics: > > 1. New version of draft-dejong-remotestora= ge Internet-Draft > available (Michiel de Jong) > 2. Re: New version of = draft-dejong-remotestorage Internet-Draft > available (Gihan Dias) > 3. Re: New version of draft-dejong-remotestorage Internet-Draft > available (Fei Song) > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org [Storagesync@ietf.org] > [https://www.ietf.org/mailman/listinfo/storagesync] [https://www.ietf.= org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/sto= ragesync [https://www.ietf.org/mailman/listinfo/storagesync] > Email had 3 attachments: > + [Storagesync] New version of = draft-dejong-remotestorage > Internet-Draft available > 2k (message/rfc822) > + Re: [Storagesync] New version of draft-dejong-remotestorage > Internet-Draft available > 1k (message/rfc822) > + Re: [Storagesync] New = version of draft-dejong-remotestorage > Internet-Draft available > 2k (message/rfc822) _______________________________________________ Storagesync mailing list Storagesync@ietf.org [Storagesync@ietf.org] [https://www.ietf.org/mailman/listinfo/storagesync] [https://www.ietf.= org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/sto= ragesync [https://www.ietf.org/mailman/listinfo/storagesync] ------sinikael-?=_1-14490706262430.07383038755506277 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sounds reasonable! How to perform this chunking and how to manage chunks = should be left for the higher level. Thanks for that : )

On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 23:05, Michiel de Jong = <mbdejong@mozilla.com> wrote:
Ah sure, that's entirely appropriate, = remoteStorage treats both the Content-Type header value and the actual body= of a document as opaque strings of bytes. It doesn't "care" if you use it = to store only data blocks that are chunks of something else.=

For instance, you could have a folder on a user's = storage that contains only inode-like JSON-documents, which list the URLs = of binary documents that make up 1Kb blocks of the actual data. Nice for = deduping, delta updates, and also renaming files without reuploading their = content.

But yeah, the argument is that *how* to = create and manage these chunks, is then still left up to the application = developer (or to another spec on top of the remoteStorage spec).=


Cheers,
Michiel.

On Wed, Dec 2, 2015 at= 3:29 PM, Linhui Sun <lh.sunlinh@gmail.com> = wrote:
Hi

2015-12-02 22:05= GMT+08:00 Michiel de Jong <mbdejong@mozilla.= com>:
Cool! I created https://github.= com/remotestorage/spec/issues/137 about the need for MOVE verb.=

Application-level chunking is partially supported by HTTP = itself through `Content-Range` headers (although it's not clear whether = these are allowed on PUT requests as well as on GET requests, see https://github.= com/remotestorage/spec/issues/131). The problem is that HTTP defines = versioning at the document level, you cannot ask a server to produce or = check an ETag for a specific byte-range of a document, only for the entire = document.
Actually what I'm = saying is a chunking before transmitting (using http), in this way, they = are treated as individual documents from the standpoint of http. But I = don't know whether this is appropriate for remoteStorage, just a comment.=

Regards,
Linhui

A comparison document sounds good! See= also http://www.servicedenuages.fr/en/generic-storage-ecosystem.=


Cheers,
Michiel.


On Wed, Dec 2, 2015 at= 2:32 PM, Linhui Sun <lh.sunlinh@gmail.com> = wrote:
That's = cool for me, a separate section for this might make sense.=

Another thing is do we need to include an = application-layer chunking here (not just for a browser sync), since if we = want to further extend other capabilities it is essential.=

Regards,
Linhui

2015-12-02 = 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.= com>:
I propose to come up with a list of advantages and disadvantages = of using WebDAV and compare them against a JSON/REST based approach, like = remoteStorage.
Does it sound good ?=
On Wed, Dec 2, 2015, at = 01:59 PM, Linhui Sun wrote:
=
2015-12-02 20:43 GMT+08:00 Hugo = Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:

On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong = wrote:
Hi all!
Thanks for all your reactions to the remoteStorage = Internet-Draft.
We get the question about WebDAV a lot, in the next version we = should add a remark about it in the intro. The folder descriptions returned= when you GET a URL that ends with a / are indeed a deviation from the XML = returned by WebDAV server, and this is just because nowadays JSON is easier= to use than XML for developers, both client-side and server-side.=
I totally agree here, this was going to happen soon or later and it is= really appreciated.
<= div>The fact that we don't require servers to support WebDAV's custom= verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an = existing WebDAV library
2) in practice, = a lot of WebDAV servers get it wrong, or don't implement all of WebDAV. = It's very annoying for client implementers to have to deal with servers = that e.g. chose not to implement LOCK and UNLOCK.
3) we don't really need all these advanced features on top of = standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a = simple folder description format, is enough for most applications.=
Other than that, the = remoteStorage Internet-Draft specifies a *lot* more than just how each HTTP= verb should behave:
* requiring support= for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the = folder's ETag changes if anything within that folder = changes)
* requiring CORS = headers
* requiring a WebFinger = announcement for service discovery
It would be easy to add these three things on top of WebDAV, = instead of putting them on top of our minimal GET/PUT/DELETE API definition= . In fact, we could probably separate it into two Internet-Drafts: one for = the 'RESTful folders' API which is our simplification of WebDAV, and a = second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or = 'RESTful folders' or whatever other HTTP-based API you want.=
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.=
It is true that a MOVE could be replaced with= a DELETE + UPLOAD but that is not acceptable in most cases due to the = inefficiency of such operation (cpu, bandwidth consumption ...)
Is there a plan to support such basic feature?
From the current remoteStorage spec, the ownCloud sync = protocol can be implemented. The missing bit is tracking those remote moves= .
I agree with Hugo that MOVE is useful,= sometimes if you just rename a file it will be perfect. But the question I= have is that whether we need to make two documents? Multiple choices is = not good for standardization. In my view, webdav is something that we need = to have a very clear decision on whether to consider it or not.
Regards,
Linhui
Cheers
On Wed, Dec 2, 2015 at 11:28 AM= , Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> = wrote:

On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun = wrote:
Hi
On = =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez = Labrador <ietf@hugo.labkode.= com> wrote:
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun = wrote:
Hi
2015-12-02 5:14 GMT+08:00 Hugo = Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:
Hi,
from my point of view the remoteStorage project = addresses a subset of
the use cases of the = WebDAV specification.
The main difference I can observe is that the specification is = built on
REST instead of XML-based = communication.
I personally like much= more REST than WebDAV because it is more
developer friendly and it is faster to develop.
Maybe the remoteStorage API becomes the next WebDAV = :)
However, the remoteStorage API = does not provide a way of synchronising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the = remoteStorage does not provide that. Is that because remoteStorage does not= perform like a typical sync services (e.g. dropbox...) or you are saying = something else?
Yes, because it does not offer synchronisation = capabilities.
Got it. And = What I am wondering is that do we need to include those capabilities in a = base specifications. Since it is hard to standardize the capabilities like = dedup or delta. Maybe a better way is to define those in a separate = specification,
Thanks for giving these examples - so by=20 'synchronisation = capabilities' you mean 1) deduplication and 2) delta=20 updates? Anything else or is that an exhaustive list?
something= like extensions. For a base document, we just need to define how to = perform sync operations.
Yes, I agree that may be an = extension of this draft could handle the synchronisation part.
Our Internet-Draft is heavily focused on the world wide web, = whose URLs are not content-addressable, we can't change that. So that = architecture is not very friendly to deduplication, compared to for = instance BitTorrent. As you already said, developers can still dedupe on = the server-side when storing blobs to disk, and can also dedupe on the = client side before creating the resources the client uploads.
As far as I know, delta updates are not supported by the = ETag system - you cannot do a range request to find out if certain bytes = within a document have changed. However, the folder system we define does = encourage you, for instance when you develop a To Do List app, put each = task on its own document, and then query the folder to see which of them = changed, instead of putting them all in one big document and retrieving the= whole document each time.
Cheers,
Michiel.
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols = against
different data backends with special = attention to provide a common sync
API.
A common API for = different sync protocols is being created based on the
architecture specified in this draft (control and data servers) = and the
I cannot find a = distributed architecture in this draft. It seems that they handle metadata = and content data together, just like a normal web service.
ClawIO is fully = distributed. Every logical unit is a different server than be scaled out. = Data and Metadata channels are independent from each other and reside on = different servers.
That is = widely employed in popular sync services. And that is also beneficial to = privacy to some extent. But in the context of sync in browser (which is = mainly considered in the remoteStorage), I don't know whether this is = reasonable. But I think we should deploy distributed architecture although = it will make things complicated.
Of course, the remoteStorage is= targeted to browsers, so syncing does not make too much sense in this case= .
With the rise of Linux container micro-service based = architectures, the deployment of such highly complex systems should become= easier and faster.
Best,
Hugo
Regards,=
Linhui
Regards,
Linhui
one from the CERN EOS project = (management, disk and queue servers).
The Phase I has implemented the ownCloud Sync Protocol and Phase II = will
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are = really
opposed to each other in terms of syncing (delta vs = non-delta,
state-based vs log/event/git-based sync = =E2=80=A6), so finding a common approach
is more challenging= .
Providing a base specification/architecture = to measure the feasibility
of this draft is one of the = objectives of the project.
I believe that the = work being done here and in ClawIO are supplementary
to each other and I think mutual collaboration could be beneficial = for
both sides.
Also, if there is interest, the remoteStorage API can be added = to
ClawIO.
Best regards,=
Hugo Gonzalez Labrador
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>
> To subscribe or unsubscribe= via the World Wide Web, visit
> or, via email, = send a message with subject or body 'help' to
>
> You can reach the person managing the list at
>
> When replying, please edit your Subject line so it is more = specific
> than "Re: Contents of Storagesync digest...= "
> Today's Topics:
>
> 1. New version of draft-dejong-remotestorage = Internet-Draft
> available (Michiel de = Jong)
> 2. Re: New version of draft-dejong-remotestora= ge Internet-Draft
> available (Gihan = Dias)
> 3. Re: New version of draft-dejong-remotestora= ge Internet-Draft
> available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 = attachments:
> + [Storagesync] New version of = draft-dejong-remotestorage
> Internet-Draft = available
> 2k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
> 1k (message/rfc822)
> + Re: [Storagesync] New= version of draft-dejong-remotestorage
> Internet-Draft = available
> 2k (message/rfc822)
_______________________________________________
Storagesync mailing list




= ------sinikael-?=_1-14490706262430.07383038755506277-- From nobody Thu Dec 3 00:00:47 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ACF1ACC8F for ; Thu, 3 Dec 2015 00:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kii0-o4B-TXL for ; Thu, 3 Dec 2015 00:00:38 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id E8E351A8AE2 for ; Thu, 3 Dec 2015 00:00:36 -0800 (PST) Received: by ajax-webmail-Jdweb3 (Coremail) ; Thu, 3 Dec 2015 16:02:51 +0800 (GMT+08:00) Date: Thu, 3 Dec 2015 16:02:51 +0800 (GMT+08:00) From: fsong@bjtu.edu.cn To: =?utf-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Message-ID: <7c1b060f.2a99.15166dd8147.Coremail.fsong@bjtu.edu.cn> In-Reply-To: <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_40109_1212717290.1449129771334" X-Originating-IP: [106.2.233.19] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20150107(58648.7033.6860) Copyright (c) 2002-2015 www.mailtech.cn bjtu X-SendMailWithSms: false X-CM-TRANSID: d55wygBHshIr919Whp8FAA--.1157W X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/1tbiAQIMB1R9XjYWkwAAsM X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: Linhui Sun , storagesync , Michiel de Jong , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 08:00:43 -0000 ------=_Part_40109_1212717290.1449129771334 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KzEuIFRoaXMgaXMgZGVmaW5pdGVseSBhIGJhc2ljIGlzc3VlIGZvciB0aGlzIGdyb3VwfgoKCi0t LS0t5Y6f5aeL6YKu5Lu2LS0tLS0K5Y+R5Lu25Lq6OiAiSHVnbyBHb256w6FsZXogTGFicmFkb3Ii IDxpZXRmQGh1Z28ubGFia29kZS5jb20+CuWPkemAgeaXtumXtDogMjAxNeW5tDEy5pyIMuaXpSDm mJ/mnJ/kuIkK5pS25Lu25Lq6OiAiTGluaHVpIFN1biIgPGxoLnN1bmxpbmhAZ21haWwuY29tPgrm ioTpgIE6IHN0b3JhZ2VzeW5jIDxzdG9yYWdlc3luY0BpZXRmLm9yZz4sICJNaWNoaWVsIGRlIEpv bmciIDxtYmRlam9uZ0Btb3ppbGxhLmNvbT4sIGZrb29tYW4gPGZrb29tYW5AdHV4ZWQubmV0Pgrk uLvpopg6IFJlOiBbU3RvcmFnZXN5bmNdIFN0b3JhZ2VzeW5jIERpZ2VzdCwgVm9sIDUsIElzc3Vl IDEKCgpJIHByb3Bvc2UgdG8gY29tZSB1cCB3aXRoIGEgbGlzdCBvZiBhZHZhbnRhZ2VzIGFuZCBk aXNhZHZhbnRhZ2VzIG9mIHVzaW5nIFdlYkRBViBhbmQgY29tcGFyZSB0aGVtIGFnYWluc3QgYSBK U09OL1JFU1QgYmFzZWQgYXBwcm9hY2gsIGxpa2UgcmVtb3RlU3RvcmFnZS4KCiAKRG9lcyBpdCBz b3VuZCBnb29kID8KIAogCk9uIFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjU5IFBNLCBMaW5odWkg U3VuIHdyb3RlOgoKIAogCjIwMTUtMTItMDIgMjA6NDMgR01UKzA4OjAwIEh1Z28gR29uesOhbGV6 IExhYnJhZG9yIDxpZXRmQGh1Z28ubGFia29kZS5jb20+OgoKCgogCiAKIAogCk9uIFdlZCwgRGVj IDIsIDIwMTUsIGF0IDAxOjMwIFBNLCBNaWNoaWVsIGRlIEpvbmcgd3JvdGU6CgpIaSBhbGwhCgpU aGFua3MgZm9yIGFsbCB5b3VyIHJlYWN0aW9ucyB0byB0aGUgcmVtb3RlU3RvcmFnZSBJbnRlcm5l dC1EcmFmdC4KCiAKV2UgZ2V0IHRoZSBxdWVzdGlvbiBhYm91dCBXZWJEQVYgYSBsb3QsIGluIHRo ZSBuZXh0IHZlcnNpb24gd2Ugc2hvdWxkIGFkZCBhIHJlbWFyayBhYm91dCBpdCBpbiB0aGUgaW50 cm8uIFRoZSBmb2xkZXIgZGVzY3JpcHRpb25zIHJldHVybmVkIHdoZW4geW91IEdFVCBhIFVSTCB0 aGF0IGVuZHMgd2l0aCBhIC8gYXJlIGluZGVlZCBhIGRldmlhdGlvbiBmcm9tIHRoZSBYTUwgcmV0 dXJuZWQgYnkgV2ViREFWIHNlcnZlciwgYW5kIHRoaXMgaXMganVzdCBiZWNhdXNlIG5vd2FkYXlz IEpTT04gaXMgZWFzaWVyIHRvIHVzZSB0aGFuIFhNTCBmb3IgZGV2ZWxvcGVycywgYm90aCBjbGll bnQtc2lkZSBhbmQgc2VydmVyLXNpZGUuCgogCiAKSSB0b3RhbGx5IGFncmVlIGhlcmUsIHRoaXMg d2FzIGdvaW5nIHRvIGhhcHBlbiBzb29uIG9yIGxhdGVyIGFuZCBpdCBpcyByZWFsbHkgYXBwcmVj aWF0ZWQuCgogCiAKVGhlIGZhY3QgdGhhdCB3ZSBkb24ndCByZXF1aXJlIHNlcnZlcnMgdG8gc3Vw cG9ydCBXZWJEQVYncyBjdXN0b20gdmVyYnMgbGlrZSBQUk9QUEFUQ0ggZXRjLiBpcyBmb3IgdGhy ZWUgcmVhc29uczoKCjEpIGl0J3MgYSBsb3Qgb2Ygd29yayB0byBpbXBsZW1lbnQgdGhpcyB3aXRo b3V0IHVzaW5nIGFuIGV4aXN0aW5nIFdlYkRBViBsaWJyYXJ5CgoyKSBpbiBwcmFjdGljZSwgYSBs b3Qgb2YgV2ViREFWIHNlcnZlcnMgZ2V0IGl0IHdyb25nLCBvciBkb24ndCBpbXBsZW1lbnQgYWxs IG9mIFdlYkRBVi4gSXQncyB2ZXJ5IGFubm95aW5nIGZvciBjbGllbnQgaW1wbGVtZW50ZXJzIHRv IGhhdmUgdG8gZGVhbCB3aXRoIHNlcnZlcnMgdGhhdCBlLmcuIGNob3NlIG5vdCB0byBpbXBsZW1l bnQgTE9DSyBhbmQgVU5MT0NLLgoKMykgd2UgZG9uJ3QgcmVhbGx5IG5lZWQgYWxsIHRoZXNlIGFk dmFuY2VkIGZlYXR1cmVzIG9uIHRvcCBvZiBzdGFuZGFyZCBIVFRQLCBqdXN0IHN1cHBvcnRpbmcg R0VUL1BVVC9ERUxFVEUgZm9yIHJlc291cmNlcywgYW5kIGFkZGluZyBhIHNpbXBsZSBmb2xkZXIg ZGVzY3JpcHRpb24gZm9ybWF0LCBpcyBlbm91Z2ggZm9yIG1vc3QgYXBwbGljYXRpb25zLgoKIApP dGhlciB0aGFuIHRoYXQsIHRoZSByZW1vdGVTdG9yYWdlIEludGVybmV0LURyYWZ0IHNwZWNpZmll cyBhICpsb3QqIG1vcmUgdGhhbiBqdXN0IGhvdyBlYWNoIEhUVFAgdmVyYiBzaG91bGQgYmVoYXZl OgoKKiByZXF1aXJpbmcgc3VwcG9ydCBmb3IgT0F1dGggaW1wbGljaXQtZ3JhbnQgZmxvdwoKKiBy ZXF1aXJpbmcgRVRhZyBzdXBwb3J0IGFuZCBuZXN0ZWQgdmVyc2lvbmluZyAoaS5lLiB0aGUgZm9s ZGVyJ3MgRVRhZyBjaGFuZ2VzIGlmIGFueXRoaW5nIHdpdGhpbiB0aGF0IGZvbGRlciBjaGFuZ2Vz KQoKKiByZXF1aXJpbmcgQ09SUyBoZWFkZXJzCgoqIHJlcXVpcmluZyBhIFdlYkZpbmdlciBhbm5v dW5jZW1lbnQgZm9yIHNlcnZpY2UgZGlzY292ZXJ5CgpJdCB3b3VsZCBiZSBlYXN5IHRvIGFkZCB0 aGVzZSB0aHJlZSB0aGluZ3Mgb24gdG9wIG9mIFdlYkRBViwgaW5zdGVhZCBvZiBwdXR0aW5nIHRo ZW0gb24gdG9wIG9mIG91ciBtaW5pbWFsIEdFVC9QVVQvREVMRVRFIEFQSSBkZWZpbml0aW9uLiBJ biBmYWN0LCB3ZSBjb3VsZCBwcm9iYWJseSBzZXBhcmF0ZSBpdCBpbnRvIHR3byBJbnRlcm5ldC1E cmFmdHM6IG9uZSBmb3IgdGhlICdSRVNUZnVsIGZvbGRlcnMnIEFQSSB3aGljaCBpcyBvdXIgc2lt cGxpZmljYXRpb24gb2YgV2ViREFWLCBhbmQgYSBzZWNvbmQgb25lIGZvciBPQXV0aC9FVGFncy9D T1JTL1dlYkZpbmdlciBvbiB0b3Agb2YgZWl0aGVyIFdlYkRBViBvciAnUkVTVGZ1bCBmb2xkZXJz JyBvciB3aGF0ZXZlciBvdGhlciBIVFRQLWJhc2VkIEFQSSB5b3Ugd2FudC4KCiAKIApUaGVyZSBp cyBvbmUgcmVxdWlyZW1lbnQgdGhhdCBhbGwgc3luY2hyb25pc2VycyBuZWVkIHRvIGhhbmRsZTog bW92aW5nIHJlc291cmNlcy4gSW4gdGhpcyBzcGVjIHRoZSBhbHRlcm5hdGl2ZSBvZiBhIFdlYkRB ViBNT1ZFIGlzIG5vdCBzcGVjaWZpZWQuIAoKIApJdCBpcyB0cnVlIHRoYXQgYSBNT1ZFIGNvdWxk IGJlIHJlcGxhY2VkIHdpdGggYSBERUxFVEUgKyBVUExPQUQgYnV0IHRoYXQgaXMgbm90IGFjY2Vw dGFibGUgaW4gbW9zdCBjYXNlcyBkdWUgdG8gdGhlIGluZWZmaWNpZW5jeSBvZiBzdWNoIG9wZXJh dGlvbiAoY3B1LCBiYW5kd2lkdGggY29uc3VtcHRpb24gLi4uKQoKIApJcyB0aGVyZSBhIHBsYW4g dG8gc3VwcG9ydCBzdWNoIGJhc2ljIGZlYXR1cmU/CgogCkZyb20gdGhlIGN1cnJlbnQgcmVtb3Rl U3RvcmFnZSBzcGVjLCB0aGUgb3duQ2xvdWQgc3luYyBwcm90b2NvbCBjYW4gYmUgaW1wbGVtZW50 ZWQuIFRoZSBtaXNzaW5nIGJpdCBpcyB0cmFja2luZyB0aG9zZSByZW1vdGUgbW92ZXMuCgpJIGFn cmVlIHdpdGggSHVnbyB0aGF0IE1PVkUgaXMgdXNlZnVsLCBzb21ldGltZXMgaWYgeW91IGp1c3Qg cmVuYW1lIGEgZmlsZSBpdCB3aWxsIGJlIHBlcmZlY3QuIEJ1dCB0aGUgcXVlc3Rpb24gSSBoYXZl IGlzIHRoYXQgd2hldGhlciB3ZSBuZWVkIHRvIG1ha2UgdHdvIGRvY3VtZW50cz8gTXVsdGlwbGUg Y2hvaWNlcyBpcyBub3QgZ29vZCBmb3Igc3RhbmRhcmRpemF0aW9uLiBJbiBteSB2aWV3LCB3ZWJk YXYgaXMgc29tZXRoaW5nIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEgdmVyeSBjbGVhciBkZWNpc2lv biBvbiB3aGV0aGVyIHRvIGNvbnNpZGVyIGl0IG9yIG5vdC4KCiAKUmVnYXJkcywKCkxpbmh1aQoK IAogCkNoZWVycwoKIApPbiBXZWQsIERlYyAyLCAyMDE1IGF0IDExOjI4IEFNLCBIdWdvIEdvbnrD oWxleiBMYWJyYWRvciA8aWV0ZkBodWdvLmxhYmtvZGUuY29tPiB3cm90ZToKCgoKIAogCiAKIApP biBXZWQsIERlYyAyLCAyMDE1LCBhdCAxMToxOCBBTSwgTGluaHVpIFN1biB3cm90ZToKCkhpCgog Ck9uIOWRqOS4iSwgMTLmnIggMiwgMjAxNSBhdCAxNzo1NiwgSHVnbyBHb256w6FsZXogTGFicmFk b3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT4gd3JvdGU6CgogCiAKIApPbiBXZWQsIERlYyAyLCAy MDE1LCBhdCAwODoyMCBBTSwgTGluaHVpIFN1biB3cm90ZToKCkhpCgogCjIwMTUtMTItMDIgNTox NCBHTVQrMDg6MDAgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNv bT46CgpIaSwKCiAKZnJvbSBteSBwb2ludCBvZiB2aWV3IHRoZSByZW1vdGVTdG9yYWdlIHByb2pl Y3QgYWRkcmVzc2VzIGEgc3Vic2V0IG9mCgp0aGUgdXNlIGNhc2VzIG9mIHRoZSAgV2ViREFWIHNw ZWNpZmljYXRpb24uCgogClRoZSBtYWluIGRpZmZlcmVuY2UgSSBjYW4gb2JzZXJ2ZSBpcyB0aGF0 IHRoZSBzcGVjaWZpY2F0aW9uIGlzIGJ1aWx0IG9uCgpSRVNUIGluc3RlYWQgb2YgWE1MLWJhc2Vk IGNvbW11bmljYXRpb24uCgogCkkgcGVyc29uYWxseSBsaWtlIG11Y2ggbW9yZSBSRVNUIHRoYW4g V2ViREFWIGJlY2F1c2UgaXQgaXMgbW9yZQoKZGV2ZWxvcGVyIGZyaWVuZGx5IGFuZCBpdCBpcyBm YXN0ZXIgdG8gZGV2ZWxvcC4KCiBNYXliZSB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgYmVjb21lcyB0 aGUgbmV4dCBXZWJEQVYgOikKCiAKSG93ZXZlciwgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGRvZXMg bm90IHByb3ZpZGUgYSB3YXkgb2Ygc3luY2hyb25pc2luZwoKZGF0YSwgdGhpcyB0YXNrIGlzIGRl bGVnYXRlZCB0byB0aGUgZGV2ZWxvcGVycy4KCklzIHRoZXJlIGEgcGxhbiB0byBwcm92aWRlIHN1 Y2ggZmVhdHVyZSBiYXNlZCBvbiB0aGUgb3V0Y29tZSBvZiB0aGlzCgpkcmFmdD8KCkknbSBhIGxp dHRsZSBiaXQgY29uZnVzZWQgd2h5IHlvdSBzYXkgdGhlIHJlbW90ZVN0b3JhZ2UgZG9lcyBub3Qg cHJvdmlkZSB0aGF0LiBJcyB0aGF0IGJlY2F1c2UgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBwZXJm b3JtIGxpa2UgYSB0eXBpY2FsIHN5bmMgc2VydmljZXMgKGUuZy4gZHJvcGJveC4uLikgb3IgeW91 IGFyZSBzYXlpbmcgc29tZXRoaW5nIGVsc2U/CgpZZXMsIGJlY2F1c2UgaXQgZG9lcyBub3Qgb2Zm ZXIgc3luY2hyb25pc2F0aW9uIGNhcGFiaWxpdGllcy4KCkdvdCBpdC4gQW5kIFdoYXQgSSBhbSB3 b25kZXJpbmcgaXMgdGhhdCBkbyB3ZSBuZWVkIHRvIGluY2x1ZGUgdGhvc2UgY2FwYWJpbGl0aWVz IGluIGEgYmFzZSBzcGVjaWZpY2F0aW9ucy4gU2luY2UgaXQgaXMgaGFyZCB0byBzdGFuZGFyZGl6 ZSB0aGUgY2FwYWJpbGl0aWVzIGxpa2UgZGVkdXAgb3IgZGVsdGEuIE1heWJlIGEgYmV0dGVyIHdh eSBpcyB0byBkZWZpbmUgdGhvc2UgaW4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLAoKIAogClRo YW5rcyBmb3IgZ2l2aW5nIHRoZXNlIGV4YW1wbGVzIC0gc28gYnkgJ3N5bmNocm9uaXNhdGlvbiBj YXBhYmlsaXRpZXMnIHlvdSBtZWFuIDEpIGRlZHVwbGljYXRpb24gYW5kIDIpIGRlbHRhIHVwZGF0 ZXM/IEFueXRoaW5nIGVsc2Ugb3IgaXMgdGhhdCBhbiBleGhhdXN0aXZlIGxpc3Q/CgogCnNvbWV0 aGluZyBsaWtlIGV4dGVuc2lvbnMuIEZvciBhIGJhc2UgZG9jdW1lbnQsIHdlIGp1c3QgbmVlZCB0 byBkZWZpbmUgaG93IHRvIHBlcmZvcm0gc3luYyBvcGVyYXRpb25zLgoKIAogClllcywgSSBhZ3Jl ZSB0aGF0IG1heSBiZSBhbiBleHRlbnNpb24gb2YgdGhpcyBkcmFmdCBjb3VsZCBoYW5kbGUgdGhl IHN5bmNocm9uaXNhdGlvbiBwYXJ0LgoKIAogCiAKIApPdXIgSW50ZXJuZXQtRHJhZnQgaXMgaGVh dmlseSBmb2N1c2VkIG9uIHRoZSB3b3JsZCB3aWRlIHdlYiwgd2hvc2UgVVJMcyBhcmUgbm90IGNv bnRlbnQtYWRkcmVzc2FibGUsIHdlIGNhbid0IGNoYW5nZSB0aGF0LiBTbyB0aGF0IGFyY2hpdGVj dHVyZSBpcyBub3QgdmVyeSBmcmllbmRseSB0byBkZWR1cGxpY2F0aW9uLCBjb21wYXJlZCB0byBm b3IgaW5zdGFuY2UgQml0VG9ycmVudC4gQXMgeW91IGFscmVhZHkgc2FpZCwgZGV2ZWxvcGVycyBj YW4gc3RpbGwgZGVkdXBlIG9uIHRoZSBzZXJ2ZXItc2lkZSB3aGVuIHN0b3JpbmcgYmxvYnMgdG8g ZGlzaywgYW5kIGNhbiBhbHNvIGRlZHVwZSBvbiB0aGUgY2xpZW50IHNpZGUgYmVmb3JlIGNyZWF0 aW5nIHRoZSByZXNvdXJjZXMgdGhlIGNsaWVudCB1cGxvYWRzLgoKQXMgZmFyIGFzIEkga25vdywg ZGVsdGEgdXBkYXRlcyBhcmUgbm90IHN1cHBvcnRlZCBieSB0aGUgRVRhZyBzeXN0ZW0gLSB5b3Ug Y2Fubm90IGRvIGEgcmFuZ2UgcmVxdWVzdCB0byBmaW5kIG91dCBpZiBjZXJ0YWluIGJ5dGVzIHdp dGhpbiBhIGRvY3VtZW50IGhhdmUgY2hhbmdlZC4gSG93ZXZlciwgdGhlIGZvbGRlciBzeXN0ZW0g d2UgZGVmaW5lIGRvZXMgZW5jb3VyYWdlIHlvdSwgZm9yIGluc3RhbmNlIHdoZW4geW91IGRldmVs b3AgYSBUbyBEbyBMaXN0IGFwcCwgcHV0IGVhY2ggdGFzayBvbiBpdHMgb3duIGRvY3VtZW50LCBh bmQgdGhlbiBxdWVyeSB0aGUgZm9sZGVyIHRvIHNlZSB3aGljaCBvZiB0aGVtIGNoYW5nZWQsIGlu c3RlYWQgb2YgcHV0dGluZyB0aGVtIGFsbCBpbiBvbmUgYmlnIGRvY3VtZW50IGFuZCByZXRyaWV2 aW5nIHRoZSB3aG9sZSBkb2N1bWVudCBlYWNoIHRpbWUuCgogCkNoZWVycywKCk1pY2hpZWwuCgog CiAKIAogCkJUVywgSSB3YW50IHRvIGludHJvZHVjZSBDbGF3SU8gKGh0dHA6Ly9jbGF3aW8uZ2l0 aHViLmlvKSwgYSByZXNlYXJjaAoKcHJvamVjdCB0byBiZW5jaG1hcmsgZGlmZmVyZW50IHN5bmNo cm9uaXNhdGlvbiBwcm90b2NvbHMgYWdhaW5zdAoKZGlmZmVyZW50IGRhdGEgYmFja2VuZHMgd2l0 aCBzcGVjaWFsIGF0dGVudGlvbiB0byBwcm92aWRlIGEgY29tbW9uIHN5bmMKCkFQSS4KCiAKQSBj b21tb24gQVBJIGZvciBkaWZmZXJlbnQgc3luYyBwcm90b2NvbHMgaXMgYmVpbmcgY3JlYXRlZCBi YXNlZCBvbiB0aGUKCmFyY2hpdGVjdHVyZSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdCAoY29udHJv bCBhbmQgZGF0YSBzZXJ2ZXJzKSBhbmQgdGhlCgpJIGNhbm5vdCBmaW5kIGEgZGlzdHJpYnV0ZWQg YXJjaGl0ZWN0dXJlIGluIHRoaXMgZHJhZnQuIEl0IHNlZW1zIHRoYXQgdGhleSBoYW5kbGUgbWV0 YWRhdGEgYW5kIGNvbnRlbnQgZGF0YSB0b2dldGhlciwganVzdCBsaWtlIGEgbm9ybWFsIHdlYiBz ZXJ2aWNlLgoKIApDbGF3SU8gaXMgZnVsbHkgZGlzdHJpYnV0ZWQuIEV2ZXJ5IGxvZ2ljYWwgdW5p dCBpcyBhIGRpZmZlcmVudCBzZXJ2ZXIgdGhhbiBiZSBzY2FsZWQgb3V0LiBEYXRhIGFuZCBNZXRh ZGF0YSBjaGFubmVscyBhcmUgaW5kZXBlbmRlbnQgZnJvbSBlYWNoIG90aGVyIGFuZCByZXNpZGUg b24gZGlmZmVyZW50IHNlcnZlcnMuCgpUaGF0IGlzIHdpZGVseSBlbXBsb3llZCBpbiBwb3B1bGFy IHN5bmMgc2VydmljZXMuIEFuZCB0aGF0IGlzIGFsc28gYmVuZWZpY2lhbCB0byBwcml2YWN5IHRv IHNvbWUgZXh0ZW50LiBCdXQgaW4gdGhlIGNvbnRleHQgb2Ygc3luYyBpbiBicm93c2VyICh3aGlj aCBpcyBtYWlubHkgY29uc2lkZXJlZCBpbiB0aGUgcmVtb3RlU3RvcmFnZSksIEkgZG9uJ3Qga25v dyB3aGV0aGVyIHRoaXMgaXMgcmVhc29uYWJsZS4gQnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGRlcGxv eSBkaXN0cmlidXRlZCBhcmNoaXRlY3R1cmUgYWx0aG91Z2ggaXQgd2lsbCBtYWtlIHRoaW5ncyBj b21wbGljYXRlZC4KCiAKIApPZiBjb3Vyc2UsIHRoZSByZW1vdGVTdG9yYWdlIGlzIHRhcmdldGVk IHRvIGJyb3dzZXJzLCBzbyBzeW5jaW5nIGRvZXMgbm90IG1ha2UgdG9vIG11Y2ggc2Vuc2UgaW4g dGhpcyBjYXNlLgoKV2l0aCB0aGUgcmlzZSBvZiBMaW51eCBjb250YWluZXIgbWljcm8tc2Vydmlj ZSBiYXNlZCBhcmNoaXRlY3R1cmVzLCB0aGUgZGVwbG95bWVudCBvZiAgc3VjaCBoaWdobHkgY29t cGxleCBzeXN0ZW1zIHNob3VsZCBiZWNvbWUgZWFzaWVyIGFuZCBmYXN0ZXIuCgogCkJlc3QsCgog CiAKSHVnbwoKIAogClJlZ2FyZHMsCgpMaW5odWkgCgogCiAKUmVnYXJkcywKCkxpbmh1aQoKb25l IGZyb20gdGhlIENFUk4gRU9TIHByb2plY3QgKG1hbmFnZW1lbnQsIGRpc2sgYW5kIHF1ZXVlIHNl cnZlcnMpLgoKIApUaGUgUGhhc2UgSSBoYXMgaW1wbGVtZW50ZWQgdGhlIG93bkNsb3VkIFN5bmMg UHJvdG9jb2wgYW5kIFBoYXNlIElJIHdpbGwKCmltcGxlbWVudCB0aGUgU2VhRmlsZSBTeW5jIFBy b3RvY29sLgoKVGhlIGNob2ljZSBvZiB0aGVzZSBwcm90b2NvbHMgYW1vbmcgb3RoZXJzIGlzIGJl Y2F1c2UgdGhleSBhcmUgcmVhbGx5CgpvcHBvc2VkIHRvIGVhY2ggb3RoZXIgaW4gdGVybXMgb2Yg c3luY2luZyAoZGVsdGEgdnMgbm9uLWRlbHRhLAoKc3RhdGUtYmFzZWQgdnMgbG9nL2V2ZW50L2dp dC1iYXNlZCBzeW5jIOKApiksIHNvIGZpbmRpbmcgYSBjb21tb24gYXBwcm9hY2gKCmlzIG1vcmUg Y2hhbGxlbmdpbmcuCgogClByb3ZpZGluZyBhIGJhc2Ugc3BlY2lmaWNhdGlvbi9hcmNoaXRlY3R1 cmUgdG8gbWVhc3VyZSB0aGUgZmVhc2liaWxpdHkKCm9mIHRoaXMgZHJhZnQgaXMgb25lIG9mIHRo ZSBvYmplY3RpdmVzIG9mIHRoZSBwcm9qZWN0LgoKIApJIGJlbGlldmUgdGhhdCB0aGUgd29yayBi ZWluZyBkb25lIGhlcmUgYW5kIGluIENsYXdJTyBhcmUgc3VwcGxlbWVudGFyeQoKdG8gZWFjaCBv dGhlciBhbmQgSSB0aGluayBtdXR1YWwgY29sbGFib3JhdGlvbiBjb3VsZCBiZSBiZW5lZmljaWFs IGZvcgoKYm90aCBzaWRlcy4KCiAKQWxzbywgaWYgdGhlcmUgaXMgaW50ZXJlc3QsIHRoZSByZW1v dGVTdG9yYWdlIEFQSSBjYW4gYmUgYWRkZWQgdG8KCkNsYXdJTy4KCiAKQmVzdCByZWdhcmRzLAoK IApIdWdvIEdvbnphbGV6IExhYnJhZG9yCgogCk9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0IDA5OjAw IFBNLCBzdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnIHdyb3RlOgoKPiBTZW5kIFN0b3JhZ2Vz eW5jIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bwoKPiAgICAgICBzdG9yYWdlc3luY0BpZXRm Lm9yZwoKPgoKPiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRl IFdlYiwgdmlzaXQKCj4gICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zdG9yYWdlc3luYwoKPiBvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1Ympl Y3Qgb3IgYm9keSAnaGVscCcgdG8KCj4gICAgICAgc3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9y ZwoKPgoKPiBZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQKCj4g ICAgICAgc3RvcmFnZXN5bmMtb3duZXJAaWV0Zi5vcmcKCj4KCj4gV2hlbiByZXBseWluZywgcGxl YXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYwoKPiB0aGFu ICJSZTogQ29udGVudHMgb2YgU3RvcmFnZXN5bmMgZGlnZXN0Li4uIgoKPiBUb2RheSdzIFRvcGlj czoKCj4KCj4gICAgMS4gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2Ug ICAgSW50ZXJuZXQtRHJhZnQKCj4gICAgICAgYXZhaWxhYmxlIChNaWNoaWVsIGRlIEpvbmcpCgo+ ICAgIDIuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRl cm5ldC1EcmFmdAoKPiAgICAgICBhdmFpbGFibGUgKEdpaGFuIERpYXMpCgo+ICAgIDMuIFJlOiBO ZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdAoK PiAgICAgICBhdmFpbGFibGUgKEZlaSBTb25nKQoKPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKPiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QKCj4gU3Rv cmFnZXN5bmNAaWV0Zi5vcmcKCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zdG9yYWdlc3luYwoKPiBFbWFpbCBoYWQgMyBhdHRhY2htZW50czoKCj4gKyBbU3RvcmFnZXN5 bmNdIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlCgo+IEludGVybmV0 LURyYWZ0IGF2YWlsYWJsZQoKPiAgIDJrIChtZXNzYWdlL3JmYzgyMikKCj4gKyBSZTogW1N0b3Jh Z2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZQoKPiBJbnRl cm5ldC1EcmFmdCBhdmFpbGFibGUKCj4gICAxayAobWVzc2FnZS9yZmM4MjIpCgo+ICsgUmU6IFtT dG9yYWdlc3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UKCj4g SW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxlCgo+ICAgMmsgKG1lc3NhZ2UvcmZjODIyKQoKIApfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKU3RvcmFnZXN5bmMg bWFpbGluZyBsaXN0CgpTdG9yYWdlc3luY0BpZXRmLm9yZwoKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYwoKIAogCiAKIA== ------=_Part_40109_1212717290.1449129771334 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 KzEuIFRoaXMgaXMgZGVmaW5pdGVseSBhIGJhc2ljIGlzc3VlIGZvciB0aGlzIGdyb3VwfjxCUj48 QlI+PEJSPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNmI2YjYgMnB4IHNvbGlk OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgi IG5hbWU9InJlcGx5Q29udGVudCI+LS0tLS3ljp/lp4vpgq7ku7YtLS0tLTxCUj48Qj7lj5Hku7bk uro6PC9CPiAiSHVnbyBHb256w6FsZXogTGFicmFkb3IiICZsdDtpZXRmQGh1Z28ubGFia29kZS5j b20mZ3Q7PEJSPjxCPuWPkemAgeaXtumXtDo8L0I+IDIwMTXlubQxMuaciDLml6Ug5pif5pyf5LiJ PEJSPjxCPuaUtuS7tuS6ujo8L0I+ICJMaW5odWkgU3VuIiAmbHQ7bGguc3VubGluaEBnbWFpbC5j b20mZ3Q7PEJSPjxCPuaKhOmAgTo8L0I+IHN0b3JhZ2VzeW5jICZsdDtzdG9yYWdlc3luY0BpZXRm Lm9yZyZndDssICJNaWNoaWVsIGRlIEpvbmciICZsdDttYmRlam9uZ0Btb3ppbGxhLmNvbSZndDss IGZrb29tYW4gJmx0O2Zrb29tYW5AdHV4ZWQubmV0Jmd0OzxCUj48Qj7kuLvpopg6PC9CPiBSZTog W1N0b3JhZ2VzeW5jXSBTdG9yYWdlc3luYyBEaWdlc3QsIFZvbCA1LCBJc3N1ZSAxPEJSPjxCUj4K PERJVj5JIHByb3Bvc2UgdG8gY29tZSB1cCB3aXRoIGEgbGlzdCBvZiBhZHZhbnRhZ2VzIGFuZCBk aXNhZHZhbnRhZ2VzIG9mIHVzaW5nIFdlYkRBViBhbmQgY29tcGFyZSB0aGVtIGFnYWluc3QgYSBK U09OL1JFU1QgYmFzZWQgYXBwcm9hY2gsIGxpa2UgcmVtb3RlU3RvcmFnZS48QlI+PC9ESVY+CjxE SVY+Jm5ic3A7PC9ESVY+CjxESVY+RG9lcyBpdCBzb3VuZCBnb29kID88L0RJVj4KPERJVj4mbmJz cDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5PbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAw MTo1OSBQTSwgTGluaHVpIFN1biB3cm90ZTo8QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNp dGUiPgo8RElWIGRpcj0ibHRyIj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4KPERJVj4mbmJzcDs8 L0RJVj4KPERJVj4KPERJVj4yMDE1LTEyLTAyIDIwOjQzIEdNVCswODowMCBIdWdvIEdvbnrDoWxl eiBMYWJyYWRvciA8U1BBTiBkaXI9Imx0ciI+Jmx0OzxBIGhyZWY9Im1haWx0bzppZXRmQGh1Z28u bGFia29kZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGh1Z28ubGFia29kZS5jb208L0E+Jmd0 OzwvU1BBTj46PEJSPjwvRElWPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigy MDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5H LUxFRlQ6IDFleCI+CjxESVY+PFU+PC9VPjxCUj48L0RJVj4KPERJVj4KPERJVj4mbmJzcDs8L0RJ Vj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4K PERJVj48U1BBTj5PbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwMTozMCBQTSwgTWljaGllbCBkZSBK b25nIHdyb3RlOjwvU1BBTj48QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8RElW IGRpcj0ibHRyIj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJ Vj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj48U1BBTj5IaSBhbGwhPC9TUEFOPjxCUj48 L0RJVj48L0RJVj4KPERJVj48U1BBTj5UaGFua3MgZm9yIGFsbCB5b3VyIHJlYWN0aW9ucyB0byB0 aGUgcmVtb3RlU3RvcmFnZSBJbnRlcm5ldC1EcmFmdC48L1NQQU4+PEJSPjwvRElWPgo8RElWPiZu YnNwOzwvRElWPjwvRElWPgo8RElWPjxTUEFOPldlIGdldCB0aGUgcXVlc3Rpb24gYWJvdXQgV2Vi REFWIGEgbG90LCBpbiB0aGUgbmV4dCB2ZXJzaW9uIHdlIHNob3VsZCBhZGQgYSByZW1hcmsgYWJv dXQgaXQgaW4gdGhlIGludHJvLiBUaGUgZm9sZGVyIGRlc2NyaXB0aW9ucyByZXR1cm5lZCB3aGVu IHlvdSBHRVQgYSBVUkwgdGhhdCBlbmRzIHdpdGggYSAvIGFyZSBpbmRlZWQgYSBkZXZpYXRpb24g ZnJvbSB0aGUgWE1MIHJldHVybmVkIGJ5IFdlYkRBViBzZXJ2ZXIsIGFuZCB0aGlzIGlzIGp1c3Qg YmVjYXVzZSBub3dhZGF5cyBKU09OIGlzIGVhc2llciB0byB1c2UgdGhhbiBYTUwgZm9yIGRldmVs b3BlcnMsIGJvdGggY2xpZW50LXNpZGUgYW5kIHNlcnZlci1zaWRlLjwvU1BBTj48QlI+PC9ESVY+ PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9E SVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElW Pgo8RElWPkkgdG90YWxseSBhZ3JlZSBoZXJlLCB0aGlzIHdhcyBnb2luZyB0byBoYXBwZW4gc29v biBvciBsYXRlciBhbmQgaXQgaXMgcmVhbGx5IGFwcHJlY2lhdGVkLjxCUj48L0RJVj4KPERJVj4m bmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+CjxE SVYgZGlyPSJsdHIiPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8 RElWPgo8RElWPgo8RElWPjxTUEFOPlRoZSBmYWN0IHRoYXQgd2UgZG9uJ3QgcmVxdWlyZSBzZXJ2 ZXJzIHRvIHN1cHBvcnQgV2ViREFWJ3MgY3VzdG9tIHZlcmJzIGxpa2UgUFJPUFBBVENIIGV0Yy4g aXMgZm9yIHRocmVlIHJlYXNvbnM6PC9TUEFOPjxCUj48L0RJVj48L0RJVj4KPERJVj48U1BBTj4x KSBpdCdzIGEgbG90IG9mIHdvcmsgdG8gaW1wbGVtZW50IHRoaXMgd2l0aG91dCB1c2luZyBhbiBl eGlzdGluZyBXZWJEQVYgbGlicmFyeTwvU1BBTj48QlI+PC9ESVY+PC9ESVY+CjxESVY+PFNQQU4+ MikgaW4gcHJhY3RpY2UsIGEgbG90IG9mIFdlYkRBViBzZXJ2ZXJzIGdldCBpdCB3cm9uZywgb3Ig ZG9uJ3QgaW1wbGVtZW50IGFsbCBvZiBXZWJEQVYuIEl0J3MgdmVyeSBhbm5veWluZyBmb3IgY2xp ZW50IGltcGxlbWVudGVycyB0byBoYXZlIHRvIGRlYWwgd2l0aCBzZXJ2ZXJzIHRoYXQgZS5nLiBj aG9zZSBub3QgdG8gaW1wbGVtZW50IExPQ0sgYW5kIFVOTE9DSy48L1NQQU4+PEJSPjwvRElWPjwv RElWPgo8RElWPjxTUEFOPjMpIHdlIGRvbid0IHJlYWxseSBuZWVkIGFsbCB0aGVzZSBhZHZhbmNl ZCBmZWF0dXJlcyBvbiB0b3Agb2Ygc3RhbmRhcmQgSFRUUCwganVzdCBzdXBwb3J0aW5nIEdFVC9Q VVQvREVMRVRFIGZvciByZXNvdXJjZXMsIGFuZCBhZGRpbmcgYSBzaW1wbGUgZm9sZGVyIGRlc2Ny aXB0aW9uIGZvcm1hdCwgaXMgZW5vdWdoIGZvciBtb3N0IGFwcGxpY2F0aW9ucy48L1NQQU4+PEJS PjwvRElWPgo8RElWPiZuYnNwOzwvRElWPjwvRElWPgo8RElWPjxTUEFOPk90aGVyIHRoYW4gdGhh dCwgdGhlIHJlbW90ZVN0b3JhZ2UgSW50ZXJuZXQtRHJhZnQgc3BlY2lmaWVzIGEgKmxvdCogbW9y ZSB0aGFuIGp1c3QgaG93IGVhY2ggSFRUUCB2ZXJiIHNob3VsZCBiZWhhdmU6PC9TUEFOPjxCUj48 L0RJVj48L0RJVj4KPERJVj48U1BBTj4qIHJlcXVpcmluZyBzdXBwb3J0IGZvciBPQXV0aCBpbXBs aWNpdC1ncmFudCBmbG93PC9TUEFOPjxCUj48L0RJVj48L0RJVj4KPERJVj48U1BBTj4qIHJlcXVp cmluZyBFVGFnIHN1cHBvcnQgYW5kIG5lc3RlZCB2ZXJzaW9uaW5nIChpLmUuIHRoZSBmb2xkZXIn cyBFVGFnIGNoYW5nZXMgaWYgYW55dGhpbmcgd2l0aGluIHRoYXQgZm9sZGVyIGNoYW5nZXMpPC9T UEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj4qIHJlcXVpcmluZyBDT1JTIGhlYWRlcnM8L1NQQU4+ PEJSPjwvRElWPjwvRElWPgo8RElWPjxTUEFOPiogcmVxdWlyaW5nIGEgV2ViRmluZ2VyIGFubm91 bmNlbWVudCBmb3Igc2VydmljZSBkaXNjb3Zlcnk8L1NQQU4+PEJSPjwvRElWPjwvRElWPgo8RElW PjxTUEFOPkl0IHdvdWxkIGJlIGVhc3kgdG8gYWRkIHRoZXNlIHRocmVlIHRoaW5ncyBvbiB0b3Ag b2YgV2ViREFWLCBpbnN0ZWFkIG9mIHB1dHRpbmcgdGhlbSBvbiB0b3Agb2Ygb3VyIG1pbmltYWwg R0VUL1BVVC9ERUxFVEUgQVBJIGRlZmluaXRpb24uIEluIGZhY3QsIHdlIGNvdWxkIHByb2JhYmx5 IHNlcGFyYXRlIGl0IGludG8gdHdvIEludGVybmV0LURyYWZ0czogb25lIGZvciB0aGUgJ1JFU1Rm dWwgZm9sZGVycycgQVBJIHdoaWNoIGlzIG91ciBzaW1wbGlmaWNhdGlvbiBvZiBXZWJEQVYsIGFu ZCBhIHNlY29uZCBvbmUgZm9yIE9BdXRoL0VUYWdzL0NPUlMvV2ViRmluZ2VyIG9uIHRvcCBvZiBl aXRoZXIgV2ViREFWIG9yICdSRVNUZnVsIGZvbGRlcnMnIG9yIHdoYXRldmVyIG90aGVyIEhUVFAt YmFzZWQgQVBJIHlvdSB3YW50LjwvU1BBTj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FV T1RFPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlRoZXJlIGlzIG9u ZSByZXF1aXJlbWVudCB0aGF0IGFsbCBzeW5jaHJvbmlzZXJzIG5lZWQgdG8gaGFuZGxlOiBtb3Zp bmcgcmVzb3VyY2VzLiBJbiB0aGlzIHNwZWMgdGhlIGFsdGVybmF0aXZlIG9mIGEgV2ViREFWIE1P VkUgaXMgbm90IHNwZWNpZmllZC4mbmJzcDs8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxE SVY+SXQgaXMgdHJ1ZSB0aGF0IGEgTU9WRSBjb3VsZCBiZSByZXBsYWNlZCB3aXRoIGEgREVMRVRF ICsgVVBMT0FEIGJ1dCB0aGF0IGlzIG5vdCBhY2NlcHRhYmxlIGluIG1vc3QgY2FzZXMgZHVlIHRv IHRoZSBpbmVmZmljaWVuY3kgb2Ygc3VjaCBvcGVyYXRpb24gKGNwdSwgYmFuZHdpZHRoIGNvbnN1 bXB0aW9uIC4uLik8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SXMgdGhlcmUgYSBw bGFuIHRvIHN1cHBvcnQgc3VjaCBiYXNpYyBmZWF0dXJlPzxCUj48L0RJVj4KPERJVj4mbmJzcDs8 L0RJVj4KPERJVj5Gcm9tIHRoZSBjdXJyZW50IHJlbW90ZVN0b3JhZ2Ugc3BlYywgdGhlIG93bkNs b3VkIHN5bmMgcHJvdG9jb2wgY2FuIGJlIGltcGxlbWVudGVkLiBUaGUgbWlzc2luZyBiaXQgaXMg dHJhY2tpbmcgdGhvc2UgcmVtb3RlIG1vdmVzLjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+ CjxESVY+SSBhZ3JlZSB3aXRoIEh1Z28gdGhhdCBNT1ZFIGlzIHVzZWZ1bCwgc29tZXRpbWVzIGlm IHlvdSBqdXN0IHJlbmFtZSBhIGZpbGUgaXQgd2lsbCBiZSBwZXJmZWN0LiBCdXQgdGhlIHF1ZXN0 aW9uIEkgaGF2ZSBpcyB0aGF0IHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIHR3byBkb2N1bWVudHM/ IE11bHRpcGxlIGNob2ljZXMgaXMgbm90IGdvb2QgZm9yIHN0YW5kYXJkaXphdGlvbi4gSW4gbXkg dmlldywgd2ViZGF2IGlzIHNvbWV0aGluZyB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIHZlcnkgY2xl YXIgZGVjaXNpb24gb24gd2hldGhlciB0byBjb25zaWRlciBpdCBvciBub3QuPEJSPjwvRElWPgo8 RElWPiZuYnNwOzwvRElWPgo8RElWPlJlZ2FyZHMsPEJSPjwvRElWPgo8RElWPkxpbmh1aTxCUj48 L0RJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFw eCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiPgo8 RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkNoZWVyczxCUj48 L0RJVj4KPERJVj4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0 ZSI+CjxESVYgZGlyPSJsdHIiPgo8RElWPgo8RElWPgo8RElWPk9uIFdlZCwgRGVjIDIsIDIwMTUg YXQgMTE6MjggQU0sIEh1Z28gR29uesOhbGV6IExhYnJhZG9yIDxTUEFOIGRpcj0ibHRyIj4mbHQ7 PEEgaHJlZj0ibWFpbHRvOmlldGZAaHVnby5sYWJrb2RlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmll dGZAaHVnby5sYWJrb2RlLmNvbTwvQT4mZ3Q7PC9TUEFOPiB3cm90ZTo8QlI+PC9ESVY+CjxCTE9D S1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1B UkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4Ij4KPERJVj48VT48L1U+ PEJSPjwvRElWPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW PiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPk9uIFdlZCwgRGVjIDIs IDIwMTUsIGF0IDExOjE4IEFNLCBMaW5odWkgU3VuIHdyb3RlOjwvU1BBTj48QlI+PC9ESVY+CjxC TE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8RElWPjxTUEFOPkhpPC9TUEFOPjxCUj48L0RJVj4KPERJ Vj4mbmJzcDs8L0RJVj4KPERJVj4KPERJViBzdHlsZT0iQ09MT1I6IHJnYigwLDAsMCkiPgo8RElW PjxTUEFOPk9uIOWRqOS4iSwgMTLmnIggMiwgMjAxNSBhdCAxNzo1NiwgSHVnbyBHb256w6FsZXog TGFicmFkb3IgJmx0OzxBIGhyZWY9Im1haWx0bzppZXRmQGh1Z28ubGFia29kZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5pZXRmQGh1Z28ubGFia29kZS5jb208L0E+Jmd0OyB3cm90ZTo8L1NQQU4+PEJS PjwvRElWPgo8RElWIHN0eWxlPSJPVkVSRkxPVy1YOiB2aXNpYmxlOyBPVkVSRkxPVy1ZOiB2aXNp YmxlIj4KPEJMT0NLUVVPVEUgc3R5bGU9IkNPTE9SOiByZ2IoNDgsNTksNjQpIj4KPERJVj4KPERJ Vj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48 U1BBTj5PbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwODoyMCBBTSwgTGluaHVpIFN1biB3cm90ZTo8 L1NQQU4+PEJSPjwvRElWPgo8QkxPQ0tRVU9URT4KPERJViBkaXI9Imx0ciI+CjxESVY+PFNQQU4+ SGk8L1NQQU4+PEJSPjwvRElWPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPgo8RElWPjxT UEFOPjIwMTUtMTItMDIgNToxNCBHTVQrMDg6MDAgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPFNQ QU4gZGlyPSJsdHIiPiZsdDs8QSBocmVmPSJtYWlsdG86aWV0ZkBodWdvLmxhYmtvZGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+aWV0ZkBodWdvLmxhYmtvZGUuY29tPC9BPiZndDs8L1NQQU4+OjwvU1BB Tj48QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQs MjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDog MWV4Ij4KPERJVj48U1BBTj5IaSw8L1NQQU4+PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8 RElWPjxTUEFOPmZyb20gbXkgcG9pbnQgb2YgdmlldyB0aGUgcmVtb3RlU3RvcmFnZSBwcm9qZWN0 IGFkZHJlc3NlcyBhIHN1YnNldCBvZjwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+dGhlIHVz ZSBjYXNlcyBvZiB0aGUmbmJzcDsgV2ViREFWIHNwZWNpZmljYXRpb24uPC9TUEFOPjxCUj48L0RJ Vj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5UaGUgbWFpbiBkaWZmZXJlbmNlIEkgY2Fu IG9ic2VydmUgaXMgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBpcyBidWlsdCBvbjwvU1BBTj48QlI+ PC9ESVY+CjxESVY+PFNQQU4+UkVTVCBpbnN0ZWFkIG9mIFhNTC1iYXNlZCBjb21tdW5pY2F0aW9u LjwvU1BBTj48QlI+PC9ESVY+PC9CTE9DS1FVT1RFPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVS LUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAu OGV4OyBQQURESU5HLUxFRlQ6IDFleCI+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+SSBw ZXJzb25hbGx5IGxpa2UgbXVjaCBtb3JlIFJFU1QgdGhhbiBXZWJEQVYgYmVjYXVzZSBpdCBpcyBt b3JlPC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj5kZXZlbG9wZXIgZnJpZW5kbHkgYW5kIGl0 IGlzIGZhc3RlciB0byBkZXZlbG9wLjwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+Jm5ic3A7 TWF5YmUgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGJlY29tZXMgdGhlIG5leHQgV2ViREFWIDopPC9T UEFOPjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5Ib3dldmVyLCB0aGUg cmVtb3RlU3RvcmFnZSBBUEkgZG9lcyBub3QgcHJvdmlkZSBhIHdheSBvZiBzeW5jaHJvbmlzaW5n PC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj5kYXRhLCB0aGlzIHRhc2sgaXMgZGVsZWdhdGVk IHRvIHRoZSBkZXZlbG9wZXJzLjwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+SXMgdGhlcmUg YSBwbGFuIHRvIHByb3ZpZGUgc3VjaCBmZWF0dXJlIGJhc2VkIG9uIHRoZSBvdXRjb21lIG9mIHRo aXM8L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPmRyYWZ0PzwvU1BBTj48QlI+PC9ESVY+PC9C TE9DS1FVT1RFPgo8RElWPjxTUEFOPkknbSBhIGxpdHRsZSBiaXQgY29uZnVzZWQgd2h5IHlvdSBz YXkgdGhlIHJlbW90ZVN0b3JhZ2UgZG9lcyBub3QgcHJvdmlkZSB0aGF0LiBJcyB0aGF0IGJlY2F1 c2UgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBwZXJmb3JtIGxpa2UgYSB0eXBpY2FsIHN5bmMgc2Vy dmljZXMgKGUuZy4gZHJvcGJveC4uLikgb3IgeW91IGFyZSBzYXlpbmcgc29tZXRoaW5nIGVsc2U/ PC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+PFNQ QU4+WWVzLCBiZWNhdXNlIGl0IGRvZXMgbm90IG9mZmVyIHN5bmNocm9uaXNhdGlvbiBjYXBhYmls aXRpZXMuPC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+PFNQQU4+R290 IGl0LiBBbmQgV2hhdCBJIGFtIHdvbmRlcmluZyBpcyB0aGF0IGRvIHdlIG5lZWQgdG8gaW5jbHVk ZSB0aG9zZSBjYXBhYmlsaXRpZXMgaW4gYSBiYXNlIHNwZWNpZmljYXRpb25zLiBTaW5jZSBpdCBp cyBoYXJkIHRvIHN0YW5kYXJkaXplIHRoZSBjYXBhYmlsaXRpZXMgbGlrZSBkZWR1cCBvciBkZWx0 YS4gTWF5YmUgYSBiZXR0ZXIgd2F5IGlzIHRvIGRlZmluZSB0aG9zZSBpbiBhIHNlcGFyYXRlIHNw ZWNpZmljYXRpb24sIDwvU1BBTj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FV T1RFPgo8RElWPiZuYnNwOzwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj4KPERJVj4mbmJz cDs8L0RJVj4KPERJVj5UaGFua3MgZm9yIGdpdmluZyB0aGVzZSBleGFtcGxlcyAtIHNvIGJ5ICdz eW5jaHJvbmlzYXRpb24gY2FwYWJpbGl0aWVzJyB5b3UgbWVhbiAxKSBkZWR1cGxpY2F0aW9uIGFu ZCAyKSBkZWx0YSB1cGRhdGVzPyBBbnl0aGluZyBlbHNlIG9yIGlzIHRoYXQgYW4gZXhoYXVzdGl2 ZSBsaXN0PyA8QlI+PC9ESVY+PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDog cmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBB RERJTkctTEVGVDogMWV4Ij4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUgdHlw ZT0iY2l0ZSI+CjxESVY+CjxESVYgc3R5bGU9IkNPTE9SOiByZ2IoMCwwLDApIj4KPERJViBzdHls ZT0iT1ZFUkZMT1ctWDogdmlzaWJsZTsgT1ZFUkZMT1ctWTogdmlzaWJsZSI+CjxESVY+PFNQQU4+ c29tZXRoaW5nIGxpa2UgZXh0ZW5zaW9ucy4gRm9yIGEgYmFzZSBkb2N1bWVudCwgd2UganVzdCBu ZWVkIHRvIGRlZmluZSBob3cgdG8gcGVyZm9ybSBzeW5jIG9wZXJhdGlvbnMuPC9TUEFOPjxCUj48 L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+CjxE SVY+Jm5ic3A7PC9ESVY+CjxESVY+WWVzLCBJIGFncmVlIHRoYXQgbWF5IGJlIGFuIGV4dGVuc2lv biBvZiB0aGlzIGRyYWZ0IGNvdWxkIGhhbmRsZSB0aGUgc3luY2hyb25pc2F0aW9uIHBhcnQuIDxC Uj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8 L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+CjxESVY+T3Vy IEludGVybmV0LURyYWZ0IGlzIGhlYXZpbHkgZm9jdXNlZCBvbiB0aGUgd29ybGQgd2lkZSB3ZWIs IHdob3NlIFVSTHMgYXJlIG5vdCBjb250ZW50LWFkZHJlc3NhYmxlLCB3ZSBjYW4ndCBjaGFuZ2Ug dGhhdC4gU28gdGhhdCBhcmNoaXRlY3R1cmUgaXMgbm90IHZlcnkgZnJpZW5kbHkgdG8gZGVkdXBs aWNhdGlvbiwgY29tcGFyZWQgdG8gZm9yIGluc3RhbmNlIEJpdFRvcnJlbnQuIEFzIHlvdSBhbHJl YWR5IHNhaWQsIGRldmVsb3BlcnMgY2FuIHN0aWxsIGRlZHVwZSBvbiB0aGUgc2VydmVyLXNpZGUg d2hlbiBzdG9yaW5nIGJsb2JzIHRvIGRpc2ssIGFuZCBjYW4gYWxzbyBkZWR1cGUgb24gdGhlIGNs aWVudCBzaWRlIGJlZm9yZSBjcmVhdGluZyB0aGUgcmVzb3VyY2VzIHRoZSBjbGllbnQgdXBsb2Fk cy48QlI+PC9ESVY+PC9ESVY+CjxESVY+CjxESVY+QXMgZmFyIGFzIEkga25vdywgZGVsdGEgdXBk YXRlcyBhcmUgbm90IHN1cHBvcnRlZCBieSB0aGUgRVRhZyBzeXN0ZW0gLSB5b3UgY2Fubm90IGRv IGEgcmFuZ2UgcmVxdWVzdCB0byBmaW5kIG91dCBpZiBjZXJ0YWluIGJ5dGVzIHdpdGhpbiBhIGRv Y3VtZW50IGhhdmUgY2hhbmdlZC4gSG93ZXZlciwgdGhlIGZvbGRlciBzeXN0ZW0gd2UgZGVmaW5l IGRvZXMgZW5jb3VyYWdlIHlvdSwgZm9yIGluc3RhbmNlIHdoZW4geW91IGRldmVsb3AgYSBUbyBE byBMaXN0IGFwcCwgcHV0IGVhY2ggdGFzayBvbiBpdHMgb3duIGRvY3VtZW50LCBhbmQgdGhlbiBx dWVyeSB0aGUgZm9sZGVyIHRvIHNlZSB3aGljaCBvZiB0aGVtIGNoYW5nZWQsIGluc3RlYWQgb2Yg cHV0dGluZyB0aGVtIGFsbCBpbiBvbmUgYmlnIGRvY3VtZW50IGFuZCByZXRyaWV2aW5nIHRoZSB3 aG9sZSBkb2N1bWVudCBlYWNoIHRpbWUuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPjwvRElW Pgo8RElWPkNoZWVycyw8QlI+PC9ESVY+CjxESVY+TWljaGllbC48QlI+PC9ESVY+CjxESVY+Jm5i c3A7PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0 KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4 Ij4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+CjxESVY+ CjxESVYgc3R5bGU9IkNPTE9SOiByZ2IoMCwwLDApIj4KPERJViBzdHlsZT0iT1ZFUkZMT1ctWDog dmlzaWJsZTsgT1ZFUkZMT1ctWTogdmlzaWJsZSI+CjxCTE9DS1FVT1RFIHN0eWxlPSJDT0xPUjog cmdiKDQ4LDU5LDY0KSI+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFPgo8RElW IGRpcj0ibHRyIj4KPERJVj4KPERJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiBy Z2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFE RElORy1MRUZUOiAxZXgiPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPkJUVywgSSB3YW50 IHRvIGludHJvZHVjZSBDbGF3SU8gKDxBIGhyZWY9Imh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvLyIg dGFyZ2V0PSJfYmxhbmsiPjwvQT48QSBocmVmPSJodHRwOi8vY2xhd2lvLmdpdGh1Yi5pby8iIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vY2xhd2lvLmdpdGh1Yi5pbzwvQT4pLCBhIHJlc2VhcmNoPC9T UEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj5wcm9qZWN0IHRvIGJlbmNobWFyayBkaWZmZXJlbnQg c3luY2hyb25pc2F0aW9uIHByb3RvY29scyBhZ2FpbnN0PC9TUEFOPjxCUj48L0RJVj4KPERJVj48 U1BBTj5kaWZmZXJlbnQgZGF0YSBiYWNrZW5kcyB3aXRoIHNwZWNpYWwgYXR0ZW50aW9uIHRvIHBy b3ZpZGUgYSBjb21tb24gc3luYzwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+QVBJLjwvU1BB Tj48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+QSBjb21tb24gQVBJIGZv ciBkaWZmZXJlbnQgc3luYyBwcm90b2NvbHMgaXMgYmVpbmcgY3JlYXRlZCBiYXNlZCBvbiB0aGU8 L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPmFyY2hpdGVjdHVyZSBzcGVjaWZpZWQgaW4gdGhp cyBkcmFmdCAoY29udHJvbCBhbmQgZGF0YSBzZXJ2ZXJzKSBhbmQgdGhlPC9TUEFOPjxCUj48L0RJ Vj48L0JMT0NLUVVPVEU+CjxESVY+PFNQQU4+SSBjYW5ub3QgZmluZCBhIGRpc3RyaWJ1dGVkIGFy Y2hpdGVjdHVyZSBpbiB0aGlzIGRyYWZ0LiBJdCBzZWVtcyB0aGF0IHRoZXkgaGFuZGxlIG1ldGFk YXRhIGFuZCBjb250ZW50IGRhdGEgdG9nZXRoZXIsIGp1c3QgbGlrZSBhIG5vcm1hbCB3ZWIgc2Vy dmljZS48L1NQQU4+PEJSPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJ Vj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5DbGF3SU8gaXMgZnVsbHkgZGlzdHJpYnV0ZWQuIEV2 ZXJ5IGxvZ2ljYWwgdW5pdCBpcyBhIGRpZmZlcmVudCBzZXJ2ZXIgdGhhbiBiZSBzY2FsZWQgb3V0 LiBEYXRhIGFuZCBNZXRhZGF0YSBjaGFubmVscyBhcmUgaW5kZXBlbmRlbnQgZnJvbSBlYWNoIG90 aGVyIGFuZCByZXNpZGUgb24gZGlmZmVyZW50IHNlcnZlcnMuPC9TUEFOPjxCUj48L0RJVj48L0RJ Vj48L0JMT0NLUVVPVEU+CjxESVY+PFNQQU4+VGhhdCBpcyB3aWRlbHkgZW1wbG95ZWQgaW4gcG9w dWxhciBzeW5jIHNlcnZpY2VzLiBBbmQgdGhhdCBpcyBhbHNvIGJlbmVmaWNpYWwgdG8gcHJpdmFj eSB0byBzb21lIGV4dGVudC4gQnV0IGluIHRoZSBjb250ZXh0IG9mIHN5bmMgaW4gYnJvd3NlciAo d2hpY2ggaXMgbWFpbmx5IGNvbnNpZGVyZWQgaW4gdGhlIHJlbW90ZVN0b3JhZ2UpLCBJIGRvbid0 IGtub3cgd2hldGhlciB0aGlzIGlzIHJlYXNvbmFibGUuIEJ1dCBJIHRoaW5rIHdlIHNob3VsZCBk ZXBsb3kgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0dXJlIGFsdGhvdWdoIGl0IHdpbGwgbWFrZSB0aGlu Z3MgY29tcGxpY2F0ZWQuPC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NL UVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+T2YgY291cnNl LCB0aGUgcmVtb3RlU3RvcmFnZSBpcyB0YXJnZXRlZCB0byBicm93c2Vycywgc28gc3luY2luZyBk b2VzIG5vdCBtYWtlIHRvbyBtdWNoIHNlbnNlIGluIHRoaXMgY2FzZS48QlI+PC9ESVY+CjxESVY+ V2l0aCB0aGUgcmlzZSBvZiBMaW51eCBjb250YWluZXIgbWljcm8tc2VydmljZSBiYXNlZCBhcmNo aXRlY3R1cmVzLCB0aGUgZGVwbG95bWVudCBvZiAmbmJzcDtzdWNoIGhpZ2hseSBjb21wbGV4IHN5 c3RlbXMgc2hvdWxkIGJlY29tZSBlYXNpZXIgYW5kIGZhc3Rlci48QlI+PC9ESVY+CjxESVY+Jm5i c3A7PC9ESVY+CjxESVY+QmVzdCw8U1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6IHJnYigxMzYsMTM2 LDEzNikiIGNsYXNzPSJjb2xvdXIiPjwvU1BBTj48L1NQQU4+PEJSPjwvRElWPgo8RElWPiZuYnNw OzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPjxTUEFOIHN0eWxlPSJDT0xPUjog cmdiKDEzNiwxMzYsMTM2KSIgY2xhc3M9ImNvbG91ciI+SHVnbzwvU1BBTj48L1NQQU4+PEJSPjwv RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxP Q0tRVU9URSB0eXBlPSJjaXRlIj4KPERJVj4KPERJViBzdHlsZT0iQ09MT1I6IHJnYigwLDAsMCki Pgo8RElWIHN0eWxlPSJPVkVSRkxPVy1YOiB2aXNpYmxlOyBPVkVSRkxPVy1ZOiB2aXNpYmxlIj4K PERJVj5SZWdhcmRzLDxCUj48L0RJVj4KPERJVj5MaW5odWkmbmJzcDs8QlI+PC9ESVY+CjxCTE9D S1FVT1RFIHN0eWxlPSJDT0xPUjogcmdiKDQ4LDU5LDY0KSI+CjxESVY+CjxESVY+Jm5ic3A7PC9E SVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFPgo8RElWIGRpcj0ibHRyIj4KPERJVj4K PERJVj4KPERJVj5SZWdhcmRzLDxCUj48L0RJVj4KPERJVj5MaW5odWk8QlI+PC9ESVY+CjxCTE9D S1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1B UkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4Ij4KPERJVj5vbmUgZnJv bSB0aGUgQ0VSTiBFT1MgcHJvamVjdCAobWFuYWdlbWVudCwgZGlzayBhbmQgcXVldWUgc2VydmVy cykuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlRoZSBQaGFzZSBJIGhhcyBpbXBs ZW1lbnRlZCB0aGUgb3duQ2xvdWQgU3luYyBQcm90b2NvbCBhbmQgUGhhc2UgSUkgd2lsbDxCUj48 L0RJVj4KPERJVj5pbXBsZW1lbnQgdGhlIFNlYUZpbGUgU3luYyBQcm90b2NvbC48QlI+PC9ESVY+ CjxESVY+VGhlIGNob2ljZSBvZiB0aGVzZSBwcm90b2NvbHMgYW1vbmcgb3RoZXJzIGlzIGJlY2F1 c2UgdGhleSBhcmUgcmVhbGx5PEJSPjwvRElWPgo8RElWPm9wcG9zZWQgdG8gZWFjaCBvdGhlciBp biB0ZXJtcyBvZiBzeW5jaW5nIChkZWx0YSB2cyBub24tZGVsdGEsPEJSPjwvRElWPgo8RElWPnN0 YXRlLWJhc2VkIHZzIGxvZy9ldmVudC9naXQtYmFzZWQgc3luYyDigKYpLCBzbyBmaW5kaW5nIGEg Y29tbW9uIGFwcHJvYWNoPEJSPjwvRElWPgo8RElWPmlzIG1vcmUgY2hhbGxlbmdpbmcuPEJSPjwv RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlByb3ZpZGluZyBhIGJhc2Ugc3BlY2lmaWNhdGlv bi9hcmNoaXRlY3R1cmUgdG8gbWVhc3VyZSB0aGUgZmVhc2liaWxpdHk8QlI+PC9ESVY+CjxESVY+ b2YgdGhpcyBkcmFmdCBpcyBvbmUgb2YgdGhlIG9iamVjdGl2ZXMgb2YgdGhlIHByb2plY3QuPEJS PjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkkgYmVsaWV2ZSB0aGF0IHRoZSB3b3JrIGJl aW5nIGRvbmUgaGVyZSBhbmQgaW4gQ2xhd0lPIGFyZSBzdXBwbGVtZW50YXJ5PEJSPjwvRElWPgo8 RElWPnRvIGVhY2ggb3RoZXIgYW5kIEkgdGhpbmsgbXV0dWFsIGNvbGxhYm9yYXRpb24gY291bGQg YmUgYmVuZWZpY2lhbCBmb3I8QlI+PC9ESVY+CjxESVY+Ym90aCBzaWRlcy48QlI+PC9ESVY+CjxE SVY+Jm5ic3A7PC9ESVY+CjxESVY+QWxzbywgaWYgdGhlcmUgaXMgaW50ZXJlc3QsIHRoZSByZW1v dGVTdG9yYWdlIEFQSSBjYW4gYmUgYWRkZWQgdG88QlI+PC9ESVY+CjxESVY+Q2xhd0lPLjxCUj48 L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5CZXN0IHJlZ2FyZHMsPEJSPjwvRElWPgo8RElW PiZuYnNwOzwvRElWPgo8RElWPkh1Z28gR29uemFsZXogTGFicmFkb3I8QlI+PC9ESVY+CjxESVY+ Jm5ic3A7PC9ESVY+CjxESVY+T24gVHVlLCBEZWMgMSwgMjAxNSwgYXQgMDk6MDAgUE0sIDxBIGhy ZWY9Im1haWx0bzpzdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9yZzwvQT4gd3JvdGU6PEJSPjwvRElWPgo8RElWPiZn dDsgU2VuZCBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG88QlI+PC9ESVY+ CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxBIGhyZWY9Im1haWx0bzpzdG9y YWdlc3luY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnN0b3JhZ2VzeW5jQGlldGYub3JnPC9B PjxCUj48L0RJVj4KPERJVj4mZ3Q7PEJSPjwvRElWPgo8RElWPiZndDsgVG8gc3Vic2NyaWJlIG9y IHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0PEJSPjwvRElWPgo8RElW PiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8QSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jIiB0YXJnZXQ9Il9ibGFuayI+PC9BPjxB IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 b3JhZ2VzeW5jPC9BPjxCUj48L0RJVj4KPERJVj4mZ3Q7IG9yLCB2aWEgZW1haWwsIHNlbmQgYSBt ZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bzxCUj48L0RJVj4KPERJVj4mZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PEEgaHJlZj0ibWFpbHRvOnN0b3JhZ2VzeW5jLXJl cXVlc3RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYu b3JnPC9BPjxCUj48L0RJVj4KPERJVj4mZ3Q7PEJSPjwvRElWPgo8RElWPiZndDsgWW91IGNhbiBy ZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0PEJSPjwvRElWPgo8RElWPiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8QSBocmVmPSJtYWlsdG86c3RvcmFnZXN5bmMtb3du ZXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zdG9yYWdlc3luYy1vd25lckBpZXRmLm9yZzwv QT48QlI+PC9ESVY+CjxESVY+Jmd0OzxCUj48L0RJVj4KPERJVj4mZ3Q7IFdoZW4gcmVwbHlpbmcs IHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWM8QlI+ PC9ESVY+CjxESVY+Jmd0OyB0aGFuICJSZTogQ29udGVudHMgb2YgU3RvcmFnZXN5bmMgZGlnZXN0 Li4uIjxCUj48L0RJVj4KPERJVj4mZ3Q7IFRvZGF5J3MgVG9waWNzOjxCUj48L0RJVj4KPERJVj4m Z3Q7PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7IDEuIE5ldyB2ZXJzaW9uIG9mIGRy YWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlJm5ic3A7ICZuYnNwOyBJbnRlcm5ldC1EcmFmdDxCUj48 L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXZhaWxhYmxlIChNaWNo aWVsIGRlIEpvbmcpPEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7IDIuIFJlOiBOZXcg dmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdDxCUj48 L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXZhaWxhYmxlIChHaWhh biBEaWFzKTxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAzLiBSZTogTmV3IHZlcnNp b24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgSW50ZXJuZXQtRHJhZnQ8QlI+PC9ESVY+ CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2F2YWlsYWJsZSAoRmVpIFNvbmcp PEJSPjwvRElWPgo8RElWPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+PC9ESVY+CjxESVY+Jmd0OyBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3Q8 QlI+PC9ESVY+CjxESVY+Jmd0OyA8QSBocmVmPSJtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5TdG9yYWdlc3luY0BpZXRmLm9yZzwvQT48QlI+PC9ESVY+CjxESVY+ Jmd0OyA8QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3Jh Z2VzeW5jIiB0YXJnZXQ9Il9ibGFuayI+PC9BPjxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jPC9BPjxCUj48L0RJVj4KPERJ Vj4mZ3Q7IEVtYWlsIGhhZCAzIGF0dGFjaG1lbnRzOjxCUj48L0RJVj4KPERJVj4mZ3Q7ICsgW1N0 b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZTxCUj48 L0RJVj4KPERJVj4mZ3Q7IEludGVybmV0LURyYWZ0IGF2YWlsYWJsZTxCUj48L0RJVj4KPERJVj4m Z3Q7Jm5ic3A7ICZuYnNwOzJrIChtZXNzYWdlL3JmYzgyMik8QlI+PC9ESVY+CjxESVY+Jmd0OyAr IFJlOiBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9y YWdlPEJSPjwvRElWPgo8RElWPiZndDsgSW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxlPEJSPjwvRElW Pgo8RElWPiZndDsmbmJzcDsgJm5ic3A7MWsgKG1lc3NhZ2UvcmZjODIyKTxCUj48L0RJVj4KPERJ Vj4mZ3Q7ICsgUmU6IFtTdG9yYWdlc3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJl bW90ZXN0b3JhZ2U8QlI+PC9ESVY+CjxESVY+Jmd0OyBJbnRlcm5ldC1EcmFmdCBhdmFpbGFibGU8 QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsyayAobWVzc2FnZS9yZmM4MjIpPEJSPjwv RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPEJSPjwvRElWPgo8RElWPlN0b3JhZ2VzeW5jIG1haWxpbmcgbGlz dDxCUj48L0RJVj4KPERJVj48QSBocmVmPSJtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5TdG9yYWdlc3luY0BpZXRmLm9yZzwvQT48QlI+PC9ESVY+CjxESVY+PEEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIg dGFyZ2V0PSJfYmxhbmsiPjwvQT48QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N0b3JhZ2VzeW5jIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYzwvQT48QlI+PC9ESVY+PC9CTE9DS1FVT1RF PjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj4mbmJzcDs8L0RJVj48L0RJVj48 L0JMT0NLUVVPVEU+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPiZuYnNwOzwv RElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48L0RJVj48L0RJVj48L0JM T0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RF PjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj4mbmJzcDs8L0RJVj48L0JMT0NL UVVPVEU+ ------=_Part_40109_1212717290.1449129771334-- From nobody Thu Dec 3 00:13:58 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD71B30CD for ; Thu, 3 Dec 2015 00:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxP3a8qFqdy5 for ; Thu, 3 Dec 2015 00:13:51 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD951B30BE for ; Thu, 3 Dec 2015 00:13:51 -0800 (PST) Received: by wmuu63 with SMTP id u63so10305071wmu.0 for ; Thu, 03 Dec 2015 00:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=I5Q5NgC0pETu2exfd6dVmM+rigxgvJM++3mSWzoT++w=; b=kKQTbUqEutwtN/ZkJXDXLgIyCHymq0mHLM+xLldDTyu8Nr2tX7olRIliwbFPZQ3Q9c 32PPfJpMu9N2PSwcEazKZbBKGa15NqW4WOBNex/NFYGfwNGeVuyPniiz0SGBbP3AGX8g YBxgMIlmZNRfYFlPoeJCBRoyC4z4lCGcdG4SyqRPp0S2u0udgAiO2XKnbgzHgGRdfvYj 9oEzifbyXXGk/xvSY+LR6qnAD4CtKGAy8DYwfXS+/X3tzR0qBJojx7h9/Q4FpP8SupXD 959FNmTmLrkyQ8VmFbQGMl62twKurb19niGEuuJxVxQ3YoS6wF1wi0QEHaDHmpJVceys wZKQ== X-Received: by 10.194.79.72 with SMTP id h8mr10395747wjx.136.1449130429812; Thu, 03 Dec 2015 00:13:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Thu, 3 Dec 2015 00:13:29 -0800 (PST) In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> From: Linhui Sun Date: Thu, 3 Dec 2015 16:13:29 +0800 Message-ID: To: Michiel de Jong Content-Type: multipart/alternative; boundary=047d7bb0499e8096b20525f9f84f Archived-At: Cc: storagesync , fkooman , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 08:13:57 -0000 --047d7bb0499e8096b20525f9f84f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I've missed some part of your message yesterday, please see my comments inline. 2015-12-02 20:30 GMT+08:00 Michiel de Jong : > Hi all! > > Thanks for all your reactions to the remoteStorage Internet-Draft. > > We get the question about WebDAV a lot, in the next version we should add > a remark about it in the intro. The folder descriptions returned when you > GET a URL that ends with a / are indeed a deviation from the XML returned > by WebDAV server, and this is just because nowadays JSON is easier to use > than XML for developers, both client-side and server-side. > > The fact that we don't require servers to support WebDAV's custom verbs > like PROPPATCH etc. is for three reasons: > 1) it's a lot of work to implement this without using an existing WebDAV > library > 2) in practice, a lot of WebDAV servers get it wrong, or don't implement > all of WebDAV. It's very annoying for client implementers to have to deal > with servers that e.g. chose not to implement LOCK and UNLOCK. > 3) we don't really need all these advanced features on top of standard > HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple > folder description format, is enough for most applications. > > Other than that, the remoteStorage Internet-Draft specifies a *lot* more > than just how each HTTP verb should behave: > * requiring support for OAuth implicit-grant flow > * requiring ETag support and nested versioning (i.e. the folder's ETag > changes if anything within that folder changes) > * requiring CORS headers > * requiring a WebFinger announcement for service discovery > > It would be easy to add these three things on top of WebDAV, instead of > putting them on top of our minimal GET/PUT/DELETE API definition. In fact= , > we could probably separate it into two Internet-Drafts: one for the > 'RESTful folders' API which is our simplification of WebDAV, and a second > one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful > folders' or whatever other HTTP-based API you want. > > On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < > ietf@hugo.labkode.com> wrote: > >> >> >> >> On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: >> >> Hi >> >> On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez = Labrador < >> ietf@hugo.labkode.com> wrote: >> >> >> >> >> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >> >> Hi >> >> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : >> >> Hi, >> >> from my point of view the remoteStorage project addresses a subset of >> the use cases of the WebDAV specification. >> >> The main difference I can observe is that the specification is built on >> REST instead of XML-based communication. >> >> >> I personally like much more REST than WebDAV because it is more >> developer friendly and it is faster to develop. >> Maybe the remoteStorage API becomes the next WebDAV :) >> >> However, the remoteStorage API does not provide a way of synchronising >> data, this task is delegated to the developers. >> Is there a plan to provide such feature based on the outcome of this >> draft? >> >> I'm a little bit confused why you say the remoteStorage does not provide >> that. Is that because remoteStorage does not perform like a typical sync >> services (e.g. dropbox...) or you are saying something else? >> >> Yes, because it does not offer synchronisation capabilities. >> >> Got it. And What I am wondering is that do we need to include those >> capabilities in a base specifications. Since it is hard to standardize t= he >> capabilities like dedup or delta. Maybe a better way is to define those = in >> a separate specification, >> >> > Thanks for giving these examples - so by 'synchronisation capabilities' > you mean 1) deduplication and 2) delta updates? Anything else or is that = an > exhaustive list? > Yes and something like chunking (the one I've mentioned in the previous message) and bundling. They are typically client capabilities (or referred as service capabilities). These should be beyond the basic document like the remoteStorage, but is important and useful to be defined in a companion document. > something like extensions. For a base document, we just need to define ho= w >> to perform sync operations. >> >> >> Yes, I agree that may be an extension of this draft could handle the >> synchronisation part. >> >> > > Our Internet-Draft is heavily focused on the world wide web, whose URLs > are not content-addressable, we can't change that. So that architecture i= s > not very friendly to deduplication, compared to for instance BitTorrent. = As > you already said, developers can still dedupe on the server-side when > storing blobs to disk, and can also dedupe on the client side before > creating the resources the client uploads. > IMO, performing dedup. inside server or client itself is not interesting. What we want for a sync service is to reduce the number of transmitting packets between client and server. That requires both client and server should be aware of which packet should be transmitted. And I think capabilities like dedup. has nothing to do with whether you use a distributed architecture. > > As far as I know, delta updates are not supported by the ETag system - yo= u > cannot do a range request to find out if certain bytes within a document > have changed. However, the folder system we define does encourage you, fo= r > instance when you develop a To Do List app, put each task on its own > document, and then query the folder to see which of them changed, instead > of putting them all in one big document and retrieving the whole document > each time. > That's a delta update in essence, but is done by user behavior. And could we make the "query the folder" something like server push (similar issue in webpush WG)? When there is a change, the server will notify the client. Regards, Linhui > > > Cheers, > Michiel. > > >> >> >> BTW, I want to introduce ClawIO ( >> http://clawio.github.io), a research >> project to benchmark different synchronisation protocols against >> different data backends with special attention to provide a common sync >> API. >> >> A common API for different sync protocols is being created based on the >> architecture specified in this draft (control and data servers) and the >> >> I cannot find a distributed architecture in this draft. It seems that >> they handle metadata and content data together, just like a normal web >> service. >> >> >> ClawIO is fully distributed. Every logical unit is a different server >> than be scaled out. Data and Metadata channels are independent from each >> other and reside on different servers. >> >> That is widely employed in popular sync services. And that is also >> beneficial to privacy to some extent. But in the context of sync in brow= ser >> (which is mainly considered in the remoteStorage), I don't know whether >> this is reasonable. But I think we should deploy distributed architectur= e >> although it will make things complicated. >> >> >> Of course, the remoteStorage is targeted to browsers, so syncing does no= t >> make too much sense in this case. >> With the rise of Linux container micro-service based architectures, the >> deployment of such highly complex systems should become easier and fast= er. >> >> Best, >> >> Hugo >> >> >> Regards, >> Linhui >> >> >> >> >> Regards, >> Linhui >> >> one from the CERN EOS project (management, disk and queue servers). >> >> The Phase I has implemented the ownCloud Sync Protocol and Phase II will >> implement the SeaFile Sync Protocol. >> The choice of these protocols among others is because they are really >> opposed to each other in terms of syncing (delta vs non-delta, >> state-based vs log/event/git-based sync =E2=80=A6), so finding a common = approach >> is more challenging. >> >> Providing a base specification/architecture to measure the feasibility >> of this draft is one of the objectives of the project. >> >> I believe that the work being done here and in ClawIO are supplementary >> to each other and I think mutual collaboration could be beneficial for >> both sides. >> >> Also, if there is interest, the remoteStorage API can be added to >> ClawIO. >> >> Best regards, >> >> Hugo Gonzalez Labrador >> >> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: >> > Send Storagesync mailing list submissions to >> > storagesync@ietf.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > >> https://www.ietf.org/mailman/listinfo/storagesync >> > or, via email, send a message with subject or body 'help' to >> > storagesync-request@ietf.org >> > >> > You can reach the person managing the list at >> > storagesync-owner@ietf.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of Storagesync digest..." >> > Today's Topics: >> > >> > 1. New version of draft-dejong-remotestorage Internet-Draft >> > available (Michiel de Jong) >> > 2. Re: New version of draft-dejong-remotestorage Internet-Draft >> > available (Gihan Dias) >> > 3. Re: New version of draft-dejong-remotestorage Internet-Draft >> > available (Fei Song) >> > _______________________________________________ >> > Storagesync mailing list >> > Storagesync@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/storagesync >> > Email had 3 attachments: >> > + [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> > 2k (message/rfc822) >> > + Re: [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> > 1k (message/rfc822) >> > + Re: [Storagesync] New version of draft-dejong-remotestorage >> > Internet-Draft available >> > 2k (message/rfc822) >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> >> https://www.ietf.org/mailman/listinfo/storagesync >> >> >> >> >> > > --047d7bb0499e8096b20525f9f84f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

I've missed some part of your me= ssage yesterday, please see my comments inline.

2015-12-02 20:30 GMT+08:00 Michiel de Jon= g <mbdejong@mozilla.com>:
=
Hi all!

Thanks for all your reactions to the remoteStorag= e Internet-Draft.

We get the question about WebDAV a lot, in t= he next version we should add a remark about it in the intro. The folder de= scriptions returned when you GET a URL that ends with a / are indeed a devi= ation from the XML returned by WebDAV server, and this is just because nowa= days JSON is easier to use than XML for developers, both client-side and se= rver-side.

The fact that we don't require servers to suppo= rt WebDAV's custom verbs like PROPPATCH etc. is for three reasons:
<= /div>1) it's a lot of work to implement this without using an existing = WebDAV library
2) in practice, a lot of WebDAV servers get it wron= g, or don't implement all of WebDAV. It's very annoying for client = implementers to have to deal with servers that e.g. chose not to implement = LOCK and UNLOCK.
3) we don't really need all these advanced fe= atures on top of standard HTTP, just supporting GET/PUT/DELETE for resource= s, and adding a simple folder description format, is enough for most applic= ations.

Other than that, the remoteStorage Internet-Draft spec= ifies a *lot* more than just how each HTTP verb should behave:
* r= equiring support for OAuth implicit-grant flow
* requiring ET= ag support and nested versioning (i.e. the folder's ETag changes if any= thing within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery

I= t would be easy to add these three things on top of WebDAV, instead of putt= ing them on top of our minimal GET/PUT/DELETE API definition. In fact, we c= ould probably separate it into two Internet-Drafts: one for the 'RESTfu= l folders' API which is our simplification of WebDAV, and a second one = for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful fold= ers' or whatever other HTTP-based API you want.

On Wed, Dec 2, 2015 at 11= :28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
On =E5=91=A8=E4=B8=89, 12=E6=9C= =88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:=
<= div>
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subset of<= br>
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is built o= n
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchronising=
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of this
draft?
I'm a little bit confused why you say the remoteStora= ge does not provide that. Is that because remoteStorage does not perform li= ke a typical sync services (e.g. dropbox...) or you are saying something el= se?
Yes, because it does not offer synchronisation capabiliti= es.
Got it. And What I am wondering is that do we need to inc= lude those capabilities in a base specifications. Since it is hard to stand= ardize the capabilities like dedup or delta. Maybe a better way is to defin= e those in a separate specification,
<= /span>

Thanks for giving these= examples - so by=20 'synchronisation capabilities' you mean 1) deduplication and 2) del= ta=20 updates? Anything else or is that an exhaustive list?
Yes and something like chunking (the one I've = mentioned in the previous message) and bundling. They are typically client = capabilities (or referred as service capabilities). These should be beyond = the basic document like the remoteStorage, but is important and useful to b= e defined in a companion document.
something like extensions. For a base document, we just= need to define how to perform sync operations.
=C2=A0
Yes, I agree that may be an extension of this draft could hand= le the synchronisation part.
=C2=A0

Our Internet-Dra= ft is heavily focused on the world wide web, whose URLs are not content-add= ressable, we can't change that. So that architecture is not very friend= ly to deduplication, compared to for instance BitTorrent. As you already sa= id, developers can still dedupe on the server-side when storing blobs to di= sk, and can also dedupe on the client side before creating the resources th= e client uploads.
IMO, perform= ing dedup. inside server or client itself is not interesting. What we want = for a sync service is to reduce the number of transmitting packets between = client and server. That requires both client and server should be aware of = which packet should be transmitted. And I think capabilities like dedup. ha= s nothing to do with whether you use a distributed architecture.

As far as I know, delta updates a= re not supported by the ETag system - you cannot do a range request to find= out if certain bytes within a document have changed. However, the folder s= ystem we define does encourage you, for instance when you develop a To Do L= ist app, put each task on its own document, and then query the folder to se= e which of them changed, instead of putting them all in one big document an= d retrieving the whole document each time.
That's a delta update in essence, but is done by user beha= vior. And could we make the "query the folder" something like ser= ver push (similar issue in webpush WG)? When there is a change, the server = will notify the client.

Regards,
Linhui<= /div>


Cheers,
Michiel.

= =C2=A0
=C2= =A0
BTW, I want to introduce ClawIO (= http://clawio.github.io), a research
project to benchmark different synchronisation protocols against
different data backends with special attention to provide a common syn= c
API.
=C2=A0
A common API for different sync protocols is being created based on th= e
architecture specified in this draft (control and data servers) and th= e
I cannot find a distributed architecture in this draft. I= t seems that they handle metadata and content data together, just like a no= rmal web service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different server = than be scaled out. Data and Metadata channels are independent from each ot= her and reside on different servers.
That is widely employed in popular sync services. And tha= t is also beneficial to privacy to some extent. But in the context of sync = in browser (which is mainly considered in the remoteStorage), I don't k= now whether this is reasonable. But I think we should deploy distributed ar= chitecture although it will make things complicated.
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncin= g does not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=C2=A0
Hugo
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (management,= disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0


--047d7bb0499e8096b20525f9f84f-- From nobody Thu Dec 3 00:38:14 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111711B32B4 for ; Thu, 3 Dec 2015 00:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elYR6ek9Gvng for ; Thu, 3 Dec 2015 00:38:08 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4621B32AD for ; Thu, 3 Dec 2015 00:38:07 -0800 (PST) Received: by ajax-webmail-Jdweb3 (Coremail) ; Thu, 3 Dec 2015 16:40:37 +0800 (GMT+08:00) Date: Thu, 3 Dec 2015 16:40:37 +0800 (GMT+08:00) From: fsong@bjtu.edu.cn To: "Michiel de Jong" Message-ID: In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_40721_16669507.1449132037389" X-Originating-IP: [106.2.233.19] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20150107(58648.7033.6860) Copyright (c) 2002-2015 www.mailtech.cn bjtu X-SendMailWithSms: false X-CM-TRANSID: d55wygBHshIFAGBWmqwFAA--.1196W X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/1tbiAQIMB1R9XjYYmwAAsK X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: Linhui Sun , storagesync , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 08:38:12 -0000 ------=_Part_40721_16669507.1449132037389 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwKCiAKCkJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbiBvbiBodHRwOi8vcmVtb3Rl c3RvcmFnZS5pby8g4oCccmVtb3RlU3RvcmFnZS1lbmFibGVkIGFwcHMgYXV0b21hdGljYWxseSBz eW5jIHlvdXIgZGF0YSBhY3Jvc3MgYWxsIG9mIHlvdXIgZGV2aWNlc+KAnS4KCiAKCkhvd2V2ZXIs IHRoZXJlIGlzIG5vIHN5bmNocm9uaXphdGlvbiBpbiB0aGUgYWJzdHJhY3QuCgrigJxUaGUgcHJv dG9jb2wgc3VwcG9ydHMgc3RvcmluZywgcmV0cmlldmluZywgYW5kIHJlbW92aW5nIGluZGl2aWR1 YWwgZG9jdW1lbnRzLCBhcyB3ZWxsIGFzIGxpc3RpbmcgdGhlIGNvbnRlbnRzIG9mIGFuIGluZGl2 aWR1YWwgZm9sZGVyLCBhbmQgYWNjZXNzIGNvbnRyb2wgaXMgYmFzZWQgb24gYmVhcmVyIHRva2Vu c+KAnQoKIAoKVGhlcmVmb3JlLCBJIHRoaW5rOgoKSWYgc3luY2hyb25pemF0aW9uIGlzIGFkZGVk IGludG8gYWJzdHJhY3QsIHRoZSBNT1ZFIGFjdGlvbiBzaG91bGQgYmUgYWRkZWQgZm9yIHN1cmUu CgpJZiBzeW5jaHJvbml6YXRpb24gaXMgbm90IGluY2x1ZGVkLCBsaWtlIGN1cnJlbnQgdmVyc2lv biwgdGhlIGJhc2ljIGFjdGlvbnMgaW4gZHJhZnQgYXJlIGVub3VnaC4KCgogCgotLS0tLeWOn+Wn i+mCruS7ti0tLS0tCuWPkeS7tuS6ujogIk1pY2hpZWwgZGUgSm9uZyIgPG1iZGVqb25nQG1vemls bGEuY29tPgrlj5HpgIHml7bpl7Q6IDIwMTXlubQxMuaciDLml6Ug5pif5pyf5LiJCuaUtuS7tuS6 ujogIkxpbmh1aSBTdW4iIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4K5oqE6YCBOiBzdG9yYWdlc3lu YyA8c3RvcmFnZXN5bmNAaWV0Zi5vcmc+LCBma29vbWFuIDxma29vbWFuQHR1eGVkLm5ldD4sICJI dWdvIEdvbnrDoWxleiBMYWJyYWRvciIgPGlldGZAaHVnby5sYWJrb2RlLmNvbT4K5Li76aKYOiBS ZTogW1N0b3JhZ2VzeW5jXSBTdG9yYWdlc3luYyBEaWdlc3QsIFZvbCA1LCBJc3N1ZSAxCgoKQ29v bCEgSSBjcmVhdGVkIGh0dHBzOi8vZ2l0aHViLmNvbS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVz LzEzNyBhYm91dCB0aGUgbmVlZCBmb3IgIE1PVkUgdmVyYi4KCgpBcHBsaWNhdGlvbi1sZXZlbCBj aHVua2luZyBpcyBwYXJ0aWFsbHkgc3VwcG9ydGVkIGJ5IEhUVFAgaXRzZWxmIHRocm91Z2ggYENv bnRlbnQtUmFuZ2VgIGhlYWRlcnMgKGFsdGhvdWdoIGl0J3Mgbm90IGNsZWFyIHdoZXRoZXIgdGhl c2UgYXJlIGFsbG93ZWQgb24gUFVUIHJlcXVlc3RzIGFzIHdlbGwgYXMgb24gR0VUIHJlcXVlc3Rz LCBzZWUgaHR0cHM6Ly9naXRodWIuY29tL3JlbW90ZXN0b3JhZ2Uvc3BlYy9pc3N1ZXMvMTMxKS4g VGhlIHByb2JsZW0gaXMgdGhhdCBIVFRQIGRlZmluZXMgdmVyc2lvbmluZyBhdCB0aGUgZG9jdW1l bnQgbGV2ZWwsIHlvdSBjYW5ub3QgYXNrIGEgc2VydmVyIHRvIHByb2R1Y2Ugb3IgY2hlY2sgYW4g RVRhZyBmb3IgYSBzcGVjaWZpYyBieXRlLXJhbmdlIG9mIGEgZG9jdW1lbnQsIG9ubHkgZm9yIHRo ZSBlbnRpcmUgZG9jdW1lbnQuCgoKQSBjb21wYXJpc29uIGRvY3VtZW50IHNvdW5kcyBnb29kISBT ZWUgYWxzbyBodHRwOi8vd3d3LnNlcnZpY2VkZW51YWdlcy5mci9lbi9nZW5lcmljLXN0b3JhZ2Ut ZWNvc3lzdGVtLgoKCgpDaGVlcnMsCgpNaWNoaWVsLgoKCgoKT24gV2VkLCBEZWMgMiwgMjAxNSBh dCAyOjMyIFBNLCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4gd3JvdGU6CgpUaGF0 J3MgY29vbCBmb3IgbWUsIGEgc2VwYXJhdGUgc2VjdGlvbiBmb3IgdGhpcyBtaWdodCBtYWtlIHNl bnNlLgoKCkFub3RoZXIgdGhpbmcgaXMgZG8gd2UgbmVlZCB0byBpbmNsdWRlIGFuIGFwcGxpY2F0 aW9uLWxheWVyIGNodW5raW5nIGhlcmUgKG5vdCBqdXN0IGZvciBhIGJyb3dzZXIgc3luYyksIHNp bmNlIGlmIHdlIHdhbnQgdG8gZnVydGhlciBleHRlbmQgb3RoZXIgY2FwYWJpbGl0aWVzIGl0IGlz IGVzc2VudGlhbC4KCgoKUmVnYXJkcywKTGluaHVpCgoKMjAxNS0xMi0wMiAyMTowMyBHTVQrMDg6 MDAgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT46CgpJIHBy b3Bvc2UgdG8gY29tZSB1cCB3aXRoIGEgbGlzdCBvZiBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRh Z2VzIG9mIHVzaW5nIFdlYkRBViBhbmQgY29tcGFyZSB0aGVtIGFnYWluc3QgYSBKU09OL1JFU1Qg YmFzZWQgYXBwcm9hY2gsIGxpa2UgcmVtb3RlU3RvcmFnZS4KCiAKRG9lcyBpdCBzb3VuZCBnb29k ID8KIAogCk9uIFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjU5IFBNLCBMaW5odWkgU3VuIHdyb3Rl OgoKIAogCjIwMTUtMTItMDIgMjA6NDMgR01UKzA4OjAwIEh1Z28gR29uesOhbGV6IExhYnJhZG9y IDxpZXRmQGh1Z28ubGFia29kZS5jb20+OgoKCgogCiAKIAogCk9uIFdlZCwgRGVjIDIsIDIwMTUs IGF0IDAxOjMwIFBNLCBNaWNoaWVsIGRlIEpvbmcgd3JvdGU6CgpIaSBhbGwhCgpUaGFua3MgZm9y IGFsbCB5b3VyIHJlYWN0aW9ucyB0byB0aGUgcmVtb3RlU3RvcmFnZSBJbnRlcm5ldC1EcmFmdC4K CiAKV2UgZ2V0IHRoZSBxdWVzdGlvbiBhYm91dCBXZWJEQVYgYSBsb3QsIGluIHRoZSBuZXh0IHZl cnNpb24gd2Ugc2hvdWxkIGFkZCBhIHJlbWFyayBhYm91dCBpdCBpbiB0aGUgaW50cm8uIFRoZSBm b2xkZXIgZGVzY3JpcHRpb25zIHJldHVybmVkIHdoZW4geW91IEdFVCBhIFVSTCB0aGF0IGVuZHMg d2l0aCBhIC8gYXJlIGluZGVlZCBhIGRldmlhdGlvbiBmcm9tIHRoZSBYTUwgcmV0dXJuZWQgYnkg V2ViREFWIHNlcnZlciwgYW5kIHRoaXMgaXMganVzdCBiZWNhdXNlIG5vd2FkYXlzIEpTT04gaXMg ZWFzaWVyIHRvIHVzZSB0aGFuIFhNTCBmb3IgZGV2ZWxvcGVycywgYm90aCBjbGllbnQtc2lkZSBh bmQgc2VydmVyLXNpZGUuCgogCiAKSSB0b3RhbGx5IGFncmVlIGhlcmUsIHRoaXMgd2FzIGdvaW5n IHRvIGhhcHBlbiBzb29uIG9yIGxhdGVyIGFuZCBpdCBpcyByZWFsbHkgYXBwcmVjaWF0ZWQuCgog CiAKVGhlIGZhY3QgdGhhdCB3ZSBkb24ndCByZXF1aXJlIHNlcnZlcnMgdG8gc3VwcG9ydCBXZWJE QVYncyBjdXN0b20gdmVyYnMgbGlrZSBQUk9QUEFUQ0ggZXRjLiBpcyBmb3IgdGhyZWUgcmVhc29u czoKCjEpIGl0J3MgYSBsb3Qgb2Ygd29yayB0byBpbXBsZW1lbnQgdGhpcyB3aXRob3V0IHVzaW5n IGFuIGV4aXN0aW5nIFdlYkRBViBsaWJyYXJ5CgoyKSBpbiBwcmFjdGljZSwgYSBsb3Qgb2YgV2Vi REFWIHNlcnZlcnMgZ2V0IGl0IHdyb25nLCBvciBkb24ndCBpbXBsZW1lbnQgYWxsIG9mIFdlYkRB Vi4gSXQncyB2ZXJ5IGFubm95aW5nIGZvciBjbGllbnQgaW1wbGVtZW50ZXJzIHRvIGhhdmUgdG8g ZGVhbCB3aXRoIHNlcnZlcnMgdGhhdCBlLmcuIGNob3NlIG5vdCB0byBpbXBsZW1lbnQgTE9DSyBh bmQgVU5MT0NLLgoKMykgd2UgZG9uJ3QgcmVhbGx5IG5lZWQgYWxsIHRoZXNlIGFkdmFuY2VkIGZl YXR1cmVzIG9uIHRvcCBvZiBzdGFuZGFyZCBIVFRQLCBqdXN0IHN1cHBvcnRpbmcgR0VUL1BVVC9E RUxFVEUgZm9yIHJlc291cmNlcywgYW5kIGFkZGluZyBhIHNpbXBsZSBmb2xkZXIgZGVzY3JpcHRp b24gZm9ybWF0LCBpcyBlbm91Z2ggZm9yIG1vc3QgYXBwbGljYXRpb25zLgoKIApPdGhlciB0aGFu IHRoYXQsIHRoZSByZW1vdGVTdG9yYWdlIEludGVybmV0LURyYWZ0IHNwZWNpZmllcyBhICpsb3Qq IG1vcmUgdGhhbiBqdXN0IGhvdyBlYWNoIEhUVFAgdmVyYiBzaG91bGQgYmVoYXZlOgoKKiByZXF1 aXJpbmcgc3VwcG9ydCBmb3IgT0F1dGggaW1wbGljaXQtZ3JhbnQgZmxvdwoKKiByZXF1aXJpbmcg RVRhZyBzdXBwb3J0IGFuZCBuZXN0ZWQgdmVyc2lvbmluZyAoaS5lLiB0aGUgZm9sZGVyJ3MgRVRh ZyBjaGFuZ2VzIGlmIGFueXRoaW5nIHdpdGhpbiB0aGF0IGZvbGRlciBjaGFuZ2VzKQoKKiByZXF1 aXJpbmcgQ09SUyBoZWFkZXJzCgoqIHJlcXVpcmluZyBhIFdlYkZpbmdlciBhbm5vdW5jZW1lbnQg Zm9yIHNlcnZpY2UgZGlzY292ZXJ5CgpJdCB3b3VsZCBiZSBlYXN5IHRvIGFkZCB0aGVzZSB0aHJl ZSB0aGluZ3Mgb24gdG9wIG9mIFdlYkRBViwgaW5zdGVhZCBvZiBwdXR0aW5nIHRoZW0gb24gdG9w IG9mIG91ciBtaW5pbWFsIEdFVC9QVVQvREVMRVRFIEFQSSBkZWZpbml0aW9uLiBJbiBmYWN0LCB3 ZSBjb3VsZCBwcm9iYWJseSBzZXBhcmF0ZSBpdCBpbnRvIHR3byBJbnRlcm5ldC1EcmFmdHM6IG9u ZSBmb3IgdGhlICdSRVNUZnVsIGZvbGRlcnMnIEFQSSB3aGljaCBpcyBvdXIgc2ltcGxpZmljYXRp b24gb2YgV2ViREFWLCBhbmQgYSBzZWNvbmQgb25lIGZvciBPQXV0aC9FVGFncy9DT1JTL1dlYkZp bmdlciBvbiB0b3Agb2YgZWl0aGVyIFdlYkRBViBvciAnUkVTVGZ1bCBmb2xkZXJzJyBvciB3aGF0 ZXZlciBvdGhlciBIVFRQLWJhc2VkIEFQSSB5b3Ugd2FudC4KCiAKIApUaGVyZSBpcyBvbmUgcmVx dWlyZW1lbnQgdGhhdCBhbGwgc3luY2hyb25pc2VycyBuZWVkIHRvIGhhbmRsZTogbW92aW5nIHJl c291cmNlcy4gSW4gdGhpcyBzcGVjIHRoZSBhbHRlcm5hdGl2ZSBvZiBhIFdlYkRBViBNT1ZFIGlz IG5vdCBzcGVjaWZpZWQuIAoKIApJdCBpcyB0cnVlIHRoYXQgYSBNT1ZFIGNvdWxkIGJlIHJlcGxh Y2VkIHdpdGggYSBERUxFVEUgKyBVUExPQUQgYnV0IHRoYXQgaXMgbm90IGFjY2VwdGFibGUgaW4g bW9zdCBjYXNlcyBkdWUgdG8gdGhlIGluZWZmaWNpZW5jeSBvZiBzdWNoIG9wZXJhdGlvbiAoY3B1 LCBiYW5kd2lkdGggY29uc3VtcHRpb24gLi4uKQoKIApJcyB0aGVyZSBhIHBsYW4gdG8gc3VwcG9y dCBzdWNoIGJhc2ljIGZlYXR1cmU/CgogCkZyb20gdGhlIGN1cnJlbnQgcmVtb3RlU3RvcmFnZSBz cGVjLCB0aGUgb3duQ2xvdWQgc3luYyBwcm90b2NvbCBjYW4gYmUgaW1wbGVtZW50ZWQuIFRoZSBt aXNzaW5nIGJpdCBpcyB0cmFja2luZyB0aG9zZSByZW1vdGUgbW92ZXMuCgpJIGFncmVlIHdpdGgg SHVnbyB0aGF0IE1PVkUgaXMgdXNlZnVsLCBzb21ldGltZXMgaWYgeW91IGp1c3QgcmVuYW1lIGEg ZmlsZSBpdCB3aWxsIGJlIHBlcmZlY3QuIEJ1dCB0aGUgcXVlc3Rpb24gSSBoYXZlIGlzIHRoYXQg d2hldGhlciB3ZSBuZWVkIHRvIG1ha2UgdHdvIGRvY3VtZW50cz8gTXVsdGlwbGUgY2hvaWNlcyBp cyBub3QgZ29vZCBmb3Igc3RhbmRhcmRpemF0aW9uLiBJbiBteSB2aWV3LCB3ZWJkYXYgaXMgc29t ZXRoaW5nIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEgdmVyeSBjbGVhciBkZWNpc2lvbiBvbiB3aGV0 aGVyIHRvIGNvbnNpZGVyIGl0IG9yIG5vdC4KCiAKUmVnYXJkcywKCkxpbmh1aQoKIAogCkNoZWVy cwoKIApPbiBXZWQsIERlYyAyLCAyMDE1IGF0IDExOjI4IEFNLCBIdWdvIEdvbnrDoWxleiBMYWJy YWRvciA8aWV0ZkBodWdvLmxhYmtvZGUuY29tPiB3cm90ZToKCgoKIAogCiAKIApPbiBXZWQsIERl YyAyLCAyMDE1LCBhdCAxMToxOCBBTSwgTGluaHVpIFN1biB3cm90ZToKCkhpCgogCk9uIOWRqOS4 iSwgMTLmnIggMiwgMjAxNSBhdCAxNzo1NiwgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPGlldGZA aHVnby5sYWJrb2RlLmNvbT4gd3JvdGU6CgogCiAKIApPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAw ODoyMCBBTSwgTGluaHVpIFN1biB3cm90ZToKCkhpCgogCjIwMTUtMTItMDIgNToxNCBHTVQrMDg6 MDAgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT46CgpIaSwK CiAKZnJvbSBteSBwb2ludCBvZiB2aWV3IHRoZSByZW1vdGVTdG9yYWdlIHByb2plY3QgYWRkcmVz c2VzIGEgc3Vic2V0IG9mCgp0aGUgdXNlIGNhc2VzIG9mIHRoZSAgV2ViREFWIHNwZWNpZmljYXRp b24uCgogClRoZSBtYWluIGRpZmZlcmVuY2UgSSBjYW4gb2JzZXJ2ZSBpcyB0aGF0IHRoZSBzcGVj aWZpY2F0aW9uIGlzIGJ1aWx0IG9uCgpSRVNUIGluc3RlYWQgb2YgWE1MLWJhc2VkIGNvbW11bmlj YXRpb24uCgogCkkgcGVyc29uYWxseSBsaWtlIG11Y2ggbW9yZSBSRVNUIHRoYW4gV2ViREFWIGJl Y2F1c2UgaXQgaXMgbW9yZQoKZGV2ZWxvcGVyIGZyaWVuZGx5IGFuZCBpdCBpcyBmYXN0ZXIgdG8g ZGV2ZWxvcC4KCiBNYXliZSB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgYmVjb21lcyB0aGUgbmV4dCBX ZWJEQVYgOikKCiAKSG93ZXZlciwgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGRvZXMgbm90IHByb3Zp ZGUgYSB3YXkgb2Ygc3luY2hyb25pc2luZwoKZGF0YSwgdGhpcyB0YXNrIGlzIGRlbGVnYXRlZCB0 byB0aGUgZGV2ZWxvcGVycy4KCklzIHRoZXJlIGEgcGxhbiB0byBwcm92aWRlIHN1Y2ggZmVhdHVy ZSBiYXNlZCBvbiB0aGUgb3V0Y29tZSBvZiB0aGlzCgpkcmFmdD8KCkknbSBhIGxpdHRsZSBiaXQg Y29uZnVzZWQgd2h5IHlvdSBzYXkgdGhlIHJlbW90ZVN0b3JhZ2UgZG9lcyBub3QgcHJvdmlkZSB0 aGF0LiBJcyB0aGF0IGJlY2F1c2UgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBwZXJmb3JtIGxpa2Ug YSB0eXBpY2FsIHN5bmMgc2VydmljZXMgKGUuZy4gZHJvcGJveC4uLikgb3IgeW91IGFyZSBzYXlp bmcgc29tZXRoaW5nIGVsc2U/CgpZZXMsIGJlY2F1c2UgaXQgZG9lcyBub3Qgb2ZmZXIgc3luY2hy b25pc2F0aW9uIGNhcGFiaWxpdGllcy4KCkdvdCBpdC4gQW5kIFdoYXQgSSBhbSB3b25kZXJpbmcg aXMgdGhhdCBkbyB3ZSBuZWVkIHRvIGluY2x1ZGUgdGhvc2UgY2FwYWJpbGl0aWVzIGluIGEgYmFz ZSBzcGVjaWZpY2F0aW9ucy4gU2luY2UgaXQgaXMgaGFyZCB0byBzdGFuZGFyZGl6ZSB0aGUgY2Fw YWJpbGl0aWVzIGxpa2UgZGVkdXAgb3IgZGVsdGEuIE1heWJlIGEgYmV0dGVyIHdheSBpcyB0byBk ZWZpbmUgdGhvc2UgaW4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLAoKIAogClRoYW5rcyBmb3Ig Z2l2aW5nIHRoZXNlIGV4YW1wbGVzIC0gc28gYnkgJ3N5bmNocm9uaXNhdGlvbiBjYXBhYmlsaXRp ZXMnIHlvdSBtZWFuIDEpIGRlZHVwbGljYXRpb24gYW5kIDIpIGRlbHRhIHVwZGF0ZXM/IEFueXRo aW5nIGVsc2Ugb3IgaXMgdGhhdCBhbiBleGhhdXN0aXZlIGxpc3Q/CgogCnNvbWV0aGluZyBsaWtl IGV4dGVuc2lvbnMuIEZvciBhIGJhc2UgZG9jdW1lbnQsIHdlIGp1c3QgbmVlZCB0byBkZWZpbmUg aG93IHRvIHBlcmZvcm0gc3luYyBvcGVyYXRpb25zLgoKIAogClllcywgSSBhZ3JlZSB0aGF0IG1h eSBiZSBhbiBleHRlbnNpb24gb2YgdGhpcyBkcmFmdCBjb3VsZCBoYW5kbGUgdGhlIHN5bmNocm9u aXNhdGlvbiBwYXJ0LgoKIAogCiAKIApPdXIgSW50ZXJuZXQtRHJhZnQgaXMgaGVhdmlseSBmb2N1 c2VkIG9uIHRoZSB3b3JsZCB3aWRlIHdlYiwgd2hvc2UgVVJMcyBhcmUgbm90IGNvbnRlbnQtYWRk cmVzc2FibGUsIHdlIGNhbid0IGNoYW5nZSB0aGF0LiBTbyB0aGF0IGFyY2hpdGVjdHVyZSBpcyBu b3QgdmVyeSBmcmllbmRseSB0byBkZWR1cGxpY2F0aW9uLCBjb21wYXJlZCB0byBmb3IgaW5zdGFu Y2UgQml0VG9ycmVudC4gQXMgeW91IGFscmVhZHkgc2FpZCwgZGV2ZWxvcGVycyBjYW4gc3RpbGwg ZGVkdXBlIG9uIHRoZSBzZXJ2ZXItc2lkZSB3aGVuIHN0b3JpbmcgYmxvYnMgdG8gZGlzaywgYW5k IGNhbiBhbHNvIGRlZHVwZSBvbiB0aGUgY2xpZW50IHNpZGUgYmVmb3JlIGNyZWF0aW5nIHRoZSBy ZXNvdXJjZXMgdGhlIGNsaWVudCB1cGxvYWRzLgoKQXMgZmFyIGFzIEkga25vdywgZGVsdGEgdXBk YXRlcyBhcmUgbm90IHN1cHBvcnRlZCBieSB0aGUgRVRhZyBzeXN0ZW0gLSB5b3UgY2Fubm90IGRv IGEgcmFuZ2UgcmVxdWVzdCB0byBmaW5kIG91dCBpZiBjZXJ0YWluIGJ5dGVzIHdpdGhpbiBhIGRv Y3VtZW50IGhhdmUgY2hhbmdlZC4gSG93ZXZlciwgdGhlIGZvbGRlciBzeXN0ZW0gd2UgZGVmaW5l IGRvZXMgZW5jb3VyYWdlIHlvdSwgZm9yIGluc3RhbmNlIHdoZW4geW91IGRldmVsb3AgYSBUbyBE byBMaXN0IGFwcCwgcHV0IGVhY2ggdGFzayBvbiBpdHMgb3duIGRvY3VtZW50LCBhbmQgdGhlbiBx dWVyeSB0aGUgZm9sZGVyIHRvIHNlZSB3aGljaCBvZiB0aGVtIGNoYW5nZWQsIGluc3RlYWQgb2Yg cHV0dGluZyB0aGVtIGFsbCBpbiBvbmUgYmlnIGRvY3VtZW50IGFuZCByZXRyaWV2aW5nIHRoZSB3 aG9sZSBkb2N1bWVudCBlYWNoIHRpbWUuCgogCkNoZWVycywKCk1pY2hpZWwuCgogCiAKIAogCkJU VywgSSB3YW50IHRvIGludHJvZHVjZSBDbGF3SU8gKGh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvKSwg YSByZXNlYXJjaAoKcHJvamVjdCB0byBiZW5jaG1hcmsgZGlmZmVyZW50IHN5bmNocm9uaXNhdGlv biBwcm90b2NvbHMgYWdhaW5zdAoKZGlmZmVyZW50IGRhdGEgYmFja2VuZHMgd2l0aCBzcGVjaWFs IGF0dGVudGlvbiB0byBwcm92aWRlIGEgY29tbW9uIHN5bmMKCkFQSS4KCiAKQSBjb21tb24gQVBJ IGZvciBkaWZmZXJlbnQgc3luYyBwcm90b2NvbHMgaXMgYmVpbmcgY3JlYXRlZCBiYXNlZCBvbiB0 aGUKCmFyY2hpdGVjdHVyZSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdCAoY29udHJvbCBhbmQgZGF0 YSBzZXJ2ZXJzKSBhbmQgdGhlCgpJIGNhbm5vdCBmaW5kIGEgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0 dXJlIGluIHRoaXMgZHJhZnQuIEl0IHNlZW1zIHRoYXQgdGhleSBoYW5kbGUgbWV0YWRhdGEgYW5k IGNvbnRlbnQgZGF0YSB0b2dldGhlciwganVzdCBsaWtlIGEgbm9ybWFsIHdlYiBzZXJ2aWNlLgoK IApDbGF3SU8gaXMgZnVsbHkgZGlzdHJpYnV0ZWQuIEV2ZXJ5IGxvZ2ljYWwgdW5pdCBpcyBhIGRp ZmZlcmVudCBzZXJ2ZXIgdGhhbiBiZSBzY2FsZWQgb3V0LiBEYXRhIGFuZCBNZXRhZGF0YSBjaGFu bmVscyBhcmUgaW5kZXBlbmRlbnQgZnJvbSBlYWNoIG90aGVyIGFuZCByZXNpZGUgb24gZGlmZmVy ZW50IHNlcnZlcnMuCgpUaGF0IGlzIHdpZGVseSBlbXBsb3llZCBpbiBwb3B1bGFyIHN5bmMgc2Vy dmljZXMuIEFuZCB0aGF0IGlzIGFsc28gYmVuZWZpY2lhbCB0byBwcml2YWN5IHRvIHNvbWUgZXh0 ZW50LiBCdXQgaW4gdGhlIGNvbnRleHQgb2Ygc3luYyBpbiBicm93c2VyICh3aGljaCBpcyBtYWlu bHkgY29uc2lkZXJlZCBpbiB0aGUgcmVtb3RlU3RvcmFnZSksIEkgZG9uJ3Qga25vdyB3aGV0aGVy IHRoaXMgaXMgcmVhc29uYWJsZS4gQnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGRlcGxveSBkaXN0cmli dXRlZCBhcmNoaXRlY3R1cmUgYWx0aG91Z2ggaXQgd2lsbCBtYWtlIHRoaW5ncyBjb21wbGljYXRl ZC4KCiAKIApPZiBjb3Vyc2UsIHRoZSByZW1vdGVTdG9yYWdlIGlzIHRhcmdldGVkIHRvIGJyb3dz ZXJzLCBzbyBzeW5jaW5nIGRvZXMgbm90IG1ha2UgdG9vIG11Y2ggc2Vuc2UgaW4gdGhpcyBjYXNl LgoKV2l0aCB0aGUgcmlzZSBvZiBMaW51eCBjb250YWluZXIgbWljcm8tc2VydmljZSBiYXNlZCBh cmNoaXRlY3R1cmVzLCB0aGUgZGVwbG95bWVudCBvZiAgc3VjaCBoaWdobHkgY29tcGxleCBzeXN0 ZW1zIHNob3VsZCBiZWNvbWUgZWFzaWVyIGFuZCBmYXN0ZXIuCgogCkJlc3QsCgogCiAKSHVnbwoK IAogClJlZ2FyZHMsCgpMaW5odWkgCgogCiAKUmVnYXJkcywKCkxpbmh1aQoKb25lIGZyb20gdGhl IENFUk4gRU9TIHByb2plY3QgKG1hbmFnZW1lbnQsIGRpc2sgYW5kIHF1ZXVlIHNlcnZlcnMpLgoK IApUaGUgUGhhc2UgSSBoYXMgaW1wbGVtZW50ZWQgdGhlIG93bkNsb3VkIFN5bmMgUHJvdG9jb2wg YW5kIFBoYXNlIElJIHdpbGwKCmltcGxlbWVudCB0aGUgU2VhRmlsZSBTeW5jIFByb3RvY29sLgoK VGhlIGNob2ljZSBvZiB0aGVzZSBwcm90b2NvbHMgYW1vbmcgb3RoZXJzIGlzIGJlY2F1c2UgdGhl eSBhcmUgcmVhbGx5CgpvcHBvc2VkIHRvIGVhY2ggb3RoZXIgaW4gdGVybXMgb2Ygc3luY2luZyAo ZGVsdGEgdnMgbm9uLWRlbHRhLAoKc3RhdGUtYmFzZWQgdnMgbG9nL2V2ZW50L2dpdC1iYXNlZCBz eW5jIOKApiksIHNvIGZpbmRpbmcgYSBjb21tb24gYXBwcm9hY2gKCmlzIG1vcmUgY2hhbGxlbmdp bmcuCgogClByb3ZpZGluZyBhIGJhc2Ugc3BlY2lmaWNhdGlvbi9hcmNoaXRlY3R1cmUgdG8gbWVh c3VyZSB0aGUgZmVhc2liaWxpdHkKCm9mIHRoaXMgZHJhZnQgaXMgb25lIG9mIHRoZSBvYmplY3Rp dmVzIG9mIHRoZSBwcm9qZWN0LgoKIApJIGJlbGlldmUgdGhhdCB0aGUgd29yayBiZWluZyBkb25l IGhlcmUgYW5kIGluIENsYXdJTyBhcmUgc3VwcGxlbWVudGFyeQoKdG8gZWFjaCBvdGhlciBhbmQg SSB0aGluayBtdXR1YWwgY29sbGFib3JhdGlvbiBjb3VsZCBiZSBiZW5lZmljaWFsIGZvcgoKYm90 aCBzaWRlcy4KCiAKQWxzbywgaWYgdGhlcmUgaXMgaW50ZXJlc3QsIHRoZSByZW1vdGVTdG9yYWdl IEFQSSBjYW4gYmUgYWRkZWQgdG8KCkNsYXdJTy4KCiAKQmVzdCByZWdhcmRzLAoKIApIdWdvIEdv bnphbGV6IExhYnJhZG9yCgogCk9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0IDA5OjAwIFBNLCBzdG9y YWdlc3luYy1yZXF1ZXN0QGlldGYub3JnIHdyb3RlOgoKPiBTZW5kIFN0b3JhZ2VzeW5jIG1haWxp bmcgbGlzdCBzdWJtaXNzaW9ucyB0bwoKPiAgICAgICBzdG9yYWdlc3luY0BpZXRmLm9yZwoKPgoK PiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlz aXQKCj4gICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdl c3luYwoKPiBvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9k eSAnaGVscCcgdG8KCj4gICAgICAgc3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9yZwoKPgoKPiBZ b3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQKCj4gICAgICAgc3Rv cmFnZXN5bmMtb3duZXJAaWV0Zi5vcmcKCj4KCj4gV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQg eW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYwoKPiB0aGFuICJSZTogQ29u dGVudHMgb2YgU3RvcmFnZXN5bmMgZGlnZXN0Li4uIgoKPiBUb2RheSdzIFRvcGljczoKCj4KCj4g ICAgMS4gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgICAgSW50ZXJu ZXQtRHJhZnQKCj4gICAgICAgYXZhaWxhYmxlIChNaWNoaWVsIGRlIEpvbmcpCgo+ICAgIDIuIFJl OiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFm dAoKPiAgICAgICBhdmFpbGFibGUgKEdpaGFuIERpYXMpCgo+ICAgIDMuIFJlOiBOZXcgdmVyc2lv biBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdAoKPiAgICAgICBh dmFpbGFibGUgKEZlaSBTb25nKQoKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKPiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QKCj4gU3RvcmFnZXN5bmNA aWV0Zi5vcmcKCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdl c3luYwoKPiBFbWFpbCBoYWQgMyBhdHRhY2htZW50czoKCj4gKyBbU3RvcmFnZXN5bmNdIE5ldyB2 ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlCgo+IEludGVybmV0LURyYWZ0IGF2 YWlsYWJsZQoKPiAgIDJrIChtZXNzYWdlL3JmYzgyMikKCj4gKyBSZTogW1N0b3JhZ2VzeW5jXSBO ZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZQoKPiBJbnRlcm5ldC1EcmFm dCBhdmFpbGFibGUKCj4gICAxayAobWVzc2FnZS9yZmM4MjIpCgo+ICsgUmU6IFtTdG9yYWdlc3lu Y10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UKCj4gSW50ZXJuZXQt RHJhZnQgYXZhaWxhYmxlCgo+ICAgMmsgKG1lc3NhZ2UvcmZjODIyKQoKIApfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKU3RvcmFnZXN5bmMgbWFpbGluZyBs aXN0CgpTdG9yYWdlc3luY0BpZXRmLm9yZwoKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdG9yYWdlc3luYwoKIAogCiAKIAoKCgo= ------=_Part_40721_16669507.1449132037389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdp bmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BB TiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXpl OiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPkhpIE1pY2hhZWwsPG86 cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJ WkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxvOnA+PEZP TlQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+CjxQIHN0eWxl PSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjog d2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9 IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogNi4wcHQi IGxhbmc9IkVOLVVTIj48Rk9OVCBmYWNlPSJDYWxpYnJpIj5CYXNlZCBvbiB0aGUgZGVzY3JpcHRp b24gb24gPC9GT05UPjxBIGhyZWY9Imh0dHA6Ly9yZW1vdGVzdG9yYWdlLmlvLyIgdGFyZ2V0PSJf YmxhbmsiPjxVPjxGT05UIGNvbG9yPSIjMDAwMGZmIiBmYWNlPSJDYWxpYnJpIj5odHRwOi8vcmVt b3Rlc3RvcmFnZS5pby88L0ZPTlQ+PC9VPjwvQT48Rk9OVCBmYWNlPSJDYWxpYnJpIj4g4oCccmVt b3RlU3RvcmFnZS1lbmFibGVkIGFwcHMgYXV0b21hdGljYWxseSBzeW5jIHlvdXIgZGF0YSBhY3Jv c3MgYWxsIG9mIHlvdXIgZGV2aWNlc+KAnS4gPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4K PFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdp bmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BB TiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXpl OiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxvOnA+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9G T05UPjwvbzpwPjwvU1BBTj48L1A+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46 IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5 cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogNi4wcHQiIGxhbmc9IkVOLVVTIj48Rk9OVCBmYWNlPSJD YWxpYnJpIj5Ib3dldmVyLCB0aGVyZSBpcyBubyBzeW5jaHJvbml6YXRpb24gaW4gdGhlIGFic3Ry YWN0LiA8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7 IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+ PEZPTlQgZmFjZT0iQ2FsaWJyaSI+4oCcVGhlIHByb3RvY29sIHN1cHBvcnRzIHN0b3JpbmcsIHJl dHJpZXZpbmcsIGFuZCByZW1vdmluZyBpbmRpdmlkdWFsIGRvY3VtZW50cywgYXMgd2VsbCBhcyBs aXN0aW5nIHRoZSBjb250ZW50cyBvZiBhbiBpbmRpdmlkdWFsIGZvbGRlciwgYW5kIGFjY2VzcyBj b250cm9sIGlzIGJhc2VkIG9uIGJlYXJlciB0b2tlbnPigJ08bzpwPjwvbzpwPjwvRk9OVD48L1NQ QU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg bXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1m b250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+PG86cD48Rk9OVCBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05U LVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxGT05U IGZhY2U9IkNhbGlicmkiPlRoZXJlZm9yZSwgSSB0aGluazo8bzpwPjwvbzpwPjwvRk9OVD48L1NQ QU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg bXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1m b250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+SWYgc3lu Y2hyb25pemF0aW9uIGlzIGFkZGVkIGludG8gYWJzdHJhY3QsIHRoZSBNT1ZFIGFjdGlvbiBzaG91 bGQgYmUgYWRkZWQgZm9yIHN1cmUuPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4KPFAgc3R5 bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9u OiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHls ZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBw dCIgbGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPklmIHN5bmNocm9uaXphdGlvbiBp cyBub3QgaW5jbHVkZWQsIGxpa2UgY3VycmVudCB2ZXJzaW9uLCB0aGUgYmFzaWMgYWN0aW9ucyBp biBkcmFmdCBhcmUgZW5vdWdoLjwvRk9OVD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElH TjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhh biIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxh Y2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1V UyI+PC9TUEFOPjxCUj4mbmJzcDs8L1A+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDog I2I2YjZiNiAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBN QVJHSU4tUklHSFQ6IDBweCIgbmFtZT0icmVwbHlDb250ZW50Ij4tLS0tLeWOn+Wni+mCruS7ti0t LS0tPEJSPjxCPuWPkeS7tuS6ujo8L0I+ICJNaWNoaWVsIGRlIEpvbmciICZsdDttYmRlam9uZ0Bt b3ppbGxhLmNvbSZndDs8QlI+PEI+5Y+R6YCB5pe26Ze0OjwvQj4gMjAxNeW5tDEy5pyIMuaXpSDm mJ/mnJ/kuIk8QlI+PEI+5pS25Lu25Lq6OjwvQj4gIkxpbmh1aSBTdW4iICZsdDtsaC5zdW5saW5o QGdtYWlsLmNvbSZndDs8QlI+PEI+5oqE6YCBOjwvQj4gc3RvcmFnZXN5bmMgJmx0O3N0b3JhZ2Vz eW5jQGlldGYub3JnJmd0OywgZmtvb21hbiAmbHQ7Zmtvb21hbkB0dXhlZC5uZXQmZ3Q7LCAiSHVn byBHb256w6FsZXogTGFicmFkb3IiICZsdDtpZXRmQGh1Z28ubGFia29kZS5jb20mZ3Q7PEJSPjxC PuS4u+mimDo8L0I+IFJlOiBbU3RvcmFnZXN5bmNdIFN0b3JhZ2VzeW5jIERpZ2VzdCwgVm9sIDUs IElzc3VlIDE8QlI+PEJSPgo8RElWIGRpcj0ibHRyIj4KPERJVj4KPERJVj4KPERJVj4KPERJVj5D b29sISBJIGNyZWF0ZWQgPEEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3JlbW90ZXN0b3JhZ2Uv c3BlYy9pc3N1ZXMvMTM3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3JlbW90 ZXN0b3JhZ2Uvc3BlYy9pc3N1ZXMvMTM3PC9BPiBhYm91dCB0aGUgbmVlZCBmb3ImbmJzcDsgTU9W RSB2ZXJiLjxCUj48QlI+PC9ESVY+QXBwbGljYXRpb24tbGV2ZWwgY2h1bmtpbmcgaXMgcGFydGlh bGx5IHN1cHBvcnRlZCBieSBIVFRQIGl0c2VsZiB0aHJvdWdoIGBDb250ZW50LVJhbmdlYCBoZWFk ZXJzIChhbHRob3VnaCBpdCdzIG5vdCBjbGVhciB3aGV0aGVyIHRoZXNlIGFyZSBhbGxvd2VkIG9u IFBVVCByZXF1ZXN0cyBhcyB3ZWxsIGFzIG9uIEdFVCByZXF1ZXN0cywgc2VlIDxBIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzMSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzMTwv QT4pLiBUaGUgcHJvYmxlbSBpcyB0aGF0IEhUVFAgZGVmaW5lcyB2ZXJzaW9uaW5nIGF0IHRoZSBk b2N1bWVudCBsZXZlbCwgeW91IGNhbm5vdCBhc2sgYSBzZXJ2ZXIgdG8gcHJvZHVjZSBvciBjaGVj ayBhbiBFVGFnIGZvciBhIHNwZWNpZmljIGJ5dGUtcmFuZ2Ugb2YgYSBkb2N1bWVudCwgb25seSBm b3IgdGhlIGVudGlyZSBkb2N1bWVudC48QlI+PEJSPjwvRElWPkEgY29tcGFyaXNvbiBkb2N1bWVu dCBzb3VuZHMgZ29vZCEgU2VlIGFsc28gPEEgaHJlZj0iaHR0cDovL3d3dy5zZXJ2aWNlZGVudWFn ZXMuZnIvZW4vZ2VuZXJpYy1zdG9yYWdlLWVjb3N5c3RlbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly93d3cuc2VydmljZWRlbnVhZ2VzLmZyL2VuL2dlbmVyaWMtc3RvcmFnZS1lY29zeXN0ZW08L0E+ LjxCUj48QlI+PEJSPjwvRElWPkNoZWVycyw8QlI+PC9ESVY+TWljaGllbC48QlI+PEJSPjwvRElW Pgo8RElWIGNsYXNzPSJnbWFpbF9leHRyYSI+PEJSPgo8RElWIGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gV2VkLCBEZWMgMiwgMjAxNSBhdCAyOjMyIFBNLCBMaW5odWkgU3VuIDxTUEFOIGRpcj0ibHRy Ij4mbHQ7PEEgaHJlZj0ibWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bGguc3VubGluaEBnbWFpbC5jb208L0E+Jmd0OzwvU1BBTj4gd3JvdGU6PEJSPgo8QkxPQ0tR VU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHgg MHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4KPERJViBk aXI9Imx0ciI+VGhhdCdzIGNvb2wgZm9yIG1lLCBhIHNlcGFyYXRlIHNlY3Rpb24gZm9yIHRoaXMg bWlnaHQgbWFrZSBzZW5zZS4gCjxESVY+PEJSPjwvRElWPgo8RElWPkFub3RoZXIgdGhpbmcgaXMg ZG8gd2UgbmVlZCB0byBpbmNsdWRlIGFuIGFwcGxpY2F0aW9uLWxheWVyIGNodW5raW5nIGhlcmUg KG5vdCBqdXN0IGZvciBhIGJyb3dzZXIgc3luYyksIHNpbmNlIGlmIHdlIHdhbnQgdG8gZnVydGhl ciBleHRlbmQgb3RoZXIgY2FwYWJpbGl0aWVzIGl0IGlzIGVzc2VudGlhbC48QlI+CjxESVY+PEJS PjwvRElWPgo8RElWPlJlZ2FyZHMsPC9ESVY+CjxESVY+TGluaHVpPC9ESVY+PC9ESVY+PC9ESVY+ CjxESVYgY2xhc3M9IkhPRW5aYiI+CjxESVYgY2xhc3M9Img1Ij4KPERJViBjbGFzcz0iZ21haWxf ZXh0cmEiPjxCUj4KPERJViBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTUtMTItMDIgMjE6MDMgR01U KzA4OjAwIEh1Z28gR29uesOhbGV6IExhYnJhZG9yIDxTUEFOIGRpcj0ibHRyIj4mbHQ7PEEgaHJl Zj0ibWFpbHRvOmlldGZAaHVnby5sYWJrb2RlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAaHVn by5sYWJrb2RlLmNvbTwvQT4mZ3Q7PC9TUEFOPjo8QlI+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JE RVItTEVGVDogI2NjYyAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJ TkctTEVGVDogMWV4IiBjbGFzcz0iZ21haWxfcXVvdGUiPjxVPjwvVT4KPERJVj4KPERJVj5JIHBy b3Bvc2UgdG8gY29tZSB1cCB3aXRoIGEgbGlzdCBvZiBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRh Z2VzIG9mIHVzaW5nIFdlYkRBViBhbmQgY29tcGFyZSB0aGVtIGFnYWluc3QgYSBKU09OL1JFU1Qg YmFzZWQgYXBwcm9hY2gsIGxpa2UgcmVtb3RlU3RvcmFnZS48QlI+PC9ESVY+CjxESVY+Jm5ic3A7 PC9ESVY+CjxESVY+RG9lcyBpdCBzb3VuZCBnb29kID88L0RJVj4KPERJVj4KPERJVj4KPERJVj4m bmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5PbiBXZWQsIERlYyAyLCAyMDE1LCBh dCAwMTo1OSBQTSwgTGluaHVpIFN1biB3cm90ZTo8QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9 ImNpdGUiPgo8RElWIGRpcj0ibHRyIj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4KPERJVj4mbmJz cDs8L0RJVj4KPERJVj4KPERJVj4yMDE1LTEyLTAyIDIwOjQzIEdNVCswODowMCBIdWdvIEdvbnrD oWxleiBMYWJyYWRvciA8U1BBTiBkaXI9Imx0ciI+Jmx0OzxBIGhyZWY9Im1haWx0bzppZXRmQGh1 Z28ubGFia29kZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGh1Z28ubGFia29kZS5jb208L0E+ Jmd0OzwvU1BBTj46PEJSPjwvRElWPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJn YigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURE SU5HLUxFRlQ6IDFleCI+CjxESVY+PFU+PC9VPjxCUj48L0RJVj4KPERJVj4KPERJVj4mbmJzcDs8 L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJ Vj4KPERJVj48U1BBTj5PbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwMTozMCBQTSwgTWljaGllbCBk ZSBKb25nIHdyb3RlOjwvU1BBTj48QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8 RElWIGRpcj0ibHRyIj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4K PERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj48U1BBTj5IaSBhbGwhPC9TUEFOPjxC Uj48L0RJVj48L0RJVj4KPERJVj48U1BBTj5UaGFua3MgZm9yIGFsbCB5b3VyIHJlYWN0aW9ucyB0 byB0aGUgcmVtb3RlU3RvcmFnZSBJbnRlcm5ldC1EcmFmdC48L1NQQU4+PEJSPjwvRElWPgo8RElW PiZuYnNwOzwvRElWPjwvRElWPgo8RElWPjxTUEFOPldlIGdldCB0aGUgcXVlc3Rpb24gYWJvdXQg V2ViREFWIGEgbG90LCBpbiB0aGUgbmV4dCB2ZXJzaW9uIHdlIHNob3VsZCBhZGQgYSByZW1hcmsg YWJvdXQgaXQgaW4gdGhlIGludHJvLiBUaGUgZm9sZGVyIGRlc2NyaXB0aW9ucyByZXR1cm5lZCB3 aGVuIHlvdSBHRVQgYSBVUkwgdGhhdCBlbmRzIHdpdGggYSAvIGFyZSBpbmRlZWQgYSBkZXZpYXRp b24gZnJvbSB0aGUgWE1MIHJldHVybmVkIGJ5IFdlYkRBViBzZXJ2ZXIsIGFuZCB0aGlzIGlzIGp1 c3QgYmVjYXVzZSBub3dhZGF5cyBKU09OIGlzIGVhc2llciB0byB1c2UgdGhhbiBYTUwgZm9yIGRl dmVsb3BlcnMsIGJvdGggY2xpZW50LXNpZGUgYW5kIHNlcnZlci1zaWRlLjwvU1BBTj48QlI+PC9E SVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+ PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwv RElWPgo8RElWPkkgdG90YWxseSBhZ3JlZSBoZXJlLCB0aGlzIHdhcyBnb2luZyB0byBoYXBwZW4g c29vbiBvciBsYXRlciBhbmQgaXQgaXMgcmVhbGx5IGFwcHJlY2lhdGVkLjxCUj48L0RJVj4KPERJ Vj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+ CjxESVYgZGlyPSJsdHIiPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElW Pgo8RElWPgo8RElWPgo8RElWPjxTUEFOPlRoZSBmYWN0IHRoYXQgd2UgZG9uJ3QgcmVxdWlyZSBz ZXJ2ZXJzIHRvIHN1cHBvcnQgV2ViREFWJ3MgY3VzdG9tIHZlcmJzIGxpa2UgUFJPUFBBVENIIGV0 Yy4gaXMgZm9yIHRocmVlIHJlYXNvbnM6PC9TUEFOPjxCUj48L0RJVj48L0RJVj4KPERJVj48U1BB Tj4xKSBpdCdzIGEgbG90IG9mIHdvcmsgdG8gaW1wbGVtZW50IHRoaXMgd2l0aG91dCB1c2luZyBh biBleGlzdGluZyBXZWJEQVYgbGlicmFyeTwvU1BBTj48QlI+PC9ESVY+PC9ESVY+CjxESVY+PFNQ QU4+MikgaW4gcHJhY3RpY2UsIGEgbG90IG9mIFdlYkRBViBzZXJ2ZXJzIGdldCBpdCB3cm9uZywg b3IgZG9uJ3QgaW1wbGVtZW50IGFsbCBvZiBXZWJEQVYuIEl0J3MgdmVyeSBhbm5veWluZyBmb3Ig Y2xpZW50IGltcGxlbWVudGVycyB0byBoYXZlIHRvIGRlYWwgd2l0aCBzZXJ2ZXJzIHRoYXQgZS5n LiBjaG9zZSBub3QgdG8gaW1wbGVtZW50IExPQ0sgYW5kIFVOTE9DSy48L1NQQU4+PEJSPjwvRElW PjwvRElWPgo8RElWPjxTUEFOPjMpIHdlIGRvbid0IHJlYWxseSBuZWVkIGFsbCB0aGVzZSBhZHZh bmNlZCBmZWF0dXJlcyBvbiB0b3Agb2Ygc3RhbmRhcmQgSFRUUCwganVzdCBzdXBwb3J0aW5nIEdF VC9QVVQvREVMRVRFIGZvciByZXNvdXJjZXMsIGFuZCBhZGRpbmcgYSBzaW1wbGUgZm9sZGVyIGRl c2NyaXB0aW9uIGZvcm1hdCwgaXMgZW5vdWdoIGZvciBtb3N0IGFwcGxpY2F0aW9ucy48L1NQQU4+ PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPjwvRElWPgo8RElWPjxTUEFOPk90aGVyIHRoYW4g dGhhdCwgdGhlIHJlbW90ZVN0b3JhZ2UgSW50ZXJuZXQtRHJhZnQgc3BlY2lmaWVzIGEgKmxvdCog bW9yZSB0aGFuIGp1c3QgaG93IGVhY2ggSFRUUCB2ZXJiIHNob3VsZCBiZWhhdmU6PC9TUEFOPjxC Uj48L0RJVj48L0RJVj4KPERJVj48U1BBTj4qIHJlcXVpcmluZyBzdXBwb3J0IGZvciBPQXV0aCBp bXBsaWNpdC1ncmFudCBmbG93PC9TUEFOPjxCUj48L0RJVj48L0RJVj4KPERJVj48U1BBTj4qIHJl cXVpcmluZyBFVGFnIHN1cHBvcnQgYW5kIG5lc3RlZCB2ZXJzaW9uaW5nIChpLmUuIHRoZSBmb2xk ZXIncyBFVGFnIGNoYW5nZXMgaWYgYW55dGhpbmcgd2l0aGluIHRoYXQgZm9sZGVyIGNoYW5nZXMp PC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj4qIHJlcXVpcmluZyBDT1JTIGhlYWRlcnM8L1NQ QU4+PEJSPjwvRElWPjwvRElWPgo8RElWPjxTUEFOPiogcmVxdWlyaW5nIGEgV2ViRmluZ2VyIGFu bm91bmNlbWVudCBmb3Igc2VydmljZSBkaXNjb3Zlcnk8L1NQQU4+PEJSPjwvRElWPjwvRElWPgo8 RElWPjxTUEFOPkl0IHdvdWxkIGJlIGVhc3kgdG8gYWRkIHRoZXNlIHRocmVlIHRoaW5ncyBvbiB0 b3Agb2YgV2ViREFWLCBpbnN0ZWFkIG9mIHB1dHRpbmcgdGhlbSBvbiB0b3Agb2Ygb3VyIG1pbmlt YWwgR0VUL1BVVC9ERUxFVEUgQVBJIGRlZmluaXRpb24uIEluIGZhY3QsIHdlIGNvdWxkIHByb2Jh Ymx5IHNlcGFyYXRlIGl0IGludG8gdHdvIEludGVybmV0LURyYWZ0czogb25lIGZvciB0aGUgJ1JF U1RmdWwgZm9sZGVycycgQVBJIHdoaWNoIGlzIG91ciBzaW1wbGlmaWNhdGlvbiBvZiBXZWJEQVYs IGFuZCBhIHNlY29uZCBvbmUgZm9yIE9BdXRoL0VUYWdzL0NPUlMvV2ViRmluZ2VyIG9uIHRvcCBv ZiBlaXRoZXIgV2ViREFWIG9yICdSRVNUZnVsIGZvbGRlcnMnIG9yIHdoYXRldmVyIG90aGVyIEhU VFAtYmFzZWQgQVBJIHlvdSB3YW50LjwvU1BBTj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9D S1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlRoZXJlIGlz IG9uZSByZXF1aXJlbWVudCB0aGF0IGFsbCBzeW5jaHJvbmlzZXJzIG5lZWQgdG8gaGFuZGxlOiBt b3ZpbmcgcmVzb3VyY2VzLiBJbiB0aGlzIHNwZWMgdGhlIGFsdGVybmF0aXZlIG9mIGEgV2ViREFW IE1PVkUgaXMgbm90IHNwZWNpZmllZC4mbmJzcDs8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+ CjxESVY+SXQgaXMgdHJ1ZSB0aGF0IGEgTU9WRSBjb3VsZCBiZSByZXBsYWNlZCB3aXRoIGEgREVM RVRFICsgVVBMT0FEIGJ1dCB0aGF0IGlzIG5vdCBhY2NlcHRhYmxlIGluIG1vc3QgY2FzZXMgZHVl IHRvIHRoZSBpbmVmZmljaWVuY3kgb2Ygc3VjaCBvcGVyYXRpb24gKGNwdSwgYmFuZHdpZHRoIGNv bnN1bXB0aW9uIC4uLik8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SXMgdGhlcmUg YSBwbGFuIHRvIHN1cHBvcnQgc3VjaCBiYXNpYyBmZWF0dXJlPzxCUj48L0RJVj4KPERJVj4mbmJz cDs8L0RJVj4KPERJVj5Gcm9tIHRoZSBjdXJyZW50IHJlbW90ZVN0b3JhZ2Ugc3BlYywgdGhlIG93 bkNsb3VkIHN5bmMgcHJvdG9jb2wgY2FuIGJlIGltcGxlbWVudGVkLiBUaGUgbWlzc2luZyBiaXQg aXMgdHJhY2tpbmcgdGhvc2UgcmVtb3RlIG1vdmVzLjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVP VEU+CjxESVY+SSBhZ3JlZSB3aXRoIEh1Z28gdGhhdCBNT1ZFIGlzIHVzZWZ1bCwgc29tZXRpbWVz IGlmIHlvdSBqdXN0IHJlbmFtZSBhIGZpbGUgaXQgd2lsbCBiZSBwZXJmZWN0LiBCdXQgdGhlIHF1 ZXN0aW9uIEkgaGF2ZSBpcyB0aGF0IHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIHR3byBkb2N1bWVu dHM/IE11bHRpcGxlIGNob2ljZXMgaXMgbm90IGdvb2QgZm9yIHN0YW5kYXJkaXphdGlvbi4gSW4g bXkgdmlldywgd2ViZGF2IGlzIHNvbWV0aGluZyB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIHZlcnkg Y2xlYXIgZGVjaXNpb24gb24gd2hldGhlciB0byBjb25zaWRlciBpdCBvciBub3QuPEJSPjwvRElW Pgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlJlZ2FyZHMsPEJSPjwvRElWPgo8RElWPkxpbmh1aTxC Uj48L0RJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQp IDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgi Pgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkNoZWVyczxC Uj48L0RJVj4KPERJVj4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0i Y2l0ZSI+CjxESVYgZGlyPSJsdHIiPgo8RElWPgo8RElWPgo8RElWPk9uIFdlZCwgRGVjIDIsIDIw MTUgYXQgMTE6MjggQU0sIEh1Z28gR29uesOhbGV6IExhYnJhZG9yIDxTUEFOIGRpcj0ibHRyIj4m bHQ7PEEgaHJlZj0ibWFpbHRvOmlldGZAaHVnby5sYWJrb2RlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmlldGZAaHVnby5sYWJrb2RlLmNvbTwvQT4mZ3Q7PC9TUEFOPiB3cm90ZTo8QlI+PC9ESVY+CjxC TE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7 IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4Ij4KPERJVj48VT48 L1U+PEJSPjwvRElWPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8 RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPk9uIFdlZCwgRGVj IDIsIDIwMTUsIGF0IDExOjE4IEFNLCBMaW5odWkgU3VuIHdyb3RlOjwvU1BBTj48QlI+PC9ESVY+ CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8RElWPjxTUEFOPkhpPC9TUEFOPjxCUj48L0RJVj4K PERJVj4mbmJzcDs8L0RJVj4KPERJVj4KPERJViBzdHlsZT0iQ09MT1I6IHJnYigwLDAsMCkiPgo8 RElWPjxTUEFOPk9uIOWRqOS4iSwgMTLmnIggMiwgMjAxNSBhdCAxNzo1NiwgSHVnbyBHb256w6Fs ZXogTGFicmFkb3IgJmx0OzxBIGhyZWY9Im1haWx0bzppZXRmQGh1Z28ubGFia29kZS5jb20iIHRh cmdldD0iX2JsYW5rIj5pZXRmQGh1Z28ubGFia29kZS5jb208L0E+Jmd0OyB3cm90ZTo8L1NQQU4+ PEJSPjwvRElWPgo8RElWIHN0eWxlPSJPVkVSRkxPVy1YOiB2aXNpYmxlOyBPVkVSRkxPVy1ZOiB2 aXNpYmxlIj4KPEJMT0NLUVVPVEUgc3R5bGU9IkNPTE9SOiByZ2IoNDgsNTksNjQpIj4KPERJVj4K PERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJ Vj48U1BBTj5PbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwODoyMCBBTSwgTGluaHVpIFN1biB3cm90 ZTo8L1NQQU4+PEJSPjwvRElWPgo8QkxPQ0tRVU9URT4KPERJViBkaXI9Imx0ciI+CjxESVY+PFNQ QU4+SGk8L1NQQU4+PEJSPjwvRElWPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPgo8RElW PjxTUEFOPjIwMTUtMTItMDIgNToxNCBHTVQrMDg6MDAgSHVnbyBHb256w6FsZXogTGFicmFkb3Ig PFNQQU4gZGlyPSJsdHIiPiZsdDs8QSBocmVmPSJtYWlsdG86aWV0ZkBodWdvLmxhYmtvZGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBodWdvLmxhYmtvZGUuY29tPC9BPiZndDs8L1NQQU4+Ojwv U1BBTj48QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwy MDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVG VDogMWV4Ij4KPERJVj48U1BBTj5IaSw8L1NQQU4+PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElW Pgo8RElWPjxTUEFOPmZyb20gbXkgcG9pbnQgb2YgdmlldyB0aGUgcmVtb3RlU3RvcmFnZSBwcm9q ZWN0IGFkZHJlc3NlcyBhIHN1YnNldCBvZjwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+dGhl IHVzZSBjYXNlcyBvZiB0aGUmbmJzcDsgV2ViREFWIHNwZWNpZmljYXRpb24uPC9TUEFOPjxCUj48 L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5UaGUgbWFpbiBkaWZmZXJlbmNlIEkg Y2FuIG9ic2VydmUgaXMgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBpcyBidWlsdCBvbjwvU1BBTj48 QlI+PC9ESVY+CjxESVY+PFNQQU4+UkVTVCBpbnN0ZWFkIG9mIFhNTC1iYXNlZCBjb21tdW5pY2F0 aW9uLjwvU1BBTj48QlI+PC9ESVY+PC9CTE9DS1FVT1RFPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9S REVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4 IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCI+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+ SSBwZXJzb25hbGx5IGxpa2UgbXVjaCBtb3JlIFJFU1QgdGhhbiBXZWJEQVYgYmVjYXVzZSBpdCBp cyBtb3JlPC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj5kZXZlbG9wZXIgZnJpZW5kbHkgYW5k IGl0IGlzIGZhc3RlciB0byBkZXZlbG9wLjwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+Jm5i c3A7TWF5YmUgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGJlY29tZXMgdGhlIG5leHQgV2ViREFWIDop PC9TUEFOPjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5Ib3dldmVyLCB0 aGUgcmVtb3RlU3RvcmFnZSBBUEkgZG9lcyBub3QgcHJvdmlkZSBhIHdheSBvZiBzeW5jaHJvbmlz aW5nPC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj5kYXRhLCB0aGlzIHRhc2sgaXMgZGVsZWdh dGVkIHRvIHRoZSBkZXZlbG9wZXJzLjwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+SXMgdGhl cmUgYSBwbGFuIHRvIHByb3ZpZGUgc3VjaCBmZWF0dXJlIGJhc2VkIG9uIHRoZSBvdXRjb21lIG9m IHRoaXM8L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPmRyYWZ0PzwvU1BBTj48QlI+PC9ESVY+ PC9CTE9DS1FVT1RFPgo8RElWPjxTUEFOPkknbSBhIGxpdHRsZSBiaXQgY29uZnVzZWQgd2h5IHlv dSBzYXkgdGhlIHJlbW90ZVN0b3JhZ2UgZG9lcyBub3QgcHJvdmlkZSB0aGF0LiBJcyB0aGF0IGJl Y2F1c2UgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBwZXJmb3JtIGxpa2UgYSB0eXBpY2FsIHN5bmMg c2VydmljZXMgKGUuZy4gZHJvcGJveC4uLikgb3IgeW91IGFyZSBzYXlpbmcgc29tZXRoaW5nIGVs c2U/PC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+ PFNQQU4+WWVzLCBiZWNhdXNlIGl0IGRvZXMgbm90IG9mZmVyIHN5bmNocm9uaXNhdGlvbiBjYXBh YmlsaXRpZXMuPC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+PFNQQU4+ R290IGl0LiBBbmQgV2hhdCBJIGFtIHdvbmRlcmluZyBpcyB0aGF0IGRvIHdlIG5lZWQgdG8gaW5j bHVkZSB0aG9zZSBjYXBhYmlsaXRpZXMgaW4gYSBiYXNlIHNwZWNpZmljYXRpb25zLiBTaW5jZSBp dCBpcyBoYXJkIHRvIHN0YW5kYXJkaXplIHRoZSBjYXBhYmlsaXRpZXMgbGlrZSBkZWR1cCBvciBk ZWx0YS4gTWF5YmUgYSBiZXR0ZXIgd2F5IGlzIHRvIGRlZmluZSB0aG9zZSBpbiBhIHNlcGFyYXRl IHNwZWNpZmljYXRpb24sIDwvU1BBTj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9D S1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj4KPERJVj4m bmJzcDs8L0RJVj4KPERJVj5UaGFua3MgZm9yIGdpdmluZyB0aGVzZSBleGFtcGxlcyAtIHNvIGJ5 ICdzeW5jaHJvbmlzYXRpb24gY2FwYWJpbGl0aWVzJyB5b3UgbWVhbiAxKSBkZWR1cGxpY2F0aW9u IGFuZCAyKSBkZWx0YSB1cGRhdGVzPyBBbnl0aGluZyBlbHNlIG9yIGlzIHRoYXQgYW4gZXhoYXVz dGl2ZSBsaXN0PyA8QlI+PC9ESVY+PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVG VDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7 IFBBRERJTkctTEVGVDogMWV4Ij4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUg dHlwZT0iY2l0ZSI+CjxESVY+CjxESVYgc3R5bGU9IkNPTE9SOiByZ2IoMCwwLDApIj4KPERJViBz dHlsZT0iT1ZFUkZMT1ctWDogdmlzaWJsZTsgT1ZFUkZMT1ctWTogdmlzaWJsZSI+CjxESVY+PFNQ QU4+c29tZXRoaW5nIGxpa2UgZXh0ZW5zaW9ucy4gRm9yIGEgYmFzZSBkb2N1bWVudCwgd2UganVz dCBuZWVkIHRvIGRlZmluZSBob3cgdG8gcGVyZm9ybSBzeW5jIG9wZXJhdGlvbnMuPC9TUEFOPjxC Uj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+ CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+WWVzLCBJIGFncmVlIHRoYXQgbWF5IGJlIGFuIGV4dGVu c2lvbiBvZiB0aGlzIGRyYWZ0IGNvdWxkIGhhbmRsZSB0aGUgc3luY2hyb25pc2F0aW9uIHBhcnQu IDxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJz cDs8L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+CjxESVY+ T3VyIEludGVybmV0LURyYWZ0IGlzIGhlYXZpbHkgZm9jdXNlZCBvbiB0aGUgd29ybGQgd2lkZSB3 ZWIsIHdob3NlIFVSTHMgYXJlIG5vdCBjb250ZW50LWFkZHJlc3NhYmxlLCB3ZSBjYW4ndCBjaGFu Z2UgdGhhdC4gU28gdGhhdCBhcmNoaXRlY3R1cmUgaXMgbm90IHZlcnkgZnJpZW5kbHkgdG8gZGVk dXBsaWNhdGlvbiwgY29tcGFyZWQgdG8gZm9yIGluc3RhbmNlIEJpdFRvcnJlbnQuIEFzIHlvdSBh bHJlYWR5IHNhaWQsIGRldmVsb3BlcnMgY2FuIHN0aWxsIGRlZHVwZSBvbiB0aGUgc2VydmVyLXNp ZGUgd2hlbiBzdG9yaW5nIGJsb2JzIHRvIGRpc2ssIGFuZCBjYW4gYWxzbyBkZWR1cGUgb24gdGhl IGNsaWVudCBzaWRlIGJlZm9yZSBjcmVhdGluZyB0aGUgcmVzb3VyY2VzIHRoZSBjbGllbnQgdXBs b2Fkcy48QlI+PC9ESVY+PC9ESVY+CjxESVY+CjxESVY+QXMgZmFyIGFzIEkga25vdywgZGVsdGEg dXBkYXRlcyBhcmUgbm90IHN1cHBvcnRlZCBieSB0aGUgRVRhZyBzeXN0ZW0gLSB5b3UgY2Fubm90 IGRvIGEgcmFuZ2UgcmVxdWVzdCB0byBmaW5kIG91dCBpZiBjZXJ0YWluIGJ5dGVzIHdpdGhpbiBh IGRvY3VtZW50IGhhdmUgY2hhbmdlZC4gSG93ZXZlciwgdGhlIGZvbGRlciBzeXN0ZW0gd2UgZGVm aW5lIGRvZXMgZW5jb3VyYWdlIHlvdSwgZm9yIGluc3RhbmNlIHdoZW4geW91IGRldmVsb3AgYSBU byBEbyBMaXN0IGFwcCwgcHV0IGVhY2ggdGFzayBvbiBpdHMgb3duIGRvY3VtZW50LCBhbmQgdGhl biBxdWVyeSB0aGUgZm9sZGVyIHRvIHNlZSB3aGljaCBvZiB0aGVtIGNoYW5nZWQsIGluc3RlYWQg b2YgcHV0dGluZyB0aGVtIGFsbCBpbiBvbmUgYmlnIGRvY3VtZW50IGFuZCByZXRyaWV2aW5nIHRo ZSB3aG9sZSBkb2N1bWVudCBlYWNoIHRpbWUuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPjwv RElWPgo8RElWPkNoZWVycyw8QlI+PC9ESVY+CjxESVY+TWljaGllbC48QlI+PC9ESVY+CjxESVY+ Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQs MjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDog MWV4Ij4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+CjxE SVY+CjxESVYgc3R5bGU9IkNPTE9SOiByZ2IoMCwwLDApIj4KPERJViBzdHlsZT0iT1ZFUkZMT1ct WDogdmlzaWJsZTsgT1ZFUkZMT1ctWTogdmlzaWJsZSI+CjxCTE9DS1FVT1RFIHN0eWxlPSJDT0xP UjogcmdiKDQ4LDU5LDY0KSI+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFPgo8 RElWIGRpcj0ibHRyIj4KPERJVj4KPERJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZU OiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsg UEFERElORy1MRUZUOiAxZXgiPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPkJUVywgSSB3 YW50IHRvIGludHJvZHVjZSBDbGF3SU8gKDxBIGhyZWY9Imh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlv LyIgdGFyZ2V0PSJfYmxhbmsiPjwvQT48QSBocmVmPSJodHRwOi8vY2xhd2lvLmdpdGh1Yi5pby8i IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vY2xhd2lvLmdpdGh1Yi5pbzwvQT4pLCBhIHJlc2VhcmNo PC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj5wcm9qZWN0IHRvIGJlbmNobWFyayBkaWZmZXJl bnQgc3luY2hyb25pc2F0aW9uIHByb3RvY29scyBhZ2FpbnN0PC9TUEFOPjxCUj48L0RJVj4KPERJ Vj48U1BBTj5kaWZmZXJlbnQgZGF0YSBiYWNrZW5kcyB3aXRoIHNwZWNpYWwgYXR0ZW50aW9uIHRv IHByb3ZpZGUgYSBjb21tb24gc3luYzwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+QVBJLjwv U1BBTj48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+QSBjb21tb24gQVBJ IGZvciBkaWZmZXJlbnQgc3luYyBwcm90b2NvbHMgaXMgYmVpbmcgY3JlYXRlZCBiYXNlZCBvbiB0 aGU8L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPmFyY2hpdGVjdHVyZSBzcGVjaWZpZWQgaW4g dGhpcyBkcmFmdCAoY29udHJvbCBhbmQgZGF0YSBzZXJ2ZXJzKSBhbmQgdGhlPC9TUEFOPjxCUj48 L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+PFNQQU4+SSBjYW5ub3QgZmluZCBhIGRpc3RyaWJ1dGVk IGFyY2hpdGVjdHVyZSBpbiB0aGlzIGRyYWZ0LiBJdCBzZWVtcyB0aGF0IHRoZXkgaGFuZGxlIG1l dGFkYXRhIGFuZCBjb250ZW50IGRhdGEgdG9nZXRoZXIsIGp1c3QgbGlrZSBhIG5vcm1hbCB3ZWIg c2VydmljZS48L1NQQU4+PEJSPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4K PERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5DbGF3SU8gaXMgZnVsbHkgZGlzdHJpYnV0ZWQu IEV2ZXJ5IGxvZ2ljYWwgdW5pdCBpcyBhIGRpZmZlcmVudCBzZXJ2ZXIgdGhhbiBiZSBzY2FsZWQg b3V0LiBEYXRhIGFuZCBNZXRhZGF0YSBjaGFubmVscyBhcmUgaW5kZXBlbmRlbnQgZnJvbSBlYWNo IG90aGVyIGFuZCByZXNpZGUgb24gZGlmZmVyZW50IHNlcnZlcnMuPC9TUEFOPjxCUj48L0RJVj48 L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+PFNQQU4+VGhhdCBpcyB3aWRlbHkgZW1wbG95ZWQgaW4g cG9wdWxhciBzeW5jIHNlcnZpY2VzLiBBbmQgdGhhdCBpcyBhbHNvIGJlbmVmaWNpYWwgdG8gcHJp dmFjeSB0byBzb21lIGV4dGVudC4gQnV0IGluIHRoZSBjb250ZXh0IG9mIHN5bmMgaW4gYnJvd3Nl ciAod2hpY2ggaXMgbWFpbmx5IGNvbnNpZGVyZWQgaW4gdGhlIHJlbW90ZVN0b3JhZ2UpLCBJIGRv bid0IGtub3cgd2hldGhlciB0aGlzIGlzIHJlYXNvbmFibGUuIEJ1dCBJIHRoaW5rIHdlIHNob3Vs ZCBkZXBsb3kgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0dXJlIGFsdGhvdWdoIGl0IHdpbGwgbWFrZSB0 aGluZ3MgY29tcGxpY2F0ZWQuPC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JM T0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+T2YgY291 cnNlLCB0aGUgcmVtb3RlU3RvcmFnZSBpcyB0YXJnZXRlZCB0byBicm93c2Vycywgc28gc3luY2lu ZyBkb2VzIG5vdCBtYWtlIHRvbyBtdWNoIHNlbnNlIGluIHRoaXMgY2FzZS48QlI+PC9ESVY+CjxE SVY+V2l0aCB0aGUgcmlzZSBvZiBMaW51eCBjb250YWluZXIgbWljcm8tc2VydmljZSBiYXNlZCBh cmNoaXRlY3R1cmVzLCB0aGUgZGVwbG95bWVudCBvZiAmbmJzcDtzdWNoIGhpZ2hseSBjb21wbGV4 IHN5c3RlbXMgc2hvdWxkIGJlY29tZSBlYXNpZXIgYW5kIGZhc3Rlci48QlI+PC9ESVY+CjxESVY+ Jm5ic3A7PC9ESVY+CjxESVY+QmVzdCw8U1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6IHJnYigxMzYs MTM2LDEzNikiPjwvU1BBTj48L1NQQU4+PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW PiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPjxTUEFOIHN0eWxlPSJDT0xPUjogcmdiKDEzNiwxMzYs MTM2KSI+SHVnbzwvU1BBTj48L1NQQU4+PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW Pgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4KPERJVj4K PERJViBzdHlsZT0iQ09MT1I6IHJnYigwLDAsMCkiPgo8RElWIHN0eWxlPSJPVkVSRkxPVy1YOiB2 aXNpYmxlOyBPVkVSRkxPVy1ZOiB2aXNpYmxlIj4KPERJVj5SZWdhcmRzLDxCUj48L0RJVj4KPERJ Vj5MaW5odWkmbmJzcDs8QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJDT0xPUjogcmdiKDQ4 LDU5LDY0KSI+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxCTE9D S1FVT1RFPgo8RElWIGRpcj0ibHRyIj4KPERJVj4KPERJVj4KPERJVj5SZWdhcmRzLDxCUj48L0RJ Vj4KPERJVj5MaW5odWk8QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDog cmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBB RERJTkctTEVGVDogMWV4Ij4KPERJVj5vbmUgZnJvbSB0aGUgQ0VSTiBFT1MgcHJvamVjdCAobWFu YWdlbWVudCwgZGlzayBhbmQgcXVldWUgc2VydmVycykuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwv RElWPgo8RElWPlRoZSBQaGFzZSBJIGhhcyBpbXBsZW1lbnRlZCB0aGUgb3duQ2xvdWQgU3luYyBQ cm90b2NvbCBhbmQgUGhhc2UgSUkgd2lsbDxCUj48L0RJVj4KPERJVj5pbXBsZW1lbnQgdGhlIFNl YUZpbGUgU3luYyBQcm90b2NvbC48QlI+PC9ESVY+CjxESVY+VGhlIGNob2ljZSBvZiB0aGVzZSBw cm90b2NvbHMgYW1vbmcgb3RoZXJzIGlzIGJlY2F1c2UgdGhleSBhcmUgcmVhbGx5PEJSPjwvRElW Pgo8RElWPm9wcG9zZWQgdG8gZWFjaCBvdGhlciBpbiB0ZXJtcyBvZiBzeW5jaW5nIChkZWx0YSB2 cyBub24tZGVsdGEsPEJSPjwvRElWPgo8RElWPnN0YXRlLWJhc2VkIHZzIGxvZy9ldmVudC9naXQt YmFzZWQgc3luYyDigKYpLCBzbyBmaW5kaW5nIGEgY29tbW9uIGFwcHJvYWNoPEJSPjwvRElWPgo8 RElWPmlzIG1vcmUgY2hhbGxlbmdpbmcuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW PlByb3ZpZGluZyBhIGJhc2Ugc3BlY2lmaWNhdGlvbi9hcmNoaXRlY3R1cmUgdG8gbWVhc3VyZSB0 aGUgZmVhc2liaWxpdHk8QlI+PC9ESVY+CjxESVY+b2YgdGhpcyBkcmFmdCBpcyBvbmUgb2YgdGhl IG9iamVjdGl2ZXMgb2YgdGhlIHByb2plY3QuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8 RElWPkkgYmVsaWV2ZSB0aGF0IHRoZSB3b3JrIGJlaW5nIGRvbmUgaGVyZSBhbmQgaW4gQ2xhd0lP IGFyZSBzdXBwbGVtZW50YXJ5PEJSPjwvRElWPgo8RElWPnRvIGVhY2ggb3RoZXIgYW5kIEkgdGhp bmsgbXV0dWFsIGNvbGxhYm9yYXRpb24gY291bGQgYmUgYmVuZWZpY2lhbCBmb3I8QlI+PC9ESVY+ CjxESVY+Ym90aCBzaWRlcy48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+QWxzbywg aWYgdGhlcmUgaXMgaW50ZXJlc3QsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBjYW4gYmUgYWRkZWQg dG88QlI+PC9ESVY+CjxESVY+Q2xhd0lPLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJ Vj5CZXN0IHJlZ2FyZHMsPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkh1Z28gR29u emFsZXogTGFicmFkb3I8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+T24gVHVlLCBE ZWMgMSwgMjAxNSwgYXQgMDk6MDAgUE0sIDxBIGhyZWY9Im1haWx0bzpzdG9yYWdlc3luYy1yZXF1 ZXN0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9y ZzwvQT4gd3JvdGU6PEJSPjwvRElWPgo8RElWPiZndDsgU2VuZCBTdG9yYWdlc3luYyBtYWlsaW5n IGxpc3Qgc3VibWlzc2lvbnMgdG88QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxBIGhyZWY9Im1haWx0bzpzdG9yYWdlc3luY0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnN0b3JhZ2VzeW5jQGlldGYub3JnPC9BPjxCUj48L0RJVj4KPERJVj4mZ3Q7PEJSPjwv RElWPgo8RElWPiZndDsgVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQg V2lkZSBXZWIsIHZpc2l0PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3Jh Z2VzeW5jIiB0YXJnZXQ9Il9ibGFuayI+PC9BPjxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jPC9BPjxCUj48L0RJVj4KPERJ Vj4mZ3Q7IG9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5 ICdoZWxwJyB0bzxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PEEgaHJlZj0ibWFpbHRvOnN0b3JhZ2VzeW5jLXJlcXVlc3RAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnPC9BPjxCUj48L0RJVj4KPERJVj4mZ3Q7 PEJSPjwvRElWPgo8RElWPiZndDsgWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRo ZSBsaXN0IGF0PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 QSBocmVmPSJtYWlsdG86c3RvcmFnZXN5bmMtb3duZXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zdG9yYWdlc3luYy1vd25lckBpZXRmLm9yZzwvQT48QlI+PC9ESVY+CjxESVY+Jmd0OzxCUj48 L0RJVj4KPERJVj4mZ3Q7IFdoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBs aW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWM8QlI+PC9ESVY+CjxESVY+Jmd0OyB0aGFuICJSZTog Q29udGVudHMgb2YgU3RvcmFnZXN5bmMgZGlnZXN0Li4uIjxCUj48L0RJVj4KPERJVj4mZ3Q7IFRv ZGF5J3MgVG9waWNzOjxCUj48L0RJVj4KPERJVj4mZ3Q7PEJSPjwvRElWPgo8RElWPiZndDsmbmJz cDsgJm5ic3A7IDEuIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlJm5i c3A7ICZuYnNwOyBJbnRlcm5ldC1EcmFmdDxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7YXZhaWxhYmxlIChNaWNoaWVsIGRlIEpvbmcpPEJSPjwvRElWPgo8RElW PiZndDsmbmJzcDsgJm5ic3A7IDIuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVt b3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdDxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7YXZhaWxhYmxlIChHaWhhbiBEaWFzKTxCUj48L0RJVj4KPERJVj4mZ3Q7 Jm5ic3A7ICZuYnNwOyAzLiBSZTogTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0 b3JhZ2UgSW50ZXJuZXQtRHJhZnQ8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2F2YWlsYWJsZSAoRmVpIFNvbmcpPEJSPjwvRElWPgo8RElWPiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+PC9ESVY+CjxESVY+ Jmd0OyBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3Q8QlI+PC9ESVY+CjxESVY+Jmd0OyA8QSBocmVm PSJtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5TdG9yYWdlc3lu Y0BpZXRmLm9yZzwvQT48QlI+PC9ESVY+CjxESVY+Jmd0OyA8QSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jIiB0YXJnZXQ9Il9ibGFuayI+PC9B PjxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5 bmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0b3JhZ2VzeW5jPC9BPjxCUj48L0RJVj4KPERJVj4mZ3Q7IEVtYWlsIGhhZCAzIGF0dGFjaG1l bnRzOjxCUj48L0RJVj4KPERJVj4mZ3Q7ICsgW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBk cmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZTxCUj48L0RJVj4KPERJVj4mZ3Q7IEludGVybmV0LURy YWZ0IGF2YWlsYWJsZTxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOzJrIChtZXNzYWdl L3JmYzgyMik8QlI+PC9ESVY+CjxESVY+Jmd0OyArIFJlOiBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJz aW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlPEJSPjwvRElWPgo8RElWPiZndDsgSW50 ZXJuZXQtRHJhZnQgYXZhaWxhYmxlPEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7MWsg KG1lc3NhZ2UvcmZjODIyKTxCUj48L0RJVj4KPERJVj4mZ3Q7ICsgUmU6IFtTdG9yYWdlc3luY10g TmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2U8QlI+PC9ESVY+CjxESVY+ Jmd0OyBJbnRlcm5ldC1EcmFmdCBhdmFpbGFibGU8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAm bmJzcDsyayAobWVzc2FnZS9yZmM4MjIpPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPjwvRElW Pgo8RElWPlN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdDxCUj48L0RJVj4KPERJVj48QSBocmVmPSJt YWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5TdG9yYWdlc3luY0Bp ZXRmLm9yZzwvQT48QlI+PC9ESVY+CjxESVY+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIgdGFyZ2V0PSJfYmxhbmsiPjwvQT48QSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdl c3luYzwvQT48QlI+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tR VU9URT4KPERJVj4mbmJzcDs8L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9ESVY+PC9E SVY+PC9CTE9DS1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxP Q0tRVU9URT48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+ PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tR VU9URT4KPERJVj4mbmJzcDs8L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9E SVY+PEJSPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9ESVY+PC9C TE9DS1FVT1RFPg== ------=_Part_40721_16669507.1449132037389-- From nobody Thu Dec 3 00:42:01 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1467C1A802D for ; Thu, 3 Dec 2015 00:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRwoXq-upSUF for ; Thu, 3 Dec 2015 00:41:55 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3606F1A70FD for ; Thu, 3 Dec 2015 00:41:54 -0800 (PST) Received: by ajax-webmail-Jdweb2 (Coremail) ; Thu, 3 Dec 2015 16:44:08 +0800 (GMT+08:00) Date: Thu, 3 Dec 2015 16:44:08 +0800 (GMT+08:00) From: fsong@bjtu.edu.cn To: "Michiel de Jong" Message-ID: <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41404_1089348070.1449132248276" X-Originating-IP: [106.2.233.19] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20150107(58648.7033.6860) Copyright (c) 2002-2015 www.mailtech.cn bjtu X-SendMailWithSms: false X-CM-TRANSID: M55wygAnttDYAGBWWQAAAA--.1W X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/1tbiAQIMB1R9XjYYmwACsI X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: Linhui Sun , storagesync , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 08:41:59 -0000 ------=_Part_41404_1089348070.1449132248276 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgTWljaGllbCBhbmQgTGluaHVpLAoKSSB0aGluayBpdCB3aWxsIGJlIGdvb2QgdG8gaGF2ZSBh IGJvdW5kYXJ5IGZvciB0aGlzIGRyYWZ0IGFuZCBsZWF2ZSBzb21lIHdvcmsgZm9yIHRoZSBhcHBs aWNhaXRvbiBsYXllcn4KCgoKLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQrlj5Hku7bkuro6ICJNaWNo aWVsIGRlIEpvbmciIDxtYmRlam9uZ0Btb3ppbGxhLmNvbT4K5Y+R6YCB5pe26Ze0OiAyMDE15bm0 MTLmnIgy5pelIOaYn+acn+S4iQrmlLbku7bkuro6ICJMaW5odWkgU3VuIiA8bGguc3VubGluaEBn bWFpbC5jb20+CuaKhOmAgTogc3RvcmFnZXN5bmMgPHN0b3JhZ2VzeW5jQGlldGYub3JnPiwgZmtv b21hbiA8Zmtvb21hbkB0dXhlZC5uZXQ+LCAiSHVnbyBHb256w6FsZXogTGFicmFkb3IiIDxpZXRm QGh1Z28ubGFia29kZS5jb20+CuS4u+mimDogUmU6IFtTdG9yYWdlc3luY10gU3RvcmFnZXN5bmMg RGlnZXN0LCBWb2wgNSwgSXNzdWUgMQoKCkFoIHN1cmUsIHRoYXQncyBlbnRpcmVseSBhcHByb3By aWF0ZSwgcmVtb3RlU3RvcmFnZSB0cmVhdHMgYm90aCB0aGUgQ29udGVudC1UeXBlIGhlYWRlciB2 YWx1ZSBhbmQgdGhlIGFjdHVhbCBib2R5IG9mIGEgZG9jdW1lbnQgYXMgb3BhcXVlIHN0cmluZ3Mg b2YgYnl0ZXMuIEl0IGRvZXNuJ3QgImNhcmUiIGlmIHlvdSB1c2UgaXQgdG8gc3RvcmUgb25seSBk YXRhIGJsb2NrcyB0aGF0IGFyZSBjaHVua3Mgb2Ygc29tZXRoaW5nIGVsc2UuCgoKRm9yIGluc3Rh bmNlLCB5b3UgY291bGQgaGF2ZSBhIGZvbGRlciBvbiBhIHVzZXIncyBzdG9yYWdlIHRoYXQgY29u dGFpbnMgb25seSBpbm9kZS1saWtlIEpTT04tZG9jdW1lbnRzLCB3aGljaCBsaXN0IHRoZSBVUkxz IG9mIGJpbmFyeSBkb2N1bWVudHMgdGhhdCBtYWtlIHVwIDFLYiBibG9ja3Mgb2YgdGhlIGFjdHVh bCBkYXRhLiBOaWNlIGZvciBkZWR1cGluZywgZGVsdGEgdXBkYXRlcywgYW5kIGFsc28gcmVuYW1p bmcgZmlsZXMgd2l0aG91dCByZXVwbG9hZGluZyB0aGVpciBjb250ZW50LgoKCgpCdXQgeWVhaCwg dGhlIGFyZ3VtZW50IGlzIHRoYXQgKmhvdyogdG8gY3JlYXRlIGFuZCBtYW5hZ2UgdGhlc2UgY2h1 bmtzLCBpcyB0aGVuIHN0aWxsIGxlZnQgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlciAo b3IgdG8gYW5vdGhlciBzcGVjIG9uIHRvcCBvZiB0aGUgcmVtb3RlU3RvcmFnZSBzcGVjKS4KCgoK Q2hlZXJzLAoKTWljaGllbC4KCgoKT24gV2VkLCBEZWMgMiwgMjAxNSBhdCAzOjI5IFBNLCBMaW5o dWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4gd3JvdGU6CgpIaQoKCjIwMTUtMTItMDIgMjI6 MDUgR01UKzA4OjAwIE1pY2hpZWwgZGUgSm9uZyA8bWJkZWpvbmdAbW96aWxsYS5jb20+OgoKQ29v bCEgSSBjcmVhdGVkIGh0dHBzOi8vZ2l0aHViLmNvbS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVz LzEzNyBhYm91dCB0aGUgbmVlZCBmb3IgIE1PVkUgdmVyYi4KCgpBcHBsaWNhdGlvbi1sZXZlbCBj aHVua2luZyBpcyBwYXJ0aWFsbHkgc3VwcG9ydGVkIGJ5IEhUVFAgaXRzZWxmIHRocm91Z2ggYENv bnRlbnQtUmFuZ2VgIGhlYWRlcnMgKGFsdGhvdWdoIGl0J3Mgbm90IGNsZWFyIHdoZXRoZXIgdGhl c2UgYXJlIGFsbG93ZWQgb24gUFVUIHJlcXVlc3RzIGFzIHdlbGwgYXMgb24gR0VUIHJlcXVlc3Rz LCBzZWUgaHR0cHM6Ly9naXRodWIuY29tL3JlbW90ZXN0b3JhZ2Uvc3BlYy9pc3N1ZXMvMTMxKS4g VGhlIHByb2JsZW0gaXMgdGhhdCBIVFRQIGRlZmluZXMgdmVyc2lvbmluZyBhdCB0aGUgZG9jdW1l bnQgbGV2ZWwsIHlvdSBjYW5ub3QgYXNrIGEgc2VydmVyIHRvIHByb2R1Y2Ugb3IgY2hlY2sgYW4g RVRhZyBmb3IgYSBzcGVjaWZpYyBieXRlLXJhbmdlIG9mIGEgZG9jdW1lbnQsIG9ubHkgZm9yIHRo ZSBlbnRpcmUgZG9jdW1lbnQuCgpBY3R1YWxseSB3aGF0IEknbSBzYXlpbmcgaXMgYSBjaHVua2lu ZyBiZWZvcmUgdHJhbnNtaXR0aW5nICh1c2luZyBodHRwKSwgaW4gdGhpcyB3YXksIHRoZXkgYXJl IHRyZWF0ZWQgYXMgaW5kaXZpZHVhbCBkb2N1bWVudHMgZnJvbSB0aGUgc3RhbmRwb2ludCBvZiBo dHRwLiBCdXQgSSBkb24ndCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhcHByb3ByaWF0ZSBmb3IgcmVt b3RlU3RvcmFnZSwganVzdCBhIGNvbW1lbnQuCgoKUmVnYXJkcywKTGluaHVpCgoKQSBjb21wYXJp c29uIGRvY3VtZW50IHNvdW5kcyBnb29kISBTZWUgYWxzbyBodHRwOi8vd3d3LnNlcnZpY2VkZW51 YWdlcy5mci9lbi9nZW5lcmljLXN0b3JhZ2UtZWNvc3lzdGVtLgoKCgpDaGVlcnMsCgpNaWNoaWVs LgoKCgoKT24gV2VkLCBEZWMgMiwgMjAxNSBhdCAyOjMyIFBNLCBMaW5odWkgU3VuIDxsaC5zdW5s aW5oQGdtYWlsLmNvbT4gd3JvdGU6CgpUaGF0J3MgY29vbCBmb3IgbWUsIGEgc2VwYXJhdGUgc2Vj dGlvbiBmb3IgdGhpcyBtaWdodCBtYWtlIHNlbnNlLgoKCkFub3RoZXIgdGhpbmcgaXMgZG8gd2Ug bmVlZCB0byBpbmNsdWRlIGFuIGFwcGxpY2F0aW9uLWxheWVyIGNodW5raW5nIGhlcmUgKG5vdCBq dXN0IGZvciBhIGJyb3dzZXIgc3luYyksIHNpbmNlIGlmIHdlIHdhbnQgdG8gZnVydGhlciBleHRl bmQgb3RoZXIgY2FwYWJpbGl0aWVzIGl0IGlzIGVzc2VudGlhbC4KCgoKUmVnYXJkcywKTGluaHVp CgoKMjAxNS0xMi0wMiAyMTowMyBHTVQrMDg6MDAgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPGll dGZAaHVnby5sYWJrb2RlLmNvbT46CgpJIHByb3Bvc2UgdG8gY29tZSB1cCB3aXRoIGEgbGlzdCBv ZiBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIG9mIHVzaW5nIFdlYkRBViBhbmQgY29tcGFy ZSB0aGVtIGFnYWluc3QgYSBKU09OL1JFU1QgYmFzZWQgYXBwcm9hY2gsIGxpa2UgcmVtb3RlU3Rv cmFnZS4KCiAKRG9lcyBpdCBzb3VuZCBnb29kID8KIAogCk9uIFdlZCwgRGVjIDIsIDIwMTUsIGF0 IDAxOjU5IFBNLCBMaW5odWkgU3VuIHdyb3RlOgoKIAogCjIwMTUtMTItMDIgMjA6NDMgR01UKzA4 OjAwIEh1Z28gR29uesOhbGV6IExhYnJhZG9yIDxpZXRmQGh1Z28ubGFia29kZS5jb20+OgoKCgog CiAKIAogCk9uIFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjMwIFBNLCBNaWNoaWVsIGRlIEpvbmcg d3JvdGU6CgpIaSBhbGwhCgpUaGFua3MgZm9yIGFsbCB5b3VyIHJlYWN0aW9ucyB0byB0aGUgcmVt b3RlU3RvcmFnZSBJbnRlcm5ldC1EcmFmdC4KCiAKV2UgZ2V0IHRoZSBxdWVzdGlvbiBhYm91dCBX ZWJEQVYgYSBsb3QsIGluIHRoZSBuZXh0IHZlcnNpb24gd2Ugc2hvdWxkIGFkZCBhIHJlbWFyayBh Ym91dCBpdCBpbiB0aGUgaW50cm8uIFRoZSBmb2xkZXIgZGVzY3JpcHRpb25zIHJldHVybmVkIHdo ZW4geW91IEdFVCBhIFVSTCB0aGF0IGVuZHMgd2l0aCBhIC8gYXJlIGluZGVlZCBhIGRldmlhdGlv biBmcm9tIHRoZSBYTUwgcmV0dXJuZWQgYnkgV2ViREFWIHNlcnZlciwgYW5kIHRoaXMgaXMganVz dCBiZWNhdXNlIG5vd2FkYXlzIEpTT04gaXMgZWFzaWVyIHRvIHVzZSB0aGFuIFhNTCBmb3IgZGV2 ZWxvcGVycywgYm90aCBjbGllbnQtc2lkZSBhbmQgc2VydmVyLXNpZGUuCgogCiAKSSB0b3RhbGx5 IGFncmVlIGhlcmUsIHRoaXMgd2FzIGdvaW5nIHRvIGhhcHBlbiBzb29uIG9yIGxhdGVyIGFuZCBp dCBpcyByZWFsbHkgYXBwcmVjaWF0ZWQuCgogCiAKVGhlIGZhY3QgdGhhdCB3ZSBkb24ndCByZXF1 aXJlIHNlcnZlcnMgdG8gc3VwcG9ydCBXZWJEQVYncyBjdXN0b20gdmVyYnMgbGlrZSBQUk9QUEFU Q0ggZXRjLiBpcyBmb3IgdGhyZWUgcmVhc29uczoKCjEpIGl0J3MgYSBsb3Qgb2Ygd29yayB0byBp bXBsZW1lbnQgdGhpcyB3aXRob3V0IHVzaW5nIGFuIGV4aXN0aW5nIFdlYkRBViBsaWJyYXJ5Cgoy KSBpbiBwcmFjdGljZSwgYSBsb3Qgb2YgV2ViREFWIHNlcnZlcnMgZ2V0IGl0IHdyb25nLCBvciBk b24ndCBpbXBsZW1lbnQgYWxsIG9mIFdlYkRBVi4gSXQncyB2ZXJ5IGFubm95aW5nIGZvciBjbGll bnQgaW1wbGVtZW50ZXJzIHRvIGhhdmUgdG8gZGVhbCB3aXRoIHNlcnZlcnMgdGhhdCBlLmcuIGNo b3NlIG5vdCB0byBpbXBsZW1lbnQgTE9DSyBhbmQgVU5MT0NLLgoKMykgd2UgZG9uJ3QgcmVhbGx5 IG5lZWQgYWxsIHRoZXNlIGFkdmFuY2VkIGZlYXR1cmVzIG9uIHRvcCBvZiBzdGFuZGFyZCBIVFRQ LCBqdXN0IHN1cHBvcnRpbmcgR0VUL1BVVC9ERUxFVEUgZm9yIHJlc291cmNlcywgYW5kIGFkZGlu ZyBhIHNpbXBsZSBmb2xkZXIgZGVzY3JpcHRpb24gZm9ybWF0LCBpcyBlbm91Z2ggZm9yIG1vc3Qg YXBwbGljYXRpb25zLgoKIApPdGhlciB0aGFuIHRoYXQsIHRoZSByZW1vdGVTdG9yYWdlIEludGVy bmV0LURyYWZ0IHNwZWNpZmllcyBhICpsb3QqIG1vcmUgdGhhbiBqdXN0IGhvdyBlYWNoIEhUVFAg dmVyYiBzaG91bGQgYmVoYXZlOgoKKiByZXF1aXJpbmcgc3VwcG9ydCBmb3IgT0F1dGggaW1wbGlj aXQtZ3JhbnQgZmxvdwoKKiByZXF1aXJpbmcgRVRhZyBzdXBwb3J0IGFuZCBuZXN0ZWQgdmVyc2lv bmluZyAoaS5lLiB0aGUgZm9sZGVyJ3MgRVRhZyBjaGFuZ2VzIGlmIGFueXRoaW5nIHdpdGhpbiB0 aGF0IGZvbGRlciBjaGFuZ2VzKQoKKiByZXF1aXJpbmcgQ09SUyBoZWFkZXJzCgoqIHJlcXVpcmlu ZyBhIFdlYkZpbmdlciBhbm5vdW5jZW1lbnQgZm9yIHNlcnZpY2UgZGlzY292ZXJ5CgpJdCB3b3Vs ZCBiZSBlYXN5IHRvIGFkZCB0aGVzZSB0aHJlZSB0aGluZ3Mgb24gdG9wIG9mIFdlYkRBViwgaW5z dGVhZCBvZiBwdXR0aW5nIHRoZW0gb24gdG9wIG9mIG91ciBtaW5pbWFsIEdFVC9QVVQvREVMRVRF IEFQSSBkZWZpbml0aW9uLiBJbiBmYWN0LCB3ZSBjb3VsZCBwcm9iYWJseSBzZXBhcmF0ZSBpdCBp bnRvIHR3byBJbnRlcm5ldC1EcmFmdHM6IG9uZSBmb3IgdGhlICdSRVNUZnVsIGZvbGRlcnMnIEFQ SSB3aGljaCBpcyBvdXIgc2ltcGxpZmljYXRpb24gb2YgV2ViREFWLCBhbmQgYSBzZWNvbmQgb25l IGZvciBPQXV0aC9FVGFncy9DT1JTL1dlYkZpbmdlciBvbiB0b3Agb2YgZWl0aGVyIFdlYkRBViBv ciAnUkVTVGZ1bCBmb2xkZXJzJyBvciB3aGF0ZXZlciBvdGhlciBIVFRQLWJhc2VkIEFQSSB5b3Ug d2FudC4KCiAKIApUaGVyZSBpcyBvbmUgcmVxdWlyZW1lbnQgdGhhdCBhbGwgc3luY2hyb25pc2Vy cyBuZWVkIHRvIGhhbmRsZTogbW92aW5nIHJlc291cmNlcy4gSW4gdGhpcyBzcGVjIHRoZSBhbHRl cm5hdGl2ZSBvZiBhIFdlYkRBViBNT1ZFIGlzIG5vdCBzcGVjaWZpZWQuIAoKIApJdCBpcyB0cnVl IHRoYXQgYSBNT1ZFIGNvdWxkIGJlIHJlcGxhY2VkIHdpdGggYSBERUxFVEUgKyBVUExPQUQgYnV0 IHRoYXQgaXMgbm90IGFjY2VwdGFibGUgaW4gbW9zdCBjYXNlcyBkdWUgdG8gdGhlIGluZWZmaWNp ZW5jeSBvZiBzdWNoIG9wZXJhdGlvbiAoY3B1LCBiYW5kd2lkdGggY29uc3VtcHRpb24gLi4uKQoK IApJcyB0aGVyZSBhIHBsYW4gdG8gc3VwcG9ydCBzdWNoIGJhc2ljIGZlYXR1cmU/CgogCkZyb20g dGhlIGN1cnJlbnQgcmVtb3RlU3RvcmFnZSBzcGVjLCB0aGUgb3duQ2xvdWQgc3luYyBwcm90b2Nv bCBjYW4gYmUgaW1wbGVtZW50ZWQuIFRoZSBtaXNzaW5nIGJpdCBpcyB0cmFja2luZyB0aG9zZSBy ZW1vdGUgbW92ZXMuCgpJIGFncmVlIHdpdGggSHVnbyB0aGF0IE1PVkUgaXMgdXNlZnVsLCBzb21l dGltZXMgaWYgeW91IGp1c3QgcmVuYW1lIGEgZmlsZSBpdCB3aWxsIGJlIHBlcmZlY3QuIEJ1dCB0 aGUgcXVlc3Rpb24gSSBoYXZlIGlzIHRoYXQgd2hldGhlciB3ZSBuZWVkIHRvIG1ha2UgdHdvIGRv Y3VtZW50cz8gTXVsdGlwbGUgY2hvaWNlcyBpcyBub3QgZ29vZCBmb3Igc3RhbmRhcmRpemF0aW9u LiBJbiBteSB2aWV3LCB3ZWJkYXYgaXMgc29tZXRoaW5nIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEg dmVyeSBjbGVhciBkZWNpc2lvbiBvbiB3aGV0aGVyIHRvIGNvbnNpZGVyIGl0IG9yIG5vdC4KCiAK UmVnYXJkcywKCkxpbmh1aQoKIAogCkNoZWVycwoKIApPbiBXZWQsIERlYyAyLCAyMDE1IGF0IDEx OjI4IEFNLCBIdWdvIEdvbnrDoWxleiBMYWJyYWRvciA8aWV0ZkBodWdvLmxhYmtvZGUuY29tPiB3 cm90ZToKCgoKIAogCiAKIApPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAxMToxOCBBTSwgTGluaHVp IFN1biB3cm90ZToKCkhpCgogCk9uIOWRqOS4iSwgMTLmnIggMiwgMjAxNSBhdCAxNzo1NiwgSHVn byBHb256w6FsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT4gd3JvdGU6CgogCiAK IApPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwODoyMCBBTSwgTGluaHVpIFN1biB3cm90ZToKCkhp CgogCjIwMTUtMTItMDIgNToxNCBHTVQrMDg6MDAgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPGll dGZAaHVnby5sYWJrb2RlLmNvbT46CgpIaSwKCiAKZnJvbSBteSBwb2ludCBvZiB2aWV3IHRoZSBy ZW1vdGVTdG9yYWdlIHByb2plY3QgYWRkcmVzc2VzIGEgc3Vic2V0IG9mCgp0aGUgdXNlIGNhc2Vz IG9mIHRoZSAgV2ViREFWIHNwZWNpZmljYXRpb24uCgogClRoZSBtYWluIGRpZmZlcmVuY2UgSSBj YW4gb2JzZXJ2ZSBpcyB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIGlzIGJ1aWx0IG9uCgpSRVNUIGlu c3RlYWQgb2YgWE1MLWJhc2VkIGNvbW11bmljYXRpb24uCgogCkkgcGVyc29uYWxseSBsaWtlIG11 Y2ggbW9yZSBSRVNUIHRoYW4gV2ViREFWIGJlY2F1c2UgaXQgaXMgbW9yZQoKZGV2ZWxvcGVyIGZy aWVuZGx5IGFuZCBpdCBpcyBmYXN0ZXIgdG8gZGV2ZWxvcC4KCiBNYXliZSB0aGUgcmVtb3RlU3Rv cmFnZSBBUEkgYmVjb21lcyB0aGUgbmV4dCBXZWJEQVYgOikKCiAKSG93ZXZlciwgdGhlIHJlbW90 ZVN0b3JhZ2UgQVBJIGRvZXMgbm90IHByb3ZpZGUgYSB3YXkgb2Ygc3luY2hyb25pc2luZwoKZGF0 YSwgdGhpcyB0YXNrIGlzIGRlbGVnYXRlZCB0byB0aGUgZGV2ZWxvcGVycy4KCklzIHRoZXJlIGEg cGxhbiB0byBwcm92aWRlIHN1Y2ggZmVhdHVyZSBiYXNlZCBvbiB0aGUgb3V0Y29tZSBvZiB0aGlz CgpkcmFmdD8KCkknbSBhIGxpdHRsZSBiaXQgY29uZnVzZWQgd2h5IHlvdSBzYXkgdGhlIHJlbW90 ZVN0b3JhZ2UgZG9lcyBub3QgcHJvdmlkZSB0aGF0LiBJcyB0aGF0IGJlY2F1c2UgcmVtb3RlU3Rv cmFnZSBkb2VzIG5vdCBwZXJmb3JtIGxpa2UgYSB0eXBpY2FsIHN5bmMgc2VydmljZXMgKGUuZy4g ZHJvcGJveC4uLikgb3IgeW91IGFyZSBzYXlpbmcgc29tZXRoaW5nIGVsc2U/CgpZZXMsIGJlY2F1 c2UgaXQgZG9lcyBub3Qgb2ZmZXIgc3luY2hyb25pc2F0aW9uIGNhcGFiaWxpdGllcy4KCkdvdCBp dC4gQW5kIFdoYXQgSSBhbSB3b25kZXJpbmcgaXMgdGhhdCBkbyB3ZSBuZWVkIHRvIGluY2x1ZGUg dGhvc2UgY2FwYWJpbGl0aWVzIGluIGEgYmFzZSBzcGVjaWZpY2F0aW9ucy4gU2luY2UgaXQgaXMg aGFyZCB0byBzdGFuZGFyZGl6ZSB0aGUgY2FwYWJpbGl0aWVzIGxpa2UgZGVkdXAgb3IgZGVsdGEu IE1heWJlIGEgYmV0dGVyIHdheSBpcyB0byBkZWZpbmUgdGhvc2UgaW4gYSBzZXBhcmF0ZSBzcGVj aWZpY2F0aW9uLAoKIAogClRoYW5rcyBmb3IgZ2l2aW5nIHRoZXNlIGV4YW1wbGVzIC0gc28gYnkg J3N5bmNocm9uaXNhdGlvbiBjYXBhYmlsaXRpZXMnIHlvdSBtZWFuIDEpIGRlZHVwbGljYXRpb24g YW5kIDIpIGRlbHRhIHVwZGF0ZXM/IEFueXRoaW5nIGVsc2Ugb3IgaXMgdGhhdCBhbiBleGhhdXN0 aXZlIGxpc3Q/CgogCnNvbWV0aGluZyBsaWtlIGV4dGVuc2lvbnMuIEZvciBhIGJhc2UgZG9jdW1l bnQsIHdlIGp1c3QgbmVlZCB0byBkZWZpbmUgaG93IHRvIHBlcmZvcm0gc3luYyBvcGVyYXRpb25z LgoKIAogClllcywgSSBhZ3JlZSB0aGF0IG1heSBiZSBhbiBleHRlbnNpb24gb2YgdGhpcyBkcmFm dCBjb3VsZCBoYW5kbGUgdGhlIHN5bmNocm9uaXNhdGlvbiBwYXJ0LgoKIAogCiAKIApPdXIgSW50 ZXJuZXQtRHJhZnQgaXMgaGVhdmlseSBmb2N1c2VkIG9uIHRoZSB3b3JsZCB3aWRlIHdlYiwgd2hv c2UgVVJMcyBhcmUgbm90IGNvbnRlbnQtYWRkcmVzc2FibGUsIHdlIGNhbid0IGNoYW5nZSB0aGF0 LiBTbyB0aGF0IGFyY2hpdGVjdHVyZSBpcyBub3QgdmVyeSBmcmllbmRseSB0byBkZWR1cGxpY2F0 aW9uLCBjb21wYXJlZCB0byBmb3IgaW5zdGFuY2UgQml0VG9ycmVudC4gQXMgeW91IGFscmVhZHkg c2FpZCwgZGV2ZWxvcGVycyBjYW4gc3RpbGwgZGVkdXBlIG9uIHRoZSBzZXJ2ZXItc2lkZSB3aGVu IHN0b3JpbmcgYmxvYnMgdG8gZGlzaywgYW5kIGNhbiBhbHNvIGRlZHVwZSBvbiB0aGUgY2xpZW50 IHNpZGUgYmVmb3JlIGNyZWF0aW5nIHRoZSByZXNvdXJjZXMgdGhlIGNsaWVudCB1cGxvYWRzLgoK QXMgZmFyIGFzIEkga25vdywgZGVsdGEgdXBkYXRlcyBhcmUgbm90IHN1cHBvcnRlZCBieSB0aGUg RVRhZyBzeXN0ZW0gLSB5b3UgY2Fubm90IGRvIGEgcmFuZ2UgcmVxdWVzdCB0byBmaW5kIG91dCBp ZiBjZXJ0YWluIGJ5dGVzIHdpdGhpbiBhIGRvY3VtZW50IGhhdmUgY2hhbmdlZC4gSG93ZXZlciwg dGhlIGZvbGRlciBzeXN0ZW0gd2UgZGVmaW5lIGRvZXMgZW5jb3VyYWdlIHlvdSwgZm9yIGluc3Rh bmNlIHdoZW4geW91IGRldmVsb3AgYSBUbyBEbyBMaXN0IGFwcCwgcHV0IGVhY2ggdGFzayBvbiBp dHMgb3duIGRvY3VtZW50LCBhbmQgdGhlbiBxdWVyeSB0aGUgZm9sZGVyIHRvIHNlZSB3aGljaCBv ZiB0aGVtIGNoYW5nZWQsIGluc3RlYWQgb2YgcHV0dGluZyB0aGVtIGFsbCBpbiBvbmUgYmlnIGRv Y3VtZW50IGFuZCByZXRyaWV2aW5nIHRoZSB3aG9sZSBkb2N1bWVudCBlYWNoIHRpbWUuCgogCkNo ZWVycywKCk1pY2hpZWwuCgogCiAKIAogCkJUVywgSSB3YW50IHRvIGludHJvZHVjZSBDbGF3SU8g KGh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvKSwgYSByZXNlYXJjaAoKcHJvamVjdCB0byBiZW5jaG1h cmsgZGlmZmVyZW50IHN5bmNocm9uaXNhdGlvbiBwcm90b2NvbHMgYWdhaW5zdAoKZGlmZmVyZW50 IGRhdGEgYmFja2VuZHMgd2l0aCBzcGVjaWFsIGF0dGVudGlvbiB0byBwcm92aWRlIGEgY29tbW9u IHN5bmMKCkFQSS4KCiAKQSBjb21tb24gQVBJIGZvciBkaWZmZXJlbnQgc3luYyBwcm90b2NvbHMg aXMgYmVpbmcgY3JlYXRlZCBiYXNlZCBvbiB0aGUKCmFyY2hpdGVjdHVyZSBzcGVjaWZpZWQgaW4g dGhpcyBkcmFmdCAoY29udHJvbCBhbmQgZGF0YSBzZXJ2ZXJzKSBhbmQgdGhlCgpJIGNhbm5vdCBm aW5kIGEgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0dXJlIGluIHRoaXMgZHJhZnQuIEl0IHNlZW1zIHRo YXQgdGhleSBoYW5kbGUgbWV0YWRhdGEgYW5kIGNvbnRlbnQgZGF0YSB0b2dldGhlciwganVzdCBs aWtlIGEgbm9ybWFsIHdlYiBzZXJ2aWNlLgoKIApDbGF3SU8gaXMgZnVsbHkgZGlzdHJpYnV0ZWQu IEV2ZXJ5IGxvZ2ljYWwgdW5pdCBpcyBhIGRpZmZlcmVudCBzZXJ2ZXIgdGhhbiBiZSBzY2FsZWQg b3V0LiBEYXRhIGFuZCBNZXRhZGF0YSBjaGFubmVscyBhcmUgaW5kZXBlbmRlbnQgZnJvbSBlYWNo IG90aGVyIGFuZCByZXNpZGUgb24gZGlmZmVyZW50IHNlcnZlcnMuCgpUaGF0IGlzIHdpZGVseSBl bXBsb3llZCBpbiBwb3B1bGFyIHN5bmMgc2VydmljZXMuIEFuZCB0aGF0IGlzIGFsc28gYmVuZWZp Y2lhbCB0byBwcml2YWN5IHRvIHNvbWUgZXh0ZW50LiBCdXQgaW4gdGhlIGNvbnRleHQgb2Ygc3lu YyBpbiBicm93c2VyICh3aGljaCBpcyBtYWlubHkgY29uc2lkZXJlZCBpbiB0aGUgcmVtb3RlU3Rv cmFnZSksIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgcmVhc29uYWJsZS4gQnV0IEkgdGhp bmsgd2Ugc2hvdWxkIGRlcGxveSBkaXN0cmlidXRlZCBhcmNoaXRlY3R1cmUgYWx0aG91Z2ggaXQg d2lsbCBtYWtlIHRoaW5ncyBjb21wbGljYXRlZC4KCiAKIApPZiBjb3Vyc2UsIHRoZSByZW1vdGVT dG9yYWdlIGlzIHRhcmdldGVkIHRvIGJyb3dzZXJzLCBzbyBzeW5jaW5nIGRvZXMgbm90IG1ha2Ug dG9vIG11Y2ggc2Vuc2UgaW4gdGhpcyBjYXNlLgoKV2l0aCB0aGUgcmlzZSBvZiBMaW51eCBjb250 YWluZXIgbWljcm8tc2VydmljZSBiYXNlZCBhcmNoaXRlY3R1cmVzLCB0aGUgZGVwbG95bWVudCBv ZiAgc3VjaCBoaWdobHkgY29tcGxleCBzeXN0ZW1zIHNob3VsZCBiZWNvbWUgZWFzaWVyIGFuZCBm YXN0ZXIuCgogCkJlc3QsCgogCiAKSHVnbwoKIAogClJlZ2FyZHMsCgpMaW5odWkgCgogCiAKUmVn YXJkcywKCkxpbmh1aQoKb25lIGZyb20gdGhlIENFUk4gRU9TIHByb2plY3QgKG1hbmFnZW1lbnQs IGRpc2sgYW5kIHF1ZXVlIHNlcnZlcnMpLgoKIApUaGUgUGhhc2UgSSBoYXMgaW1wbGVtZW50ZWQg dGhlIG93bkNsb3VkIFN5bmMgUHJvdG9jb2wgYW5kIFBoYXNlIElJIHdpbGwKCmltcGxlbWVudCB0 aGUgU2VhRmlsZSBTeW5jIFByb3RvY29sLgoKVGhlIGNob2ljZSBvZiB0aGVzZSBwcm90b2NvbHMg YW1vbmcgb3RoZXJzIGlzIGJlY2F1c2UgdGhleSBhcmUgcmVhbGx5CgpvcHBvc2VkIHRvIGVhY2gg b3RoZXIgaW4gdGVybXMgb2Ygc3luY2luZyAoZGVsdGEgdnMgbm9uLWRlbHRhLAoKc3RhdGUtYmFz ZWQgdnMgbG9nL2V2ZW50L2dpdC1iYXNlZCBzeW5jIOKApiksIHNvIGZpbmRpbmcgYSBjb21tb24g YXBwcm9hY2gKCmlzIG1vcmUgY2hhbGxlbmdpbmcuCgogClByb3ZpZGluZyBhIGJhc2Ugc3BlY2lm aWNhdGlvbi9hcmNoaXRlY3R1cmUgdG8gbWVhc3VyZSB0aGUgZmVhc2liaWxpdHkKCm9mIHRoaXMg ZHJhZnQgaXMgb25lIG9mIHRoZSBvYmplY3RpdmVzIG9mIHRoZSBwcm9qZWN0LgoKIApJIGJlbGll dmUgdGhhdCB0aGUgd29yayBiZWluZyBkb25lIGhlcmUgYW5kIGluIENsYXdJTyBhcmUgc3VwcGxl bWVudGFyeQoKdG8gZWFjaCBvdGhlciBhbmQgSSB0aGluayBtdXR1YWwgY29sbGFib3JhdGlvbiBj b3VsZCBiZSBiZW5lZmljaWFsIGZvcgoKYm90aCBzaWRlcy4KCiAKQWxzbywgaWYgdGhlcmUgaXMg aW50ZXJlc3QsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBjYW4gYmUgYWRkZWQgdG8KCkNsYXdJTy4K CiAKQmVzdCByZWdhcmRzLAoKIApIdWdvIEdvbnphbGV6IExhYnJhZG9yCgogCk9uIFR1ZSwgRGVj IDEsIDIwMTUsIGF0IDA5OjAwIFBNLCBzdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnIHdyb3Rl OgoKPiBTZW5kIFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bwoKPiAgICAg ICBzdG9yYWdlc3luY0BpZXRmLm9yZwoKPgoKPiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUg dmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQKCj4gICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYwoKPiBvciwgdmlhIGVtYWlsLCBzZW5kIGEg bWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8KCj4gICAgICAgc3RvcmFnZXN5 bmMtcmVxdWVzdEBpZXRmLm9yZwoKPgoKPiBZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdp bmcgdGhlIGxpc3QgYXQKCj4gICAgICAgc3RvcmFnZXN5bmMtb3duZXJAaWV0Zi5vcmcKCj4KCj4g V2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9y ZSBzcGVjaWZpYwoKPiB0aGFuICJSZTogQ29udGVudHMgb2YgU3RvcmFnZXN5bmMgZGlnZXN0Li4u IgoKPiBUb2RheSdzIFRvcGljczoKCj4KCj4gICAgMS4gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVq b25nLXJlbW90ZXN0b3JhZ2UgICAgSW50ZXJuZXQtRHJhZnQKCj4gICAgICAgYXZhaWxhYmxlIChN aWNoaWVsIGRlIEpvbmcpCgo+ICAgIDIuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmct cmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdAoKPiAgICAgICBhdmFpbGFibGUgKEdpaGFuIERp YXMpCgo+ICAgIDMuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFn ZSBJbnRlcm5ldC1EcmFmdAoKPiAgICAgICBhdmFpbGFibGUgKEZlaSBTb25nKQoKPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKPiBTdG9yYWdlc3luYyBt YWlsaW5nIGxpc3QKCj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcKCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYwoKPiBFbWFpbCBoYWQgMyBhdHRhY2htZW50 czoKCj4gKyBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVz dG9yYWdlCgo+IEludGVybmV0LURyYWZ0IGF2YWlsYWJsZQoKPiAgIDJrIChtZXNzYWdlL3JmYzgy MikKCj4gKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVt b3Rlc3RvcmFnZQoKPiBJbnRlcm5ldC1EcmFmdCBhdmFpbGFibGUKCj4gICAxayAobWVzc2FnZS9y ZmM4MjIpCgo+ICsgUmU6IFtTdG9yYWdlc3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25n LXJlbW90ZXN0b3JhZ2UKCj4gSW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxlCgo+ICAgMmsgKG1lc3Nh Z2UvcmZjODIyKQoKIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0CgpTdG9yYWdlc3luY0BpZXRmLm9yZwoKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYwoKIAogCiAKIAoK CgoKCgoK ------=_Part_41404_1089348070.1449132248276 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PFA+SGkgTWljaGllbCBhbmQgTGluaHVpLDwvUD4KPFA+SSB0aGluayBpdCB3aWxsIGJlIGdvb2Qg dG8gaGF2ZSBhIGJvdW5kYXJ5IGZvciB0aGlzIGRyYWZ0IGFuZCBsZWF2ZSBzb21lIHdvcmsgZm9y IHRoZSBhcHBsaWNhaXRvbiBsYXllcn48QlI+PEJSPjwvUD4KPEJMT0NLUVVPVEUgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjZiNmI2IDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1M RUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4IiBuYW1lPSJyZXBseUNvbnRlbnQiPi0tLS0t5Y6f 5aeL6YKu5Lu2LS0tLS08QlI+PEI+5Y+R5Lu25Lq6OjwvQj4gIk1pY2hpZWwgZGUgSm9uZyIgJmx0 O21iZGVqb25nQG1vemlsbGEuY29tJmd0OzxCUj48Qj7lj5HpgIHml7bpl7Q6PC9CPiAyMDE15bm0 MTLmnIgy5pelIOaYn+acn+S4iTxCUj48Qj7mlLbku7bkuro6PC9CPiAiTGluaHVpIFN1biIgJmx0 O2xoLnN1bmxpbmhAZ21haWwuY29tJmd0OzxCUj48Qj7mioTpgIE6PC9CPiBzdG9yYWdlc3luYyAm bHQ7c3RvcmFnZXN5bmNAaWV0Zi5vcmcmZ3Q7LCBma29vbWFuICZsdDtma29vbWFuQHR1eGVkLm5l dCZndDssICJIdWdvIEdvbnrDoWxleiBMYWJyYWRvciIgJmx0O2lldGZAaHVnby5sYWJrb2RlLmNv bSZndDs8QlI+PEI+5Li76aKYOjwvQj4gUmU6IFtTdG9yYWdlc3luY10gU3RvcmFnZXN5bmMgRGln ZXN0LCBWb2wgNSwgSXNzdWUgMTxCUj48QlI+CjxESVYgZGlyPSJsdHIiPgo8RElWPgo8RElWPgo8 RElWPkFoIHN1cmUsIHRoYXQncyBlbnRpcmVseSBhcHByb3ByaWF0ZSwgcmVtb3RlU3RvcmFnZSB0 cmVhdHMgYm90aCB0aGUgQ29udGVudC1UeXBlIGhlYWRlciB2YWx1ZSBhbmQgdGhlIGFjdHVhbCBi b2R5IG9mIGEgZG9jdW1lbnQgYXMgb3BhcXVlIHN0cmluZ3Mgb2YgYnl0ZXMuIEl0IGRvZXNuJ3Qg ImNhcmUiIGlmIHlvdSB1c2UgaXQgdG8gc3RvcmUgb25seSBkYXRhIGJsb2NrcyB0aGF0IGFyZSBj aHVua3Mgb2Ygc29tZXRoaW5nIGVsc2UuPEJSPjxCUj48L0RJVj4KPERJVj5Gb3IgaW5zdGFuY2Us IHlvdSBjb3VsZCBoYXZlIGEgZm9sZGVyIG9uIGEgdXNlcidzIHN0b3JhZ2UgdGhhdCBjb250YWlu cyBvbmx5IGlub2RlLWxpa2UgSlNPTi1kb2N1bWVudHMsIHdoaWNoIGxpc3QgdGhlIFVSTHMgb2Yg YmluYXJ5IGRvY3VtZW50cyB0aGF0IG1ha2UgdXAgMUtiIGJsb2NrcyBvZiB0aGUgYWN0dWFsIGRh dGEuIE5pY2UgZm9yIGRlZHVwaW5nLCBkZWx0YSB1cGRhdGVzLCBhbmQgYWxzbyByZW5hbWluZyBm aWxlcyB3aXRob3V0IHJldXBsb2FkaW5nIHRoZWlyIGNvbnRlbnQuPEJSPjwvRElWPgo8RElWPjxC Uj48L0RJVj5CdXQgeWVhaCwgdGhlIGFyZ3VtZW50IGlzIHRoYXQgKmhvdyogdG8gY3JlYXRlIGFu ZCBtYW5hZ2UgdGhlc2UgY2h1bmtzLCBpcyB0aGVuIHN0aWxsIGxlZnQgdXAgdG8gdGhlIGFwcGxp Y2F0aW9uIGRldmVsb3BlciAob3IgdG8gYW5vdGhlciBzcGVjIG9uIHRvcCBvZiB0aGUgcmVtb3Rl U3RvcmFnZSBzcGVjKS48QlI+PEJSPjxCUj48L0RJVj5DaGVlcnMsPEJSPjwvRElWPk1pY2hpZWwu PEJSPjwvRElWPgo8RElWIGNsYXNzPSJnbWFpbF9leHRyYSI+PEJSPgo8RElWIGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gV2VkLCBEZWMgMiwgMjAxNSBhdCAzOjI5IFBNLCBMaW5odWkgU3VuIDxTUEFO IGRpcj0ibHRyIj4mbHQ7PEEgaHJlZj0ibWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bGguc3VubGluaEBnbWFpbC5jb208L0E+Jmd0OzwvU1BBTj4gd3JvdGU6PEJS Pgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46 IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4KPERJViBkaXI9Imx0ciI+SGkgCjxESVYgY2xhc3M9ImdtYWlsX2V4dHJhIj48QlI+CjxESVYg Y2xhc3M9ImdtYWlsX3F1b3RlIj48U1BBTj4yMDE1LTEyLTAyIDIyOjA1IEdNVCswODowMCBNaWNo aWVsIGRlIEpvbmcgPFNQQU4gZGlyPSJsdHIiPiZsdDs8QSBocmVmPSJtYWlsdG86bWJkZWpvbmdA bW96aWxsYS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYmRlam9uZ0Btb3ppbGxhLmNvbTwvQT4mZ3Q7 PC9TUEFOPjo8QlI+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogI2NjYyAxcHggc29s aWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiBjbGFzcz0i Z21haWxfcXVvdGUiPgo8RElWIGRpcj0ibHRyIj4KPERJVj4KPERJVj4KPERJVj4KPERJVj5Db29s ISBJIGNyZWF0ZWQgPEEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3JlbW90ZXN0b3JhZ2Uvc3Bl Yy9pc3N1ZXMvMTM3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3JlbW90ZXN0 b3JhZ2Uvc3BlYy9pc3N1ZXMvMTM3PC9BPiBhYm91dCB0aGUgbmVlZCBmb3ImbmJzcDsgTU9WRSB2 ZXJiLjxCUj48QlI+PC9ESVY+QXBwbGljYXRpb24tbGV2ZWwgY2h1bmtpbmcgaXMgcGFydGlhbGx5 IHN1cHBvcnRlZCBieSBIVFRQIGl0c2VsZiB0aHJvdWdoIGBDb250ZW50LVJhbmdlYCBoZWFkZXJz IChhbHRob3VnaCBpdCdzIG5vdCBjbGVhciB3aGV0aGVyIHRoZXNlIGFyZSBhbGxvd2VkIG9uIFBV VCByZXF1ZXN0cyBhcyB3ZWxsIGFzIG9uIEdFVCByZXF1ZXN0cywgc2VlIDxBIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzMSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzMTwvQT4p LiBUaGUgcHJvYmxlbSBpcyB0aGF0IEhUVFAgZGVmaW5lcyB2ZXJzaW9uaW5nIGF0IHRoZSBkb2N1 bWVudCBsZXZlbCwgeW91IGNhbm5vdCBhc2sgYSBzZXJ2ZXIgdG8gcHJvZHVjZSBvciBjaGVjayBh biBFVGFnIGZvciBhIHNwZWNpZmljIGJ5dGUtcmFuZ2Ugb2YgYSBkb2N1bWVudCwgb25seSBmb3Ig dGhlIGVudGlyZSBkb2N1bWVudC48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FV T1RFPjwvU1BBTj4KPERJVj5BY3R1YWxseSB3aGF0IEknbSBzYXlpbmcgaXMgYSBjaHVua2luZyBi ZWZvcmUgdHJhbnNtaXR0aW5nICh1c2luZyBodHRwKSwgaW4gdGhpcyB3YXksIHRoZXkgYXJlIHRy ZWF0ZWQgYXMgaW5kaXZpZHVhbCBkb2N1bWVudHMgZnJvbSB0aGUgc3RhbmRwb2ludCBvZiBodHRw LiBCdXQgSSBkb24ndCBrbm93IHdoZXRoZXIgdGhpcyBpcyBhcHByb3ByaWF0ZSBmb3IgcmVtb3Rl U3RvcmFnZSwganVzdCBhIGNvbW1lbnQuPC9ESVY+CjxESVY+PEJSPjwvRElWPgo8RElWPlJlZ2Fy ZHMsPC9ESVY+CjxESVY+TGluaHVpPC9ESVY+CjxESVY+CjxESVYgY2xhc3M9Img1Ij4KPEJMT0NL UVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4 IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+CjxESVYg ZGlyPSJsdHIiPgo8RElWPgo8RElWPgo8RElWPjxCUj48L0RJVj5BIGNvbXBhcmlzb24gZG9jdW1l bnQgc291bmRzIGdvb2QhIFNlZSBhbHNvIDxBIGhyZWY9Imh0dHA6Ly93d3cuc2VydmljZWRlbnVh Z2VzLmZyL2VuL2dlbmVyaWMtc3RvcmFnZS1lY29zeXN0ZW0iIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vd3d3LnNlcnZpY2VkZW51YWdlcy5mci9lbi9nZW5lcmljLXN0b3JhZ2UtZWNvc3lzdGVtPC9B Pi48QlI+PEJSPjxCUj48L0RJVj5DaGVlcnMsPEJSPjwvRElWPk1pY2hpZWwuPEJSPjxCUj48L0RJ Vj4KPERJVj4KPERJVj4KPERJViBjbGFzcz0iZ21haWxfZXh0cmEiPjxCUj4KPERJViBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIFdlZCwgRGVjIDIsIDIwMTUgYXQgMjozMiBQTSwgTGluaHVpIFN1biA8 U1BBTiBkaXI9Imx0ciI+Jmx0OzxBIGhyZWY9Im1haWx0bzpsaC5zdW5saW5oQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmxoLnN1bmxpbmhAZ21haWwuY29tPC9BPiZndDs8L1NQQU4+IHdyb3Rl OjxCUj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZDsgTUFS R0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIGNsYXNzPSJnbWFpbF9x dW90ZSI+CjxESVYgZGlyPSJsdHIiPlRoYXQncyBjb29sIGZvciBtZSwgYSBzZXBhcmF0ZSBzZWN0 aW9uIGZvciB0aGlzIG1pZ2h0IG1ha2Ugc2Vuc2UuIAo8RElWPjxCUj48L0RJVj4KPERJVj5Bbm90 aGVyIHRoaW5nIGlzIGRvIHdlIG5lZWQgdG8gaW5jbHVkZSBhbiBhcHBsaWNhdGlvbi1sYXllciBj aHVua2luZyBoZXJlIChub3QganVzdCBmb3IgYSBicm93c2VyIHN5bmMpLCBzaW5jZSBpZiB3ZSB3 YW50IHRvIGZ1cnRoZXIgZXh0ZW5kIG90aGVyIGNhcGFiaWxpdGllcyBpdCBpcyBlc3NlbnRpYWwu PEJSPgo8RElWPjxCUj48L0RJVj4KPERJVj5SZWdhcmRzLDwvRElWPgo8RElWPkxpbmh1aTwvRElW PjwvRElWPjwvRElWPgo8RElWPgo8RElWPgo8RElWIGNsYXNzPSJnbWFpbF9leHRyYSI+PEJSPgo8 RElWIGNsYXNzPSJnbWFpbF9xdW90ZSI+MjAxNS0xMi0wMiAyMTowMyBHTVQrMDg6MDAgSHVnbyBH b256w6FsZXogTGFicmFkb3IgPFNQQU4gZGlyPSJsdHIiPiZsdDs8QSBocmVmPSJtYWlsdG86aWV0 ZkBodWdvLmxhYmtvZGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBodWdvLmxhYmtvZGUuY29t PC9BPiZndDs8L1NQQU4+OjxCUj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiAjY2Nj IDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgi IGNsYXNzPSJnbWFpbF9xdW90ZSI+PFU+PC9VPgo8RElWPgo8RElWPkkgcHJvcG9zZSB0byBjb21l IHVwIHdpdGggYSBsaXN0IG9mIGFkdmFudGFnZXMgYW5kIGRpc2FkdmFudGFnZXMgb2YgdXNpbmcg V2ViREFWIGFuZCBjb21wYXJlIHRoZW0gYWdhaW5zdCBhIEpTT04vUkVTVCBiYXNlZCBhcHByb2Fj aCwgbGlrZSByZW1vdGVTdG9yYWdlLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5E b2VzIGl0IHNvdW5kIGdvb2QgPzwvRElWPgo8RElWPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8 RElWPiZuYnNwOzwvRElWPgo8RElWPk9uIFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjU5IFBNLCBM aW5odWkgU3VuIHdyb3RlOjxCUj48L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+CjxESVYg ZGlyPSJsdHIiPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW Pgo8RElWPjIwMTUtMTItMDIgMjA6NDMgR01UKzA4OjAwIEh1Z28gR29uesOhbGV6IExhYnJhZG9y IDxTUEFOIGRpcj0ibHRyIj4mbHQ7PEEgaHJlZj0ibWFpbHRvOmlldGZAaHVnby5sYWJrb2RlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAaHVnby5sYWJrb2RlLmNvbTwvQT4mZ3Q7PC9TUEFOPjo8 QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0 KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4 Ij4KPERJVj48VT48L1U+PEJSPjwvRElWPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZu YnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFO Pk9uIFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjMwIFBNLCBNaWNoaWVsIGRlIEpvbmcgd3JvdGU6 PC9TUEFOPjxCUj48L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+CjxESVYgZGlyPSJsdHIi Pgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8RElWPgo8 RElWPgo8RElWPgo8RElWPgo8RElWPjxTUEFOPkhpIGFsbCE8L1NQQU4+PEJSPjwvRElWPjwvRElW Pgo8RElWPjxTUEFOPlRoYW5rcyBmb3IgYWxsIHlvdXIgcmVhY3Rpb25zIHRvIHRoZSByZW1vdGVT dG9yYWdlIEludGVybmV0LURyYWZ0LjwvU1BBTj48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+ PC9ESVY+CjxESVY+PFNQQU4+V2UgZ2V0IHRoZSBxdWVzdGlvbiBhYm91dCBXZWJEQVYgYSBsb3Qs IGluIHRoZSBuZXh0IHZlcnNpb24gd2Ugc2hvdWxkIGFkZCBhIHJlbWFyayBhYm91dCBpdCBpbiB0 aGUgaW50cm8uIFRoZSBmb2xkZXIgZGVzY3JpcHRpb25zIHJldHVybmVkIHdoZW4geW91IEdFVCBh IFVSTCB0aGF0IGVuZHMgd2l0aCBhIC8gYXJlIGluZGVlZCBhIGRldmlhdGlvbiBmcm9tIHRoZSBY TUwgcmV0dXJuZWQgYnkgV2ViREFWIHNlcnZlciwgYW5kIHRoaXMgaXMganVzdCBiZWNhdXNlIG5v d2FkYXlzIEpTT04gaXMgZWFzaWVyIHRvIHVzZSB0aGFuIFhNTCBmb3IgZGV2ZWxvcGVycywgYm90 aCBjbGllbnQtc2lkZSBhbmQgc2VydmVyLXNpZGUuPC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0RJ Vj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48 L0JMT0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SSB0 b3RhbGx5IGFncmVlIGhlcmUsIHRoaXMgd2FzIGdvaW5nIHRvIGhhcHBlbiBzb29uIG9yIGxhdGVy IGFuZCBpdCBpcyByZWFsbHkgYXBwcmVjaWF0ZWQuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElW Pgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4KPERJViBkaXI9Imx0 ciI+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+ CjxESVY+PFNQQU4+VGhlIGZhY3QgdGhhdCB3ZSBkb24ndCByZXF1aXJlIHNlcnZlcnMgdG8gc3Vw cG9ydCBXZWJEQVYncyBjdXN0b20gdmVyYnMgbGlrZSBQUk9QUEFUQ0ggZXRjLiBpcyBmb3IgdGhy ZWUgcmVhc29uczo8L1NQQU4+PEJSPjwvRElWPjwvRElWPgo8RElWPjxTUEFOPjEpIGl0J3MgYSBs b3Qgb2Ygd29yayB0byBpbXBsZW1lbnQgdGhpcyB3aXRob3V0IHVzaW5nIGFuIGV4aXN0aW5nIFdl YkRBViBsaWJyYXJ5PC9TUEFOPjxCUj48L0RJVj48L0RJVj4KPERJVj48U1BBTj4yKSBpbiBwcmFj dGljZSwgYSBsb3Qgb2YgV2ViREFWIHNlcnZlcnMgZ2V0IGl0IHdyb25nLCBvciBkb24ndCBpbXBs ZW1lbnQgYWxsIG9mIFdlYkRBVi4gSXQncyB2ZXJ5IGFubm95aW5nIGZvciBjbGllbnQgaW1wbGVt ZW50ZXJzIHRvIGhhdmUgdG8gZGVhbCB3aXRoIHNlcnZlcnMgdGhhdCBlLmcuIGNob3NlIG5vdCB0 byBpbXBsZW1lbnQgTE9DSyBhbmQgVU5MT0NLLjwvU1BBTj48QlI+PC9ESVY+PC9ESVY+CjxESVY+ PFNQQU4+Mykgd2UgZG9uJ3QgcmVhbGx5IG5lZWQgYWxsIHRoZXNlIGFkdmFuY2VkIGZlYXR1cmVz IG9uIHRvcCBvZiBzdGFuZGFyZCBIVFRQLCBqdXN0IHN1cHBvcnRpbmcgR0VUL1BVVC9ERUxFVEUg Zm9yIHJlc291cmNlcywgYW5kIGFkZGluZyBhIHNpbXBsZSBmb2xkZXIgZGVzY3JpcHRpb24gZm9y bWF0LCBpcyBlbm91Z2ggZm9yIG1vc3QgYXBwbGljYXRpb25zLjwvU1BBTj48QlI+PC9ESVY+CjxE SVY+Jm5ic3A7PC9ESVY+PC9ESVY+CjxESVY+PFNQQU4+T3RoZXIgdGhhbiB0aGF0LCB0aGUgcmVt b3RlU3RvcmFnZSBJbnRlcm5ldC1EcmFmdCBzcGVjaWZpZXMgYSAqbG90KiBtb3JlIHRoYW4ganVz dCBob3cgZWFjaCBIVFRQIHZlcmIgc2hvdWxkIGJlaGF2ZTo8L1NQQU4+PEJSPjwvRElWPjwvRElW Pgo8RElWPjxTUEFOPiogcmVxdWlyaW5nIHN1cHBvcnQgZm9yIE9BdXRoIGltcGxpY2l0LWdyYW50 IGZsb3c8L1NQQU4+PEJSPjwvRElWPjwvRElWPgo8RElWPjxTUEFOPiogcmVxdWlyaW5nIEVUYWcg c3VwcG9ydCBhbmQgbmVzdGVkIHZlcnNpb25pbmcgKGkuZS4gdGhlIGZvbGRlcidzIEVUYWcgY2hh bmdlcyBpZiBhbnl0aGluZyB3aXRoaW4gdGhhdCBmb2xkZXIgY2hhbmdlcyk8L1NQQU4+PEJSPjwv RElWPgo8RElWPjxTUEFOPiogcmVxdWlyaW5nIENPUlMgaGVhZGVyczwvU1BBTj48QlI+PC9ESVY+ PC9ESVY+CjxESVY+PFNQQU4+KiByZXF1aXJpbmcgYSBXZWJGaW5nZXIgYW5ub3VuY2VtZW50IGZv ciBzZXJ2aWNlIGRpc2NvdmVyeTwvU1BBTj48QlI+PC9ESVY+PC9ESVY+CjxESVY+PFNQQU4+SXQg d291bGQgYmUgZWFzeSB0byBhZGQgdGhlc2UgdGhyZWUgdGhpbmdzIG9uIHRvcCBvZiBXZWJEQVYs IGluc3RlYWQgb2YgcHV0dGluZyB0aGVtIG9uIHRvcCBvZiBvdXIgbWluaW1hbCBHRVQvUFVUL0RF TEVURSBBUEkgZGVmaW5pdGlvbi4gSW4gZmFjdCwgd2UgY291bGQgcHJvYmFibHkgc2VwYXJhdGUg aXQgaW50byB0d28gSW50ZXJuZXQtRHJhZnRzOiBvbmUgZm9yIHRoZSAnUkVTVGZ1bCBmb2xkZXJz JyBBUEkgd2hpY2ggaXMgb3VyIHNpbXBsaWZpY2F0aW9uIG9mIFdlYkRBViwgYW5kIGEgc2Vjb25k IG9uZSBmb3IgT0F1dGgvRVRhZ3MvQ09SUy9XZWJGaW5nZXIgb24gdG9wIG9mIGVpdGhlciBXZWJE QVYgb3IgJ1JFU1RmdWwgZm9sZGVycycgb3Igd2hhdGV2ZXIgb3RoZXIgSFRUUC1iYXNlZCBBUEkg eW91IHdhbnQuPC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+ Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+VGhlcmUgaXMgb25lIHJlcXVpcmVt ZW50IHRoYXQgYWxsIHN5bmNocm9uaXNlcnMgbmVlZCB0byBoYW5kbGU6IG1vdmluZyByZXNvdXJj ZXMuIEluIHRoaXMgc3BlYyB0aGUgYWx0ZXJuYXRpdmUgb2YgYSBXZWJEQVYgTU9WRSBpcyBub3Qg c3BlY2lmaWVkLiZuYnNwOzxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JdCBpcyB0 cnVlIHRoYXQgYSBNT1ZFIGNvdWxkIGJlIHJlcGxhY2VkIHdpdGggYSBERUxFVEUgKyBVUExPQUQg YnV0IHRoYXQgaXMgbm90IGFjY2VwdGFibGUgaW4gbW9zdCBjYXNlcyBkdWUgdG8gdGhlIGluZWZm aWNpZW5jeSBvZiBzdWNoIG9wZXJhdGlvbiAoY3B1LCBiYW5kd2lkdGggY29uc3VtcHRpb24gLi4u KTxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JcyB0aGVyZSBhIHBsYW4gdG8gc3Vw cG9ydCBzdWNoIGJhc2ljIGZlYXR1cmU/PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW PkZyb20gdGhlIGN1cnJlbnQgcmVtb3RlU3RvcmFnZSBzcGVjLCB0aGUgb3duQ2xvdWQgc3luYyBw cm90b2NvbCBjYW4gYmUgaW1wbGVtZW50ZWQuIFRoZSBtaXNzaW5nIGJpdCBpcyB0cmFja2luZyB0 aG9zZSByZW1vdGUgbW92ZXMuPEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj5JIGFn cmVlIHdpdGggSHVnbyB0aGF0IE1PVkUgaXMgdXNlZnVsLCBzb21ldGltZXMgaWYgeW91IGp1c3Qg cmVuYW1lIGEgZmlsZSBpdCB3aWxsIGJlIHBlcmZlY3QuIEJ1dCB0aGUgcXVlc3Rpb24gSSBoYXZl IGlzIHRoYXQgd2hldGhlciB3ZSBuZWVkIHRvIG1ha2UgdHdvIGRvY3VtZW50cz8gTXVsdGlwbGUg Y2hvaWNlcyBpcyBub3QgZ29vZCBmb3Igc3RhbmRhcmRpemF0aW9uLiBJbiBteSB2aWV3LCB3ZWJk YXYgaXMgc29tZXRoaW5nIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEgdmVyeSBjbGVhciBkZWNpc2lv biBvbiB3aGV0aGVyIHRvIGNvbnNpZGVyIGl0IG9yIG5vdC48QlI+PC9ESVY+CjxESVY+Jm5ic3A7 PC9ESVY+CjxESVY+UmVnYXJkcyw8QlI+PC9ESVY+CjxESVY+TGluaHVpPEJSPjwvRElWPgo8QkxP Q0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBN QVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCI+CjxESVY+CjxESVY+ Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Q2hlZXJzPEJSPjwvRElWPgo8RElW Pgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4KPERJViBk aXI9Imx0ciI+CjxESVY+CjxESVY+CjxESVY+T24gV2VkLCBEZWMgMiwgMjAxNSBhdCAxMToyOCBB TSwgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPFNQQU4gZGlyPSJsdHIiPiZsdDs8QSBocmVmPSJt YWlsdG86aWV0ZkBodWdvLmxhYmtvZGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBodWdvLmxh YmtvZGUuY29tPC9BPiZndDs8L1NQQU4+IHdyb3RlOjxCUj48L0RJVj4KPEJMT0NLUVVPVEUgc3R5 bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHgg MHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiPgo8RElWPjxVPjwvVT48QlI+PC9ESVY+ CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9E SVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+T24gV2VkLCBEZWMgMiwgMjAxNSwgYXQg MTE6MTggQU0sIExpbmh1aSBTdW4gd3JvdGU6PC9TUEFOPjxCUj48L0RJVj4KPEJMT0NLUVVPVEUg dHlwZT0iY2l0ZSI+CjxESVY+PFNQQU4+SGk8L1NQQU4+PEJSPjwvRElWPgo8RElWPiZuYnNwOzwv RElWPgo8RElWPgo8RElWIHN0eWxlPSJDT0xPUjogcmdiKDAsMCwwKSI+CjxESVY+PFNQQU4+T24g 5ZGo5LiJLCAxMuaciCAyLCAyMDE1IGF0IDE3OjU2LCBIdWdvIEdvbnrDoWxleiBMYWJyYWRvciAm bHQ7PEEgaHJlZj0ibWFpbHRvOmlldGZAaHVnby5sYWJrb2RlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmlldGZAaHVnby5sYWJrb2RlLmNvbTwvQT4mZ3Q7IHdyb3RlOjwvU1BBTj48QlI+PC9ESVY+CjxE SVYgc3R5bGU9Ik9WRVJGTE9XLVg6IHZpc2libGU7IE9WRVJGTE9XLVk6IHZpc2libGUiPgo8QkxP Q0tRVU9URSBzdHlsZT0iQ09MT1I6IHJnYig0OCw1OSw2NCkiPgo8RElWPgo8RElWPiZuYnNwOzwv RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPk9uIFdl ZCwgRGVjIDIsIDIwMTUsIGF0IDA4OjIwIEFNLCBMaW5odWkgU3VuIHdyb3RlOjwvU1BBTj48QlI+ PC9ESVY+CjxCTE9DS1FVT1RFPgo8RElWIGRpcj0ibHRyIj4KPERJVj48U1BBTj5IaTwvU1BBTj48 QlI+PC9ESVY+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+CjxESVY+PFNQQU4+MjAxNS0x Mi0wMiA1OjE0IEdNVCswODowMCBIdWdvIEdvbnrDoWxleiBMYWJyYWRvciA8U1BBTiBkaXI9Imx0 ciI+Jmx0OzxBIGhyZWY9Im1haWx0bzppZXRmQGh1Z28ubGFia29kZS5jb20iIHRhcmdldD0iX2Js YW5rIj5pZXRmQGh1Z28ubGFia29kZS5jb208L0E+Jmd0OzwvU1BBTj46PC9TUEFOPjxCUj48L0RJ Vj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBz b2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiPgo8RElW PjxTUEFOPkhpLDwvU1BBTj48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+ ZnJvbSBteSBwb2ludCBvZiB2aWV3IHRoZSByZW1vdGVTdG9yYWdlIHByb2plY3QgYWRkcmVzc2Vz IGEgc3Vic2V0IG9mPC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj50aGUgdXNlIGNhc2VzIG9m IHRoZSZuYnNwOyBXZWJEQVYgc3BlY2lmaWNhdGlvbi48L1NQQU4+PEJSPjwvRElWPgo8RElWPiZu YnNwOzwvRElWPgo8RElWPjxTUEFOPlRoZSBtYWluIGRpZmZlcmVuY2UgSSBjYW4gb2JzZXJ2ZSBp cyB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIGlzIGJ1aWx0IG9uPC9TUEFOPjxCUj48L0RJVj4KPERJ Vj48U1BBTj5SRVNUIGluc3RlYWQgb2YgWE1MLWJhc2VkIGNvbW11bmljYXRpb24uPC9TUEFOPjxC Uj48L0RJVj48L0JMT0NLUVVPVEU+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdi KDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJ TkctTEVGVDogMWV4Ij4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5JIHBlcnNvbmFsbHkg bGlrZSBtdWNoIG1vcmUgUkVTVCB0aGFuIFdlYkRBViBiZWNhdXNlIGl0IGlzIG1vcmU8L1NQQU4+ PEJSPjwvRElWPgo8RElWPjxTUEFOPmRldmVsb3BlciBmcmllbmRseSBhbmQgaXQgaXMgZmFzdGVy IHRvIGRldmVsb3AuPC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj4mbmJzcDtNYXliZSB0aGUg cmVtb3RlU3RvcmFnZSBBUEkgYmVjb21lcyB0aGUgbmV4dCBXZWJEQVYgOik8L1NQQU4+PEJSPjwv RElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPkhvd2V2ZXIsIHRoZSByZW1vdGVTdG9y YWdlIEFQSSBkb2VzIG5vdCBwcm92aWRlIGEgd2F5IG9mIHN5bmNocm9uaXNpbmc8L1NQQU4+PEJS PjwvRElWPgo8RElWPjxTUEFOPmRhdGEsIHRoaXMgdGFzayBpcyBkZWxlZ2F0ZWQgdG8gdGhlIGRl dmVsb3BlcnMuPC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj5JcyB0aGVyZSBhIHBsYW4gdG8g cHJvdmlkZSBzdWNoIGZlYXR1cmUgYmFzZWQgb24gdGhlIG91dGNvbWUgb2YgdGhpczwvU1BBTj48 QlI+PC9ESVY+CjxESVY+PFNQQU4+ZHJhZnQ/PC9TUEFOPjxCUj48L0RJVj48L0JMT0NLUVVPVEU+ CjxESVY+PFNQQU4+SSdtIGEgbGl0dGxlIGJpdCBjb25mdXNlZCB3aHkgeW91IHNheSB0aGUgcmVt b3RlU3RvcmFnZSBkb2VzIG5vdCBwcm92aWRlIHRoYXQuIElzIHRoYXQgYmVjYXVzZSByZW1vdGVT dG9yYWdlIGRvZXMgbm90IHBlcmZvcm0gbGlrZSBhIHR5cGljYWwgc3luYyBzZXJ2aWNlcyAoZS5n LiBkcm9wYm94Li4uKSBvciB5b3UgYXJlIHNheWluZyBzb21ldGhpbmcgZWxzZT88L1NQQU4+PEJS PjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj48U1BBTj5ZZXMsIGJl Y2F1c2UgaXQgZG9lcyBub3Qgb2ZmZXIgc3luY2hyb25pc2F0aW9uIGNhcGFiaWxpdGllcy48L1NQ QU4+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj48U1BBTj5Hb3QgaXQuIEFuZCBX aGF0IEkgYW0gd29uZGVyaW5nIGlzIHRoYXQgZG8gd2UgbmVlZCB0byBpbmNsdWRlIHRob3NlIGNh cGFiaWxpdGllcyBpbiBhIGJhc2Ugc3BlY2lmaWNhdGlvbnMuIFNpbmNlIGl0IGlzIGhhcmQgdG8g c3RhbmRhcmRpemUgdGhlIGNhcGFiaWxpdGllcyBsaWtlIGRlZHVwIG9yIGRlbHRhLiBNYXliZSBh IGJldHRlciB3YXkgaXMgdG8gZGVmaW5lIHRob3NlIGluIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlv biwgPC9TUEFOPjxCUj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+ Jm5ic3A7PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8 RElWPlRoYW5rcyBmb3IgZ2l2aW5nIHRoZXNlIGV4YW1wbGVzIC0gc28gYnkgJ3N5bmNocm9uaXNh dGlvbiBjYXBhYmlsaXRpZXMnIHlvdSBtZWFuIDEpIGRlZHVwbGljYXRpb24gYW5kIDIpIGRlbHRh IHVwZGF0ZXM/IEFueXRoaW5nIGVsc2Ugb3IgaXMgdGhhdCBhbiBleGhhdXN0aXZlIGxpc3Q/IDxC Uj48L0RJVj48L0RJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIw NCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZU OiAxZXgiPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4K PERJVj4KPERJViBzdHlsZT0iQ09MT1I6IHJnYigwLDAsMCkiPgo8RElWIHN0eWxlPSJPVkVSRkxP Vy1YOiB2aXNpYmxlOyBPVkVSRkxPVy1ZOiB2aXNpYmxlIj4KPERJVj48U1BBTj5zb21ldGhpbmcg bGlrZSBleHRlbnNpb25zLiBGb3IgYSBiYXNlIGRvY3VtZW50LCB3ZSBqdXN0IG5lZWQgdG8gZGVm aW5lIGhvdyB0byBwZXJmb3JtIHN5bmMgb3BlcmF0aW9ucy48L1NQQU4+PEJSPjwvRElWPjwvRElW PjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8 L0RJVj4KPERJVj5ZZXMsIEkgYWdyZWUgdGhhdCBtYXkgYmUgYW4gZXh0ZW5zaW9uIG9mIHRoaXMg ZHJhZnQgY291bGQgaGFuZGxlIHRoZSBzeW5jaHJvbmlzYXRpb24gcGFydC4gPEJSPjwvRElWPgo8 RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPjwvRElW PjwvQkxPQ0tRVU9URT4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4KPERJVj5PdXIgSW50ZXJuZXQt RHJhZnQgaXMgaGVhdmlseSBmb2N1c2VkIG9uIHRoZSB3b3JsZCB3aWRlIHdlYiwgd2hvc2UgVVJM cyBhcmUgbm90IGNvbnRlbnQtYWRkcmVzc2FibGUsIHdlIGNhbid0IGNoYW5nZSB0aGF0LiBTbyB0 aGF0IGFyY2hpdGVjdHVyZSBpcyBub3QgdmVyeSBmcmllbmRseSB0byBkZWR1cGxpY2F0aW9uLCBj b21wYXJlZCB0byBmb3IgaW5zdGFuY2UgQml0VG9ycmVudC4gQXMgeW91IGFscmVhZHkgc2FpZCwg ZGV2ZWxvcGVycyBjYW4gc3RpbGwgZGVkdXBlIG9uIHRoZSBzZXJ2ZXItc2lkZSB3aGVuIHN0b3Jp bmcgYmxvYnMgdG8gZGlzaywgYW5kIGNhbiBhbHNvIGRlZHVwZSBvbiB0aGUgY2xpZW50IHNpZGUg YmVmb3JlIGNyZWF0aW5nIHRoZSByZXNvdXJjZXMgdGhlIGNsaWVudCB1cGxvYWRzLjxCUj48L0RJ Vj48L0RJVj4KPERJVj4KPERJVj5BcyBmYXIgYXMgSSBrbm93LCBkZWx0YSB1cGRhdGVzIGFyZSBu b3Qgc3VwcG9ydGVkIGJ5IHRoZSBFVGFnIHN5c3RlbSAtIHlvdSBjYW5ub3QgZG8gYSByYW5nZSBy ZXF1ZXN0IHRvIGZpbmQgb3V0IGlmIGNlcnRhaW4gYnl0ZXMgd2l0aGluIGEgZG9jdW1lbnQgaGF2 ZSBjaGFuZ2VkLiBIb3dldmVyLCB0aGUgZm9sZGVyIHN5c3RlbSB3ZSBkZWZpbmUgZG9lcyBlbmNv dXJhZ2UgeW91LCBmb3IgaW5zdGFuY2Ugd2hlbiB5b3UgZGV2ZWxvcCBhIFRvIERvIExpc3QgYXBw LCBwdXQgZWFjaCB0YXNrIG9uIGl0cyBvd24gZG9jdW1lbnQsIGFuZCB0aGVuIHF1ZXJ5IHRoZSBm b2xkZXIgdG8gc2VlIHdoaWNoIG9mIHRoZW0gY2hhbmdlZCwgaW5zdGVhZCBvZiBwdXR0aW5nIHRo ZW0gYWxsIGluIG9uZSBiaWcgZG9jdW1lbnQgYW5kIHJldHJpZXZpbmcgdGhlIHdob2xlIGRvY3Vt ZW50IGVhY2ggdGltZS48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+PC9ESVY+CjxESVY+Q2hl ZXJzLDxCUj48L0RJVj4KPERJVj5NaWNoaWVsLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4K PEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xp ZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiPgo8RElWPgo8 RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4KPERJVj4KPERJViBzdHls ZT0iQ09MT1I6IHJnYigwLDAsMCkiPgo8RElWIHN0eWxlPSJPVkVSRkxPVy1YOiB2aXNpYmxlOyBP VkVSRkxPVy1ZOiB2aXNpYmxlIj4KPEJMT0NLUVVPVEUgc3R5bGU9IkNPTE9SOiByZ2IoNDgsNTks NjQpIj4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEU+CjxESVYgZGlyPSJsdHIi Pgo8RElWPgo8RElWPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0 LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6 IDFleCI+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+QlRXLCBJIHdhbnQgdG8gaW50cm9k dWNlIENsYXdJTyAoPEEgaHJlZj0iaHR0cDovL2NsYXdpby5naXRodWIuaW8vIiB0YXJnZXQ9Il9i bGFuayI+PC9BPjxBIGhyZWY9Imh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvLyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvPC9BPiksIGEgcmVzZWFyY2g8L1NQQU4+PEJSPjwv RElWPgo8RElWPjxTUEFOPnByb2plY3QgdG8gYmVuY2htYXJrIGRpZmZlcmVudCBzeW5jaHJvbmlz YXRpb24gcHJvdG9jb2xzIGFnYWluc3Q8L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPmRpZmZl cmVudCBkYXRhIGJhY2tlbmRzIHdpdGggc3BlY2lhbCBhdHRlbnRpb24gdG8gcHJvdmlkZSBhIGNv bW1vbiBzeW5jPC9TUEFOPjxCUj48L0RJVj4KPERJVj48U1BBTj5BUEkuPC9TUEFOPjxCUj48L0RJ Vj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5BIGNvbW1vbiBBUEkgZm9yIGRpZmZlcmVu dCBzeW5jIHByb3RvY29scyBpcyBiZWluZyBjcmVhdGVkIGJhc2VkIG9uIHRoZTwvU1BBTj48QlI+ PC9ESVY+CjxESVY+PFNQQU4+YXJjaGl0ZWN0dXJlIHNwZWNpZmllZCBpbiB0aGlzIGRyYWZ0IChj b250cm9sIGFuZCBkYXRhIHNlcnZlcnMpIGFuZCB0aGU8L1NQQU4+PEJSPjwvRElWPjwvQkxPQ0tR VU9URT4KPERJVj48U1BBTj5JIGNhbm5vdCBmaW5kIGEgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0dXJl IGluIHRoaXMgZHJhZnQuIEl0IHNlZW1zIHRoYXQgdGhleSBoYW5kbGUgbWV0YWRhdGEgYW5kIGNv bnRlbnQgZGF0YSB0b2dldGhlciwganVzdCBsaWtlIGEgbm9ybWFsIHdlYiBzZXJ2aWNlLjwvU1BB Tj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPiZuYnNwOzwv RElWPgo8RElWPjxTUEFOPkNsYXdJTyBpcyBmdWxseSBkaXN0cmlidXRlZC4gRXZlcnkgbG9naWNh bCB1bml0IGlzIGEgZGlmZmVyZW50IHNlcnZlciB0aGFuIGJlIHNjYWxlZCBvdXQuIERhdGEgYW5k IE1ldGFkYXRhIGNoYW5uZWxzIGFyZSBpbmRlcGVuZGVudCBmcm9tIGVhY2ggb3RoZXIgYW5kIHJl c2lkZSBvbiBkaWZmZXJlbnQgc2VydmVycy48L1NQQU4+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tR VU9URT4KPERJVj48U1BBTj5UaGF0IGlzIHdpZGVseSBlbXBsb3llZCBpbiBwb3B1bGFyIHN5bmMg c2VydmljZXMuIEFuZCB0aGF0IGlzIGFsc28gYmVuZWZpY2lhbCB0byBwcml2YWN5IHRvIHNvbWUg ZXh0ZW50LiBCdXQgaW4gdGhlIGNvbnRleHQgb2Ygc3luYyBpbiBicm93c2VyICh3aGljaCBpcyBt YWlubHkgY29uc2lkZXJlZCBpbiB0aGUgcmVtb3RlU3RvcmFnZSksIEkgZG9uJ3Qga25vdyB3aGV0 aGVyIHRoaXMgaXMgcmVhc29uYWJsZS4gQnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGRlcGxveSBkaXN0 cmlidXRlZCBhcmNoaXRlY3R1cmUgYWx0aG91Z2ggaXQgd2lsbCBtYWtlIHRoaW5ncyBjb21wbGlj YXRlZC48L1NQQU4+PEJSPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJ Vj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5PZiBjb3Vyc2UsIHRoZSByZW1v dGVTdG9yYWdlIGlzIHRhcmdldGVkIHRvIGJyb3dzZXJzLCBzbyBzeW5jaW5nIGRvZXMgbm90IG1h a2UgdG9vIG11Y2ggc2Vuc2UgaW4gdGhpcyBjYXNlLjxCUj48L0RJVj4KPERJVj5XaXRoIHRoZSBy aXNlIG9mIExpbnV4IGNvbnRhaW5lciBtaWNyby1zZXJ2aWNlIGJhc2VkIGFyY2hpdGVjdHVyZXMs IHRoZSBkZXBsb3ltZW50IG9mICZuYnNwO3N1Y2ggaGlnaGx5IGNvbXBsZXggc3lzdGVtcyBzaG91 bGQgYmVjb21lIGVhc2llciBhbmQgZmFzdGVyLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4K PERJVj5CZXN0LDxTUEFOPjxTUEFOIHN0eWxlPSJDT0xPUjogcmdiKDEzNiwxMzYsMTM2KSI+PC9T UEFOPjwvU1BBTj48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+ CjxESVY+PFNQQU4+PFNQQU4gc3R5bGU9IkNPTE9SOiByZ2IoMTM2LDEzNiwxMzYpIj5IdWdvPC9T UEFOPjwvU1BBTj48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+CjxESVY+CjxESVY+ Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8RElWPgo8RElWIHN0eWxlPSJD T0xPUjogcmdiKDAsMCwwKSI+CjxESVYgc3R5bGU9Ik9WRVJGTE9XLVg6IHZpc2libGU7IE9WRVJG TE9XLVk6IHZpc2libGUiPgo8RElWPlJlZ2FyZHMsPEJSPjwvRElWPgo8RElWPkxpbmh1aSZuYnNw OzxCUj48L0RJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkNPTE9SOiByZ2IoNDgsNTksNjQpIj4KPERJ Vj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPEJMT0NLUVVPVEU+CjxESVYg ZGlyPSJsdHIiPgo8RElWPgo8RElWPgo8RElWPlJlZ2FyZHMsPEJSPjwvRElWPgo8RElWPkxpbmh1 aTxCUj48L0RJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwy MDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAx ZXgiPgo8RElWPm9uZSBmcm9tIHRoZSBDRVJOIEVPUyBwcm9qZWN0IChtYW5hZ2VtZW50LCBkaXNr IGFuZCBxdWV1ZSBzZXJ2ZXJzKS48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+VGhl IFBoYXNlIEkgaGFzIGltcGxlbWVudGVkIHRoZSBvd25DbG91ZCBTeW5jIFByb3RvY29sIGFuZCBQ aGFzZSBJSSB3aWxsPEJSPjwvRElWPgo8RElWPmltcGxlbWVudCB0aGUgU2VhRmlsZSBTeW5jIFBy b3RvY29sLjxCUj48L0RJVj4KPERJVj5UaGUgY2hvaWNlIG9mIHRoZXNlIHByb3RvY29scyBhbW9u ZyBvdGhlcnMgaXMgYmVjYXVzZSB0aGV5IGFyZSByZWFsbHk8QlI+PC9ESVY+CjxESVY+b3Bwb3Nl ZCB0byBlYWNoIG90aGVyIGluIHRlcm1zIG9mIHN5bmNpbmcgKGRlbHRhIHZzIG5vbi1kZWx0YSw8 QlI+PC9ESVY+CjxESVY+c3RhdGUtYmFzZWQgdnMgbG9nL2V2ZW50L2dpdC1iYXNlZCBzeW5jIOKA piksIHNvIGZpbmRpbmcgYSBjb21tb24gYXBwcm9hY2g8QlI+PC9ESVY+CjxESVY+aXMgbW9yZSBj aGFsbGVuZ2luZy48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+UHJvdmlkaW5nIGEg YmFzZSBzcGVjaWZpY2F0aW9uL2FyY2hpdGVjdHVyZSB0byBtZWFzdXJlIHRoZSBmZWFzaWJpbGl0 eTxCUj48L0RJVj4KPERJVj5vZiB0aGlzIGRyYWZ0IGlzIG9uZSBvZiB0aGUgb2JqZWN0aXZlcyBv ZiB0aGUgcHJvamVjdC48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SSBiZWxpZXZl IHRoYXQgdGhlIHdvcmsgYmVpbmcgZG9uZSBoZXJlIGFuZCBpbiBDbGF3SU8gYXJlIHN1cHBsZW1l bnRhcnk8QlI+PC9ESVY+CjxESVY+dG8gZWFjaCBvdGhlciBhbmQgSSB0aGluayBtdXR1YWwgY29s bGFib3JhdGlvbiBjb3VsZCBiZSBiZW5lZmljaWFsIGZvcjxCUj48L0RJVj4KPERJVj5ib3RoIHNp ZGVzLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5BbHNvLCBpZiB0aGVyZSBpcyBp bnRlcmVzdCwgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGNhbiBiZSBhZGRlZCB0bzxCUj48L0RJVj4K PERJVj5DbGF3SU8uPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkJlc3QgcmVnYXJk cyw8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SHVnbyBHb256YWxleiBMYWJyYWRv cjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5PbiBUdWUsIERlYyAxLCAyMDE1LCBh dCAwOTowMCBQTSwgPEEgaHJlZj0ibWFpbHRvOnN0b3JhZ2VzeW5jLXJlcXVlc3RAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnPC9BPiB3cm90ZTo8 QlI+PC9ESVY+CjxESVY+Jmd0OyBTZW5kIFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBzdWJtaXNz aW9ucyB0bzxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PEEg aHJlZj0ibWFpbHRvOnN0b3JhZ2VzeW5jQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3RvcmFn ZXN5bmNAaWV0Zi5vcmc8L0E+PEJSPjwvRElWPgo8RElWPiZndDs8QlI+PC9ESVY+CjxESVY+Jmd0 OyBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlz aXQ8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxBIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMiIHRhcmdl dD0iX2JsYW5rIj48L0E+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zdG9yYWdlc3luYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmM8L0E+PEJSPjwvRElWPgo8RElWPiZndDsgb3IsIHZp YSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvPEJS PjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8QSBocmVmPSJtYWls dG86c3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnN0b3JhZ2Vz eW5jLXJlcXVlc3RAaWV0Zi5vcmc8L0E+PEJSPjwvRElWPgo8RElWPiZndDs8QlI+PC9ESVY+CjxE SVY+Jmd0OyBZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQ8QlI+ PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxBIGhyZWY9Im1haWx0 bzpzdG9yYWdlc3luYy1vd25lckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnN0b3JhZ2VzeW5j LW93bmVyQGlldGYub3JnPC9BPjxCUj48L0RJVj4KPERJVj4mZ3Q7PEJSPjwvRElWPgo8RElWPiZn dDsgV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMg bW9yZSBzcGVjaWZpYzxCUj48L0RJVj4KPERJVj4mZ3Q7IHRoYW4gIlJlOiBDb250ZW50cyBvZiBT dG9yYWdlc3luYyBkaWdlc3QuLi4iPEJSPjwvRElWPgo8RElWPiZndDsgVG9kYXkncyBUb3BpY3M6 PEJSPjwvRElWPgo8RElWPiZndDs8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgMS4g TmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UmbmJzcDsgJm5ic3A7IElu dGVybmV0LURyYWZ0PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDthdmFpbGFibGUgKE1pY2hpZWwgZGUgSm9uZyk8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAm bmJzcDsgMi4gUmU6IE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlIElu dGVybmV0LURyYWZ0PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDthdmFpbGFibGUgKEdpaGFuIERpYXMpPEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7 IDMuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5l dC1EcmFmdDxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXZh aWxhYmxlIChGZWkgU29uZyk8QlI+PC9ESVY+CjxESVY+Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj48L0RJVj4KPERJVj4mZ3Q7IFN0b3JhZ2Vz eW5jIG1haWxpbmcgbGlzdDxCUj48L0RJVj4KPERJVj4mZ3Q7IDxBIGhyZWY9Im1haWx0bzpTdG9y YWdlc3luY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlN0b3JhZ2VzeW5jQGlldGYub3JnPC9B PjxCUj48L0RJVj4KPERJVj4mZ3Q7IDxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3RvcmFnZXN5bmMiIHRhcmdldD0iX2JsYW5rIj48L0E+PEEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmM8 L0E+PEJSPjwvRElWPgo8RElWPiZndDsgRW1haWwgaGFkIDMgYXR0YWNobWVudHM6PEJSPjwvRElW Pgo8RElWPiZndDsgKyBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1y ZW1vdGVzdG9yYWdlPEJSPjwvRElWPgo8RElWPiZndDsgSW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxl PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7MmsgKG1lc3NhZ2UvcmZjODIyKTxCUj48 L0RJVj4KPERJVj4mZ3Q7ICsgUmU6IFtTdG9yYWdlc3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQt ZGVqb25nLXJlbW90ZXN0b3JhZ2U8QlI+PC9ESVY+CjxESVY+Jmd0OyBJbnRlcm5ldC1EcmFmdCBh dmFpbGFibGU8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsxayAobWVzc2FnZS9yZmM4 MjIpPEJSPjwvRElWPgo8RElWPiZndDsgKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBv ZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZTxCUj48L0RJVj4KPERJVj4mZ3Q7IEludGVybmV0 LURyYWZ0IGF2YWlsYWJsZTxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOzJrIChtZXNz YWdlL3JmYzgyMik8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+PC9ESVY+CjxESVY+U3RvcmFn ZXN5bmMgbWFpbGluZyBsaXN0PEJSPjwvRElWPgo8RElWPjxBIGhyZWY9Im1haWx0bzpTdG9yYWdl c3luY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlN0b3JhZ2VzeW5jQGlldGYub3JnPC9BPjxC Uj48L0RJVj4KPERJVj48QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N0b3JhZ2VzeW5jIiB0YXJnZXQ9Il9ibGFuayI+PC9BPjxBIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jPC9BPjxCUj48 L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPiZu YnNwOzwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVP VEU+CjxESVY+Jm5ic3A7PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElW PjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj4mbmJzcDs8L0RJVj48L0RJVj48L0RJVj48 L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPiZu YnNwOzwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9ESVY+ PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjxCUj48L0RJVj48L0RJVj48L0RJVj48L0JM T0NLUVVPVEU+PC9ESVY+PC9ESVY+PC9ESVY+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48 L0RJVj48QlI+PC9ESVY+PC9CTE9DS1FVT1RFPg== ------=_Part_41404_1089348070.1449132248276-- From nobody Thu Dec 3 00:59:59 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F0B1B32DF for ; Thu, 3 Dec 2015 00:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTZ0SJdYlu46 for ; Thu, 3 Dec 2015 00:59:55 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68BA61B32E0 for ; Thu, 3 Dec 2015 00:59:54 -0800 (PST) Received: by wmvv187 with SMTP id v187so16275761wmv.1 for ; Thu, 03 Dec 2015 00:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kptdVh/newYpeLucBWdMjEWIh0FSQKLkSMyzjIaxZvY=; b=cr3nRwVOm6Ckg11aIe574jYhceWXRSKDnCtLMzue48q/IVuTSG4Yff83Ai+rib85Gu Y3gF29L44UpSsq3ERN3lmPtxBOFYy5TL0o3FdT5emSGLVMNmZHVuHnFvaJF8itAgPrMZ 35TFzFlNzjrEdfiurj9e2Ejzn+HLxa9Gm7MJ7oUUTIro+wJSNA+FwjJbZd0M11x7meiu ZXH+4XwKropF0m+tdNbD+Qp9CNU4sLOI+3yU24nIDhN2dxxWShHFtH1PIvU9vcd5YCDs OxuvIABsnXfZg9v5ctm19Cga8yHIVCm6CDLUcqTe9GHevjMFYXJJBj6FK6fRuhyGVpM/ Op3A== X-Received: by 10.194.172.2 with SMTP id ay2mr6898102wjc.137.1449133193049; Thu, 03 Dec 2015 00:59:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Thu, 3 Dec 2015 00:59:33 -0800 (PST) In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> From: Linhui Sun Date: Thu, 3 Dec 2015 16:59:33 +0800 Message-ID: To: fsong Content-Type: multipart/alternative; boundary=089e013c6214343c350525fa9d86 Archived-At: Cc: storagesync , fkooman , Michiel de Jong , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 08:59:57 -0000 --089e013c6214343c350525fa9d86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-12-03 16:40 GMT+08:00 : > Hi Michael, > > > > Based on the description on *http://remotestorage.io/* > =E2=80=9CremoteStorage-enabled apps automatica= lly sync > your data across all of your devices=E2=80=9D. > > > > However, there is no synchronization in the abstract. > > =E2=80=9CThe protocol supports storing, retrieving, and removing individu= al > documents, as well as listing the contents of an individual folder, and > access control is based on bearer tokens=E2=80=9D > > > > Therefore, I think: > > If synchronization is added into abstract, the MOVE action should be adde= d > for sure. > > If synchronization is not included, like current version, the basic > actions in draft are enough. > I don't know why MOVE should be tied to the =E2=80=9Csynchronization=E2=80= =9D. It seems that only sync allows MOVE to be used. Regards, Linhui --089e013c6214343c350525fa9d86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-03 16:40 GMT+08:00 <fsong@bjtu.edu.cn>:

Hi Michael,

<= font face=3D"Calibri">=C2=A0

Based on the description on h= ttp://remotestorage.io/ =E2=80=9Cremo= teStorage-enabled apps automatically sync your data across all of your devi= ces=E2=80=9D.

<= font face=3D"Calibri">=C2=A0

However, there is no synchronization in the abstract.

=E2=80=9CThe protocol supports storing, retrieving, and remo= ving individual documents, as well as listing the contents of an individual= folder, and access control is based on bearer tokens=E2=80=9D

<= font face=3D"Calibri">=C2=A0

Therefore, I think:

If synchronization is added into abstract, the MOVE action s= hould be added for sure.

If synchronization is not included, like current version, th= e basic actions in draft are enough.

I d= on't know why MOVE should be tied to the =E2=80=9Csynchronization=E2=80= =9D. It seems that only sync allows MOVE to be used.

Regards,
Linhui
--089e013c6214343c350525fa9d86-- From nobody Thu Dec 3 01:01:45 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20D41B32EB for ; Thu, 3 Dec 2015 01:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2Zkhr8cHLPQ for ; Thu, 3 Dec 2015 01:01:34 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B9B1B32E7 for ; Thu, 3 Dec 2015 01:01:34 -0800 (PST) Received: by iouu10 with SMTP id u10so75821828iou.0 for ; Thu, 03 Dec 2015 01:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lit8k2x3eALBbCx5AGfp6hHvUZ27XVF2mZa0nfMQHKs=; b=gtLauDwyeXbKsIt+W/+pbNOkHt2ItScZ6nA5SVuQp4Zu7tukTug1e2BwMLjL5mixMr J4WU6upU1J0HnHEFF/lqeEt1DOMkbfOkvm9G/XQqj+r72Oxq9ssI5jpg8YFXVFrVaKoC t67tDq4ilPx5agCRvKI2yH/edcyGlbrjQDOIv9/dSeSeg2uFLILySDN5QxL2Vw+XFU+9 NrMzIzVXC/DrZ3fdIHlrT8AKEVsjkT1/cIWiZ5L7ics8ULIbWT3a0ga6NTjmYFOiFZHe iOofJvpA2JxQi20pEz9VZHsVJifSoEepI/fu64JuQk3VrnK39u0lUmRVrtv4+OYtFDqD Nl7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lit8k2x3eALBbCx5AGfp6hHvUZ27XVF2mZa0nfMQHKs=; b=gqfVoLdJ5vUYhL1HswQS+gbYC0YoBDYh3h4zAM0rMj0VJX46mnURvE96eoTlA3Zxm7 cZaFGKh+ijUgIcgMk2Libp6bHzer7EXG3qaO4RR7923H8648MWHvEV8e7k5cOo1uooXm aU/ckiP8asFg/1OnoVVb55HBzEJbAEPa+Fsho4+wffswso9cFGiUSVsFSwOLfnW7HS+3 HjaDrSdErGYBWn9MuEKoz4Xujt5kjLrh4HuiXnW9jA31id+QhUqR/0HobRfoSCwDNY0q sBSwuM3bAfiRUSmxq3FwHePjJmKpzDF6/Rc3c+5VHbN6T2UL5HvJLs/9bUFo52dd7q8V EkZA== X-Gm-Message-State: ALoCoQkYLDxVEu8UIzg19eV9ItGdpjYFLqWdO9FYgCUtUafqTQiz0usFbv2zEGNkzvxCCEVNND8W MIME-Version: 1.0 X-Received: by 10.107.129.82 with SMTP id c79mr8236409iod.95.1449133293367; Thu, 03 Dec 2015 01:01:33 -0800 (PST) Received: by 10.107.137.68 with HTTP; Thu, 3 Dec 2015 01:01:33 -0800 (PST) In-Reply-To: <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> Date: Thu, 3 Dec 2015 10:01:33 +0100 Message-ID: From: Michiel de Jong To: fsong@bjtu.edu.cn Content-Type: multipart/alternative; boundary=001a113f9b762f0e320525faa34f Archived-At: Cc: Linhui Sun , storagesync , fkooman , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:01:40 -0000 --001a113f9b762f0e320525faa34f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes! I'll discuss with Francois how we can make these boundaries clearer. Maybe we can split along these lines: * upload/manipulate/query/download protocol (e.g. WebDAV or the GET/PUT/DELETE operations we currently define) * CORS or other cross-origin access mechanism, OAUTH or other auth mechanism, WebFinger or other discovery mechanism, ETag or other versioning mechanism * chunking/deduping/delta-updates And the remoteStorage spec should probably only define the middle part. On Thu, Dec 3, 2015 at 9:44 AM, wrote: > Hi Michiel and Linhui, > > I think it will be good to have a boundary for this draft and leave some > work for the applicaiton layer~ > > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* "Michiel de Jong" > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2015=E5=B9=B412=E6=9C=882=E6=97= =A5 =E6=98=9F=E6=9C=9F=E4=B8=89 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* "Linhui Sun" > *=E6=8A=84=E9=80=81:* storagesync , fkooman , > "Hugo Gonz=C3=A1lez Labrador" > *=E4=B8=BB=E9=A2=98:* Re: [Storagesync] Storagesync Digest, Vol 5, Issue = 1 > > Ah sure, that's entirely appropriate, remoteStorage treats both the > Content-Type header value and the actual body of a document as opaque > strings of bytes. It doesn't "care" if you use it to store only data bloc= ks > that are chunks of something else. > > For instance, you could have a folder on a user's storage that contains > only inode-like JSON-documents, which list the URLs of binary documents > that make up 1Kb blocks of the actual data. Nice for deduping, delta > updates, and also renaming files without reuploading their content. > > But yeah, the argument is that *how* to create and manage these chunks, i= s > then still left up to the application developer (or to another spec on to= p > of the remoteStorage spec). > > > Cheers, > Michiel. > > On Wed, Dec 2, 2015 at 3:29 PM, Linhui Sun wrote: > >> Hi >> >> 2015-12-02 22:05 GMT+08:00 Michiel de Jong : >> >>> Cool! I created https://github.com/remotestorage/spec/issues/137 about >>> the need for MOVE verb. >>> >>> Application-level chunking is partially supported by HTTP itself throug= h >>> `Content-Range` headers (although it's not clear whether these are allo= wed >>> on PUT requests as well as on GET requests, see >>> https://github.com/remotestorage/spec/issues/131). The problem is that >>> HTTP defines versioning at the document level, you cannot ask a server = to >>> produce or check an ETag for a specific byte-range of a document, only = for >>> the entire document. >>> >> Actually what I'm saying is a chunking before transmitting (using http), >> in this way, they are treated as individual documents from the standpoin= t >> of http. But I don't know whether this is appropriate for remoteStorage, >> just a comment. >> >> Regards, >> Linhui >> >>> >>> A comparison document sounds good! See also >>> http://www.servicedenuages.fr/en/generic-storage-ecosystem. >>> >>> >>> Cheers, >>> Michiel. >>> >>> >>> On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun wrote= : >>> >>>> That's cool for me, a separate section for this might make sense. >>>> >>>> Another thing is do we need to include an application-layer chunking >>>> here (not just for a browser sync), since if we want to further extend >>>> other capabilities it is essential. >>>> >>>> Regards, >>>> Linhui >>>> >>>> 2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador < >>>> ietf@hugo.labkode.com>: >>>> >>>>> I propose to come up with a list of advantages and disadvantages of >>>>> using WebDAV and compare them against a JSON/REST based approach, lik= e >>>>> remoteStorage. >>>>> >>>>> Does it sound good ? >>>>> >>>>> >>>>> On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: >>>>> >>>>> >>>>> >>>>> 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador < >>>>> ietf@hugo.labkode.com>: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: >>>>> >>>>> Hi all! >>>>> Thanks for all your reactions to the remoteStorage Internet-Draft. >>>>> >>>>> We get the question about WebDAV a lot, in the next version we should >>>>> add a remark about it in the intro. The folder descriptions returned = when >>>>> you GET a URL that ends with a / are indeed a deviation from the XML >>>>> returned by WebDAV server, and this is just because nowadays JSON is = easier >>>>> to use than XML for developers, both client-side and server-side. >>>>> >>>>> >>>>> >>>>> I totally agree here, this was going to happen soon or later and it i= s >>>>> really appreciated. >>>>> >>>>> >>>>> >>>>> The fact that we don't require servers to support WebDAV's custom >>>>> verbs like PROPPATCH etc. is for three reasons: >>>>> 1) it's a lot of work to implement this without using an existing >>>>> WebDAV library >>>>> 2) in practice, a lot of WebDAV servers get it wrong, or don't >>>>> implement all of WebDAV. It's very annoying for client implementers t= o have >>>>> to deal with servers that e.g. chose not to implement LOCK and UNLOCK= . >>>>> 3) we don't really need all these advanced features on top of standar= d >>>>> HTTP, just supporting GET/PUT/DELETE for resources, and adding a simp= le >>>>> folder description format, is enough for most applications. >>>>> >>>>> Other than that, the remoteStorage Internet-Draft specifies a *lot* >>>>> more than just how each HTTP verb should behave: >>>>> * requiring support for OAuth implicit-grant flow >>>>> * requiring ETag support and nested versioning (i.e. the folder's ETa= g >>>>> changes if anything within that folder changes) >>>>> * requiring CORS headers >>>>> * requiring a WebFinger announcement for service discovery >>>>> It would be easy to add these three things on top of WebDAV, instead >>>>> of putting them on top of our minimal GET/PUT/DELETE API definition. = In >>>>> fact, we could probably separate it into two Internet-Drafts: one for= the >>>>> 'RESTful folders' API which is our simplification of WebDAV, and a se= cond >>>>> one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTfu= l >>>>> folders' or whatever other HTTP-based API you want. >>>>> >>>>> >>>>> >>>>> There is one requirement that all synchronisers need to handle: movin= g >>>>> resources. In this spec the alternative of a WebDAV MOVE is not speci= fied. >>>>> >>>>> It is true that a MOVE could be replaced with a DELETE + UPLOAD but >>>>> that is not acceptable in most cases due to the inefficiency of such >>>>> operation (cpu, bandwidth consumption ...) >>>>> >>>>> Is there a plan to support such basic feature? >>>>> >>>>> From the current remoteStorage spec, the ownCloud sync protocol can b= e >>>>> implemented. The missing bit is tracking those remote moves. >>>>> >>>>> I agree with Hugo that MOVE is useful, sometimes if you just rename a >>>>> file it will be perfect. But the question I have is that whether we n= eed to >>>>> make two documents? Multiple choices is not good for standardization.= In my >>>>> view, webdav is something that we need to have a very clear decision = on >>>>> whether to consider it or not. >>>>> >>>>> Regards, >>>>> Linhui >>>>> >>>>> >>>>> >>>>> Cheers >>>>> >>>>> >>>>> On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < >>>>> ietf@hugo.labkode.com> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: >>>>> >>>>> Hi >>>>> >>>>> On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1l= ez Labrador < >>>>> ietf@hugo.labkode.com> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >>>>> >>>>> Hi >>>>> >>>>> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador < >>>>> ietf@hugo.labkode.com>: >>>>> >>>>> Hi, >>>>> >>>>> from my point of view the remoteStorage project addresses a subset of >>>>> the use cases of the WebDAV specification. >>>>> >>>>> The main difference I can observe is that the specification is built = on >>>>> REST instead of XML-based communication. >>>>> >>>>> >>>>> I personally like much more REST than WebDAV because it is more >>>>> developer friendly and it is faster to develop. >>>>> Maybe the remoteStorage API becomes the next WebDAV :) >>>>> >>>>> However, the remoteStorage API does not provide a way of synchronisin= g >>>>> data, this task is delegated to the developers. >>>>> Is there a plan to provide such feature based on the outcome of this >>>>> draft? >>>>> >>>>> I'm a little bit confused why you say the remoteStorage does not >>>>> provide that. Is that because remoteStorage does not perform like a t= ypical >>>>> sync services (e.g. dropbox...) or you are saying something else? >>>>> >>>>> Yes, because it does not offer synchronisation capabilities. >>>>> >>>>> Got it. And What I am wondering is that do we need to include those >>>>> capabilities in a base specifications. Since it is hard to standardiz= e the >>>>> capabilities like dedup or delta. Maybe a better way is to define tho= se in >>>>> a separate specification, >>>>> >>>>> >>>>> >>>>> >>>>> Thanks for giving these examples - so by 'synchronisation >>>>> capabilities' you mean 1) deduplication and 2) delta updates? Anythin= g else >>>>> or is that an exhaustive list? >>>>> >>>>> >>>>> >>>>> something like extensions. For a base document, we just need to defin= e >>>>> how to perform sync operations. >>>>> >>>>> >>>>> >>>>> Yes, I agree that may be an extension of this draft could handle the >>>>> synchronisation part. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Our Internet-Draft is heavily focused on the world wide web, whose >>>>> URLs are not content-addressable, we can't change that. So that >>>>> architecture is not very friendly to deduplication, compared to for >>>>> instance BitTorrent. As you already said, developers can still dedupe= on >>>>> the server-side when storing blobs to disk, and can also dedupe on th= e >>>>> client side before creating the resources the client uploads. >>>>> As far as I know, delta updates are not supported by the ETag system = - >>>>> you cannot do a range request to find out if certain bytes within a >>>>> document have changed. However, the folder system we define does enco= urage >>>>> you, for instance when you develop a To Do List app, put each task on= its >>>>> own document, and then query the folder to see which of them changed, >>>>> instead of putting them all in one big document and retrieving the wh= ole >>>>> document each time. >>>>> >>>>> Cheers, >>>>> Michiel. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> BTW, I want to introduce ClawIO ( >>>>> http://clawio.github.io), a research >>>>> project to benchmark different synchronisation protocols against >>>>> different data backends with special attention to provide a common sy= nc >>>>> API. >>>>> >>>>> A common API for different sync protocols is being created based on t= he >>>>> architecture specified in this draft (control and data servers) and t= he >>>>> >>>>> I cannot find a distributed architecture in this draft. It seems that >>>>> they handle metadata and content data together, just like a normal we= b >>>>> service. >>>>> >>>>> >>>>> ClawIO is fully distributed. Every logical unit is a different server >>>>> than be scaled out. Data and Metadata channels are independent from e= ach >>>>> other and reside on different servers. >>>>> >>>>> That is widely employed in popular sync services. And that is also >>>>> beneficial to privacy to some extent. But in the context of sync in b= rowser >>>>> (which is mainly considered in the remoteStorage), I don't know wheth= er >>>>> this is reasonable. But I think we should deploy distributed architec= ture >>>>> although it will make things complicated. >>>>> >>>>> >>>>> >>>>> Of course, the remoteStorage is targeted to browsers, so syncing does >>>>> not make too much sense in this case. >>>>> With the rise of Linux container micro-service based architectures, >>>>> the deployment of such highly complex systems should become easier a= nd >>>>> faster. >>>>> >>>>> Best, >>>>> >>>>> >>>>> Hugo >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Linhui >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Linhui >>>>> >>>>> one from the CERN EOS project (management, disk and queue servers). >>>>> >>>>> The Phase I has implemented the ownCloud Sync Protocol and Phase II >>>>> will >>>>> implement the SeaFile Sync Protocol. >>>>> The choice of these protocols among others is because they are really >>>>> opposed to each other in terms of syncing (delta vs non-delta, >>>>> state-based vs log/event/git-based sync =E2=80=A6), so finding a comm= on >>>>> approach >>>>> is more challenging. >>>>> >>>>> Providing a base specification/architecture to measure the feasibilit= y >>>>> of this draft is one of the objectives of the project. >>>>> >>>>> I believe that the work being done here and in ClawIO are supplementa= ry >>>>> to each other and I think mutual collaboration could be beneficial fo= r >>>>> both sides. >>>>> >>>>> Also, if there is interest, the remoteStorage API can be added to >>>>> ClawIO. >>>>> >>>>> Best regards, >>>>> >>>>> Hugo Gonzalez Labrador >>>>> >>>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: >>>>> > Send Storagesync mailing list submissions to >>>>> > storagesync@ietf.org >>>>> > >>>>> > To subscribe or unsubscribe via the World Wide Web, visit >>>>> > >>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>> > or, via email, send a message with subject or body 'help' to >>>>> > storagesync-request@ietf.org >>>>> > >>>>> > You can reach the person managing the list at >>>>> > storagesync-owner@ietf.org >>>>> > >>>>> > When replying, please edit your Subject line so it is more specific >>>>> > than "Re: Contents of Storagesync digest..." >>>>> > Today's Topics: >>>>> > >>>>> > 1. New version of draft-dejong-remotestorage Internet-Draft >>>>> > available (Michiel de Jong) >>>>> > 2. Re: New version of draft-dejong-remotestorage Internet-Draft >>>>> > available (Gihan Dias) >>>>> > 3. Re: New version of draft-dejong-remotestorage Internet-Draft >>>>> > available (Fei Song) >>>>> > _______________________________________________ >>>>> > Storagesync mailing list >>>>> > Storagesync@ietf.org >>>>> > >>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>> > Email had 3 attachments: >>>>> > + [Storagesync] New version of draft-dejong-remotestorage >>>>> > Internet-Draft available >>>>> > 2k (message/rfc822) >>>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>>>> > Internet-Draft available >>>>> > 1k (message/rfc822) >>>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage >>>>> > Internet-Draft available >>>>> > 2k (message/rfc822) >>>>> >>>>> _______________________________________________ >>>>> Storagesync mailing list >>>>> Storagesync@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --001a113f9b762f0e320525faa34f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes! I'll discuss with Francois ho= w we can make these boundaries clearer. Maybe we can split along these line= s:

* upload/manipulate/query/download protocol (e.g. WebDAV or= the GET/PUT/DELETE operations we currently define)
* CORS or othe= r cross-origin access mechanism, OAUTH or other auth mechanism, WebFinger o= r other discovery mechanism, ETag or other versioning mechanism
* = chunking/deduping/delta-updates

And the remoteStorage spec sho= uld probably only define the middle part.


On Thu, Dec 3, 2015 at 9:4= 4 AM, <fsong@bjtu.edu.cn> wrote:

Hi Michiel and Linhui,

I think it will be good to have a boundary for this draft and leave some= work for the applicaiton layer~

-----=E5= =8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: "Michiel de Jong" <mbdejong@mozilla.com>
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2015=E5=B9=B412=E6=9C=882=E6=97=A5 =E6=98=9F=E6=9C=9F= =E4=B8=89
=E6=94=B6=E4=BB=B6=E4=BA=BA: "Linhui Sun" <= ;lh.sunlinh@gmail= .com>
=E6=8A=84=E9=80=81: storagesync <storagesync@ietf.org>, fko= oman <fkooman@tux= ed.net>, "Hugo Gonz=C3=A1lez Labrador" <ietf@hugo.labkode.com>=E4=B8=BB=E9=A2=98: Re: [Storagesync] Storagesync Digest, Vol 5, I= ssue 1

Ah sure, that's entirely appropriate, remoteStorage treats both th= e Content-Type header value and the actual body of a document as opaque str= ings of bytes. It doesn't "care" if you use it to store only = data blocks that are chunks of something else.

For instance, you could have a folder on a user's storage that con= tains only inode-like JSON-documents, which list the URLs of binary documen= ts that make up 1Kb blocks of the actual data. Nice for deduping, delta upd= ates, and also renaming files without reuploading their content.

But yeah, the argument is that *how* to create and manage th= ese chunks, is then still left up to the application developer (or to anoth= er spec on top of the remoteStorage spec).


Cheers,
Michiel.

On Wed, Dec 2, 2015 at 3:29 PM, Linhui Sun <= lh.sunlinh@gmail.com> wrote:
Hi=20

2015-12-02 22:05 GMT+08:00 Michiel de Jong= <mbdejong@mozilla.com>:
Actually what I'm saying is a chunking before transmitting (using = http), in this way, they are treated as individual documents from the stand= point of http. But I don't know whether this is appropriate for remoteS= torage, just a comment.

Regards,
Linhui

A comparison document sounds good! See also ht= tp://www.servicedenuages.fr/en/generic-storage-ecosystem.


Cheers,
Michiel.


On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun <= lh.sunlinh@gmail.com> wrote:
That's cool for me, a separate section for this might = make sense.=20

Another thing is do we need to include an application-layer chunking h= ere (not just for a browser sync), since if we want to further extend other= capabilities it is essential.

Regards,
Linhui

2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez La= brador <ietf@hugo.labkode.com>:
I propose to come up with a list of advantages and disadvantages of us= ing WebDAV and compare them against a JSON/REST based approach, like remote= Storage.
=C2=A0
Does it sound good ?
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote:
=C2=A0
=C2=A0
2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo= .labkode.com>:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:<= br>
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draf= t.
=C2=A0
We get the question about WebDAV a lot, in the next version we s= hould add a remark about it in the intro. The folder descriptions returned = when you GET a URL that ends with a / are indeed a deviation from the XML r= eturned by WebDAV server, and this is just because nowadays JSON is easier = to use than XML for developers, both client-side and server-side.
=C2=A0
=C2=A0
I totally agree here, this was going to happen soon or later and it is= really appreciated.
=C2=A0
=C2=A0
The fact that we don't require servers to support WebDAV'= ;s custom verbs like PROPPATCH etc. is for three reasons:
<= /div>
1) it's a lot of work to implement this without using an exi= sting WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don'= ;t implement all of WebDAV. It's very annoying for client implementers = to have to deal with servers that e.g. chose not to implement LOCK and UNLO= CK.
3) we don't really need all these advanced features on top o= f standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a= simple folder description format, is enough for most applications.<= br>
=C2=A0
Other than that, the remoteStorage Internet-Draft specifies a *l= ot* more than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder&= #39;s ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, ins= tead of putting them on top of our minimal GET/PUT/DELETE API definition. I= n fact, we could probably separate it into two Internet-Drafts: one for the= 'RESTful folders' API which is our simplification of WebDAV, and a= second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or '= RESTful folders' or whatever other HTTP-based API you want.
<= /div>
=C2=A0
=C2=A0
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.= =C2=A0
=C2=A0
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
=C2=A0
Is there a plan to support such basic feature?
=C2=A0
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you just rename a = file it will be perfect. But the question I have is that whether we need to= make two documents? Multiple choices is not good for standardization. In m= y view, webdav is something that we need to have a very clear decision on w= hether to consider it or not.
=C2=A0
Regards,
Linhui
=C2=A0
=C2=A0
Cheers
=C2=A0
On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com> wrote:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz= =C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remoteStorage does= not provide that. Is that because remoteStorage does not perform like a ty= pical sync services (e.g. dropbox...) or you are saying something else?
Yes, because it does not offer synchronisation capabilities.
Got it. And What I am wondering is that do we need to include th= ose capabilities in a base specifications. Since it is hard to standardize = the capabilities like dedup or delta. Maybe a better way is to define those= in a separate specification,
=C2=A0
=C2=A0
Thanks for giving these examples - so by 'synchronisation capabili= ties' you mean 1) deduplication and 2) delta updates? Anything else or = is that an exhaustive list?
=C2=A0
something like extensions. For a base document, we just need to = define how to perform sync operations.
=C2=A0
=C2=A0
Yes, I agree that may be an extension of this draft could handle the s= ynchronisation part.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Our Internet-Draft is heavily focused on the world wide web, whose URL= s are not content-addressable, we can't change that. So that architectu= re is not very friendly to deduplication, compared to for instance BitTorre= nt. As you already said, developers can still dedupe on the server-side whe= n storing blobs to disk, and can also dedupe on the client side before crea= ting the resources the client uploads.
As far as I know, delta updates are not supported by the ETag system -= you cannot do a range request to find out if certain bytes within a docume= nt have changed. However, the folder system we define does encourage you, f= or instance when you develop a To Do List app, put each task on its own doc= ument, and then query the folder to see which of them changed, instead of p= utting them all in one big document and retrieving the whole document each = time.
=C2=A0
Cheers,
Michiel.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
=C2=A0
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this draft. It seems= that they handle metadata and content data together, just like a normal we= b service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. And that is al= so beneficial to privacy to some extent. But in the context of sync in brow= ser (which is mainly considered in the remoteStorage), I don't know whe= ther this is reasonable. But I think we should deploy distributed architect= ure although it will make things complicated.
<= /div>
=C2=A0
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=C2=A0
=C2=A0
Hugo
=C2=A0
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (management, disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0
=C2=A0
=C2=A0




___= ____________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync


--001a113f9b762f0e320525faa34f-- From nobody Thu Dec 3 01:04:10 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A871C1B32F3 for ; Thu, 3 Dec 2015 01:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUN5YibYKUZA for ; Thu, 3 Dec 2015 01:04:06 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1F01B32F1 for ; Thu, 3 Dec 2015 01:04:05 -0800 (PST) Received: by ajax-webmail-Jdweb3 (Coremail) ; Thu, 3 Dec 2015 17:06:40 +0800 (GMT+08:00) Date: Thu, 3 Dec 2015 17:06:40 +0800 (GMT+08:00) From: fsong@bjtu.edu.cn To: "Michiel de Jong" Message-ID: <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41233_1733010373.1449133600595" X-Originating-IP: [106.2.233.19] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20150107(58648.7033.6860) Copyright (c) 2002-2015 www.mailtech.cn bjtu X-SendMailWithSms: false X-CM-TRANSID: d55wygAHhAYgBmBWkLYFAA--.3438W X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/1tbiAQIMB1R9XjYYmwAJsD X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: Linhui Sun , storagesync , fkooman@tuxed.net, =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:04:09 -0000 ------=_Part_41233_1733010373.1449133600595 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkKCiAKCklmIHdlIHJlYWxseSB3YW50IHRvIGRpc2N1c3MgdGhlIFByb3MgYW5kIENvbnMgb2Yg V2ViREFWLCBjYW4gd2UgbWFyayB0aGVzZSB0aHJlZSByZWFzb25zIGFzIGRpc2FkdmFudGFnZXMg b2YgV2ViREFWPyBhbnkgc3VwcG9ydCBmb3IgdGhhdD8KCiAKCkZvciB0aGUgdGFyZ2V0IG9mIG91 ciBJU1MgZ3JvdXAsIHdoZXRoZXIgdGhlIFdlYkRBViBjYW4gYmUgcmV1c2VkIGlzIGNyaXRpY2Fs LgoKLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQrlj5Hku7bkuro6ICJNaWNoaWVsIGRlIEpvbmciIDxt YmRlam9uZ0Btb3ppbGxhLmNvbT4K5Y+R6YCB5pe26Ze0OiAyMDE15bm0MTLmnIgy5pelIOaYn+ac n+S4iQrmlLbku7bkuro6ICJIdWdvIEdvbnrDoWxleiBMYWJyYWRvciIgPGlldGZAaHVnby5sYWJr b2RlLmNvbT4K5oqE6YCBOiAiTGluaHVpIFN1biIgPGxoLnN1bmxpbmhAZ21haWwuY29tPiwgc3Rv cmFnZXN5bmMgPHN0b3JhZ2VzeW5jQGlldGYub3JnPiwgZmtvb21hbkB0dXhlZC5uZXQK5Li76aKY OiBSZTogW1N0b3JhZ2VzeW5jXSBTdG9yYWdlc3luYyBEaWdlc3QsIFZvbCA1LCBJc3N1ZSAxCgoK SGkgYWxsIQoKClRoYW5rcyBmb3IgYWxsIHlvdXIgcmVhY3Rpb25zIHRvIHRoZSByZW1vdGVTdG9y YWdlIEludGVybmV0LURyYWZ0LgoKCldlIGdldCB0aGUgcXVlc3Rpb24gYWJvdXQgV2ViREFWIGEg bG90LCBpbiB0aGUgbmV4dCB2ZXJzaW9uIHdlIHNob3VsZCBhZGQgYSByZW1hcmsgYWJvdXQgaXQg aW4gdGhlIGludHJvLiBUaGUgZm9sZGVyIGRlc2NyaXB0aW9ucyByZXR1cm5lZCB3aGVuIHlvdSBH RVQgYSBVUkwgdGhhdCBlbmRzIHdpdGggYSAvIGFyZSBpbmRlZWQgYSBkZXZpYXRpb24gZnJvbSB0 aGUgWE1MIHJldHVybmVkIGJ5IFdlYkRBViBzZXJ2ZXIsIGFuZCB0aGlzIGlzIGp1c3QgYmVjYXVz ZSBub3dhZGF5cyBKU09OIGlzIGVhc2llciB0byB1c2UgdGhhbiBYTUwgZm9yIGRldmVsb3BlcnMs IGJvdGggY2xpZW50LXNpZGUgYW5kIHNlcnZlci1zaWRlLgoKClRoZSBmYWN0IHRoYXQgd2UgZG9u J3QgcmVxdWlyZSBzZXJ2ZXJzIHRvIHN1cHBvcnQgV2ViREFWJ3MgY3VzdG9tIHZlcmJzIGxpa2Ug UFJPUFBBVENIIGV0Yy4gaXMgZm9yIHRocmVlIHJlYXNvbnM6CgoxKSBpdCdzIGEgbG90IG9mIHdv cmsgdG8gaW1wbGVtZW50IHRoaXMgd2l0aG91dCB1c2luZyBhbiBleGlzdGluZyBXZWJEQVYgbGli cmFyeQoKMikgaW4gcHJhY3RpY2UsIGEgbG90IG9mIFdlYkRBViBzZXJ2ZXJzIGdldCBpdCB3cm9u Zywgb3IgZG9uJ3QgaW1wbGVtZW50IGFsbCBvZiBXZWJEQVYuIEl0J3MgdmVyeSBhbm5veWluZyBm b3IgY2xpZW50IGltcGxlbWVudGVycyB0byBoYXZlIHRvIGRlYWwgd2l0aCBzZXJ2ZXJzIHRoYXQg ZS5nLiBjaG9zZSBub3QgdG8gaW1wbGVtZW50IExPQ0sgYW5kIFVOTE9DSy4KCjMpIHdlIGRvbid0 IHJlYWxseSBuZWVkIGFsbCB0aGVzZSBhZHZhbmNlZCBmZWF0dXJlcyBvbiB0b3Agb2Ygc3RhbmRh cmQgSFRUUCwganVzdCBzdXBwb3J0aW5nIEdFVC9QVVQvREVMRVRFIGZvciByZXNvdXJjZXMsIGFu ZCBhZGRpbmcgYSBzaW1wbGUgZm9sZGVyIGRlc2NyaXB0aW9uIGZvcm1hdCwgaXMgZW5vdWdoIGZv ciBtb3N0IGFwcGxpY2F0aW9ucy4KCgpPdGhlciB0aGFuIHRoYXQsIHRoZSByZW1vdGVTdG9yYWdl IEludGVybmV0LURyYWZ0IHNwZWNpZmllcyBhICpsb3QqIG1vcmUgdGhhbiBqdXN0IGhvdyBlYWNo IEhUVFAgdmVyYiBzaG91bGQgYmVoYXZlOgoKKiByZXF1aXJpbmcgc3VwcG9ydCBmb3IgT0F1dGgg aW1wbGljaXQtZ3JhbnQgZmxvdwoKKiByZXF1aXJpbmcgRVRhZyBzdXBwb3J0IGFuZCBuZXN0ZWQg dmVyc2lvbmluZyAoaS5lLiB0aGUgZm9sZGVyJ3MgRVRhZyBjaGFuZ2VzIGlmIGFueXRoaW5nIHdp dGhpbiB0aGF0IGZvbGRlciBjaGFuZ2VzKQoKKiByZXF1aXJpbmcgQ09SUyBoZWFkZXJzCgoqIHJl cXVpcmluZyBhIFdlYkZpbmdlciBhbm5vdW5jZW1lbnQgZm9yIHNlcnZpY2UgZGlzY292ZXJ5CgoK SXQgd291bGQgYmUgZWFzeSB0byBhZGQgdGhlc2UgdGhyZWUgdGhpbmdzIG9uIHRvcCBvZiBXZWJE QVYsIGluc3RlYWQgb2YgcHV0dGluZyB0aGVtIG9uIHRvcCBvZiBvdXIgbWluaW1hbCBHRVQvUFVU L0RFTEVURSBBUEkgZGVmaW5pdGlvbi4gSW4gZmFjdCwgd2UgY291bGQgcHJvYmFibHkgc2VwYXJh dGUgaXQgaW50byB0d28gSW50ZXJuZXQtRHJhZnRzOiBvbmUgZm9yIHRoZSAnUkVTVGZ1bCBmb2xk ZXJzJyBBUEkgd2hpY2ggaXMgb3VyIHNpbXBsaWZpY2F0aW9uIG9mIFdlYkRBViwgYW5kIGEgc2Vj b25kIG9uZSBmb3IgT0F1dGgvRVRhZ3MvQ09SUy9XZWJGaW5nZXIgb24gdG9wIG9mIGVpdGhlciBX ZWJEQVYgb3IgJ1JFU1RmdWwgZm9sZGVycycgb3Igd2hhdGV2ZXIgb3RoZXIgSFRUUC1iYXNlZCBB UEkgeW91IHdhbnQuCgoKCk9uIFdlZCwgRGVjIDIsIDIwMTUgYXQgMTE6MjggQU0sIEh1Z28gR29u esOhbGV6IExhYnJhZG9yIDxpZXRmQGh1Z28ubGFia29kZS5jb20+IHdyb3RlOgoKIAogCiAKT24g V2VkLCBEZWMgMiwgMjAxNSwgYXQgMTE6MTggQU0sIExpbmh1aSBTdW4gd3JvdGU6CgpIaQoKIApP biDlkajkuIksIDEy5pyIIDIsIDIwMTUgYXQgMTc6NTYsIEh1Z28gR29uesOhbGV6IExhYnJhZG9y IDxpZXRmQGh1Z28ubGFia29kZS5jb20+IHdyb3RlOgoKIAogCiAKT24gV2VkLCBEZWMgMiwgMjAx NSwgYXQgMDg6MjAgQU0sIExpbmh1aSBTdW4gd3JvdGU6CgpIaQoKIAoyMDE1LTEyLTAyIDU6MTQg R01UKzA4OjAwIEh1Z28gR29uesOhbGV6IExhYnJhZG9yIDxpZXRmQGh1Z28ubGFia29kZS5jb20+ OgoKSGksCgogCmZyb20gbXkgcG9pbnQgb2YgdmlldyB0aGUgcmVtb3RlU3RvcmFnZSBwcm9qZWN0 IGFkZHJlc3NlcyBhIHN1YnNldCBvZgoKdGhlIHVzZSBjYXNlcyBvZiB0aGUgIFdlYkRBViBzcGVj aWZpY2F0aW9uLgoKIApUaGUgbWFpbiBkaWZmZXJlbmNlIEkgY2FuIG9ic2VydmUgaXMgdGhhdCB0 aGUgc3BlY2lmaWNhdGlvbiBpcyBidWlsdCBvbgoKUkVTVCBpbnN0ZWFkIG9mIFhNTC1iYXNlZCBj b21tdW5pY2F0aW9uLgoKIApJIHBlcnNvbmFsbHkgbGlrZSBtdWNoIG1vcmUgUkVTVCB0aGFuIFdl YkRBViBiZWNhdXNlIGl0IGlzIG1vcmUKCmRldmVsb3BlciBmcmllbmRseSBhbmQgaXQgaXMgZmFz dGVyIHRvIGRldmVsb3AuCgogTWF5YmUgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGJlY29tZXMgdGhl IG5leHQgV2ViREFWIDopCgogCkhvd2V2ZXIsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBkb2VzIG5v dCBwcm92aWRlIGEgd2F5IG9mIHN5bmNocm9uaXNpbmcKCmRhdGEsIHRoaXMgdGFzayBpcyBkZWxl Z2F0ZWQgdG8gdGhlIGRldmVsb3BlcnMuCgpJcyB0aGVyZSBhIHBsYW4gdG8gcHJvdmlkZSBzdWNo IGZlYXR1cmUgYmFzZWQgb24gdGhlIG91dGNvbWUgb2YgdGhpcwoKZHJhZnQ/CgpJJ20gYSBsaXR0 bGUgYml0IGNvbmZ1c2VkIHdoeSB5b3Ugc2F5IHRoZSByZW1vdGVTdG9yYWdlIGRvZXMgbm90IHBy b3ZpZGUgdGhhdC4gSXMgdGhhdCBiZWNhdXNlIHJlbW90ZVN0b3JhZ2UgZG9lcyBub3QgcGVyZm9y bSBsaWtlIGEgdHlwaWNhbCBzeW5jIHNlcnZpY2VzIChlLmcuIGRyb3Bib3guLi4pIG9yIHlvdSBh cmUgc2F5aW5nIHNvbWV0aGluZyBlbHNlPwoKWWVzLCBiZWNhdXNlIGl0IGRvZXMgbm90IG9mZmVy IHN5bmNocm9uaXNhdGlvbiBjYXBhYmlsaXRpZXMuCgpHb3QgaXQuIEFuZCBXaGF0IEkgYW0gd29u ZGVyaW5nIGlzIHRoYXQgZG8gd2UgbmVlZCB0byBpbmNsdWRlIHRob3NlIGNhcGFiaWxpdGllcyBp biBhIGJhc2Ugc3BlY2lmaWNhdGlvbnMuIFNpbmNlIGl0IGlzIGhhcmQgdG8gc3RhbmRhcmRpemUg dGhlIGNhcGFiaWxpdGllcyBsaWtlIGRlZHVwIG9yIGRlbHRhLiBNYXliZSBhIGJldHRlciB3YXkg aXMgdG8gZGVmaW5lIHRob3NlIGluIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiwKCgpUaGFua3Mg Zm9yIGdpdmluZyB0aGVzZSBleGFtcGxlcyAtIHNvIGJ5ICdzeW5jaHJvbmlzYXRpb24gY2FwYWJp bGl0aWVzJyB5b3UgbWVhbiAxKSBkZWR1cGxpY2F0aW9uIGFuZCAyKSBkZWx0YSB1cGRhdGVzPyBB bnl0aGluZyBlbHNlIG9yIGlzIHRoYXQgYW4gZXhoYXVzdGl2ZSBsaXN0PwoKc29tZXRoaW5nIGxp a2UgZXh0ZW5zaW9ucy4gRm9yIGEgYmFzZSBkb2N1bWVudCwgd2UganVzdCBuZWVkIHRvIGRlZmlu ZSBob3cgdG8gcGVyZm9ybSBzeW5jIG9wZXJhdGlvbnMuCgogClllcywgSSBhZ3JlZSB0aGF0IG1h eSBiZSBhbiBleHRlbnNpb24gb2YgdGhpcyBkcmFmdCBjb3VsZCBoYW5kbGUgdGhlIHN5bmNocm9u aXNhdGlvbiBwYXJ0LgoKIAoKCk91ciBJbnRlcm5ldC1EcmFmdCBpcyBoZWF2aWx5IGZvY3VzZWQg b24gdGhlIHdvcmxkIHdpZGUgd2ViLCB3aG9zZSBVUkxzIGFyZSBub3QgY29udGVudC1hZGRyZXNz YWJsZSwgd2UgY2FuJ3QgY2hhbmdlIHRoYXQuIFNvIHRoYXQgYXJjaGl0ZWN0dXJlIGlzIG5vdCB2 ZXJ5IGZyaWVuZGx5IHRvIGRlZHVwbGljYXRpb24sIGNvbXBhcmVkIHRvIGZvciBpbnN0YW5jZSBC aXRUb3JyZW50LiBBcyB5b3UgYWxyZWFkeSBzYWlkLCBkZXZlbG9wZXJzIGNhbiBzdGlsbCBkZWR1 cGUgb24gdGhlIHNlcnZlci1zaWRlIHdoZW4gc3RvcmluZyBibG9icyB0byBkaXNrLCBhbmQgY2Fu IGFsc28gZGVkdXBlIG9uIHRoZSBjbGllbnQgc2lkZSBiZWZvcmUgY3JlYXRpbmcgdGhlIHJlc291 cmNlcyB0aGUgY2xpZW50IHVwbG9hZHMuCgoKQXMgZmFyIGFzIEkga25vdywgZGVsdGEgdXBkYXRl cyBhcmUgbm90IHN1cHBvcnRlZCBieSB0aGUgRVRhZyBzeXN0ZW0gLSB5b3UgY2Fubm90IGRvIGEg cmFuZ2UgcmVxdWVzdCB0byBmaW5kIG91dCBpZiBjZXJ0YWluIGJ5dGVzIHdpdGhpbiBhIGRvY3Vt ZW50IGhhdmUgY2hhbmdlZC4gSG93ZXZlciwgdGhlIGZvbGRlciBzeXN0ZW0gd2UgZGVmaW5lIGRv ZXMgZW5jb3VyYWdlIHlvdSwgZm9yIGluc3RhbmNlIHdoZW4geW91IGRldmVsb3AgYSBUbyBEbyBM aXN0IGFwcCwgcHV0IGVhY2ggdGFzayBvbiBpdHMgb3duIGRvY3VtZW50LCBhbmQgdGhlbiBxdWVy eSB0aGUgZm9sZGVyIHRvIHNlZSB3aGljaCBvZiB0aGVtIGNoYW5nZWQsIGluc3RlYWQgb2YgcHV0 dGluZyB0aGVtIGFsbCBpbiBvbmUgYmlnIGRvY3VtZW50IGFuZCByZXRyaWV2aW5nIHRoZSB3aG9s ZSBkb2N1bWVudCBlYWNoIHRpbWUuCgoKCkNoZWVycywKCk1pY2hpZWwuCgoKCiAKIApCVFcsIEkg d2FudCB0byBpbnRyb2R1Y2UgQ2xhd0lPIChodHRwOi8vY2xhd2lvLmdpdGh1Yi5pbyksIGEgcmVz ZWFyY2gKCnByb2plY3QgdG8gYmVuY2htYXJrIGRpZmZlcmVudCBzeW5jaHJvbmlzYXRpb24gcHJv dG9jb2xzIGFnYWluc3QKCmRpZmZlcmVudCBkYXRhIGJhY2tlbmRzIHdpdGggc3BlY2lhbCBhdHRl bnRpb24gdG8gcHJvdmlkZSBhIGNvbW1vbiBzeW5jCgpBUEkuCgogCkEgY29tbW9uIEFQSSBmb3Ig ZGlmZmVyZW50IHN5bmMgcHJvdG9jb2xzIGlzIGJlaW5nIGNyZWF0ZWQgYmFzZWQgb24gdGhlCgph cmNoaXRlY3R1cmUgc3BlY2lmaWVkIGluIHRoaXMgZHJhZnQgKGNvbnRyb2wgYW5kIGRhdGEgc2Vy dmVycykgYW5kIHRoZQoKSSBjYW5ub3QgZmluZCBhIGRpc3RyaWJ1dGVkIGFyY2hpdGVjdHVyZSBp biB0aGlzIGRyYWZ0LiBJdCBzZWVtcyB0aGF0IHRoZXkgaGFuZGxlIG1ldGFkYXRhIGFuZCBjb250 ZW50IGRhdGEgdG9nZXRoZXIsIGp1c3QgbGlrZSBhIG5vcm1hbCB3ZWIgc2VydmljZS4KCiAKQ2xh d0lPIGlzIGZ1bGx5IGRpc3RyaWJ1dGVkLiBFdmVyeSBsb2dpY2FsIHVuaXQgaXMgYSBkaWZmZXJl bnQgc2VydmVyIHRoYW4gYmUgc2NhbGVkIG91dC4gRGF0YSBhbmQgTWV0YWRhdGEgY2hhbm5lbHMg YXJlIGluZGVwZW5kZW50IGZyb20gZWFjaCBvdGhlciBhbmQgcmVzaWRlIG9uIGRpZmZlcmVudCBz ZXJ2ZXJzLgoKVGhhdCBpcyB3aWRlbHkgZW1wbG95ZWQgaW4gcG9wdWxhciBzeW5jIHNlcnZpY2Vz LiBBbmQgdGhhdCBpcyBhbHNvIGJlbmVmaWNpYWwgdG8gcHJpdmFjeSB0byBzb21lIGV4dGVudC4g QnV0IGluIHRoZSBjb250ZXh0IG9mIHN5bmMgaW4gYnJvd3NlciAod2hpY2ggaXMgbWFpbmx5IGNv bnNpZGVyZWQgaW4gdGhlIHJlbW90ZVN0b3JhZ2UpLCBJIGRvbid0IGtub3cgd2hldGhlciB0aGlz IGlzIHJlYXNvbmFibGUuIEJ1dCBJIHRoaW5rIHdlIHNob3VsZCBkZXBsb3kgZGlzdHJpYnV0ZWQg YXJjaGl0ZWN0dXJlIGFsdGhvdWdoIGl0IHdpbGwgbWFrZSB0aGluZ3MgY29tcGxpY2F0ZWQuCgog Ck9mIGNvdXJzZSwgdGhlIHJlbW90ZVN0b3JhZ2UgaXMgdGFyZ2V0ZWQgdG8gYnJvd3NlcnMsIHNv IHN5bmNpbmcgZG9lcyBub3QgbWFrZSB0b28gbXVjaCBzZW5zZSBpbiB0aGlzIGNhc2UuCgpXaXRo IHRoZSByaXNlIG9mIExpbnV4IGNvbnRhaW5lciBtaWNyby1zZXJ2aWNlIGJhc2VkIGFyY2hpdGVj dHVyZXMsIHRoZSBkZXBsb3ltZW50IG9mICBzdWNoIGhpZ2hseSBjb21wbGV4IHN5c3RlbXMgc2hv dWxkIGJlY29tZSBlYXNpZXIgYW5kIGZhc3Rlci4KCiAKQmVzdCwKCiAKSHVnbwogClJlZ2FyZHMs CgpMaW5odWkgCgogCiAKUmVnYXJkcywKCkxpbmh1aQoKb25lIGZyb20gdGhlIENFUk4gRU9TIHBy b2plY3QgKG1hbmFnZW1lbnQsIGRpc2sgYW5kIHF1ZXVlIHNlcnZlcnMpLgoKIApUaGUgUGhhc2Ug SSBoYXMgaW1wbGVtZW50ZWQgdGhlIG93bkNsb3VkIFN5bmMgUHJvdG9jb2wgYW5kIFBoYXNlIElJ IHdpbGwKCmltcGxlbWVudCB0aGUgU2VhRmlsZSBTeW5jIFByb3RvY29sLgoKVGhlIGNob2ljZSBv ZiB0aGVzZSBwcm90b2NvbHMgYW1vbmcgb3RoZXJzIGlzIGJlY2F1c2UgdGhleSBhcmUgcmVhbGx5 CgpvcHBvc2VkIHRvIGVhY2ggb3RoZXIgaW4gdGVybXMgb2Ygc3luY2luZyAoZGVsdGEgdnMgbm9u LWRlbHRhLAoKc3RhdGUtYmFzZWQgdnMgbG9nL2V2ZW50L2dpdC1iYXNlZCBzeW5jIOKApiksIHNv IGZpbmRpbmcgYSBjb21tb24gYXBwcm9hY2gKCmlzIG1vcmUgY2hhbGxlbmdpbmcuCgogClByb3Zp ZGluZyBhIGJhc2Ugc3BlY2lmaWNhdGlvbi9hcmNoaXRlY3R1cmUgdG8gbWVhc3VyZSB0aGUgZmVh c2liaWxpdHkKCm9mIHRoaXMgZHJhZnQgaXMgb25lIG9mIHRoZSBvYmplY3RpdmVzIG9mIHRoZSBw cm9qZWN0LgoKIApJIGJlbGlldmUgdGhhdCB0aGUgd29yayBiZWluZyBkb25lIGhlcmUgYW5kIGlu IENsYXdJTyBhcmUgc3VwcGxlbWVudGFyeQoKdG8gZWFjaCBvdGhlciBhbmQgSSB0aGluayBtdXR1 YWwgY29sbGFib3JhdGlvbiBjb3VsZCBiZSBiZW5lZmljaWFsIGZvcgoKYm90aCBzaWRlcy4KCiAK QWxzbywgaWYgdGhlcmUgaXMgaW50ZXJlc3QsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBjYW4gYmUg YWRkZWQgdG8KCkNsYXdJTy4KCiAKQmVzdCByZWdhcmRzLAoKIApIdWdvIEdvbnphbGV6IExhYnJh ZG9yCgogCk9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0IDA5OjAwIFBNLCBzdG9yYWdlc3luYy1yZXF1 ZXN0QGlldGYub3JnIHdyb3RlOgoKPiBTZW5kIFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBzdWJt aXNzaW9ucyB0bwoKPiAgICAgICBzdG9yYWdlc3luY0BpZXRmLm9yZwoKPgoKPiBUbyBzdWJzY3Jp YmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQKCj4gICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYwoKPiBvciwg dmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8K Cj4gICAgICAgc3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9yZwoKPgoKPiBZb3UgY2FuIHJlYWNo IHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQKCj4gICAgICAgc3RvcmFnZXN5bmMtb3du ZXJAaWV0Zi5vcmcKCj4KCj4gV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0 IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYwoKPiB0aGFuICJSZTogQ29udGVudHMgb2YgU3Rv cmFnZXN5bmMgZGlnZXN0Li4uIgoKPiBUb2RheSdzIFRvcGljczoKCj4KCj4gICAgMS4gTmV3IHZl cnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgICAgSW50ZXJuZXQtRHJhZnQKCj4g ICAgICAgYXZhaWxhYmxlIChNaWNoaWVsIGRlIEpvbmcpCgo+ICAgIDIuIFJlOiBOZXcgdmVyc2lv biBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdAoKPiAgICAgICBh dmFpbGFibGUgKEdpaGFuIERpYXMpCgo+ICAgIDMuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1k ZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdAoKPiAgICAgICBhdmFpbGFibGUgKEZl aSBTb25nKQoKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKPiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QKCj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcKCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYwoKPiBFbWFp bCBoYWQgMyBhdHRhY2htZW50czoKCj4gKyBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9mIGRy YWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlCgo+IEludGVybmV0LURyYWZ0IGF2YWlsYWJsZQoKPiAg IDJrIChtZXNzYWdlL3JmYzgyMikKCj4gKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBv ZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZQoKPiBJbnRlcm5ldC1EcmFmdCBhdmFpbGFibGUK Cj4gICAxayAobWVzc2FnZS9yZmM4MjIpCgo+ICsgUmU6IFtTdG9yYWdlc3luY10gTmV3IHZlcnNp b24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UKCj4gSW50ZXJuZXQtRHJhZnQgYXZhaWxh YmxlCgo+ICAgMmsgKG1lc3NhZ2UvcmZjODIyKQoKIApfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0CgpTdG9yYWdl c3luY0BpZXRmLm9yZwoKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9y YWdlc3luYwoKIAogCgo= ------=_Part_41233_1733010373.1449133600595 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdp bmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BB TiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXpl OiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPkhpIDxvOnA+PC9vOnA+ PC9GT05UPjwvU1BBTj48L1A+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBj bSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQ7 IG1zby1iaWRpLWZvbnQtc2l6ZTogNi4wcHQiIGxhbmc9IkVOLVVTIj48bzpwPjxGT05UIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1B TElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9y cGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjog YmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDYuMHB0IiBsYW5nPSJF Ti1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+SWYgd2UgcmVhbGx5IHdhbnQgdG8gZGlzY3VzcyB0 aGUgUHJvcyBhbmQgQ29ucyBvZiBXZWJEQVYsIGNhbiB3ZSBtYXJrIHRoZXNlIHRocmVlIHJlYXNv bnMgYXMgZGlzYWR2YW50YWdlcyBvZiBXZWJEQVY/IGFueSBzdXBwb3J0IGZvciB0aGF0PzwvRk9O VD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28t YmlkaS1mb250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+ PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvUD4KPFAgc3R5bGU9IlRFWFQtQUxJR046 IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4i IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIgbGFuZz0iRU4tVVMi PjxGT05UIGZhY2U9IkNhbGlicmkiPkZvciB0aGUgdGFyZ2V0IG9mIG91ciBJU1MgZ3JvdXAsIHdo ZXRoZXIgdGhlIFdlYkRBViBjYW4gYmUgcmV1c2VkIGlzIGNyaXRpY2FsLjwvRk9OVD48L1NQQU4+ PC9QPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNmI2YjYgMnB4IHNvbGlkOyBQ QURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiIG5h bWU9InJlcGx5Q29udGVudCI+LS0tLS3ljp/lp4vpgq7ku7YtLS0tLTxCUj48Qj7lj5Hku7bkuro6 PC9CPiAiTWljaGllbCBkZSBKb25nIiAmbHQ7bWJkZWpvbmdAbW96aWxsYS5jb20mZ3Q7PEJSPjxC PuWPkemAgeaXtumXtDo8L0I+IDIwMTXlubQxMuaciDLml6Ug5pif5pyf5LiJPEJSPjxCPuaUtuS7 tuS6ujo8L0I+ICJIdWdvIEdvbnrDoWxleiBMYWJyYWRvciIgJmx0O2lldGZAaHVnby5sYWJrb2Rl LmNvbSZndDs8QlI+PEI+5oqE6YCBOjwvQj4gIkxpbmh1aSBTdW4iICZsdDtsaC5zdW5saW5oQGdt YWlsLmNvbSZndDssIHN0b3JhZ2VzeW5jICZsdDtzdG9yYWdlc3luY0BpZXRmLm9yZyZndDssIGZr b29tYW5AdHV4ZWQubmV0PEJSPjxCPuS4u+mimDo8L0I+IFJlOiBbU3RvcmFnZXN5bmNdIFN0b3Jh Z2VzeW5jIERpZ2VzdCwgVm9sIDUsIElzc3VlIDE8QlI+PEJSPgo8RElWIGRpcj0ibHRyIj4KPERJ Vj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4K PERJVj4KPERJVj5IaSBhbGwhPEJSPjxCUj48L0RJVj5UaGFua3MgZm9yIGFsbCB5b3VyIHJlYWN0 aW9ucyB0byB0aGUgcmVtb3RlU3RvcmFnZSBJbnRlcm5ldC1EcmFmdC48QlI+PEJSPjwvRElWPldl IGdldCB0aGUgcXVlc3Rpb24gYWJvdXQgV2ViREFWIGEgbG90LCBpbiB0aGUgbmV4dCB2ZXJzaW9u IHdlIHNob3VsZCBhZGQgYSByZW1hcmsgYWJvdXQgaXQgaW4gdGhlIGludHJvLiBUaGUgZm9sZGVy IGRlc2NyaXB0aW9ucyByZXR1cm5lZCB3aGVuIHlvdSBHRVQgYSBVUkwgdGhhdCBlbmRzIHdpdGgg YSAvIGFyZSBpbmRlZWQgYSBkZXZpYXRpb24gZnJvbSB0aGUgWE1MIHJldHVybmVkIGJ5IFdlYkRB ViBzZXJ2ZXIsIGFuZCB0aGlzIGlzIGp1c3QgYmVjYXVzZSBub3dhZGF5cyBKU09OIGlzIGVhc2ll ciB0byB1c2UgdGhhbiBYTUwgZm9yIGRldmVsb3BlcnMsIGJvdGggY2xpZW50LXNpZGUgYW5kIHNl cnZlci1zaWRlLjxCUj48QlI+PC9ESVY+VGhlIGZhY3QgdGhhdCB3ZSBkb24ndCByZXF1aXJlIHNl cnZlcnMgdG8gc3VwcG9ydCBXZWJEQVYncyBjdXN0b20gdmVyYnMgbGlrZSBQUk9QUEFUQ0ggZXRj LiBpcyBmb3IgdGhyZWUgcmVhc29uczo8QlI+PC9ESVY+MSkgaXQncyBhIGxvdCBvZiB3b3JrIHRv IGltcGxlbWVudCB0aGlzIHdpdGhvdXQgdXNpbmcgYW4gZXhpc3RpbmcgV2ViREFWIGxpYnJhcnk8 QlI+PC9ESVY+MikgaW4gcHJhY3RpY2UsIGEgbG90IG9mIFdlYkRBViBzZXJ2ZXJzIGdldCBpdCB3 cm9uZywgb3IgZG9uJ3QgaW1wbGVtZW50IGFsbCBvZiBXZWJEQVYuIEl0J3MgdmVyeSBhbm5veWlu ZyBmb3IgY2xpZW50IGltcGxlbWVudGVycyB0byBoYXZlIHRvIGRlYWwgd2l0aCBzZXJ2ZXJzIHRo YXQgZS5nLiBjaG9zZSBub3QgdG8gaW1wbGVtZW50IExPQ0sgYW5kIFVOTE9DSy48QlI+PC9ESVY+ Mykgd2UgZG9uJ3QgcmVhbGx5IG5lZWQgYWxsIHRoZXNlIGFkdmFuY2VkIGZlYXR1cmVzIG9uIHRv cCBvZiBzdGFuZGFyZCBIVFRQLCBqdXN0IHN1cHBvcnRpbmcgR0VUL1BVVC9ERUxFVEUgZm9yIHJl c291cmNlcywgYW5kIGFkZGluZyBhIHNpbXBsZSBmb2xkZXIgZGVzY3JpcHRpb24gZm9ybWF0LCBp cyBlbm91Z2ggZm9yIG1vc3QgYXBwbGljYXRpb25zLjxCUj48QlI+PC9ESVY+T3RoZXIgdGhhbiB0 aGF0LCB0aGUgcmVtb3RlU3RvcmFnZSBJbnRlcm5ldC1EcmFmdCBzcGVjaWZpZXMgYSAqbG90KiBt b3JlIHRoYW4ganVzdCBob3cgZWFjaCBIVFRQIHZlcmIgc2hvdWxkIGJlaGF2ZTo8QlI+PC9ESVY+ KiByZXF1aXJpbmcgc3VwcG9ydCBmb3IgT0F1dGggaW1wbGljaXQtZ3JhbnQgZmxvdzxCUj48L0RJ Vj4KPERJVj4qIHJlcXVpcmluZyBFVGFnIHN1cHBvcnQgYW5kIG5lc3RlZCB2ZXJzaW9uaW5nIChp LmUuIHRoZSBmb2xkZXIncyBFVGFnIGNoYW5nZXMgaWYgYW55dGhpbmcgd2l0aGluIHRoYXQgZm9s ZGVyIGNoYW5nZXMpPEJSPjwvRElWPiogcmVxdWlyaW5nIENPUlMgaGVhZGVyczxCUj48L0RJVj4q IHJlcXVpcmluZyBhIFdlYkZpbmdlciBhbm5vdW5jZW1lbnQgZm9yIHNlcnZpY2UgZGlzY292ZXJ5 PEJSPjxCUj48L0RJVj5JdCB3b3VsZCBiZSBlYXN5IHRvIGFkZCB0aGVzZSB0aHJlZSB0aGluZ3Mg b24gdG9wIG9mIFdlYkRBViwgaW5zdGVhZCBvZiBwdXR0aW5nIHRoZW0gb24gdG9wIG9mIG91ciBt aW5pbWFsIEdFVC9QVVQvREVMRVRFIEFQSSBkZWZpbml0aW9uLiBJbiBmYWN0LCB3ZSBjb3VsZCBw cm9iYWJseSBzZXBhcmF0ZSBpdCBpbnRvIHR3byBJbnRlcm5ldC1EcmFmdHM6IG9uZSBmb3IgdGhl ICdSRVNUZnVsIGZvbGRlcnMnIEFQSSB3aGljaCBpcyBvdXIgc2ltcGxpZmljYXRpb24gb2YgV2Vi REFWLCBhbmQgYSBzZWNvbmQgb25lIGZvciBPQXV0aC9FVGFncy9DT1JTL1dlYkZpbmdlciBvbiB0 b3Agb2YgZWl0aGVyIFdlYkRBViBvciAnUkVTVGZ1bCBmb2xkZXJzJyBvciB3aGF0ZXZlciBvdGhl ciBIVFRQLWJhc2VkIEFQSSB5b3Ugd2FudC48QlI+PC9ESVY+CjxESVYgY2xhc3M9ImdtYWlsX2V4 dHJhIj48QlI+CjxESVYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIERlYyAyLCAyMDE1IGF0 IDExOjI4IEFNLCBIdWdvIEdvbnrDoWxleiBMYWJyYWRvciA8U1BBTiBkaXI9Imx0ciI+Jmx0OzxB IGhyZWY9Im1haWx0bzppZXRmQGh1Z28ubGFia29kZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRm QGh1Z28ubGFia29kZS5jb208L0E+Jmd0OzwvU1BBTj4gd3JvdGU6PEJSPgo8QkxPQ0tRVU9URSBz dHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBw eCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj48 VT48L1U+CjxESVY+PFNQQU4+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxE SVY+Jm5ic3A7PC9ESVY+CjxESVY+T24gV2VkLCBEZWMgMiwgMjAxNSwgYXQgMTE6MTggQU0sIExp bmh1aSBTdW4gd3JvdGU6PEJSPjwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4KPERJVj5I aTxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4KPERJViBzdHlsZT0iQ09MT1I6IHJn YigwLDAsMCkiPgo8RElWPk9uIOWRqOS4iSwgMTLmnIggMiwgMjAxNSBhdCAxNzo1NiwgSHVnbyBH b256w6FsZXogTGFicmFkb3IgJmx0OzxBIGhyZWY9Im1haWx0bzppZXRmQGh1Z28ubGFia29kZS5j b20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGh1Z28ubGFia29kZS5jb208L0E+Jmd0OyB3cm90ZTo8 QlI+PC9ESVY+CjxESVYgc3R5bGU9Ik9WRVJGTE9XOiB2aXNpYmxlIj4KPEJMT0NLUVVPVEUgc3R5 bGU9IkNPTE9SOiByZ2IoNDgsNTksNjQpIj4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4m bmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5PbiBXZWQsIERlYyAyLCAyMDE1LCBh dCAwODoyMCBBTSwgTGluaHVpIFN1biB3cm90ZTo8QlI+PC9ESVY+CjxCTE9DS1FVT1RFPgo8RElW IGRpcj0ibHRyIj4KPERJVj5IaTxCUj48L0RJVj4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJ Vj4KPERJVj4yMDE1LTEyLTAyIDU6MTQgR01UKzA4OjAwIEh1Z28gR29uesOhbGV6IExhYnJhZG9y IDxTUEFOIGRpcj0ibHRyIj4mbHQ7PEEgaHJlZj0ibWFpbHRvOmlldGZAaHVnby5sYWJrb2RlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAaHVnby5sYWJrb2RlLmNvbTwvQT4mZ3Q7PC9TUEFOPjo8 QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0 KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4 Ij4KPERJVj5IaSw8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+ZnJvbSBteSBwb2lu dCBvZiB2aWV3IHRoZSByZW1vdGVTdG9yYWdlIHByb2plY3QgYWRkcmVzc2VzIGEgc3Vic2V0IG9m PEJSPjwvRElWPgo8RElWPnRoZSB1c2UgY2FzZXMgb2YgdGhlJm5ic3A7IFdlYkRBViBzcGVjaWZp Y2F0aW9uLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5UaGUgbWFpbiBkaWZmZXJl bmNlIEkgY2FuIG9ic2VydmUgaXMgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBpcyBidWlsdCBvbjxC Uj48L0RJVj4KPERJVj5SRVNUIGluc3RlYWQgb2YgWE1MLWJhc2VkIGNvbW11bmljYXRpb24uPEJS PjwvRElWPjwvQkxPQ0tRVU9URT4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2Io MjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElO Ry1MRUZUOiAxZXgiPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkkgcGVyc29uYWxseSBsaWtlIG11 Y2ggbW9yZSBSRVNUIHRoYW4gV2ViREFWIGJlY2F1c2UgaXQgaXMgbW9yZTxCUj48L0RJVj4KPERJ Vj5kZXZlbG9wZXIgZnJpZW5kbHkgYW5kIGl0IGlzIGZhc3RlciB0byBkZXZlbG9wLjxCUj48L0RJ Vj4KPERJVj4mbmJzcDtNYXliZSB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgYmVjb21lcyB0aGUgbmV4 dCBXZWJEQVYgOik8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SG93ZXZlciwgdGhl IHJlbW90ZVN0b3JhZ2UgQVBJIGRvZXMgbm90IHByb3ZpZGUgYSB3YXkgb2Ygc3luY2hyb25pc2lu ZzxCUj48L0RJVj4KPERJVj5kYXRhLCB0aGlzIHRhc2sgaXMgZGVsZWdhdGVkIHRvIHRoZSBkZXZl bG9wZXJzLjxCUj48L0RJVj4KPERJVj5JcyB0aGVyZSBhIHBsYW4gdG8gcHJvdmlkZSBzdWNoIGZl YXR1cmUgYmFzZWQgb24gdGhlIG91dGNvbWUgb2YgdGhpczxCUj48L0RJVj4KPERJVj5kcmFmdD88 QlI+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPkknbSBhIGxpdHRsZSBiaXQgY29uZnVzZWQgd2h5 IHlvdSBzYXkgdGhlIHJlbW90ZVN0b3JhZ2UgZG9lcyBub3QgcHJvdmlkZSB0aGF0LiBJcyB0aGF0 IGJlY2F1c2UgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBwZXJmb3JtIGxpa2UgYSB0eXBpY2FsIHN5 bmMgc2VydmljZXMgKGUuZy4gZHJvcGJveC4uLikgb3IgeW91IGFyZSBzYXlpbmcgc29tZXRoaW5n IGVsc2U/PEJSPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj5ZZXMs IGJlY2F1c2UgaXQgZG9lcyBub3Qgb2ZmZXIgc3luY2hyb25pc2F0aW9uIGNhcGFiaWxpdGllcy48 QlI+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPkdvdCBpdC4gQW5kIFdoYXQgSSBhbSB3 b25kZXJpbmcgaXMgdGhhdCBkbyB3ZSBuZWVkIHRvIGluY2x1ZGUgdGhvc2UgY2FwYWJpbGl0aWVz IGluIGEgYmFzZSBzcGVjaWZpY2F0aW9ucy4gU2luY2UgaXQgaXMgaGFyZCB0byBzdGFuZGFyZGl6 ZSB0aGUgY2FwYWJpbGl0aWVzIGxpa2UgZGVkdXAgb3IgZGVsdGEuIE1heWJlIGEgYmV0dGVyIHdh eSBpcyB0byBkZWZpbmUgdGhvc2UgaW4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLCA8L0RJVj48 L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9TUEFOPjwvRElWPjwvQkxPQ0tRVU9URT4K PERJVj4KPERJVj48QlI+PC9ESVY+VGhhbmtzIGZvciBnaXZpbmcgdGhlc2UgZXhhbXBsZXMgLSBz byBieSAnc3luY2hyb25pc2F0aW9uIGNhcGFiaWxpdGllcycgeW91IG1lYW4gMSkgZGVkdXBsaWNh dGlvbiBhbmQgMikgZGVsdGEgdXBkYXRlcz8gQW55dGhpbmcgZWxzZSBvciBpcyB0aGF0IGFuIGV4 aGF1c3RpdmUgbGlzdD8gPEJSPjwvRElWPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6 IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQ QURESU5HLUxFRlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4KPERJVj48U1BBTj4KPEJMT0NL UVVPVEUgdHlwZT0iY2l0ZSI+CjxESVY+CjxESVYgc3R5bGU9IkNPTE9SOiByZ2IoMCwwLDApIj4K PERJViBzdHlsZT0iT1ZFUkZMT1c6IHZpc2libGUiPgo8RElWPnNvbWV0aGluZyBsaWtlIGV4dGVu c2lvbnMuIEZvciBhIGJhc2UgZG9jdW1lbnQsIHdlIGp1c3QgbmVlZCB0byBkZWZpbmUgaG93IHRv IHBlcmZvcm0gc3luYyBvcGVyYXRpb25zLjxCUj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JM T0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+PC9TUEFOPgo8RElWPlllcywgSSBhZ3JlZSB0aGF0 IG1heSBiZSBhbiBleHRlbnNpb24gb2YgdGhpcyBkcmFmdCBjb3VsZCBoYW5kbGUgdGhlIHN5bmNo cm9uaXNhdGlvbiBwYXJ0LiA8QlI+PC9ESVY+PFNQQU4+CjxESVY+Jm5ic3A7PC9ESVY+PC9TUEFO PjwvRElWPjwvQkxPQ0tRVU9URT48QlI+CjxESVY+T3VyIEludGVybmV0LURyYWZ0IGlzIGhlYXZp bHkgZm9jdXNlZCBvbiB0aGUgd29ybGQgd2lkZSB3ZWIsIHdob3NlIFVSTHMgYXJlIG5vdCBjb250 ZW50LWFkZHJlc3NhYmxlLCB3ZSBjYW4ndCBjaGFuZ2UgdGhhdC4gU28gdGhhdCBhcmNoaXRlY3R1 cmUgaXMgbm90IHZlcnkgZnJpZW5kbHkgdG8gZGVkdXBsaWNhdGlvbiwgY29tcGFyZWQgdG8gZm9y IGluc3RhbmNlIEJpdFRvcnJlbnQuIEFzIHlvdSBhbHJlYWR5IHNhaWQsIGRldmVsb3BlcnMgY2Fu IHN0aWxsIGRlZHVwZSBvbiB0aGUgc2VydmVyLXNpZGUgd2hlbiBzdG9yaW5nIGJsb2JzIHRvIGRp c2ssIGFuZCBjYW4gYWxzbyBkZWR1cGUgb24gdGhlIGNsaWVudCBzaWRlIGJlZm9yZSBjcmVhdGlu ZyB0aGUgcmVzb3VyY2VzIHRoZSBjbGllbnQgdXBsb2Fkcy48QlI+PEJSPjwvRElWPgo8RElWPkFz IGZhciBhcyBJIGtub3csIGRlbHRhIHVwZGF0ZXMgYXJlIG5vdCBzdXBwb3J0ZWQgYnkgdGhlIEVU YWcgc3lzdGVtIC0geW91IGNhbm5vdCBkbyBhIHJhbmdlIHJlcXVlc3QgdG8gZmluZCBvdXQgaWYg Y2VydGFpbiBieXRlcyB3aXRoaW4gYSBkb2N1bWVudCBoYXZlIGNoYW5nZWQuIEhvd2V2ZXIsIHRo ZSBmb2xkZXIgc3lzdGVtIHdlIGRlZmluZSBkb2VzIGVuY291cmFnZSB5b3UsIGZvciBpbnN0YW5j ZSB3aGVuIHlvdSBkZXZlbG9wIGEgVG8gRG8gTGlzdCBhcHAsIHB1dCBlYWNoIHRhc2sgb24gaXRz IG93biBkb2N1bWVudCwgYW5kIHRoZW4gcXVlcnkgdGhlIGZvbGRlciB0byBzZWUgd2hpY2ggb2Yg dGhlbSBjaGFuZ2VkLCBpbnN0ZWFkIG9mIHB1dHRpbmcgdGhlbSBhbGwgaW4gb25lIGJpZyBkb2N1 bWVudCBhbmQgcmV0cmlldmluZyB0aGUgd2hvbGUgZG9jdW1lbnQgZWFjaCB0aW1lLjxCUj48QlI+ PEJSPjwvRElWPgo8RElWPkNoZWVycyw8QlI+PC9ESVY+CjxESVY+TWljaGllbC48QlI+PC9ESVY+ CjxESVY+PEJSPjwvRElWPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQs MjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxF RlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4KPERJVj48U1BBTj4KPEJMT0NLUVVPVEUgdHlw ZT0iY2l0ZSI+CjxESVY+CjxESVYgc3R5bGU9IkNPTE9SOiByZ2IoMCwwLDApIj4KPERJViBzdHls ZT0iT1ZFUkZMT1c6IHZpc2libGUiPgo8QkxPQ0tRVU9URSBzdHlsZT0iQ09MT1I6IHJnYig0OCw1 OSw2NCkiPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URT4KPERJViBkaXI9Imx0 ciI+CjxESVY+CjxESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwy MDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVG VDogMWV4Ij4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5CVFcsIEkgd2FudCB0byBpbnRyb2R1Y2Ug Q2xhd0lPICg8QSBocmVmPSJodHRwOi8vY2xhd2lvLmdpdGh1Yi5pby8iIHRhcmdldD0iX2JsYW5r Ij48L0E+PEEgaHJlZj0iaHR0cDovL2NsYXdpby5naXRodWIuaW8vIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL2NsYXdpby5naXRodWIuaW88L0E+KSwgYSByZXNlYXJjaDxCUj48L0RJVj4KPERJVj5w cm9qZWN0IHRvIGJlbmNobWFyayBkaWZmZXJlbnQgc3luY2hyb25pc2F0aW9uIHByb3RvY29scyBh Z2FpbnN0PEJSPjwvRElWPgo8RElWPmRpZmZlcmVudCBkYXRhIGJhY2tlbmRzIHdpdGggc3BlY2lh bCBhdHRlbnRpb24gdG8gcHJvdmlkZSBhIGNvbW1vbiBzeW5jPEJSPjwvRElWPgo8RElWPkFQSS48 QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+QSBjb21tb24gQVBJIGZvciBkaWZmZXJl bnQgc3luYyBwcm90b2NvbHMgaXMgYmVpbmcgY3JlYXRlZCBiYXNlZCBvbiB0aGU8QlI+PC9ESVY+ CjxESVY+YXJjaGl0ZWN0dXJlIHNwZWNpZmllZCBpbiB0aGlzIGRyYWZ0IChjb250cm9sIGFuZCBk YXRhIHNlcnZlcnMpIGFuZCB0aGU8QlI+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPkkgY2Fubm90 IGZpbmQgYSBkaXN0cmlidXRlZCBhcmNoaXRlY3R1cmUgaW4gdGhpcyBkcmFmdC4gSXQgc2VlbXMg dGhhdCB0aGV5IGhhbmRsZSBtZXRhZGF0YSBhbmQgY29udGVudCBkYXRhIHRvZ2V0aGVyLCBqdXN0 IGxpa2UgYSBub3JtYWwgd2ViIHNlcnZpY2UuPEJSPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwv QkxPQ0tRVU9URT4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5DbGF3SU8gaXMgZnVsbHkgZGlzdHJp YnV0ZWQuIEV2ZXJ5IGxvZ2ljYWwgdW5pdCBpcyBhIGRpZmZlcmVudCBzZXJ2ZXIgdGhhbiBiZSBz Y2FsZWQgb3V0LiBEYXRhIGFuZCBNZXRhZGF0YSBjaGFubmVscyBhcmUgaW5kZXBlbmRlbnQgZnJv bSBlYWNoIG90aGVyIGFuZCByZXNpZGUgb24gZGlmZmVyZW50IHNlcnZlcnMuPEJSPjwvRElWPjwv RElWPjwvQkxPQ0tRVU9URT4KPERJVj5UaGF0IGlzIHdpZGVseSBlbXBsb3llZCBpbiBwb3B1bGFy IHN5bmMgc2VydmljZXMuIEFuZCB0aGF0IGlzIGFsc28gYmVuZWZpY2lhbCB0byBwcml2YWN5IHRv IHNvbWUgZXh0ZW50LiBCdXQgaW4gdGhlIGNvbnRleHQgb2Ygc3luYyBpbiBicm93c2VyICh3aGlj aCBpcyBtYWlubHkgY29uc2lkZXJlZCBpbiB0aGUgcmVtb3RlU3RvcmFnZSksIEkgZG9uJ3Qga25v dyB3aGV0aGVyIHRoaXMgaXMgcmVhc29uYWJsZS4gQnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGRlcGxv eSBkaXN0cmlidXRlZCBhcmNoaXRlY3R1cmUgYWx0aG91Z2ggaXQgd2lsbCBtYWtlIHRoaW5ncyBj b21wbGljYXRlZC48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElW PiZuYnNwOzwvRElWPjwvU1BBTj4KPERJVj5PZiBjb3Vyc2UsIHRoZSByZW1vdGVTdG9yYWdlIGlz IHRhcmdldGVkIHRvIGJyb3dzZXJzLCBzbyBzeW5jaW5nIGRvZXMgbm90IG1ha2UgdG9vIG11Y2gg c2Vuc2UgaW4gdGhpcyBjYXNlLjxCUj48L0RJVj4KPERJVj5XaXRoIHRoZSByaXNlIG9mIExpbnV4 IGNvbnRhaW5lciBtaWNyby1zZXJ2aWNlIGJhc2VkIGFyY2hpdGVjdHVyZXMsIHRoZSBkZXBsb3lt ZW50IG9mICZuYnNwO3N1Y2ggaGlnaGx5IGNvbXBsZXggc3lzdGVtcyBzaG91bGQgYmVjb21lIGVh c2llciBhbmQgZmFzdGVyLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5CZXN0LDxT UEFOPjxGT05UIGNvbG9yPSIjODg4ODg4Ij48QlI+PC9GT05UPjwvU1BBTj48L0RJVj48U1BBTj48 Rk9OVCBjb2xvcj0iIzg4ODg4OCI+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SHVnbzwvRElWPjwv Rk9OVD48L1NQQU4+CjxESVY+CjxESVYgY2xhc3M9Img1Ij4KPERJVj4mbmJzcDs8L0RJVj4KPEJM T0NLUVVPVEUgdHlwZT0iY2l0ZSI+CjxESVY+CjxESVYgc3R5bGU9IkNPTE9SOiByZ2IoMCwwLDAp Ij4KPERJViBzdHlsZT0iT1ZFUkZMT1c6IHZpc2libGUiPgo8RElWPlJlZ2FyZHMsPEJSPjwvRElW Pgo8RElWPkxpbmh1aSZuYnNwOzxCUj48L0RJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkNPTE9SOiBy Z2IoNDgsNTksNjQpIj4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4K PEJMT0NLUVVPVEU+CjxESVYgZGlyPSJsdHIiPgo8RElWPgo8RElWPgo8RElWPlJlZ2FyZHMsPEJS PjwvRElWPgo8RElWPkxpbmh1aTxCUj48L0RJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1M RUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhl eDsgUEFERElORy1MRUZUOiAxZXgiPgo8RElWPm9uZSBmcm9tIHRoZSBDRVJOIEVPUyBwcm9qZWN0 IChtYW5hZ2VtZW50LCBkaXNrIGFuZCBxdWV1ZSBzZXJ2ZXJzKS48QlI+PC9ESVY+CjxESVY+Jm5i c3A7PC9ESVY+CjxESVY+VGhlIFBoYXNlIEkgaGFzIGltcGxlbWVudGVkIHRoZSBvd25DbG91ZCBT eW5jIFByb3RvY29sIGFuZCBQaGFzZSBJSSB3aWxsPEJSPjwvRElWPgo8RElWPmltcGxlbWVudCB0 aGUgU2VhRmlsZSBTeW5jIFByb3RvY29sLjxCUj48L0RJVj4KPERJVj5UaGUgY2hvaWNlIG9mIHRo ZXNlIHByb3RvY29scyBhbW9uZyBvdGhlcnMgaXMgYmVjYXVzZSB0aGV5IGFyZSByZWFsbHk8QlI+ PC9ESVY+CjxESVY+b3Bwb3NlZCB0byBlYWNoIG90aGVyIGluIHRlcm1zIG9mIHN5bmNpbmcgKGRl bHRhIHZzIG5vbi1kZWx0YSw8QlI+PC9ESVY+CjxESVY+c3RhdGUtYmFzZWQgdnMgbG9nL2V2ZW50 L2dpdC1iYXNlZCBzeW5jIOKApiksIHNvIGZpbmRpbmcgYSBjb21tb24gYXBwcm9hY2g8QlI+PC9E SVY+CjxESVY+aXMgbW9yZSBjaGFsbGVuZ2luZy48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+ CjxESVY+UHJvdmlkaW5nIGEgYmFzZSBzcGVjaWZpY2F0aW9uL2FyY2hpdGVjdHVyZSB0byBtZWFz dXJlIHRoZSBmZWFzaWJpbGl0eTxCUj48L0RJVj4KPERJVj5vZiB0aGlzIGRyYWZ0IGlzIG9uZSBv ZiB0aGUgb2JqZWN0aXZlcyBvZiB0aGUgcHJvamVjdC48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9E SVY+CjxESVY+SSBiZWxpZXZlIHRoYXQgdGhlIHdvcmsgYmVpbmcgZG9uZSBoZXJlIGFuZCBpbiBD bGF3SU8gYXJlIHN1cHBsZW1lbnRhcnk8QlI+PC9ESVY+CjxESVY+dG8gZWFjaCBvdGhlciBhbmQg SSB0aGluayBtdXR1YWwgY29sbGFib3JhdGlvbiBjb3VsZCBiZSBiZW5lZmljaWFsIGZvcjxCUj48 L0RJVj4KPERJVj5ib3RoIHNpZGVzLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5B bHNvLCBpZiB0aGVyZSBpcyBpbnRlcmVzdCwgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGNhbiBiZSBh ZGRlZCB0bzxCUj48L0RJVj4KPERJVj5DbGF3SU8uPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElW Pgo8RElWPkJlc3QgcmVnYXJkcyw8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SHVn byBHb256YWxleiBMYWJyYWRvcjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5PbiBU dWUsIERlYyAxLCAyMDE1LCBhdCAwOTowMCBQTSwgPEEgaHJlZj0ibWFpbHRvOnN0b3JhZ2VzeW5j LXJlcXVlc3RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zdG9yYWdlc3luYy1yZXF1ZXN0QGll dGYub3JnPC9BPiB3cm90ZTo8QlI+PC9ESVY+CjxESVY+Jmd0OyBTZW5kIFN0b3JhZ2VzeW5jIG1h aWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bzxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PEEgaHJlZj0ibWFpbHRvOnN0b3JhZ2VzeW5jQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c3RvcmFnZXN5bmNAaWV0Zi5vcmc8L0E+PEJSPjwvRElWPgo8RElWPiZndDs8 QlI+PC9ESVY+CjxESVY+Jmd0OyBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBX b3JsZCBXaWRlIFdlYiwgdmlzaXQ8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3RvcmFnZXN5bmMiIHRhcmdldD0iX2JsYW5rIj48L0E+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmM8L0E+PEJSPjwvRElW Pgo8RElWPiZndDsgb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9y IGJvZHkgJ2hlbHAnIHRvPEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8QSBocmVmPSJtYWlsdG86c3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnN0b3JhZ2VzeW5jLXJlcXVlc3RAaWV0Zi5vcmc8L0E+PEJSPjwvRElWPgo8RElW PiZndDs8QlI+PC9ESVY+CjxESVY+Jmd0OyBZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdp bmcgdGhlIGxpc3QgYXQ8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxBIGhyZWY9Im1haWx0bzpzdG9yYWdlc3luYy1vd25lckBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnN0b3JhZ2VzeW5jLW93bmVyQGlldGYub3JnPC9BPjxCUj48L0RJVj4KPERJVj4mZ3Q7 PEJSPjwvRElWPgo8RElWPiZndDsgV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJq ZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYzxCUj48L0RJVj4KPERJVj4mZ3Q7IHRoYW4g IlJlOiBDb250ZW50cyBvZiBTdG9yYWdlc3luYyBkaWdlc3QuLi4iPEJSPjwvRElWPgo8RElWPiZn dDsgVG9kYXkncyBUb3BpY3M6PEJSPjwvRElWPgo8RElWPiZndDs8QlI+PC9ESVY+CjxESVY+Jmd0 OyZuYnNwOyAmbmJzcDsgMS4gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3Jh Z2UmbmJzcDsgJm5ic3A7IEludGVybmV0LURyYWZ0PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDthdmFpbGFibGUgKE1pY2hpZWwgZGUgSm9uZyk8QlI+PC9ESVY+ CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgMi4gUmU6IE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9u Zy1yZW1vdGVzdG9yYWdlIEludGVybmV0LURyYWZ0PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDthdmFpbGFibGUgKEdpaGFuIERpYXMpPEJSPjwvRElWPgo8RElW PiZndDsmbmJzcDsgJm5ic3A7IDMuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVt b3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdDxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7YXZhaWxhYmxlIChGZWkgU29uZyk8QlI+PC9ESVY+CjxESVY+Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj48L0RJVj4K PERJVj4mZ3Q7IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdDxCUj48L0RJVj4KPERJVj4mZ3Q7IDxB IGhyZWY9Im1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlN0b3Jh Z2VzeW5jQGlldGYub3JnPC9BPjxCUj48L0RJVj4KPERJVj4mZ3Q7IDxBIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMiIHRhcmdldD0iX2JsYW5r Ij48L0E+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9y YWdlc3luYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3RvcmFnZXN5bmM8L0E+PEJSPjwvRElWPgo8RElWPiZndDsgRW1haWwgaGFkIDMgYXR0 YWNobWVudHM6PEJSPjwvRElWPgo8RElWPiZndDsgKyBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9u IG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlPEJSPjwvRElWPgo8RElWPiZndDsgSW50ZXJu ZXQtRHJhZnQgYXZhaWxhYmxlPEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7MmsgKG1l c3NhZ2UvcmZjODIyKTxCUj48L0RJVj4KPERJVj4mZ3Q7ICsgUmU6IFtTdG9yYWdlc3luY10gTmV3 IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2U8QlI+PC9ESVY+CjxESVY+Jmd0 OyBJbnRlcm5ldC1EcmFmdCBhdmFpbGFibGU8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJz cDsxayAobWVzc2FnZS9yZmM4MjIpPEJSPjwvRElWPgo8RElWPiZndDsgKyBSZTogW1N0b3JhZ2Vz eW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZTxCUj48L0RJVj4K PERJVj4mZ3Q7IEludGVybmV0LURyYWZ0IGF2YWlsYWJsZTxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5i c3A7ICZuYnNwOzJrIChtZXNzYWdlL3JmYzgyMik8QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+ CjxESVY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ PC9ESVY+CjxESVY+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0PEJSPjwvRElWPgo8RElWPjxBIGhy ZWY9Im1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlN0b3JhZ2Vz eW5jQGlldGYub3JnPC9BPjxCUj48L0RJVj4KPERJVj48QSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jIiB0YXJnZXQ9Il9ibGFuayI+PC9BPjxB IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 b3JhZ2VzeW5jPC9BPjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9ESVY+PC9ESVY+PC9C TE9DS1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48L0RJ Vj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+ PC9CTE9DS1FVT1RFPjwvRElWPjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+ ------=_Part_41233_1733010373.1449133600595-- From nobody Thu Dec 3 01:14:15 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3166D1B3330 for ; Thu, 3 Dec 2015 01:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REZZ8S1_CmMJ for ; Thu, 3 Dec 2015 01:14:12 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id D57B71B333A for ; Thu, 3 Dec 2015 01:13:46 -0800 (PST) Received: by ajax-webmail-Jdweb4 (Coremail) ; Thu, 3 Dec 2015 17:15:27 +0800 (GMT+08:00) Date: Thu, 3 Dec 2015 17:15:27 +0800 (GMT+08:00) From: fsong@bjtu.edu.cn To: "Linhui Sun" Message-ID: <6e37a6c8.2c11.151671ffb15.Coremail.fsong@bjtu.edu.cn> In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41428_1478054699.1449134127891" X-Originating-IP: [106.2.233.19] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20150107(58648.7033.6860) Copyright (c) 2002-2015 www.mailtech.cn bjtu X-SendMailWithSms: false X-CM-TRANSID: eJ5wygDHqR4vCGBWWbgFAA--.2202W X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/1tbiAQIMB1R9XjYZnAACsO X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: storagesync , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= , Michiel de Jong , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:14:13 -0000 ------=_Part_41428_1478054699.1449134127891 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgTGluaHVpLAoKIAoKVGhhbmtzIGZvciBhc2tpbmchIE1heWJlIEkgZGlkbuKAmXQgZXhwcmVz cyBjbGVhcmx5LiBJIHRoaW5rIE1PVkUgaXMgZ29vZCBhbmQgbW9yZSB1c2VmdWwgZm9yIHN5bmNo cm9uaXphdGlvbi4KCkJ1dCBpZiB0aGlzIGRyYWZ0IG9ubHkgd2FudCB0byBpZGVudGlmeSB0aGUg YmFzaWMgZWxlbWVudHMgZm9yIHJlbW90ZVN0b3JhZ2UgYW5kIGxvb2sgZm9yIHRoZSBtaW5pbXVt IHNldCwgTU9WRSBzaG91bGQgYmUgZnVydGhlciBpbnZlc3RpZ2F0ZWQuCgpBZnRlciBhbGwsIGl0 IGNhbiBiZSByZXBsYWNlZCBieSBERUwgKyBVUExPQUQuCgoKCgotLS0tLeWOn+Wni+mCruS7ti0t LS0tCuWPkeS7tuS6ujogIkxpbmh1aSBTdW4iIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4K5Y+R6YCB 5pe26Ze0OiAyMDE15bm0MTLmnIgz5pelIOaYn+acn+WbmwrmlLbku7bkuro6IGZzb25nIDxmc29u Z0BianR1LmVkdS5jbj4K5oqE6YCBOiBzdG9yYWdlc3luYyA8c3RvcmFnZXN5bmNAaWV0Zi5vcmc+ LCBma29vbWFuIDxma29vbWFuQHR1eGVkLm5ldD4sICJNaWNoaWVsIGRlIEpvbmciIDxtYmRlam9u Z0Btb3ppbGxhLmNvbT4sICJIdWdvIEdvbnrDoWxleiBMYWJyYWRvciIgPGlldGZAaHVnby5sYWJr b2RlLmNvbT4K5Li76aKYOiBSZTogW1N0b3JhZ2VzeW5jXSBTdG9yYWdlc3luYyBEaWdlc3QsIFZv bCA1LCBJc3N1ZSAxCgoKCgoKCjIwMTUtMTItMDMgMTY6NDAgR01UKzA4OjAwIDxmc29uZ0BianR1 LmVkdS5jbj46CgoKSGkgTWljaGFlbCwKCiAKCkJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbiBvbiBo dHRwOi8vcmVtb3Rlc3RvcmFnZS5pby8g4oCccmVtb3RlU3RvcmFnZS1lbmFibGVkIGFwcHMgYXV0 b21hdGljYWxseSBzeW5jIHlvdXIgZGF0YSBhY3Jvc3MgYWxsIG9mIHlvdXIgZGV2aWNlc+KAnS4K CiAKCkhvd2V2ZXIsIHRoZXJlIGlzIG5vIHN5bmNocm9uaXphdGlvbiBpbiB0aGUgYWJzdHJhY3Qu CgrigJxUaGUgcHJvdG9jb2wgc3VwcG9ydHMgc3RvcmluZywgcmV0cmlldmluZywgYW5kIHJlbW92 aW5nIGluZGl2aWR1YWwgZG9jdW1lbnRzLCBhcyB3ZWxsIGFzIGxpc3RpbmcgdGhlIGNvbnRlbnRz IG9mIGFuIGluZGl2aWR1YWwgZm9sZGVyLCBhbmQgYWNjZXNzIGNvbnRyb2wgaXMgYmFzZWQgb24g YmVhcmVyIHRva2Vuc+KAnQoKIAoKVGhlcmVmb3JlLCBJIHRoaW5rOgoKSWYgc3luY2hyb25pemF0 aW9uIGlzIGFkZGVkIGludG8gYWJzdHJhY3QsIHRoZSBNT1ZFIGFjdGlvbiBzaG91bGQgYmUgYWRk ZWQgZm9yIHN1cmUuCgpJZiBzeW5jaHJvbml6YXRpb24gaXMgbm90IGluY2x1ZGVkLCBsaWtlIGN1 cnJlbnQgdmVyc2lvbiwgdGhlIGJhc2ljIGFjdGlvbnMgaW4gZHJhZnQgYXJlIGVub3VnaC4KCkkg ZG9uJ3Qga25vdyB3aHkgTU9WRSBzaG91bGQgYmUgdGllZCB0byB0aGUg4oCcc3luY2hyb25pemF0 aW9u4oCdLiBJdCBzZWVtcyB0aGF0IG9ubHkgc3luYyBhbGxvd3MgTU9WRSB0byBiZSB1c2VkLgoK ClJlZ2FyZHMsCkxpbmh1aQ== ------=_Part_41428_1478054699.1449134127891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdp bmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BB TiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXpl OiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPkhpIExpbmh1aSw8bzpw PjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0la RTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+PG86cD48Rk9O VCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4KPFAgc3R5bGU9 IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3 aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0i Q09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIg bGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPlRoYW5rcyBmb3IgYXNraW5nISBNYXli ZSBJIGRpZG7igJl0IGV4cHJlc3MgY2xlYXJseS4gPC9GT05UPjwvU1BBTj48U1BBTiBzdHlsZT0i Q09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIg bGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPkkgdGhpbmsgTU9WRSBpcyBnb29kIGFu ZCBtb3JlIHVzZWZ1bCBmb3Igc3luY2hyb25pemF0aW9uLiA8bzpwPjwvbzpwPjwvRk9OVD48L1NQ QU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg bXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1m b250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+QnV0IGlm IHRoaXMgZHJhZnQgb25seSB3YW50IHRvIGlkZW50aWZ5IHRoZSBiYXNpYyBlbGVtZW50cyBmb3Ig cmVtb3RlU3RvcmFnZSBhbmQgbG9vayBmb3ImbmJzcDt0aGUgbWluaW11bSBzZXQsIE1PVkUgc2hv dWxkIGJlIGZ1cnRoZXIgaW52ZXN0aWdhdGVkLjwvRk9OVD48L1NQQU4+PC9QPgo8UCBzdHlsZT0i VEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdp ZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJD T0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDYuMHB0IiBs YW5nPSJFTi1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+QWZ0ZXIgYWxsLCBpdCBjYW4gYmUgcmVw bGFjZWQgYnkgREVMICsgVVBMT0FELjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+PEJSPjxC Uj48QlI+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogI2I2YjZiNiAycHggc29saWQ7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCIg bmFtZT0icmVwbHlDb250ZW50Ij4tLS0tLeWOn+Wni+mCruS7ti0tLS0tPEJSPjxCPuWPkeS7tuS6 ujo8L0I+ICJMaW5odWkgU3VuIiAmbHQ7bGguc3VubGluaEBnbWFpbC5jb20mZ3Q7PEJSPjxCPuWP kemAgeaXtumXtDo8L0I+IDIwMTXlubQxMuaciDPml6Ug5pif5pyf5ZubPEJSPjxCPuaUtuS7tuS6 ujo8L0I+IGZzb25nICZsdDtmc29uZ0BianR1LmVkdS5jbiZndDs8QlI+PEI+5oqE6YCBOjwvQj4g c3RvcmFnZXN5bmMgJmx0O3N0b3JhZ2VzeW5jQGlldGYub3JnJmd0OywgZmtvb21hbiAmbHQ7Zmtv b21hbkB0dXhlZC5uZXQmZ3Q7LCAiTWljaGllbCBkZSBKb25nIiAmbHQ7bWJkZWpvbmdAbW96aWxs YS5jb20mZ3Q7LCAiSHVnbyBHb256w6FsZXogTGFicmFkb3IiICZsdDtpZXRmQGh1Z28ubGFia29k ZS5jb20mZ3Q7PEJSPjxCPuS4u+mimDo8L0I+IFJlOiBbU3RvcmFnZXN5bmNdIFN0b3JhZ2VzeW5j IERpZ2VzdCwgVm9sIDUsIElzc3VlIDE8QlI+PEJSPgo8RElWIGRpcj0ibHRyIj48QlI+CjxESVYg Y2xhc3M9ImdtYWlsX2V4dHJhIj48QlI+CjxESVYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE1LTEy LTAzIDE2OjQwIEdNVCswODowMCA8U1BBTiBkaXI9Imx0ciI+Jmx0OzxBIGhyZWY9Im1haWx0bzpm c29uZ0BianR1LmVkdS5jbiIgdGFyZ2V0PSJfYmxhbmsiPmZzb25nQGJqdHUuZWR1LmNuPC9BPiZn dDs8L1NQQU4+OjxCUj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiAjY2NjIDFweCBz b2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIGNsYXNz PSJnbWFpbF9xdW90ZSI+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAw Y20gMHB0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkNPTE9S OiBibGFjazsgRk9OVC1TSVpFOiA5cHQiIGxhbmc9IkVOLVVTIj48Rk9OVCBmYWNlPSJDYWxpYnJp Ij5IaSBNaWNoYWVsLDxVPjwvVT48VT48L1U+PC9GT05UPjwvU1BBTj48L1A+CjxQIHN0eWxlPSJU RVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQiIGxh bmc9IkVOLVVTIj48VT48L1U+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9GT05UPjxVPjwv VT48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNt IDBwdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjog YmxhY2s7IEZPTlQtU0laRTogOXB0IiBsYW5nPSJFTi1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+ QmFzZWQgb24gdGhlIGRlc2NyaXB0aW9uIG9uIDwvRk9OVD48QSBocmVmPSJodHRwOi8vcmVtb3Rl c3RvcmFnZS5pby8iIHRhcmdldD0iX2JsYW5rIj48VT48Rk9OVCBjb2xvcj0iIzAwMDBmZiIgZmFj ZT0iQ2FsaWJyaSI+aHR0cDovL3JlbW90ZXN0b3JhZ2UuaW8vPC9GT05UPjwvVT48L0E+PEZPTlQg ZmFjZT0iQ2FsaWJyaSI+IOKAnHJlbW90ZVN0b3JhZ2UtZW5hYmxlZCBhcHBzIGF1dG9tYXRpY2Fs bHkgc3luYyB5b3VyIGRhdGEgYWNyb3NzIGFsbCBvZiB5b3VyIGRldmljZXPigJ0uIDxVPjwvVT48 VT48L1U+PC9GT05UPjwvU1BBTj48L1A+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJH SU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5 bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQiIGxhbmc9IkVOLVVTIj48VT48L1U+PEZP TlQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9GT05UPjxVPjwvVT48L1NQQU4+PC9QPgo8UCBzdHls ZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0 IiBsYW5nPSJFTi1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+SG93ZXZlciwgdGhlcmUgaXMgbm8g c3luY2hyb25pemF0aW9uIGluIHRoZSBhYnN0cmFjdC4gPFU+PC9VPjxVPjwvVT48L0ZPTlQ+PC9T UEFOPjwvUD4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQi IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDlwdCIgbGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPuKAnFRo ZSBwcm90b2NvbCBzdXBwb3J0cyBzdG9yaW5nLCByZXRyaWV2aW5nLCBhbmQgcmVtb3ZpbmcgaW5k aXZpZHVhbCBkb2N1bWVudHMsIGFzIHdlbGwgYXMgbGlzdGluZyB0aGUgY29udGVudHMgb2YgYW4g aW5kaXZpZHVhbCBmb2xkZXIsIGFuZCBhY2Nlc3MgY29udHJvbCBpcyBiYXNlZCBvbiBiZWFyZXIg dG9rZW5z4oCdPFU+PC9VPjxVPjwvVT48L0ZPTlQ+PC9TUEFOPjwvUD4KPFAgc3R5bGU9IlRFWFQt QUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdCIgbGFuZz0i RU4tVVMiPjxVPjwvVT48Rk9OVCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L0ZPTlQ+PFU+PC9VPjwv U1BBTj48L1A+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0 IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFj azsgRk9OVC1TSVpFOiA5cHQiIGxhbmc9IkVOLVVTIj48Rk9OVCBmYWNlPSJDYWxpYnJpIj5UaGVy ZWZvcmUsIEkgdGhpbms6PFU+PC9VPjxVPjwvVT48L0ZPTlQ+PC9TUEFOPjwvUD4KPFAgc3R5bGU9 IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdCIg bGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPklmIHN5bmNocm9uaXphdGlvbiBpcyBh ZGRlZCBpbnRvIGFic3RyYWN0LCB0aGUgTU9WRSBhY3Rpb24gc2hvdWxkIGJlIGFkZGVkIGZvciBz dXJlLjxVPjwvVT48VT48L1U+PC9GT05UPjwvU1BBTj48L1A+CjxQIHN0eWxlPSJURVhULUFMSUdO OiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVm dCI+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQiIGxhbmc9IkVOLVVT Ij48Rk9OVCBmYWNlPSJDYWxpYnJpIj5JZiBzeW5jaHJvbml6YXRpb24gaXMgbm90IGluY2x1ZGVk LCBsaWtlIGN1cnJlbnQgdmVyc2lvbiwgdGhlIGJhc2ljIGFjdGlvbnMgaW4gZHJhZnQgYXJlIGVu b3VnaC48L0ZPTlQ+PC9TUEFOPjwvUD48L0JMT0NLUVVPVEU+CjxESVY+SSBkb24ndCBrbm93IHdo eSBNT1ZFIHNob3VsZCBiZSB0aWVkIHRvIHRoZSDigJxzeW5jaHJvbml6YXRpb27igJ0uIEl0IHNl ZW1zIHRoYXQgb25seSBzeW5jIGFsbG93cyBNT1ZFIHRvIGJlIHVzZWQuPC9ESVY+CjxESVY+PEJS PjwvRElWPgo8RElWPlJlZ2FyZHMsPC9ESVY+CjxESVY+TGluaHVpPC9ESVY+PC9ESVY+PC9ESVY+ PC9ESVY+PC9CTE9DS1FVT1RFPg== ------=_Part_41428_1478054699.1449134127891-- From nobody Thu Dec 3 01:29:27 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85D51A8876 for ; Thu, 3 Dec 2015 01:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi_-46vX1-Xl for ; Thu, 3 Dec 2015 01:29:18 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 8C56D1A877B for ; Thu, 3 Dec 2015 01:29:16 -0800 (PST) Received: by ajax-webmail-Jdweb3 (Coremail) ; Thu, 3 Dec 2015 17:31:51 +0800 (GMT+08:00) Date: Thu, 3 Dec 2015 17:31:51 +0800 (GMT+08:00) From: fsong@bjtu.edu.cn To: "Michiel de Jong" Message-ID: <5ca31214.2c3d.151672efcf7.Coremail.fsong@bjtu.edu.cn> In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41660_1275101042.1449135111401" X-Originating-IP: [106.2.233.19] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20150107(58648.7033.6860) Copyright (c) 2002-2015 www.mailtech.cn bjtu X-SendMailWithSms: false X-CM-TRANSID: d55wygBHshIHDGBW5cEFAA--.1257W X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/1tbiAQEMB1R9XjYafgABsv X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: Linhui Sun , storagesync , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:29:22 -0000 ------=_Part_41660_1275101042.1449135111401 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 R3JlYXTvvIEKCgotLS0tLeWOn+Wni+mCruS7ti0tLS0tCuWPkeS7tuS6ujogIk1pY2hpZWwgZGUg Sm9uZyIgPG1iZGVqb25nQG1vemlsbGEuY29tPgrlj5HpgIHml7bpl7Q6IDIwMTXlubQxMuaciDPm l6Ug5pif5pyf5ZubCuaUtuS7tuS6ujogZnNvbmdAYmp0dS5lZHUuY24K5oqE6YCBOiAiTGluaHVp IFN1biIgPGxoLnN1bmxpbmhAZ21haWwuY29tPiwgc3RvcmFnZXN5bmMgPHN0b3JhZ2VzeW5jQGll dGYub3JnPiwgZmtvb21hbiA8Zmtvb21hbkB0dXhlZC5uZXQ+LCAiSHVnbyBHb256w6FsZXogTGFi cmFkb3IiIDxpZXRmQGh1Z28ubGFia29kZS5jb20+CuS4u+mimDogUmU6IFtTdG9yYWdlc3luY10g U3RvcmFnZXN5bmMgRGlnZXN0LCBWb2wgNSwgSXNzdWUgMQoKClllcyEgSSdsbCBkaXNjdXNzIHdp dGggRnJhbmNvaXMgaG93IHdlIGNhbiBtYWtlIHRoZXNlIGJvdW5kYXJpZXMgY2xlYXJlci4gTWF5 YmUgd2UgY2FuIHNwbGl0IGFsb25nIHRoZXNlIGxpbmVzOgoKCiogdXBsb2FkL21hbmlwdWxhdGUv cXVlcnkvZG93bmxvYWQgcHJvdG9jb2wgKGUuZy4gV2ViREFWIG9yIHRoZSBHRVQvUFVUL0RFTEVU RSBvcGVyYXRpb25zIHdlIGN1cnJlbnRseSBkZWZpbmUpCgoqIENPUlMgb3Igb3RoZXIgY3Jvc3Mt b3JpZ2luIGFjY2VzcyBtZWNoYW5pc20sIE9BVVRIIG9yIG90aGVyIGF1dGggbWVjaGFuaXNtLCBX ZWJGaW5nZXIgb3Igb3RoZXIgZGlzY292ZXJ5IG1lY2hhbmlzbSwgRVRhZyBvciBvdGhlciB2ZXJz aW9uaW5nIG1lY2hhbmlzbQoKKiBjaHVua2luZy9kZWR1cGluZy9kZWx0YS11cGRhdGVzCgoKQW5k IHRoZSByZW1vdGVTdG9yYWdlIHNwZWMgc2hvdWxkIHByb2JhYmx5IG9ubHkgZGVmaW5lIHRoZSBt aWRkbGUgcGFydC4KCgoKCgpPbiBUaHUsIERlYyAzLCAyMDE1IGF0IDk6NDQgQU0sIDxmc29uZ0Bi anR1LmVkdS5jbj4gd3JvdGU6CgoKSGkgTWljaGllbCBhbmQgTGluaHVpLAoKSSB0aGluayBpdCB3 aWxsIGJlIGdvb2QgdG8gaGF2ZSBhIGJvdW5kYXJ5IGZvciB0aGlzIGRyYWZ0IGFuZCBsZWF2ZSBz b21lIHdvcmsgZm9yIHRoZSBhcHBsaWNhaXRvbiBsYXllcn4KCgoKLS0tLS3ljp/lp4vpgq7ku7Yt LS0tLQrlj5Hku7bkuro6ICJNaWNoaWVsIGRlIEpvbmciIDxtYmRlam9uZ0Btb3ppbGxhLmNvbT4K 5Y+R6YCB5pe26Ze0OiAyMDE15bm0MTLmnIgy5pelIOaYn+acn+S4iQrmlLbku7bkuro6ICJMaW5o dWkgU3VuIiA8bGguc3VubGluaEBnbWFpbC5jb20+CuaKhOmAgTogc3RvcmFnZXN5bmMgPHN0b3Jh Z2VzeW5jQGlldGYub3JnPiwgZmtvb21hbiA8Zmtvb21hbkB0dXhlZC5uZXQ+LCAiSHVnbyBHb256 w6FsZXogTGFicmFkb3IiIDxpZXRmQGh1Z28ubGFia29kZS5jb20+CuS4u+mimDogUmU6IFtTdG9y YWdlc3luY10gU3RvcmFnZXN5bmMgRGlnZXN0LCBWb2wgNSwgSXNzdWUgMQoKCkFoIHN1cmUsIHRo YXQncyBlbnRpcmVseSBhcHByb3ByaWF0ZSwgcmVtb3RlU3RvcmFnZSB0cmVhdHMgYm90aCB0aGUg Q29udGVudC1UeXBlIGhlYWRlciB2YWx1ZSBhbmQgdGhlIGFjdHVhbCBib2R5IG9mIGEgZG9jdW1l bnQgYXMgb3BhcXVlIHN0cmluZ3Mgb2YgYnl0ZXMuIEl0IGRvZXNuJ3QgImNhcmUiIGlmIHlvdSB1 c2UgaXQgdG8gc3RvcmUgb25seSBkYXRhIGJsb2NrcyB0aGF0IGFyZSBjaHVua3Mgb2Ygc29tZXRo aW5nIGVsc2UuCgoKRm9yIGluc3RhbmNlLCB5b3UgY291bGQgaGF2ZSBhIGZvbGRlciBvbiBhIHVz ZXIncyBzdG9yYWdlIHRoYXQgY29udGFpbnMgb25seSBpbm9kZS1saWtlIEpTT04tZG9jdW1lbnRz LCB3aGljaCBsaXN0IHRoZSBVUkxzIG9mIGJpbmFyeSBkb2N1bWVudHMgdGhhdCBtYWtlIHVwIDFL YiBibG9ja3Mgb2YgdGhlIGFjdHVhbCBkYXRhLiBOaWNlIGZvciBkZWR1cGluZywgZGVsdGEgdXBk YXRlcywgYW5kIGFsc28gcmVuYW1pbmcgZmlsZXMgd2l0aG91dCByZXVwbG9hZGluZyB0aGVpciBj b250ZW50LgoKCgpCdXQgeWVhaCwgdGhlIGFyZ3VtZW50IGlzIHRoYXQgKmhvdyogdG8gY3JlYXRl IGFuZCBtYW5hZ2UgdGhlc2UgY2h1bmtzLCBpcyB0aGVuIHN0aWxsIGxlZnQgdXAgdG8gdGhlIGFw cGxpY2F0aW9uIGRldmVsb3BlciAob3IgdG8gYW5vdGhlciBzcGVjIG9uIHRvcCBvZiB0aGUgcmVt b3RlU3RvcmFnZSBzcGVjKS4KCgoKQ2hlZXJzLAoKTWljaGllbC4KCgoKT24gV2VkLCBEZWMgMiwg MjAxNSBhdCAzOjI5IFBNLCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4gd3JvdGU6 CgpIaQoKCjIwMTUtMTItMDIgMjI6MDUgR01UKzA4OjAwIE1pY2hpZWwgZGUgSm9uZyA8bWJkZWpv bmdAbW96aWxsYS5jb20+OgoKQ29vbCEgSSBjcmVhdGVkIGh0dHBzOi8vZ2l0aHViLmNvbS9yZW1v dGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzNyBhYm91dCB0aGUgbmVlZCBmb3IgIE1PVkUgdmVyYi4K CgpBcHBsaWNhdGlvbi1sZXZlbCBjaHVua2luZyBpcyBwYXJ0aWFsbHkgc3VwcG9ydGVkIGJ5IEhU VFAgaXRzZWxmIHRocm91Z2ggYENvbnRlbnQtUmFuZ2VgIGhlYWRlcnMgKGFsdGhvdWdoIGl0J3Mg bm90IGNsZWFyIHdoZXRoZXIgdGhlc2UgYXJlIGFsbG93ZWQgb24gUFVUIHJlcXVlc3RzIGFzIHdl bGwgYXMgb24gR0VUIHJlcXVlc3RzLCBzZWUgaHR0cHM6Ly9naXRodWIuY29tL3JlbW90ZXN0b3Jh Z2Uvc3BlYy9pc3N1ZXMvMTMxKS4gVGhlIHByb2JsZW0gaXMgdGhhdCBIVFRQIGRlZmluZXMgdmVy c2lvbmluZyBhdCB0aGUgZG9jdW1lbnQgbGV2ZWwsIHlvdSBjYW5ub3QgYXNrIGEgc2VydmVyIHRv IHByb2R1Y2Ugb3IgY2hlY2sgYW4gRVRhZyBmb3IgYSBzcGVjaWZpYyBieXRlLXJhbmdlIG9mIGEg ZG9jdW1lbnQsIG9ubHkgZm9yIHRoZSBlbnRpcmUgZG9jdW1lbnQuCgpBY3R1YWxseSB3aGF0IEkn bSBzYXlpbmcgaXMgYSBjaHVua2luZyBiZWZvcmUgdHJhbnNtaXR0aW5nICh1c2luZyBodHRwKSwg aW4gdGhpcyB3YXksIHRoZXkgYXJlIHRyZWF0ZWQgYXMgaW5kaXZpZHVhbCBkb2N1bWVudHMgZnJv bSB0aGUgc3RhbmRwb2ludCBvZiBodHRwLiBCdXQgSSBkb24ndCBrbm93IHdoZXRoZXIgdGhpcyBp cyBhcHByb3ByaWF0ZSBmb3IgcmVtb3RlU3RvcmFnZSwganVzdCBhIGNvbW1lbnQuCgoKUmVnYXJk cywKTGluaHVpCgoKQSBjb21wYXJpc29uIGRvY3VtZW50IHNvdW5kcyBnb29kISBTZWUgYWxzbyBo dHRwOi8vd3d3LnNlcnZpY2VkZW51YWdlcy5mci9lbi9nZW5lcmljLXN0b3JhZ2UtZWNvc3lzdGVt LgoKCgpDaGVlcnMsCgpNaWNoaWVsLgoKCgoKT24gV2VkLCBEZWMgMiwgMjAxNSBhdCAyOjMyIFBN LCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4gd3JvdGU6CgpUaGF0J3MgY29vbCBm b3IgbWUsIGEgc2VwYXJhdGUgc2VjdGlvbiBmb3IgdGhpcyBtaWdodCBtYWtlIHNlbnNlLgoKCkFu b3RoZXIgdGhpbmcgaXMgZG8gd2UgbmVlZCB0byBpbmNsdWRlIGFuIGFwcGxpY2F0aW9uLWxheWVy IGNodW5raW5nIGhlcmUgKG5vdCBqdXN0IGZvciBhIGJyb3dzZXIgc3luYyksIHNpbmNlIGlmIHdl IHdhbnQgdG8gZnVydGhlciBleHRlbmQgb3RoZXIgY2FwYWJpbGl0aWVzIGl0IGlzIGVzc2VudGlh bC4KCgoKUmVnYXJkcywKTGluaHVpCgoKMjAxNS0xMi0wMiAyMTowMyBHTVQrMDg6MDAgSHVnbyBH b256w6FsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT46CgpJIHByb3Bvc2UgdG8g Y29tZSB1cCB3aXRoIGEgbGlzdCBvZiBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIG9mIHVz aW5nIFdlYkRBViBhbmQgY29tcGFyZSB0aGVtIGFnYWluc3QgYSBKU09OL1JFU1QgYmFzZWQgYXBw cm9hY2gsIGxpa2UgcmVtb3RlU3RvcmFnZS4KCiAKRG9lcyBpdCBzb3VuZCBnb29kID8KIAogCk9u IFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjU5IFBNLCBMaW5odWkgU3VuIHdyb3RlOgoKIAogCjIw MTUtMTItMDIgMjA6NDMgR01UKzA4OjAwIEh1Z28gR29uesOhbGV6IExhYnJhZG9yIDxpZXRmQGh1 Z28ubGFia29kZS5jb20+OgoKCgogCiAKIAogCk9uIFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjMw IFBNLCBNaWNoaWVsIGRlIEpvbmcgd3JvdGU6CgpIaSBhbGwhCgpUaGFua3MgZm9yIGFsbCB5b3Vy IHJlYWN0aW9ucyB0byB0aGUgcmVtb3RlU3RvcmFnZSBJbnRlcm5ldC1EcmFmdC4KCiAKV2UgZ2V0 IHRoZSBxdWVzdGlvbiBhYm91dCBXZWJEQVYgYSBsb3QsIGluIHRoZSBuZXh0IHZlcnNpb24gd2Ug c2hvdWxkIGFkZCBhIHJlbWFyayBhYm91dCBpdCBpbiB0aGUgaW50cm8uIFRoZSBmb2xkZXIgZGVz Y3JpcHRpb25zIHJldHVybmVkIHdoZW4geW91IEdFVCBhIFVSTCB0aGF0IGVuZHMgd2l0aCBhIC8g YXJlIGluZGVlZCBhIGRldmlhdGlvbiBmcm9tIHRoZSBYTUwgcmV0dXJuZWQgYnkgV2ViREFWIHNl cnZlciwgYW5kIHRoaXMgaXMganVzdCBiZWNhdXNlIG5vd2FkYXlzIEpTT04gaXMgZWFzaWVyIHRv IHVzZSB0aGFuIFhNTCBmb3IgZGV2ZWxvcGVycywgYm90aCBjbGllbnQtc2lkZSBhbmQgc2VydmVy LXNpZGUuCgogCiAKSSB0b3RhbGx5IGFncmVlIGhlcmUsIHRoaXMgd2FzIGdvaW5nIHRvIGhhcHBl biBzb29uIG9yIGxhdGVyIGFuZCBpdCBpcyByZWFsbHkgYXBwcmVjaWF0ZWQuCgogCiAKVGhlIGZh Y3QgdGhhdCB3ZSBkb24ndCByZXF1aXJlIHNlcnZlcnMgdG8gc3VwcG9ydCBXZWJEQVYncyBjdXN0 b20gdmVyYnMgbGlrZSBQUk9QUEFUQ0ggZXRjLiBpcyBmb3IgdGhyZWUgcmVhc29uczoKCjEpIGl0 J3MgYSBsb3Qgb2Ygd29yayB0byBpbXBsZW1lbnQgdGhpcyB3aXRob3V0IHVzaW5nIGFuIGV4aXN0 aW5nIFdlYkRBViBsaWJyYXJ5CgoyKSBpbiBwcmFjdGljZSwgYSBsb3Qgb2YgV2ViREFWIHNlcnZl cnMgZ2V0IGl0IHdyb25nLCBvciBkb24ndCBpbXBsZW1lbnQgYWxsIG9mIFdlYkRBVi4gSXQncyB2 ZXJ5IGFubm95aW5nIGZvciBjbGllbnQgaW1wbGVtZW50ZXJzIHRvIGhhdmUgdG8gZGVhbCB3aXRo IHNlcnZlcnMgdGhhdCBlLmcuIGNob3NlIG5vdCB0byBpbXBsZW1lbnQgTE9DSyBhbmQgVU5MT0NL LgoKMykgd2UgZG9uJ3QgcmVhbGx5IG5lZWQgYWxsIHRoZXNlIGFkdmFuY2VkIGZlYXR1cmVzIG9u IHRvcCBvZiBzdGFuZGFyZCBIVFRQLCBqdXN0IHN1cHBvcnRpbmcgR0VUL1BVVC9ERUxFVEUgZm9y IHJlc291cmNlcywgYW5kIGFkZGluZyBhIHNpbXBsZSBmb2xkZXIgZGVzY3JpcHRpb24gZm9ybWF0 LCBpcyBlbm91Z2ggZm9yIG1vc3QgYXBwbGljYXRpb25zLgoKIApPdGhlciB0aGFuIHRoYXQsIHRo ZSByZW1vdGVTdG9yYWdlIEludGVybmV0LURyYWZ0IHNwZWNpZmllcyBhICpsb3QqIG1vcmUgdGhh biBqdXN0IGhvdyBlYWNoIEhUVFAgdmVyYiBzaG91bGQgYmVoYXZlOgoKKiByZXF1aXJpbmcgc3Vw cG9ydCBmb3IgT0F1dGggaW1wbGljaXQtZ3JhbnQgZmxvdwoKKiByZXF1aXJpbmcgRVRhZyBzdXBw b3J0IGFuZCBuZXN0ZWQgdmVyc2lvbmluZyAoaS5lLiB0aGUgZm9sZGVyJ3MgRVRhZyBjaGFuZ2Vz IGlmIGFueXRoaW5nIHdpdGhpbiB0aGF0IGZvbGRlciBjaGFuZ2VzKQoKKiByZXF1aXJpbmcgQ09S UyBoZWFkZXJzCgoqIHJlcXVpcmluZyBhIFdlYkZpbmdlciBhbm5vdW5jZW1lbnQgZm9yIHNlcnZp Y2UgZGlzY292ZXJ5CgpJdCB3b3VsZCBiZSBlYXN5IHRvIGFkZCB0aGVzZSB0aHJlZSB0aGluZ3Mg b24gdG9wIG9mIFdlYkRBViwgaW5zdGVhZCBvZiBwdXR0aW5nIHRoZW0gb24gdG9wIG9mIG91ciBt aW5pbWFsIEdFVC9QVVQvREVMRVRFIEFQSSBkZWZpbml0aW9uLiBJbiBmYWN0LCB3ZSBjb3VsZCBw cm9iYWJseSBzZXBhcmF0ZSBpdCBpbnRvIHR3byBJbnRlcm5ldC1EcmFmdHM6IG9uZSBmb3IgdGhl ICdSRVNUZnVsIGZvbGRlcnMnIEFQSSB3aGljaCBpcyBvdXIgc2ltcGxpZmljYXRpb24gb2YgV2Vi REFWLCBhbmQgYSBzZWNvbmQgb25lIGZvciBPQXV0aC9FVGFncy9DT1JTL1dlYkZpbmdlciBvbiB0 b3Agb2YgZWl0aGVyIFdlYkRBViBvciAnUkVTVGZ1bCBmb2xkZXJzJyBvciB3aGF0ZXZlciBvdGhl ciBIVFRQLWJhc2VkIEFQSSB5b3Ugd2FudC4KCiAKIApUaGVyZSBpcyBvbmUgcmVxdWlyZW1lbnQg dGhhdCBhbGwgc3luY2hyb25pc2VycyBuZWVkIHRvIGhhbmRsZTogbW92aW5nIHJlc291cmNlcy4g SW4gdGhpcyBzcGVjIHRoZSBhbHRlcm5hdGl2ZSBvZiBhIFdlYkRBViBNT1ZFIGlzIG5vdCBzcGVj aWZpZWQuIAoKIApJdCBpcyB0cnVlIHRoYXQgYSBNT1ZFIGNvdWxkIGJlIHJlcGxhY2VkIHdpdGgg YSBERUxFVEUgKyBVUExPQUQgYnV0IHRoYXQgaXMgbm90IGFjY2VwdGFibGUgaW4gbW9zdCBjYXNl cyBkdWUgdG8gdGhlIGluZWZmaWNpZW5jeSBvZiBzdWNoIG9wZXJhdGlvbiAoY3B1LCBiYW5kd2lk dGggY29uc3VtcHRpb24gLi4uKQoKIApJcyB0aGVyZSBhIHBsYW4gdG8gc3VwcG9ydCBzdWNoIGJh c2ljIGZlYXR1cmU/CgogCkZyb20gdGhlIGN1cnJlbnQgcmVtb3RlU3RvcmFnZSBzcGVjLCB0aGUg b3duQ2xvdWQgc3luYyBwcm90b2NvbCBjYW4gYmUgaW1wbGVtZW50ZWQuIFRoZSBtaXNzaW5nIGJp dCBpcyB0cmFja2luZyB0aG9zZSByZW1vdGUgbW92ZXMuCgpJIGFncmVlIHdpdGggSHVnbyB0aGF0 IE1PVkUgaXMgdXNlZnVsLCBzb21ldGltZXMgaWYgeW91IGp1c3QgcmVuYW1lIGEgZmlsZSBpdCB3 aWxsIGJlIHBlcmZlY3QuIEJ1dCB0aGUgcXVlc3Rpb24gSSBoYXZlIGlzIHRoYXQgd2hldGhlciB3 ZSBuZWVkIHRvIG1ha2UgdHdvIGRvY3VtZW50cz8gTXVsdGlwbGUgY2hvaWNlcyBpcyBub3QgZ29v ZCBmb3Igc3RhbmRhcmRpemF0aW9uLiBJbiBteSB2aWV3LCB3ZWJkYXYgaXMgc29tZXRoaW5nIHRo YXQgd2UgbmVlZCB0byBoYXZlIGEgdmVyeSBjbGVhciBkZWNpc2lvbiBvbiB3aGV0aGVyIHRvIGNv bnNpZGVyIGl0IG9yIG5vdC4KCiAKUmVnYXJkcywKCkxpbmh1aQoKIAogCkNoZWVycwoKIApPbiBX ZWQsIERlYyAyLCAyMDE1IGF0IDExOjI4IEFNLCBIdWdvIEdvbnrDoWxleiBMYWJyYWRvciA8aWV0 ZkBodWdvLmxhYmtvZGUuY29tPiB3cm90ZToKCgoKIAogCiAKIApPbiBXZWQsIERlYyAyLCAyMDE1 LCBhdCAxMToxOCBBTSwgTGluaHVpIFN1biB3cm90ZToKCkhpCgogCk9uIOWRqOS4iSwgMTLmnIgg MiwgMjAxNSBhdCAxNzo1NiwgSHVnbyBHb256w6FsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJr b2RlLmNvbT4gd3JvdGU6CgogCiAKIApPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwODoyMCBBTSwg TGluaHVpIFN1biB3cm90ZToKCkhpCgogCjIwMTUtMTItMDIgNToxNCBHTVQrMDg6MDAgSHVnbyBH b256w6FsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT46CgpIaSwKCiAKZnJvbSBt eSBwb2ludCBvZiB2aWV3IHRoZSByZW1vdGVTdG9yYWdlIHByb2plY3QgYWRkcmVzc2VzIGEgc3Vi c2V0IG9mCgp0aGUgdXNlIGNhc2VzIG9mIHRoZSAgV2ViREFWIHNwZWNpZmljYXRpb24uCgogClRo ZSBtYWluIGRpZmZlcmVuY2UgSSBjYW4gb2JzZXJ2ZSBpcyB0aGF0IHRoZSBzcGVjaWZpY2F0aW9u IGlzIGJ1aWx0IG9uCgpSRVNUIGluc3RlYWQgb2YgWE1MLWJhc2VkIGNvbW11bmljYXRpb24uCgog CkkgcGVyc29uYWxseSBsaWtlIG11Y2ggbW9yZSBSRVNUIHRoYW4gV2ViREFWIGJlY2F1c2UgaXQg aXMgbW9yZQoKZGV2ZWxvcGVyIGZyaWVuZGx5IGFuZCBpdCBpcyBmYXN0ZXIgdG8gZGV2ZWxvcC4K CiBNYXliZSB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgYmVjb21lcyB0aGUgbmV4dCBXZWJEQVYgOikK CiAKSG93ZXZlciwgdGhlIHJlbW90ZVN0b3JhZ2UgQVBJIGRvZXMgbm90IHByb3ZpZGUgYSB3YXkg b2Ygc3luY2hyb25pc2luZwoKZGF0YSwgdGhpcyB0YXNrIGlzIGRlbGVnYXRlZCB0byB0aGUgZGV2 ZWxvcGVycy4KCklzIHRoZXJlIGEgcGxhbiB0byBwcm92aWRlIHN1Y2ggZmVhdHVyZSBiYXNlZCBv biB0aGUgb3V0Y29tZSBvZiB0aGlzCgpkcmFmdD8KCkknbSBhIGxpdHRsZSBiaXQgY29uZnVzZWQg d2h5IHlvdSBzYXkgdGhlIHJlbW90ZVN0b3JhZ2UgZG9lcyBub3QgcHJvdmlkZSB0aGF0LiBJcyB0 aGF0IGJlY2F1c2UgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBwZXJmb3JtIGxpa2UgYSB0eXBpY2Fs IHN5bmMgc2VydmljZXMgKGUuZy4gZHJvcGJveC4uLikgb3IgeW91IGFyZSBzYXlpbmcgc29tZXRo aW5nIGVsc2U/CgpZZXMsIGJlY2F1c2UgaXQgZG9lcyBub3Qgb2ZmZXIgc3luY2hyb25pc2F0aW9u IGNhcGFiaWxpdGllcy4KCkdvdCBpdC4gQW5kIFdoYXQgSSBhbSB3b25kZXJpbmcgaXMgdGhhdCBk byB3ZSBuZWVkIHRvIGluY2x1ZGUgdGhvc2UgY2FwYWJpbGl0aWVzIGluIGEgYmFzZSBzcGVjaWZp Y2F0aW9ucy4gU2luY2UgaXQgaXMgaGFyZCB0byBzdGFuZGFyZGl6ZSB0aGUgY2FwYWJpbGl0aWVz IGxpa2UgZGVkdXAgb3IgZGVsdGEuIE1heWJlIGEgYmV0dGVyIHdheSBpcyB0byBkZWZpbmUgdGhv c2UgaW4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLAoKIAogClRoYW5rcyBmb3IgZ2l2aW5nIHRo ZXNlIGV4YW1wbGVzIC0gc28gYnkgJ3N5bmNocm9uaXNhdGlvbiBjYXBhYmlsaXRpZXMnIHlvdSBt ZWFuIDEpIGRlZHVwbGljYXRpb24gYW5kIDIpIGRlbHRhIHVwZGF0ZXM/IEFueXRoaW5nIGVsc2Ug b3IgaXMgdGhhdCBhbiBleGhhdXN0aXZlIGxpc3Q/CgogCnNvbWV0aGluZyBsaWtlIGV4dGVuc2lv bnMuIEZvciBhIGJhc2UgZG9jdW1lbnQsIHdlIGp1c3QgbmVlZCB0byBkZWZpbmUgaG93IHRvIHBl cmZvcm0gc3luYyBvcGVyYXRpb25zLgoKIAogClllcywgSSBhZ3JlZSB0aGF0IG1heSBiZSBhbiBl eHRlbnNpb24gb2YgdGhpcyBkcmFmdCBjb3VsZCBoYW5kbGUgdGhlIHN5bmNocm9uaXNhdGlvbiBw YXJ0LgoKIAogCiAKIApPdXIgSW50ZXJuZXQtRHJhZnQgaXMgaGVhdmlseSBmb2N1c2VkIG9uIHRo ZSB3b3JsZCB3aWRlIHdlYiwgd2hvc2UgVVJMcyBhcmUgbm90IGNvbnRlbnQtYWRkcmVzc2FibGUs IHdlIGNhbid0IGNoYW5nZSB0aGF0LiBTbyB0aGF0IGFyY2hpdGVjdHVyZSBpcyBub3QgdmVyeSBm cmllbmRseSB0byBkZWR1cGxpY2F0aW9uLCBjb21wYXJlZCB0byBmb3IgaW5zdGFuY2UgQml0VG9y cmVudC4gQXMgeW91IGFscmVhZHkgc2FpZCwgZGV2ZWxvcGVycyBjYW4gc3RpbGwgZGVkdXBlIG9u IHRoZSBzZXJ2ZXItc2lkZSB3aGVuIHN0b3JpbmcgYmxvYnMgdG8gZGlzaywgYW5kIGNhbiBhbHNv IGRlZHVwZSBvbiB0aGUgY2xpZW50IHNpZGUgYmVmb3JlIGNyZWF0aW5nIHRoZSByZXNvdXJjZXMg dGhlIGNsaWVudCB1cGxvYWRzLgoKQXMgZmFyIGFzIEkga25vdywgZGVsdGEgdXBkYXRlcyBhcmUg bm90IHN1cHBvcnRlZCBieSB0aGUgRVRhZyBzeXN0ZW0gLSB5b3UgY2Fubm90IGRvIGEgcmFuZ2Ug cmVxdWVzdCB0byBmaW5kIG91dCBpZiBjZXJ0YWluIGJ5dGVzIHdpdGhpbiBhIGRvY3VtZW50IGhh dmUgY2hhbmdlZC4gSG93ZXZlciwgdGhlIGZvbGRlciBzeXN0ZW0gd2UgZGVmaW5lIGRvZXMgZW5j b3VyYWdlIHlvdSwgZm9yIGluc3RhbmNlIHdoZW4geW91IGRldmVsb3AgYSBUbyBEbyBMaXN0IGFw cCwgcHV0IGVhY2ggdGFzayBvbiBpdHMgb3duIGRvY3VtZW50LCBhbmQgdGhlbiBxdWVyeSB0aGUg Zm9sZGVyIHRvIHNlZSB3aGljaCBvZiB0aGVtIGNoYW5nZWQsIGluc3RlYWQgb2YgcHV0dGluZyB0 aGVtIGFsbCBpbiBvbmUgYmlnIGRvY3VtZW50IGFuZCByZXRyaWV2aW5nIHRoZSB3aG9sZSBkb2N1 bWVudCBlYWNoIHRpbWUuCgogCkNoZWVycywKCk1pY2hpZWwuCgogCiAKIAogCkJUVywgSSB3YW50 IHRvIGludHJvZHVjZSBDbGF3SU8gKGh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvKSwgYSByZXNlYXJj aAoKcHJvamVjdCB0byBiZW5jaG1hcmsgZGlmZmVyZW50IHN5bmNocm9uaXNhdGlvbiBwcm90b2Nv bHMgYWdhaW5zdAoKZGlmZmVyZW50IGRhdGEgYmFja2VuZHMgd2l0aCBzcGVjaWFsIGF0dGVudGlv biB0byBwcm92aWRlIGEgY29tbW9uIHN5bmMKCkFQSS4KCiAKQSBjb21tb24gQVBJIGZvciBkaWZm ZXJlbnQgc3luYyBwcm90b2NvbHMgaXMgYmVpbmcgY3JlYXRlZCBiYXNlZCBvbiB0aGUKCmFyY2hp dGVjdHVyZSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdCAoY29udHJvbCBhbmQgZGF0YSBzZXJ2ZXJz KSBhbmQgdGhlCgpJIGNhbm5vdCBmaW5kIGEgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0dXJlIGluIHRo aXMgZHJhZnQuIEl0IHNlZW1zIHRoYXQgdGhleSBoYW5kbGUgbWV0YWRhdGEgYW5kIGNvbnRlbnQg ZGF0YSB0b2dldGhlciwganVzdCBsaWtlIGEgbm9ybWFsIHdlYiBzZXJ2aWNlLgoKIApDbGF3SU8g aXMgZnVsbHkgZGlzdHJpYnV0ZWQuIEV2ZXJ5IGxvZ2ljYWwgdW5pdCBpcyBhIGRpZmZlcmVudCBz ZXJ2ZXIgdGhhbiBiZSBzY2FsZWQgb3V0LiBEYXRhIGFuZCBNZXRhZGF0YSBjaGFubmVscyBhcmUg aW5kZXBlbmRlbnQgZnJvbSBlYWNoIG90aGVyIGFuZCByZXNpZGUgb24gZGlmZmVyZW50IHNlcnZl cnMuCgpUaGF0IGlzIHdpZGVseSBlbXBsb3llZCBpbiBwb3B1bGFyIHN5bmMgc2VydmljZXMuIEFu ZCB0aGF0IGlzIGFsc28gYmVuZWZpY2lhbCB0byBwcml2YWN5IHRvIHNvbWUgZXh0ZW50LiBCdXQg aW4gdGhlIGNvbnRleHQgb2Ygc3luYyBpbiBicm93c2VyICh3aGljaCBpcyBtYWlubHkgY29uc2lk ZXJlZCBpbiB0aGUgcmVtb3RlU3RvcmFnZSksIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMgaXMg cmVhc29uYWJsZS4gQnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGRlcGxveSBkaXN0cmlidXRlZCBhcmNo aXRlY3R1cmUgYWx0aG91Z2ggaXQgd2lsbCBtYWtlIHRoaW5ncyBjb21wbGljYXRlZC4KCiAKIApP ZiBjb3Vyc2UsIHRoZSByZW1vdGVTdG9yYWdlIGlzIHRhcmdldGVkIHRvIGJyb3dzZXJzLCBzbyBz eW5jaW5nIGRvZXMgbm90IG1ha2UgdG9vIG11Y2ggc2Vuc2UgaW4gdGhpcyBjYXNlLgoKV2l0aCB0 aGUgcmlzZSBvZiBMaW51eCBjb250YWluZXIgbWljcm8tc2VydmljZSBiYXNlZCBhcmNoaXRlY3R1 cmVzLCB0aGUgZGVwbG95bWVudCBvZiAgc3VjaCBoaWdobHkgY29tcGxleCBzeXN0ZW1zIHNob3Vs ZCBiZWNvbWUgZWFzaWVyIGFuZCBmYXN0ZXIuCgogCkJlc3QsCgogCiAKSHVnbwoKIAogClJlZ2Fy ZHMsCgpMaW5odWkgCgogCiAKUmVnYXJkcywKCkxpbmh1aQoKb25lIGZyb20gdGhlIENFUk4gRU9T IHByb2plY3QgKG1hbmFnZW1lbnQsIGRpc2sgYW5kIHF1ZXVlIHNlcnZlcnMpLgoKIApUaGUgUGhh c2UgSSBoYXMgaW1wbGVtZW50ZWQgdGhlIG93bkNsb3VkIFN5bmMgUHJvdG9jb2wgYW5kIFBoYXNl IElJIHdpbGwKCmltcGxlbWVudCB0aGUgU2VhRmlsZSBTeW5jIFByb3RvY29sLgoKVGhlIGNob2lj ZSBvZiB0aGVzZSBwcm90b2NvbHMgYW1vbmcgb3RoZXJzIGlzIGJlY2F1c2UgdGhleSBhcmUgcmVh bGx5CgpvcHBvc2VkIHRvIGVhY2ggb3RoZXIgaW4gdGVybXMgb2Ygc3luY2luZyAoZGVsdGEgdnMg bm9uLWRlbHRhLAoKc3RhdGUtYmFzZWQgdnMgbG9nL2V2ZW50L2dpdC1iYXNlZCBzeW5jIOKApiks IHNvIGZpbmRpbmcgYSBjb21tb24gYXBwcm9hY2gKCmlzIG1vcmUgY2hhbGxlbmdpbmcuCgogClBy b3ZpZGluZyBhIGJhc2Ugc3BlY2lmaWNhdGlvbi9hcmNoaXRlY3R1cmUgdG8gbWVhc3VyZSB0aGUg ZmVhc2liaWxpdHkKCm9mIHRoaXMgZHJhZnQgaXMgb25lIG9mIHRoZSBvYmplY3RpdmVzIG9mIHRo ZSBwcm9qZWN0LgoKIApJIGJlbGlldmUgdGhhdCB0aGUgd29yayBiZWluZyBkb25lIGhlcmUgYW5k IGluIENsYXdJTyBhcmUgc3VwcGxlbWVudGFyeQoKdG8gZWFjaCBvdGhlciBhbmQgSSB0aGluayBt dXR1YWwgY29sbGFib3JhdGlvbiBjb3VsZCBiZSBiZW5lZmljaWFsIGZvcgoKYm90aCBzaWRlcy4K CiAKQWxzbywgaWYgdGhlcmUgaXMgaW50ZXJlc3QsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBjYW4g YmUgYWRkZWQgdG8KCkNsYXdJTy4KCiAKQmVzdCByZWdhcmRzLAoKIApIdWdvIEdvbnphbGV6IExh YnJhZG9yCgogCk9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0IDA5OjAwIFBNLCBzdG9yYWdlc3luYy1y ZXF1ZXN0QGlldGYub3JnIHdyb3RlOgoKPiBTZW5kIFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBz dWJtaXNzaW9ucyB0bwoKPiAgICAgICBzdG9yYWdlc3luY0BpZXRmLm9yZwoKPgoKPiBUbyBzdWJz Y3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQKCj4gICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYwoKPiBv ciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcg dG8KCj4gICAgICAgc3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9yZwoKPgoKPiBZb3UgY2FuIHJl YWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQKCj4gICAgICAgc3RvcmFnZXN5bmMt b3duZXJAaWV0Zi5vcmcKCj4KCj4gV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJq ZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYwoKPiB0aGFuICJSZTogQ29udGVudHMgb2Yg U3RvcmFnZXN5bmMgZGlnZXN0Li4uIgoKPiBUb2RheSdzIFRvcGljczoKCj4KCj4gICAgMS4gTmV3 IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgICAgSW50ZXJuZXQtRHJhZnQK Cj4gICAgICAgYXZhaWxhYmxlIChNaWNoaWVsIGRlIEpvbmcpCgo+ICAgIDIuIFJlOiBOZXcgdmVy c2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdAoKPiAgICAg ICBhdmFpbGFibGUgKEdpaGFuIERpYXMpCgo+ICAgIDMuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFm dC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdAoKPiAgICAgICBhdmFpbGFibGUg KEZlaSBTb25nKQoKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKPiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QKCj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcK Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYwoKPiBF bWFpbCBoYWQgMyBhdHRhY2htZW50czoKCj4gKyBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9m IGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlCgo+IEludGVybmV0LURyYWZ0IGF2YWlsYWJsZQoK PiAgIDJrIChtZXNzYWdlL3JmYzgyMikKCj4gKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lv biBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZQoKPiBJbnRlcm5ldC1EcmFmdCBhdmFpbGFi bGUKCj4gICAxayAobWVzc2FnZS9yZmM4MjIpCgo+ICsgUmU6IFtTdG9yYWdlc3luY10gTmV3IHZl cnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UKCj4gSW50ZXJuZXQtRHJhZnQgYXZh aWxhYmxlCgo+ICAgMmsgKG1lc3NhZ2UvcmZjODIyKQoKIApfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0CgpTdG9y YWdlc3luY0BpZXRmLm9yZwoKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z dG9yYWdlc3luYwoKIAogCiAKIAoKCgoKCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QKU3RvcmFnZXN5bmNA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3lu YwoKCgo= ------=_Part_41660_1275101042.1449135111401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 R3JlYXTvvIE8QlI+PEJSPjxCUj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjZi NmI2IDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJ Ti1SSUdIVDogMHB4IiBuYW1lPSJyZXBseUNvbnRlbnQiPi0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS08 QlI+PEI+5Y+R5Lu25Lq6OjwvQj4gIk1pY2hpZWwgZGUgSm9uZyIgJmx0O21iZGVqb25nQG1vemls bGEuY29tJmd0OzxCUj48Qj7lj5HpgIHml7bpl7Q6PC9CPiAyMDE15bm0MTLmnIgz5pelIOaYn+ac n+WbmzxCUj48Qj7mlLbku7bkuro6PC9CPiBmc29uZ0BianR1LmVkdS5jbjxCUj48Qj7mioTpgIE6 PC9CPiAiTGluaHVpIFN1biIgJmx0O2xoLnN1bmxpbmhAZ21haWwuY29tJmd0Oywgc3RvcmFnZXN5 bmMgJmx0O3N0b3JhZ2VzeW5jQGlldGYub3JnJmd0OywgZmtvb21hbiAmbHQ7Zmtvb21hbkB0dXhl ZC5uZXQmZ3Q7LCAiSHVnbyBHb256w6FsZXogTGFicmFkb3IiICZsdDtpZXRmQGh1Z28ubGFia29k ZS5jb20mZ3Q7PEJSPjxCPuS4u+mimDo8L0I+IFJlOiBbU3RvcmFnZXN5bmNdIFN0b3JhZ2VzeW5j IERpZ2VzdCwgVm9sIDUsIElzc3VlIDE8QlI+PEJSPgo8RElWIGRpcj0ibHRyIj4KPERJVj4KPERJ Vj4KPERJVj4KPERJVj5ZZXMhIEknbGwgZGlzY3VzcyB3aXRoIEZyYW5jb2lzIGhvdyB3ZSBjYW4g bWFrZSB0aGVzZSBib3VuZGFyaWVzIGNsZWFyZXIuIE1heWJlIHdlIGNhbiBzcGxpdCBhbG9uZyB0 aGVzZSBsaW5lczo8QlI+PEJSPjwvRElWPiogdXBsb2FkL21hbmlwdWxhdGUvcXVlcnkvZG93bmxv YWQgcHJvdG9jb2wgKGUuZy4gV2ViREFWIG9yIHRoZSBHRVQvUFVUL0RFTEVURSBvcGVyYXRpb25z IHdlIGN1cnJlbnRseSBkZWZpbmUpPEJSPjwvRElWPiogQ09SUyBvciBvdGhlciBjcm9zcy1vcmln aW4gYWNjZXNzIG1lY2hhbmlzbSwgT0FVVEggb3Igb3RoZXIgYXV0aCBtZWNoYW5pc20sIFdlYkZp bmdlciBvciBvdGhlciBkaXNjb3ZlcnkgbWVjaGFuaXNtLCBFVGFnIG9yIG90aGVyIHZlcnNpb25p bmcgbWVjaGFuaXNtPEJSPjwvRElWPiogY2h1bmtpbmcvZGVkdXBpbmcvZGVsdGEtdXBkYXRlczxC Uj48QlI+PC9ESVY+QW5kIHRoZSByZW1vdGVTdG9yYWdlIHNwZWMgc2hvdWxkIHByb2JhYmx5IG9u bHkgZGVmaW5lIHRoZSBtaWRkbGUgcGFydC48QlI+CjxESVY+PEJSPjwvRElWPjwvRElWPgo8RElW IGNsYXNzPSJnbWFpbF9leHRyYSI+PEJSPgo8RElWIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1 LCBEZWMgMywgMjAxNSBhdCA5OjQ0IEFNLCA8U1BBTiBkaXI9Imx0ciI+Jmx0OzxBIGhyZWY9Im1h aWx0bzpmc29uZ0BianR1LmVkdS5jbiIgdGFyZ2V0PSJfYmxhbmsiPmZzb25nQGJqdHUuZWR1LmNu PC9BPiZndDs8L1NQQU4+IHdyb3RlOjxCUj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZU OiAjY2NjIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZU OiAxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+CjxQPkhpIE1pY2hpZWwgYW5kIExpbmh1aSw8L1A+ CjxQPkkgdGhpbmsgaXQgd2lsbCBiZSBnb29kIHRvIGhhdmUgYSBib3VuZGFyeSBmb3IgdGhpcyBk cmFmdCBhbmQgbGVhdmUgc29tZSB3b3JrIGZvciB0aGUgYXBwbGljYWl0b24gbGF5ZXJ+PEJSPjxC Uj48L1A+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogI2I2YjZiNiAycHggc29saWQ7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCIg bmFtZT0icmVwbHlDb250ZW50Ij48U1BBTj4tLS0tLeWOn+Wni+mCruS7ti0tLS0tPEJSPjxCPuWP keS7tuS6ujo8L0I+ICJNaWNoaWVsIGRlIEpvbmciICZsdDs8QSBocmVmPSJtYWlsdG86bWJkZWpv bmdAbW96aWxsYS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYmRlam9uZ0Btb3ppbGxhLmNvbTwvQT4m Z3Q7PEJSPjxCPuWPkemAgeaXtumXtDo8L0I+IDIwMTXlubQxMuaciDLml6Ug5pif5pyf5LiJPEJS PjxCPuaUtuS7tuS6ujo8L0I+ICJMaW5odWkgU3VuIiAmbHQ7PEEgaHJlZj0ibWFpbHRvOmxoLnN1 bmxpbmhAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGguc3VubGluaEBnbWFpbC5jb208L0E+ Jmd0OzxCUj48Qj7mioTpgIE6PC9CPiBzdG9yYWdlc3luYyAmbHQ7PEEgaHJlZj0ibWFpbHRvOnN0 b3JhZ2VzeW5jQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3RvcmFnZXN5bmNAaWV0Zi5vcmc8 L0E+Jmd0OywgZmtvb21hbiAmbHQ7PEEgaHJlZj0ibWFpbHRvOmZrb29tYW5AdHV4ZWQubmV0IiB0 YXJnZXQ9Il9ibGFuayI+Zmtvb21hbkB0dXhlZC5uZXQ8L0E+Jmd0OywgIkh1Z28gR29uesOhbGV6 IExhYnJhZG9yIiAmbHQ7PEEgaHJlZj0ibWFpbHRvOmlldGZAaHVnby5sYWJrb2RlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmlldGZAaHVnby5sYWJrb2RlLmNvbTwvQT4mZ3Q7PEJSPjxCPuS4u+mimDo8 L0I+IFJlOiBbU3RvcmFnZXN5bmNdIFN0b3JhZ2VzeW5jIERpZ2VzdCwgVm9sIDUsIElzc3VlIDE8 QlI+PEJSPjwvU1BBTj4KPERJVj4KPERJViBjbGFzcz0iaDUiPgo8RElWIGRpcj0ibHRyIj4KPERJ Vj4KPERJVj4KPERJVj5BaCBzdXJlLCB0aGF0J3MgZW50aXJlbHkgYXBwcm9wcmlhdGUsIHJlbW90 ZVN0b3JhZ2UgdHJlYXRzIGJvdGggdGhlIENvbnRlbnQtVHlwZSBoZWFkZXIgdmFsdWUgYW5kIHRo ZSBhY3R1YWwgYm9keSBvZiBhIGRvY3VtZW50IGFzIG9wYXF1ZSBzdHJpbmdzIG9mIGJ5dGVzLiBJ dCBkb2Vzbid0ICJjYXJlIiBpZiB5b3UgdXNlIGl0IHRvIHN0b3JlIG9ubHkgZGF0YSBibG9ja3Mg dGhhdCBhcmUgY2h1bmtzIG9mIHNvbWV0aGluZyBlbHNlLjxCUj48QlI+PC9ESVY+CjxESVY+Rm9y IGluc3RhbmNlLCB5b3UgY291bGQgaGF2ZSBhIGZvbGRlciBvbiBhIHVzZXIncyBzdG9yYWdlIHRo YXQgY29udGFpbnMgb25seSBpbm9kZS1saWtlIEpTT04tZG9jdW1lbnRzLCB3aGljaCBsaXN0IHRo ZSBVUkxzIG9mIGJpbmFyeSBkb2N1bWVudHMgdGhhdCBtYWtlIHVwIDFLYiBibG9ja3Mgb2YgdGhl IGFjdHVhbCBkYXRhLiBOaWNlIGZvciBkZWR1cGluZywgZGVsdGEgdXBkYXRlcywgYW5kIGFsc28g cmVuYW1pbmcgZmlsZXMgd2l0aG91dCByZXVwbG9hZGluZyB0aGVpciBjb250ZW50LjxCUj48L0RJ Vj4KPERJVj48QlI+PC9ESVY+QnV0IHllYWgsIHRoZSBhcmd1bWVudCBpcyB0aGF0ICpob3cqIHRv IGNyZWF0ZSBhbmQgbWFuYWdlIHRoZXNlIGNodW5rcywgaXMgdGhlbiBzdGlsbCBsZWZ0IHVwIHRv IHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgKG9yIHRvIGFub3RoZXIgc3BlYyBvbiB0b3Agb2Yg dGhlIHJlbW90ZVN0b3JhZ2Ugc3BlYykuPEJSPjxCUj48QlI+PC9ESVY+Q2hlZXJzLDxCUj48L0RJ Vj5NaWNoaWVsLjxCUj48L0RJVj4KPERJViBjbGFzcz0iZ21haWxfZXh0cmEiPjxCUj4KPERJViBj bGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgRGVjIDIsIDIwMTUgYXQgMzoyOSBQTSwgTGluaHVp IFN1biA8U1BBTiBkaXI9Imx0ciI+Jmx0OzxBIGhyZWY9Im1haWx0bzpsaC5zdW5saW5oQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxoLnN1bmxpbmhAZ21haWwuY29tPC9BPiZndDs8L1NQQU4+ IHdyb3RlOjxCUj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xp ZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIGNsYXNzPSJn bWFpbF9xdW90ZSI+CjxESVYgZGlyPSJsdHIiPkhpIAo8RElWIGNsYXNzPSJnbWFpbF9leHRyYSI+ PEJSPgo8RElWIGNsYXNzPSJnbWFpbF9xdW90ZSI+PFNQQU4+MjAxNS0xMi0wMiAyMjowNSBHTVQr MDg6MDAgTWljaGllbCBkZSBKb25nIDxTUEFOIGRpcj0ibHRyIj4mbHQ7PEEgaHJlZj0ibWFpbHRv Om1iZGVqb25nQG1vemlsbGEuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWJkZWpvbmdAbW96aWxsYS5j b208L0E+Jmd0OzwvU1BBTj46PEJSPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNj Y2MgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFl eCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4KPERJViBkaXI9Imx0ciI+CjxESVY+CjxESVY+CjxESVY+ CjxESVY+Q29vbCEgSSBjcmVhdGVkIDxBIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9yZW1vdGVz dG9yYWdlL3NwZWMvaXNzdWVzLzEzNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNv bS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzNzwvQT4gYWJvdXQgdGhlIG5lZWQgZm9yJm5i c3A7IE1PVkUgdmVyYi48QlI+PEJSPjwvRElWPkFwcGxpY2F0aW9uLWxldmVsIGNodW5raW5nIGlz IHBhcnRpYWxseSBzdXBwb3J0ZWQgYnkgSFRUUCBpdHNlbGYgdGhyb3VnaCBgQ29udGVudC1SYW5n ZWAgaGVhZGVycyAoYWx0aG91Z2ggaXQncyBub3QgY2xlYXIgd2hldGhlciB0aGVzZSBhcmUgYWxs b3dlZCBvbiBQVVQgcmVxdWVzdHMgYXMgd2VsbCBhcyBvbiBHRVQgcmVxdWVzdHMsIHNlZSA8QSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vcmVtb3Rlc3RvcmFnZS9zcGVjL2lzc3Vlcy8xMzEiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vcmVtb3Rlc3RvcmFnZS9zcGVjL2lzc3Vl cy8xMzE8L0E+KS4gVGhlIHByb2JsZW0gaXMgdGhhdCBIVFRQIGRlZmluZXMgdmVyc2lvbmluZyBh dCB0aGUgZG9jdW1lbnQgbGV2ZWwsIHlvdSBjYW5ub3QgYXNrIGEgc2VydmVyIHRvIHByb2R1Y2Ug b3IgY2hlY2sgYW4gRVRhZyBmb3IgYSBzcGVjaWZpYyBieXRlLXJhbmdlIG9mIGEgZG9jdW1lbnQs IG9ubHkgZm9yIHRoZSBlbnRpcmUgZG9jdW1lbnQuPEJSPjwvRElWPjwvRElWPjwvRElWPjwvRElW PjwvQkxPQ0tRVU9URT48L1NQQU4+CjxESVY+QWN0dWFsbHkgd2hhdCBJJ20gc2F5aW5nIGlzIGEg Y2h1bmtpbmcgYmVmb3JlIHRyYW5zbWl0dGluZyAodXNpbmcgaHR0cCksIGluIHRoaXMgd2F5LCB0 aGV5IGFyZSB0cmVhdGVkIGFzIGluZGl2aWR1YWwgZG9jdW1lbnRzIGZyb20gdGhlIHN0YW5kcG9p bnQgb2YgaHR0cC4gQnV0IEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYXBwcm9wcmlhdGUg Zm9yIHJlbW90ZVN0b3JhZ2UsIGp1c3QgYSBjb21tZW50LjwvRElWPgo8RElWPjxCUj48L0RJVj4K PERJVj5SZWdhcmRzLDwvRElWPgo8RElWPkxpbmh1aTwvRElWPgo8RElWPgo8RElWPgo8QkxPQ0tR VU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHgg MHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4KPERJViBk aXI9Imx0ciI+CjxESVY+CjxESVY+CjxESVY+PEJSPjwvRElWPkEgY29tcGFyaXNvbiBkb2N1bWVu dCBzb3VuZHMgZ29vZCEgU2VlIGFsc28gPEEgaHJlZj0iaHR0cDovL3d3dy5zZXJ2aWNlZGVudWFn ZXMuZnIvZW4vZ2VuZXJpYy1zdG9yYWdlLWVjb3N5c3RlbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly93d3cuc2VydmljZWRlbnVhZ2VzLmZyL2VuL2dlbmVyaWMtc3RvcmFnZS1lY29zeXN0ZW08L0E+ LjxCUj48QlI+PEJSPjwvRElWPkNoZWVycyw8QlI+PC9ESVY+TWljaGllbC48QlI+PEJSPjwvRElW Pgo8RElWPgo8RElWPgo8RElWIGNsYXNzPSJnbWFpbF9leHRyYSI+PEJSPgo8RElWIGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gV2VkLCBEZWMgMiwgMjAxNSBhdCAyOjMyIFBNLCBMaW5odWkgU3VuIDxT UEFOIGRpcj0ibHRyIj4mbHQ7PEEgaHJlZj0ibWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bGguc3VubGluaEBnbWFpbC5jb208L0E+Jmd0OzwvU1BBTj4gd3JvdGU6 PEJSPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJH SU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1 b3RlIj4KPERJViBkaXI9Imx0ciI+VGhhdCdzIGNvb2wgZm9yIG1lLCBhIHNlcGFyYXRlIHNlY3Rp b24gZm9yIHRoaXMgbWlnaHQgbWFrZSBzZW5zZS4gCjxESVY+PEJSPjwvRElWPgo8RElWPkFub3Ro ZXIgdGhpbmcgaXMgZG8gd2UgbmVlZCB0byBpbmNsdWRlIGFuIGFwcGxpY2F0aW9uLWxheWVyIGNo dW5raW5nIGhlcmUgKG5vdCBqdXN0IGZvciBhIGJyb3dzZXIgc3luYyksIHNpbmNlIGlmIHdlIHdh bnQgdG8gZnVydGhlciBleHRlbmQgb3RoZXIgY2FwYWJpbGl0aWVzIGl0IGlzIGVzc2VudGlhbC48 QlI+CjxESVY+PEJSPjwvRElWPgo8RElWPlJlZ2FyZHMsPC9ESVY+CjxESVY+TGluaHVpPC9ESVY+ PC9ESVY+PC9ESVY+CjxESVY+CjxESVY+CjxESVYgY2xhc3M9ImdtYWlsX2V4dHJhIj48QlI+CjxE SVYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE1LTEyLTAyIDIxOjAzIEdNVCswODowMCBIdWdvIEdv bnrDoWxleiBMYWJyYWRvciA8U1BBTiBkaXI9Imx0ciI+Jmx0OzxBIGhyZWY9Im1haWx0bzppZXRm QGh1Z28ubGFia29kZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGh1Z28ubGFia29kZS5jb208 L0E+Jmd0OzwvU1BBTj46PEJSPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNjY2Mg MXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIg Y2xhc3M9ImdtYWlsX3F1b3RlIj48VT48L1U+CjxESVY+CjxESVY+SSBwcm9wb3NlIHRvIGNvbWUg dXAgd2l0aCBhIGxpc3Qgb2YgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyBvZiB1c2luZyBX ZWJEQVYgYW5kIGNvbXBhcmUgdGhlbSBhZ2FpbnN0IGEgSlNPTi9SRVNUIGJhc2VkIGFwcHJvYWNo LCBsaWtlIHJlbW90ZVN0b3JhZ2UuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkRv ZXMgaXQgc291bmQgZ29vZCA/PC9ESVY+CjxESVY+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxE SVY+Jm5ic3A7PC9ESVY+CjxESVY+T24gV2VkLCBEZWMgMiwgMjAxNSwgYXQgMDE6NTkgUE0sIExp bmh1aSBTdW4gd3JvdGU6PEJSPjwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4KPERJViBk aXI9Imx0ciI+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+ CjxESVY+MjAxNS0xMi0wMiAyMDo0MyBHTVQrMDg6MDAgSHVnbyBHb256w6FsZXogTGFicmFkb3Ig PFNQQU4gZGlyPSJsdHIiPiZsdDs8QSBocmVmPSJtYWlsdG86aWV0ZkBodWdvLmxhYmtvZGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBodWdvLmxhYmtvZGUuY29tPC9BPiZndDs8L1NQQU4+OjxC Uj48L0RJVj4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQp IDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgi Pgo8RElWPjxVPjwvVT48QlI+PC9ESVY+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5i c3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+ T24gV2VkLCBEZWMgMiwgMjAxNSwgYXQgMDE6MzAgUE0sIE1pY2hpZWwgZGUgSm9uZyB3cm90ZTo8 L1NQQU4+PEJSPjwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4KPERJViBkaXI9Imx0ciI+ CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxESVY+CjxE SVY+CjxESVY+CjxESVY+CjxESVY+PFNQQU4+SGkgYWxsITwvU1BBTj48QlI+PC9ESVY+PC9ESVY+ CjxESVY+PFNQQU4+VGhhbmtzIGZvciBhbGwgeW91ciByZWFjdGlvbnMgdG8gdGhlIHJlbW90ZVN0 b3JhZ2UgSW50ZXJuZXQtRHJhZnQuPC9TUEFOPjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj48 L0RJVj4KPERJVj48U1BBTj5XZSBnZXQgdGhlIHF1ZXN0aW9uIGFib3V0IFdlYkRBViBhIGxvdCwg aW4gdGhlIG5leHQgdmVyc2lvbiB3ZSBzaG91bGQgYWRkIGEgcmVtYXJrIGFib3V0IGl0IGluIHRo ZSBpbnRyby4gVGhlIGZvbGRlciBkZXNjcmlwdGlvbnMgcmV0dXJuZWQgd2hlbiB5b3UgR0VUIGEg VVJMIHRoYXQgZW5kcyB3aXRoIGEgLyBhcmUgaW5kZWVkIGEgZGV2aWF0aW9uIGZyb20gdGhlIFhN TCByZXR1cm5lZCBieSBXZWJEQVYgc2VydmVyLCBhbmQgdGhpcyBpcyBqdXN0IGJlY2F1c2Ugbm93 YWRheXMgSlNPTiBpcyBlYXNpZXIgdG8gdXNlIHRoYW4gWE1MIGZvciBkZXZlbG9wZXJzLCBib3Ro IGNsaWVudC1zaWRlIGFuZCBzZXJ2ZXItc2lkZS48L1NQQU4+PEJSPjwvRElWPjwvRElWPjwvRElW PjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwv QkxPQ0tRVU9URT4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JIHRv dGFsbHkgYWdyZWUgaGVyZSwgdGhpcyB3YXMgZ29pbmcgdG8gaGFwcGVuIHNvb24gb3IgbGF0ZXIg YW5kIGl0IGlzIHJlYWxseSBhcHByZWNpYXRlZC48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+ CjxESVY+Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8RElWIGRpcj0ibHRy Ij4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4KPERJVj4K PERJVj48U1BBTj5UaGUgZmFjdCB0aGF0IHdlIGRvbid0IHJlcXVpcmUgc2VydmVycyB0byBzdXBw b3J0IFdlYkRBVidzIGN1c3RvbSB2ZXJicyBsaWtlIFBST1BQQVRDSCBldGMuIGlzIGZvciB0aHJl ZSByZWFzb25zOjwvU1BBTj48QlI+PC9ESVY+PC9ESVY+CjxESVY+PFNQQU4+MSkgaXQncyBhIGxv dCBvZiB3b3JrIHRvIGltcGxlbWVudCB0aGlzIHdpdGhvdXQgdXNpbmcgYW4gZXhpc3RpbmcgV2Vi REFWIGxpYnJhcnk8L1NQQU4+PEJSPjwvRElWPjwvRElWPgo8RElWPjxTUEFOPjIpIGluIHByYWN0 aWNlLCBhIGxvdCBvZiBXZWJEQVYgc2VydmVycyBnZXQgaXQgd3JvbmcsIG9yIGRvbid0IGltcGxl bWVudCBhbGwgb2YgV2ViREFWLiBJdCdzIHZlcnkgYW5ub3lpbmcgZm9yIGNsaWVudCBpbXBsZW1l bnRlcnMgdG8gaGF2ZSB0byBkZWFsIHdpdGggc2VydmVycyB0aGF0IGUuZy4gY2hvc2Ugbm90IHRv IGltcGxlbWVudCBMT0NLIGFuZCBVTkxPQ0suPC9TUEFOPjxCUj48L0RJVj48L0RJVj4KPERJVj48 U1BBTj4zKSB3ZSBkb24ndCByZWFsbHkgbmVlZCBhbGwgdGhlc2UgYWR2YW5jZWQgZmVhdHVyZXMg b24gdG9wIG9mIHN0YW5kYXJkIEhUVFAsIGp1c3Qgc3VwcG9ydGluZyBHRVQvUFVUL0RFTEVURSBm b3IgcmVzb3VyY2VzLCBhbmQgYWRkaW5nIGEgc2ltcGxlIGZvbGRlciBkZXNjcmlwdGlvbiBmb3Jt YXQsIGlzIGVub3VnaCBmb3IgbW9zdCBhcHBsaWNhdGlvbnMuPC9TUEFOPjxCUj48L0RJVj4KPERJ Vj4mbmJzcDs8L0RJVj48L0RJVj4KPERJVj48U1BBTj5PdGhlciB0aGFuIHRoYXQsIHRoZSByZW1v dGVTdG9yYWdlIEludGVybmV0LURyYWZ0IHNwZWNpZmllcyBhICpsb3QqIG1vcmUgdGhhbiBqdXN0 IGhvdyBlYWNoIEhUVFAgdmVyYiBzaG91bGQgYmVoYXZlOjwvU1BBTj48QlI+PC9ESVY+PC9ESVY+ CjxESVY+PFNQQU4+KiByZXF1aXJpbmcgc3VwcG9ydCBmb3IgT0F1dGggaW1wbGljaXQtZ3JhbnQg ZmxvdzwvU1BBTj48QlI+PC9ESVY+PC9ESVY+CjxESVY+PFNQQU4+KiByZXF1aXJpbmcgRVRhZyBz dXBwb3J0IGFuZCBuZXN0ZWQgdmVyc2lvbmluZyAoaS5lLiB0aGUgZm9sZGVyJ3MgRVRhZyBjaGFu Z2VzIGlmIGFueXRoaW5nIHdpdGhpbiB0aGF0IGZvbGRlciBjaGFuZ2VzKTwvU1BBTj48QlI+PC9E SVY+CjxESVY+PFNQQU4+KiByZXF1aXJpbmcgQ09SUyBoZWFkZXJzPC9TUEFOPjxCUj48L0RJVj48 L0RJVj4KPERJVj48U1BBTj4qIHJlcXVpcmluZyBhIFdlYkZpbmdlciBhbm5vdW5jZW1lbnQgZm9y IHNlcnZpY2UgZGlzY292ZXJ5PC9TUEFOPjxCUj48L0RJVj48L0RJVj4KPERJVj48U1BBTj5JdCB3 b3VsZCBiZSBlYXN5IHRvIGFkZCB0aGVzZSB0aHJlZSB0aGluZ3Mgb24gdG9wIG9mIFdlYkRBViwg aW5zdGVhZCBvZiBwdXR0aW5nIHRoZW0gb24gdG9wIG9mIG91ciBtaW5pbWFsIEdFVC9QVVQvREVM RVRFIEFQSSBkZWZpbml0aW9uLiBJbiBmYWN0LCB3ZSBjb3VsZCBwcm9iYWJseSBzZXBhcmF0ZSBp dCBpbnRvIHR3byBJbnRlcm5ldC1EcmFmdHM6IG9uZSBmb3IgdGhlICdSRVNUZnVsIGZvbGRlcnMn IEFQSSB3aGljaCBpcyBvdXIgc2ltcGxpZmljYXRpb24gb2YgV2ViREFWLCBhbmQgYSBzZWNvbmQg b25lIGZvciBPQXV0aC9FVGFncy9DT1JTL1dlYkZpbmdlciBvbiB0b3Agb2YgZWl0aGVyIFdlYkRB ViBvciAnUkVTVGZ1bCBmb2xkZXJzJyBvciB3aGF0ZXZlciBvdGhlciBIVFRQLWJhc2VkIEFQSSB5 b3Ugd2FudC48L1NQQU4+PEJSPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj4m bmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5UaGVyZSBpcyBvbmUgcmVxdWlyZW1l bnQgdGhhdCBhbGwgc3luY2hyb25pc2VycyBuZWVkIHRvIGhhbmRsZTogbW92aW5nIHJlc291cmNl cy4gSW4gdGhpcyBzcGVjIHRoZSBhbHRlcm5hdGl2ZSBvZiBhIFdlYkRBViBNT1ZFIGlzIG5vdCBz cGVjaWZpZWQuJm5ic3A7PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkl0IGlzIHRy dWUgdGhhdCBhIE1PVkUgY291bGQgYmUgcmVwbGFjZWQgd2l0aCBhIERFTEVURSArIFVQTE9BRCBi dXQgdGhhdCBpcyBub3QgYWNjZXB0YWJsZSBpbiBtb3N0IGNhc2VzIGR1ZSB0byB0aGUgaW5lZmZp Y2llbmN5IG9mIHN1Y2ggb3BlcmF0aW9uIChjcHUsIGJhbmR3aWR0aCBjb25zdW1wdGlvbiAuLi4p PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPklzIHRoZXJlIGEgcGxhbiB0byBzdXBw b3J0IHN1Y2ggYmFzaWMgZmVhdHVyZT88QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+ RnJvbSB0aGUgY3VycmVudCByZW1vdGVTdG9yYWdlIHNwZWMsIHRoZSBvd25DbG91ZCBzeW5jIHBy b3RvY29sIGNhbiBiZSBpbXBsZW1lbnRlZC4gVGhlIG1pc3NpbmcgYml0IGlzIHRyYWNraW5nIHRo b3NlIHJlbW90ZSBtb3Zlcy48QlI+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPkkgYWdy ZWUgd2l0aCBIdWdvIHRoYXQgTU9WRSBpcyB1c2VmdWwsIHNvbWV0aW1lcyBpZiB5b3UganVzdCBy ZW5hbWUgYSBmaWxlIGl0IHdpbGwgYmUgcGVyZmVjdC4gQnV0IHRoZSBxdWVzdGlvbiBJIGhhdmUg aXMgdGhhdCB3aGV0aGVyIHdlIG5lZWQgdG8gbWFrZSB0d28gZG9jdW1lbnRzPyBNdWx0aXBsZSBj aG9pY2VzIGlzIG5vdCBnb29kIGZvciBzdGFuZGFyZGl6YXRpb24uIEluIG15IHZpZXcsIHdlYmRh diBpcyBzb21ldGhpbmcgdGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSB2ZXJ5IGNsZWFyIGRlY2lzaW9u IG9uIHdoZXRoZXIgdG8gY29uc2lkZXIgaXQgb3Igbm90LjxCUj48L0RJVj4KPERJVj4mbmJzcDs8 L0RJVj4KPERJVj5SZWdhcmRzLDxCUj48L0RJVj4KPERJVj5MaW5odWk8QlI+PC9ESVY+CjxCTE9D S1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1B UkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4Ij4KPERJVj4KPERJVj4m bmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5DaGVlcnM8QlI+PC9ESVY+CjxESVY+ CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8RElWIGRp cj0ibHRyIj4KPERJVj4KPERJVj4KPERJVj5PbiBXZWQsIERlYyAyLCAyMDE1IGF0IDExOjI4IEFN LCBIdWdvIEdvbnrDoWxleiBMYWJyYWRvciA8U1BBTiBkaXI9Imx0ciI+Jmx0OzxBIGhyZWY9Im1h aWx0bzppZXRmQGh1Z28ubGFia29kZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGh1Z28ubGFi a29kZS5jb208L0E+Jmd0OzwvU1BBTj4gd3JvdGU6PEJSPjwvRElWPgo8QkxPQ0tRVU9URSBzdHls ZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAw cHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCI+CjxESVY+PFU+PC9VPjxCUj48L0RJVj4K PERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJ Vj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5PbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAx MToxOCBBTSwgTGluaHVpIFN1biB3cm90ZTo8L1NQQU4+PEJSPjwvRElWPgo8QkxPQ0tRVU9URSB0 eXBlPSJjaXRlIj4KPERJVj48U1BBTj5IaTwvU1BBTj48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9E SVY+CjxESVY+CjxESVYgc3R5bGU9IkNPTE9SOiByZ2IoMCwwLDApIj4KPERJVj48U1BBTj5PbiDl kajkuIksIDEy5pyIIDIsIDIwMTUgYXQgMTc6NTYsIEh1Z28gR29uesOhbGV6IExhYnJhZG9yICZs dDs8QSBocmVmPSJtYWlsdG86aWV0ZkBodWdvLmxhYmtvZGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aWV0ZkBodWdvLmxhYmtvZGUuY29tPC9BPiZndDsgd3JvdGU6PC9TUEFOPjxCUj48L0RJVj4KPERJ ViBzdHlsZT0iT1ZFUkZMT1ctWDogdmlzaWJsZTsgT1ZFUkZMT1ctWTogdmlzaWJsZSI+CjxCTE9D S1FVT1RFIHN0eWxlPSJDT0xPUjogcmdiKDQ4LDU5LDY0KSI+CjxESVY+CjxESVY+Jm5ic3A7PC9E SVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+T24gV2Vk LCBEZWMgMiwgMjAxNSwgYXQgMDg6MjAgQU0sIExpbmh1aSBTdW4gd3JvdGU6PC9TUEFOPjxCUj48 L0RJVj4KPEJMT0NLUVVPVEU+CjxESVYgZGlyPSJsdHIiPgo8RElWPjxTUEFOPkhpPC9TUEFOPjxC Uj48L0RJVj4KPERJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4KPERJVj48U1BBTj4yMDE1LTEy LTAyIDU6MTQgR01UKzA4OjAwIEh1Z28gR29uesOhbGV6IExhYnJhZG9yIDxTUEFOIGRpcj0ibHRy Ij4mbHQ7PEEgaHJlZj0ibWFpbHRvOmlldGZAaHVnby5sYWJrb2RlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmlldGZAaHVnby5sYWJrb2RlLmNvbTwvQT4mZ3Q7PC9TUEFOPjo8L1NQQU4+PEJSPjwvRElW Pgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNv bGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCI+CjxESVY+ PFNQQU4+SGksPC9TUEFOPjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5m cm9tIG15IHBvaW50IG9mIHZpZXcgdGhlIHJlbW90ZVN0b3JhZ2UgcHJvamVjdCBhZGRyZXNzZXMg YSBzdWJzZXQgb2Y8L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPnRoZSB1c2UgY2FzZXMgb2Yg dGhlJm5ic3A7IFdlYkRBViBzcGVjaWZpY2F0aW9uLjwvU1BBTj48QlI+PC9ESVY+CjxESVY+Jm5i c3A7PC9ESVY+CjxESVY+PFNQQU4+VGhlIG1haW4gZGlmZmVyZW5jZSBJIGNhbiBvYnNlcnZlIGlz IHRoYXQgdGhlIHNwZWNpZmljYXRpb24gaXMgYnVpbHQgb248L1NQQU4+PEJSPjwvRElWPgo8RElW PjxTUEFOPlJFU1QgaW5zdGVhZCBvZiBYTUwtYmFzZWQgY29tbXVuaWNhdGlvbi48L1NQQU4+PEJS PjwvRElWPjwvQkxPQ0tRVU9URT4KPEJMT0NLUVVPVEUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2Io MjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElO Ry1MRUZUOiAxZXgiPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPkkgcGVyc29uYWxseSBs aWtlIG11Y2ggbW9yZSBSRVNUIHRoYW4gV2ViREFWIGJlY2F1c2UgaXQgaXMgbW9yZTwvU1BBTj48 QlI+PC9ESVY+CjxESVY+PFNQQU4+ZGV2ZWxvcGVyIGZyaWVuZGx5IGFuZCBpdCBpcyBmYXN0ZXIg dG8gZGV2ZWxvcC48L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPiZuYnNwO01heWJlIHRoZSBy ZW1vdGVTdG9yYWdlIEFQSSBiZWNvbWVzIHRoZSBuZXh0IFdlYkRBViA6KTwvU1BBTj48QlI+PC9E SVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNQQU4+SG93ZXZlciwgdGhlIHJlbW90ZVN0b3Jh Z2UgQVBJIGRvZXMgbm90IHByb3ZpZGUgYSB3YXkgb2Ygc3luY2hyb25pc2luZzwvU1BBTj48QlI+ PC9ESVY+CjxESVY+PFNQQU4+ZGF0YSwgdGhpcyB0YXNrIGlzIGRlbGVnYXRlZCB0byB0aGUgZGV2 ZWxvcGVycy48L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPklzIHRoZXJlIGEgcGxhbiB0byBw cm92aWRlIHN1Y2ggZmVhdHVyZSBiYXNlZCBvbiB0aGUgb3V0Y29tZSBvZiB0aGlzPC9TUEFOPjxC Uj48L0RJVj4KPERJVj48U1BBTj5kcmFmdD88L1NQQU4+PEJSPjwvRElWPjwvQkxPQ0tRVU9URT4K PERJVj48U1BBTj5JJ20gYSBsaXR0bGUgYml0IGNvbmZ1c2VkIHdoeSB5b3Ugc2F5IHRoZSByZW1v dGVTdG9yYWdlIGRvZXMgbm90IHByb3ZpZGUgdGhhdC4gSXMgdGhhdCBiZWNhdXNlIHJlbW90ZVN0 b3JhZ2UgZG9lcyBub3QgcGVyZm9ybSBsaWtlIGEgdHlwaWNhbCBzeW5jIHNlcnZpY2VzIChlLmcu IGRyb3Bib3guLi4pIG9yIHlvdSBhcmUgc2F5aW5nIHNvbWV0aGluZyBlbHNlPzwvU1BBTj48QlI+ PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPjxTUEFOPlllcywgYmVj YXVzZSBpdCBkb2VzIG5vdCBvZmZlciBzeW5jaHJvbmlzYXRpb24gY2FwYWJpbGl0aWVzLjwvU1BB Tj48QlI+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPjxTUEFOPkdvdCBpdC4gQW5kIFdo YXQgSSBhbSB3b25kZXJpbmcgaXMgdGhhdCBkbyB3ZSBuZWVkIHRvIGluY2x1ZGUgdGhvc2UgY2Fw YWJpbGl0aWVzIGluIGEgYmFzZSBzcGVjaWZpY2F0aW9ucy4gU2luY2UgaXQgaXMgaGFyZCB0byBz dGFuZGFyZGl6ZSB0aGUgY2FwYWJpbGl0aWVzIGxpa2UgZGVkdXAgb3IgZGVsdGEuIE1heWJlIGEg YmV0dGVyIHdheSBpcyB0byBkZWZpbmUgdGhvc2UgaW4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9u LCA8L1NQQU4+PEJSPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4KPERJVj4m bmJzcDs8L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxE SVY+VGhhbmtzIGZvciBnaXZpbmcgdGhlc2UgZXhhbXBsZXMgLSBzbyBieSAnc3luY2hyb25pc2F0 aW9uIGNhcGFiaWxpdGllcycgeW91IG1lYW4gMSkgZGVkdXBsaWNhdGlvbiBhbmQgMikgZGVsdGEg dXBkYXRlcz8gQW55dGhpbmcgZWxzZSBvciBpcyB0aGF0IGFuIGV4aGF1c3RpdmUgbGlzdD8gPEJS PjwvRElWPjwvRElWPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0 LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6 IDFleCI+CjxESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8 RElWPgo8RElWIHN0eWxlPSJDT0xPUjogcmdiKDAsMCwwKSI+CjxESVYgc3R5bGU9Ik9WRVJGTE9X LVg6IHZpc2libGU7IE9WRVJGTE9XLVk6IHZpc2libGUiPgo8RElWPjxTUEFOPnNvbWV0aGluZyBs aWtlIGV4dGVuc2lvbnMuIEZvciBhIGJhc2UgZG9jdW1lbnQsIHdlIGp1c3QgbmVlZCB0byBkZWZp bmUgaG93IHRvIHBlcmZvcm0gc3luYyBvcGVyYXRpb25zLjwvU1BBTj48QlI+PC9ESVY+PC9ESVY+ PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwv RElWPgo8RElWPlllcywgSSBhZ3JlZSB0aGF0IG1heSBiZSBhbiBleHRlbnNpb24gb2YgdGhpcyBk cmFmdCBjb3VsZCBoYW5kbGUgdGhlIHN5bmNocm9uaXNhdGlvbiBwYXJ0LiA8QlI+PC9ESVY+CjxE SVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+PC9ESVY+ PC9CTE9DS1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPgo8RElWPk91ciBJbnRlcm5ldC1E cmFmdCBpcyBoZWF2aWx5IGZvY3VzZWQgb24gdGhlIHdvcmxkIHdpZGUgd2ViLCB3aG9zZSBVUkxz IGFyZSBub3QgY29udGVudC1hZGRyZXNzYWJsZSwgd2UgY2FuJ3QgY2hhbmdlIHRoYXQuIFNvIHRo YXQgYXJjaGl0ZWN0dXJlIGlzIG5vdCB2ZXJ5IGZyaWVuZGx5IHRvIGRlZHVwbGljYXRpb24sIGNv bXBhcmVkIHRvIGZvciBpbnN0YW5jZSBCaXRUb3JyZW50LiBBcyB5b3UgYWxyZWFkeSBzYWlkLCBk ZXZlbG9wZXJzIGNhbiBzdGlsbCBkZWR1cGUgb24gdGhlIHNlcnZlci1zaWRlIHdoZW4gc3Rvcmlu ZyBibG9icyB0byBkaXNrLCBhbmQgY2FuIGFsc28gZGVkdXBlIG9uIHRoZSBjbGllbnQgc2lkZSBi ZWZvcmUgY3JlYXRpbmcgdGhlIHJlc291cmNlcyB0aGUgY2xpZW50IHVwbG9hZHMuPEJSPjwvRElW PjwvRElWPgo8RElWPgo8RElWPkFzIGZhciBhcyBJIGtub3csIGRlbHRhIHVwZGF0ZXMgYXJlIG5v dCBzdXBwb3J0ZWQgYnkgdGhlIEVUYWcgc3lzdGVtIC0geW91IGNhbm5vdCBkbyBhIHJhbmdlIHJl cXVlc3QgdG8gZmluZCBvdXQgaWYgY2VydGFpbiBieXRlcyB3aXRoaW4gYSBkb2N1bWVudCBoYXZl IGNoYW5nZWQuIEhvd2V2ZXIsIHRoZSBmb2xkZXIgc3lzdGVtIHdlIGRlZmluZSBkb2VzIGVuY291 cmFnZSB5b3UsIGZvciBpbnN0YW5jZSB3aGVuIHlvdSBkZXZlbG9wIGEgVG8gRG8gTGlzdCBhcHAs IHB1dCBlYWNoIHRhc2sgb24gaXRzIG93biBkb2N1bWVudCwgYW5kIHRoZW4gcXVlcnkgdGhlIGZv bGRlciB0byBzZWUgd2hpY2ggb2YgdGhlbSBjaGFuZ2VkLCBpbnN0ZWFkIG9mIHB1dHRpbmcgdGhl bSBhbGwgaW4gb25lIGJpZyBkb2N1bWVudCBhbmQgcmV0cmlldmluZyB0aGUgd2hvbGUgZG9jdW1l bnQgZWFjaCB0aW1lLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj48L0RJVj4KPERJVj5DaGVl cnMsPEJSPjwvRElWPgo8RElWPk1pY2hpZWwuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8 QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlk OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCI+CjxESVY+CjxE SVY+Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgo8RElWPgo8RElWIHN0eWxl PSJDT0xPUjogcmdiKDAsMCwwKSI+CjxESVYgc3R5bGU9Ik9WRVJGTE9XLVg6IHZpc2libGU7IE9W RVJGTE9XLVk6IHZpc2libGUiPgo8QkxPQ0tRVU9URSBzdHlsZT0iQ09MT1I6IHJnYig0OCw1OSw2 NCkiPgo8RElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URT4KPERJViBkaXI9Imx0ciI+ CjxESVY+CjxESVY+CjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQs MjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDog MWV4Ij4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj48U1BBTj5CVFcsIEkgd2FudCB0byBpbnRyb2R1 Y2UgQ2xhd0lPICg8QSBocmVmPSJodHRwOi8vY2xhd2lvLmdpdGh1Yi5pby8iIHRhcmdldD0iX2Js YW5rIj48L0E+PEEgaHJlZj0iaHR0cDovL2NsYXdpby5naXRodWIuaW8vIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL2NsYXdpby5naXRodWIuaW88L0E+KSwgYSByZXNlYXJjaDwvU1BBTj48QlI+PC9E SVY+CjxESVY+PFNQQU4+cHJvamVjdCB0byBiZW5jaG1hcmsgZGlmZmVyZW50IHN5bmNocm9uaXNh dGlvbiBwcm90b2NvbHMgYWdhaW5zdDwvU1BBTj48QlI+PC9ESVY+CjxESVY+PFNQQU4+ZGlmZmVy ZW50IGRhdGEgYmFja2VuZHMgd2l0aCBzcGVjaWFsIGF0dGVudGlvbiB0byBwcm92aWRlIGEgY29t bW9uIHN5bmM8L1NQQU4+PEJSPjwvRElWPgo8RElWPjxTUEFOPkFQSS48L1NQQU4+PEJSPjwvRElW Pgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjxTUEFOPkEgY29tbW9uIEFQSSBmb3IgZGlmZmVyZW50 IHN5bmMgcHJvdG9jb2xzIGlzIGJlaW5nIGNyZWF0ZWQgYmFzZWQgb24gdGhlPC9TUEFOPjxCUj48 L0RJVj4KPERJVj48U1BBTj5hcmNoaXRlY3R1cmUgc3BlY2lmaWVkIGluIHRoaXMgZHJhZnQgKGNv bnRyb2wgYW5kIGRhdGEgc2VydmVycykgYW5kIHRoZTwvU1BBTj48QlI+PC9ESVY+PC9CTE9DS1FV T1RFPgo8RElWPjxTUEFOPkkgY2Fubm90IGZpbmQgYSBkaXN0cmlidXRlZCBhcmNoaXRlY3R1cmUg aW4gdGhpcyBkcmFmdC4gSXQgc2VlbXMgdGhhdCB0aGV5IGhhbmRsZSBtZXRhZGF0YSBhbmQgY29u dGVudCBkYXRhIHRvZ2V0aGVyLCBqdXN0IGxpa2UgYSBub3JtYWwgd2ViIHNlcnZpY2UuPC9TUEFO PjxCUj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5ic3A7PC9E SVY+CjxESVY+PFNQQU4+Q2xhd0lPIGlzIGZ1bGx5IGRpc3RyaWJ1dGVkLiBFdmVyeSBsb2dpY2Fs IHVuaXQgaXMgYSBkaWZmZXJlbnQgc2VydmVyIHRoYW4gYmUgc2NhbGVkIG91dC4gRGF0YSBhbmQg TWV0YWRhdGEgY2hhbm5lbHMgYXJlIGluZGVwZW5kZW50IGZyb20gZWFjaCBvdGhlciBhbmQgcmVz aWRlIG9uIGRpZmZlcmVudCBzZXJ2ZXJzLjwvU1BBTj48QlI+PC9ESVY+PC9ESVY+PC9CTE9DS1FV T1RFPgo8RElWPjxTUEFOPlRoYXQgaXMgd2lkZWx5IGVtcGxveWVkIGluIHBvcHVsYXIgc3luYyBz ZXJ2aWNlcy4gQW5kIHRoYXQgaXMgYWxzbyBiZW5lZmljaWFsIHRvIHByaXZhY3kgdG8gc29tZSBl eHRlbnQuIEJ1dCBpbiB0aGUgY29udGV4dCBvZiBzeW5jIGluIGJyb3dzZXIgKHdoaWNoIGlzIG1h aW5seSBjb25zaWRlcmVkIGluIHRoZSByZW1vdGVTdG9yYWdlKSwgSSBkb24ndCBrbm93IHdoZXRo ZXIgdGhpcyBpcyByZWFzb25hYmxlLiBCdXQgSSB0aGluayB3ZSBzaG91bGQgZGVwbG95IGRpc3Ry aWJ1dGVkIGFyY2hpdGVjdHVyZSBhbHRob3VnaCBpdCB3aWxsIG1ha2UgdGhpbmdzIGNvbXBsaWNh dGVkLjwvU1BBTj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElW PiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPk9mIGNvdXJzZSwgdGhlIHJlbW90 ZVN0b3JhZ2UgaXMgdGFyZ2V0ZWQgdG8gYnJvd3NlcnMsIHNvIHN5bmNpbmcgZG9lcyBub3QgbWFr ZSB0b28gbXVjaCBzZW5zZSBpbiB0aGlzIGNhc2UuPEJSPjwvRElWPgo8RElWPldpdGggdGhlIHJp c2Ugb2YgTGludXggY29udGFpbmVyIG1pY3JvLXNlcnZpY2UgYmFzZWQgYXJjaGl0ZWN0dXJlcywg dGhlIGRlcGxveW1lbnQgb2YgJm5ic3A7c3VjaCBoaWdobHkgY29tcGxleCBzeXN0ZW1zIHNob3Vs ZCBiZWNvbWUgZWFzaWVyIGFuZCBmYXN0ZXIuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8 RElWPkJlc3QsPFNQQU4+PFNQQU4gc3R5bGU9IkNPTE9SOiByZ2IoMTM2LDEzNiwxMzYpIj48L1NQ QU4+PC9TUEFOPjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4K PERJVj48U1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6IHJnYigxMzYsMTM2LDEzNikiPkh1Z288L1NQ QU4+PC9TUEFOPjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4KPERJVj4KPERJVj4m bmJzcDs8L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+CjxESVY+CjxESVYgc3R5bGU9IkNP TE9SOiByZ2IoMCwwLDApIj4KPERJViBzdHlsZT0iT1ZFUkZMT1ctWDogdmlzaWJsZTsgT1ZFUkZM T1ctWTogdmlzaWJsZSI+CjxESVY+UmVnYXJkcyw8QlI+PC9ESVY+CjxESVY+TGluaHVpJm5ic3A7 PEJSPjwvRElWPgo8QkxPQ0tRVU9URSBzdHlsZT0iQ09MT1I6IHJnYig0OCw1OSw2NCkiPgo8RElW Pgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URT4KPERJViBk aXI9Imx0ciI+CjxESVY+CjxESVY+CjxESVY+UmVnYXJkcyw8QlI+PC9ESVY+CjxESVY+TGluaHVp PEJSPjwvRElWPgo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIw NCkgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFl eCI+CjxESVY+b25lIGZyb20gdGhlIENFUk4gRU9TIHByb2plY3QgKG1hbmFnZW1lbnQsIGRpc2sg YW5kIHF1ZXVlIHNlcnZlcnMpLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5UaGUg UGhhc2UgSSBoYXMgaW1wbGVtZW50ZWQgdGhlIG93bkNsb3VkIFN5bmMgUHJvdG9jb2wgYW5kIFBo YXNlIElJIHdpbGw8QlI+PC9ESVY+CjxESVY+aW1wbGVtZW50IHRoZSBTZWFGaWxlIFN5bmMgUHJv dG9jb2wuPEJSPjwvRElWPgo8RElWPlRoZSBjaG9pY2Ugb2YgdGhlc2UgcHJvdG9jb2xzIGFtb25n IG90aGVycyBpcyBiZWNhdXNlIHRoZXkgYXJlIHJlYWxseTxCUj48L0RJVj4KPERJVj5vcHBvc2Vk IHRvIGVhY2ggb3RoZXIgaW4gdGVybXMgb2Ygc3luY2luZyAoZGVsdGEgdnMgbm9uLWRlbHRhLDxC Uj48L0RJVj4KPERJVj5zdGF0ZS1iYXNlZCB2cyBsb2cvZXZlbnQvZ2l0LWJhc2VkIHN5bmMg4oCm KSwgc28gZmluZGluZyBhIGNvbW1vbiBhcHByb2FjaDxCUj48L0RJVj4KPERJVj5pcyBtb3JlIGNo YWxsZW5naW5nLjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5Qcm92aWRpbmcgYSBi YXNlIHNwZWNpZmljYXRpb24vYXJjaGl0ZWN0dXJlIHRvIG1lYXN1cmUgdGhlIGZlYXNpYmlsaXR5 PEJSPjwvRElWPgo8RElWPm9mIHRoaXMgZHJhZnQgaXMgb25lIG9mIHRoZSBvYmplY3RpdmVzIG9m IHRoZSBwcm9qZWN0LjxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JIGJlbGlldmUg dGhhdCB0aGUgd29yayBiZWluZyBkb25lIGhlcmUgYW5kIGluIENsYXdJTyBhcmUgc3VwcGxlbWVu dGFyeTxCUj48L0RJVj4KPERJVj50byBlYWNoIG90aGVyIGFuZCBJIHRoaW5rIG11dHVhbCBjb2xs YWJvcmF0aW9uIGNvdWxkIGJlIGJlbmVmaWNpYWwgZm9yPEJSPjwvRElWPgo8RElWPmJvdGggc2lk ZXMuPEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkFsc28sIGlmIHRoZXJlIGlzIGlu dGVyZXN0LCB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgY2FuIGJlIGFkZGVkIHRvPEJSPjwvRElWPgo8 RElWPkNsYXdJTy48QlI+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+QmVzdCByZWdhcmRz LDxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5IdWdvIEdvbnphbGV6IExhYnJhZG9y PEJSPjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPk9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0 IDA5OjAwIFBNLCA8QSBocmVmPSJtYWlsdG86c3RvcmFnZXN5bmMtcmVxdWVzdEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnN0b3JhZ2VzeW5jLXJlcXVlc3RAaWV0Zi5vcmc8L0E+IHdyb3RlOjxC Uj48L0RJVj4KPERJVj4mZ3Q7IFNlbmQgU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0IHN1Ym1pc3Np b25zIHRvPEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8QSBo cmVmPSJtYWlsdG86c3RvcmFnZXN5bmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zdG9yYWdl c3luY0BpZXRmLm9yZzwvQT48QlI+PC9ESVY+CjxESVY+Jmd0OzxCUj48L0RJVj4KPERJVj4mZ3Q7 IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNp dDxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PEEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIgdGFyZ2V0 PSJfYmxhbmsiPjwvQT48QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N0b3JhZ2VzeW5jIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdG9yYWdlc3luYzwvQT48QlI+PC9ESVY+CjxESVY+Jmd0OyBvciwgdmlh IGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG88QlI+ PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxBIGhyZWY9Im1haWx0 bzpzdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3RvcmFnZXN5 bmMtcmVxdWVzdEBpZXRmLm9yZzwvQT48QlI+PC9ESVY+CjxESVY+Jmd0OzxCUj48L0RJVj4KPERJ Vj4mZ3Q7IFlvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdDxCUj48 L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PEEgaHJlZj0ibWFpbHRv OnN0b3JhZ2VzeW5jLW93bmVyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3RvcmFnZXN5bmMt b3duZXJAaWV0Zi5vcmc8L0E+PEJSPjwvRElWPgo8RElWPiZndDs8QlI+PC9ESVY+CjxESVY+Jmd0 OyBXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBt b3JlIHNwZWNpZmljPEJSPjwvRElWPgo8RElWPiZndDsgdGhhbiAiUmU6IENvbnRlbnRzIG9mIFN0 b3JhZ2VzeW5jIGRpZ2VzdC4uLiI8QlI+PC9ESVY+CjxESVY+Jmd0OyBUb2RheSdzIFRvcGljczo8 QlI+PC9ESVY+CjxESVY+Jmd0OzxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOyAxLiBO ZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSZuYnNwOyAmbmJzcDsgSW50 ZXJuZXQtRHJhZnQ8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2F2YWlsYWJsZSAoTWljaGllbCBkZSBKb25nKTxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZu YnNwOyAyLiBSZTogTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgSW50 ZXJuZXQtRHJhZnQ8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2F2YWlsYWJsZSAoR2loYW4gRGlhcyk8QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsg My4gUmU6IE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlIEludGVybmV0 LURyYWZ0PEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthdmFp bGFibGUgKEZlaSBTb25nKTxCUj48L0RJVj4KPERJVj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPjwvRElWPgo8RElWPiZndDsgU3RvcmFnZXN5 bmMgbWFpbGluZyBsaXN0PEJSPjwvRElWPgo8RElWPiZndDsgPEEgaHJlZj0ibWFpbHRvOlN0b3Jh Z2VzeW5jQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U3RvcmFnZXN5bmNAaWV0Zi5vcmc8L0E+ PEJSPjwvRElWPgo8RElWPiZndDsgPEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zdG9yYWdlc3luYyIgdGFyZ2V0PSJfYmxhbmsiPjwvQT48QSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYzwv QT48QlI+PC9ESVY+CjxESVY+Jmd0OyBFbWFpbCBoYWQgMyBhdHRhY2htZW50czo8QlI+PC9ESVY+ CjxESVY+Jmd0OyArIFtTdG9yYWdlc3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJl bW90ZXN0b3JhZ2U8QlI+PC9ESVY+CjxESVY+Jmd0OyBJbnRlcm5ldC1EcmFmdCBhdmFpbGFibGU8 QlI+PC9ESVY+CjxESVY+Jmd0OyZuYnNwOyAmbmJzcDsyayAobWVzc2FnZS9yZmM4MjIpPEJSPjwv RElWPgo8RElWPiZndDsgKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1k ZWpvbmctcmVtb3Rlc3RvcmFnZTxCUj48L0RJVj4KPERJVj4mZ3Q7IEludGVybmV0LURyYWZ0IGF2 YWlsYWJsZTxCUj48L0RJVj4KPERJVj4mZ3Q7Jm5ic3A7ICZuYnNwOzFrIChtZXNzYWdlL3JmYzgy Mik8QlI+PC9ESVY+CjxESVY+Jmd0OyArIFJlOiBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9m IGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlPEJSPjwvRElWPgo8RElWPiZndDsgSW50ZXJuZXQt RHJhZnQgYXZhaWxhYmxlPEJSPjwvRElWPgo8RElWPiZndDsmbmJzcDsgJm5ic3A7MmsgKG1lc3Nh Z2UvcmZjODIyKTxCUj48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj48L0RJVj4KPERJVj5TdG9yYWdl c3luYyBtYWlsaW5nIGxpc3Q8QlI+PC9ESVY+CjxESVY+PEEgaHJlZj0ibWFpbHRvOlN0b3JhZ2Vz eW5jQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U3RvcmFnZXN5bmNAaWV0Zi5vcmc8L0E+PEJS PjwvRElWPgo8RElWPjxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3RvcmFnZXN5bmMiIHRhcmdldD0iX2JsYW5rIj48L0E+PEEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmM8L0E+PEJSPjwv RElWPjwvQkxPQ0tRVU9URT48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5i c3A7PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9U RT4KPERJVj4mbmJzcDs8L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+ PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPgo8RElWPiZuYnNwOzwvRElWPjwvRElWPjwvRElWPjwv RElWPjwvQkxPQ0tRVU9URT48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+CjxESVY+Jm5i c3A7PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjxCUj48L0RJVj48 L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPjwvRElWPjwvRElWPjwvRElWPjwvQkxP Q0tRVU9URT48L0RJVj48L0RJVj48L0RJVj48QlI+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwv RElWPjxCUj48L0RJVj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PEJSPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPlN0b3JhZ2VzeW5jIG1haWxpbmcg bGlzdDxCUj48QSBocmVmPSJtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5TdG9yYWdlc3luY0BpZXRmLm9yZzwvQT48QlI+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdl c3luYzwvQT48QlI+PEJSPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9ESVY+PC9CTE9DS1FVT1RF Pg== ------=_Part_41660_1275101042.1449135111401-- From nobody Thu Dec 3 01:44:52 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E921B2CCF for ; Thu, 3 Dec 2015 01:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6HsWWZFE7Er for ; Thu, 3 Dec 2015 01:44:48 -0800 (PST) Received: from ursa.uberspace.de (ursa.uberspace.de [95.143.172.203]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A631AD0BC for ; Thu, 3 Dec 2015 01:44:47 -0800 (PST) Received: (qmail 24619 invoked from network); 3 Dec 2015 09:44:44 -0000 Received: from localhost (HELO ?10.87.3.103?) (127.0.0.1) by ursa.uberspace.de with SMTP; 3 Dec 2015 09:44:44 -0000 To: fsong@bjtu.edu.cn, Michiel de Jong References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> From: =?UTF-8?Q?Fran=c3=a7ois_Kooman?= X-Enigmail-Draft-Status: N1110 Message-ID: <56600F0A.9000200@tuxed.net> Date: Thu, 3 Dec 2015 10:44:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Linhui Sun , storagesync , =?UTF-8?Q?Hugo_Gonz=c3=a1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:44:50 -0000 On 12/03/2015 10:06 AM, fsong@bjtu.edu.cn wrote: > If we really want to discuss the Pros and Cons of WebDAV, can we > mark these three reasons as disadvantages of WebDAV? any support for > that? Personally, I do not think that is fair. > 1) it's a lot of work to implement this without using an existing > WebDAV library I do not see a problem in reusing an existing WebDAV library. This has the added benefit that you get a lot of functionality 'for free' and that existing test suites are available for testing compatibility. This is purely a practical argument! > 2) in practice, a lot of WebDAV servers get it wrong, > or don't implement all of WebDAV. It's very annoying for client > implementers to have to deal with servers that e.g. chose not to > implement LOCK and UNLOCK. The point is not to have a fully compliant (whatever that is exactly) WebDAV server. Either this ML (or remoteStorage specification) could determine a subset of WebDAV that would be required to be implemented. E.g. we exhaustively list the verbs that need to be implemented and their expected behavior. If we keep this a limited as possible and stay away from experimental features we have a high probability that most libraries will get it right! If we stay away from locking and ACLs the library situation looks a lot brighter :) > 3) we don't really need all these advanced > features on top of standard HTTP, just supporting GET/PUT/DELETE for > resources, and adding a simple folder description format, is enough > for most applications. Exactly! > For the target of our ISS group, whether the WebDAV can be reused is > critical. Well, my point is that there is little reason to reinvent the wheel if the only benefit is to use JSON instead of XML for folder listings. The amount of experience and available tooling for WebDAV is already huge! It would be a waste to throw this away just for liking JSON better. But maybe there are other reasons using (a limited set of) WebDAV is impossible or unwanted... Cheers, François From nobody Thu Dec 3 01:49:19 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832C61A0062 for ; Thu, 3 Dec 2015 01:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TmGAJ9ph9jV for ; Thu, 3 Dec 2015 01:49:11 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E4C1A004D for ; Thu, 3 Dec 2015 01:49:11 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 86E99204C5 for ; Thu, 3 Dec 2015 04:49:10 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute5.internal (MEProxy); Thu, 03 Dec 2015 04:49:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=9PIwv64AMb+6ZbFKSwAzIZwg6EE=; b=cHGcCp bZ8wPcvzu9xn5t69UcMsOWE2GtUzhjisuxfhhyRg4kNUd9MpbxtpwSKbqdpRb0sE KiAu7SR2prDRPlhd3k02DHc9Vj3wV+r+wGS8DkTPd0QGH0dcEDfG6l63jk45t4nL 1HrPkdskhXBurqBZtaeErmE/x9AUk4JZrk33M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=9PIwv64AMb+6ZbF KSwAzIZwg6EE=; b=RiHSlHYDRnhTgsXGWZFotZjJG7Y53eEzPU4lRqPg+TcomTQ e5J5pHefVzbH/rWJ/NT+fctpxSRztAMnGbHbHV6218Zj0AJtUZYyng/l0dulXC3I SZP0SbACQHEg4ff5Slgl1q0AN5WrxN556Y8vEWrOFbt593B6I3X9GPwq0d+M= Received: by web1.nyi.internal (Postfix, from userid 99) id 40249AF124D; Thu, 3 Dec 2015 04:49:10 -0500 (EST) Message-Id: <1449136149.4121117.456781881.1C2D2EA8@webmail.messagingengine.com> X-Sasl-Enc: ZdSJ7t6k1DMQMGL9bVFGuOlbAAqoZf45vMJqHfWz88Zi 1449136149 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: fsong@bjtu.edu.cn, Michiel de Jong MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_144913615041211170"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 Date: Thu, 03 Dec 2015 10:49:09 +0100 In-Reply-To: <5ca31214.2c3d.151672efcf7.Coremail.fsong@bjtu.edu.cn> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> <5ca31214.2c3d.151672efcf7.Coremail.fsong@bjtu.edu.cn> Archived-At: Cc: Linhui Sun , storagesync , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:49:17 -0000 This is a multi-part message in MIME format. --_----------=_144913615041211170 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" What is the best way to collect the advantages and drawbacks of WebDAV vs remoteStorage ? I propose to create a GitHub instead of/in addition to specify the differences here. I think is clear to show this info in something like a table on GitHub instead of in a series of mail messages. I can create the repo if it is okay for you. Best,Hugo On Thu, Dec 3, 2015, at 10:31 AM, fsong@bjtu.edu.cn wrote: > Great=EF=BC=81 > > >> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- *=E5=8F=91=E4=BB=B6=E4=BA= =BA:* "Michiel de Jong" >> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2015=E5=B9=B412=E6=9C=883=E6=97= =A5 =E6=98=9F=E6=9C=9F=E5=9B=9B *=E6=94=B6=E4=BB=B6=E4=BA=BA:* fsong@bjtu.e= du.cn *=E6=8A=84=E9=80=81:* "Linhui Sun" >> , storagesync , fkooman >> , "Hugo Gonz=C3=A1lez Labrador" >> *=E4=B8=BB=E9=A2=98:* Re: [Storagesync] Storagesync Digest, Vol 5, Issue= 1 >> >> Yes! I'll discuss with Francois how we can make these boundaries >> clearer. Maybe we can split along these lines: >> * upload/manipulate/query/download protocol (e.g. WebDAV or the >> GET/PUT/DELETE operations we currently define) >> * CORS or other cross-origin access mechanism, OAUTH or other auth >> mechanism, WebFinger or other discovery mechanism, ETag or other >> versioning mechanism >> * chunking/deduping/delta-updates >> >> And the remoteStorage spec should probably only define the >> middle part. >> >> >> On Thu, Dec 3, 2015 at 9:44 AM, wrote: >>> Hi Michiel and Linhui, >>> I think it will be good to have a boundary for this draft and leave >>> some work for the applicaiton layer~ >>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- *=E5=8F=91=E4=BB=B6=E4= =BA=BA:* "Michiel de Jong" >>>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2015=E5=B9=B412=E6=9C=882=E6= =97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89 *=E6=94=B6=E4=BB=B6=E4=BA=BA:* "Linhui S= un" >>>> *=E6=8A=84=E9=80=81:* storagesync , fkooman >>>> , "Hugo Gonz=C3=A1lez Labrador" >>>> *=E4=B8=BB=E9=A2=98:* Re: [Storagesync] Storag= esync Digest, >>>> Vol 5, Issue 1 >>>> >>>> Ah sure, that's entirely appropriate, remoteStorage treats both the >>>> Content-Type header value and the actual body of a document as >>>> opaque strings of bytes. It doesn't "care" if you use it to store >>>> only data blocks that are chunks of something else. For instance, >>>> you could have a folder on a user's storage that contains only inode- >>>> like JSON-documents, which list the URLs of binary documents that >>>> make up 1Kb blocks of the actual data. Nice for deduping, delta >>>> updates, and also renaming files without reuploading their content. >>>> >>>> But yeah, the argument is that *how* to create and manage these >>>> chunks, is then still left up to the application developer (or to >>>> another spec on top of the remoteStorage spec). >>>> >>>> >>>> Cheers, Michiel. >>>> >>>> On Wed, Dec 2, 2015 at 3:29 PM, Linhui Sun >>>> wrote: >>>>> Hi >>>>> >>>>> 2015-12-02 22:05 GMT+08:00 Michiel de Jong : >>>>>> Cool! I created https://github.com/remotestorage/spec/issues/137 >>>>>> about the need for=C2=A0 MOVE verb. Application-level chunking is >>>>>> partially supported by HTTP itself through `Content-Range` >>>>>> headers (although it's not clear whether these are allowed on PUT >>>>>> requests as well as on GET requests, see >>>>>> https://github.com/remotestorage/spec/issues/131). The problem is >>>>>> that HTTP defines versioning at the document level, you cannot >>>>>> ask a server to produce or check an ETag for a specific byte- >>>>>> range of a document, only for the entire document. >>>>> >>>>> Actually what I'm saying is a chunking before transmitting (using >>>>> http), in this way, they are treated as individual documents from >>>>> the standpoint of http. But I don't know whether this is >>>>> appropriate for remoteStorage, just a comment. >>>>> >>>>> Regards, Linhui >>>>>> >>>>>> A comparison document sounds good! See also >>>>>> http://www.servicedenuages.fr/en/generic-storage-ecosystem. >>>>>> >>>>>> >>>>>> Cheers, Michiel. >>>>>> >>>>>> >>>>>> On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun >>>>>> wrote: >>>>>>> That's cool for me, a separate section for this might make >>>>>>> sense. >>>>>>> >>>>>>> Another thing is do we need to include an application-layer >>>>>>> chunking here (not just for a browser sync), since if we want to >>>>>>> further extend other capabilities it is essential. >>>>>>> >>>>>>> Regards, Linhui >>>>>>> >>>>>>> 2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >>>>>>> : >>>>>>>> __ >>>>>>>> I propose to come up with a list of advantages and >>>>>>>> disadvantages of using WebDAV and compare them against a >>>>>>>> JSON/REST based approach, like remoteStorage. >>>>>>>> >>>>>>>> Does it sound good ? >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >>>>>>>>> : >>>>>>>>>> __ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: >>>>>>>>>>> Hi all! Thanks for all your reactions to the remoteStorage >>>>>>>>>>> Internet-Draft. >>>>>>>>>>> >>>>>>>>>>> We get the question about WebDAV a lot, in the next version >>>>>>>>>>> we should add a remark about it in the intro. The folder >>>>>>>>>>> descriptions returned when you GET a URL that ends with a / >>>>>>>>>>> are indeed a deviation from the XML returned by WebDAV >>>>>>>>>>> server, and this is just because nowadays JSON is easier to >>>>>>>>>>> use than XML for developers, both client-side and server- >>>>>>>>>>> side. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I totally agree here, this was going to happen soon or later >>>>>>>>>> and it is really appreciated. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The fact that we don't require servers to support WebDAV's >>>>>>>>>>> custom verbs like PROPPATCH etc. is for three reasons: >>>>>>>>>>> 1) it's a lot of work to implement this without using an >>>>>>>>>>> existing WebDAV library >>>>>>>>>>> 2) in practice, a lot of WebDAV servers get it wrong, or >>>>>>>>>>> don't implement all of WebDAV. It's very annoying for >>>>>>>>>>> client implementers to have to deal with servers that >>>>>>>>>>> e.g. chose not to implement LOCK and UNLOCK. >>>>>>>>>>> 3) we don't really need all these advanced features on top >>>>>>>>>>> of standard HTTP, just supporting GET/PUT/DELETE for >>>>>>>>>>> resources, and adding a simple folder description format, >>>>>>>>>>> is enough for most applications. >>>>>>>>>>> >>>>>>>>>>> Other than that, the remoteStorage Internet-Draft specifies >>>>>>>>>>> a *lot* more than just how each HTTP verb should behave: >>>>>>>>>>> * requiring support for OAuth implicit-grant flow >>>>>>>>>>> * requiring ETag support and nested versioning (i.e. the >>>>>>>>>>> folder's ETag changes if anything within that folder >>>>>>>>>>> changes) >>>>>>>>>>> * requiring CORS headers >>>>>>>>>>> * requiring a WebFinger announcement for service discovery >>>>>>>>>>> It would be easy to add these three things on top of >>>>>>>>>>> WebDAV, instead of putting them on top of our minimal >>>>>>>>>>> GET/PUT/DELETE API definition. In fact, we could probably >>>>>>>>>>> separate it into two Internet-Drafts: one for the 'RESTful >>>>>>>>>>> folders' API which is our simplification of WebDAV, and a >>>>>>>>>>> second one for OAuth/ETags/CORS/WebFinger on top of either >>>>>>>>>>> WebDAV or 'RESTful folders' or whatever other HTTP-based >>>>>>>>>>> API you want. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There is one requirement that all synchronisers need to >>>>>>>>>> handle: moving resources. In this spec the alternative of a >>>>>>>>>> WebDAV MOVE is not specified. >>>>>>>>>> >>>>>>>>>> It is true that a MOVE could be replaced with a DELETE + >>>>>>>>>> UPLOAD but that is not acceptable in most cases due to the >>>>>>>>>> inefficiency of such operation (cpu, bandwidth consumption >>>>>>>>>> ...) >>>>>>>>>> >>>>>>>>>> Is there a plan to support such basic feature? >>>>>>>>>> >>>>>>>>>> From the current remoteStorage spec, the ownCloud sync >>>>>>>>>> protocol can be implemented. The missing bit is tracking >>>>>>>>>> those remote moves. >>>>>>>>> I agree with Hugo that MOVE is useful, sometimes if you just >>>>>>>>> rename a file it will be perfect. But the question I have is >>>>>>>>> that whether we need to make two documents? Multiple choices >>>>>>>>> is not good for standardization. In my view, webdav is >>>>>>>>> something that we need to have a very clear decision on >>>>>>>>> whether to consider it or not. >>>>>>>>> >>>>>>>>> Regards, Linhui >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>>> On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador >>>>>>>>>>> wrote: >>>>>>>>>>>> __ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gon= z=C3=A1lez Labrador >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: >>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador >>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> from my point of view the remoteStorage project >>>>>>>>>>>>>>>> addresses a subset of the use cases of the=C2=A0 WebDAV >>>>>>>>>>>>>>>> specification. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The main difference I can observe is that the >>>>>>>>>>>>>>>> specification is built on REST instead of XML-based >>>>>>>>>>>>>>>> communication. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I personally like much more REST than WebDAV because it >>>>>>>>>>>>>>>> is more developer friendly and it is faster to develop. >>>>>>>>>>>>>>>> Maybe the remoteStorage API becomes the next WebDAV :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, the remoteStorage API does not provide a way >>>>>>>>>>>>>>>> of synchronising data, this task is delegated to the >>>>>>>>>>>>>>>> developers. Is there a plan to provide such feature >>>>>>>>>>>>>>>> based on the outcome of this draft? >>>>>>>>>>>>>>> I'm a little bit confused why you say the remoteStorage >>>>>>>>>>>>>>> does not provide that. Is that because remoteStorage >>>>>>>>>>>>>>> does not perform like a typical sync services (e.g. >>>>>>>>>>>>>>> dropbox...) or you are saying something else? >>>>>>>>>>>>>> Yes, because it does not offer synchronisation >>>>>>>>>>>>>> capabilities. >>>>>>>>>>>>> Got it. And What I am wondering is that do we need to >>>>>>>>>>>>> include those capabilities in a base specifications. Since >>>>>>>>>>>>> it is hard to standardize the capabilities like dedup or >>>>>>>>>>>>> delta. Maybe a better way is to define those in a separate >>>>>>>>>>>>> specification, >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for giving these examples - so by 'synchronisation >>>>>>>>>>> capabilities' you mean 1) deduplication and 2) delta >>>>>>>>>>> updates? Anything else or is that an exhaustive list? >>>>>>>>>>>> >>>>>>>>>>>>> something like extensions. For a base document, we just >>>>>>>>>>>>> need to define how to perform sync operations. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yes, I agree that may be an extension of this draft could >>>>>>>>>>>> handle the synchronisation part. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Our Internet-Draft is heavily focused on the world wide web, >>>>>>>>>>> whose URLs are not content-addressable, we can't change >>>>>>>>>>> that. So that architecture is not very friendly to >>>>>>>>>>> deduplication, compared to for instance BitTorrent. As you >>>>>>>>>>> already said, developers can still dedupe on the server-side >>>>>>>>>>> when storing blobs to disk, and can also dedupe on the >>>>>>>>>>> client side before creating the resources the client >>>>>>>>>>> uploads. As far as I know, delta updates are not supported >>>>>>>>>>> by the ETag system - you cannot do a range request to find >>>>>>>>>>> out if certain bytes within a document have changed. >>>>>>>>>>> However, the folder system we define does encourage you, for >>>>>>>>>>> instance when you develop a To Do List app, put each task on >>>>>>>>>>> its own document, and then query the folder to see which of >>>>>>>>>>> them changed, instead of putting them all in one big >>>>>>>>>>> document and retrieving the whole document each time. >>>>>>>>>>> >>>>>>>>>>> Cheers, Michiel. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> BTW, I want to introduce ClawIO >>>>>>>>>>>>>>>> (http://clawio.github.io[1]), a research project to >>>>>>>>>>>>>>>> benchmark different synchronisation protocols against >>>>>>>>>>>>>>>> different data backends with special attention to >>>>>>>>>>>>>>>> provide a common sync API. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A common API for different sync protocols is being >>>>>>>>>>>>>>>> created based on the architecture specified in this >>>>>>>>>>>>>>>> draft (control and data servers) and the >>>>>>>>>>>>>>> I cannot find a distributed architecture in this draft. >>>>>>>>>>>>>>> It seems that they handle metadata and content data >>>>>>>>>>>>>>> together, just like a normal web service. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ClawIO is fully distributed. Every logical unit is a >>>>>>>>>>>>>> different server than be scaled out. Data and Metadata >>>>>>>>>>>>>> channels are independent from each other and reside on >>>>>>>>>>>>>> different servers. >>>>>>>>>>>>> That is widely employed in popular sync services. And that >>>>>>>>>>>>> is also beneficial to privacy to some extent. But in the >>>>>>>>>>>>> context of sync in browser (which is mainly considered in >>>>>>>>>>>>> the remoteStorage), I don't know whether this is >>>>>>>>>>>>> reasonable. But I think we should deploy distributed >>>>>>>>>>>>> architecture although it will make things complicated. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Of course, the remoteStorage is targeted to browsers, so >>>>>>>>>>>> syncing does not make too much sense in this case. With the >>>>>>>>>>>> rise of Linux container micro-service based architectures, >>>>>>>>>>>> the deployment of =C2=A0such highly complex systems should >>>>>>>>>>>> become easier and faster. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hugo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Regards, Linhui >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, Linhui >>>>>>>>>>>>>>>> one from the CERN EOS project (management, disk and >>>>>>>>>>>>>>>> queue servers). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The Phase I has implemented the ownCloud Sync Protocol >>>>>>>>>>>>>>>> and Phase II will implement the SeaFile Sync Protocol. >>>>>>>>>>>>>>>> The choice of these protocols among others is because >>>>>>>>>>>>>>>> they are really opposed to each other in terms of >>>>>>>>>>>>>>>> syncing (delta vs non-delta, state-based vs log/event/git- >>>>>>>>>>>>>>>> based sync =E2=80=A6), so finding a common approach is more >>>>>>>>>>>>>>>> challenging. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Providing a base specification/architecture to measure >>>>>>>>>>>>>>>> the feasibility of this draft is one of the objectives >>>>>>>>>>>>>>>> of the project. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I believe that the work being done here and in ClawIO >>>>>>>>>>>>>>>> are supplementary to each other and I think mutual >>>>>>>>>>>>>>>> collaboration could be beneficial for both sides. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, if there is interest, the remoteStorage API can >>>>>>>>>>>>>>>> be added to ClawIO. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hugo Gonzalez Labrador >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync- >>>>>>>>>>>>>>>> request@ietf.org wrote: >>>>>>>>>>>>>>>> > Send Storagesync mailing list submissions to >>>>>>>>>>>>>>>> > storagesync@ietf.org >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > To subscribe or unsubscribe via the World Wide Web, >>>>>>>>>>>>>>>> > visit >>>>>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/storagesync or, >>>>>>>>>>>>>>>> > via email, send a message with subject or body 'help' >>>>>>>>>>>>>>>> > to=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > You can reach the person managing the list at >>>>>>>>>>>>>>>> > storagesync-owner@ietf.org >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > When replying, please edit your Subject line so it is >>>>>>>>>>>>>>>> > more specific than "Re: Contents of Storagesync >>>>>>>>>>>>>>>> > digest..." Today's Topics: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >1. New version of draft-dejong-remotestorage=C2=A0 =C2=A0= Internet- >>>>>>>>>>>>>>>> >Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jon= g)=C2=A0 =C2=A0 2. Re: New >>>>>>>>>>>>>>>> >version of draft-dejong-remotestorage Internet-Draft >>>>>>>>>>>>>>>> >available (Gihan Dias)=C2=A0 =C2=A0 3. Re: New version of= draft-dejong- >>>>>>>>>>>>>>>> >remotestorage Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0av= ailable (Fei >>>>>>>>>>>>>>>> >Song) >>>>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>>>> > Storagesync mailing list Storagesync@ietf.org >>>>>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/storagesync >>>>>>>>>>>>>>>> > Email had 3 attachments: >>>>>>>>>>>>>>>> > + [Storagesync] New version of draft-dejong- >>>>>>>>>>>>>>>> > remotestorage Internet-Draft available=C2=A0 =C2=A02k >>>>>>>>>>>>>>>> > (message/rfc822) >>>>>>>>>>>>>>>> > + Re: [Storagesync] New version of draft-dejong- >>>>>>>>>>>>>>>> > remotestorage Internet-Draft available=C2=A0 =C2=A01k >>>>>>>>>>>>>>>> > (message/rfc822) >>>>>>>>>>>>>>>> > + Re: [Storagesync] New version of draft-dejong- >>>>>>>>>>>>>>>> > remotestorage Internet-Draft available=C2=A0 =C2=A02k >>>>>>>>>>>>>>>> > (message/rfc822) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Storagesync mailing list Storagesync@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/storagesync >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Storagesync mailing list Storagesync@ietf.org >>> https://www.ietf.org/mailman/listinfo/storagesync Links: 1. http://clawio.github.io/ --_----------=_144913615041211170 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
What is the best way to collect the advantages and drawbacks of = WebDAV vs remoteStorage ?
 
I propose to create a GitHub instead of/in addition to specify the dif= ferences here. I think is clear to show this info in something like a table= on GitHub instead of in a series of mail messages.
 
I can create the repo if it is okay for you.
 
Best,Hugo
 
 
Great=EF=BC=81
 
 
-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-= ----
=E5=8F=91=E4=BB=B6=E4=BA=BA: "Michiel de Jong" <mbdejong@moz= illa.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B412=E6=9C=883= =E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B
=E6=94=B6=E4=BB=B6=E4=BA=BA: fsong@bjtu.edu.cn
=E6=8A=84=E9=80=81: "Linhui Sun" <lh.sunlinh@gmail.com>, = storagesync <storagesync@ietf.org>, fkooman <fkooman@tuxed.net>= , "Hugo Gonz=C3=A1lez Labrador" <ietf@hugo.labkode.com>
=E4=B8=BB=E9=A2=98: Re: [Storagesync] Storagesync Digest, Vol 5= , Issue 1
 
Yes! I'll discuss with Francois h= ow we can make these boundaries clearer. Maybe we can split along these lin= es:
* upload/manipulate/query/download protocol (e.g. WebDAV or the GET/PU= T/DELETE operations we currently define)
* CORS or other cross-origin access mechanism, OAUTH or other auth mec= hanism, WebFinger or other discovery mechanism, ETag or other versioning me= chanism
* chunking/deduping/delta-updates
 
And the remoteStorage spec should probably only define the middle part= .
 
 
On Thu, Dec 3, 2015 at 9:44 AM, <fsong@bjtu.edu.cn> wrote:

Hi Michiel and Linhui,

<= p>
I think it will be good to have a boundary for this draft and leave = some work for the applicaiton layer~

-----=E5=8E=9F=E5=A7=8B=E9=82=AE= =E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: "Michiel de Jong" <= ;mbdejong@mozilla.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B412=E6=9C=882=E6=97= =A5 =E6=98=9F=E6=9C=9F=E4=B8=89
=E6=94=B6=E4=BB=B6=E4=BA=BA: "Lin= hui Sun" <lh.sunlinh@gmail.com>
=E6=8A=84=E9=80=81: storagesync <storagesync@ietf.org>, fkooman <fkooman@tuxed.net>, "Hugo Gonz=C3=A1lez Labrad= or" <ietf@hugo.labkode.com&= gt;
=E4=B8=BB=E9=A2=98: Re: [Storagesync] Storagesync Digest, Vol= 5, Issue 1

Ah sure, that's entirely app= ropriate, remoteStorage treats both the Content-Type header value and the a= ctual body of a document as opaque strings of bytes. It doesn't "care" if y= ou use it to store only data blocks that are chunks of something else.
<= /div>
For instance, you could have a folder on a user's storage that contain= s only inode-like JSON-documents, which list the URLs of binary documents t= hat make up 1Kb blocks of the actual data. Nice for deduping, delta updates= , and also renaming files without reuploading their content.
 
But yeah, the argument is that *how* to create and manage these chunks= , is then still left up to the application developer (or to another spec on= top of the remoteStorage spec).
 
 
Cheers,
Michiel.
 
On Wed, Dec 2, 2015 at 3:29 PM, Linhui Sun <= lh.sunlinh@gmail.com>= wrote:
Hi
 
2015-12-02 22:05 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com><= /span>:
Cool! I created https://github.com/remotestorage/spec/issues/137 about the n= eed for  MOVE verb.
Application-level chunking is partially supported by HTTP itself= through `Content-Range` headers (although it's not clear whether these are= allowed on PUT requests as well as on GET requests, see https://github.com/remotestorage= /spec/issues/131). The problem is that HTTP defines versioning at the d= ocument level, you cannot ask a server to produce or check an ETag for a sp= ecific byte-range of a document, only for the entire document.
 
Actually what I'm saying is a chunking before transmitting (using http= ), in this way, they are treated as individual documents from the standpoin= t of http. But I don't know whether this is appropriate for remoteStorage, = just a comment.
 
Regards,
Linhui
 
A comparison document sounds good! See also http://www.servicedenuages.fr/= en/generic-storage-ecosystem.
 
 
Cheers,
Michiel.
 
 
On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun <= lh.sunlinh@gmail.com>= wrote:
That's cool = for me, a separate section for this might make sense.
 
Another thing is do we need to include an application-layer chunk= ing here (not just for a browser sync), since if we want to further extend = other capabilities it is essential.
 
Regards,
Linhui
 
2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com= >:

I propose to come up with a list of advantages and disadvantages = of using WebDAV and compare them against a JSON/REST based approach, like r= emoteStorage.
 
Does it sound good ?
 
 
On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote:
 
 
2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com= >:

 
 
 
 
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:<= br>
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draf= t.
 
We get the question about WebDAV a lot, in the next version we s= hould add a remark about it in the intro. The folder descriptions returned = when you GET a URL that ends with a / are indeed a deviation from the XML r= eturned by WebDAV server, and this is just because nowadays JSON is easier = to use than XML for developers, both client-side and server-side.
 
 
I totally agree here, this was going to happen soon or later and it is= really appreciated.
 
 
The fact that we don't require servers to support W= ebDAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an existin= g WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don't i= mplement all of WebDAV. It's very annoying for client implementers to have = to deal with servers that e.g. chose not to implement LOCK and UNLOCK.
3) we don't really need all these advanced features on top of st= andard HTTP, just supporting GET/PUT/DELETE for resources, and adding a sim= ple folder description format, is enough for most applications.
<= /div>
 
Other than that, the remoteStorage Internet-Draft specifies a *l= ot* more than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder'= s ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, ins= tead of putting them on top of our minimal GET/PUT/DELETE API definition. I= n fact, we could probably separate it into two Internet-Drafts: one for the= 'RESTful folders' API which is our simplification of WebDAV, and a second = one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful fold= ers' or whatever other HTTP-based API you want.
 
 
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.=  
 
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
 
Is there a plan to support such basic feature?
 
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you j= ust rename a file it will be perfect. But the question I have is that wheth= er we need to make two documents? Multiple choices is not good for standard= ization. In my view, webdav is something that we need to have a very clear = decision on whether to consider it or not.
 
Regards,
Linhui
 
 
Cheers
 
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrot= e:

 
 
 
 
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
 
On =E5=91=A8=E4=B8=89, 1= 2=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:
<= /div>
 
 
 
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
 
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode= .com>:
Hi,
 
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the  WebDAV specification.
 
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
 
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
 Maybe the remoteStorage API becomes the next WebDAV :)
 
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remoteSto= rage does not provide that. Is that because remoteStorage does not perform = like a typical sync services (e.g. dropbox...) or you are saying something = else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
 
 
Thanks for giving these examples - so by 'synchronisation capabilities= ' you mean 1) deduplication and 2) delta updates? Anything else or is that = an exhaustive list?
 
something like exte= nsions. For a base document, we just need to define how to perform sync ope= rations.
 
 
Yes, I agree that may be an extension of this draft could handle the s= ynchronisation part.
 
 
 
 
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that architect= ure is not very friendly to deduplication, compared to for instance BitTorr= ent. As you already said, developers can still dedupe on the server-side wh= en storing blobs to disk, and can also dedupe on the client side before cre= ating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
 
Cheers,
Michiel.
 
 
 
 
BTW, I want to introduce ClawIO (http://clawio.github.io)= , a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
 
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
 
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don't= know whether this is reasonable. But I think we should deploy distributed = architecture although it will make things complicated.
 
 
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of  such highly complex systems should become easier and = faster.
 
Best,<= /span>
 
 
Hugo
 
 
Regards,
Linhui 
 
 
Regards,
Linhui
one from the CERN EOS project= (management, disk and queue servers).
 
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
 
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
 
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
 
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
 
Best regards,
 
Hugo Gonzalez Labrador
 
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://www.ietf.org/mailman/listinfo/storagesync
> or, via email, send a message with subject or body 'help' to
<= /div>
>
> You can reach the person managing the list at
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>    1. New version of draft-dejong-remotestorage  &= nbsp; Internet-Draft
>       available (Michiel de Jong)
>    2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>       available (Gihan Dias)
>    3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>       available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
> + [Storagesync] New version of draft-dejong-remotestorage
> Internet-Draft available
>   2k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
>   1k (message/rfc822)
> + Re: [Storagesync] New version of draft-dejong-remotestorage
=
> Internet-Draft available
>   2k (message/rfc822)
 
_______________________________________________
Storagesync mailing list
 
 
 
 
 
 
 
 
 
_______________________________________________
Storagesync mailing list
 
--_----------=_144913615041211170-- From nobody Thu Dec 3 01:52:56 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C591A1BD7 for ; Thu, 3 Dec 2015 01:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn9xe2Fw-mJh for ; Thu, 3 Dec 2015 01:52:52 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB83E1A1BCD for ; Thu, 3 Dec 2015 01:52:52 -0800 (PST) Received: by igl9 with SMTP id 9so7434093igl.0 for ; Thu, 03 Dec 2015 01:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=neO3MAzu4hAkjrItQNB8h0WAhFaDeh/iDBgcIqwrwLs=; b=Pj7oHLeQmiriRGBZZxB1puSyFPTO1Zg/clZkuKpBhydqzI/rtwYVlGNfWRD0/d8fsQ +37/06N6EjP1D0nl0cmEe3x5dN2/2Nm9USy+ugs+cvVToDY4pFN0+CcYtFMTXC/ZnGRp Eaekf1NtGr3blGaXymP+NoSKIM6G1LIkH8HGUNKLXOx/euY2RiG/P9fKMnjTu+35bn4m 3JCJVI0+qp+Qjbg0SdY8dlpuQdSob+kBHNw8Ure5trDVinrOyR8ehbI3GdZmURnqNG8c B0Noo4+BoPL7uL5vyCgg417ynnGbrHCq1kIuIQceT5DicgWQCEUchLjIm/Julx62tXsx rbjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=neO3MAzu4hAkjrItQNB8h0WAhFaDeh/iDBgcIqwrwLs=; b=k2C4b4Uiimw1sqUn1TJZu/XynhnOWT3+84uevbK9O6/oGAD5obswDhVOYQ9eoIVuD5 P7xa4OVHYvmQ52YLgCpnUvs7WTrX3M5XbtTgVs25AzB6Vh21t/7HxGRgGrvAImDck+Do ba8xDoXsZ9pYimhfa78wWG/oY9FiYkL4xAFaxTuLwOSJa3B2ytMYF3UXuWjykB4HAakq cURxmKV0EYZTUkSVmtwsFObYwPuBcGkdKFlHm2ZCwDCIouGPGJ/lCFqv61798XJ/DOYy 0kYpBOP/C4PvZ92h5P7eOuvfdygPN92Lm5o+UJE5+NF4ehwDCOBpZleIP4CtnEIfp7Tf mLoQ== X-Gm-Message-State: ALoCoQlvLk54+1SqZaJeStCAcbhxL0Kv6LDScYUCn34gxbbc+uw6pu/yfu5x/0AamL0xqxXSnMMy MIME-Version: 1.0 X-Received: by 10.50.90.180 with SMTP id bx20mr8865694igb.9.1449136372114; Thu, 03 Dec 2015 01:52:52 -0800 (PST) Received: by 10.107.137.68 with HTTP; Thu, 3 Dec 2015 01:52:51 -0800 (PST) In-Reply-To: <56600F0A.9000200@tuxed.net> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> Date: Thu, 3 Dec 2015 10:52:51 +0100 Message-ID: From: Michiel de Jong To: =?UTF-8?Q?Fran=C3=A7ois_Kooman?= Content-Type: multipart/alternative; boundary=047d7bea3d28b107a40525fb5a44 Archived-At: Cc: fsong@bjtu.edu.cn, Linhui Sun , storagesync , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 09:52:55 -0000 --047d7bea3d28b107a40525fb5a44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we should not (try to) pick one protocol - https://xkcd.com/927/ I think sync *clients* should be "protocol polyglots" in the same way as https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#Proto= col_support On Thu, Dec 3, 2015 at 10:44 AM, Fran=C3=A7ois Kooman w= rote: > On 12/03/2015 10:06 AM, fsong@bjtu.edu.cn wrote: > > If we really want to discuss the Pros and Cons of WebDAV, can we > > mark these three reasons as disadvantages of WebDAV? any support for > > that? > > Personally, I do not think that is fair. > > > 1) it's a lot of work to implement this without using an existing > > WebDAV library > > I do not see a problem in reusing an existing WebDAV library. This has > the added benefit that you get a lot of functionality 'for free' and > that existing test suites are available for testing compatibility. This > is purely a practical argument! > > > 2) in practice, a lot of WebDAV servers get it wrong, > > or don't implement all of WebDAV. It's very annoying for client > > implementers to have to deal with servers that e.g. chose not to > > implement LOCK and UNLOCK. > > The point is not to have a fully compliant (whatever that is exactly) > WebDAV server. Either this ML (or remoteStorage specification) could > determine a subset of WebDAV that would be required to be implemented. > E.g. we exhaustively list the verbs that need to be implemented and > their expected behavior. If we keep this a limited as possible and stay > away from experimental features we have a high probability that most > libraries will get it right! If we stay away from locking and ACLs the > library situation looks a lot brighter :) > > > 3) we don't really need all these advanced > > features on top of standard HTTP, just supporting GET/PUT/DELETE for > > resources, and adding a simple folder description format, is enough > > for most applications. > > Exactly! > > > For the target of our ISS group, whether the WebDAV can be reused is > > critical. > > Well, my point is that there is little reason to reinvent the wheel if > the only benefit is to use JSON instead of XML for folder listings. The > amount of experience and available tooling for WebDAV is already huge! > It would be a waste to throw this away just for liking JSON better. > > But maybe there are other reasons using (a limited set of) WebDAV is > impossible or unwanted... > > Cheers, > Fran=C3=A7ois > --047d7bea3d28b107a40525fb5a44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we should not (try to) pick one protocol= - https://xkcd.com/927/
I think sync *clients* should be "protocol polyglots" in t= he same way as https://en.wikipedia.org/wiki/Compar= ison_of_instant_messaging_clients#Protocol_support

On Thu, Dec 3, 2015 at 10:4= 4 AM, Fran=C3=A7ois Kooman <fkooman@tuxed.net> wrote:
On 12/03/2015 10:06 AM, fsong@bjtu.edu.cn wrote:
> If we really want to discuss the Pros and Cons of WebDAV, can we
> mark these three reasons as disadvantages of WebDAV? any support for > that?

Personally, I do not think that is fair.

> 1) it's a lot of work to implement this without using an existing<= br> > WebDAV library

I do not see a problem in reusing an existing WebDAV library. This h= as
the added benefit that you get a lot of functionality 'for free' an= d
that existing test suites are available for testing compatibility. This
is purely a practical argument!

> 2) in practice, a lot of WebDAV servers get it wrong,
> or don't implement all of WebDAV. It's very annoying for clien= t
> implementers to have to deal with servers that e.g. chose not to
> implement LOCK and UNLOCK.

The point is not to have a fully compliant (whatever that is exactly= )
WebDAV server. Either this ML (or remoteStorage specification) could
determine a subset of WebDAV that would be required to be implemented.
E.g. we exhaustively list the verbs that need to be implemented and
their expected behavior. If we keep this a limited as possible and stay
away from experimental features we have a high probability that most
libraries will get it right! If we stay away from locking and ACLs the
library situation looks a lot brighter :)

> 3) we don't really need all these advanced
> features on top of standard HTTP, just supporting GET/PUT/DELETE for > resources, and adding a simple folder description format, is enough > for most applications.

Exactly!

> For the target of our ISS group, whether the WebDAV can be reused is > critical.

Well, my point is that there is little reason to reinvent the wheel = if
the only benefit is to use JSON instead of XML for folder listings. The
amount of experience and available tooling for WebDAV is already huge!
It would be a waste to throw this away just for liking JSON better.

But maybe there are other reasons using (a limited set of) WebDAV is
impossible or unwanted...

Cheers,
Fran=C3=A7ois

--047d7bea3d28b107a40525fb5a44-- From nobody Thu Dec 3 02:05:45 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0297A1A6F47 for ; Thu, 3 Dec 2015 02:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICJGyJQdEEXr for ; Thu, 3 Dec 2015 02:05:41 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0ECA1A6F3B for ; Thu, 3 Dec 2015 02:05:40 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 39DBA20BAD for ; Thu, 3 Dec 2015 05:05:40 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 03 Dec 2015 05:05:40 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=XPEXVyel+WK0RBzRvZ0Sh/cPYrw=; b=ngknNj kZE2HD4hcyvvviuJbvTOdMtgYytcTU8t1euvZdlPl6Fb6SoaT9Q0J/X+V99tpmcR 6NLYX7ii5EL8XyOJrY0k8LllPF/+KgD9OIObglHKZNlFtcun68ptBzdBR1zDc5vv zbtxuIS/Rxp6cVerntSu89oz5t1g7Y6fyRi20= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=XPEXVyel+WK0RBz RvZ0Sh/cPYrw=; b=ZIosggXRqhDIdmufmwUFkvZ14oRYXjjVp0Uh6tCBmnooEQC 3GPi4cPQd0wUjyceVd48zcvwPgUAYTqsY+yfvdOOvUF5BTSSvyw/AlxSUIwOGps1 80LMJCRjP5qc2EPgmXpVrTy/Okn0pfZjeOc9H2f1i64t82NvTFYPG7k99wZw= Received: by web1.nyi.internal (Postfix, from userid 99) id F2ADDAF128E; Thu, 3 Dec 2015 05:05:39 -0500 (EST) Message-Id: <1449137139.4126055.456789761.295F86DA@webmail.messagingengine.com> X-Sasl-Enc: 7NdxGb2uR+rXRwHfKmsni4LVfh7QE3YmAc/Y8int3tEm 1449137139 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: Michiel de Jong , =?ISO-8859-1?Q?Fran=E7ois=20Kooman?= MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_144913713941260553"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> Date: Thu, 03 Dec 2015 11:05:39 +0100 Archived-At: Cc: fsong@bjtu.edu.cn, Linhui Sun , storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 10:05:44 -0000 This is a multi-part message in MIME format. --_----------=_144913713941260553 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" If clients need to be polyglot, then I don't see the need for remoteStorage= or this draft, in the end, they will be other standards that clients need = to implement (3rd image of https://xkcd.com/927/)=A0 There are already a bunch of polyglot sync clients, https://crosscloud.me/=A0as an example. The problem with such client is that they have to deal with N different protocols. I thought the objective of this draft was to avoid such situation and let the cloud provider implement a common standard (the one we are seeking for). On Thu, Dec 3, 2015, at 10:52 AM, Michiel de Jong wrote: > I think we should not (try to) pick one protocol - > https://xkcd.com/927/ I think sync *clients* should be "protocol > polyglots" in the same way as > https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#Pro= tocol_support > > On Thu, Dec 3, 2015 at 10:44 AM, Fran=E7ois Kooman > wrote: >> On 12/03/2015 10:06 AM, fsong@bjtu.edu.cn wrote: >> > If we really want to discuss the Pros and Cons of WebDAV, can we >> > mark these three reasons as disadvantages of WebDAV? any support for >> > that? >> >> Personally, I do not think that is fair. >> >> > 1) it's a lot of work to implement this without using an existing >> > WebDAV library >> >> I do not see a problem in reusing an existing WebDAV library. >> This has >> the added benefit that you get a lot of functionality 'for free' and >> that existing test suites are available for testing compatibility. This >> is purely a practical argument! >> >> > 2) in practice, a lot of WebDAV servers get it wrong, >> > or don't implement all of WebDAV. It's very annoying for client >> > implementers to have to deal with servers that e.g. chose not to >> > implement LOCK and UNLOCK. >> >> The point is not to have a fully compliant (whatever that is exactly) >> WebDAV server. Either this ML (or remoteStorage specification) could >> determine a subset of WebDAV that would be required to be implemented. >> E.g. we exhaustively list the verbs that need to be implemented and >> their expected behavior. If we keep this a limited as possible and stay >> away from experimental features we have a high probability that most >> libraries will get it right! If we stay away from locking and ACLs the >> library situation looks a lot brighter :) >> >> > 3) we don't really need all these advanced >> > features on top of standard HTTP, just supporting GET/PUT/DELETE for >> > resources, and adding a simple folder description format, is enough >> > for most applications. >> >> Exactly! >> >> > For the target of our ISS group, whether the WebDAV can be reused is >> > critical. >> >> Well, my point is that there is little reason to reinvent the >> wheel if >> the only benefit is to use JSON instead of XML for folder listings. The >> amount of experience and available tooling for WebDAV is already huge! >> It would be a waste to throw this away just for liking JSON better. >> >> But maybe there are other reasons using (a limited set of) WebDAV is >> impossible or unwanted... >> >> Cheers, >> Fran=E7ois --_----------=_144913713941260553 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
If clients need to be polyglot, then I don't see the need for re= moteStorage or this draft, in the end, they will be other standards that cl= ients need to implement (3rd image of htt= ps://xkcd.com/927/) 
 
There are already a bunch of polyglot sync clients, https://crosscloud.me/ as an example.
The problem with such client is that they have to deal with N differen= t protocols.
 
I thought the objective of this draft was to avoid such situation and = let the cloud provider implement a common standard (the one we are seeking = for).
 
 
On Thu, Dec 3, 2015, at 10:52 AM, Michiel de Jong wrote:
I think we should not = (try to) pick one protocol - https://xkcd= .com/927/
I think sync *clients* should be "protocol polyglots" in the same way = as https://en.wikipedia.org/wiki/Comparison_of_inst= ant_messaging_clients#Protocol_support
 
On Thu, Dec 3, 2015 at 10:44 AM, Fran=E7ois Kooman <fkooman@tuxed.net> wrote:
On 12/03/2015 10:06 AM,= fsong@bjtu.edu.cn wrote:
> If we really want to discuss the Pros and Cons of WebDAV, can we
> mark these three reasons as disadvantages of WebDAV? any support for > that?

Personally, I do not think that is fair.

> 1) it's a lot of work to implement this without using an existing
> WebDAV library

I do not see a problem in reusing an exi= sting WebDAV library. This has
the added benefit that you get a lot of functionality 'for free' and
that existing test suites are available for testing compatibility. This
=
is purely a practical argument!

> 2) in practice, a lot of WebDAV servers get it wrong,
> or don't implement all of WebDAV. It's very annoying for client
> implementers to have to deal with servers that e.g. chose not to
> implement LOCK and UNLOCK.

The point is not to have a f= ully compliant (whatever that is exactly)
WebDAV server. Either this ML (or remoteStorage specification) could
determine a subset of WebDAV that would be required to be implemented.
<= /div>
E.g. we exhaustively list the verbs that need to be implemented and
their expected behavior. If we keep this a limited as possible and stay
=
away from experimental features we have a high probability that most
libraries will get it right! If we stay away from locking and ACLs the
<= /div>
library situation looks a lot brighter :)

> 3) we don't really need all these advanced
> features on top of standard HTTP, just supporting GET/PUT/DELETE for > resources, and adding a simple folder description format, is enough
> for most applications.

Exactly!

> For the target of our ISS group, whether the WebDAV can be reused is > critical.

Well, my point is that there is little reason= to reinvent the wheel if
the only benefit is to use JSON instead of XML for folder listings. The
=
amount of experience and available tooling for WebDAV is already huge!
<= /div>
It would be a waste to throw this away just for liking JSON better.
 
But maybe there are other reasons using (a limited set of) WebDAV is
impossible or unwanted...
 
Cheers,
Fran=E7ois
 
--_----------=_144913713941260553-- From nobody Thu Dec 3 02:09:55 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30831A6F81 for ; Thu, 3 Dec 2015 02:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFGWZXOfkLM1 for ; Thu, 3 Dec 2015 02:09:52 -0800 (PST) Received: from ursa.uberspace.de (ursa.uberspace.de [95.143.172.203]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCEF41A6EF4 for ; Thu, 3 Dec 2015 02:09:51 -0800 (PST) Received: (qmail 29056 invoked from network); 3 Dec 2015 10:09:50 -0000 Received: from localhost (HELO ?10.87.3.103?) (127.0.0.1) by ursa.uberspace.de with SMTP; 3 Dec 2015 10:09:50 -0000 To: Michiel de Jong References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> From: =?UTF-8?Q?Fran=c3=a7ois_Kooman?= X-Enigmail-Draft-Status: N1110 Message-ID: <566014EA.2010705@tuxed.net> Date: Thu, 3 Dec 2015 11:09:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: fsong@bjtu.edu.cn, Linhui Sun , storagesync , =?UTF-8?Q?Hugo_Gonz=c3=a1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 10:09:53 -0000 On 12/03/2015 10:52 AM, Michiel de Jong wrote: > I think we should not (try to) pick one protocol - https://xkcd.com/927/ Saying that after writing your own spec ;) > I think sync *clients* should be "protocol polyglots" in the same way as > https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#Protocol_support Because it worked so well for messaging clients? Yeah, I guess it works if you live in the year 2000 and don't care about file transfer, voice, video, offline messaging, receive notifications, sending pictures, group chats, sync between devices, usable encryption, stickers and the holy grail: federation. Is this not solved by Signal nowadays? In theory it is a great idea and I'd agree with you, but in practice not so much. KISS is key here. I'd recommend building on technology that is already there, working and proven and free! Cheers, François From nobody Thu Dec 3 02:52:25 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA221B337F for ; Thu, 3 Dec 2015 02:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0xm6n0pJ4wx for ; Thu, 3 Dec 2015 02:52:22 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CF41B337D for ; Thu, 3 Dec 2015 02:52:22 -0800 (PST) Received: by wmec201 with SMTP id c201so16581144wme.1 for ; Thu, 03 Dec 2015 02:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CAOtt/ccAu1UGltTYoWz9DDpYvkf+gJ2q9h2ualgQ00=; b=Lycn6Wov5/7lT+ZtDjL8YzTBCvlmj7JJyx0A33JQURtilXCqTTGAXV/XQ0qPSbnULH AAmdsb4q45yTsVxdiL4RXoPJmRORYD/h+5JSi/OMs5rHPjdt78jVZX8IpFKtuNFSzrfa p+eJ9NcF5EGUHAjQNpLsd2RJhtTZDDd1MUoZ4xsLdEfsQ80C+2Tr2xAmvJen1l0rx3OC Zs2/wqqTs99f4eET5W0f0l09+ep57KhaI5Zbi0YZkPVYMTeatTLoAoH3SgRktSLHJFy9 K7/xZgkB4P7H87kCwGZksG/CDOVbVG4zwMNJ/rYDcbCNa5D1GfAF2I+76Y1jkR5iXYEY Zd1g== X-Received: by 10.194.84.4 with SMTP id u4mr11817686wjy.149.1449139940732; Thu, 03 Dec 2015 02:52:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Thu, 3 Dec 2015 02:52:01 -0800 (PST) In-Reply-To: <566014EA.2010705@tuxed.net> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> From: Linhui Sun Date: Thu, 3 Dec 2015 18:52:01 +0800 Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Kooman?= Content-Type: multipart/alternative; boundary=047d7bb04d3665b48d0525fc2f29 Archived-At: Cc: fsong , storagesync , Michiel de Jong , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 10:52:23 -0000 --047d7bb04d3665b48d0525fc2f29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi 2015-12-03 18:09 GMT+08:00 Fran=C3=A7ois Kooman : > On 12/03/2015 10:52 AM, Michiel de Jong wrote: > > I think we should not (try to) pick one protocol - https://xkcd.com/927= / > > Saying that after writing your own spec ;) > > > I think sync *clients* should be "protocol polyglots" in the same way a= s > > > https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#Pro= tocol_support > > Because it worked so well for messaging clients? Yeah, I guess it works > if you live in the year 2000 and don't care about file transfer, voice, > video, offline messaging, receive notifications, sending pictures, group > chats, sync between devices, usable encryption, stickers and the holy > grail: federation. Is this not solved by Signal nowadays? > > In theory it is a great idea and I'd agree with you, but in practice not > so much. KISS is key here. I'd recommend building on technology that is > already there, working and proven and free! > Which technology are you talking about here? > > Cheers, > Fran=C3=A7ois > --047d7bb04d3665b48d0525fc2f29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

2015-12-03 18:09 GMT+08:00 Fran=C3=A7ois Kooman <= ;fkooman@tuxed.net>:
On 12/03/= 2015 10:52 AM, Michiel de Jong wrote:
> I think we should not (try to) pick one protocol - https://xkcd.com/927/

Saying that after writing your own spec ;)

> I think sync *clients* should be "protocol polyglots" in the= same way as
> https://e= n.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#Protocol_suppo= rt

Because it worked so well for messaging clients? Yeah, I guess it wo= rks
if you live in the year 2000 and don't care about file transfer, voice,=
video, offline messaging, receive notifications, sending pictures, group chats, sync between devices, usable encryption, stickers and the holy
grail: federation. Is this not solved by Signal nowadays?

In theory it is a great idea and I'd agree with you, but in practice no= t
so much. KISS is key here. I'd recommend building on technology that is=
already there, working and proven and free!
Which tech= nology are you talking about here?
=C2=A0

Cheers,
Fran=C3=A7ois

--047d7bb04d3665b48d0525fc2f29-- From nobody Thu Dec 3 02:53:21 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ED91B337D for ; Thu, 3 Dec 2015 02:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku0FElETStz9 for ; Thu, 3 Dec 2015 02:53:18 -0800 (PST) Received: from ursa.uberspace.de (ursa.uberspace.de [95.143.172.203]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78EF51B3377 for ; Thu, 3 Dec 2015 02:53:17 -0800 (PST) Received: (qmail 8478 invoked from network); 3 Dec 2015 10:53:15 -0000 Received: from localhost (HELO ?172.16.212.139?) (127.0.0.1) by ursa.uberspace.de with SMTP; 3 Dec 2015 10:53:15 -0000 To: Linhui Sun References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> From: =?UTF-8?Q?Fran=c3=a7ois_Kooman?= Message-ID: <56601F18.8030409@tuxed.net> Date: Thu, 3 Dec 2015 11:53:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: fsong , storagesync , Michiel de Jong , =?UTF-8?Q?Hugo_Gonz=c3=a1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 10:53:19 -0000 On 12/03/2015 11:52 AM, Linhui Sun wrote: > Which technology are you talking about here? WebDAV :) Cheers, François From nobody Thu Dec 3 03:01:12 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790EA1B3390 for ; Thu, 3 Dec 2015 03:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMt1ON5FI9qs for ; Thu, 3 Dec 2015 03:01:09 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523961B338D for ; Thu, 3 Dec 2015 03:01:09 -0800 (PST) Received: by wmww144 with SMTP id w144so16881994wmw.0 for ; Thu, 03 Dec 2015 03:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5PZqbRVAA8TIKL9UzoPT7hfI+xRJ7Rjqf40mxGsu9Ig=; b=Pp195CS8+EXyPPR5GRgNnYxB0L23Ld+uBXIdSaTna+/eg59s6/fbA1uelZ67osSs0J YNzc2rP4M6g+cEYHB1rYXxTsZSWmjoMoh8I0+iMlFZVuoKXR2TdzJCAWjWexRzZ3gPNh uUrWiNgQ+CtFpL3OzVosLSGi4SJFzcRbLPBiJwPREwZrFdxxcPEKqk0kC4ln3v8jmbwb D3W20trLrkrrIA/yoWoEHktGDMUqOEauGe+Jalfc/dlV4nIg5RX35vlAuh9UfbcQSZy2 IUoszdpb2Q1d9hEoy7WlL9TOgjFzQ0Ns3iklOxJXtoxKPlWwIV9dIaz2KZUlPAySVrUr GGdQ== X-Received: by 10.194.79.72 with SMTP id h8mr11331508wjx.136.1449140467913; Thu, 03 Dec 2015 03:01:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Thu, 3 Dec 2015 03:00:48 -0800 (PST) In-Reply-To: <56601F18.8030409@tuxed.net> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> From: Linhui Sun Date: Thu, 3 Dec 2015 19:00:48 +0800 Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Kooman?= Content-Type: multipart/alternative; boundary=047d7bb0499ed1ddb30525fc4edb Archived-At: Cc: fsong , storagesync , Michiel de Jong , =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 11:01:10 -0000 --047d7bb0499ed1ddb30525fc4edb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-12-03 18:53 GMT+08:00 Fran=C3=A7ois Kooman : > On 12/03/2015 11:52 AM, Linhui Sun wrote: > > Which technology are you talking about here? > > WebDAV :) > Ah, as I guessed : ) However I'd prefer HTTP rather than WebDAV. Since I still think WebDAV is not suitable for today's sync service. The frequency of operations is far higher than what WebDAV expects. For example, frequently sending propfind to detect changes is not a good way in my view. Regards, Linhui > > Cheers, > Fran=C3=A7ois > > --047d7bb0499ed1ddb30525fc4edb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-03 18:53 GMT+08:00 Fran=C3=A7ois Kooman <<= a href=3D"mailto:fkooman@tuxed.net" target=3D"_blank">fkooman@tuxed.net= >:
On 12/03/2015 11:52 AM= , Linhui Sun wrote:
> Which technology are you talking about here?

WebDAV :)
Ah, as I guessed : )
Howeve= r I'd prefer HTTP rather than WebDAV. Since I still think WebDAV is not= suitable for today's sync service. The frequency of operations is far = higher than what WebDAV expects. For example, frequently sending propfind t= o detect changes is not a good way in my view.

Reg= ards,
Linhui

Cheers,
Fran=C3=A7ois


--047d7bb0499ed1ddb30525fc4edb-- From nobody Thu Dec 3 03:07:04 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CD31B3399 for ; Thu, 3 Dec 2015 03:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuNDin6ZHWm3 for ; Thu, 3 Dec 2015 03:06:58 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD3D1B3397 for ; Thu, 3 Dec 2015 03:06:57 -0800 (PST) Received: by wmvv187 with SMTP id v187so21416622wmv.1 for ; Thu, 03 Dec 2015 03:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BfqU0mo08m7dIuqO8bR55v/4pzDLl3F0oVDFj1oEFEk=; b=vLwT6fOqhCtNgD6StHjVpBO3Q13ywY5Qk2UCFnUNgCPcWgVqUWov5BzojmB5IDQoZk GU0Kzcr5vTtzjvBSuhS1jdm5Z+gOwa0kXmMQqwVuIoaeVG6f/ey7QEqCANAphwAE0wJe X64/CWCE9d2QQaSlsKQwIGlE8AcBOebwVeAMeIajwm/t/ZIDCaoc+ZPLfvoP9WG1R+Tt xpZUDAPmaTa49zdRde2EMPaiFDVZwjfq6OkbW80sMfM7lCzYuPVly2/MZ+A0hS+2oAwz n23As88t53IRKRqM2ic7q+xIv5WdOXU9jYZgx+XCWSwcDw2rrUhnQeB97f6lvAA8wvcR gx9Q== X-Received: by 10.28.48.10 with SMTP id w10mr47754700wmw.39.1449140815981; Thu, 03 Dec 2015 03:06:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Thu, 3 Dec 2015 03:06:36 -0800 (PST) In-Reply-To: <1449136149.4121117.456781881.1C2D2EA8@webmail.messagingengine.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> <5ca31214.2c3d.151672efcf7.Coremail.fsong@bjtu.edu.cn> <1449136149.4121117.456781881.1C2D2EA8@webmail.messagingengine.com> From: Linhui Sun Date: Thu, 3 Dec 2015 19:06:36 +0800 Message-ID: To: =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Content-Type: multipart/alternative; boundary=001a11422fa890f2eb0525fc6385 Archived-At: Cc: fsong , storagesync , Michiel de Jong , fkooman Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 11:07:03 -0000 --001a11422fa890f2eb0525fc6385 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-12-03 17:49 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > What is the best way to collect the advantages and drawbacks of WebDAV vs > remoteStorage ? > > I propose to create a GitHub instead of/in addition to specify the > differences here. I think is clear to show this info in something like a > table on GitHub instead of in a series of mail messages. > That is a good way to discuss, but I think we should not saying the pros or cons, it's just about applicability here. A discussion about whether it is suitable to build on WebDAV is better. Regards, Linhui > > I can create the repo if it is okay for you. > > Best,Hugo > > > On Thu, Dec 3, 2015, at 10:31 AM, fsong@bjtu.edu.cn wrote: > > Great=EF=BC=81 > > > > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* "Michiel de Jong" > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2015=E5=B9=B412=E6=9C=883=E6=97= =A5 =E6=98=9F=E6=9C=9F=E5=9B=9B > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* fsong@bjtu.edu.cn > *=E6=8A=84=E9=80=81:* "Linhui Sun" , storagesync < > storagesync@ietf.org>, fkooman , "Hugo Gonz=C3=A1lez > Labrador" > *=E4=B8=BB=E9=A2=98:* Re: [Storagesync] Storagesync Digest, Vol 5, Issue = 1 > > Yes! I'll discuss with Francois how we can make these boundaries clearer. > Maybe we can split along these lines: > * upload/manipulate/query/download protocol (e.g. WebDAV or the > GET/PUT/DELETE operations we currently define) > * CORS or other cross-origin access mechanism, OAUTH or other auth > mechanism, WebFinger or other discovery mechanism, ETag or other versioni= ng > mechanism > * chunking/deduping/delta-updates > > And the remoteStorage spec should probably only define the middle part. > > > On Thu, Dec 3, 2015 at 9:44 AM, wrote: > > Hi Michiel and Linhui, > > I think it will be good to have a boundary for this draft and leave some > work for the applicaiton layer~ > > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* "Michiel de Jong" > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2015=E5=B9=B412=E6=9C=882=E6=97= =A5 =E6=98=9F=E6=9C=9F=E4=B8=89 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* "Linhui Sun" > *=E6=8A=84=E9=80=81:* storagesync , fkooman , > "Hugo Gonz=C3=A1lez Labrador" > *=E4=B8=BB=E9=A2=98:* Re: [Storagesync] Storagesync Digest, Vol 5, Issue = 1 > > Ah sure, that's entirely appropriate, remoteStorage treats both the > Content-Type header value and the actual body of a document as opaque > strings of bytes. It doesn't "care" if you use it to store only data bloc= ks > that are chunks of something else. > For instance, you could have a folder on a user's storage that contains > only inode-like JSON-documents, which list the URLs of binary documents > that make up 1Kb blocks of the actual data. Nice for deduping, delta > updates, and also renaming files without reuploading their content. > > But yeah, the argument is that *how* to create and manage these chunks, i= s > then still left up to the application developer (or to another spec on to= p > of the remoteStorage spec). > > > Cheers, > Michiel. > > On Wed, Dec 2, 2015 at 3:29 PM, Linhui Sun wrote: > > Hi > > 2015-12-02 22:05 GMT+08:00 Michiel de Jong : > > Cool! I created https://github.com/remotestorage/spec/issues/137 about > the need for MOVE verb. > Application-level chunking is partially supported by HTTP itself through > `Content-Range` headers (although it's not clear whether these are allowe= d > on PUT requests as well as on GET requests, see > https://github.com/remotestorage/spec/issues/131). The problem is that > HTTP defines versioning at the document level, you cannot ask a server to > produce or check an ETag for a specific byte-range of a document, only fo= r > the entire document. > > > Actually what I'm saying is a chunking before transmitting (using http), > in this way, they are treated as individual documents from the standpoint > of http. But I don't know whether this is appropriate for remoteStorage, > just a comment. > > Regards, > Linhui > > > A comparison document sounds good! See also > http://www.servicedenuages.fr/en/generic-storage-ecosystem. > > > Cheers, > Michiel. > > > On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun wrote: > > That's cool for me, a separate section for this might make sense. > > Another thing is do we need to include an application-layer chunking here > (not just for a browser sync), since if we want to further extend other > capabilities it is essential. > > Regards, > Linhui > > 2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > > I propose to come up with a list of advantages and disadvantages of using > WebDAV and compare them against a JSON/REST based approach, like > remoteStorage. > > Does it sound good ? > > > On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote: > > > > 2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > > > > > > On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote: > > Hi all! > Thanks for all your reactions to the remoteStorage Internet-Draft. > > We get the question about WebDAV a lot, in the next version we should add > a remark about it in the intro. The folder descriptions returned when you > GET a URL that ends with a / are indeed a deviation from the XML returned > by WebDAV server, and this is just because nowadays JSON is easier to use > than XML for developers, both client-side and server-side. > > > > I totally agree here, this was going to happen soon or later and it is > really appreciated. > > > > The fact that we don't require servers to support WebDAV's custom verbs > like PROPPATCH etc. is for three reasons: > 1) it's a lot of work to implement this without using an existing WebDAV > library > 2) in practice, a lot of WebDAV servers get it wrong, or don't implement > all of WebDAV. It's very annoying for client implementers to have to deal > with servers that e.g. chose not to implement LOCK and UNLOCK. > 3) we don't really need all these advanced features on top of standard > HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple > folder description format, is enough for most applications. > > Other than that, the remoteStorage Internet-Draft specifies a *lot* more > than just how each HTTP verb should behave: > * requiring support for OAuth implicit-grant flow > * requiring ETag support and nested versioning (i.e. the folder's ETag > changes if anything within that folder changes) > * requiring CORS headers > * requiring a WebFinger announcement for service discovery > It would be easy to add these three things on top of WebDAV, instead of > putting them on top of our minimal GET/PUT/DELETE API definition. In fact= , > we could probably separate it into two Internet-Drafts: one for the > 'RESTful folders' API which is our simplification of WebDAV, and a second > one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful > folders' or whatever other HTTP-based API you want. > > > > There is one requirement that all synchronisers need to handle: moving > resources. In this spec the alternative of a WebDAV MOVE is not specified= . > > It is true that a MOVE could be replaced with a DELETE + UPLOAD but that > is not acceptable in most cases due to the inefficiency of such operation > (cpu, bandwidth consumption ...) > > Is there a plan to support such basic feature? > > From the current remoteStorage spec, the ownCloud sync protocol can be > implemented. The missing bit is tracking those remote moves. > > I agree with Hugo that MOVE is useful, sometimes if you just rename a fil= e > it will be perfect. But the question I have is that whether we need to ma= ke > two documents? Multiple choices is not good for standardization. In my > view, webdav is something that we need to have a very clear decision on > whether to consider it or not. > > Regards, > Linhui > > > > Cheers > > > On Wed, Dec 2, 2015 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador < > ietf@hugo.labkode.com> wrote: > > > > > > > On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote: > > Hi > > On =E5=91=A8=E4=B8=89, 12=E6=9C=88 2, 2015 at 17:56, Hugo Gonz=C3=A1lez L= abrador > wrote: > > > > > On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote: > > Hi > > 2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > Hi, > > from my point of view the remoteStorage project addresses a subset of > the use cases of the WebDAV specification. > > The main difference I can observe is that the specification is built on > REST instead of XML-based communication. > > > I personally like much more REST than WebDAV because it is more > developer friendly and it is faster to develop. > Maybe the remoteStorage API becomes the next WebDAV :) > > However, the remoteStorage API does not provide a way of synchronising > data, this task is delegated to the developers. > Is there a plan to provide such feature based on the outcome of this > draft? > > I'm a little bit confused why you say the remoteStorage does not provide > that. Is that because remoteStorage does not perform like a typical sync > services (e.g. dropbox...) or you are saying something else? > > Yes, because it does not offer synchronisation capabilities. > > Got it. And What I am wondering is that do we need to include those > capabilities in a base specifications. Since it is hard to standardize th= e > capabilities like dedup or delta. Maybe a better way is to define those i= n > a separate specification, > > > > > Thanks for giving these examples - so by 'synchronisation capabilities' > you mean 1) deduplication and 2) delta updates? Anything else or is that = an > exhaustive list? > > > > something like extensions. For a base document, we just need to define ho= w > to perform sync operations. > > > > Yes, I agree that may be an extension of this draft could handle the > synchronisation part. > > > > > > Our Internet-Draft is heavily focused on the world wide web, whose URLs > are not content-addressable, we can't change that. So that architecture i= s > not very friendly to deduplication, compared to for instance BitTorrent. = As > you already said, developers can still dedupe on the server-side when > storing blobs to disk, and can also dedupe on the client side before > creating the resources the client uploads. > As far as I know, delta updates are not supported by the ETag system - yo= u > cannot do a range request to find out if certain bytes within a document > have changed. However, the folder system we define does encourage you, fo= r > instance when you develop a To Do List app, put each task on its own > document, and then query the folder to see which of them changed, instead > of putting them all in one big document and retrieving the whole document > each time. > > Cheers, > Michiel. > > > > > > > > BTW, I want to introduce ClawIO ( > http://clawio.github.io), a research > project to benchmark different synchronisation protocols against > different data backends with special attention to provide a common sync > API. > > A common API for different sync protocols is being created based on the > architecture specified in this draft (control and data servers) and the > > I cannot find a distributed architecture in this draft. It seems that the= y > handle metadata and content data together, just like a normal web service= . > > > ClawIO is fully distributed. Every logical unit is a different server tha= n > be scaled out. Data and Metadata channels are independent from each other > and reside on different servers. > > That is widely employed in popular sync services. And that is also > beneficial to privacy to some extent. But in the context of sync in brows= er > (which is mainly considered in the remoteStorage), I don't know whether > this is reasonable. But I think we should deploy distributed architecture > although it will make things complicated. > > > > Of course, the remoteStorage is targeted to browsers, so syncing does not > make too much sense in this case. > With the rise of Linux container micro-service based architectures, the > deployment of such highly complex systems should become easier and faste= r. > > Best, > > > Hugo > > > > Regards, > Linhui > > > > > Regards, > Linhui > > one from the CERN EOS project (management, disk and queue servers). > > The Phase I has implemented the ownCloud Sync Protocol and Phase II will > implement the SeaFile Sync Protocol. > The choice of these protocols among others is because they are really > opposed to each other in terms of syncing (delta vs non-delta, > state-based vs log/event/git-based sync =E2=80=A6), so finding a common a= pproach > is more challenging. > > Providing a base specification/architecture to measure the feasibility > of this draft is one of the objectives of the project. > > I believe that the work being done here and in ClawIO are supplementary > to each other and I think mutual collaboration could be beneficial for > both sides. > > Also, if there is interest, the remoteStorage API can be added to > ClawIO. > > Best regards, > > Hugo Gonzalez Labrador > > On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote: > > Send Storagesync mailing list submissions to > > storagesync@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/storagesync > > or, via email, send a message with subject or body 'help' to > > storagesync-request@ietf.org > > > > You can reach the person managing the list at > > storagesync-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Storagesync digest..." > > Today's Topics: > > > > 1. New version of draft-dejong-remotestorage Internet-Draft > > available (Michiel de Jong) > > 2. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Gihan Dias) > > 3. Re: New version of draft-dejong-remotestorage Internet-Draft > > available (Fei Song) > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > Email had 3 attachments: > > + [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 1k (message/rfc822) > > + Re: [Storagesync] New version of draft-dejong-remotestorage > > Internet-Draft available > > 2k (message/rfc822) > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > > > > > > > > > > > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > > --001a11422fa890f2eb0525fc6385 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-03 17:49 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.= labkode.com>:
What is the best way to collect the advantages and drawbacks of W= ebDAV vs remoteStorage ?
=C2=A0
I propose to create a GitHub instead of/in addition to specify the dif= ferences here. I think is clear to show this info in something like a table= on GitHub instead of in a series of mail messages.
That is a good way to discuss, but I think we should not saying t= he pros or cons, it's just about applicability here. A discussion about= whether it is suitable to build on WebDAV is better.

<= div>Regards,
Linhui
=C2=A0
I can create the repo if it is okay for you.
=C2=A0
Best,Hugo
=C2=A0
=C2=A0
On Thu, Dec 3, 2015, at 10:31 AM, fsong@bjtu.edu.cn wrote:
Great=EF=BC=81
=C2=A0
=C2=A0
-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----= -
=E5=8F=91=E4=BB=B6=E4=BA=BA: "Michiel de Jong" <mbdejong@mozilla.co= m>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B412=E6=9C=883= =E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B
=E6=94=B6=E4=BB=B6=E4=BA=BA: fsong@bjtu.edu.cn
=E6=8A=84=E9=80=81: "Linhui Sun" <lh.sunlinh@gmail.com>, sto= ragesync <stor= agesync@ietf.org>, fkooman <fkooman@tuxed.net>, "Hugo Gonz=C3=A1lez Labra= dor" <ie= tf@hugo.labkode.com>
=E4=B8=BB=E9=A2=98: Re: [Storagesync] Storagesync Digest, Vol 5= , Issue 1
=C2=A0
Yes! I'll discuss with Franco= is how we can make these boundaries clearer. Maybe we can split along these= lines:
* upload/manipulate/query/download protocol (e.g. WebDAV or the GET/PU= T/DELETE operations we currently define)
* CORS or other cross-origin access mechanism, OAUTH or other auth mec= hanism, WebFinger or other discovery mechanism, ETag or other versioning me= chanism
* chunking/deduping/delta-updates
=C2=A0
And the remoteStorage spec should probably only define the middle part= .
=C2=A0
=C2=A0
On Thu, Dec 3, 2015 at 9:44 AM, <fsong@bjtu.edu.cn> wrote:

Hi Michiel and Linhui,

<= /p>

I think it will be good to have a boundary for this draft and leave= some work for the applicaiton layer~

-----=E5=8E=9F=E5=A7=8B=E9=82=AE= =E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: "Michiel de Jong= " <mbdejo= ng@mozilla.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015= =E5=B9=B412=E6=9C=882=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89
=E6=94=B6= =E4=BB=B6=E4=BA=BA: "Linhui Sun" <lh.sunlinh@gmail.com>
=E6=8A= =84=E9=80=81: storagesync <storagesync@ietf.org>, fkooman <fkooman@tuxed.net>, "Hug= o Gonz=C3=A1lez Labrador" <ietf@hugo.labkode.com>
=E4=B8=BB=E9=A2=98:<= /b> Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1
Ah sure, that's entirely= appropriate, remoteStorage treats both the Content-Type header value and t= he actual body of a document as opaque strings of bytes. It doesn't &qu= ot;care" if you use it to store only data blocks that are chunks of so= mething else.
For instance, you could have a folder on a user's storage that con= tains only inode-like JSON-documents, which list the URLs of binary documen= ts that make up 1Kb blocks of the actual data. Nice for deduping, delta upd= ates, and also renaming files without reuploading their content.
=C2=A0
But yeah, the argument is that *how* to create and manage these chunks= , is then still left up to the application developer (or to another spec on= top of the remoteStorage spec).
=C2=A0
=C2=A0
Cheers,
Michiel.
=C2=A0
On Wed, Dec 2, 2015 at 3:29 PM, Linhui Sun <= lh.sunlinh@gmail.= com> wrote:
Hi
=C2=A0
2015-12-02 22:05 GMT+08:00 Michiel de Jong <mbdejong@mo= zilla.com>:
=C2=A0
Actually what I'm saying is a chunking before transmitting (using = http), in this way, they are treated as individual documents from the stand= point of http. But I don't know whether this is appropriate for remoteS= torage, just a comment.
=C2=A0
Regards,
Linhui
=
=C2=A0
A comparison document sounds good! See also http://www.s= ervicedenuages.fr/en/generic-storage-ecosystem.
=C2=A0
=C2=A0
Cheers,
Michiel.
=C2=A0
=C2=A0
On Wed, Dec 2, 2015 at 2:32 PM, Linhui Sun <= lh.sunlinh@gmail.= com> wrote:
That's cool= for me, a separate section for this might make sense.
=C2=A0
Another thing is do we need to include an application-layer chunk= ing here (not just for a browser sync), since if we want to further extend = other capabilities it is essential.
=C2=A0
Regards,
Linhui
=C2=A0
2015-12-02 21:03 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:

I propose to come up with a list of advantages and disadvantages = of using WebDAV and compare them against a JSON/REST based approach, like r= emoteStorage.
=C2=A0
Does it sound good ?
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:59 PM, Linhui Sun wrote:
=C2=A0
=C2=A0
2015-12-02 20:43 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <iet= f@hugo.labkode.com>:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 01:30 PM, Michiel de Jong wrote:<= br>
Hi all!
Thanks for all your reactions to the remoteStorage Internet-Draf= t.
=C2=A0
We get the question about WebDAV a lot, in the next version we s= hould add a remark about it in the intro. The folder descriptions returned = when you GET a URL that ends with a / are indeed a deviation from the XML r= eturned by WebDAV server, and this is just because nowadays JSON is easier = to use than XML for developers, both client-side and server-side.
=C2=A0
=C2=A0
I totally agree here, this was going to happen soon or later and it is= really appreciated.
=C2=A0
=C2=A0
The fact that we don't require servers to suppo= rt WebDAV's custom verbs like PROPPATCH etc. is for three reasons:
1) it's a lot of work to implement this without using an exi= sting WebDAV library
2) in practice, a lot of WebDAV servers get it wrong, or don'= ;t implement all of WebDAV. It's very annoying for client implementers = to have to deal with servers that e.g. chose not to implement LOCK and UNLO= CK.
3) we don't really need all these advanced features on top o= f standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a= simple folder description format, is enough for most applications.<= br>
=C2=A0
Other than that, the remoteStorage Internet-Draft specifies a *l= ot* more than just how each HTTP verb should behave:
* requiring support for OAuth implicit-grant flow
* requiring ETag support and nested versioning (i.e. the folder&= #39;s ETag changes if anything within that folder changes)
* requiring CORS headers
* requiring a WebFinger announcement for service discovery
It would be easy to add these three things on top of WebDAV, ins= tead of putting them on top of our minimal GET/PUT/DELETE API definition. I= n fact, we could probably separate it into two Internet-Drafts: one for the= 'RESTful folders' API which is our simplification of WebDAV, and a= second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or '= RESTful folders' or whatever other HTTP-based API you want.
<= /div>
=C2=A0
=C2=A0
There is one requirement that all synchronisers need to handle: moving= resources. In this spec the alternative of a WebDAV MOVE is not specified.= =C2=A0
=C2=A0
It is true that a MOVE could be replaced with a DELETE + UPLOAD but th= at is not acceptable in most cases due to the inefficiency of such operatio= n (cpu, bandwidth consumption ...)
=C2=A0
Is there a plan to support such basic feature?
=C2=A0
From the current remoteStorage spec, the ownCloud sync protocol can be= implemented. The missing bit is tracking those remote moves.
I agree with Hugo that MOVE is useful, sometimes if you j= ust rename a file it will be perfect. But the question I have is that wheth= er we need to make two documents? Multiple choices is not good for standard= ization. In my view, webdav is something that we need to have a very clear = decision on whether to consider it or not.
=C2=A0
Regards,
Linhui
=C2=A0
=C2=A0
Cheers
=C2=A0
On Wed, Dec 2, 20= 15 at 11:28 AM, Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com> wrote:

=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
Hi
=C2=A0
=C2=A0
=C2=A0
=C2=A0
On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
Hi
=C2=A0
2015-12-02 5:14 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.labkode.com>:
Hi,
=C2=A0
from my point of view the remoteStorage project addresses a subs= et of
the use cases of the=C2=A0 WebDAV specification.
=C2=A0
The main difference I can observe is that the specification is b= uilt on
REST instead of XML-based communication.
=C2=A0
I personally like much more REST than WebDAV because it is more<= /span>
developer friendly and it is faster to develop.
=C2=A0Maybe the remoteStorage API becomes the next WebDAV :)
=C2=A0
However, the remoteStorage API does not provide a way of synchro= nising
data, this task is delegated to the developers.
Is there a plan to provide such feature based on the outcome of = this
draft?
I'm a little bit confused why you say the remot= eStorage does not provide that. Is that because remoteStorage does not perf= orm like a typical sync services (e.g. dropbox...) or you are saying someth= ing else?
Yes, because it does not offer synchronisation capa= bilities.
Got it. And What I am wondering is that do we need = to include those capabilities in a base specifications. Since it is hard to= standardize the capabilities like dedup or delta. Maybe a better way is to= define those in a separate specification,
=C2=A0
=C2=A0
Thanks for giving these examples - so by 'synchronisation capabili= ties' you mean 1) deduplication and 2) delta updates? Anything else or = is that an exhaustive list?
=C2=A0
something like extens= ions. For a base document, we just need to define how to perform sync opera= tions.
=C2=A0
=C2=A0
Yes, I agree that may be an extension of this draft could handle the s= ynchronisation part.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Our Internet-Draft is heavily focused on the world wide web, whos= e URLs are not content-addressable, we can't change that. So that archi= tecture is not very friendly to deduplication, compared to for instance Bit= Torrent. As you already said, developers can still dedupe on the server-sid= e when storing blobs to disk, and can also dedupe on the client side before= creating the resources the client uploads.
As far as I know, delta updates are not supported by the ETag sys= tem - you cannot do a range request to find out if certain bytes within a d= ocument have changed. However, the folder system we define does encourage y= ou, for instance when you develop a To Do List app, put each task on its ow= n document, and then query the folder to see which of them changed, instead= of putting them all in one big document and retrieving the whole document = each time.
=C2=A0
Cheers,
Michiel.
=C2=A0
=C2=A0
=C2=A0
=C2=A0
BTW, I want to introduce ClawIO (http://clawio.github.io), a research
project to benchmark different synchronisation protocols against=
different data backends with special attention to provide a comm= on sync
API.
=C2=A0
A common API for different sync protocols is being created based= on the
architecture specified in this draft (control and data servers) = and the
I cannot find a distributed architecture in this dr= aft. It seems that they handle metadata and content data together, just lik= e a normal web service.
=C2=A0
ClawIO is fully distributed. Every logical unit is a different s= erver than be scaled out. Data and Metadata channels are independent from e= ach other and reside on different servers.
That is widely employed in popular sync services. A= nd that is also beneficial to privacy to some extent. But in the context of= sync in browser (which is mainly considered in the remoteStorage), I don&#= 39;t know whether this is reasonable. But I think we should deploy distribu= ted architecture although it will make things complicated.
=C2=A0
=C2=A0
Of course, the remoteStorage is targeted to browsers, so syncing does = not make too much sense in this case.
With the rise of Linux container micro-service based architectures, th= e deployment of =C2=A0such highly complex systems should become easier and = faster.
=C2=A0
Best,
=C2=A0
=C2=A0
Hugo
=C2=A0
=C2=A0
Regards,
Linhui=C2=A0
=C2=A0
=C2=A0
Regards,
Linhui
one from the CERN EOS project (m= anagement, disk and queue servers).
=C2=A0
The Phase I has implemented the ownCloud Sync Protocol and Phase II wi= ll
implement the SeaFile Sync Protocol.
The choice of these protocols among others is because they are really<= br>
opposed to each other in terms of syncing (delta vs non-delta,
state-based vs log/event/git-based sync =E2=80=A6), so finding a commo= n approach
is more challenging.
=C2=A0
Providing a base specification/architecture to measure the feasibility=
of this draft is one of the objectives of the project.
=C2=A0
I believe that the work being done here and in ClawIO are supplementar= y
to each other and I think mutual collaboration could be beneficial for=
both sides.
=C2=A0
Also, if there is interest, the remoteStorage API can be added to
<= /div>
ClawIO.
=C2=A0
Best regards,
=C2=A0
Hugo Gonzalez Labrador
=C2=A0
On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org wrote:
> Send Storagesync mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help'= to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0storagesync-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specif= ic
> than "Re: Contents of Storagesync digest..."
> Today's Topics:
>
>=C2=A0 =C2=A0 1. New version of draft-dejong-remotestorage=C2=A0 = =C2=A0 Internet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Michiel de Jong)
>=C2=A0 =C2=A0 2. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Gihan Dias)
>=C2=A0 =C2=A0 3. Re: New version of draft-dejong-remotestorage Int= ernet-Draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0available (Fei Song)
> _______________________________________________
> Storagesync mailing list
> Email had 3 attachments:
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
_______________________________________________
Storagesync mailing list
=C2=A0

--001a11422fa890f2eb0525fc6385-- From nobody Thu Dec 3 04:17:04 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9C11B3468 for ; Thu, 3 Dec 2015 04:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDezzVJaiOdt for ; Thu, 3 Dec 2015 04:17:01 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AA01B3464 for ; Thu, 3 Dec 2015 04:17:00 -0800 (PST) Received: (qmail 24885 invoked from network); 3 Dec 2015 12:16:55 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 3 Dec 2015 12:16:55 -0000 Date: Thu, 3 Dec 2015 13:16:48 +0100 From: Markus Unterwaditzer To: =?iso-8859-1?Q?Fran=E7ois?= Kooman Message-ID: <20151203121648.GA19890@chromebot.fritz.box> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56600F0A.9000200@tuxed.net> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 12:17:03 -0000 On Thu, Dec 03, 2015 at 10:44:42AM +0100, François Kooman wrote: > On 12/03/2015 10:06 AM, fsong@bjtu.edu.cn wrote: > > If we really want to discuss the Pros and Cons of WebDAV, can we > > mark these three reasons as disadvantages of WebDAV? any support for > > that? > > Personally, I do not think that is fair. > > > 1) it's a lot of work to implement this without using an existing > > WebDAV library > > I do not see a problem in reusing an existing WebDAV library. This has > the added benefit that you get a lot of functionality 'for free' and > that existing test suites are available for testing compatibility. This > is purely a practical argument! > > > 2) in practice, a lot of WebDAV servers get it wrong, > > or don't implement all of WebDAV. It's very annoying for client > > implementers to have to deal with servers that e.g. chose not to > > implement LOCK and UNLOCK. > > The point is not to have a fully compliant (whatever that is exactly) > WebDAV server. Either this ML (or remoteStorage specification) could > determine a subset of WebDAV that would be required to be implemented. > E.g. we exhaustively list the verbs that need to be implemented and > their expected behavior. If we keep this a limited as possible and stay > away from experimental features we have a high probability that most > libraries will get it right! If we stay away from locking and ACLs the > library situation looks a lot brighter :) WebDAV's syntax is excessively verbose to allow non-standard properties on files and folders, non-standard querying methods for `calendar-multiget`, PROPFIND and friends, and etc. The whole point of XML is extensibility at the cost of verbosity. If you take that away from your newly defined subset of WebDAV, what is left? A new protocol which - requires extra requests for creating and deleting folders (while there's nothing left that would speak against implicitly creating those). Sure you have GET, PUT, DELETE for documents - has excessively verbose syntax for listing folders, but without the advanced filtering capabilities. - is not backwards-compatible with most client implementations and therefore has to be rebranded as a new protocol so users don't try to plug a "full" WebDAV client into a server that only implements your subset Especially that last one. If you're going to slice off 90% of WebDAV's features, you might as well define a new, clean protocol. > > > 3) we don't really need all these advanced > > features on top of standard HTTP, just supporting GET/PUT/DELETE for > > resources, and adding a simple folder description format, is enough > > for most applications. > > Exactly! > > > For the target of our ISS group, whether the WebDAV can be reused is > > critical. > > Well, my point is that there is little reason to reinvent the wheel if > the only benefit is to use JSON instead of XML for folder listings. The > amount of experience and available tooling for WebDAV is already huge! > It would be a waste to throw this away just for liking JSON better. > > But maybe there are other reasons using (a limited set of) WebDAV is > impossible or unwanted... > > Cheers, > François > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Thu Dec 3 06:38:12 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E2B1A891F for ; Thu, 3 Dec 2015 06:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frD3-3zYhC6n for ; Thu, 3 Dec 2015 06:38:09 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9C41A8907 for ; Thu, 3 Dec 2015 06:38:08 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14491534856070.5080998982302845" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> Date: Thu, 03 Dec 2015 14:38:05 +0000 Message-Id: <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 14:38:10 -0000 ------sinikael-?=_1-14491534856070.5080998982302845 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 6:00 AM Linhui Sun wrote: > However I'd prefer HTTP rather than WebDAV. Since I still think WebDAV = is > not suitable for today's sync service. The frequency of operations is = far > higher than what WebDAV expects. For example, frequently sending = propfind > to detect changes is not a good way in my view. WebDAV is HTTP. However, your point about propfind is correct--that = doesn't scale. What you want is a separate layer for dealing with = synchronization of metadata. You could use HTTP transport to do this, but= not propfind. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14491534856070.5080998982302845 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYFPOCRAMw8Nu0HeKywAA+28IANJGtLNzlWATshaePwPj AqIdWQcfFg3jHK+5oYSd73j2zp6mKe+qPfLzaAbrzMC/ape8l+1pLVLQ4mnk P3kn/PGMEV41NRkphE8ZDsoF1U1EfX9I8NvZZfHZHW50noa+PgBClFS9pbT8 6wvBHpTW+OtEbDcT/XkEkcdQ91ARHt+bGHa8G9uzlMDWgJYQ4HT/2L7qz6qG mw9u1PCLP1C1BdRvFJ1GSiFpCeu6nxppnJcDM6odSI04Y8LKzMKbQZPtV4IH 8PbYBdoJz46TnJL/FGF1hCMHyKpxGqdv22snQqXDw8t326/t4Sd4HJdUbVzn TMmcxAC7uxvABffkMI8uLas= =G3FR -----END PGP SIGNATURE----- ------sinikael-?=_1-14491534856070.5080998982302845-- From nobody Thu Dec 3 10:42:18 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D681B3540 for ; Thu, 3 Dec 2015 10:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXFPKx9pVdBy for ; Thu, 3 Dec 2015 10:42:14 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0674.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::674]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1091B353E for ; Thu, 3 Dec 2015 10:42:13 -0800 (PST) Received: from VI1PR06CA0077.eurprd06.prod.outlook.com (10.163.160.45) by AMSPR06MB405.eurprd06.prod.outlook.com (10.242.22.15) with Microsoft SMTP Server (TLS) id 15.1.337.19; Thu, 3 Dec 2015 18:41:51 +0000 Received: from DB3FFO11FD048.protection.gbl (2a01:111:f400:7e04::143) by VI1PR06CA0077.outlook.office365.com (2a01:111:e400:533c::45) with Microsoft SMTP Server (TLS) id 15.1.337.19 via Frontend Transport; Thu, 3 Dec 2015 18:41:51 +0000 Authentication-Results: spf=pass (sender IP is 188.184.36.48) smtp.mailfrom=cern.ch; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=cern.ch; Received-SPF: Pass (protection.outlook.com: domain of cern.ch designates 188.184.36.48 as permitted sender) receiver=protection.outlook.com; client-ip=188.184.36.48; helo=CERNMX12.cern.ch; Received: from CERNMX12.cern.ch (188.184.36.48) by DB3FFO11FD048.mail.protection.outlook.com (10.47.217.79) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Thu, 3 Dec 2015 18:41:50 +0000 Received: from cernfe04.cern.ch (188.184.36.41) by cernmxgwlb4.cern.ch (188.184.36.48) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Dec 2015 19:41:38 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE04.cern.ch ([fe80::f81a:af99:b5b1:d9ee%11]) with mapi id 14.03.0174.001; Thu, 3 Dec 2015 19:41:38 +0100 From: Jakub Moscicki To: Ted Lemon Thread-Topic: [Storagesync] Storagesync Digest, Vol 5, Issue 1 Thread-Index: AQHRLH0+7gCKX1UFx02QDZgdWy/v7563OhsAgAArgwCAAAZPgIAAAsoAgAAiFACAAVlOAIAACqEAgAACRoCAAAS6AIAAC86AgAAAVQCAAAIgAIAAPLWAgABECgA= Date: Thu, 3 Dec 2015 18:41:37 +0000 Message-ID: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> In-Reply-To: <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [177.21.120.179] Content-Type: text/plain; charset="utf-8" Content-ID: <16FE947411B4D64A98F1F5F4B37422E2@cern.ch> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD048; 1:UgT6obRNYlMcOZTzyP3a9ne/3XyN1pTmcnx0dew4GXHrFcxTo3VhsiTRYwx8Oyll5aSSySgGNEwCiJqygPWE3OuU6Zw8pIwW5vVDzWax36Wrx7vUBrnUgomQxAvNWkP9TG8OLw7WsNmAg3b0tzQJy+s5/8sMMTE312wYwtLZQaoulxnM+QxJaa1bzR6Jaxl+xWD79ySbk+jtkDPYw1eNuQ6c2STUFIhx8Vlv+9RaG00MKEHrdJyFZKkupgCTPwOcFMKDlBjaeCzy8hCpCMH3jeH1fXnOMBlkRiIU2rr3f1weCBoi/yA3KSSTCJL62YqJIn1fIrD4y7DeOLzSHNazF0/1pFBU/GvFpddKZjdcCZBiex/m4Nmij+USmuS+39ojvw11cOU6cGu1gfV6/4SYz7bt5ADx5bnZ6HbAcPmHAT0= X-Forefront-Antispam-Report: CIP:188.184.36.48; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(10533003)(24454002)(18543002)(377454003)(5403001)(189002)(199003)(19580395003)(19580405001)(1220700001)(189998001)(53416004)(1096002)(11100500001)(74482002)(106116001)(93886004)(5004730100002)(6116002)(3846002)(102836003)(5008740100001)(50466002)(86362001)(26826002)(586003)(82746002)(6806005)(5003600100002)(106466001)(66066001)(47776003)(15975445007)(83716003)(2900100001)(76176999)(92566002)(87936001)(5250100002)(33656002)(23676002)(50986999)(54356999)(2950100001)(36756003)(16796002)(5001970100001)(110136002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR06MB405; H:CERNMX12.cern.ch; FPR:; SPF:Pass; PTR:cernmx12.cern.ch; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB405; 2:NwUnjrPFpo9Ba2QJct6VZFlG/PsHM6KCBOrCXpDBuQVOTMcUg0UHI/JVd/2j/F9SRDgFPyX4flX3CxA/dIcPCZA4TLINoVgwEm6bovTxb73SdViHc4WleZ68ilpPnKI1gYjtnBpEeIY0aitpu+MQAA==; 3:0zfkuGE6FmoAM0hnDKEa2RYYqljfoPsNgrWqyLONvCy9uWn9BLgdrYeKA0qqJHNwVGlT1Ee8wQ6/AT7mJH+DDMxz7au/uvoH2U2H8xHDCAh2khwiH0TvIGjNtrDTRa2aEeDiTTa/Zi9/g6Dh3uUVL2nruv3pYfwf+tdm1216KT172N5QktgwZ/sjMgeD8RxyruaBeSkf4Kis3mYItXxi+I/jtNGFUtAQJ4bJYqZc8fUXDfdQ0DNn7ahzWfZR6Jg6AR18D3aHs0FN12NJrbc6Vg==; 25:PHUwseBSgPOafYoYO5ZfBLwnIT5cLvr9sNHdIkkH7a3tBoBUDFkC6MivyNdB88nhmArVvBsgQOqONhBEw2KsthiBmPOwRgqNZ4XLc0KyQ3aPDoD0ccYQW+eLfCP36/wnW7x7G2FQeWO0VdNlO8dv8pHY9Jp6WIuGnYtjiZ310VqWK+8svNATCpzmteGMV7WZz9APMFPViU5VgfRcR/7JCMitQerHCbZ8DM4yzQFWx+/5HJvVzK6OBQJguxw03At8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AMSPR06MB405; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB405; 20:aU7SvcVj6xvUN9BqOJYe7NnmsqHHF5y0deML/XqvXYkFkLM3TK/5ogvR4Tb9ax7zcrz2zwWMUXT2yzrWWkHxf9tsjRihnl+/ZwjPWM48TYqsdLFNlaYf7ZqvPpT7qwJFzjgajvMXlk+xnuDCTPjNU5PH+g3bWLArB+py7FNNpgM/C/XWEtFlKqk5Ylh0Fxa8KuGkPoa0K8V/5RyL2ckpql5w9haGQk35f56G/yxc5eU4fldMbKU1jsgml/nwPKqIB4AtRofwx5zvSoht8MCC11dGGa6icwX7ue4aG+UopFMtN6SP2nzk0ES3toISY5VohFDWmQeQtAa1lN0KSsxIUIYRG2fi06MfueZZRLZfRpvbnNOrNGMGm+IhmJS7+ZXjh1J5N9dl9OwIFO6R4jyWM2R62+yLOLFiBVe/eiRLkti+ojid+rWlprgsXyl/a1XG2erEtEbpPLdBhqRpR1Qvq+jwlt+j2Rm5hb338S6A09lB1+yC3rzipm+2nZXyI1P/; 4:wJSmNZMAYFDD9f986si0uOst4ABt8/wT15GHx7zWdDZhIq/5CFVBdPtq31zFEuaqZqtYv8NVvXOFYqAq8+1lI4Po/W4ejgzWhJ3ExrkI5aLEc8zFs1luBMgIr0MhkNjpSXKz1Z72IKKr6yhZHgtGj6nZ6iLdOvKfJqLU9Tocn2/JvYv77ZlERUB81h8Wng9qYlLZT2cTNdoElQFLNQOSLrxUS564/W3mGghwM0223UUVo+QyVYCWN3UaiMnx/CstDTEYAnvuP+VdzfIMr8xAFqElaSDc7dEdN4HfVa6S57F4Joxomx4Ku/n2TMB4PIuk/nPkfJrckI3L6+b/mIsZRh7UEdtl/PqZx9/pq+0OrOaiGHfMZR5q5QC8dGvMCcR+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR06MB405; BCL:0; PCL:0; RULEID:; SRVR:AMSPR06MB405; X-Forefront-PRVS: 077929D941 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVNQUjA2TUI0MDU7MjM6dFA3d1YwWXgyL01IaDh5dU5OU3RJWGViaGM3?= =?utf-8?B?VExoelJucjBLTm9QTVJERHY1ZFBnRlpxTjBMRGE0Qy9UVUJ4VVozL2l6bzRl?= =?utf-8?B?a3o0ZFpPb0lueTRlenV6K3NOYnd2amFQWU1xREsxYUtUNnM3clJrUUFuY2Rj?= =?utf-8?B?M0d2RGRHTEM0VEVDSkZ5Yis5QkFRMWNRV0dVdWtCQjVGdFdMZW5mc0wwWWxS?= =?utf-8?B?ZGdqQmY1L2FocVlqb1plV3htSCtRaVhqdzZOazkvOWV2Q01od1Zsb1JkQ0lJ?= =?utf-8?B?TEE3dUlwVDFGR2dHeTNBUXk3dC9lRUhWWjNMb2hoWEo4UVhDWHVKck9UVHk0?= =?utf-8?B?Umh0UFFkN3dTVG9wTkRUNmY4Wm1EcHZGTEdPYUNMSVlsMGdVNnV1M3l6Uk16?= =?utf-8?B?N2sxR1hrMTRTS24yVTBlNUdqQzAwRlEyQlNCcEpaNVVqZS9qZU5nU0o0V1px?= =?utf-8?B?WUJiYWMrTXVqd3ZNc202NDFKY1phWTlReGM4ekV5bWxiNmcrSmZUNmdnMjBk?= =?utf-8?B?Yi9LYUZZR2hBd1M2dTdPN1pJSkJpS1RSYUFLOG54WHR1QVJOcDRsOFhqd0NL?= =?utf-8?B?K3BBb095aGtJaWQzOS9CSFhLN29sL0UwOHBEbE1zdGhwOFZ0cUZQejRNcWNj?= =?utf-8?B?ZFU0NkRhbm8yT25VQnRFZ3pUTnhpK0NQRERueFhkbU1kRDR1OXBlZGJ5VU1U?= =?utf-8?B?TGxXWDNaeWkwUnRqYzhxTTVhdGI4MXBFN3ZwZ1MyZmVRcDUrcVRsRnI3WUwr?= =?utf-8?B?YjUzbFRtU09VZ2RQS0R2S2FWV3p5bGZMdG9pUzU4Y2xlZGpCeXBaeFZMeSta?= =?utf-8?B?bmZUbGoya0NMT0RncFJOaEF1bHBQMFRDTFBwVXk4MWtmZkNqZ0lyUTBBZFlZ?= =?utf-8?B?azF6ODRDbDRJcUY2L282Q1ZjcnFoNmcrY2hpWFdzd2ZsMWE5dDRtWng4NmZR?= =?utf-8?B?LzNvcFpJY3RQekFFdDhoM3ZJWWFSNmNwQXYrRll5ekVTcTllZ0Z4YnZzTERU?= =?utf-8?B?MElzbkZLK2Q1aGU3aFQ3RGRPamNRem5aUWdwRzdvL2lMYjZRRm80Yy9IUFN3?= =?utf-8?B?Qi9DalVKQnlTRHMzSG05OUZmeFcvdmJnL2crTWJ5eDNCZ1lCVjBzcVd5ZU9H?= =?utf-8?B?REN1Q1hHNCs1cmlKNDIwL3pQUzd6TThXbmlrUkJEbjEyRWFIQkh0SXhZdWxv?= =?utf-8?B?NmNEVUM4VC9YZ3RDZ3BsZmFRTEZJOFcrTVRtZmx4TFR6ZnRScGpEa0h5ejJa?= =?utf-8?B?bGptdUp5d1hWam5Rbi9SMGhjbWVzU2dKT09UR2Y1Vm9vdTdqd1A2ZzhwL0xG?= =?utf-8?B?cjI4TmFEaDZPSHBUS01aa2lzYnd6MXZaSlZmODRSTDk3eGR0emtuQmlrQnV2?= =?utf-8?B?Q0NTeHV5ZHZGN1dmTHFUTVFGajQxd3VGdTZudWQ4N2Q5SUlVUjJYN1E5U3hO?= =?utf-8?B?NGx2ZTJHb3ZsY0t4TXBVS0ZrV3dNUy91OG9KTHd6dmxJMDk3eWRsalZabzli?= =?utf-8?B?TzlRVi9ka29ZSEVDQWpDRWVrQUFWMzNUNm9qWW1iYytFYkd0dFl0MmpCaEZx?= =?utf-8?B?MUw5ZWZoNnFqTmgrc2tLcnZzY01TU2pTaUFHS0FMaW0vYlV5b2h2RkszQ1da?= =?utf-8?B?RGoyNCtPQ2VoQW4wV1M4SFZ0cW9nTzVlMjY5ckFsWkZGNmRGOGxMVHJ3YnNs?= =?utf-8?B?YVVTUlUyeHNFcEFBYkh5ZFdha0gzblFRNWtXK0dtbFozaVpVQUhXVXFDR2Vk?= =?utf-8?B?WFk4YzltNFY0S2xwTGF5KzlZSk5YbXA2NkppRHpxMzUrZFRVeDBIa0IzME03?= =?utf-8?Q?nf7jt25oHEb1?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB405; 5:BOIsyfKRtryNQg6UUGiuOOMh4MI+H5r29XrnD/9nky7RXP1yzd7A+GMOzD2SQvWyIqB4ZwvYe0+Epb8eNA2WBiIHQ4K03JSr/mpmAWvn5Ki19U6b/Lrn6bkdTXxOfby2zDVb+OvQEhYrn0AUfM1Wog==; 24:PApS/C7Z8iUEXCrv/KWQTsLBLolmuxj0VytmbpQuD+YfHUoj0LWpXyOycPIS72iWqTVeXID9sqETkS5YU//lqXb/alDrLoyO9oQXsUNIZS8= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2015 18:41:50.7736 (UTC) X-MS-Exchange-CrossTenant-Id: c80d3499-4a40-4a8c-986e-abce017d6b19 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c80d3499-4a40-4a8c-986e-abce017d6b19; Ip=[188.184.36.48]; Helo=[CERNMX12.cern.ch] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR06MB405 Archived-At: Cc: "storagesync@ietf.org" Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 18:42:17 -0000 PiBUaHVyc2RheSwgRGVjIDMsIDIwMTUgNjowMCBBTSBMaW5odWkgU3VuIHdyb3RlOg0KPj4gSG93 ZXZlciBJJ2QgcHJlZmVyIEhUVFAgcmF0aGVyIHRoYW4gV2ViREFWLiBTaW5jZSBJIHN0aWxsIHRo aW5rIFdlYkRBViBpcw0KPj4gbm90IHN1aXRhYmxlIGZvciB0b2RheSdzIHN5bmMgc2VydmljZS4g VGhlIGZyZXF1ZW5jeSBvZiBvcGVyYXRpb25zIGlzIGZhcg0KPj4gaGlnaGVyIHRoYW4gd2hhdCBX ZWJEQVYgZXhwZWN0cy4gRm9yIGV4YW1wbGUsIGZyZXF1ZW50bHkgc2VuZGluZyBwcm9wZmluZA0K Pj4gdG8gZGV0ZWN0IGNoYW5nZXMgaXMgbm90IGEgZ29vZCB3YXkgaW4gbXkgdmlldy4NCj4gDQo+ IFdlYkRBViBpcyBIVFRQLiAgIEhvd2V2ZXIsIHlvdXIgcG9pbnQgYWJvdXQgcHJvcGZpbmQgaXMg Y29ycmVjdC0tdGhhdCBkb2Vzbid0IHNjYWxlLiAgIA0KDQpDb3VsZCB5b3UgcGxlYXNlIGV4cGxh aW4gd2h5IHlvdSB0aGluayBpdCBkb2VzIG5vdCBzY2FsZT8gVGhlcmUgYXJlIHNjaGVtZXMgaW4g d2hpY2ggeW91IGRvIG5vdCBuZWVkIHRvIHByb3BmaW5kIHRoZSBlbnRpcmUgcmVtb3RlIHRyZWUg dG8gZGlzY292ZXIgY2hhbmdlcywgb25seSBhIHNlcXVlbmNlIG9mIHByb3BmaW5kcyBpbiBhIGRp cmVjdCBwYXRoIGxlYWRpbmcgdG8gYSBjaGFuZ2VkIGVudGl0eS4gVGhhdOKAmXMgbm90IG9wdGlt YWwgZm9yIHN1cmUgKHNldmVyYWwgY2FsbHMgbmVlZGVkLCBkZXBlbmRpbmcgb24gdGhlIGRlcHRo IG9mIHRoZSBjaGFuZ2UpIGJ1dCBpZiBpdCBjb21lcyB0byBXZWJEQVYgaXRzZWxmLCBhcGFydCBm cm9tIGEgYmxvYXRlZCBYTUwgcmVwcmVzZW50YXRpb24sIEkgZG8gbm90IHNlZSBtdWNoIHByb2Js ZW0uDQoNCj4gV2hhdCB5b3Ugd2FudCBpcyBhIHNlcGFyYXRlIGxheWVyIGZvciBkZWFsaW5nIHdp dGggc3luY2hyb25pemF0aW9uIG9mIG1ldGFkYXRhLiAgIFlvdSBjb3VsZCB1c2UgSFRUUCB0cmFu c3BvcnQgdG8gZG8gdGhpcywgYnV0IG5vdCBwcm9wZmluZC4NCg0KT2tleSwgYnV0IHdoYXQgeW91 IG5lZWQgdG8gcmVtZW1iZXIgdGhlIGNsaWVudCBzdGF0ZSBhbmQgcGFzcyBpdCBvbiB0byB0aGUg c2VydmVyIHRvIGNhbGN1bGF0ZSB0aGUgZGlmZiBzdGF0ZS4gQW55IGdvb2QgaWRlYXMgaG93IHRv IGRvIHRoYXQ/DQoNCmt1YmENCg0KLS0NCg0KPiANCj4gLS0NCj4gU2VudCBmcm9tIFdoaXRlb3V0 IE1haWwgLSBodHRwczovL3doaXRlb3V0LmlvDQo+IA0KPiBNeSBQR1Aga2V5OiBodHRwczovL2tl eXMud2hpdGVvdXQuaW8vbWVsbG9uQGZ1Z3VlLmNvbV9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPiBTdG9y YWdlc3luY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0b3JhZ2VzeW5jDQoNCg== From nobody Thu Dec 3 11:14:14 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22EB1A002C for ; Thu, 3 Dec 2015 11:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c49JRLG9VVJl for ; Thu, 3 Dec 2015 11:14:11 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id A10761A0016 for ; Thu, 3 Dec 2015 11:14:10 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14491700470270.6078331582248211" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> Date: Thu, 03 Dec 2015 19:14:07 +0000 Message-Id: <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 19:14:13 -0000 ------sinikael-?=_1-14491700470270.6078331582248211 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 1:41 PM Jakub Moscicki wrote: > Could you please explain why you think it does not scale=3F There are = schemes in which you do not need to propfind the entire remote tree to = discover changes, only a sequence of propfinds in a direct path leading to = a changed entity. That=E2=80=99s not optimal for sure (several calls needed= , depending on the depth of the change) but if it comes to WebDAV itself, = apart from a bloated XML representation, I do not see much problem. It doesn't scale because you've just described a lockstep process for = locating changes; instead of there being one transaction to get the set of = changes from a known common version, you have multiple steps, and the = number of steps increases at least logarithmically (I am guessing, since I = don't know your algorithm) as the number of changes since last sync = increases or the size of the tree increases. If you are syncing = continuously this may not be a big deal, but I don't think that's a = reasonable assumption. This also has the problem that you have no separation of metadata and data,= and no versioning, which means that you have to have a client-server model= , and you can't have a distributed peer model. > Okey, but what you need to remember the client state and pass it on to = the server to calculate the diff state. Any good ideas how to do that=3F Keep the metadata sorted (e.g. by modification time), and do a diff = whenever a new version is generated. Versions that have never been shared= with other peers should be trimmed once they are not the head version. = When peer A wants to sync with peer B, it announces the version it has and = the version it last remembers syncing with peer B. If Peer B remembers = that version, then the difference can be computed trivially, O(n), and is = minimal (n*2 at worst), where n is the number of changes. If Peer B has = lost its memory, then it has to send the complete inventory of its head = version, which Peer A can then compare with its head to see what's changed.= -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14491700470270.6078331582248211 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYJR/CRAMw8Nu0HeKywAARoAIAK+Q9xqsiwgmA1sT6dS7 iRi3O1Vmh2ZIZgBKXDoh5Xli5V+tJ9gRgWilzPOFVC9KOc8LASTbh71hXTRi ewv8A6alRe6J0M+0F/RNcGzZ3Q+R7ULrl/Ge9oEBg4aYbFAg7A5a9zWt0iYo 3zXzYOrukmoKuC4UinmEana0Zcz+9sDUWwBW1xxyd+A07VksSvxSKJGZF20x C08pr6WxzufLIlcHa2nezxIXXhFv/yExubZnFC92xfeZliP7gAL9viUr2MwM tkHBR3n6Fs3htdaa9WIExkTKFZghaBMSUW/cyzK2MFImvkFFB6uYor7uFPNs 45leKmqIJK9yeo/mdYG1z6M= =9f3y -----END PGP SIGNATURE----- ------sinikael-?=_1-14491700470270.6078331582248211-- From nobody Thu Dec 3 13:14:51 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A232C1A8838 for ; Thu, 3 Dec 2015 13:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMVw26_Gz-6O for ; Thu, 3 Dec 2015 13:14:47 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3921A8822 for ; Thu, 3 Dec 2015 13:14:47 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8D8E120825 for ; Thu, 3 Dec 2015 16:14:46 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute2.internal (MEProxy); Thu, 03 Dec 2015 16:14:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=RxF SdHLGsihivksyK8VFoBTpLKY=; b=NpU1Mo7YKKH/ju6IYrV45/18n3MxaSp/pzj 1YPOhI6/8XzXmpa4d4+nmR1J5t0C7vE0u7bUqW8QU+T27m7MuDsAIdOAS3TsBTsQ 8qUVTux4kziRH7JLpjUXtkaW6qGTNm2hGZvmE8nzPvJxeHQiAU31gMCSJ/RKZq5Z juM1vdkM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=RxFSdHLGsihivksyK8VFoBTpLKY=; b=YVfm7 L4AAeSurD2vPiPVLeGYs1BRY1Ar1MJtJsEyYLpONGYrmzVrBEbPxJAgwTNsl1CSF lmJlFS3JYe1TKE3w0sakMXzJ4XTXLh7O2NzPMtZTXTnelT0cwMXb2GNFsz7RXcNM fw1jKzZERAKtwYF0Q7P4SsMS52eJJnSrhZWhjQ= Received: by web2.nyi.internal (Postfix, from userid 99) id 5624C5402A0; Thu, 3 Dec 2015 16:14:46 -0500 (EST) Message-Id: <1449177286.2507848.457409737.10AEAB2B@webmail.messagingengine.com> X-Sasl-Enc: dU//eIaUHSs0TNQtkEj1PQhyRTfqRwN4AnD4se/yxR7t 1449177286 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: storagesync@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 Date: Thu, 03 Dec 2015 22:14:46 +0100 Archived-At: Subject: [Storagesync] Mechanisms to synchronize client file systems with Internet-based data storage services X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 21:14:49 -0000 >Thursday, Dec 3, 2015 1:41 PM Jakub Moscicki wrote: >Could you please explain why you think it does not scale? There are scheme= s in which you do not need to propfind >the entire remote tree to discover = changes, only a sequence of propfinds in a direct path leading to a changed= >entity. That=E2=80=99s not optimal for sure (several calls needed, depend= ing on the depth of the change) but if it comes to >WebDAV itself, apart fr= om a bloated XML representation, I do not see much problem. >It doesn't scale because you've just described a lockstep process for loca= ting changes; instead of there being one >transaction to get the set of cha= nges from a known common version, you have multiple steps, and the number o= f >steps increases at least logarithmically (I am guessing, since I don't k= now your algorithm) as the number of >changes since last sync increases or = the size of the tree increases. If you are syncing continuously this may = not >be a big deal, but I don't think that's a reasonable assumption. This depends on which part of your system you want to put the synchronisation logic. The approach Jakub has described delegates the sync responsibility to clients and the server does not do too much job and can scale to handle the blast of possible PROPFIND requests. On the other hand, as you mentioned, the server can facilitate the sync job to clients creating snapshots of the system in a given moment and give the clients a delta. This approach puts much more load on the server and it is more difficult to scale. Both types of sync has their own benefits and drawbacks and the election should be made on the use case you want for your business. >This also has the problem that you have no separation of metadata and data= , and no versioning, which means that >you have to have a client-server mod= el, and you can't have a distributed peer model. I totally disagree here, you can have your metadata fully detached from the data and be able to sync. Also, you can expose versions trough WebDAV creating your own logic or use WebDAV extensions that deal with that. The RFC https://www.ietf.org/rfc/rfc3253.txt gives GIT-like version control to WebDAV Resources. >Okey, but what you need to remember the client state and pass it on to the= server to calculate the diff state. Any >good ideas how to do that? >Keep the metadata sorted (e.g. by modification time), and do a diff whenev= er a new version is generated. Versions >that have never been shared with= other peers should be trimmed once they are not the head version. When p= eer >A wants to sync with peer B, it announces the version it has and the v= ersion it last remembers syncing with peer B. >If Peer B remembers that v= ersion, then the difference can be computed trivially, O(n), and is minimal= (n*2 at worst), >where n is the number of changes. If Peer B has lost it= s memory, then it has to send the complete inventory of its >head version, = which Peer A can then compare with its head to see what's changed. From nobody Thu Dec 3 17:40:30 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AD71ACE62 for ; Thu, 3 Dec 2015 17:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.539 X-Spam-Level: *** X-Spam-Status: No, score=3.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGdyPE7_xToU for ; Thu, 3 Dec 2015 17:40:26 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8901ACE58 for ; Thu, 3 Dec 2015 17:40:25 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygB3WB2f72BWNgoHAA--.5165S2; Fri, 04 Dec 2015 09:42:55 +0800 (CST) Date: Fri, 4 Dec 2015 09:40:16 +0800 From: "Fei Song" To: =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= , "Linhui Sun" References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com>, <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120409400610904616@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygB3WB2f72BWNgoHAA--.5165S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Jw4DWFy8ur1xJw1DAF4DXFb_yoWxGFWkpF W7JFsrKr4kJr4rA3s2vr1Iqw10vryvgr47Xrn8tr1xJ3s0yF93Kr17Ar1ruFW7Xr15Gr1j vr4YgFy3WrZ8AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUgw FxDUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 01:40:29 -0000 SGkNCg0KU29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5LCBQbGVhc2Ugc2VlIGl0IGlubGluZX4NCg0K DQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj4NCj4NCj4NCj5PbiBXZWQsIERlYyAyLCAyMDE1 LCBhdCAxMToxOCBBTSwgTGluaHVpIFN1biB3cm90ZToNCj4+IEhpDQo+Pg0KPj4gT24g1tzI/Swg MTLUwiAyLCAyMDE1IGF0IDE3OjU2LCAgSHVnbyBHb256qKJsZXogTGFicmFkb3INCj4+IDxpZXRm QGh1Z28ubGFia29kZS5jb20+IHdyb3RlOg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIFdlZCwgRGVj IDIsIDIwMTUsIGF0IDA4OjIwIEFNLCBMaW5odWkgU3VuIHdyb3RlOg0KPj4+PiBIaQ0KPj4+Pg0K Pj4+PiAyMDE1LTEyLTAyIDU6MTQgR01UKzA4OjAwIEh1Z28gR29ueqiibGV6IExhYnJhZG9yDQo+ Pj4+IDxpZXRmQGh1Z28ubGFia29kZS5jb20+Og0KPj4+Pj4gSGksDQo+Pj4+Pg0KPj4+Pj4gZnJv bSBteSBwb2ludCBvZiB2aWV3IHRoZSByZW1vdGVTdG9yYWdlIHByb2plY3QgYWRkcmVzc2VzIGEg c3Vic2V0DQo+Pj4+PiBvZiB0aGUgdXNlIGNhc2VzIG9mIHRoZT8gV2ViREFWIHNwZWNpZmljYXRp b24uDQo+Pj4+Pg0KPj4+Pj4gVGhlIG1haW4gZGlmZmVyZW5jZSBJIGNhbiBvYnNlcnZlIGlzIHRo YXQgdGhlIHNwZWNpZmljYXRpb24gaXMNCj4+Pj4+IGJ1aWx0IG9uIFJFU1QgaW5zdGVhZCBvZiBY TUwtYmFzZWQgY29tbXVuaWNhdGlvbi4NCj4+Pj4+DQo+Pj4+PiBJIHBlcnNvbmFsbHkgbGlrZSBt dWNoIG1vcmUgUkVTVCB0aGFuIFdlYkRBViBiZWNhdXNlIGl0IGlzIG1vcmUNCj4+Pj4+IGRldmVs b3BlciBmcmllbmRseSBhbmQgaXQgaXMgZmFzdGVyIHRvIGRldmVsb3AuP01heWJlIHRoZQ0KPj4+ Pj4gcmVtb3RlU3RvcmFnZSBBUEkgYmVjb21lcyB0aGUgbmV4dCBXZWJEQVYgOikNCj4+Pj4+DQo+ Pj4+PiBIb3dldmVyLCB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgZG9lcyBub3QgcHJvdmlkZSBhIHdh eSBvZg0KPj4+Pj4gc3luY2hyb25pc2luZyBkYXRhLCB0aGlzIHRhc2sgaXMgZGVsZWdhdGVkIHRv IHRoZSBkZXZlbG9wZXJzLiBJcw0KPj4+Pj4gdGhlcmUgYSBwbGFuIHRvIHByb3ZpZGUgc3VjaCBm ZWF0dXJlIGJhc2VkIG9uIHRoZSBvdXRjb21lIG9mIHRoaXMNCj4+Pj4+IGRyYWZ0Pw0KPj4+PiBJ J20gYSBsaXR0bGUgYml0IGNvbmZ1c2VkIHdoeSB5b3Ugc2F5IHRoZSByZW1vdGVTdG9yYWdlIGRv ZXMgbm90DQo+Pj4+IHByb3ZpZGUgdGhhdC4gSXMgdGhhdCBiZWNhdXNlIHJlbW90ZVN0b3JhZ2Ug ZG9lcyBub3QgcGVyZm9ybSBsaWtlDQo+Pj4+IGEgdHlwaWNhbCBzeW5jIHNlcnZpY2VzIChlLmcu IGRyb3Bib3guLi4pIG9yIHlvdSBhcmUgc2F5aW5nDQo+Pj4+IHNvbWV0aGluZyBlbHNlPw0KPj4+ IFllcywgYmVjYXVzZSBpdCBkb2VzIG5vdCBvZmZlciBzeW5jaHJvbmlzYXRpb24gY2FwYWJpbGl0 aWVzLg0KPj4gR290IGl0LiBBbmQgV2hhdCBJIGFtIHdvbmRlcmluZyBpcyB0aGF0IGRvIHdlIG5l ZWQgdG8gaW5jbHVkZSB0aG9zZQ0KPj4gY2FwYWJpbGl0aWVzIGluIGEgYmFzZSBzcGVjaWZpY2F0 aW9ucy4gU2luY2UgaXQgaXMgaGFyZCB0byBzdGFuZGFyZGl6ZQ0KPj4gdGhlIGNhcGFiaWxpdGll cyBsaWtlIGRlZHVwIG9yIGRlbHRhLiBNYXliZSBhIGJldHRlciB3YXkgaXMgdG8gZGVmaW5lDQo+ PiB0aG9zZSBpbiBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24sIHNvbWV0aGluZyBsaWtlIGV4dGVu c2lvbnMuIEZvciBhDQo+PiBiYXNlIGRvY3VtZW50LCB3ZSBqdXN0IG5lZWQgdG8gZGVmaW5lIGhv dyB0byBwZXJmb3JtIHN5bmMgb3BlcmF0aW9ucy4NCj4NCj5ZZXMsIEkgYWdyZWUgdGhhdCBtYXkg YmUgIGFuIGV4dGVuc2lvbiBvZiB0aGlzIGRyYWZ0IGNvdWxkIGhhbmRsZSB0aGUNCj5zeW5jaHJv bmlzYXRpb24gcGFydC4NCj4NCj4+Pg0KPj4+Pj4NCj4+Pj4+IEJUVywgSSB3YW50IHRvIGludHJv ZHVjZSBDbGF3SU8gKGh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvKSwgYQ0KPj4+Pj4gcmVzZWFyY2gg cHJvamVjdCB0byBiZW5jaG1hcmsgZGlmZmVyZW50IHN5bmNocm9uaXNhdGlvbiBwcm90b2NvbHMN Cj4+Pj4+IGFnYWluc3QgZGlmZmVyZW50IGRhdGEgYmFja2VuZHMgd2l0aCBzcGVjaWFsIGF0dGVu dGlvbiB0byBwcm92aWRlIGENCj4+Pj4+IGNvbW1vbiBzeW5jIEFQSS4NCj4+Pj4+DQo+Pj4+PiBB IGNvbW1vbiBBUEkgZm9yIGRpZmZlcmVudCBzeW5jIHByb3RvY29scyBpcyBiZWluZyBjcmVhdGVk IGJhc2VkIG9uDQo+Pj4+PiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmllZCBpbiB0aGlzIGRyYWZ0 IChjb250cm9sIGFuZCBkYXRhIHNlcnZlcnMpDQo+Pj4+PiBhbmQgdGhlDQo+Pj4+IEkgY2Fubm90 IGZpbmQgYSBkaXN0cmlidXRlZCBhcmNoaXRlY3R1cmUgaW4gdGhpcyBkcmFmdC4gSXQgc2VlbXMN Cj4+Pj4gdGhhdCB0aGV5IGhhbmRsZSBtZXRhZGF0YSBhbmQgY29udGVudCBkYXRhIHRvZ2V0aGVy LCBqdXN0IGxpa2UgYQ0KPj4+PiBub3JtYWwgd2ViIHNlcnZpY2UuDQo+Pj4NCj4+PiBDbGF3SU8g aXMgZnVsbHkgZGlzdHJpYnV0ZWQuIEV2ZXJ5IGxvZ2ljYWwgdW5pdCBpcyBhIGRpZmZlcmVudCBz ZXJ2ZXINCj4+PiB0aGFuIGJlIHNjYWxlZCBvdXQuIERhdGEgYW5kIE1ldGFkYXRhIGNoYW5uZWxz IGFyZSBpbmRlcGVuZGVudCBmcm9tDQo+Pj4gZWFjaCBvdGhlciBhbmQgcmVzaWRlIG9uIGRpZmZl cmVudCBzZXJ2ZXJzLg0KPj4gVGhhdCBpcyB3aWRlbHkgZW1wbG95ZWQgaW4gcG9wdWxhciBzeW5j IHNlcnZpY2VzLiBBbmQgdGhhdCBpcyBhbHNvDQo+PiBiZW5lZmljaWFsIHRvIHByaXZhY3kgdG8g c29tZSBleHRlbnQuIEJ1dCBpbiB0aGUgY29udGV4dCBvZiBzeW5jIGluDQo+PiBicm93c2VyICh3 aGljaCBpcyBtYWlubHkgY29uc2lkZXJlZCBpbiB0aGUgcmVtb3RlU3RvcmFnZSksIEkgZG9uJ3QN Cj4+IGtub3cgd2hldGhlciB0aGlzIGlzIHJlYXNvbmFibGUuIEJ1dCBJIHRoaW5rIHdlIHNob3Vs ZCBkZXBsb3kNCj4+IGRpc3RyaWJ1dGVkIGFyY2hpdGVjdHVyZSBhbHRob3VnaCBpdCB3aWxsIG1h a2UgdGhpbmdzIGNvbXBsaWNhdGVkLg0KPg0KPk9mIGNvdXJzZSwgdGhlIHJlbW90ZVN0b3JhZ2Ug aXMgdGFyZ2V0ZWQgdG8gYnJvd3NlcnMsIHNvIHN5bmNpbmcgZG9lcw0KPm5vdCBtYWtlIHRvbyBt dWNoIHNlbnNlIGluIHRoaXMgY2FzZS4gV2l0aCB0aGUgcmlzZSBvZiBMaW51eCBjb250YWluZXIN Cj5taWNyby1zZXJ2aWNlIGJhc2VkIGFyY2hpdGVjdHVyZXMsIHRoZSBkZXBsb3ltZW50IG9mID9z dWNoIGhpZ2hseQ0KPmNvbXBsZXggc3lzdGVtcyBzaG91bGQgYmVjb21lIGVhc2llciBhbmQgZmFz dGVyLg0KDQpJbmRlZWSjoVRoaXMgaXMgd2h5IEkgc2FpZCB0aGUgc3luY2hyb25pemF0aW9uIHNo b3VsZCBiZSBtZW50aW9uZWQgYXQgdGhlIGFic3RyYWN0Lg0KT3RoZXJ3aXNlLCBpdCBzZWVtcyB0 aGF0IHRoZSByZW1vdGVTdG9yYWdlIGRyYWZ0IG9ubHkgZm9jdXMgb24gYnJvd3Nlci1iYXNlZCBz dG9yYWdlLg0KDQoNCj4NCj5CZXN0LA0KPg0KPkh1Z28NCj4NCj4+IFJlZ2FyZHMsIExpbmh1aQ0K Pj4+DQo+Pj4NCj4+Pj4gUmVnYXJkcywgTGluaHVpDQo+Pj4+PiBvbmUgZnJvbSB0aGUgQ0VSTiBF T1MgcHJvamVjdCAobWFuYWdlbWVudCwgZGlzayBhbmQgcXVldWUgc2VydmVycykuDQo+Pj4+Pg0K Pj4+Pj4gVGhlIFBoYXNlIEkgaGFzIGltcGxlbWVudGVkIHRoZSBvd25DbG91ZCBTeW5jIFByb3Rv Y29sIGFuZCBQaGFzZSBJSQ0KPj4+Pj4gd2lsbCBpbXBsZW1lbnQgdGhlIFNlYUZpbGUgU3luYyBQ cm90b2NvbC4gVGhlIGNob2ljZSBvZiB0aGVzZQ0KPj4+Pj4gcHJvdG9jb2xzIGFtb25nIG90aGVy cyBpcyBiZWNhdXNlIHRoZXkgYXJlIHJlYWxseSBvcHBvc2VkIHRvIGVhY2gNCj4+Pj4+IG90aGVy IGluIHRlcm1zIG9mIHN5bmNpbmcgKGRlbHRhIHZzIG5vbi1kZWx0YSwgc3RhdGUtYmFzZWQgdnMg bG9nL2V2ZW50L2dpdC0NCj4+Pj4+IGJhc2VkIHN5bmMgoa0pLCBzbyBmaW5kaW5nIGEgY29tbW9u IGFwcHJvYWNoIGlzIG1vcmUgY2hhbGxlbmdpbmcuDQo+Pj4+Pg0KPj4+Pj4gUHJvdmlkaW5nIGEg YmFzZSBzcGVjaWZpY2F0aW9uL2FyY2hpdGVjdHVyZSB0byBtZWFzdXJlIHRoZQ0KPj4+Pj4gZmVh c2liaWxpdHkgb2YgdGhpcyBkcmFmdCBpcyBvbmUgb2YgdGhlIG9iamVjdGl2ZXMgb2YgdGhlIHBy b2plY3QuDQo+Pj4+Pg0KPj4+Pj4gSSBiZWxpZXZlIHRoYXQgdGhlIHdvcmsgYmVpbmcgZG9uZSBo ZXJlIGFuZCBpbiBDbGF3SU8gYXJlDQo+Pj4+PiBzdXBwbGVtZW50YXJ5IHRvIGVhY2ggb3RoZXIg YW5kIEkgdGhpbmsgbXV0dWFsIGNvbGxhYm9yYXRpb24gY291bGQNCj4+Pj4+IGJlIGJlbmVmaWNp YWwgZm9yIGJvdGggc2lkZXMuDQo+Pj4+Pg0KPj4+Pj4gQWxzbywgaWYgdGhlcmUgaXMgaW50ZXJl c3QsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBjYW4gYmUgYWRkZWQgdG8NCj4+Pj4+IENsYXdJTy4N Cj4+Pj4+DQo+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+Pg0KPj4+Pj4gSHVnbyBHb256YWxleiBM YWJyYWRvcg0KPj4+Pj4NCj4+Pj4+IE9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0IDA5OjAwIFBNLCBz dG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnDQo+Pj4+PiB3cm90ZToNCj4+Pj4+ID4gU2VuZCBT dG9yYWdlc3luYyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCj4+Pj4+ID4gc3RvcmFnZXN5 bmNAaWV0Zi5vcmcNCj4+Pj4+ID4NCj4+Pj4+ID4gVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJl IHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQo+Pj4+PiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMgb3IsIHZpYSBlbWFpbCwNCj4+Pj4+ID4g c2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvPyA/ID8gP3N0b3Jh Z2VzeW5jLQ0KPj4+Pj4gPiByZXF1ZXN0QGlldGYub3JnDQo+Pj4+PiA+DQo+Pj4+PiA+IFlvdSBj YW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdD8gPyA/ID9zdG9yYWdlc3lu Yy0NCj4+Pj4+ID4gb3duZXJAaWV0Zi5vcmcNCj4+Pj4+ID4NCj4+Pj4+ID4gV2hlbiByZXBseWlu ZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZQ0KPj4+Pj4gPiBz cGVjaWZpYyB0aGFuICJSZTogQ29udGVudHMgb2YgU3RvcmFnZXN5bmMgZGlnZXN0Li4uIiBUb2Rh eSdzDQo+Pj4+PiA+IFRvcGljczoNCj4+Pj4+ID4NCj4+Pj4+ID4xLiBOZXcgdmVyc2lvbiBvZiBk cmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZT8gPyBJbnRlcm5ldC1EcmFmdA0KPj4+Pj4gPmF2YWls YWJsZSAoTWljaGllbCBkZSBKb25nKT8gPyAyLiBSZTogTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVq b25nLQ0KPj4+Pj4gPnJlbW90ZXN0b3JhZ2UgSW50ZXJuZXQtRHJhZnQ/ID8gPyA/YXZhaWxhYmxl IChHaWhhbiBEaWFzKT8gPyAzLg0KPj4+Pj4gPlJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpv bmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdA0KPj4+Pj4gPmF2YWlsYWJsZSAoRmVpIFNv bmcpDQo+Pj4+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+PiA+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBTdG9yYWdlc3luY0BpZXRmLm9y Zw0KPj4+Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2Vz eW5jIEVtYWlsIGhhZCAzDQo+Pj4+PiA+IGF0dGFjaG1lbnRzOg0KPj4+Pj4gPiArIFtTdG9yYWdl c3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgSW50ZXJuZXQt DQo+Pj4+PiA+ICAgRHJhZnQgYXZhaWxhYmxlPyA/MmsgKG1lc3NhZ2UvcmZjODIyKQ0KPj4+Pj4g PiArIFJlOiBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVz dG9yYWdlIEludGVybmV0LQ0KPj4+Pj4gPiAgIERyYWZ0IGF2YWlsYWJsZT8gPzFrIChtZXNzYWdl L3JmYzgyMikNCj4+Pj4+ID4gKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFm dC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC0NCj4+Pj4+ID4gICBEcmFmdCBhdmFpbGFi bGU/ID8yayAobWVzc2FnZS9yZmM4MjIpDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcg bGlzdCBTdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPj4+DQo+ From nobody Thu Dec 3 17:47:24 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91F1AD0D6 for ; Thu, 3 Dec 2015 17:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCIUdUnNrGEp for ; Thu, 3 Dec 2015 17:47:22 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E41AD0D2 for ; Thu, 3 Dec 2015 17:47:21 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygAnpAZE8WBWww4HAA--.17018S2; Fri, 04 Dec 2015 09:49:56 +0800 (CST) Date: Fri, 4 Dec 2015 09:47:16 +0800 From: "Fei Song" To: =?gb2312?B?RnJhbj9vaXMgS29vbWFu?= , "Michiel de Jong" References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn>, <56600F0A.9000200@tuxed.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120409471596810319@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygAnpAZE8WBWww4HAA--.17018S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw1xtw4xJrWfAryrXF1fWFg_yoW8KF15pa yfKr4fKFWkJF4fAw18Ww1xWr1Fvws7JFW3Grn3KryfG398JFyrKry0yw4FgFn7Zry5Wr12 vrWj9F9xu3Z8AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 xWrtUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Linhui Sun , storagesync , =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 01:47:23 -0000 SGkgRnJhbj9vaXMsDQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+T24gMTIvMDMvMjAx NSAxMDowNiBBTSwgZnNvbmdAYmp0dS5lZHUuY24gd3JvdGU6DQo+PiBJZiB3ZSByZWFsbHkgd2Fu dCB0byBkaXNjdXNzIHRoZSBQcm9zIGFuZCBDb25zIG9mIFdlYkRBViwgY2FuIHdlDQo+PiBtYXJr IHRoZXNlIHRocmVlIHJlYXNvbnMgYXMgZGlzYWR2YW50YWdlcyBvZiBXZWJEQVY/IGFueSBzdXBw b3J0IGZvcg0KPj4gdGhhdD8NCj4NCj5QZXJzb25hbGx5LCBJIGRvIG5vdCB0aGluayB0aGF0IGlz IGZhaXIuDQo+DQo+PiAxKSBpdCdzIGEgbG90IG9mIHdvcmsgdG8gaW1wbGVtZW50IHRoaXMgd2l0 aG91dCB1c2luZyBhbiBleGlzdGluZw0KPj4gV2ViREFWIGxpYnJhcnkgDQo+DQo+SSBkbyBub3Qg c2VlIGEgcHJvYmxlbSBpbiByZXVzaW5nIGFuIGV4aXN0aW5nIFdlYkRBViBsaWJyYXJ5LiBUaGlz IGhhcw0KPnRoZSBhZGRlZCBiZW5lZml0IHRoYXQgeW91IGdldCBhIGxvdCBvZiBmdW5jdGlvbmFs aXR5ICdmb3IgZnJlZScgYW5kDQo+dGhhdCBleGlzdGluZyB0ZXN0IHN1aXRlcyBhcmUgYXZhaWxh YmxlIGZvciB0ZXN0aW5nIGNvbXBhdGliaWxpdHkuIFRoaXMNCj5pcyBwdXJlbHkgYSBwcmFjdGlj YWwgYXJndW1lbnQhDQo+DQo+PiAyKSBpbiBwcmFjdGljZSwgYSBsb3Qgb2YgV2ViREFWIHNlcnZl cnMgZ2V0IGl0IHdyb25nLA0KPj4gb3IgZG9uJ3QgaW1wbGVtZW50IGFsbCBvZiBXZWJEQVYuIEl0 J3MgdmVyeSBhbm5veWluZyBmb3IgY2xpZW50DQo+PiBpbXBsZW1lbnRlcnMgdG8gaGF2ZSB0byBk ZWFsIHdpdGggc2VydmVycyB0aGF0IGUuZy4gY2hvc2Ugbm90IHRvDQo+PiBpbXBsZW1lbnQgTE9D SyBhbmQgVU5MT0NLLiANCj4NCj5UaGUgcG9pbnQgaXMgbm90IHRvIGhhdmUgYSBmdWxseSBjb21w bGlhbnQgKHdoYXRldmVyIHRoYXQgaXMgZXhhY3RseSkNCj5XZWJEQVYgc2VydmVyLiBFaXRoZXIg dGhpcyBNTCAob3IgcmVtb3RlU3RvcmFnZSBzcGVjaWZpY2F0aW9uKSBjb3VsZA0KPmRldGVybWlu ZSBhIHN1YnNldCBvZiBXZWJEQVYgdGhhdCB3b3VsZCBiZSByZXF1aXJlZCB0byBiZSBpbXBsZW1l bnRlZC4NCj5FLmcuIHdlIGV4aGF1c3RpdmVseSBsaXN0IHRoZSB2ZXJicyB0aGF0IG5lZWQgdG8g YmUgaW1wbGVtZW50ZWQgYW5kDQo+dGhlaXIgZXhwZWN0ZWQgYmVoYXZpb3IuIElmIHdlIGtlZXAg dGhpcyBhIGxpbWl0ZWQgYXMgcG9zc2libGUgYW5kIHN0YXkNCj5hd2F5IGZyb20gZXhwZXJpbWVu dGFsIGZlYXR1cmVzIHdlIGhhdmUgYSBoaWdoIHByb2JhYmlsaXR5IHRoYXQgbW9zdA0KPmxpYnJh cmllcyB3aWxsIGdldCBpdCByaWdodCEgSWYgd2Ugc3RheSBhd2F5IGZyb20gbG9ja2luZyBhbmQg QUNMcyB0aGUNCj5saWJyYXJ5IHNpdHVhdGlvbiBsb29rcyBhIGxvdCBicmlnaHRlciA6KQ0KPg0K Pj4gMykgd2UgZG9uJ3QgcmVhbGx5IG5lZWQgYWxsIHRoZXNlIGFkdmFuY2VkDQo+PiBmZWF0dXJl cyBvbiB0b3Agb2Ygc3RhbmRhcmQgSFRUUCwganVzdCBzdXBwb3J0aW5nIEdFVC9QVVQvREVMRVRF IGZvcg0KPj4gcmVzb3VyY2VzLCBhbmQgYWRkaW5nIGEgc2ltcGxlIGZvbGRlciBkZXNjcmlwdGlv biBmb3JtYXQsIGlzIGVub3VnaA0KPj4gZm9yIG1vc3QgYXBwbGljYXRpb25zLg0KPg0KPkV4YWN0 bHkhDQo+DQo+PiBGb3IgdGhlIHRhcmdldCBvZiBvdXIgSVNTIGdyb3VwLCB3aGV0aGVyIHRoZSBX ZWJEQVYgY2FuIGJlIHJldXNlZCBpcyANCj4+IGNyaXRpY2FsLg0KPg0KPldlbGwsIG15IHBvaW50 IGlzIHRoYXQgdGhlcmUgaXMgbGl0dGxlIHJlYXNvbiB0byByZWludmVudCB0aGUgd2hlZWwgaWYN Cj50aGUgb25seSBiZW5lZml0IGlzIHRvIHVzZSBKU09OIGluc3RlYWQgb2YgWE1MIGZvciBmb2xk ZXIgbGlzdGluZ3MuIFRoZQ0KPmFtb3VudCBvZiBleHBlcmllbmNlIGFuZCBhdmFpbGFibGUgdG9v bGluZyBmb3IgV2ViREFWIGlzIGFscmVhZHkgaHVnZSENCj5JdCB3b3VsZCBiZSBhIHdhc3RlIHRv IHRocm93IHRoaXMgYXdheSBqdXN0IGZvciBsaWtpbmcgSlNPTiBiZXR0ZXIuDQo+DQo+QnV0IG1h eWJlIHRoZXJlIGFyZSBvdGhlciByZWFzb25zIHVzaW5nIChhIGxpbWl0ZWQgc2V0IG9mKSBXZWJE QVYgaXMNCj5pbXBvc3NpYmxlIG9yIHVud2FudGVkLi4uDQoNCkZvciB5b3VyIGxhc3QgY29tbWVu dCwgSSB3b25kZXIgZG8gd2UgYWxyZWFkeSBoYXZlIGEgbGltaXRlZCB2ZXJzaW9uIG9mIFdlYkRB Vj8gDQoNCg0KPg0KPkNoZWVycywNCj5GcmFuP29pcw0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+ U3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N0b3JhZ2VzeW5j From nobody Thu Dec 3 17:49:21 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0905B1AD16B for ; Thu, 3 Dec 2015 17:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.878 X-Spam-Level: *** X-Spam-Status: No, score=3.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVMF5Nbz_nGi for ; Thu, 3 Dec 2015 17:49:16 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 160FF1AD151 for ; Thu, 3 Dec 2015 17:49:15 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygB3rj2v8WBW0Q0HAA--.15982S2; Fri, 04 Dec 2015 09:51:43 +0800 (CST) Date: Fri, 4 Dec 2015 09:49:03 +0800 From: "Fei Song" To: =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= , "Michiel de Jong" References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> <5ca31214.2c3d.151672efcf7.Coremail.fsong@bjtu.edu.cn>, <1449136149.4121117.456781881.1C2D2EA8@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120409490359338720@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygB3rj2v8WBW0Q0HAA--.15982S2 X-Coremail-Antispam: 1UD129KBjvAXoWfJFyDGw4UJF4DXw4UAF1kKrg_yoW8Zr4xJo WUJr17Jr48Jr1UXr1DJw1UJr1UJ3WUJr1UJryUXr1UJr15tw1UJr1UJr1UXF45Jr1UXr1U Jr1UJr1UAryUJr18n29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUYw7k0a2IF6F4UM7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0 x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj4 1l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4U JVW0owA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcV CF04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv 6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07j5mR UUUUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Linhui Sun , storagesync , =?gb2312?B?RnJhbj9vaXMgS29vbWFu?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 01:49:20 -0000 SSB0aGluayB0aGF0IHdvdWxkIGJlIG1vcmUgZWZmaWNpZW50LCB0aGFua3MgSHVnb34NCg0KDQot LS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5XaGF0IGlzIHRoZSBiZXN0IHdheSB0byBjb2xsZWN0 IHRoZSBhZHZhbnRhZ2VzIGFuZCBkcmF3YmFja3Mgb2YgV2ViREFWDQo+dnMgcmVtb3RlU3RvcmFn ZSA/DQo+DQo+SSBwcm9wb3NlIHRvIGNyZWF0ZSBhIEdpdEh1YiBpbnN0ZWFkIG9mL2luIGFkZGl0 aW9uIHRvIHNwZWNpZnkgdGhlDQo+ZGlmZmVyZW5jZXMgaGVyZS4gSSB0aGluayBpcyBjbGVhciB0 byBzaG93IHRoaXMgaW5mbyBpbiBzb21ldGhpbmcgbGlrZSBhDQo+dGFibGUgb24gR2l0SHViIGlu c3RlYWQgb2YgaW4gYSBzZXJpZXMgb2YgbWFpbCBtZXNzYWdlcy4NCj4NCj5JIGNhbiBjcmVhdGUg dGhlIHJlcG8gaWYgaXQgaXMgb2theSBmb3IgeW91Lg0KPg0KPkJlc3QsSHVnbw0KPg0KPg0KPk9u IFRodSwgRGVjIDMsIDIwMTUsIGF0IDEwOjMxIEFNLCBmc29uZ0BianR1LmVkdS5jbiB3cm90ZToN Cj4+IEdyZWF0o6ENCj4+DQo+Pg0KPj4+IC0tLS0t1K3KvNPKvP4tLS0tLSAqt6K8/sjLOiogIk1p Y2hpZWwgZGUgSm9uZyIgPG1iZGVqb25nQG1vemlsbGEuY29tPg0KPj4+ICq3osvNyrG85DoqIDIw MTXE6jEy1MIzyNUg0MfG2svEICrK1bz+yMs6KiBmc29uZ0BianR1LmVkdS5jbiAqs63LzToqICJM aW5odWkgU3VuIg0KPj4+IDxsaC5zdW5saW5oQGdtYWlsLmNvbT4sIHN0b3JhZ2VzeW5jIDxzdG9y YWdlc3luY0BpZXRmLm9yZz4sIGZrb29tYW4NCj4+PiA8Zmtvb21hbkB0dXhlZC5uZXQ+LCAiSHVn byBHb256qKJsZXogTGFicmFkb3IiIDxpZXRmQGh1Z28ubGFia29kZS5jb20+DQo+Pj4gKtb3zOI6 KiBSZTogW1N0b3JhZ2VzeW5jXSBTdG9yYWdlc3luYyBEaWdlc3QsIFZvbCA1LCBJc3N1ZSAxDQo+ Pj4NCj4+PiBZZXMhIEknbGwgZGlzY3VzcyB3aXRoIEZyYW5jb2lzIGhvdyB3ZSBjYW4gbWFrZSB0 aGVzZSBib3VuZGFyaWVzDQo+Pj4gY2xlYXJlci4gTWF5YmUgd2UgY2FuIHNwbGl0IGFsb25nIHRo ZXNlIGxpbmVzOg0KPj4+ICogdXBsb2FkL21hbmlwdWxhdGUvcXVlcnkvZG93bmxvYWQgcHJvdG9j b2wgKGUuZy4gV2ViREFWIG9yIHRoZQ0KPj4+ICAgR0VUL1BVVC9ERUxFVEUgb3BlcmF0aW9ucyB3 ZSBjdXJyZW50bHkgZGVmaW5lKQ0KPj4+ICogQ09SUyBvciBvdGhlciBjcm9zcy1vcmlnaW4gYWNj ZXNzIG1lY2hhbmlzbSwgT0FVVEggb3Igb3RoZXIgYXV0aA0KPj4+ICAgbWVjaGFuaXNtLCBXZWJG aW5nZXIgb3Igb3RoZXIgZGlzY292ZXJ5IG1lY2hhbmlzbSwgRVRhZyBvciBvdGhlcg0KPj4+ICAg dmVyc2lvbmluZyBtZWNoYW5pc20NCj4+PiAqIGNodW5raW5nL2RlZHVwaW5nL2RlbHRhLXVwZGF0 ZXMNCj4+Pg0KPj4+IEFuZCB0aGUgcmVtb3RlU3RvcmFnZSBzcGVjIHNob3VsZCBwcm9iYWJseSBv bmx5IGRlZmluZSB0aGUNCj4+PiBtaWRkbGUgcGFydC4NCj4+Pg0KPj4+DQo+Pj4gT24gVGh1LCBE ZWMgMywgMjAxNSBhdCA5OjQ0IEFNLCA8ZnNvbmdAYmp0dS5lZHUuY24+IHdyb3RlOg0KPj4+PiBI aSBNaWNoaWVsIGFuZCBMaW5odWksDQo+DQo+DQo+Pj4+IEkgdGhpbmsgaXQgd2lsbCBiZSBnb29k IHRvIGhhdmUgYSBib3VuZGFyeSBmb3IgdGhpcyBkcmFmdCBhbmQgbGVhdmUNCj4+Pj4gc29tZSB3 b3JrIGZvciB0aGUgYXBwbGljYWl0b24gbGF5ZXJ+DQo+DQo+DQo+Pj4+PiAtLS0tLdStyrzTyrz+ LS0tLS0gKreivP7IyzoqICJNaWNoaWVsIGRlIEpvbmciIDxtYmRlam9uZ0Btb3ppbGxhLmNvbT4N Cj4+Pj4+ICq3osvNyrG85DoqIDIwMTXE6jEy1MIyyNUg0MfG2sj9ICrK1bz+yMs6KiAiTGluaHVp IFN1biIgPGxoLnN1bmxpbmhAZ21haWwuY29tPg0KPj4+Pj4gKrOty806KiBzdG9yYWdlc3luYyA8 c3RvcmFnZXN5bmNAaWV0Zi5vcmc+LCBma29vbWFuDQo+Pj4+PiA8Zmtvb21hbkB0dXhlZC5uZXQ+ LCAiSHVnbyBHb256qKJsZXogTGFicmFkb3IiDQo+Pj4+PiA8aWV0ZkBodWdvLmxhYmtvZGUuY29t PiAq1vfM4joqIFJlOiBbU3RvcmFnZXN5bmNdIFN0b3JhZ2VzeW5jIERpZ2VzdCwNCj4+Pj4+IFZv bCA1LCBJc3N1ZSAxDQo+Pj4+Pg0KPj4+Pj4gQWggc3VyZSwgdGhhdCdzIGVudGlyZWx5IGFwcHJv cHJpYXRlLCByZW1vdGVTdG9yYWdlIHRyZWF0cyBib3RoIHRoZQ0KPj4+Pj4gQ29udGVudC1UeXBl IGhlYWRlciB2YWx1ZSBhbmQgdGhlIGFjdHVhbCBib2R5IG9mIGEgZG9jdW1lbnQgYXMNCj4+Pj4+ IG9wYXF1ZSBzdHJpbmdzIG9mIGJ5dGVzLiBJdCBkb2Vzbid0ICJjYXJlIiBpZiB5b3UgdXNlIGl0 IHRvIHN0b3JlDQo+Pj4+PiBvbmx5IGRhdGEgYmxvY2tzIHRoYXQgYXJlIGNodW5rcyBvZiBzb21l dGhpbmcgZWxzZS4gRm9yIGluc3RhbmNlLA0KPj4+Pj4geW91IGNvdWxkIGhhdmUgYSBmb2xkZXIg b24gYSB1c2VyJ3Mgc3RvcmFnZSB0aGF0IGNvbnRhaW5zIG9ubHkgaW5vZGUtDQo+Pj4+PiBsaWtl IEpTT04tZG9jdW1lbnRzLCB3aGljaCBsaXN0IHRoZSBVUkxzIG9mIGJpbmFyeSBkb2N1bWVudHMg dGhhdA0KPj4+Pj4gbWFrZSB1cCAxS2IgYmxvY2tzIG9mIHRoZSBhY3R1YWwgZGF0YS4gTmljZSBm b3IgZGVkdXBpbmcsIGRlbHRhDQo+Pj4+PiB1cGRhdGVzLCBhbmQgYWxzbyByZW5hbWluZyBmaWxl cyB3aXRob3V0IHJldXBsb2FkaW5nIHRoZWlyIGNvbnRlbnQuDQo+Pj4+Pg0KPj4+Pj4gQnV0IHll YWgsIHRoZSBhcmd1bWVudCBpcyB0aGF0ICpob3cqIHRvIGNyZWF0ZSBhbmQgbWFuYWdlIHRoZXNl DQo+Pj4+PiBjaHVua3MsIGlzIHRoZW4gc3RpbGwgbGVmdCB1cCB0byB0aGUgYXBwbGljYXRpb24g ZGV2ZWxvcGVyIChvciB0bw0KPj4+Pj4gYW5vdGhlciBzcGVjIG9uIHRvcCBvZiB0aGUgcmVtb3Rl U3RvcmFnZSBzcGVjKS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gQ2hlZXJzLCBNaWNoaWVsLg0KPj4+ Pj4NCj4+Pj4+IE9uIFdlZCwgRGVjIDIsIDIwMTUgYXQgMzoyOSBQTSwgTGluaHVpIFN1biA8bGgu c3VubGluaEBnbWFpbC5jb20+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+PiBIaQ0KPj4+Pj4+DQo+Pj4+ Pj4gMjAxNS0xMi0wMiAyMjowNSBHTVQrMDg6MDAgTWljaGllbCBkZSBKb25nIDxtYmRlam9uZ0Bt b3ppbGxhLmNvbT46DQo+Pj4+Pj4+IENvb2whIEkgY3JlYXRlZCBodHRwczovL2dpdGh1Yi5jb20v cmVtb3Rlc3RvcmFnZS9zcGVjL2lzc3Vlcy8xMzcNCj4+Pj4+Pj4gYWJvdXQgdGhlIG5lZWQgZm9y PyBNT1ZFIHZlcmIuIEFwcGxpY2F0aW9uLWxldmVsIGNodW5raW5nIGlzDQo+Pj4+Pj4+IHBhcnRp YWxseSBzdXBwb3J0ZWQgYnkgSFRUUCBpdHNlbGYgdGhyb3VnaCBgQ29udGVudC1SYW5nZWANCj4+ Pj4+Pj4gaGVhZGVycyAoYWx0aG91Z2ggaXQncyBub3QgY2xlYXIgd2hldGhlciB0aGVzZSBhcmUg YWxsb3dlZCBvbiBQVVQNCj4+Pj4+Pj4gcmVxdWVzdHMgYXMgd2VsbCBhcyBvbiBHRVQgcmVxdWVz dHMsIHNlZQ0KPj4+Pj4+PiBodHRwczovL2dpdGh1Yi5jb20vcmVtb3Rlc3RvcmFnZS9zcGVjL2lz c3Vlcy8xMzEpLiBUaGUgcHJvYmxlbSBpcw0KPj4+Pj4+PiB0aGF0IEhUVFAgZGVmaW5lcyB2ZXJz aW9uaW5nIGF0IHRoZSBkb2N1bWVudCBsZXZlbCwgeW91IGNhbm5vdA0KPj4+Pj4+PiBhc2sgYSBz ZXJ2ZXIgdG8gcHJvZHVjZSBvciBjaGVjayBhbiBFVGFnIGZvciBhIHNwZWNpZmljIGJ5dGUtDQo+ Pj4+Pj4+IHJhbmdlIG9mIGEgZG9jdW1lbnQsIG9ubHkgZm9yIHRoZSBlbnRpcmUgZG9jdW1lbnQu DQo+Pj4+Pj4NCj4+Pj4+PiBBY3R1YWxseSB3aGF0IEknbSBzYXlpbmcgaXMgYSBjaHVua2luZyBi ZWZvcmUgdHJhbnNtaXR0aW5nICh1c2luZw0KPj4+Pj4+IGh0dHApLCBpbiB0aGlzIHdheSwgdGhl eSBhcmUgdHJlYXRlZCBhcyBpbmRpdmlkdWFsIGRvY3VtZW50cyBmcm9tDQo+Pj4+Pj4gdGhlIHN0 YW5kcG9pbnQgb2YgaHR0cC4gQnV0IEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMgaXMNCj4+Pj4+ PiBhcHByb3ByaWF0ZSBmb3IgcmVtb3RlU3RvcmFnZSwganVzdCBhIGNvbW1lbnQuDQo+Pj4+Pj4N Cj4+Pj4+PiBSZWdhcmRzLCBMaW5odWkNCj4+Pj4+Pj4NCj4+Pj4+Pj4gQSBjb21wYXJpc29uIGRv Y3VtZW50IHNvdW5kcyBnb29kISBTZWUgYWxzbw0KPj4+Pj4+PiBodHRwOi8vd3d3LnNlcnZpY2Vk ZW51YWdlcy5mci9lbi9nZW5lcmljLXN0b3JhZ2UtZWNvc3lzdGVtLg0KPj4+Pj4+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBDaGVlcnMsIE1pY2hpZWwuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9u IFdlZCwgRGVjIDIsIDIwMTUgYXQgMjozMiBQTSwgTGluaHVpIFN1biA8bGguc3VubGluaEBnbWFp bC5jb20+DQo+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4gVGhhdCdzIGNvb2wgZm9yIG1lLCBhIHNl cGFyYXRlIHNlY3Rpb24gZm9yIHRoaXMgbWlnaHQgbWFrZQ0KPj4+Pj4+Pj4gc2Vuc2UuDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gQW5vdGhlciB0aGluZyBpcyBkbyB3ZSBuZWVkIHRvIGluY2x1ZGUgYW4g YXBwbGljYXRpb24tbGF5ZXINCj4+Pj4+Pj4+IGNodW5raW5nIGhlcmUgKG5vdCBqdXN0IGZvciBh IGJyb3dzZXIgc3luYyksIHNpbmNlIGlmIHdlIHdhbnQgdG8NCj4+Pj4+Pj4+IGZ1cnRoZXIgZXh0 ZW5kIG90aGVyIGNhcGFiaWxpdGllcyBpdCBpcyBlc3NlbnRpYWwuDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gUmVnYXJkcywgTGluaHVpDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gMjAxNS0xMi0wMiAyMTowMyBH TVQrMDg6MDAgSHVnbyBHb256qKJsZXogTGFicmFkb3INCj4+Pj4+Pj4+IDxpZXRmQGh1Z28ubGFi a29kZS5jb20+Og0KPj4+Pj4+Pj4+IF9fDQo+Pj4+Pj4+Pj4gSSBwcm9wb3NlIHRvIGNvbWUgdXAg d2l0aCBhIGxpc3Qgb2YgYWR2YW50YWdlcyBhbmQNCj4+Pj4+Pj4+PiBkaXNhZHZhbnRhZ2VzIG9m IHVzaW5nIFdlYkRBViBhbmQgY29tcGFyZSB0aGVtIGFnYWluc3QgYQ0KPj4+Pj4+Pj4+IEpTT04v UkVTVCBiYXNlZCBhcHByb2FjaCwgbGlrZSByZW1vdGVTdG9yYWdlLg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gRG9lcyBpdCBzb3VuZCBnb29kID8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gT24gV2VkLCBEZWMgMiwgMjAxNSwgYXQgMDE6NTkgUE0sIExpbmh1aSBTdW4gd3JvdGU6DQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IDIwMTUtMTItMDIgMjA6NDMgR01UKzA4 OjAwIEh1Z28gR29ueqiibGV6IExhYnJhZG9yDQo+Pj4+Pj4+Pj4+IDxpZXRmQGh1Z28ubGFia29k ZS5jb20+Og0KPj4+Pj4+Pj4+Pj4gX18NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAw MTozMCBQTSwgTWljaGllbCBkZSBKb25nIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+IEhpIGFsbCEgVGhh bmtzIGZvciBhbGwgeW91ciByZWFjdGlvbnMgdG8gdGhlIHJlbW90ZVN0b3JhZ2UNCj4+Pj4+Pj4+ Pj4+PiBJbnRlcm5ldC1EcmFmdC4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFdlIGdldCB0 aGUgcXVlc3Rpb24gYWJvdXQgV2ViREFWIGEgbG90LCBpbiB0aGUgbmV4dCB2ZXJzaW9uDQo+Pj4+ Pj4+Pj4+Pj4gd2Ugc2hvdWxkIGFkZCBhIHJlbWFyayBhYm91dCBpdCBpbiB0aGUgaW50cm8uIFRo ZSBmb2xkZXINCj4+Pj4+Pj4+Pj4+PiBkZXNjcmlwdGlvbnMgcmV0dXJuZWQgd2hlbiB5b3UgR0VU IGEgVVJMIHRoYXQgZW5kcyB3aXRoIGEgLw0KPj4+Pj4+Pj4+Pj4+IGFyZSBpbmRlZWQgYSBkZXZp YXRpb24gZnJvbSB0aGUgWE1MIHJldHVybmVkIGJ5IFdlYkRBVg0KPj4+Pj4+Pj4+Pj4+IHNlcnZl ciwgYW5kIHRoaXMgaXMganVzdCBiZWNhdXNlIG5vd2FkYXlzIEpTT04gaXMgZWFzaWVyIHRvDQo+ Pj4+Pj4+Pj4+Pj4gdXNlIHRoYW4gWE1MIGZvciBkZXZlbG9wZXJzLCBib3RoIGNsaWVudC1zaWRl IGFuZCBzZXJ2ZXItDQo+Pj4+Pj4+Pj4+Pj4gc2lkZS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4gSSB0b3RhbGx5IGFncmVlIGhlcmUsIHRoaXMgd2FzIGdvaW5nIHRvIGhh cHBlbiBzb29uIG9yIGxhdGVyDQo+Pj4+Pj4+Pj4+PiBhbmQgaXQgaXMgcmVhbGx5IGFwcHJlY2lh dGVkLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhlIGZhY3QgdGhh dCB3ZSBkb24ndCByZXF1aXJlIHNlcnZlcnMgdG8gc3VwcG9ydCBXZWJEQVYncw0KPj4+Pj4+Pj4+ Pj4+IGN1c3RvbSB2ZXJicyBsaWtlIFBST1BQQVRDSCBldGMuIGlzIGZvciB0aHJlZSByZWFzb25z Og0KPj4+Pj4+Pj4+Pj4+IDEpIGl0J3MgYSBsb3Qgb2Ygd29yayB0byBpbXBsZW1lbnQgdGhpcyB3 aXRob3V0IHVzaW5nIGFuDQo+Pj4+Pj4+Pj4+Pj4gICAgZXhpc3RpbmcgV2ViREFWIGxpYnJhcnkN Cj4+Pj4+Pj4+Pj4+PiAyKSBpbiBwcmFjdGljZSwgYSBsb3Qgb2YgV2ViREFWIHNlcnZlcnMgZ2V0 IGl0IHdyb25nLCBvcg0KPj4+Pj4+Pj4+Pj4+ICAgIGRvbid0IGltcGxlbWVudCBhbGwgb2YgV2Vi REFWLiBJdCdzIHZlcnkgYW5ub3lpbmcgZm9yDQo+Pj4+Pj4+Pj4+Pj4gICAgY2xpZW50IGltcGxl bWVudGVycyB0byBoYXZlIHRvIGRlYWwgd2l0aCBzZXJ2ZXJzIHRoYXQNCj4+Pj4+Pj4+Pj4+PiAg ICBlLmcuIGNob3NlIG5vdCB0byBpbXBsZW1lbnQgTE9DSyBhbmQgVU5MT0NLLg0KPj4+Pj4+Pj4+ Pj4+IDMpIHdlIGRvbid0IHJlYWxseSBuZWVkIGFsbCB0aGVzZSBhZHZhbmNlZCBmZWF0dXJlcyBv biB0b3ANCj4+Pj4+Pj4+Pj4+PiAgICBvZiBzdGFuZGFyZCBIVFRQLCBqdXN0IHN1cHBvcnRpbmcg R0VUL1BVVC9ERUxFVEUgZm9yDQo+Pj4+Pj4+Pj4+Pj4gICAgcmVzb3VyY2VzLCBhbmQgYWRkaW5n IGEgc2ltcGxlIGZvbGRlciBkZXNjcmlwdGlvbiBmb3JtYXQsDQo+Pj4+Pj4+Pj4+Pj4gICAgaXMg ZW5vdWdoIGZvciBtb3N0IGFwcGxpY2F0aW9ucy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ IE90aGVyIHRoYW4gdGhhdCwgdGhlIHJlbW90ZVN0b3JhZ2UgSW50ZXJuZXQtRHJhZnQgc3BlY2lm aWVzDQo+Pj4+Pj4+Pj4+Pj4gYSAqbG90KiBtb3JlIHRoYW4ganVzdCBob3cgZWFjaCBIVFRQIHZl cmIgc2hvdWxkIGJlaGF2ZToNCj4+Pj4+Pj4+Pj4+PiAqIHJlcXVpcmluZyBzdXBwb3J0IGZvciBP QXV0aCBpbXBsaWNpdC1ncmFudCBmbG93DQo+Pj4+Pj4+Pj4+Pj4gKiByZXF1aXJpbmcgRVRhZyBz dXBwb3J0IGFuZCBuZXN0ZWQgdmVyc2lvbmluZyAoaS5lLiB0aGUNCj4+Pj4+Pj4+Pj4+PiAgIGZv bGRlcidzIEVUYWcgY2hhbmdlcyBpZiBhbnl0aGluZyB3aXRoaW4gdGhhdCBmb2xkZXINCj4+Pj4+ Pj4+Pj4+PiAgIGNoYW5nZXMpDQo+Pj4+Pj4+Pj4+Pj4gKiByZXF1aXJpbmcgQ09SUyBoZWFkZXJz DQo+Pj4+Pj4+Pj4+Pj4gKiByZXF1aXJpbmcgYSBXZWJGaW5nZXIgYW5ub3VuY2VtZW50IGZvciBz ZXJ2aWNlIGRpc2NvdmVyeQ0KPj4+Pj4+Pj4+Pj4+ICAgSXQgd291bGQgYmUgZWFzeSB0byBhZGQg dGhlc2UgdGhyZWUgdGhpbmdzIG9uIHRvcCBvZg0KPj4+Pj4+Pj4+Pj4+ICAgV2ViREFWLCBpbnN0 ZWFkIG9mIHB1dHRpbmcgdGhlbSBvbiB0b3Agb2Ygb3VyIG1pbmltYWwNCj4+Pj4+Pj4+Pj4+PiAg IEdFVC9QVVQvREVMRVRFIEFQSSBkZWZpbml0aW9uLiBJbiBmYWN0LCB3ZSBjb3VsZCBwcm9iYWJs eQ0KPj4+Pj4+Pj4+Pj4+ICAgc2VwYXJhdGUgaXQgaW50byB0d28gSW50ZXJuZXQtRHJhZnRzOiBv bmUgZm9yIHRoZSAnUkVTVGZ1bA0KPj4+Pj4+Pj4+Pj4+ICAgZm9sZGVycycgQVBJIHdoaWNoIGlz IG91ciBzaW1wbGlmaWNhdGlvbiBvZiBXZWJEQVYsIGFuZCBhDQo+Pj4+Pj4+Pj4+Pj4gICBzZWNv bmQgb25lIGZvciBPQXV0aC9FVGFncy9DT1JTL1dlYkZpbmdlciBvbiB0b3Agb2YgZWl0aGVyDQo+ Pj4+Pj4+Pj4+Pj4gICBXZWJEQVYgb3IgJ1JFU1RmdWwgZm9sZGVycycgb3Igd2hhdGV2ZXIgb3Ro ZXIgSFRUUC1iYXNlZA0KPj4+Pj4+Pj4+Pj4+ICAgQVBJIHlvdSB3YW50Lg0KPj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBUaGVyZSBpcyBvbmUgcmVxdWlyZW1lbnQgdGhhdCBh bGwgc3luY2hyb25pc2VycyBuZWVkIHRvDQo+Pj4+Pj4+Pj4+PiBoYW5kbGU6IG1vdmluZyByZXNv dXJjZXMuIEluIHRoaXMgc3BlYyB0aGUgYWx0ZXJuYXRpdmUgb2YgYQ0KPj4+Pj4+Pj4+Pj4gV2Vi REFWIE1PVkUgaXMgbm90IHNwZWNpZmllZC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBJdCBp cyB0cnVlIHRoYXQgYSBNT1ZFIGNvdWxkIGJlIHJlcGxhY2VkIHdpdGggYSBERUxFVEUgKw0KPj4+ Pj4+Pj4+Pj4gVVBMT0FEIGJ1dCB0aGF0IGlzIG5vdCBhY2NlcHRhYmxlIGluIG1vc3QgY2FzZXMg ZHVlIHRvIHRoZQ0KPj4+Pj4+Pj4+Pj4gaW5lZmZpY2llbmN5IG9mIHN1Y2ggb3BlcmF0aW9uIChj cHUsIGJhbmR3aWR0aCBjb25zdW1wdGlvbg0KPj4+Pj4+Pj4+Pj4gLi4uKQ0KPj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+IElzIHRoZXJlIGEgcGxhbiB0byBzdXBwb3J0IHN1Y2ggYmFzaWMgZmVhdHVy ZT8NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBGcm9tIHRoZSBjdXJyZW50IHJlbW90ZVN0b3Jh Z2Ugc3BlYywgdGhlIG93bkNsb3VkIHN5bmMNCj4+Pj4+Pj4+Pj4+IHByb3RvY29sIGNhbiBiZSBp bXBsZW1lbnRlZC4gVGhlIG1pc3NpbmcgYml0IGlzIHRyYWNraW5nDQo+Pj4+Pj4+Pj4+PiB0aG9z ZSByZW1vdGUgbW92ZXMuDQo+Pj4+Pj4+Pj4+IEkgYWdyZWUgd2l0aCBIdWdvIHRoYXQgTU9WRSBp cyB1c2VmdWwsIHNvbWV0aW1lcyBpZiB5b3UganVzdA0KPj4+Pj4+Pj4+PiByZW5hbWUgYSBmaWxl IGl0IHdpbGwgYmUgcGVyZmVjdC4gQnV0IHRoZSBxdWVzdGlvbiBJIGhhdmUgaXMNCj4+Pj4+Pj4+ Pj4gdGhhdCB3aGV0aGVyIHdlIG5lZWQgdG8gbWFrZSB0d28gZG9jdW1lbnRzPyBNdWx0aXBsZSBj aG9pY2VzDQo+Pj4+Pj4+Pj4+IGlzIG5vdCBnb29kIGZvciBzdGFuZGFyZGl6YXRpb24uIEluIG15 IHZpZXcsIHdlYmRhdiBpcw0KPj4+Pj4+Pj4+PiBzb21ldGhpbmcgdGhhdCB3ZSBuZWVkIHRvIGhh dmUgYSB2ZXJ5IGNsZWFyIGRlY2lzaW9uIG9uDQo+Pj4+Pj4+Pj4+IHdoZXRoZXIgdG8gY29uc2lk ZXIgaXQgb3Igbm90Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBSZWdhcmRzLCBMaW5odWkNCj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQ2hlZXJzDQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+IE9uIFdlZCwgRGVjIDIsIDIwMTUgYXQgMTE6MjggQU0sIEh1Z28gR29ueqii bGV6IExhYnJhZG9yDQo+Pj4+Pj4+Pj4+Pj4gPGlldGZAaHVnby5sYWJrb2RlLmNvbT4gd3JvdGU6 DQo+Pj4+Pj4+Pj4+Pj4+IF9fDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IE9uIFdlZCwgRGVjIDIsIDIwMTUs IGF0IDExOjE4IEFNLCBMaW5odWkgU3VuIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4gSGkNCj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBPbiDW3Mj9LCAxMtTCIDIsIDIwMTUgYXQgMTc6NTYs IEh1Z28gR29ueqiibGV6IExhYnJhZG9yDQo+Pj4+Pj4+Pj4+Pj4+PiA8aWV0ZkBodWdvLmxhYmtv ZGUuY29tPiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwODoyMCBB TSwgTGluaHVpIFN1biB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gSGkNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gMjAxNS0xMi0wMiA1OjE0IEdNVCswODowMCBIdWdvIEdvbnqo omxleiBMYWJyYWRvcg0KPj4+Pj4+Pj4+Pj4+Pj4+PiA8aWV0ZkBodWdvLmxhYmtvZGUuY29tPjoN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhpLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IGZyb20gbXkgcG9pbnQgb2YgdmlldyB0aGUgcmVtb3RlU3RvcmFnZSBwcm9qZWN0DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBhZGRyZXNzZXMgYSBzdWJzZXQgb2YgdGhlIHVzZSBjYXNlcyBvZiB0aGU/ IFdlYkRBVg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3BlY2lmaWNhdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgbWFpbiBkaWZmZXJlbmNlIEkgY2FuIG9ic2VydmUg aXMgdGhhdCB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHNwZWNpZmljYXRpb24gaXMgYnVpbHQgb24g UkVTVCBpbnN0ZWFkIG9mIFhNTC1iYXNlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29tbXVuaWNhdGlv bi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIHBlcnNvbmFsbHkgbGlr ZSBtdWNoIG1vcmUgUkVTVCB0aGFuIFdlYkRBViBiZWNhdXNlIGl0DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBpcyBtb3JlIGRldmVsb3BlciBmcmllbmRseSBhbmQgaXQgaXMgZmFzdGVyIHRvIGRldmVsb3Au DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBNYXliZSB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgYmVjb21lcyB0 aGUgbmV4dCBXZWJEQVYgOikNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBI b3dldmVyLCB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgZG9lcyBub3QgcHJvdmlkZSBhIHdheQ0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4gb2Ygc3luY2hyb25pc2luZyBkYXRhLCB0aGlzIHRhc2sgaXMgZGVsZWdh dGVkIHRvIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gZGV2ZWxvcGVycy4gSXMgdGhlcmUgYSBwbGFu IHRvIHByb3ZpZGUgc3VjaCBmZWF0dXJlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiYXNlZCBvbiB0aGUg b3V0Y29tZSBvZiB0aGlzIGRyYWZ0Pw0KPj4+Pj4+Pj4+Pj4+Pj4+PiBJJ20gYSBsaXR0bGUgYml0 IGNvbmZ1c2VkIHdoeSB5b3Ugc2F5IHRoZSByZW1vdGVTdG9yYWdlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IGRvZXMgbm90IHByb3ZpZGUgdGhhdC4gSXMgdGhhdCBiZWNhdXNlIHJlbW90ZVN0b3JhZ2UNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4gZG9lcyBub3QgcGVyZm9ybSBsaWtlIGEgdHlwaWNhbCBzeW5jIHNlcnZp Y2VzIChlLmcuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGRyb3Bib3guLi4pIG9yIHlvdSBhcmUgc2F5aW5n IHNvbWV0aGluZyBlbHNlPw0KPj4+Pj4+Pj4+Pj4+Pj4+IFllcywgYmVjYXVzZSBpdCBkb2VzIG5v dCBvZmZlciBzeW5jaHJvbmlzYXRpb24NCj4+Pj4+Pj4+Pj4+Pj4+PiBjYXBhYmlsaXRpZXMuDQo+ Pj4+Pj4+Pj4+Pj4+PiBHb3QgaXQuIEFuZCBXaGF0IEkgYW0gd29uZGVyaW5nIGlzIHRoYXQgZG8g d2UgbmVlZCB0bw0KPj4+Pj4+Pj4+Pj4+Pj4gaW5jbHVkZSB0aG9zZSBjYXBhYmlsaXRpZXMgaW4g YSBiYXNlIHNwZWNpZmljYXRpb25zLiBTaW5jZQ0KPj4+Pj4+Pj4+Pj4+Pj4gaXQgaXMgaGFyZCB0 byBzdGFuZGFyZGl6ZSB0aGUgY2FwYWJpbGl0aWVzIGxpa2UgZGVkdXAgb3INCj4+Pj4+Pj4+Pj4+ Pj4+IGRlbHRhLiBNYXliZSBhIGJldHRlciB3YXkgaXMgdG8gZGVmaW5lIHRob3NlIGluIGEgc2Vw YXJhdGUNCj4+Pj4+Pj4+Pj4+Pj4+IHNwZWNpZmljYXRpb24sDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGFua3MgZm9yIGdpdmluZyB0aGVzZSBleGFtcGxlcyAt IHNvIGJ5ICdzeW5jaHJvbmlzYXRpb24NCj4+Pj4+Pj4+Pj4+PiBjYXBhYmlsaXRpZXMnIHlvdSBt ZWFuIDEpIGRlZHVwbGljYXRpb24gYW5kIDIpIGRlbHRhDQo+Pj4+Pj4+Pj4+Pj4gdXBkYXRlcz8g QW55dGhpbmcgZWxzZSBvciBpcyB0aGF0IGFuIGV4aGF1c3RpdmUgbGlzdD8NCj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IHNvbWV0aGluZyBsaWtlIGV4dGVuc2lvbnMuIEZvciBhIGJhc2Ug ZG9jdW1lbnQsIHdlIGp1c3QNCj4+Pj4+Pj4+Pj4+Pj4+IG5lZWQgdG8gZGVmaW5lIGhvdyB0byBw ZXJmb3JtIHN5bmMgb3BlcmF0aW9ucy4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4gWWVzLCBJIGFncmVlIHRoYXQgbWF5IGJlIGFuIGV4dGVuc2lvbiBvZiB0aGlz IGRyYWZ0IGNvdWxkDQo+Pj4+Pj4+Pj4+Pj4+IGhhbmRsZSB0aGUgc3luY2hyb25pc2F0aW9uIHBh cnQuDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBPdXIgSW50ZXJuZXQtRHJhZnQgaXMgaGVhdmlseSBmb2N1c2Vk IG9uIHRoZSB3b3JsZCB3aWRlIHdlYiwNCj4+Pj4+Pj4+Pj4+PiB3aG9zZSBVUkxzIGFyZSBub3Qg Y29udGVudC1hZGRyZXNzYWJsZSwgd2UgY2FuJ3QgY2hhbmdlDQo+Pj4+Pj4+Pj4+Pj4gdGhhdC4g U28gdGhhdCBhcmNoaXRlY3R1cmUgaXMgbm90IHZlcnkgZnJpZW5kbHkgdG8NCj4+Pj4+Pj4+Pj4+ PiBkZWR1cGxpY2F0aW9uLCBjb21wYXJlZCB0byBmb3IgaW5zdGFuY2UgQml0VG9ycmVudC4gQXMg eW91DQo+Pj4+Pj4+Pj4+Pj4gYWxyZWFkeSBzYWlkLCBkZXZlbG9wZXJzIGNhbiBzdGlsbCBkZWR1 cGUgb24gdGhlIHNlcnZlci1zaWRlDQo+Pj4+Pj4+Pj4+Pj4gd2hlbiBzdG9yaW5nIGJsb2JzIHRv IGRpc2ssIGFuZCBjYW4gYWxzbyBkZWR1cGUgb24gdGhlDQo+Pj4+Pj4+Pj4+Pj4gY2xpZW50IHNp ZGUgYmVmb3JlIGNyZWF0aW5nIHRoZSByZXNvdXJjZXMgdGhlIGNsaWVudA0KPj4+Pj4+Pj4+Pj4+ IHVwbG9hZHMuIEFzIGZhciBhcyBJIGtub3csIGRlbHRhIHVwZGF0ZXMgYXJlIG5vdCBzdXBwb3J0 ZWQNCj4+Pj4+Pj4+Pj4+PiBieSB0aGUgRVRhZyBzeXN0ZW0gLSB5b3UgY2Fubm90IGRvIGEgcmFu Z2UgcmVxdWVzdCB0byBmaW5kDQo+Pj4+Pj4+Pj4+Pj4gb3V0IGlmIGNlcnRhaW4gYnl0ZXMgd2l0 aGluIGEgZG9jdW1lbnQgaGF2ZSBjaGFuZ2VkLg0KPj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHRoZSBm b2xkZXIgc3lzdGVtIHdlIGRlZmluZSBkb2VzIGVuY291cmFnZSB5b3UsIGZvcg0KPj4+Pj4+Pj4+ Pj4+IGluc3RhbmNlIHdoZW4geW91IGRldmVsb3AgYSBUbyBEbyBMaXN0IGFwcCwgcHV0IGVhY2gg dGFzayBvbg0KPj4+Pj4+Pj4+Pj4+IGl0cyBvd24gZG9jdW1lbnQsIGFuZCB0aGVuIHF1ZXJ5IHRo ZSBmb2xkZXIgdG8gc2VlIHdoaWNoIG9mDQo+Pj4+Pj4+Pj4+Pj4gdGhlbSBjaGFuZ2VkLCBpbnN0 ZWFkIG9mIHB1dHRpbmcgdGhlbSBhbGwgaW4gb25lIGJpZw0KPj4+Pj4+Pj4+Pj4+IGRvY3VtZW50 IGFuZCByZXRyaWV2aW5nIHRoZSB3aG9sZSBkb2N1bWVudCBlYWNoIHRpbWUuDQo+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+PiBDaGVlcnMsIE1pY2hpZWwuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IEJUVywgSSB3YW50IHRvIGludHJvZHVjZSBDbGF3SU8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICho dHRwOi8vY2xhd2lvLmdpdGh1Yi5pb1sxXSksIGEgcmVzZWFyY2ggcHJvamVjdCB0bw0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4gYmVuY2htYXJrIGRpZmZlcmVudCBzeW5jaHJvbmlzYXRpb24gcHJvdG9jb2xz IGFnYWluc3QNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRpZmZlcmVudCBkYXRhIGJhY2tlbmRzIHdpdGgg c3BlY2lhbCBhdHRlbnRpb24gdG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHByb3ZpZGUgYSBjb21tb24g c3luYyBBUEkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gQSBjb21tb24g QVBJIGZvciBkaWZmZXJlbnQgc3luYyBwcm90b2NvbHMgaXMgYmVpbmcNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IGNyZWF0ZWQgYmFzZWQgb24gdGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpZWQgaW4gdGhpcw0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZHJhZnQgKGNvbnRyb2wgYW5kIGRhdGEgc2VydmVycykgYW5kIHRo ZQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBJIGNhbm5vdCBmaW5kIGEgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0 dXJlIGluIHRoaXMgZHJhZnQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEl0IHNlZW1zIHRoYXQgdGhleSBo YW5kbGUgbWV0YWRhdGEgYW5kIGNvbnRlbnQgZGF0YQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiB0b2dldGhl ciwganVzdCBsaWtlIGEgbm9ybWFsIHdlYiBzZXJ2aWNlLg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4gQ2xhd0lPIGlzIGZ1bGx5IGRpc3RyaWJ1dGVkLiBFdmVyeSBsb2dpY2FsIHVu aXQgaXMgYQ0KPj4+Pj4+Pj4+Pj4+Pj4+IGRpZmZlcmVudCBzZXJ2ZXIgdGhhbiBiZSBzY2FsZWQg b3V0LiBEYXRhIGFuZCBNZXRhZGF0YQ0KPj4+Pj4+Pj4+Pj4+Pj4+IGNoYW5uZWxzIGFyZSBpbmRl cGVuZGVudCBmcm9tIGVhY2ggb3RoZXIgYW5kIHJlc2lkZSBvbg0KPj4+Pj4+Pj4+Pj4+Pj4+IGRp ZmZlcmVudCBzZXJ2ZXJzLg0KPj4+Pj4+Pj4+Pj4+Pj4gVGhhdCBpcyB3aWRlbHkgZW1wbG95ZWQg aW4gcG9wdWxhciBzeW5jIHNlcnZpY2VzLiBBbmQgdGhhdA0KPj4+Pj4+Pj4+Pj4+Pj4gaXMgYWxz byBiZW5lZmljaWFsIHRvIHByaXZhY3kgdG8gc29tZSBleHRlbnQuIEJ1dCBpbiB0aGUNCj4+Pj4+ Pj4+Pj4+Pj4+IGNvbnRleHQgb2Ygc3luYyBpbiBicm93c2VyICh3aGljaCBpcyBtYWlubHkgY29u c2lkZXJlZCBpbg0KPj4+Pj4+Pj4+Pj4+Pj4gdGhlIHJlbW90ZVN0b3JhZ2UpLCBJIGRvbid0IGtu b3cgd2hldGhlciB0aGlzIGlzDQo+Pj4+Pj4+Pj4+Pj4+PiByZWFzb25hYmxlLiBCdXQgSSB0aGlu ayB3ZSBzaG91bGQgZGVwbG95IGRpc3RyaWJ1dGVkDQo+Pj4+Pj4+Pj4+Pj4+PiBhcmNoaXRlY3R1 cmUgYWx0aG91Z2ggaXQgd2lsbCBtYWtlIHRoaW5ncyBjb21wbGljYXRlZC4NCj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gT2YgY291cnNlLCB0aGUgcmVtb3RlU3Rv cmFnZSBpcyB0YXJnZXRlZCB0byBicm93c2Vycywgc28NCj4+Pj4+Pj4+Pj4+Pj4gc3luY2luZyBk b2VzIG5vdCBtYWtlIHRvbyBtdWNoIHNlbnNlIGluIHRoaXMgY2FzZS4gV2l0aCB0aGUNCj4+Pj4+ Pj4+Pj4+Pj4gcmlzZSBvZiBMaW51eCBjb250YWluZXIgbWljcm8tc2VydmljZSBiYXNlZCBhcmNo aXRlY3R1cmVzLA0KPj4+Pj4+Pj4+Pj4+PiB0aGUgZGVwbG95bWVudCBvZiA/c3VjaCBoaWdobHkg Y29tcGxleCBzeXN0ZW1zIHNob3VsZA0KPj4+Pj4+Pj4+Pj4+PiBiZWNvbWUgZWFzaWVyIGFuZCBm YXN0ZXIuDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEJlc3QsDQo+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEh1Z28NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IFJlZ2FyZHMsIExpbmh1aQ0KPj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gUmVnYXJkcywgTGluaHVpDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBvbmUgZnJvbSB0aGUgQ0VSTiBFT1MgcHJvamVjdCAobWFuYWdlbWVudCwg ZGlzayBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHF1ZXVlIHNlcnZlcnMpLg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBQaGFzZSBJIGhhcyBpbXBsZW1lbnRlZCB0aGUg b3duQ2xvdWQgU3luYyBQcm90b2NvbA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gYW5kIFBoYXNlIElJIHdp bGwgaW1wbGVtZW50IHRoZSBTZWFGaWxlIFN5bmMgUHJvdG9jb2wuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBUaGUgY2hvaWNlIG9mIHRoZXNlIHByb3RvY29scyBhbW9uZyBvdGhlcnMgaXMgYmVjYXVzZQ0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhleSBhcmUgcmVhbGx5IG9wcG9zZWQgdG8gZWFjaCBvdGhlciBp biB0ZXJtcyBvZg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3luY2luZyAoZGVsdGEgdnMgbm9uLWRlbHRh LCBzdGF0ZS1iYXNlZCB2cyBsb2cvZXZlbnQvZ2l0LQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmFzZWQg c3luYyChrSksIHNvIGZpbmRpbmcgYSBjb21tb24gYXBwcm9hY2ggaXMgbW9yZQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4gY2hhbGxlbmdpbmcuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4gUHJvdmlkaW5nIGEgYmFzZSBzcGVjaWZpY2F0aW9uL2FyY2hpdGVjdHVyZSB0byBtZWFzdXJl DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgZmVhc2liaWxpdHkgb2YgdGhpcyBkcmFmdCBpcyBvbmUg b2YgdGhlIG9iamVjdGl2ZXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG9mIHRoZSBwcm9qZWN0Lg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgYmVsaWV2ZSB0aGF0IHRoZSB3b3Jr IGJlaW5nIGRvbmUgaGVyZSBhbmQgaW4gQ2xhd0lPDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhcmUgc3Vw cGxlbWVudGFyeSB0byBlYWNoIG90aGVyIGFuZCBJIHRoaW5rIG11dHVhbA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4gY29sbGFib3JhdGlvbiBjb3VsZCBiZSBiZW5lZmljaWFsIGZvciBib3RoIHNpZGVzLg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEFsc28sIGlmIHRoZXJlIGlzIGlu dGVyZXN0LCB0aGUgcmVtb3RlU3RvcmFnZSBBUEkgY2FuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZSBh ZGRlZCB0byBDbGF3SU8uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gQmVz dCByZWdhcmRzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEh1Z28gR29u emFsZXogTGFicmFkb3INCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBPbiBU dWUsIERlYyAxLCAyMDE1LCBhdCAwOTowMCBQTSwgc3RvcmFnZXN5bmMtDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+PiByZXF1ZXN0QGlldGYub3JnIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiBTZW5kIFN0 b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4g PiBzdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4gPiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdl YiwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4gdmlzaXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyBvciwNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+ID4gdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9k eSAnaGVscCcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4gdG8/ID8gPyA/c3RvcmFnZXN5bmMtcmVxdWVz dEBpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiBZb3Ug Y2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+ID4gc3RvcmFnZXN5bmMtb3duZXJAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+ID4gV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0 IGxpbmUgc28gaXQgaXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4gbW9yZSBzcGVjaWZpYyB0aGFuICJS ZTogQ29udGVudHMgb2YgU3RvcmFnZXN5bmMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4gZGlnZXN0Li4u IiBUb2RheSdzIFRvcGljczoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ ID4xLiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZT8gPyBJbnRlcm5l dC0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID5EcmFmdD8gPyA/ID9hdmFpbGFibGUgKE1pY2hpZWwgZGUg Sm9uZyk/ID8gMi4gUmU6IE5ldw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPnZlcnNpb24gb2YgZHJhZnQt ZGVqb25nLXJlbW90ZXN0b3JhZ2UgSW50ZXJuZXQtRHJhZnQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID5h dmFpbGFibGUgKEdpaGFuIERpYXMpPyA/IDMuIFJlOiBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpv bmctDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+cmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdD8gPyA/ ID9hdmFpbGFibGUgKEZlaQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPlNvbmcpDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+PiA+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBTdG9yYWdlc3luY0Bp ZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+IEVtYWlsIGhhZCAzIGF0 dGFjaG1lbnRzOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiArIFtTdG9yYWdlc3luY10gTmV3IHZlcnNp b24gb2YgZHJhZnQtZGVqb25nLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiAgIHJlbW90ZXN0b3JhZ2Ug SW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxlPyA/MmsNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4gICAobWVz c2FnZS9yZmM4MjIpDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+ICsgUmU6IFtTdG9yYWdlc3luY10gTmV3 IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiAgIHJlbW90ZXN0 b3JhZ2UgSW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxlPyA/MWsNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4g ICAobWVzc2FnZS9yZmM4MjIpDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+ICsgUmU6IFtTdG9yYWdlc3lu Y10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiAgIHJl bW90ZXN0b3JhZ2UgSW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxlPyA/MmsNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+ID4gICAobWVzc2FnZS9yZmM4MjIpDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBTdG9yYWdlc3luY0BpZXRm Lm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zdG9yYWdlc3luYw0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0K Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ PiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QgU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPg0KPg0KPg0K PkxpbmtzOg0KPg0KPiAgMS4gaHR0cDovL2NsYXdpby5naXRodWIuaW8vDQo+ From nobody Thu Dec 3 17:55:49 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E6B1AD28D for ; Thu, 3 Dec 2015 17:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.878 X-Spam-Level: *** X-Spam-Status: No, score=3.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HsZGJUTbdir for ; Thu, 3 Dec 2015 17:55:45 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 89B421AD0CD for ; Thu, 3 Dec 2015 17:55:44 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygAHMQY782BW2hEHAA--.16942S2; Fri, 04 Dec 2015 09:58:20 +0800 (CST) Date: Fri, 4 Dec 2015 09:55:39 +0800 From: "Fei Song" To: =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= , "Michiel de Jong" References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> <5ca31214.2c3d.151672efcf7.Coremail.fsong@bjtu.edu.cn>, <1449136149.4121117.456781881.1C2D2EA8@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120409553914082222@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygAHMQY782BW2hEHAA--.16942S2 X-Coremail-Antispam: 1UD129KBjvAXoW3CFWxZF45Jw4rWw4DtrWxXrb_yoW8Zry3Xo WUJr17Jr48Jr1UXr1DJw1UJr1UJ3WUJr18JryUXr1UJr15tw1UJr1UJr1UXr45Jr1UXr1U Jr1UJr1UAryUJr18n29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUYg7k0a2IF6F4UM7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0 x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj4 1l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4U JVW0owA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwCFI7km07C267AKxVWUXVWUAwC20s026c 02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_ Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcS sGvfC2KfnxnUUI43ZEXa7IU8gB_UUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Linhui Sun , storagesync , =?gb2312?B?RnJhbj9vaXMgS29vbWFu?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 01:55:48 -0000 SGkgSHVnbywNCg0KSnVzdCBhIHF1aWNrIGNvbW1lbnQsIGNvbXBhcmlzb24gaXMgZ3JlYXQuIA0K RG8geW91IHRoaW5rIHdlIHNob3VsZCBsYXVuY2ggc29tZXRoaW5nIGxpa2UgIldlYkRBViB2cyBy ZW1vdGVTdG9yYWdlIiBvciAiYWR2YW50YWdlcyB2cyBkaXNhZHZhbnRhZ2VzIG9mIFdlYkRBViIu DQpvciBib3RoIG9mIHRoZW0/DQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KPldoYXQgaXMg dGhlIGJlc3Qgd2F5IHRvIGNvbGxlY3QgdGhlIGFkdmFudGFnZXMgYW5kIGRyYXdiYWNrcyBvZiBX ZWJEQVYNCj52cyByZW1vdGVTdG9yYWdlID8NCj4NCj5JIHByb3Bvc2UgdG8gY3JlYXRlIGEgR2l0 SHViIGluc3RlYWQgb2YvaW4gYWRkaXRpb24gdG8gc3BlY2lmeSB0aGUNCj5kaWZmZXJlbmNlcyBo ZXJlLiBJIHRoaW5rIGlzIGNsZWFyIHRvIHNob3cgdGhpcyBpbmZvIGluIHNvbWV0aGluZyBsaWtl IGENCj50YWJsZSBvbiBHaXRIdWIgaW5zdGVhZCBvZiBpbiBhIHNlcmllcyBvZiBtYWlsIG1lc3Nh Z2VzLg0KPg0KPkkgY2FuIGNyZWF0ZSB0aGUgcmVwbyBpZiBpdCBpcyBva2F5IGZvciB5b3UuDQo+ DQo+QmVzdCxIdWdvDQo+DQo+DQo+T24gVGh1LCBEZWMgMywgMjAxNSwgYXQgMTA6MzEgQU0sIGZz b25nQGJqdHUuZWR1LmNuIHdyb3RlOg0KPj4gR3JlYXSjoQ0KPj4NCj4+DQo+Pj4gLS0tLS3Urcq8 08q8/i0tLS0tICq3orz+yMs6KiAiTWljaGllbCBkZSBKb25nIiA8bWJkZWpvbmdAbW96aWxsYS5j b20+DQo+Pj4gKreiy83KsbzkOiogMjAxNcTqMTLUwjPI1SDQx8bay8QgKsrVvP7IyzoqIGZzb25n QGJqdHUuZWR1LmNuICqzrcvNOiogIkxpbmh1aSBTdW4iDQo+Pj4gPGxoLnN1bmxpbmhAZ21haWwu Y29tPiwgc3RvcmFnZXN5bmMgPHN0b3JhZ2VzeW5jQGlldGYub3JnPiwgZmtvb21hbg0KPj4+IDxm a29vbWFuQHR1eGVkLm5ldD4sICJIdWdvIEdvbnqoomxleiBMYWJyYWRvciIgPGlldGZAaHVnby5s YWJrb2RlLmNvbT4NCj4+PiAq1vfM4joqIFJlOiBbU3RvcmFnZXN5bmNdIFN0b3JhZ2VzeW5jIERp Z2VzdCwgVm9sIDUsIElzc3VlIDENCj4+Pg0KPj4+IFllcyEgSSdsbCBkaXNjdXNzIHdpdGggRnJh bmNvaXMgaG93IHdlIGNhbiBtYWtlIHRoZXNlIGJvdW5kYXJpZXMNCj4+PiBjbGVhcmVyLiBNYXli ZSB3ZSBjYW4gc3BsaXQgYWxvbmcgdGhlc2UgbGluZXM6DQo+Pj4gKiB1cGxvYWQvbWFuaXB1bGF0 ZS9xdWVyeS9kb3dubG9hZCBwcm90b2NvbCAoZS5nLiBXZWJEQVYgb3IgdGhlDQo+Pj4gICBHRVQv UFVUL0RFTEVURSBvcGVyYXRpb25zIHdlIGN1cnJlbnRseSBkZWZpbmUpDQo+Pj4gKiBDT1JTIG9y IG90aGVyIGNyb3NzLW9yaWdpbiBhY2Nlc3MgbWVjaGFuaXNtLCBPQVVUSCBvciBvdGhlciBhdXRo DQo+Pj4gICBtZWNoYW5pc20sIFdlYkZpbmdlciBvciBvdGhlciBkaXNjb3ZlcnkgbWVjaGFuaXNt LCBFVGFnIG9yIG90aGVyDQo+Pj4gICB2ZXJzaW9uaW5nIG1lY2hhbmlzbQ0KPj4+ICogY2h1bmtp bmcvZGVkdXBpbmcvZGVsdGEtdXBkYXRlcw0KPj4+DQo+Pj4gQW5kIHRoZSByZW1vdGVTdG9yYWdl IHNwZWMgc2hvdWxkIHByb2JhYmx5IG9ubHkgZGVmaW5lIHRoZQ0KPj4+IG1pZGRsZSBwYXJ0Lg0K Pj4+DQo+Pj4NCj4+PiBPbiBUaHUsIERlYyAzLCAyMDE1IGF0IDk6NDQgQU0sIDxmc29uZ0BianR1 LmVkdS5jbj4gd3JvdGU6DQo+Pj4+IEhpIE1pY2hpZWwgYW5kIExpbmh1aSwNCj4NCj4NCj4+Pj4g SSB0aGluayBpdCB3aWxsIGJlIGdvb2QgdG8gaGF2ZSBhIGJvdW5kYXJ5IGZvciB0aGlzIGRyYWZ0 IGFuZCBsZWF2ZQ0KPj4+PiBzb21lIHdvcmsgZm9yIHRoZSBhcHBsaWNhaXRvbiBsYXllcn4NCj4N Cj4NCj4+Pj4+IC0tLS0t1K3KvNPKvP4tLS0tLSAqt6K8/sjLOiogIk1pY2hpZWwgZGUgSm9uZyIg PG1iZGVqb25nQG1vemlsbGEuY29tPg0KPj4+Pj4gKreiy83KsbzkOiogMjAxNcTqMTLUwjLI1SDQ x8bayP0gKsrVvP7IyzoqICJMaW5odWkgU3VuIiA8bGguc3VubGluaEBnbWFpbC5jb20+DQo+Pj4+ PiAqs63LzToqIHN0b3JhZ2VzeW5jIDxzdG9yYWdlc3luY0BpZXRmLm9yZz4sIGZrb29tYW4NCj4+ Pj4+IDxma29vbWFuQHR1eGVkLm5ldD4sICJIdWdvIEdvbnqoomxleiBMYWJyYWRvciINCj4+Pj4+ IDxpZXRmQGh1Z28ubGFia29kZS5jb20+ICrW98ziOiogUmU6IFtTdG9yYWdlc3luY10gU3RvcmFn ZXN5bmMgRGlnZXN0LA0KPj4+Pj4gVm9sIDUsIElzc3VlIDENCj4+Pj4+DQo+Pj4+PiBBaCBzdXJl LCB0aGF0J3MgZW50aXJlbHkgYXBwcm9wcmlhdGUsIHJlbW90ZVN0b3JhZ2UgdHJlYXRzIGJvdGgg dGhlDQo+Pj4+PiBDb250ZW50LVR5cGUgaGVhZGVyIHZhbHVlIGFuZCB0aGUgYWN0dWFsIGJvZHkg b2YgYSBkb2N1bWVudCBhcw0KPj4+Pj4gb3BhcXVlIHN0cmluZ3Mgb2YgYnl0ZXMuIEl0IGRvZXNu J3QgImNhcmUiIGlmIHlvdSB1c2UgaXQgdG8gc3RvcmUNCj4+Pj4+IG9ubHkgZGF0YSBibG9ja3Mg dGhhdCBhcmUgY2h1bmtzIG9mIHNvbWV0aGluZyBlbHNlLiBGb3IgaW5zdGFuY2UsDQo+Pj4+PiB5 b3UgY291bGQgaGF2ZSBhIGZvbGRlciBvbiBhIHVzZXIncyBzdG9yYWdlIHRoYXQgY29udGFpbnMg b25seSBpbm9kZS0NCj4+Pj4+IGxpa2UgSlNPTi1kb2N1bWVudHMsIHdoaWNoIGxpc3QgdGhlIFVS THMgb2YgYmluYXJ5IGRvY3VtZW50cyB0aGF0DQo+Pj4+PiBtYWtlIHVwIDFLYiBibG9ja3Mgb2Yg dGhlIGFjdHVhbCBkYXRhLiBOaWNlIGZvciBkZWR1cGluZywgZGVsdGENCj4+Pj4+IHVwZGF0ZXMs IGFuZCBhbHNvIHJlbmFtaW5nIGZpbGVzIHdpdGhvdXQgcmV1cGxvYWRpbmcgdGhlaXIgY29udGVu dC4NCj4+Pj4+DQo+Pj4+PiBCdXQgeWVhaCwgdGhlIGFyZ3VtZW50IGlzIHRoYXQgKmhvdyogdG8g Y3JlYXRlIGFuZCBtYW5hZ2UgdGhlc2UNCj4+Pj4+IGNodW5rcywgaXMgdGhlbiBzdGlsbCBsZWZ0 IHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgKG9yIHRvDQo+Pj4+PiBhbm90aGVyIHNw ZWMgb24gdG9wIG9mIHRoZSByZW1vdGVTdG9yYWdlIHNwZWMpLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ PiBDaGVlcnMsIE1pY2hpZWwuDQo+Pj4+Pg0KPj4+Pj4gT24gV2VkLCBEZWMgMiwgMjAxNSBhdCAz OjI5IFBNLCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4NCj4+Pj4+IHdyb3RlOg0K Pj4+Pj4+IEhpDQo+Pj4+Pj4NCj4+Pj4+PiAyMDE1LTEyLTAyIDIyOjA1IEdNVCswODowMCBNaWNo aWVsIGRlIEpvbmcgPG1iZGVqb25nQG1vemlsbGEuY29tPjoNCj4+Pj4+Pj4gQ29vbCEgSSBjcmVh dGVkIGh0dHBzOi8vZ2l0aHViLmNvbS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzNw0KPj4+ Pj4+PiBhYm91dCB0aGUgbmVlZCBmb3I/IE1PVkUgdmVyYi4gQXBwbGljYXRpb24tbGV2ZWwgY2h1 bmtpbmcgaXMNCj4+Pj4+Pj4gcGFydGlhbGx5IHN1cHBvcnRlZCBieSBIVFRQIGl0c2VsZiB0aHJv dWdoIGBDb250ZW50LVJhbmdlYA0KPj4+Pj4+PiBoZWFkZXJzIChhbHRob3VnaCBpdCdzIG5vdCBj bGVhciB3aGV0aGVyIHRoZXNlIGFyZSBhbGxvd2VkIG9uIFBVVA0KPj4+Pj4+PiByZXF1ZXN0cyBh cyB3ZWxsIGFzIG9uIEdFVCByZXF1ZXN0cywgc2VlDQo+Pj4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNv bS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzMSkuIFRoZSBwcm9ibGVtIGlzDQo+Pj4+Pj4+ IHRoYXQgSFRUUCBkZWZpbmVzIHZlcnNpb25pbmcgYXQgdGhlIGRvY3VtZW50IGxldmVsLCB5b3Ug Y2Fubm90DQo+Pj4+Pj4+IGFzayBhIHNlcnZlciB0byBwcm9kdWNlIG9yIGNoZWNrIGFuIEVUYWcg Zm9yIGEgc3BlY2lmaWMgYnl0ZS0NCj4+Pj4+Pj4gcmFuZ2Ugb2YgYSBkb2N1bWVudCwgb25seSBm b3IgdGhlIGVudGlyZSBkb2N1bWVudC4NCj4+Pj4+Pg0KPj4+Pj4+IEFjdHVhbGx5IHdoYXQgSSdt IHNheWluZyBpcyBhIGNodW5raW5nIGJlZm9yZSB0cmFuc21pdHRpbmcgKHVzaW5nDQo+Pj4+Pj4g aHR0cCksIGluIHRoaXMgd2F5LCB0aGV5IGFyZSB0cmVhdGVkIGFzIGluZGl2aWR1YWwgZG9jdW1l bnRzIGZyb20NCj4+Pj4+PiB0aGUgc3RhbmRwb2ludCBvZiBodHRwLiBCdXQgSSBkb24ndCBrbm93 IHdoZXRoZXIgdGhpcyBpcw0KPj4+Pj4+IGFwcHJvcHJpYXRlIGZvciByZW1vdGVTdG9yYWdlLCBq dXN0IGEgY29tbWVudC4NCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2FyZHMsIExpbmh1aQ0KPj4+Pj4+Pg0K Pj4+Pj4+PiBBIGNvbXBhcmlzb24gZG9jdW1lbnQgc291bmRzIGdvb2QhIFNlZSBhbHNvDQo+Pj4+ Pj4+IGh0dHA6Ly93d3cuc2VydmljZWRlbnVhZ2VzLmZyL2VuL2dlbmVyaWMtc3RvcmFnZS1lY29z eXN0ZW0uDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IENoZWVycywgTWljaGllbC4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gV2VkLCBEZWMgMiwgMjAxNSBhdCAyOjMyIFBNLCBMaW5o dWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4NCj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+PiBU aGF0J3MgY29vbCBmb3IgbWUsIGEgc2VwYXJhdGUgc2VjdGlvbiBmb3IgdGhpcyBtaWdodCBtYWtl DQo+Pj4+Pj4+PiBzZW5zZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBbm90aGVyIHRoaW5nIGlzIGRv IHdlIG5lZWQgdG8gaW5jbHVkZSBhbiBhcHBsaWNhdGlvbi1sYXllcg0KPj4+Pj4+Pj4gY2h1bmtp bmcgaGVyZSAobm90IGp1c3QgZm9yIGEgYnJvd3NlciBzeW5jKSwgc2luY2UgaWYgd2Ugd2FudCB0 bw0KPj4+Pj4+Pj4gZnVydGhlciBleHRlbmQgb3RoZXIgY2FwYWJpbGl0aWVzIGl0IGlzIGVzc2Vu dGlhbC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBSZWdhcmRzLCBMaW5odWkNCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiAyMDE1LTEyLTAyIDIxOjAzIEdNVCswODowMCBIdWdvIEdvbnqoomxleiBMYWJyYWRvcg0K Pj4+Pj4+Pj4gPGlldGZAaHVnby5sYWJrb2RlLmNvbT46DQo+Pj4+Pj4+Pj4gX18NCj4+Pj4+Pj4+ PiBJIHByb3Bvc2UgdG8gY29tZSB1cCB3aXRoIGEgbGlzdCBvZiBhZHZhbnRhZ2VzIGFuZA0KPj4+ Pj4+Pj4+IGRpc2FkdmFudGFnZXMgb2YgdXNpbmcgV2ViREFWIGFuZCBjb21wYXJlIHRoZW0gYWdh aW5zdCBhDQo+Pj4+Pj4+Pj4gSlNPTi9SRVNUIGJhc2VkIGFwcHJvYWNoLCBsaWtlIHJlbW90ZVN0 b3JhZ2UuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBEb2VzIGl0IHNvdW5kIGdvb2QgPw0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwMTo1OSBQ TSwgTGluaHVpIFN1biB3cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g MjAxNS0xMi0wMiAyMDo0MyBHTVQrMDg6MDAgSHVnbyBHb256qKJsZXogTGFicmFkb3INCj4+Pj4+ Pj4+Pj4gPGlldGZAaHVnby5sYWJrb2RlLmNvbT46DQo+Pj4+Pj4+Pj4+PiBfXw0KPj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IE9u IFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjMwIFBNLCBNaWNoaWVsIGRlIEpvbmcgd3JvdGU6DQo+ Pj4+Pj4+Pj4+Pj4gSGkgYWxsISBUaGFua3MgZm9yIGFsbCB5b3VyIHJlYWN0aW9ucyB0byB0aGUg cmVtb3RlU3RvcmFnZQ0KPj4+Pj4+Pj4+Pj4+IEludGVybmV0LURyYWZ0Lg0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4gV2UgZ2V0IHRoZSBxdWVzdGlvbiBhYm91dCBXZWJEQVYgYSBsb3QsIGlu IHRoZSBuZXh0IHZlcnNpb24NCj4+Pj4+Pj4+Pj4+PiB3ZSBzaG91bGQgYWRkIGEgcmVtYXJrIGFi b3V0IGl0IGluIHRoZSBpbnRyby4gVGhlIGZvbGRlcg0KPj4+Pj4+Pj4+Pj4+IGRlc2NyaXB0aW9u cyByZXR1cm5lZCB3aGVuIHlvdSBHRVQgYSBVUkwgdGhhdCBlbmRzIHdpdGggYSAvDQo+Pj4+Pj4+ Pj4+Pj4gYXJlIGluZGVlZCBhIGRldmlhdGlvbiBmcm9tIHRoZSBYTUwgcmV0dXJuZWQgYnkgV2Vi REFWDQo+Pj4+Pj4+Pj4+Pj4gc2VydmVyLCBhbmQgdGhpcyBpcyBqdXN0IGJlY2F1c2Ugbm93YWRh eXMgSlNPTiBpcyBlYXNpZXIgdG8NCj4+Pj4+Pj4+Pj4+PiB1c2UgdGhhbiBYTUwgZm9yIGRldmVs b3BlcnMsIGJvdGggY2xpZW50LXNpZGUgYW5kIHNlcnZlci0NCj4+Pj4+Pj4+Pj4+PiBzaWRlLg0K Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBJIHRvdGFsbHkgYWdyZWUgaGVy ZSwgdGhpcyB3YXMgZ29pbmcgdG8gaGFwcGVuIHNvb24gb3IgbGF0ZXINCj4+Pj4+Pj4+Pj4+IGFu ZCBpdCBpcyByZWFsbHkgYXBwcmVjaWF0ZWQuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+PiBUaGUgZmFjdCB0aGF0IHdlIGRvbid0IHJlcXVpcmUgc2VydmVycyB0byBzdXBw b3J0IFdlYkRBVidzDQo+Pj4+Pj4+Pj4+Pj4gY3VzdG9tIHZlcmJzIGxpa2UgUFJPUFBBVENIIGV0 Yy4gaXMgZm9yIHRocmVlIHJlYXNvbnM6DQo+Pj4+Pj4+Pj4+Pj4gMSkgaXQncyBhIGxvdCBvZiB3 b3JrIHRvIGltcGxlbWVudCB0aGlzIHdpdGhvdXQgdXNpbmcgYW4NCj4+Pj4+Pj4+Pj4+PiAgICBl eGlzdGluZyBXZWJEQVYgbGlicmFyeQ0KPj4+Pj4+Pj4+Pj4+IDIpIGluIHByYWN0aWNlLCBhIGxv dCBvZiBXZWJEQVYgc2VydmVycyBnZXQgaXQgd3JvbmcsIG9yDQo+Pj4+Pj4+Pj4+Pj4gICAgZG9u J3QgaW1wbGVtZW50IGFsbCBvZiBXZWJEQVYuIEl0J3MgdmVyeSBhbm5veWluZyBmb3INCj4+Pj4+ Pj4+Pj4+PiAgICBjbGllbnQgaW1wbGVtZW50ZXJzIHRvIGhhdmUgdG8gZGVhbCB3aXRoIHNlcnZl cnMgdGhhdA0KPj4+Pj4+Pj4+Pj4+ICAgIGUuZy4gY2hvc2Ugbm90IHRvIGltcGxlbWVudCBMT0NL IGFuZCBVTkxPQ0suDQo+Pj4+Pj4+Pj4+Pj4gMykgd2UgZG9uJ3QgcmVhbGx5IG5lZWQgYWxsIHRo ZXNlIGFkdmFuY2VkIGZlYXR1cmVzIG9uIHRvcA0KPj4+Pj4+Pj4+Pj4+ICAgIG9mIHN0YW5kYXJk IEhUVFAsIGp1c3Qgc3VwcG9ydGluZyBHRVQvUFVUL0RFTEVURSBmb3INCj4+Pj4+Pj4+Pj4+PiAg ICByZXNvdXJjZXMsIGFuZCBhZGRpbmcgYSBzaW1wbGUgZm9sZGVyIGRlc2NyaXB0aW9uIGZvcm1h dCwNCj4+Pj4+Pj4+Pj4+PiAgICBpcyBlbm91Z2ggZm9yIG1vc3QgYXBwbGljYXRpb25zLg0KPj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gT3RoZXIgdGhhbiB0aGF0LCB0aGUgcmVtb3RlU3RvcmFn ZSBJbnRlcm5ldC1EcmFmdCBzcGVjaWZpZXMNCj4+Pj4+Pj4+Pj4+PiBhICpsb3QqIG1vcmUgdGhh biBqdXN0IGhvdyBlYWNoIEhUVFAgdmVyYiBzaG91bGQgYmVoYXZlOg0KPj4+Pj4+Pj4+Pj4+ICog cmVxdWlyaW5nIHN1cHBvcnQgZm9yIE9BdXRoIGltcGxpY2l0LWdyYW50IGZsb3cNCj4+Pj4+Pj4+ Pj4+PiAqIHJlcXVpcmluZyBFVGFnIHN1cHBvcnQgYW5kIG5lc3RlZCB2ZXJzaW9uaW5nIChpLmUu IHRoZQ0KPj4+Pj4+Pj4+Pj4+ICAgZm9sZGVyJ3MgRVRhZyBjaGFuZ2VzIGlmIGFueXRoaW5nIHdp dGhpbiB0aGF0IGZvbGRlcg0KPj4+Pj4+Pj4+Pj4+ICAgY2hhbmdlcykNCj4+Pj4+Pj4+Pj4+PiAq IHJlcXVpcmluZyBDT1JTIGhlYWRlcnMNCj4+Pj4+Pj4+Pj4+PiAqIHJlcXVpcmluZyBhIFdlYkZp bmdlciBhbm5vdW5jZW1lbnQgZm9yIHNlcnZpY2UgZGlzY292ZXJ5DQo+Pj4+Pj4+Pj4+Pj4gICBJ dCB3b3VsZCBiZSBlYXN5IHRvIGFkZCB0aGVzZSB0aHJlZSB0aGluZ3Mgb24gdG9wIG9mDQo+Pj4+ Pj4+Pj4+Pj4gICBXZWJEQVYsIGluc3RlYWQgb2YgcHV0dGluZyB0aGVtIG9uIHRvcCBvZiBvdXIg bWluaW1hbA0KPj4+Pj4+Pj4+Pj4+ICAgR0VUL1BVVC9ERUxFVEUgQVBJIGRlZmluaXRpb24uIElu IGZhY3QsIHdlIGNvdWxkIHByb2JhYmx5DQo+Pj4+Pj4+Pj4+Pj4gICBzZXBhcmF0ZSBpdCBpbnRv IHR3byBJbnRlcm5ldC1EcmFmdHM6IG9uZSBmb3IgdGhlICdSRVNUZnVsDQo+Pj4+Pj4+Pj4+Pj4g ICBmb2xkZXJzJyBBUEkgd2hpY2ggaXMgb3VyIHNpbXBsaWZpY2F0aW9uIG9mIFdlYkRBViwgYW5k IGENCj4+Pj4+Pj4+Pj4+PiAgIHNlY29uZCBvbmUgZm9yIE9BdXRoL0VUYWdzL0NPUlMvV2ViRmlu Z2VyIG9uIHRvcCBvZiBlaXRoZXINCj4+Pj4+Pj4+Pj4+PiAgIFdlYkRBViBvciAnUkVTVGZ1bCBm b2xkZXJzJyBvciB3aGF0ZXZlciBvdGhlciBIVFRQLWJhc2VkDQo+Pj4+Pj4+Pj4+Pj4gICBBUEkg eW91IHdhbnQuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFRoZXJlIGlz IG9uZSByZXF1aXJlbWVudCB0aGF0IGFsbCBzeW5jaHJvbmlzZXJzIG5lZWQgdG8NCj4+Pj4+Pj4+ Pj4+IGhhbmRsZTogbW92aW5nIHJlc291cmNlcy4gSW4gdGhpcyBzcGVjIHRoZSBhbHRlcm5hdGl2 ZSBvZiBhDQo+Pj4+Pj4+Pj4+PiBXZWJEQVYgTU9WRSBpcyBub3Qgc3BlY2lmaWVkLg0KPj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEl0IGlzIHRydWUgdGhhdCBhIE1PVkUgY291bGQgYmUgcmVwbGFj ZWQgd2l0aCBhIERFTEVURSArDQo+Pj4+Pj4+Pj4+PiBVUExPQUQgYnV0IHRoYXQgaXMgbm90IGFj Y2VwdGFibGUgaW4gbW9zdCBjYXNlcyBkdWUgdG8gdGhlDQo+Pj4+Pj4+Pj4+PiBpbmVmZmljaWVu Y3kgb2Ygc3VjaCBvcGVyYXRpb24gKGNwdSwgYmFuZHdpZHRoIGNvbnN1bXB0aW9uDQo+Pj4+Pj4+ Pj4+PiAuLi4pDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gSXMgdGhlcmUgYSBwbGFuIHRvIHN1 cHBvcnQgc3VjaCBiYXNpYyBmZWF0dXJlPw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEZyb20g dGhlIGN1cnJlbnQgcmVtb3RlU3RvcmFnZSBzcGVjLCB0aGUgb3duQ2xvdWQgc3luYw0KPj4+Pj4+ Pj4+Pj4gcHJvdG9jb2wgY2FuIGJlIGltcGxlbWVudGVkLiBUaGUgbWlzc2luZyBiaXQgaXMgdHJh Y2tpbmcNCj4+Pj4+Pj4+Pj4+IHRob3NlIHJlbW90ZSBtb3Zlcy4NCj4+Pj4+Pj4+Pj4gSSBhZ3Jl ZSB3aXRoIEh1Z28gdGhhdCBNT1ZFIGlzIHVzZWZ1bCwgc29tZXRpbWVzIGlmIHlvdSBqdXN0DQo+ Pj4+Pj4+Pj4+IHJlbmFtZSBhIGZpbGUgaXQgd2lsbCBiZSBwZXJmZWN0LiBCdXQgdGhlIHF1ZXN0 aW9uIEkgaGF2ZSBpcw0KPj4+Pj4+Pj4+PiB0aGF0IHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIHR3 byBkb2N1bWVudHM/IE11bHRpcGxlIGNob2ljZXMNCj4+Pj4+Pj4+Pj4gaXMgbm90IGdvb2QgZm9y IHN0YW5kYXJkaXphdGlvbi4gSW4gbXkgdmlldywgd2ViZGF2IGlzDQo+Pj4+Pj4+Pj4+IHNvbWV0 aGluZyB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIHZlcnkgY2xlYXIgZGVjaXNpb24gb24NCj4+Pj4+ Pj4+Pj4gd2hldGhlciB0byBjb25zaWRlciBpdCBvciBub3QuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IFJlZ2FyZHMsIExpbmh1aQ0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ PiBDaGVlcnMNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gT24gV2VkLCBEZWMgMiwgMjAxNSBh dCAxMToyOCBBTSwgSHVnbyBHb256qKJsZXogTGFicmFkb3INCj4+Pj4+Pj4+Pj4+PiA8aWV0ZkBo dWdvLmxhYmtvZGUuY29tPiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4gX18NCj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4gT24gV2VkLCBEZWMgMiwgMjAxNSwgYXQgMTE6MTggQU0sIExpbmh1aSBTdW4gd3JvdGU6DQo+ Pj4+Pj4+Pj4+Pj4+PiBIaQ0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IE9uINbcyP0s IDEy1MIgMiwgMjAxNSBhdCAxNzo1NiwgSHVnbyBHb256qKJsZXogTGFicmFkb3INCj4+Pj4+Pj4+ Pj4+Pj4+IDxpZXRmQGh1Z28ubGFia29kZS5jb20+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IE9uIFdlZCwg RGVjIDIsIDIwMTUsIGF0IDA4OjIwIEFNLCBMaW5odWkgU3VuIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+ Pj4+PiBIaQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+PiAyMDE1LTEyLTAyIDU6 MTQgR01UKzA4OjAwIEh1Z28gR29ueqiibGV6IExhYnJhZG9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IDxp ZXRmQGh1Z28ubGFia29kZS5jb20+Og0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gZnJvbSBteSBwb2ludCBvZiB2aWV3IHRoZSByZW1v dGVTdG9yYWdlIHByb2plY3QNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFkZHJlc3NlcyBhIHN1YnNldCBv ZiB0aGUgdXNlIGNhc2VzIG9mIHRoZT8gV2ViREFWDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzcGVjaWZp Y2F0aW9uLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBtYWluIGRp ZmZlcmVuY2UgSSBjYW4gb2JzZXJ2ZSBpcyB0aGF0IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3Bl Y2lmaWNhdGlvbiBpcyBidWlsdCBvbiBSRVNUIGluc3RlYWQgb2YgWE1MLWJhc2VkDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBjb21tdW5pY2F0aW9uLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IEkgcGVyc29uYWxseSBsaWtlIG11Y2ggbW9yZSBSRVNUIHRoYW4gV2ViREFWIGJlY2F1 c2UgaXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGlzIG1vcmUgZGV2ZWxvcGVyIGZyaWVuZGx5IGFuZCBp dCBpcyBmYXN0ZXIgdG8gZGV2ZWxvcC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE1heWJlIHRoZSByZW1v dGVTdG9yYWdlIEFQSSBiZWNvbWVzIHRoZSBuZXh0IFdlYkRBViA6KQ0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBkb2Vz IG5vdCBwcm92aWRlIGEgd2F5DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvZiBzeW5jaHJvbmlzaW5nIGRh dGEsIHRoaXMgdGFzayBpcyBkZWxlZ2F0ZWQgdG8gdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkZXZl bG9wZXJzLiBJcyB0aGVyZSBhIHBsYW4gdG8gcHJvdmlkZSBzdWNoIGZlYXR1cmUNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IGJhc2VkIG9uIHRoZSBvdXRjb21lIG9mIHRoaXMgZHJhZnQ/DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+IEknbSBhIGxpdHRsZSBiaXQgY29uZnVzZWQgd2h5IHlvdSBzYXkgdGhlIHJlbW90ZVN0 b3JhZ2UNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZG9lcyBub3QgcHJvdmlkZSB0aGF0LiBJcyB0aGF0IGJl Y2F1c2UgcmVtb3RlU3RvcmFnZQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBkb2VzIG5vdCBwZXJmb3JtIGxp a2UgYSB0eXBpY2FsIHN5bmMgc2VydmljZXMgKGUuZy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZHJvcGJv eC4uLikgb3IgeW91IGFyZSBzYXlpbmcgc29tZXRoaW5nIGVsc2U/DQo+Pj4+Pj4+Pj4+Pj4+Pj4g WWVzLCBiZWNhdXNlIGl0IGRvZXMgbm90IG9mZmVyIHN5bmNocm9uaXNhdGlvbg0KPj4+Pj4+Pj4+ Pj4+Pj4+IGNhcGFiaWxpdGllcy4NCj4+Pj4+Pj4+Pj4+Pj4+IEdvdCBpdC4gQW5kIFdoYXQgSSBh bSB3b25kZXJpbmcgaXMgdGhhdCBkbyB3ZSBuZWVkIHRvDQo+Pj4+Pj4+Pj4+Pj4+PiBpbmNsdWRl IHRob3NlIGNhcGFiaWxpdGllcyBpbiBhIGJhc2Ugc3BlY2lmaWNhdGlvbnMuIFNpbmNlDQo+Pj4+ Pj4+Pj4+Pj4+PiBpdCBpcyBoYXJkIHRvIHN0YW5kYXJkaXplIHRoZSBjYXBhYmlsaXRpZXMgbGlr ZSBkZWR1cCBvcg0KPj4+Pj4+Pj4+Pj4+Pj4gZGVsdGEuIE1heWJlIGEgYmV0dGVyIHdheSBpcyB0 byBkZWZpbmUgdGhvc2UgaW4gYSBzZXBhcmF0ZQ0KPj4+Pj4+Pj4+Pj4+Pj4gc3BlY2lmaWNhdGlv biwNCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFRoYW5rcyBmb3Ig Z2l2aW5nIHRoZXNlIGV4YW1wbGVzIC0gc28gYnkgJ3N5bmNocm9uaXNhdGlvbg0KPj4+Pj4+Pj4+ Pj4+IGNhcGFiaWxpdGllcycgeW91IG1lYW4gMSkgZGVkdXBsaWNhdGlvbiBhbmQgMikgZGVsdGEN Cj4+Pj4+Pj4+Pj4+PiB1cGRhdGVzPyBBbnl0aGluZyBlbHNlIG9yIGlzIHRoYXQgYW4gZXhoYXVz dGl2ZSBsaXN0Pw0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gc29tZXRoaW5nIGxpa2Ug ZXh0ZW5zaW9ucy4gRm9yIGEgYmFzZSBkb2N1bWVudCwgd2UganVzdA0KPj4+Pj4+Pj4+Pj4+Pj4g bmVlZCB0byBkZWZpbmUgaG93IHRvIHBlcmZvcm0gc3luYyBvcGVyYXRpb25zLg0KPj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBZZXMsIEkgYWdyZWUgdGhhdCBtYXkg YmUgYW4gZXh0ZW5zaW9uIG9mIHRoaXMgZHJhZnQgY291bGQNCj4+Pj4+Pj4+Pj4+Pj4gaGFuZGxl IHRoZSBzeW5jaHJvbmlzYXRpb24gcGFydC4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IE91ciBJbnRlcm5ldC1E cmFmdCBpcyBoZWF2aWx5IGZvY3VzZWQgb24gdGhlIHdvcmxkIHdpZGUgd2ViLA0KPj4+Pj4+Pj4+ Pj4+IHdob3NlIFVSTHMgYXJlIG5vdCBjb250ZW50LWFkZHJlc3NhYmxlLCB3ZSBjYW4ndCBjaGFu Z2UNCj4+Pj4+Pj4+Pj4+PiB0aGF0LiBTbyB0aGF0IGFyY2hpdGVjdHVyZSBpcyBub3QgdmVyeSBm cmllbmRseSB0bw0KPj4+Pj4+Pj4+Pj4+IGRlZHVwbGljYXRpb24sIGNvbXBhcmVkIHRvIGZvciBp bnN0YW5jZSBCaXRUb3JyZW50LiBBcyB5b3UNCj4+Pj4+Pj4+Pj4+PiBhbHJlYWR5IHNhaWQsIGRl dmVsb3BlcnMgY2FuIHN0aWxsIGRlZHVwZSBvbiB0aGUgc2VydmVyLXNpZGUNCj4+Pj4+Pj4+Pj4+ PiB3aGVuIHN0b3JpbmcgYmxvYnMgdG8gZGlzaywgYW5kIGNhbiBhbHNvIGRlZHVwZSBvbiB0aGUN Cj4+Pj4+Pj4+Pj4+PiBjbGllbnQgc2lkZSBiZWZvcmUgY3JlYXRpbmcgdGhlIHJlc291cmNlcyB0 aGUgY2xpZW50DQo+Pj4+Pj4+Pj4+Pj4gdXBsb2Fkcy4gQXMgZmFyIGFzIEkga25vdywgZGVsdGEg dXBkYXRlcyBhcmUgbm90IHN1cHBvcnRlZA0KPj4+Pj4+Pj4+Pj4+IGJ5IHRoZSBFVGFnIHN5c3Rl bSAtIHlvdSBjYW5ub3QgZG8gYSByYW5nZSByZXF1ZXN0IHRvIGZpbmQNCj4+Pj4+Pj4+Pj4+PiBv dXQgaWYgY2VydGFpbiBieXRlcyB3aXRoaW4gYSBkb2N1bWVudCBoYXZlIGNoYW5nZWQuDQo+Pj4+ Pj4+Pj4+Pj4gSG93ZXZlciwgdGhlIGZvbGRlciBzeXN0ZW0gd2UgZGVmaW5lIGRvZXMgZW5jb3Vy YWdlIHlvdSwgZm9yDQo+Pj4+Pj4+Pj4+Pj4gaW5zdGFuY2Ugd2hlbiB5b3UgZGV2ZWxvcCBhIFRv IERvIExpc3QgYXBwLCBwdXQgZWFjaCB0YXNrIG9uDQo+Pj4+Pj4+Pj4+Pj4gaXRzIG93biBkb2N1 bWVudCwgYW5kIHRoZW4gcXVlcnkgdGhlIGZvbGRlciB0byBzZWUgd2hpY2ggb2YNCj4+Pj4+Pj4+ Pj4+PiB0aGVtIGNoYW5nZWQsIGluc3RlYWQgb2YgcHV0dGluZyB0aGVtIGFsbCBpbiBvbmUgYmln DQo+Pj4+Pj4+Pj4+Pj4gZG9jdW1lbnQgYW5kIHJldHJpZXZpbmcgdGhlIHdob2xlIGRvY3VtZW50 IGVhY2ggdGltZS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IENoZWVycywgTWljaGllbC4N Cj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gQlRXLCBJIHdhbnQgdG8gaW50cm9kdWNlIENsYXdJ Tw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gKGh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvWzFdKSwgYSByZXNl YXJjaCBwcm9qZWN0IHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZW5jaG1hcmsgZGlmZmVyZW50IHN5 bmNocm9uaXNhdGlvbiBwcm90b2NvbHMgYWdhaW5zdA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gZGlmZmVy ZW50IGRhdGEgYmFja2VuZHMgd2l0aCBzcGVjaWFsIGF0dGVudGlvbiB0bw0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4gcHJvdmlkZSBhIGNvbW1vbiBzeW5jIEFQSS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBBIGNvbW1vbiBBUEkgZm9yIGRpZmZlcmVudCBzeW5jIHByb3RvY29scyBp cyBiZWluZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gY3JlYXRlZCBiYXNlZCBvbiB0aGUgYXJjaGl0ZWN0 dXJlIHNwZWNpZmllZCBpbiB0aGlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkcmFmdCAoY29udHJvbCBh bmQgZGF0YSBzZXJ2ZXJzKSBhbmQgdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgY2Fubm90IGZpbmQg YSBkaXN0cmlidXRlZCBhcmNoaXRlY3R1cmUgaW4gdGhpcyBkcmFmdC4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gSXQgc2VlbXMgdGhhdCB0aGV5IGhhbmRsZSBtZXRhZGF0YSBhbmQgY29udGVudCBkYXRhDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+IHRvZ2V0aGVyLCBqdXN0IGxpa2UgYSBub3JtYWwgd2ViIHNlcnZpY2Uu DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBDbGF3SU8gaXMgZnVsbHkgZGlzdHJp YnV0ZWQuIEV2ZXJ5IGxvZ2ljYWwgdW5pdCBpcyBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZGlmZmVyZW50 IHNlcnZlciB0aGFuIGJlIHNjYWxlZCBvdXQuIERhdGEgYW5kIE1ldGFkYXRhDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gY2hhbm5lbHMgYXJlIGluZGVwZW5kZW50IGZyb20gZWFjaCBvdGhlciBhbmQgcmVzaWRl IG9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZGlmZmVyZW50IHNlcnZlcnMuDQo+Pj4+Pj4+Pj4+Pj4+PiBU aGF0IGlzIHdpZGVseSBlbXBsb3llZCBpbiBwb3B1bGFyIHN5bmMgc2VydmljZXMuIEFuZCB0aGF0 DQo+Pj4+Pj4+Pj4+Pj4+PiBpcyBhbHNvIGJlbmVmaWNpYWwgdG8gcHJpdmFjeSB0byBzb21lIGV4 dGVudC4gQnV0IGluIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4gY29udGV4dCBvZiBzeW5jIGluIGJyb3dz ZXIgKHdoaWNoIGlzIG1haW5seSBjb25zaWRlcmVkIGluDQo+Pj4+Pj4+Pj4+Pj4+PiB0aGUgcmVt b3RlU3RvcmFnZSksIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMgaXMNCj4+Pj4+Pj4+Pj4+Pj4+ IHJlYXNvbmFibGUuIEJ1dCBJIHRoaW5rIHdlIHNob3VsZCBkZXBsb3kgZGlzdHJpYnV0ZWQNCj4+ Pj4+Pj4+Pj4+Pj4+IGFyY2hpdGVjdHVyZSBhbHRob3VnaCBpdCB3aWxsIG1ha2UgdGhpbmdzIGNv bXBsaWNhdGVkLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBP ZiBjb3Vyc2UsIHRoZSByZW1vdGVTdG9yYWdlIGlzIHRhcmdldGVkIHRvIGJyb3dzZXJzLCBzbw0K Pj4+Pj4+Pj4+Pj4+PiBzeW5jaW5nIGRvZXMgbm90IG1ha2UgdG9vIG11Y2ggc2Vuc2UgaW4gdGhp cyBjYXNlLiBXaXRoIHRoZQ0KPj4+Pj4+Pj4+Pj4+PiByaXNlIG9mIExpbnV4IGNvbnRhaW5lciBt aWNyby1zZXJ2aWNlIGJhc2VkIGFyY2hpdGVjdHVyZXMsDQo+Pj4+Pj4+Pj4+Pj4+IHRoZSBkZXBs b3ltZW50IG9mID9zdWNoIGhpZ2hseSBjb21wbGV4IHN5c3RlbXMgc2hvdWxkDQo+Pj4+Pj4+Pj4+ Pj4+IGJlY29tZSBlYXNpZXIgYW5kIGZhc3Rlci4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4gQmVzdCwNCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gSHVn bw0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gUmVnYXJkcywg TGluaHVpDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ PiBSZWdhcmRzLCBMaW5odWkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG9uZSBmcm9tIHRoZSBDRVJOIEVP UyBwcm9qZWN0IChtYW5hZ2VtZW50LCBkaXNrIGFuZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gcXVldWUg c2VydmVycykuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIFBoYXNl IEkgaGFzIGltcGxlbWVudGVkIHRoZSBvd25DbG91ZCBTeW5jIFByb3RvY29sDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBhbmQgUGhhc2UgSUkgd2lsbCBpbXBsZW1lbnQgdGhlIFNlYUZpbGUgU3luYyBQcm90 b2NvbC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBjaG9pY2Ugb2YgdGhlc2UgcHJvdG9jb2xzIGFt b25nIG90aGVycyBpcyBiZWNhdXNlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGV5IGFyZSByZWFsbHkg b3Bwb3NlZCB0byBlYWNoIG90aGVyIGluIHRlcm1zIG9mDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzeW5j aW5nIChkZWx0YSB2cyBub24tZGVsdGEsIHN0YXRlLWJhc2VkIHZzIGxvZy9ldmVudC9naXQtDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBiYXNlZCBzeW5jIKGtKSwgc28gZmluZGluZyBhIGNvbW1vbiBhcHBy b2FjaCBpcyBtb3JlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjaGFsbGVuZ2luZy4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBQcm92aWRpbmcgYSBiYXNlIHNwZWNpZmljYXRpb24v YXJjaGl0ZWN0dXJlIHRvIG1lYXN1cmUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBmZWFzaWJpbGl0 eSBvZiB0aGlzIGRyYWZ0IGlzIG9uZSBvZiB0aGUgb2JqZWN0aXZlcw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4gb2YgdGhlIHByb2plY3QuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4g SSBiZWxpZXZlIHRoYXQgdGhlIHdvcmsgYmVpbmcgZG9uZSBoZXJlIGFuZCBpbiBDbGF3SU8NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGFyZSBzdXBwbGVtZW50YXJ5IHRvIGVhY2ggb3RoZXIgYW5kIEkgdGhp bmsgbXV0dWFsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjb2xsYWJvcmF0aW9uIGNvdWxkIGJlIGJlbmVm aWNpYWwgZm9yIGJvdGggc2lkZXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4gQWxzbywgaWYgdGhlcmUgaXMgaW50ZXJlc3QsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBjYW4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJlIGFkZGVkIHRvIENsYXdJTy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4gSHVnbyBHb256YWxleiBMYWJyYWRvcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0IDA5OjAwIFBNLCBzdG9y YWdlc3luYy0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlcXVlc3RAaWV0Zi5vcmcgd3JvdGU6DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+PiA+IFNlbmQgU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25z IHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+IHN0b3JhZ2VzeW5jQGlldGYub3JnDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+PiA+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmli ZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiB2aXNpdA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 b3JhZ2VzeW5jIG9yLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiB2aWEgZW1haWwsIHNlbmQgYSBtZXNz YWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiB0bz8g PyA/ID9zdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+PiA+IFlvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUg bGlzdCBhdA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiBzdG9yYWdlc3luYy1vd25lckBpZXRmLm9yZw0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiBXaGVuIHJlcGx5aW5nLCBw bGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4g PiBtb3JlIHNwZWNpZmljIHRoYW4gIlJlOiBDb250ZW50cyBvZiBTdG9yYWdlc3luYw0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4gPiBkaWdlc3QuLi4iIFRvZGF5J3MgVG9waWNzOg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4gPg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPjEuIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1y ZW1vdGVzdG9yYWdlPyA/IEludGVybmV0LQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPkRyYWZ0PyA/ID8g P2F2YWlsYWJsZSAoTWljaGllbCBkZSBKb25nKT8gPyAyLiBSZTogTmV3DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+PiA+dmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFm dA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPmF2YWlsYWJsZSAoR2loYW4gRGlhcyk/ID8gMy4gUmU6IE5l dyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID5yZW1vdGVzdG9y YWdlIEludGVybmV0LURyYWZ0PyA/ID8gP2F2YWlsYWJsZSAoRmVpDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ PiA+U29uZykNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4gU3RvcmFnZXN5bmMgbWFp bGluZyBsaXN0IFN0b3JhZ2VzeW5jQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+ID4gRW1haWwgaGFkIDMgYXR0YWNobWVudHM6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+ICsg W1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+PiA+ICAgcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdCBhdmFpbGFibGU/ID8yaw0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4gPiAgIChtZXNzYWdlL3JmYzgyMikNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID4g KyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiA+ICAgcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdCBhdmFpbGFibGU/ID8x aw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiAgIChtZXNzYWdlL3JmYzgyMikNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+ID4gKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+PiA+ICAgcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdCBhdmFpbGFi bGU/ID8yaw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPiAgIChtZXNzYWdlL3JmYzgyMikNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gU3RvcmFnZXN5bmMgbWFpbGlu ZyBsaXN0IFN0b3JhZ2VzeW5jQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBTdG9yYWdl c3luY0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0b3JhZ2VzeW5jDQo+DQo+DQo+DQo+TGlua3M6DQo+DQo+ICAxLiBodHRwOi8vY2xhd2lvLmdp dGh1Yi5pby8NCj4= From nobody Thu Dec 3 18:06:27 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063491AD377 for ; Thu, 3 Dec 2015 18:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.478 X-Spam-Level: **** X-Spam-Status: No, score=4.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqjVUdsDp4fA for ; Thu, 3 Dec 2015 18:06:24 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 720C61AD375 for ; Thu, 3 Dec 2015 18:06:23 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygB3Wjy59WBWrxQHAA--.15931S2; Fri, 04 Dec 2015 10:08:57 +0800 (CST) Date: Fri, 4 Dec 2015 10:06:18 +0800 From: "Fei Song" To: "Linhui Sun" , =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <1449060218.3721231.455737161.5D657D6D@webmail.messagingengine.com> <1449061417.3729762.455755681.08D95D5B@webmail.messagingengine.com> <52aa75c9.2c03.15167034cd6.Coremail.fsong@bjtu.edu.cn> <5ca31214.2c3d.151672efcf7.Coremail.fsong@bjtu.edu.cn> <1449136149.4121117.456781881.1C2D2EA8@webmail.messagingengine.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120410061804681024@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygB3Wjy59WBWrxQHAA--.15931S2 X-Coremail-Antispam: 1UD129KBjvAXoW3ur4xuFWrtryrur1DGr18Grg_yoW8Wr1xWo WfZrs2kw4xKr18WF4qkasrCa97Wa4Ykw18Aryqqw1UCFnYqaya9w4UCw4kWFZayr1UWr4U Ja48Xay3ZFWvqa4fn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUYy7k0a2IF6F4UM7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0 x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj4 1l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4U JVW0owA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r12 6r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7Yx BIdaVFxhVjvjDU0xZFpf9x07j0OJOUUUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync , Michiel de Jong , =?gb2312?B?RnJhbj9vaXMgS29vbWFu?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 02:06:27 -0000 R29vZCBzdWdnZXN0aW9uLCAiUHJvcyBhbmQgQ29ucyIgaXMgbm90IGEgZ29vZCBvcHRpb24gZm9y IGRpc2N1c3Npb24gaW4gY3VycmVudCBwaGFzZS4NCg0KU28gdW50aWwgbm93IHdlIGhhdmUNCjEu IFdoZXRoZXIgaXQgaXMgc3VpdGFibGUgdG8gYnVpbGQgb24gV2ViREFWDQoyLiBXZWJEQVYgdnMg cmVtb3RlU3RvcmFnZQ0KMy4gQWR2YW50YWdlcyB2cyBkaXNhZHZhbnRhZ2VzIG9mIFdlYkRBVg0K TWF5YmUgb3B0aW9uIDEgaXMgdGhlIHJlc3VsdCBvZiBvcHRpb24gMywganVzdCBsaWtlICJQcm9z IGFuZCBDb25zIiBpcyB0aGUgcmVzdWx0IG9mIG9wdGlvbiAxLg0KDQpXaGF0IGRvIHlvdSB0aGlu aywgSHVnbz8NCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+MjAxNS0xMi0wMyAxNzo0OSBH TVQrMDg6MDAgSHVnbyBHb256qKJsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT46 DQo+DQo+PiBXaGF0IGlzIHRoZSBiZXN0IHdheSB0byBjb2xsZWN0IHRoZSBhZHZhbnRhZ2VzIGFu ZCBkcmF3YmFja3Mgb2YgV2ViREFWIHZzDQo+PiByZW1vdGVTdG9yYWdlID8NCj4+DQo+PiBJIHBy b3Bvc2UgdG8gY3JlYXRlIGEgR2l0SHViIGluc3RlYWQgb2YvaW4gYWRkaXRpb24gdG8gc3BlY2lm eSB0aGUNCj4+IGRpZmZlcmVuY2VzIGhlcmUuIEkgdGhpbmsgaXMgY2xlYXIgdG8gc2hvdyB0aGlz IGluZm8gaW4gc29tZXRoaW5nIGxpa2UgYQ0KPj4gdGFibGUgb24gR2l0SHViIGluc3RlYWQgb2Yg aW4gYSBzZXJpZXMgb2YgbWFpbCBtZXNzYWdlcy4NCj4+DQo+VGhhdCBpcyBhIGdvb2Qgd2F5IHRv IGRpc2N1c3MsIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCBub3Qgc2F5aW5nIHRoZSBwcm9zIG9yDQo+ Y29ucywgaXQncyBqdXN0IGFib3V0IGFwcGxpY2FiaWxpdHkgaGVyZS4gQSBkaXNjdXNzaW9uIGFi b3V0IHdoZXRoZXIgaXQgaXMNCj5zdWl0YWJsZSB0byBidWlsZCBvbiBXZWJEQVYgaXMgYmV0dGVy Lg0KPg0KPlJlZ2FyZHMsDQo+TGluaHVpDQo+DQo+Pg0KPj4gSSBjYW4gY3JlYXRlIHRoZSByZXBv IGlmIGl0IGlzIG9rYXkgZm9yIHlvdS4NCj4+DQo+PiBCZXN0LEh1Z28NCj4+DQo+Pg0KPj4gT24g VGh1LCBEZWMgMywgMjAxNSwgYXQgMTA6MzEgQU0sIGZzb25nQGJqdHUuZWR1LmNuIHdyb3RlOg0K Pj4NCj4+IEdyZWF0o6ENCj4+DQo+Pg0KPj4NCj4+IC0tLS0t1K3KvNPKvP4tLS0tLQ0KPj4gKrei vP7IyzoqICJNaWNoaWVsIGRlIEpvbmciIDxtYmRlam9uZ0Btb3ppbGxhLmNvbT4NCj4+ICq3osvN yrG85DoqIDIwMTXE6jEy1MIzyNUg0MfG2svEDQo+PiAqytW8/sjLOiogZnNvbmdAYmp0dS5lZHUu Y24NCj4+ICqzrcvNOiogIkxpbmh1aSBTdW4iIDxsaC5zdW5saW5oQGdtYWlsLmNvbT4sIHN0b3Jh Z2VzeW5jIDwNCj4+IHN0b3JhZ2VzeW5jQGlldGYub3JnPiwgZmtvb21hbiA8Zmtvb21hbkB0dXhl ZC5uZXQ+LCAiSHVnbyBHb256qKJsZXoNCj4+IExhYnJhZG9yIiA8aWV0ZkBodWdvLmxhYmtvZGUu Y29tPg0KPj4gKtb3zOI6KiBSZTogW1N0b3JhZ2VzeW5jXSBTdG9yYWdlc3luYyBEaWdlc3QsIFZv bCA1LCBJc3N1ZSAxDQo+Pg0KPj4gWWVzISBJJ2xsIGRpc2N1c3Mgd2l0aCBGcmFuY29pcyBob3cg d2UgY2FuIG1ha2UgdGhlc2UgYm91bmRhcmllcyBjbGVhcmVyLg0KPj4gTWF5YmUgd2UgY2FuIHNw bGl0IGFsb25nIHRoZXNlIGxpbmVzOg0KPj4gKiB1cGxvYWQvbWFuaXB1bGF0ZS9xdWVyeS9kb3du bG9hZCBwcm90b2NvbCAoZS5nLiBXZWJEQVYgb3IgdGhlDQo+PiBHRVQvUFVUL0RFTEVURSBvcGVy YXRpb25zIHdlIGN1cnJlbnRseSBkZWZpbmUpDQo+PiAqIENPUlMgb3Igb3RoZXIgY3Jvc3Mtb3Jp Z2luIGFjY2VzcyBtZWNoYW5pc20sIE9BVVRIIG9yIG90aGVyIGF1dGgNCj4+IG1lY2hhbmlzbSwg V2ViRmluZ2VyIG9yIG90aGVyIGRpc2NvdmVyeSBtZWNoYW5pc20sIEVUYWcgb3Igb3RoZXIgdmVy c2lvbmluZw0KPj4gbWVjaGFuaXNtDQo+PiAqIGNodW5raW5nL2RlZHVwaW5nL2RlbHRhLXVwZGF0 ZXMNCj4+DQo+PiBBbmQgdGhlIHJlbW90ZVN0b3JhZ2Ugc3BlYyBzaG91bGQgcHJvYmFibHkgb25s eSBkZWZpbmUgdGhlIG1pZGRsZSBwYXJ0Lg0KPj4NCj4+DQo+PiBPbiBUaHUsIERlYyAzLCAyMDE1 IGF0IDk6NDQgQU0sIDxmc29uZ0BianR1LmVkdS5jbj4gd3JvdGU6DQo+Pg0KPj4gSGkgTWljaGll bCBhbmQgTGluaHVpLA0KPj4NCj4+IEkgdGhpbmsgaXQgd2lsbCBiZSBnb29kIHRvIGhhdmUgYSBi b3VuZGFyeSBmb3IgdGhpcyBkcmFmdCBhbmQgbGVhdmUgc29tZQ0KPj4gd29yayBmb3IgdGhlIGFw cGxpY2FpdG9uIGxheWVyfg0KPj4NCj4+IC0tLS0t1K3KvNPKvP4tLS0tLQ0KPj4gKreivP7Iyzoq ICJNaWNoaWVsIGRlIEpvbmciIDxtYmRlam9uZ0Btb3ppbGxhLmNvbT4NCj4+ICq3osvNyrG85Doq IDIwMTXE6jEy1MIyyNUg0MfG2sj9DQo+PiAqytW8/sjLOiogIkxpbmh1aSBTdW4iIDxsaC5zdW5s aW5oQGdtYWlsLmNvbT4NCj4+ICqzrcvNOiogc3RvcmFnZXN5bmMgPHN0b3JhZ2VzeW5jQGlldGYu b3JnPiwgZmtvb21hbiA8Zmtvb21hbkB0dXhlZC5uZXQ+LA0KPj4gIkh1Z28gR29ueqiibGV6IExh YnJhZG9yIiA8aWV0ZkBodWdvLmxhYmtvZGUuY29tPg0KPj4gKtb3zOI6KiBSZTogW1N0b3JhZ2Vz eW5jXSBTdG9yYWdlc3luYyBEaWdlc3QsIFZvbCA1LCBJc3N1ZSAxDQo+Pg0KPj4gQWggc3VyZSwg dGhhdCdzIGVudGlyZWx5IGFwcHJvcHJpYXRlLCByZW1vdGVTdG9yYWdlIHRyZWF0cyBib3RoIHRo ZQ0KPj4gQ29udGVudC1UeXBlIGhlYWRlciB2YWx1ZSBhbmQgdGhlIGFjdHVhbCBib2R5IG9mIGEg ZG9jdW1lbnQgYXMgb3BhcXVlDQo+PiBzdHJpbmdzIG9mIGJ5dGVzLiBJdCBkb2Vzbid0ICJjYXJl IiBpZiB5b3UgdXNlIGl0IHRvIHN0b3JlIG9ubHkgZGF0YSBibG9ja3MNCj4+IHRoYXQgYXJlIGNo dW5rcyBvZiBzb21ldGhpbmcgZWxzZS4NCj4+IEZvciBpbnN0YW5jZSwgeW91IGNvdWxkIGhhdmUg YSBmb2xkZXIgb24gYSB1c2VyJ3Mgc3RvcmFnZSB0aGF0IGNvbnRhaW5zDQo+PiBvbmx5IGlub2Rl LWxpa2UgSlNPTi1kb2N1bWVudHMsIHdoaWNoIGxpc3QgdGhlIFVSTHMgb2YgYmluYXJ5IGRvY3Vt ZW50cw0KPj4gdGhhdCBtYWtlIHVwIDFLYiBibG9ja3Mgb2YgdGhlIGFjdHVhbCBkYXRhLiBOaWNl IGZvciBkZWR1cGluZywgZGVsdGENCj4+IHVwZGF0ZXMsIGFuZCBhbHNvIHJlbmFtaW5nIGZpbGVz IHdpdGhvdXQgcmV1cGxvYWRpbmcgdGhlaXIgY29udGVudC4NCj4+DQo+PiBCdXQgeWVhaCwgdGhl IGFyZ3VtZW50IGlzIHRoYXQgKmhvdyogdG8gY3JlYXRlIGFuZCBtYW5hZ2UgdGhlc2UgY2h1bmtz LCBpcw0KPj4gdGhlbiBzdGlsbCBsZWZ0IHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIg KG9yIHRvIGFub3RoZXIgc3BlYyBvbiB0b3ANCj4+IG9mIHRoZSByZW1vdGVTdG9yYWdlIHNwZWMp Lg0KPj4NCj4+DQo+PiBDaGVlcnMsDQo+PiBNaWNoaWVsLg0KPj4NCj4+IE9uIFdlZCwgRGVjIDIs IDIwMTUgYXQgMzoyOSBQTSwgTGluaHVpIFN1biA8bGguc3VubGluaEBnbWFpbC5jb20+IHdyb3Rl Og0KPj4NCj4+IEhpDQo+Pg0KPj4gMjAxNS0xMi0wMiAyMjowNSBHTVQrMDg6MDAgTWljaGllbCBk ZSBKb25nIDxtYmRlam9uZ0Btb3ppbGxhLmNvbT46DQo+Pg0KPj4gQ29vbCEgSSBjcmVhdGVkIGh0 dHBzOi8vZ2l0aHViLmNvbS9yZW1vdGVzdG9yYWdlL3NwZWMvaXNzdWVzLzEzNyBhYm91dA0KPj4g dGhlIG5lZWQgZm9yICBNT1ZFIHZlcmIuDQo+PiBBcHBsaWNhdGlvbi1sZXZlbCBjaHVua2luZyBp cyBwYXJ0aWFsbHkgc3VwcG9ydGVkIGJ5IEhUVFAgaXRzZWxmIHRocm91Z2gNCj4+IGBDb250ZW50 LVJhbmdlYCBoZWFkZXJzIChhbHRob3VnaCBpdCdzIG5vdCBjbGVhciB3aGV0aGVyIHRoZXNlIGFy ZSBhbGxvd2VkDQo+PiBvbiBQVVQgcmVxdWVzdHMgYXMgd2VsbCBhcyBvbiBHRVQgcmVxdWVzdHMs IHNlZQ0KPj4gaHR0cHM6Ly9naXRodWIuY29tL3JlbW90ZXN0b3JhZ2Uvc3BlYy9pc3N1ZXMvMTMx KS4gVGhlIHByb2JsZW0gaXMgdGhhdA0KPj4gSFRUUCBkZWZpbmVzIHZlcnNpb25pbmcgYXQgdGhl IGRvY3VtZW50IGxldmVsLCB5b3UgY2Fubm90IGFzayBhIHNlcnZlciB0bw0KPj4gcHJvZHVjZSBv ciBjaGVjayBhbiBFVGFnIGZvciBhIHNwZWNpZmljIGJ5dGUtcmFuZ2Ugb2YgYSBkb2N1bWVudCwg b25seSBmb3INCj4+IHRoZSBlbnRpcmUgZG9jdW1lbnQuDQo+Pg0KPj4NCj4+IEFjdHVhbGx5IHdo YXQgSSdtIHNheWluZyBpcyBhIGNodW5raW5nIGJlZm9yZSB0cmFuc21pdHRpbmcgKHVzaW5nIGh0 dHApLA0KPj4gaW4gdGhpcyB3YXksIHRoZXkgYXJlIHRyZWF0ZWQgYXMgaW5kaXZpZHVhbCBkb2N1 bWVudHMgZnJvbSB0aGUgc3RhbmRwb2ludA0KPj4gb2YgaHR0cC4gQnV0IEkgZG9uJ3Qga25vdyB3 aGV0aGVyIHRoaXMgaXMgYXBwcm9wcmlhdGUgZm9yIHJlbW90ZVN0b3JhZ2UsDQo+PiBqdXN0IGEg Y29tbWVudC4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gTGluaHVpDQo+Pg0KPj4NCj4+IEEgY29tcGFy aXNvbiBkb2N1bWVudCBzb3VuZHMgZ29vZCEgU2VlIGFsc28NCj4+IGh0dHA6Ly93d3cuc2Vydmlj ZWRlbnVhZ2VzLmZyL2VuL2dlbmVyaWMtc3RvcmFnZS1lY29zeXN0ZW0uDQo+Pg0KPj4NCj4+IENo ZWVycywNCj4+IE1pY2hpZWwuDQo+Pg0KPj4NCj4+IE9uIFdlZCwgRGVjIDIsIDIwMTUgYXQgMjoz MiBQTSwgTGluaHVpIFN1biA8bGguc3VubGluaEBnbWFpbC5jb20+IHdyb3RlOg0KPj4NCj4+IFRo YXQncyBjb29sIGZvciBtZSwgYSBzZXBhcmF0ZSBzZWN0aW9uIGZvciB0aGlzIG1pZ2h0IG1ha2Ug c2Vuc2UuDQo+Pg0KPj4gQW5vdGhlciB0aGluZyBpcyBkbyB3ZSBuZWVkIHRvIGluY2x1ZGUgYW4g YXBwbGljYXRpb24tbGF5ZXIgY2h1bmtpbmcgaGVyZQ0KPj4gKG5vdCBqdXN0IGZvciBhIGJyb3dz ZXIgc3luYyksIHNpbmNlIGlmIHdlIHdhbnQgdG8gZnVydGhlciBleHRlbmQgb3RoZXINCj4+IGNh cGFiaWxpdGllcyBpdCBpcyBlc3NlbnRpYWwuDQo+Pg0KPj4gUmVnYXJkcywNCj4+IExpbmh1aQ0K Pj4NCj4+IDIwMTUtMTItMDIgMjE6MDMgR01UKzA4OjAwIEh1Z28gR29ueqiibGV6IExhYnJhZG9y IDxpZXRmQGh1Z28ubGFia29kZS5jb20+Og0KPj4NCj4+DQo+PiBJIHByb3Bvc2UgdG8gY29tZSB1 cCB3aXRoIGEgbGlzdCBvZiBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIG9mIHVzaW5nDQo+ PiBXZWJEQVYgYW5kIGNvbXBhcmUgdGhlbSBhZ2FpbnN0IGEgSlNPTi9SRVNUIGJhc2VkIGFwcHJv YWNoLCBsaWtlDQo+PiByZW1vdGVTdG9yYWdlLg0KPj4NCj4+IERvZXMgaXQgc291bmQgZ29vZCA/ DQo+Pg0KPj4NCj4+IE9uIFdlZCwgRGVjIDIsIDIwMTUsIGF0IDAxOjU5IFBNLCBMaW5odWkgU3Vu IHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4gMjAxNS0xMi0wMiAyMDo0MyBHTVQrMDg6MDAgSHVnbyBH b256qKJsZXogTGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT46DQo+Pg0KPj4NCj4+DQo+ Pg0KPj4NCj4+DQo+PiBPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwMTozMCBQTSwgTWljaGllbCBk ZSBKb25nIHdyb3RlOg0KPj4NCj4+IEhpIGFsbCENCj4+IFRoYW5rcyBmb3IgYWxsIHlvdXIgcmVh Y3Rpb25zIHRvIHRoZSByZW1vdGVTdG9yYWdlIEludGVybmV0LURyYWZ0Lg0KPj4NCj4+IFdlIGdl dCB0aGUgcXVlc3Rpb24gYWJvdXQgV2ViREFWIGEgbG90LCBpbiB0aGUgbmV4dCB2ZXJzaW9uIHdl IHNob3VsZCBhZGQNCj4+IGEgcmVtYXJrIGFib3V0IGl0IGluIHRoZSBpbnRyby4gVGhlIGZvbGRl ciBkZXNjcmlwdGlvbnMgcmV0dXJuZWQgd2hlbiB5b3UNCj4+IEdFVCBhIFVSTCB0aGF0IGVuZHMg d2l0aCBhIC8gYXJlIGluZGVlZCBhIGRldmlhdGlvbiBmcm9tIHRoZSBYTUwgcmV0dXJuZWQNCj4+ IGJ5IFdlYkRBViBzZXJ2ZXIsIGFuZCB0aGlzIGlzIGp1c3QgYmVjYXVzZSBub3dhZGF5cyBKU09O IGlzIGVhc2llciB0byB1c2UNCj4+IHRoYW4gWE1MIGZvciBkZXZlbG9wZXJzLCBib3RoIGNsaWVu dC1zaWRlIGFuZCBzZXJ2ZXItc2lkZS4NCj4+DQo+Pg0KPj4NCj4+IEkgdG90YWxseSBhZ3JlZSBo ZXJlLCB0aGlzIHdhcyBnb2luZyB0byBoYXBwZW4gc29vbiBvciBsYXRlciBhbmQgaXQgaXMNCj4+ IHJlYWxseSBhcHByZWNpYXRlZC4NCj4+DQo+Pg0KPj4NCj4+IFRoZSBmYWN0IHRoYXQgd2UgZG9u J3QgcmVxdWlyZSBzZXJ2ZXJzIHRvIHN1cHBvcnQgV2ViREFWJ3MgY3VzdG9tIHZlcmJzDQo+PiBs aWtlIFBST1BQQVRDSCBldGMuIGlzIGZvciB0aHJlZSByZWFzb25zOg0KPj4gMSkgaXQncyBhIGxv dCBvZiB3b3JrIHRvIGltcGxlbWVudCB0aGlzIHdpdGhvdXQgdXNpbmcgYW4gZXhpc3RpbmcgV2Vi REFWDQo+PiBsaWJyYXJ5DQo+PiAyKSBpbiBwcmFjdGljZSwgYSBsb3Qgb2YgV2ViREFWIHNlcnZl cnMgZ2V0IGl0IHdyb25nLCBvciBkb24ndCBpbXBsZW1lbnQNCj4+IGFsbCBvZiBXZWJEQVYuIEl0 J3MgdmVyeSBhbm5veWluZyBmb3IgY2xpZW50IGltcGxlbWVudGVycyB0byBoYXZlIHRvIGRlYWwN Cj4+IHdpdGggc2VydmVycyB0aGF0IGUuZy4gY2hvc2Ugbm90IHRvIGltcGxlbWVudCBMT0NLIGFu ZCBVTkxPQ0suDQo+PiAzKSB3ZSBkb24ndCByZWFsbHkgbmVlZCBhbGwgdGhlc2UgYWR2YW5jZWQg ZmVhdHVyZXMgb24gdG9wIG9mIHN0YW5kYXJkDQo+PiBIVFRQLCBqdXN0IHN1cHBvcnRpbmcgR0VU L1BVVC9ERUxFVEUgZm9yIHJlc291cmNlcywgYW5kIGFkZGluZyBhIHNpbXBsZQ0KPj4gZm9sZGVy IGRlc2NyaXB0aW9uIGZvcm1hdCwgaXMgZW5vdWdoIGZvciBtb3N0IGFwcGxpY2F0aW9ucy4NCj4+ DQo+PiBPdGhlciB0aGFuIHRoYXQsIHRoZSByZW1vdGVTdG9yYWdlIEludGVybmV0LURyYWZ0IHNw ZWNpZmllcyBhICpsb3QqIG1vcmUNCj4+IHRoYW4ganVzdCBob3cgZWFjaCBIVFRQIHZlcmIgc2hv dWxkIGJlaGF2ZToNCj4+ICogcmVxdWlyaW5nIHN1cHBvcnQgZm9yIE9BdXRoIGltcGxpY2l0LWdy YW50IGZsb3cNCj4+ICogcmVxdWlyaW5nIEVUYWcgc3VwcG9ydCBhbmQgbmVzdGVkIHZlcnNpb25p bmcgKGkuZS4gdGhlIGZvbGRlcidzIEVUYWcNCj4+IGNoYW5nZXMgaWYgYW55dGhpbmcgd2l0aGlu IHRoYXQgZm9sZGVyIGNoYW5nZXMpDQo+PiAqIHJlcXVpcmluZyBDT1JTIGhlYWRlcnMNCj4+ICog cmVxdWlyaW5nIGEgV2ViRmluZ2VyIGFubm91bmNlbWVudCBmb3Igc2VydmljZSBkaXNjb3ZlcnkN Cj4+IEl0IHdvdWxkIGJlIGVhc3kgdG8gYWRkIHRoZXNlIHRocmVlIHRoaW5ncyBvbiB0b3Agb2Yg V2ViREFWLCBpbnN0ZWFkIG9mDQo+PiBwdXR0aW5nIHRoZW0gb24gdG9wIG9mIG91ciBtaW5pbWFs IEdFVC9QVVQvREVMRVRFIEFQSSBkZWZpbml0aW9uLiBJbiBmYWN0LA0KPj4gd2UgY291bGQgcHJv YmFibHkgc2VwYXJhdGUgaXQgaW50byB0d28gSW50ZXJuZXQtRHJhZnRzOiBvbmUgZm9yIHRoZQ0K Pj4gJ1JFU1RmdWwgZm9sZGVycycgQVBJIHdoaWNoIGlzIG91ciBzaW1wbGlmaWNhdGlvbiBvZiBX ZWJEQVYsIGFuZCBhIHNlY29uZA0KPj4gb25lIGZvciBPQXV0aC9FVGFncy9DT1JTL1dlYkZpbmdl ciBvbiB0b3Agb2YgZWl0aGVyIFdlYkRBViBvciAnUkVTVGZ1bA0KPj4gZm9sZGVycycgb3Igd2hh dGV2ZXIgb3RoZXIgSFRUUC1iYXNlZCBBUEkgeW91IHdhbnQuDQo+Pg0KPj4NCj4+DQo+PiBUaGVy ZSBpcyBvbmUgcmVxdWlyZW1lbnQgdGhhdCBhbGwgc3luY2hyb25pc2VycyBuZWVkIHRvIGhhbmRs ZTogbW92aW5nDQo+PiByZXNvdXJjZXMuIEluIHRoaXMgc3BlYyB0aGUgYWx0ZXJuYXRpdmUgb2Yg YSBXZWJEQVYgTU9WRSBpcyBub3Qgc3BlY2lmaWVkLg0KPj4NCj4+IEl0IGlzIHRydWUgdGhhdCBh IE1PVkUgY291bGQgYmUgcmVwbGFjZWQgd2l0aCBhIERFTEVURSArIFVQTE9BRCBidXQgdGhhdA0K Pj4gaXMgbm90IGFjY2VwdGFibGUgaW4gbW9zdCBjYXNlcyBkdWUgdG8gdGhlIGluZWZmaWNpZW5j eSBvZiBzdWNoIG9wZXJhdGlvbg0KPj4gKGNwdSwgYmFuZHdpZHRoIGNvbnN1bXB0aW9uIC4uLikN Cj4+DQo+PiBJcyB0aGVyZSBhIHBsYW4gdG8gc3VwcG9ydCBzdWNoIGJhc2ljIGZlYXR1cmU/DQo+ Pg0KPj4gRnJvbSB0aGUgY3VycmVudCByZW1vdGVTdG9yYWdlIHNwZWMsIHRoZSBvd25DbG91ZCBz eW5jIHByb3RvY29sIGNhbiBiZQ0KPj4gaW1wbGVtZW50ZWQuIFRoZSBtaXNzaW5nIGJpdCBpcyB0 cmFja2luZyB0aG9zZSByZW1vdGUgbW92ZXMuDQo+Pg0KPj4gSSBhZ3JlZSB3aXRoIEh1Z28gdGhh dCBNT1ZFIGlzIHVzZWZ1bCwgc29tZXRpbWVzIGlmIHlvdSBqdXN0IHJlbmFtZSBhIGZpbGUNCj4+ IGl0IHdpbGwgYmUgcGVyZmVjdC4gQnV0IHRoZSBxdWVzdGlvbiBJIGhhdmUgaXMgdGhhdCB3aGV0 aGVyIHdlIG5lZWQgdG8gbWFrZQ0KPj4gdHdvIGRvY3VtZW50cz8gTXVsdGlwbGUgY2hvaWNlcyBp cyBub3QgZ29vZCBmb3Igc3RhbmRhcmRpemF0aW9uLiBJbiBteQ0KPj4gdmlldywgd2ViZGF2IGlz IHNvbWV0aGluZyB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIHZlcnkgY2xlYXIgZGVjaXNpb24gb24N Cj4+IHdoZXRoZXIgdG8gY29uc2lkZXIgaXQgb3Igbm90Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBM aW5odWkNCj4+DQo+Pg0KPj4NCj4+IENoZWVycw0KPj4NCj4+DQo+PiBPbiBXZWQsIERlYyAyLCAy MDE1IGF0IDExOjI4IEFNLCBIdWdvIEdvbnqoomxleiBMYWJyYWRvciA8DQo+PiBpZXRmQGh1Z28u bGFia29kZS5jb20+IHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gT24gV2VkLCBE ZWMgMiwgMjAxNSwgYXQgMTE6MTggQU0sIExpbmh1aSBTdW4gd3JvdGU6DQo+Pg0KPj4gSGkNCj4+ DQo+PiBPbiDW3Mj9LCAxMtTCIDIsIDIwMTUgYXQgMTc6NTYsIEh1Z28gR29ueqiibGV6IExhYnJh ZG9yIDxpZXRmQGh1Z28ubGFia29kZS5jb20+DQo+PiB3cm90ZToNCj4+DQo+Pg0KPj4NCj4+DQo+ PiBPbiBXZWQsIERlYyAyLCAyMDE1LCBhdCAwODoyMCBBTSwgTGluaHVpIFN1biB3cm90ZToNCj4+ DQo+PiBIaQ0KPj4NCj4+IDIwMTUtMTItMDIgNToxNCBHTVQrMDg6MDAgSHVnbyBHb256qKJsZXog TGFicmFkb3IgPGlldGZAaHVnby5sYWJrb2RlLmNvbT46DQo+Pg0KPj4gSGksDQo+Pg0KPj4gZnJv bSBteSBwb2ludCBvZiB2aWV3IHRoZSByZW1vdGVTdG9yYWdlIHByb2plY3QgYWRkcmVzc2VzIGEg c3Vic2V0IG9mDQo+PiB0aGUgdXNlIGNhc2VzIG9mIHRoZSAgV2ViREFWIHNwZWNpZmljYXRpb24u DQo+Pg0KPj4gVGhlIG1haW4gZGlmZmVyZW5jZSBJIGNhbiBvYnNlcnZlIGlzIHRoYXQgdGhlIHNw ZWNpZmljYXRpb24gaXMgYnVpbHQgb24NCj4+IFJFU1QgaW5zdGVhZCBvZiBYTUwtYmFzZWQgY29t bXVuaWNhdGlvbi4NCj4+DQo+Pg0KPj4gSSBwZXJzb25hbGx5IGxpa2UgbXVjaCBtb3JlIFJFU1Qg dGhhbiBXZWJEQVYgYmVjYXVzZSBpdCBpcyBtb3JlDQo+PiBkZXZlbG9wZXIgZnJpZW5kbHkgYW5k IGl0IGlzIGZhc3RlciB0byBkZXZlbG9wLg0KPj4gIE1heWJlIHRoZSByZW1vdGVTdG9yYWdlIEFQ SSBiZWNvbWVzIHRoZSBuZXh0IFdlYkRBViA6KQ0KPj4NCj4+IEhvd2V2ZXIsIHRoZSByZW1vdGVT dG9yYWdlIEFQSSBkb2VzIG5vdCBwcm92aWRlIGEgd2F5IG9mIHN5bmNocm9uaXNpbmcNCj4+IGRh dGEsIHRoaXMgdGFzayBpcyBkZWxlZ2F0ZWQgdG8gdGhlIGRldmVsb3BlcnMuDQo+PiBJcyB0aGVy ZSBhIHBsYW4gdG8gcHJvdmlkZSBzdWNoIGZlYXR1cmUgYmFzZWQgb24gdGhlIG91dGNvbWUgb2Yg dGhpcw0KPj4gZHJhZnQ/DQo+Pg0KPj4gSSdtIGEgbGl0dGxlIGJpdCBjb25mdXNlZCB3aHkgeW91 IHNheSB0aGUgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBwcm92aWRlDQo+PiB0aGF0LiBJcyB0aGF0 IGJlY2F1c2UgcmVtb3RlU3RvcmFnZSBkb2VzIG5vdCBwZXJmb3JtIGxpa2UgYSB0eXBpY2FsIHN5 bmMNCj4+IHNlcnZpY2VzIChlLmcuIGRyb3Bib3guLi4pIG9yIHlvdSBhcmUgc2F5aW5nIHNvbWV0 aGluZyBlbHNlPw0KPj4NCj4+IFllcywgYmVjYXVzZSBpdCBkb2VzIG5vdCBvZmZlciBzeW5jaHJv bmlzYXRpb24gY2FwYWJpbGl0aWVzLg0KPj4NCj4+IEdvdCBpdC4gQW5kIFdoYXQgSSBhbSB3b25k ZXJpbmcgaXMgdGhhdCBkbyB3ZSBuZWVkIHRvIGluY2x1ZGUgdGhvc2UNCj4+IGNhcGFiaWxpdGll cyBpbiBhIGJhc2Ugc3BlY2lmaWNhdGlvbnMuIFNpbmNlIGl0IGlzIGhhcmQgdG8gc3RhbmRhcmRp emUgdGhlDQo+PiBjYXBhYmlsaXRpZXMgbGlrZSBkZWR1cCBvciBkZWx0YS4gTWF5YmUgYSBiZXR0 ZXIgd2F5IGlzIHRvIGRlZmluZSB0aG9zZSBpbg0KPj4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9u LA0KPj4NCj4+DQo+Pg0KPj4NCj4+IFRoYW5rcyBmb3IgZ2l2aW5nIHRoZXNlIGV4YW1wbGVzIC0g c28gYnkgJ3N5bmNocm9uaXNhdGlvbiBjYXBhYmlsaXRpZXMnDQo+PiB5b3UgbWVhbiAxKSBkZWR1 cGxpY2F0aW9uIGFuZCAyKSBkZWx0YSB1cGRhdGVzPyBBbnl0aGluZyBlbHNlIG9yIGlzIHRoYXQg YW4NCj4+IGV4aGF1c3RpdmUgbGlzdD8NCj4+DQo+Pg0KPj4NCj4+IHNvbWV0aGluZyBsaWtlIGV4 dGVuc2lvbnMuIEZvciBhIGJhc2UgZG9jdW1lbnQsIHdlIGp1c3QgbmVlZCB0byBkZWZpbmUgaG93 DQo+PiB0byBwZXJmb3JtIHN5bmMgb3BlcmF0aW9ucy4NCj4+DQo+Pg0KPj4NCj4+IFllcywgSSBh Z3JlZSB0aGF0IG1heSBiZSBhbiBleHRlbnNpb24gb2YgdGhpcyBkcmFmdCBjb3VsZCBoYW5kbGUg dGhlDQo+PiBzeW5jaHJvbmlzYXRpb24gcGFydC4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gT3Vy IEludGVybmV0LURyYWZ0IGlzIGhlYXZpbHkgZm9jdXNlZCBvbiB0aGUgd29ybGQgd2lkZSB3ZWIs IHdob3NlIFVSTHMNCj4+IGFyZSBub3QgY29udGVudC1hZGRyZXNzYWJsZSwgd2UgY2FuJ3QgY2hh bmdlIHRoYXQuIFNvIHRoYXQgYXJjaGl0ZWN0dXJlIGlzDQo+PiBub3QgdmVyeSBmcmllbmRseSB0 byBkZWR1cGxpY2F0aW9uLCBjb21wYXJlZCB0byBmb3IgaW5zdGFuY2UgQml0VG9ycmVudC4gQXMN Cj4+IHlvdSBhbHJlYWR5IHNhaWQsIGRldmVsb3BlcnMgY2FuIHN0aWxsIGRlZHVwZSBvbiB0aGUg c2VydmVyLXNpZGUgd2hlbg0KPj4gc3RvcmluZyBibG9icyB0byBkaXNrLCBhbmQgY2FuIGFsc28g ZGVkdXBlIG9uIHRoZSBjbGllbnQgc2lkZSBiZWZvcmUNCj4+IGNyZWF0aW5nIHRoZSByZXNvdXJj ZXMgdGhlIGNsaWVudCB1cGxvYWRzLg0KPj4gQXMgZmFyIGFzIEkga25vdywgZGVsdGEgdXBkYXRl cyBhcmUgbm90IHN1cHBvcnRlZCBieSB0aGUgRVRhZyBzeXN0ZW0gLSB5b3UNCj4+IGNhbm5vdCBk byBhIHJhbmdlIHJlcXVlc3QgdG8gZmluZCBvdXQgaWYgY2VydGFpbiBieXRlcyB3aXRoaW4gYSBk b2N1bWVudA0KPj4gaGF2ZSBjaGFuZ2VkLiBIb3dldmVyLCB0aGUgZm9sZGVyIHN5c3RlbSB3ZSBk ZWZpbmUgZG9lcyBlbmNvdXJhZ2UgeW91LCBmb3INCj4+IGluc3RhbmNlIHdoZW4geW91IGRldmVs b3AgYSBUbyBEbyBMaXN0IGFwcCwgcHV0IGVhY2ggdGFzayBvbiBpdHMgb3duDQo+PiBkb2N1bWVu dCwgYW5kIHRoZW4gcXVlcnkgdGhlIGZvbGRlciB0byBzZWUgd2hpY2ggb2YgdGhlbSBjaGFuZ2Vk LCBpbnN0ZWFkDQo+PiBvZiBwdXR0aW5nIHRoZW0gYWxsIGluIG9uZSBiaWcgZG9jdW1lbnQgYW5k IHJldHJpZXZpbmcgdGhlIHdob2xlIGRvY3VtZW50DQo+PiBlYWNoIHRpbWUuDQo+Pg0KPj4gQ2hl ZXJzLA0KPj4gTWljaGllbC4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBCVFcsIEkg d2FudCB0byBpbnRyb2R1Y2UgQ2xhd0lPICggPGh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvLz4NCj4+ IGh0dHA6Ly9jbGF3aW8uZ2l0aHViLmlvKSwgYSByZXNlYXJjaA0KPj4gcHJvamVjdCB0byBiZW5j aG1hcmsgZGlmZmVyZW50IHN5bmNocm9uaXNhdGlvbiBwcm90b2NvbHMgYWdhaW5zdA0KPj4gZGlm ZmVyZW50IGRhdGEgYmFja2VuZHMgd2l0aCBzcGVjaWFsIGF0dGVudGlvbiB0byBwcm92aWRlIGEg Y29tbW9uIHN5bmMNCj4+IEFQSS4NCj4+DQo+PiBBIGNvbW1vbiBBUEkgZm9yIGRpZmZlcmVudCBz eW5jIHByb3RvY29scyBpcyBiZWluZyBjcmVhdGVkIGJhc2VkIG9uIHRoZQ0KPj4gYXJjaGl0ZWN0 dXJlIHNwZWNpZmllZCBpbiB0aGlzIGRyYWZ0IChjb250cm9sIGFuZCBkYXRhIHNlcnZlcnMpIGFu ZCB0aGUNCj4+DQo+PiBJIGNhbm5vdCBmaW5kIGEgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0dXJlIGlu IHRoaXMgZHJhZnQuIEl0IHNlZW1zIHRoYXQgdGhleQ0KPj4gaGFuZGxlIG1ldGFkYXRhIGFuZCBj b250ZW50IGRhdGEgdG9nZXRoZXIsIGp1c3QgbGlrZSBhIG5vcm1hbCB3ZWIgc2VydmljZS4NCj4+ DQo+Pg0KPj4gQ2xhd0lPIGlzIGZ1bGx5IGRpc3RyaWJ1dGVkLiBFdmVyeSBsb2dpY2FsIHVuaXQg aXMgYSBkaWZmZXJlbnQgc2VydmVyIHRoYW4NCj4+IGJlIHNjYWxlZCBvdXQuIERhdGEgYW5kIE1l dGFkYXRhIGNoYW5uZWxzIGFyZSBpbmRlcGVuZGVudCBmcm9tIGVhY2ggb3RoZXINCj4+IGFuZCBy ZXNpZGUgb24gZGlmZmVyZW50IHNlcnZlcnMuDQo+Pg0KPj4gVGhhdCBpcyB3aWRlbHkgZW1wbG95 ZWQgaW4gcG9wdWxhciBzeW5jIHNlcnZpY2VzLiBBbmQgdGhhdCBpcyBhbHNvDQo+PiBiZW5lZmlj aWFsIHRvIHByaXZhY3kgdG8gc29tZSBleHRlbnQuIEJ1dCBpbiB0aGUgY29udGV4dCBvZiBzeW5j IGluIGJyb3dzZXINCj4+ICh3aGljaCBpcyBtYWlubHkgY29uc2lkZXJlZCBpbiB0aGUgcmVtb3Rl U3RvcmFnZSksIEkgZG9uJ3Qga25vdyB3aGV0aGVyDQo+PiB0aGlzIGlzIHJlYXNvbmFibGUuIEJ1 dCBJIHRoaW5rIHdlIHNob3VsZCBkZXBsb3kgZGlzdHJpYnV0ZWQgYXJjaGl0ZWN0dXJlDQo+PiBh bHRob3VnaCBpdCB3aWxsIG1ha2UgdGhpbmdzIGNvbXBsaWNhdGVkLg0KPj4NCj4+DQo+Pg0KPj4g T2YgY291cnNlLCB0aGUgcmVtb3RlU3RvcmFnZSBpcyB0YXJnZXRlZCB0byBicm93c2Vycywgc28g c3luY2luZyBkb2VzIG5vdA0KPj4gbWFrZSB0b28gbXVjaCBzZW5zZSBpbiB0aGlzIGNhc2UuDQo+ PiBXaXRoIHRoZSByaXNlIG9mIExpbnV4IGNvbnRhaW5lciBtaWNyby1zZXJ2aWNlIGJhc2VkIGFy Y2hpdGVjdHVyZXMsIHRoZQ0KPj4gZGVwbG95bWVudCBvZiAgc3VjaCBoaWdobHkgY29tcGxleCBz eXN0ZW1zIHNob3VsZCBiZWNvbWUgZWFzaWVyIGFuZCBmYXN0ZXIuDQo+Pg0KPj4gQmVzdCwNCj4+ DQo+Pg0KPj4gSHVnbw0KPj4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+IExpbmh1aQ0KPj4NCj4+ DQo+Pg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBMaW5odWkNCj4+DQo+PiBvbmUgZnJvbSB0aGUgQ0VS TiBFT1MgcHJvamVjdCAobWFuYWdlbWVudCwgZGlzayBhbmQgcXVldWUgc2VydmVycykuDQo+Pg0K Pj4gVGhlIFBoYXNlIEkgaGFzIGltcGxlbWVudGVkIHRoZSBvd25DbG91ZCBTeW5jIFByb3RvY29s IGFuZCBQaGFzZSBJSSB3aWxsDQo+PiBpbXBsZW1lbnQgdGhlIFNlYUZpbGUgU3luYyBQcm90b2Nv bC4NCj4+IFRoZSBjaG9pY2Ugb2YgdGhlc2UgcHJvdG9jb2xzIGFtb25nIG90aGVycyBpcyBiZWNh dXNlIHRoZXkgYXJlIHJlYWxseQ0KPj4gb3Bwb3NlZCB0byBlYWNoIG90aGVyIGluIHRlcm1zIG9m IHN5bmNpbmcgKGRlbHRhIHZzIG5vbi1kZWx0YSwNCj4+IHN0YXRlLWJhc2VkIHZzIGxvZy9ldmVu dC9naXQtYmFzZWQgc3luYyChrSksIHNvIGZpbmRpbmcgYSBjb21tb24gYXBwcm9hY2gNCj4+IGlz IG1vcmUgY2hhbGxlbmdpbmcuDQo+Pg0KPj4gUHJvdmlkaW5nIGEgYmFzZSBzcGVjaWZpY2F0aW9u L2FyY2hpdGVjdHVyZSB0byBtZWFzdXJlIHRoZSBmZWFzaWJpbGl0eQ0KPj4gb2YgdGhpcyBkcmFm dCBpcyBvbmUgb2YgdGhlIG9iamVjdGl2ZXMgb2YgdGhlIHByb2plY3QuDQo+Pg0KPj4gSSBiZWxp ZXZlIHRoYXQgdGhlIHdvcmsgYmVpbmcgZG9uZSBoZXJlIGFuZCBpbiBDbGF3SU8gYXJlIHN1cHBs ZW1lbnRhcnkNCj4+IHRvIGVhY2ggb3RoZXIgYW5kIEkgdGhpbmsgbXV0dWFsIGNvbGxhYm9yYXRp b24gY291bGQgYmUgYmVuZWZpY2lhbCBmb3INCj4+IGJvdGggc2lkZXMuDQo+Pg0KPj4gQWxzbywg aWYgdGhlcmUgaXMgaW50ZXJlc3QsIHRoZSByZW1vdGVTdG9yYWdlIEFQSSBjYW4gYmUgYWRkZWQg dG8NCj4+IENsYXdJTy4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4gSHVnbyBHb256YWxl eiBMYWJyYWRvcg0KPj4NCj4+IE9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0IDA5OjAwIFBNLCBzdG9y YWdlc3luYy1yZXF1ZXN0QGlldGYub3JnIHdyb3RlOg0KPj4gPiBTZW5kIFN0b3JhZ2VzeW5jIG1h aWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KPj4gPiAgICAgICBzdG9yYWdlc3luY0BpZXRmLm9y Zw0KPj4gPg0KPj4gPiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBX aWRlIFdlYiwgdmlzaXQNCj4+ID4gICAgICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N0b3JhZ2VzeW5jPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdG9yYWdlc3luYw0KPj4gPiBvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3 aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCj4+ID4gICAgICAgc3RvcmFnZXN5bmMtcmVx dWVzdEBpZXRmLm9yZw0KPj4gPg0KPj4gPiBZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdp bmcgdGhlIGxpc3QgYXQNCj4+ID4gICAgICAgc3RvcmFnZXN5bmMtb3duZXJAaWV0Zi5vcmcNCj4+ ID4NCj4+ID4gV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28g aXQgaXMgbW9yZSBzcGVjaWZpYw0KPj4gPiB0aGFuICJSZTogQ29udGVudHMgb2YgU3RvcmFnZXN5 bmMgZGlnZXN0Li4uIg0KPj4gPiBUb2RheSdzIFRvcGljczoNCj4+ID4NCj4+ID4gICAgMS4gTmV3 IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgICAgSW50ZXJuZXQtRHJhZnQN Cj4+ID4gICAgICAgYXZhaWxhYmxlIChNaWNoaWVsIGRlIEpvbmcpDQo+PiA+ICAgIDIuIFJlOiBO ZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdA0K Pj4gPiAgICAgICBhdmFpbGFibGUgKEdpaGFuIERpYXMpDQo+PiA+ICAgIDMuIFJlOiBOZXcgdmVy c2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC1EcmFmdA0KPj4gPiAg ICAgICBhdmFpbGFibGUgKEZlaSBTb25nKQ0KPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNCj4+ ID4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+ID4gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3RvcmFnZXN5bmM+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+PiA+IEVtYWlsIGhhZCAzIGF0dGFjaG1lbnRzOg0KPj4g PiArIFtTdG9yYWdlc3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3Jh Z2UNCj4+ID4gSW50ZXJuZXQtRHJhZnQgYXZhaWxhYmxlDQo+PiA+ICAgMmsgKG1lc3NhZ2UvcmZj ODIyKQ0KPj4gPiArIFJlOiBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9u Zy1yZW1vdGVzdG9yYWdlDQo+PiA+IEludGVybmV0LURyYWZ0IGF2YWlsYWJsZQ0KPj4gPiAgIDFr IChtZXNzYWdlL3JmYzgyMikNCj4+ID4gKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBv ZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZQ0KPj4gPiBJbnRlcm5ldC1EcmFmdCBhdmFpbGFi bGUNCj4+ID4gICAyayAobWVzc2FnZS9yZmM4MjIpDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlz dA0KPj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zdG9yYWdlc3luYw0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+ Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcg bGlzdA0KPj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+DQo+Pg0KPj4NCj4= From nobody Thu Dec 3 19:01:57 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572621B2AAB for ; Thu, 3 Dec 2015 19:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P0eZCyuaANZ for ; Thu, 3 Dec 2015 19:01:54 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA891B2AA8 for ; Thu, 3 Dec 2015 19:01:53 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygAnTpSyAmFWSAAAAA--.11S2; Fri, 04 Dec 2015 11:04:19 +0800 (CST) Date: Fri, 4 Dec 2015 11:01:45 +0800 From: "Fei Song" To: "Michiel de Jong" , =?gb2312?B?RnJhbj9vaXMgS29vbWFu?= References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120411014357832227@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygAnTpSyAmFWSAAAAA--.11S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCFW5GF4rKry7JryfArWUArb_yoW5GF18pa ySga1fKFWkJFyfAr1xuw12g3WFq3yxtF43Wrn3JryxC398JFyftF40y3yF9F93ZrWUWr12 vrW29a43ZFn8AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Fb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwCFI7km07C267AKxVWUAVWUtwC20s026c 02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_ Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcS sGvfC2KfnxnUUI43ZEXa7IU0OTmPUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Linhui Sun , storagesync , =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 03:01:56 -0000 bG9sLCB2ZXJ5IGdvb2QgcGljLiBTbyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhpcyByZW1vdGVT dG9yYWdlIGRyYWZ0IGlzIHRvIGJlIGEgdXNlZnVsIGFuZCBzcGVjaWZpYyAxNXRoLiANCg0KDQot LS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5JIHRoaW5rIHdlIHNob3VsZCBub3QgKHRyeSB0bykg cGljayBvbmUgcHJvdG9jb2wgLSBodHRwczovL3hrY2QuY29tLzkyNy8NCj4NCj5JIHRoaW5rIHN5 bmMgKmNsaWVudHMqIHNob3VsZCBiZSAicHJvdG9jb2wgcG9seWdsb3RzIiBpbiB0aGUgc2FtZSB3 YXkgYXMNCj5odHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Db21wYXJpc29uX29mX2luc3Rh bnRfbWVzc2FnaW5nX2NsaWVudHMjUHJvdG9jb2xfc3VwcG9ydA0KPg0KPk9uIFRodSwgRGVjIDMs IDIwMTUgYXQgMTA6NDQgQU0sIEZyYW4/b2lzIEtvb21hbiA8Zmtvb21hbkB0dXhlZC5uZXQ+IHdy b3RlOg0KPg0KPj4gT24gMTIvMDMvMjAxNSAxMDowNiBBTSwgZnNvbmdAYmp0dS5lZHUuY24gd3Jv dGU6DQo+PiA+IElmIHdlIHJlYWxseSB3YW50IHRvIGRpc2N1c3MgdGhlIFByb3MgYW5kIENvbnMg b2YgV2ViREFWLCBjYW4gd2UNCj4+ID4gbWFyayB0aGVzZSB0aHJlZSByZWFzb25zIGFzIGRpc2Fk dmFudGFnZXMgb2YgV2ViREFWPyBhbnkgc3VwcG9ydCBmb3INCj4+ID4gdGhhdD8NCj4+DQo+PiBQ ZXJzb25hbGx5LCBJIGRvIG5vdCB0aGluayB0aGF0IGlzIGZhaXIuDQo+Pg0KPj4gPiAxKSBpdCdz IGEgbG90IG9mIHdvcmsgdG8gaW1wbGVtZW50IHRoaXMgd2l0aG91dCB1c2luZyBhbiBleGlzdGlu Zw0KPj4gPiBXZWJEQVYgbGlicmFyeQ0KPj4NCj4+IEkgZG8gbm90IHNlZSBhIHByb2JsZW0gaW4g cmV1c2luZyBhbiBleGlzdGluZyBXZWJEQVYgbGlicmFyeS4gVGhpcyBoYXMNCj4+IHRoZSBhZGRl ZCBiZW5lZml0IHRoYXQgeW91IGdldCBhIGxvdCBvZiBmdW5jdGlvbmFsaXR5ICdmb3IgZnJlZScg YW5kDQo+PiB0aGF0IGV4aXN0aW5nIHRlc3Qgc3VpdGVzIGFyZSBhdmFpbGFibGUgZm9yIHRlc3Rp bmcgY29tcGF0aWJpbGl0eS4gVGhpcw0KPj4gaXMgcHVyZWx5IGEgcHJhY3RpY2FsIGFyZ3VtZW50 IQ0KPj4NCj4+ID4gMikgaW4gcHJhY3RpY2UsIGEgbG90IG9mIFdlYkRBViBzZXJ2ZXJzIGdldCBp dCB3cm9uZywNCj4+ID4gb3IgZG9uJ3QgaW1wbGVtZW50IGFsbCBvZiBXZWJEQVYuIEl0J3MgdmVy eSBhbm5veWluZyBmb3IgY2xpZW50DQo+PiA+IGltcGxlbWVudGVycyB0byBoYXZlIHRvIGRlYWwg d2l0aCBzZXJ2ZXJzIHRoYXQgZS5nLiBjaG9zZSBub3QgdG8NCj4+ID4gaW1wbGVtZW50IExPQ0sg YW5kIFVOTE9DSy4NCj4+DQo+PiBUaGUgcG9pbnQgaXMgbm90IHRvIGhhdmUgYSBmdWxseSBjb21w bGlhbnQgKHdoYXRldmVyIHRoYXQgaXMgZXhhY3RseSkNCj4+IFdlYkRBViBzZXJ2ZXIuIEVpdGhl ciB0aGlzIE1MIChvciByZW1vdGVTdG9yYWdlIHNwZWNpZmljYXRpb24pIGNvdWxkDQo+PiBkZXRl cm1pbmUgYSBzdWJzZXQgb2YgV2ViREFWIHRoYXQgd291bGQgYmUgcmVxdWlyZWQgdG8gYmUgaW1w bGVtZW50ZWQuDQo+PiBFLmcuIHdlIGV4aGF1c3RpdmVseSBsaXN0IHRoZSB2ZXJicyB0aGF0IG5l ZWQgdG8gYmUgaW1wbGVtZW50ZWQgYW5kDQo+PiB0aGVpciBleHBlY3RlZCBiZWhhdmlvci4gSWYg d2Uga2VlcCB0aGlzIGEgbGltaXRlZCBhcyBwb3NzaWJsZSBhbmQgc3RheQ0KPj4gYXdheSBmcm9t IGV4cGVyaW1lbnRhbCBmZWF0dXJlcyB3ZSBoYXZlIGEgaGlnaCBwcm9iYWJpbGl0eSB0aGF0IG1v c3QNCj4+IGxpYnJhcmllcyB3aWxsIGdldCBpdCByaWdodCEgSWYgd2Ugc3RheSBhd2F5IGZyb20g bG9ja2luZyBhbmQgQUNMcyB0aGUNCj4+IGxpYnJhcnkgc2l0dWF0aW9uIGxvb2tzIGEgbG90IGJy aWdodGVyIDopDQo+Pg0KPj4gPiAzKSB3ZSBkb24ndCByZWFsbHkgbmVlZCBhbGwgdGhlc2UgYWR2 YW5jZWQNCj4+ID4gZmVhdHVyZXMgb24gdG9wIG9mIHN0YW5kYXJkIEhUVFAsIGp1c3Qgc3VwcG9y dGluZyBHRVQvUFVUL0RFTEVURSBmb3INCj4+ID4gcmVzb3VyY2VzLCBhbmQgYWRkaW5nIGEgc2lt cGxlIGZvbGRlciBkZXNjcmlwdGlvbiBmb3JtYXQsIGlzIGVub3VnaA0KPj4gPiBmb3IgbW9zdCBh cHBsaWNhdGlvbnMuDQo+Pg0KPj4gRXhhY3RseSENCj4+DQo+PiA+IEZvciB0aGUgdGFyZ2V0IG9m IG91ciBJU1MgZ3JvdXAsIHdoZXRoZXIgdGhlIFdlYkRBViBjYW4gYmUgcmV1c2VkIGlzDQo+PiA+ IGNyaXRpY2FsLg0KPj4NCj4+IFdlbGwsIG15IHBvaW50IGlzIHRoYXQgdGhlcmUgaXMgbGl0dGxl IHJlYXNvbiB0byByZWludmVudCB0aGUgd2hlZWwgaWYNCj4+IHRoZSBvbmx5IGJlbmVmaXQgaXMg dG8gdXNlIEpTT04gaW5zdGVhZCBvZiBYTUwgZm9yIGZvbGRlciBsaXN0aW5ncy4gVGhlDQo+PiBh bW91bnQgb2YgZXhwZXJpZW5jZSBhbmQgYXZhaWxhYmxlIHRvb2xpbmcgZm9yIFdlYkRBViBpcyBh bHJlYWR5IGh1Z2UhDQo+PiBJdCB3b3VsZCBiZSBhIHdhc3RlIHRvIHRocm93IHRoaXMgYXdheSBq dXN0IGZvciBsaWtpbmcgSlNPTiBiZXR0ZXIuDQo+Pg0KPj4gQnV0IG1heWJlIHRoZXJlIGFyZSBv dGhlciByZWFzb25zIHVzaW5nIChhIGxpbWl0ZWQgc2V0IG9mKSBXZWJEQVYgaXMNCj4+IGltcG9z c2libGUgb3IgdW53YW50ZWQuLi4NCj4+DQo+PiBDaGVlcnMsDQo+PiBGcmFuP29pcw0KPj4NCj4= From nobody Thu Dec 3 19:07:40 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055101B2AB0 for ; Thu, 3 Dec 2015 19:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atLtss3tddQR for ; Thu, 3 Dec 2015 19:07:38 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 84C0D1A001C for ; Thu, 3 Dec 2015 19:07:37 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygCHaB0RBGFW4y4HAA--.5550S2; Fri, 04 Dec 2015 11:10:10 +0800 (CST) Date: Fri, 4 Dec 2015 11:07:31 +0800 From: "Fei Song" To: =?gb2312?B?RnJhbj9vaXMgS29vbWFu?= , "Michiel de Jong" References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> , <566014EA.2010705@tuxed.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120411072964071629@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygCHaB0RBGFW4y4HAA--.5550S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Cr1xJr4rAw1DAFWDuF4DArb_yoW8Gr15pF 4ftayUCr4kGrW7Aw48Xw18GFyY9r1rCw47Gws8KrykCFy5JFyFk34rtr4fJay7Jry3Jr1U tr4YgrWUJ3W0vaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Fb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwCFI7km07C267AKxVWUAVWUtwC20s026c 02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_ Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcS sGvfC2KfnxnUUI43ZEXa7IU8ZiStUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Linhui Sun , storagesync , =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 03:07:39 -0000 SGkNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+T24gMTIvMDMvMjAxNSAxMDo1MiBBTSwg TWljaGllbCBkZSBKb25nIHdyb3RlOg0KPj4gSSB0aGluayB3ZSBzaG91bGQgbm90ICh0cnkgdG8p IHBpY2sgb25lIHByb3RvY29sIC0gaHR0cHM6Ly94a2NkLmNvbS85MjcvDQo+DQo+U2F5aW5nIHRo YXQgYWZ0ZXIgd3JpdGluZyB5b3VyIG93biBzcGVjIDspDQo+DQo+PiBJIHRoaW5rIHN5bmMgKmNs aWVudHMqIHNob3VsZCBiZSAicHJvdG9jb2wgcG9seWdsb3RzIiBpbiB0aGUgc2FtZSB3YXkgYXMN Cj4+IGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0NvbXBhcmlzb25fb2ZfaW5zdGFudF9t ZXNzYWdpbmdfY2xpZW50cyNQcm90b2NvbF9zdXBwb3J0DQo+DQo+QmVjYXVzZSBpdCB3b3JrZWQg c28gd2VsbCBmb3IgbWVzc2FnaW5nIGNsaWVudHM/IFllYWgsIEkgZ3Vlc3MgaXQgd29ya3MNCj5p ZiB5b3UgbGl2ZSBpbiB0aGUgeWVhciAyMDAwIGFuZCBkb24ndCBjYXJlIGFib3V0IGZpbGUgdHJh bnNmZXIsIHZvaWNlLA0KPnZpZGVvLCBvZmZsaW5lIG1lc3NhZ2luZywgcmVjZWl2ZSBub3RpZmlj YXRpb25zLCBzZW5kaW5nIHBpY3R1cmVzLCBncm91cA0KPmNoYXRzLCBzeW5jIGJldHdlZW4gZGV2 aWNlcywgdXNhYmxlIGVuY3J5cHRpb24sIHN0aWNrZXJzIGFuZCB0aGUgaG9seQ0KPmdyYWlsOiBm ZWRlcmF0aW9uLiBJcyB0aGlzIG5vdCBzb2x2ZWQgYnkgU2lnbmFsIG5vd2FkYXlzPw0KDQorMSwg bW9yZSBhcHBsaWNhdGlvbnMgYW5kIHJlcXVpcmVtZW50cyBhcHBlYXIsIG1vcmUgY2xpZW50cyB3 aWxsIGJlIGNyZWF0ZWQuDQpIb3dldmVyLCB0aGVzZSBuZXcgY2xpZW50cyB3aWxsIHRyaWdnZXIg dGhlIHByb2Nlc3Mgb2Ygc3RhbmRhcmQgZGVzaWduIGFzIHdlbGwgYW5kIGhvcGUgbmV3IHN0YW5k YXJkIGNvdWxkIHJlZHVjZSB0aGUgd29ya2xvYWRzDQoNCg0KPg0KPkluIHRoZW9yeSBpdCBpcyBh IGdyZWF0IGlkZWEgYW5kIEknZCBhZ3JlZSB3aXRoIHlvdSwgYnV0IGluIHByYWN0aWNlIG5vdA0K PnNvIG11Y2guIEtJU1MgaXMga2V5IGhlcmUuIEknZCByZWNvbW1lbmQgYnVpbGRpbmcgb24gdGVj aG5vbG9neSB0aGF0IGlzDQo+YWxyZWFkeSB0aGVyZSwgd29ya2luZyBhbmQgcHJvdmVuIGFuZCBm cmVlIQ0KPg0KPkNoZWVycywNCj5GcmFuP29pcw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+U3Rv cmFnZXN5bmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0b3JhZ2VzeW5j From nobody Thu Dec 3 19:27:20 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAECF1B2B5D for ; Thu, 3 Dec 2015 19:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOIjZQyE5YuG for ; Thu, 3 Dec 2015 19:27:18 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4E91B2B63 for ; Thu, 3 Dec 2015 19:27:17 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygDnyB2oCGFWxzUHAA--.5593S2; Fri, 04 Dec 2015 11:29:44 +0800 (CST) Date: Fri, 4 Dec 2015 11:27:05 +0800 From: "Fei Song" To: =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= , storagesync References: <1449177286.2507848.457409737.10AEAB2B@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120411270531225432@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygDnyB2oCGFWxzUHAA--.5593S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXrWDCw17tF4fZF1Uuw1Utrb_yoW5tr4fpF yfKFy2ka1DJr4xJ3ykAw17XFW8Ar93Jw45JFn8Kryxua9xu342grySy34FgF9rCr93A3yj vrW09Fs8C3sYyFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU5 iVy3UUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: mellon Subject: Re: [Storagesync] Mechanisms to synchronize client file systems with Internet-based data storage services X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 03:27:20 -0000 SGkgSHVnbywNCg0KSSB0aGluayB0aGUgY29uZGl0aW9uIG1lbnRpb25lZCBieSBUZWQgaXMgbW9y ZSBnZW5lcmljLihwbGVhc2UgY29ycmVjdCBtZSBoZXJlKQ0KSXQgd291bGQgYmUgdXNlZnVsIHRv IGRpc2N1c3MgYSBjb21tb24gc2NlbmFyaW8uDQpEbyB5b3UgaGF2ZSBhbnkgZ29vZCBhcHByb2Fj aGVzIChvciBzb21lIGV4YW1wbGVzKSB0byBzZXBlcmF0ZSB0aGUgbWV0YWRhdGEgYW5kIGRhdGE/ DQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KPg0KPj5UaHVyc2RheSwgRGVjIDMsIDIwMTUg MTo0MSBQTSBKYWt1YiBNb3NjaWNraSB3cm90ZToNCj4+Q291bGQgeW91IHBsZWFzZSBleHBsYWlu IHdoeSB5b3UgdGhpbmsgaXQgZG9lcyBub3Qgc2NhbGU/IFRoZXJlIGFyZSBzY2hlbWVzIGluIHdo aWNoIHlvdSBkbyBub3QgbmVlZCB0byBwcm9wZmluZCA+dGhlIGVudGlyZSByZW1vdGUgdHJlZSB0 byBkaXNjb3ZlciBjaGFuZ2VzLCBvbmx5IGEgc2VxdWVuY2Ugb2YgcHJvcGZpbmRzIGluIGEgZGly ZWN0IHBhdGggbGVhZGluZyB0byBhIGNoYW5nZWQgPmVudGl0eS4gVGhhdKGvcyBub3Qgb3B0aW1h bCBmb3Igc3VyZSAoc2V2ZXJhbCBjYWxscyBuZWVkZWQsIGRlcGVuZGluZyBvbiB0aGUgZGVwdGgg b2YgdGhlIGNoYW5nZSkgYnV0IGlmIGl0IGNvbWVzIHRvID5XZWJEQVYgaXRzZWxmLCBhcGFydCBm cm9tIGEgYmxvYXRlZCBYTUwgcmVwcmVzZW50YXRpb24sIEkgZG8gbm90IHNlZSBtdWNoIHByb2Js ZW0uDQo+DQo+Pkl0IGRvZXNuJ3Qgc2NhbGUgYmVjYXVzZSB5b3UndmUganVzdCBkZXNjcmliZWQg YSBsb2Nrc3RlcCBwcm9jZXNzIGZvciBsb2NhdGluZyBjaGFuZ2VzOyBpbnN0ZWFkIG9mIHRoZXJl IGJlaW5nIG9uZSA+dHJhbnNhY3Rpb24gdG8gZ2V0IHRoZSBzZXQgb2YgY2hhbmdlcyBmcm9tIGEg a25vd24gY29tbW9uIHZlcnNpb24sIHlvdSBoYXZlIG11bHRpcGxlIHN0ZXBzLCBhbmQgdGhlIG51 bWJlciBvZiA+c3RlcHMgaW5jcmVhc2VzIGF0IGxlYXN0IGxvZ2FyaXRobWljYWxseSAoSSBhbSBn dWVzc2luZywgc2luY2UgSSBkb24ndCBrbm93IHlvdXIgYWxnb3JpdGhtKSBhcyB0aGUgbnVtYmVy IG9mID5jaGFuZ2VzIHNpbmNlIGxhc3Qgc3luYyBpbmNyZWFzZXMgb3IgdGhlIHNpemUgb2YgdGhl IHRyZWUgaW5jcmVhc2VzLiAgIElmIHlvdSBhcmUgc3luY2luZyBjb250aW51b3VzbHkgdGhpcyBt YXkgbm90ID5iZSBhIGJpZyBkZWFsLCBidXQgSSBkb24ndCB0aGluayB0aGF0J3MgYSByZWFzb25h YmxlIGFzc3VtcHRpb24uDQo+DQo+VGhpcyBkZXBlbmRzIG9uIHdoaWNoIHBhcnQgb2YgeW91ciBz eXN0ZW0geW91IHdhbnQgdG8gcHV0IHRoZQ0KPnN5bmNocm9uaXNhdGlvbiBsb2dpYy4gVGhlIGFw cHJvYWNoIEpha3ViIGhhcyBkZXNjcmliZWQgZGVsZWdhdGVzIHRoZQ0KPnN5bmMgcmVzcG9uc2li aWxpdHkgdG8gY2xpZW50cyBhbmQgdGhlIHNlcnZlciBkb2VzIG5vdCBkbyB0b28gbXVjaCBqb2IN Cj5hbmQgY2FuIHNjYWxlICB0byBoYW5kbGUgdGhlIGJsYXN0IG9mIHBvc3NpYmxlIFBST1BGSU5E IHJlcXVlc3RzLg0KPk9uIHRoZSBvdGhlciBoYW5kLCBhcyB5b3UgbWVudGlvbmVkLCB0aGUgc2Vy dmVyIGNhbiBmYWNpbGl0YXRlIHRoZSBzeW5jDQo+am9iIHRvIGNsaWVudHMgY3JlYXRpbmcgc25h cHNob3RzIG9mIHRoZSBzeXN0ZW0gaW4gYSBnaXZlbiBtb21lbnQgYW5kDQo+Z2l2ZSB0aGUgY2xp ZW50cyBhIGRlbHRhLiBUaGlzIGFwcHJvYWNoIHB1dHMgbXVjaCBtb3JlIGxvYWQgb24gdGhlDQo+ c2VydmVyIGFuZCBpdCBpcyBtb3JlIGRpZmZpY3VsdCB0byBzY2FsZS4NCj5Cb3RoIHR5cGVzIG9m IHN5bmMgaGFzIHRoZWlyIG93biBiZW5lZml0cyBhbmQgZHJhd2JhY2tzIGFuZCB0aGUgZWxlY3Rp b24NCj5zaG91bGQgYmUgbWFkZSBvbiB0aGUgdXNlIGNhc2UgeW91IHdhbnQgZm9yIHlvdXIgYnVz aW5lc3MuDQo+DQo+PlRoaXMgYWxzbyBoYXMgdGhlIHByb2JsZW0gdGhhdCB5b3UgaGF2ZSBubyBz ZXBhcmF0aW9uIG9mIG1ldGFkYXRhIGFuZCBkYXRhLCBhbmQgbm8gdmVyc2lvbmluZywgd2hpY2gg bWVhbnMgdGhhdCA+eW91IGhhdmUgdG8gaGF2ZSBhIGNsaWVudC1zZXJ2ZXIgbW9kZWwsIGFuZCB5 b3UgY2FuJ3QgaGF2ZSBhIGRpc3RyaWJ1dGVkIHBlZXIgbW9kZWwuDQo+DQo+SSB0b3RhbGx5IGRp c2FncmVlIGhlcmUsIHlvdSBjYW4gaGF2ZSB5b3VyIG1ldGFkYXRhIGZ1bGx5IGRldGFjaGVkIGZy b20NCj50aGUgZGF0YSBhbmQgYmUgYWJsZSB0byBzeW5jLiBBbHNvLCB5b3UgY2FuIGV4cG9zZSB2 ZXJzaW9ucyB0cm91Z2gNCj5XZWJEQVYgY3JlYXRpbmcgeW91ciBvd24gbG9naWMgb3IgdXNlIFdl YkRBViBleHRlbnNpb25zIHRoYXQgZGVhbCB3aXRoDQo+dGhhdC4gVGhlIFJGQyBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmMvcmZjMzI1My50eHQgZ2l2ZXMgR0lULWxpa2UNCj52ZXJzaW9uIGNvbnRy b2wgdG8gV2ViREFWIFJlc291cmNlcy4NCj4NCj4+T2tleSwgYnV0IHdoYXQgeW91IG5lZWQgdG8g cmVtZW1iZXIgdGhlIGNsaWVudCBzdGF0ZSBhbmQgcGFzcyBpdCBvbiB0byB0aGUgc2VydmVyIHRv IGNhbGN1bGF0ZSB0aGUgZGlmZiBzdGF0ZS4gQW55ID5nb29kIGlkZWFzIGhvdyB0byBkbyB0aGF0 Pw0KPg0KPj5LZWVwIHRoZSBtZXRhZGF0YSBzb3J0ZWQgKGUuZy4gYnkgbW9kaWZpY2F0aW9uIHRp bWUpLCBhbmQgZG8gYSBkaWZmIHdoZW5ldmVyIGEgbmV3IHZlcnNpb24gaXMgZ2VuZXJhdGVkLiAg IFZlcnNpb25zID50aGF0IGhhdmUgbmV2ZXIgYmVlbiBzaGFyZWQgd2l0aCBvdGhlciBwZWVycyBz aG91bGQgYmUgdHJpbW1lZCBvbmNlIHRoZXkgYXJlIG5vdCB0aGUgaGVhZCB2ZXJzaW9uLiAgIFdo ZW4gcGVlciA+QSB3YW50cyB0byBzeW5jIHdpdGggcGVlciBCLCBpdCBhbm5vdW5jZXMgdGhlIHZl cnNpb24gaXQgaGFzIGFuZCB0aGUgdmVyc2lvbiBpdCBsYXN0IHJlbWVtYmVycyBzeW5jaW5nIHdp dGggcGVlciBCLiAgID5JZiBQZWVyIEIgcmVtZW1iZXJzIHRoYXQgdmVyc2lvbiwgdGhlbiB0aGUg ZGlmZmVyZW5jZSBjYW4gYmUgY29tcHV0ZWQgdHJpdmlhbGx5LCBPKG4pLCBhbmQgaXMgbWluaW1h bCAobioyIGF0IHdvcnN0KSwgPndoZXJlIG4gaXMgdGhlIG51bWJlciBvZiBjaGFuZ2VzLiAgIElm IFBlZXIgQiBoYXMgbG9zdCBpdHMgbWVtb3J5LCB0aGVuIGl0IGhhcyB0byBzZW5kIHRoZSBjb21w bGV0ZSBpbnZlbnRvcnkgb2YgaXRzID5oZWFkIHZlcnNpb24sIHdoaWNoIFBlZXIgQSBjYW4gdGhl biBjb21wYXJlIHdpdGggaXRzIGhlYWQgdG8gc2VlIHdoYXQncyBjaGFuZ2VkLg0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMg bWFpbGluZyBsaXN0DQo+U3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5j From nobody Thu Dec 3 19:52:08 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DAD1B2C9A for ; Thu, 3 Dec 2015 19:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWkZN3THnVmt for ; Thu, 3 Dec 2015 19:52:05 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 515981B2C98 for ; Thu, 3 Dec 2015 19:52:05 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygCXoKKGDmFWDgAAAA--.6S2; Fri, 04 Dec 2015 11:54:46 +0800 (CST) Date: Fri, 4 Dec 2015 11:52:05 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120411520301597733@bjtu.edu.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart202603565401_=----" X-CM-TRANSID: M55wygCXoKKGDmFWDgAAAA--.6S2 X-Coremail-Antispam: 1UD129KBjvdXoWrtr4DZrW8Ww17Cry5Aw43Jrb_yoWftrg_Wa 1ftryv9w45Ww17JF1rG3Z3Wr4UAFyvkFyUCay8KF1jg34qvFs5uFn8WFZ3ZF48XFsIq3Z8 Ca43Z347Cw13ujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbDAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWxJr0_ GcWl84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVWUJVW8JwAqx4xG6c804VAF z4xC04v7Mc02F40Ew4AK048IF2xKxVW8JVW5JwAqx4xG6xAIxVCFxsxG0wAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCY02 Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8G jcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2I x0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK 8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6x kF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jz4iUU UUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 03:52:07 -0000 This is a multi-part message in MIME format. ------=_001_NextPart202603565401_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24uIEkgY2xhc3NpZmllZCB0aGVtIGEgYml0LiBQbGVh c2UgZW1haWwgbWUgaWYgYW55dGhpbmcgaXMgbWlzc2VkOg0KIA0KMS4gICAgICAgICBUaGUgZGVz aWduIHRhcmdldHMgb2YgV2ViREFWLCByc3luYyBhbmQgb3RoZXIgZXhpc3RpbmcgYXBwcm9hY2hl cz8NCjIuICAgICAgICAgVGhlIHBvdGVudGlhbCB1c2UgY2FzZXMgb2YgSVNTLCBzdWNoIGFzIGNs aWVudC9zZXJ2ZXIsIGdpdC1saWtlIHBhdHRlcm4sIHN2biwgZXRjLg0KMy4gICAgICAgICBUaGUg ZWZmaWNpZW5jeSBpbXByb3ZlbWVudHMgbWlnaHQgYmUgdGhlIHNlY29uZCBnb2FsIGZvciBzdGFu ZGFyZGl6aW5nIElTUyBwcm90b2NvbA0KNC4gICAgICAgICBDT1JTIGhlYWRlcnMgb24gc3RvcmFn ZSBzeW5jIEFQSXMNCjUuICAgICAgICAgV2hhdCBpcyBuZWVkZWQgZm9yIHRoZSBJU1M6IGEgc3lu YyBwcm90b2NvbCBvciBhIGdlbmVyYWxpemVkIEFQSQ0KNi4gICAgICAgICByZW1vdGVTdG9yYWdl IGRyYWZ0IGRpc2N1c3Npb24NCmEpICAgICAgICAgcmVsYXRpb25zaGlwIHZzIFdlYkRBVg0KYikg ICAgICAgICBNT1ZFIGFjdGlvbiBzaG91bGQgYmUgYWRkZWQgb3Igbm90DQpjKSAgICAgICAgIHN5 bmNocm9uaXphdGlvbiBzaG91bGQgYmUgY29uc2lkZXJlZCBvciBub3QNCmQpICAgICAgICAgY29t aWNzIG9mIG5ldyBzdGFuZGFyZA0KNy4gICAgICAgICBHaXRIdWIgaW5zdGVhZCBvZiBlbWFpbCBt ZXNzYWdlcw0KYSkgICAgICAgICBXaGF0IGlzIHRoZSB0b3BpYz8gDQogICAgICAgICAgICAgICAg ICAgICAgICAgaS4gICAgICAgICAgICAgIFdoZXRoZXIgaXQgaXMgc3VpdGFibGUgdG8gYnVpbGQg b24gV2ViREFWDQogICAgICAgICAgICAgICAgICAgICAgIGlpLiAgICAgICAgICAgICAgV2ViREFW IHZzIHJlbW90ZVN0b3JhZ2UNCiAgICAgICAgICAgICAgICAgICAgICBpaWkuICAgICAgICAgICAg ICBBZHZhbnRhZ2VzIHZzIGRpc2FkdmFudGFnZXMgb2YgV2ViREFWDQogDQogDQpTb21lIHJlbGF0 ZWQgb3JnYW5pemF0aW9ucywgZXZlbnRzLCBwcm9qZWN0cywgZXRjLjogDQpHRUFOVCBjb21tdW5p dHksIE9wZW5DbG91ZE1lc2gsIG93bkNsb3VkLCBDUzMsIHJlbW90ZVN0b3JhZ2UsIENsYXdJTywg Y3Jvc3NjbG91ZCwgdG8gYmUgYWRkZWShrQ== ------=_001_NextPart202603565401_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Here is the latest version. I classified the= m a bit.=20 Please email me if anything is missed:

 <= /P> 1.      =   =20 The = design=20 targets of WebDAV, rsync and other existing approaches?

2.      =   =20 The = potential=20 use cases of ISS, such as client/server, git-like pattern, svn,=20 etc.

3.      =   =20 The = efficiency=20 improvements might be the second goal for standardizing ISS=20 protocol

4.      =   =20 CORS= headers on=20 storage sync APIs

5.      =   =20 What= is needed=20 for the ISS: a sync protocol or a generalized API

6.      =   =20 remo= teStorage=20 draft discussion

a)      =   =20 rela= tionship vs=20 WebDAV

b)      =   =20 MOVE= action=20 should be added or not

c)      =   =20 sync= hronization=20 should be considered or not

d)      =   =20 comi= cs of new=20 standard

7.      =   =20 GitH= ub instead=20 of email messages

a)      =   =20 What= is the=20 topic?

      =             &n= bsp;     =20 i.      =        =20 Whether it=20 is suitable to build on WebDAV

      =             &n= bsp;   =20 ii.      =        =20 WebDAV vs=20 remoteStorage

      =             &n= bsp;  =20 iii.      =        =20 Adva= ntages vs=20 disadvantages of WebDAV

 

 

Some related organizations, events, projects, etc.:=20

GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorag= e,=20 ClawIO, crosscloud, to be=20 added=A1=AD

------=_001_NextPart202603565401_=------ From nobody Thu Dec 3 19:53:50 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBF41B2CAE for ; Thu, 3 Dec 2015 19:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqL4I9L8zR0j for ; Thu, 3 Dec 2015 19:53:46 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA311B2CB1 for ; Thu, 3 Dec 2015 19:53:44 -0800 (PST) Received: by wmec201 with SMTP id c201so56109034wme.0 for ; Thu, 03 Dec 2015 19:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RtAvqJJipvSEvPloRxLWM+xvsaEdEVTn0zb7Bc9kcfE=; b=c1yhkFqPtW11dT5shS7+dWaG84skuySZQ4MNUM9VSxdXVHReXOIjYX7tDRT+/eH1D7 xXO9/kRyAIBkhWn4JvGMV1qoA08DH+KqGlBU+aSpcNhh/Yowjvx+B5MTRW5nN9jmGuEP JghOIa7FaNJpa+fJEVW+m/HJAzB+XSgpnuSOiDYnt94oXTgrczTzXWqjvw55/+qAhjTE sQh2zZoLwasZmK0ZGieyINdui+iYuuKIpi2/gZIK/wYPgU6WlsN4mN1zHMSs8G8XOhvX nXxfxop0wWbbudiuPium6wPIYVjpvI9z+sCAeKUVi6vWgewPi2+PldTm3vAxU3WU92h7 a2Ew== X-Received: by 10.194.79.72 with SMTP id h8mr16267962wjx.136.1449201222726; Thu, 03 Dec 2015 19:53:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Thu, 3 Dec 2015 19:53:23 -0800 (PST) In-Reply-To: <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> From: Linhui Sun Date: Fri, 4 Dec 2015 11:53:23 +0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bb0499e16b8ce05260a7456 Archived-At: Cc: Jakub Moscicki , storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 03:53:49 -0000 --047d7bb0499e16b8ce05260a7456 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-12-04 3:14 GMT+08:00 Ted Lemon : > Thursday, Dec 3, 2015 1:41 PM Jakub Moscicki wrote: > > Could you please explain why you think it does not scale? There are > schemes in which you do not need to propfind the entire remote tree to > discover changes, only a sequence of propfinds in a direct path leading t= o > a changed entity. That=E2=80=99s not optimal for sure (several calls need= ed, > depending on the depth of the change) but if it comes to WebDAV itself, > apart from a bloated XML representation, I do not see much problem. > > It doesn't scale because you've just described a lockstep process for > locating changes; instead of there being one transaction to get the set o= f > changes from a known common version, you have multiple steps, and the > number of steps increases at least logarithmically (I am guessing, since = I > don't know your algorithm) as the number of changes since last sync > increases or the size of the tree increases. If you are syncing > continuously this may not be a big deal, but I don't think that's a > reasonable assumption. > Agree. In my view, the key problem is not about how to reduce the number of propfinds but how to come up with an improved method to replace the existing pattern. > > This also has the problem that you have no separation of metadata and > data, and no versioning, which means that you have to have a client-serve= r > model, and you can't have a distributed peer model. > Separation of metadata and data is better. But I don't understand why we need a distributed peer model. C/S model could still work fine with such separation. > > > Okey, but what you need to remember the client state and pass it on to > the server to calculate the diff state. Any good ideas how to do that? > > Keep the metadata sorted (e.g. by modification time), and do a diff > whenever a new version is generated. Versions that have never been shar= ed > with other peers should be trimmed once they are not the head version. > When peer A wants to sync with peer B, it announces the version it has a= nd > the version it last remembers syncing with peer B. If Peer B remembers > that version, then the difference can be computed trivially, O(n), and is > minimal (n*2 at worst), where n is the number of changes. If Peer B has > lost its memory, then it has to send the complete inventory of its head > version, which Peer A can then compare with its head to see what's change= d. > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mellon@fugue.com > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --047d7bb0499e16b8ce05260a7456 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-04 3:14 GMT+08:00 Ted Lemon <mellon@fugue.com>:
Thursday, Dec 3, 2015 1:41 PM Jakub = Moscicki wrote:
> Could you please explain why you think it does not scale? There are sc= hemes in which you do not need to propfind the entire remote tree to discov= er changes, only a sequence of propfinds in a direct path leading to a chan= ged entity. That=E2=80=99s not optimal for sure (several calls needed, depe= nding on the depth of the change) but if it comes to WebDAV itself, apart f= rom a bloated XML representation, I do not see much problem.

It doesn't scale because you've just described a lockstep pr= ocess for locating changes; instead of there being one transaction to get t= he set of changes from a known common version, you have multiple steps, and= the number of steps increases at least logarithmically (I am guessing, sin= ce I don't know your algorithm) as the number of changes since last syn= c increases or the size of the tree increases.=C2=A0 =C2=A0If you are synci= ng continuously this may not be a big deal, but I don't think that'= s a reasonable assumption.
Agree. In my view, the key = problem is not about how to reduce the number of propfinds but how to come = up with an improved method to replace the existing pattern.

This also has the problem that you have no separation of metadata and data,= and no versioning, which means that you have to have a client-server model= , and you can't have a distributed peer model.
Sep= aration of metadata and data is better. But I don't understand why we n= eed a distributed peer model. C/S model could still work fine with such sep= aration.

> Okey, but what you need to remember the client state and pass it on to= the server to calculate the diff state. Any good ideas how to do that?

Keep the metadata sorted (e.g. by modification time), and do a diff = whenever a new version is generated.=C2=A0 =C2=A0Versions that have never b= een shared with other peers should be trimmed once they are not the head ve= rsion.=C2=A0 =C2=A0When peer A wants to sync with peer B, it announces the = version it has and the version it last remembers syncing with peer B.=C2=A0= =C2=A0If Peer B remembers that version, then the difference can be compute= d trivially, O(n), and is minimal (n*2 at worst), where n is the number of = changes.=C2=A0 =C2=A0If Peer B has lost its memory, then it has to send the= complete inventory of its head version, which Peer A can then compare with= its head to see what's changed.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com

_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync


--047d7bb0499e16b8ce05260a7456-- From nobody Thu Dec 3 19:54:38 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D210E1B2CAE for ; Thu, 3 Dec 2015 19:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAFCtQR1sNaN for ; Thu, 3 Dec 2015 19:54:36 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id C51811B2CA3 for ; Thu, 3 Dec 2015 19:54:35 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492012705610.9377071233466268" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <2015120411270531225432@bjtu.edu.cn> References: <1449177286.2507848.457409737.10AEAB2B@webmail.messagingengine.com> <2015120411270531225432@bjtu.edu.cn> Date: Fri, 04 Dec 2015 03:54:30 +0000 Message-Id: <1449201270885-396c6fe9-59ad7779-e6224fc2@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Mechanisms to synchronize client file systems with Internet-based data storage services X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 03:54:38 -0000 ------sinikael-?=_1-14492012705610.9377071233466268 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 10:27 PM Fei Song wrote: > I think the condition mentioned by Ted is more generic.(please correct me= here) RFC 3253 would basically meet my use case, but has the problems I mentioned= earlier. Jakub is right that what I suggest would impose a greater load = on the core repository if there is one, but this is a problem that github = has solved, so I don't think that's really a serious issue--if it works = with github's funding model, it probably would work with Box/Google/etc. = But to be fair, I am not personally really concerned about whether it works= with Box/Google/etc. They may already consider what they have =22good = enough=22 and not be interested in what we are discussing here. That was = certainly Igor's and EKR's position at the microphone in Yokohama! One of my big concerns with RFC 3253 is that because it's piggybacked on = top of WebDAV, it's really complicated. It's quite an achievement to do = that with WebDAV's native architecture, and I'm willing to be convinced = that it's good enough, but I've never heard of an implementation of RFC = 3253 that I could use. Hm, actually I'm not sure it was Jakub who was talking about RFC 3253--the = threading got a bit confusing in there. If I got that wrong, apologies! -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14492012705610.9377071233466268 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYQ53CRAMw8Nu0HeKywAAtPAH/iHx1IbSmk+gkO97h8Zx giHLnRKcA7YObZGB2GxFucjYeMlu9TFEcGIkKH3uzOkRdIzgnqnA1P+GH7I+ pgdfSQdiiTzU/9WHQqEBPkWNJqpvaDsE/XQk2mUHksYKL67zGnerXXAUZQo7 O9dimaDPqyRBU7QlZ1dLKnWenRZI8uO3rNyqQ3RYuOZLVKtdluEoeffDIWlw 4jUom4e7gBsqMzE15bc3MMf5TyPpz44T34ocRYUyHuAdlGd+qgOiEioTvz1k /yluo3Zu1OQp0w9KrujS8ffWjo4EZyHwcIjIXZ0aysO43euSDnRsAWH0beXV nidge8CTYcJAOHO41/ZTLmU= =5e+T -----END PGP SIGNATURE----- ------sinikael-?=_1-14492012705610.9377071233466268-- From nobody Fri Dec 4 05:48:00 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B111B31A3 for ; Fri, 4 Dec 2015 05:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZV4eFR2r6Mw for ; Fri, 4 Dec 2015 05:47:57 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BACF1B319C for ; Fri, 4 Dec 2015 05:47:57 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7A5C720443 for ; Fri, 4 Dec 2015 08:47:56 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Fri, 04 Dec 2015 08:47:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=MMdwwgeXxdK1lKasnjIXg+SilEA=; b=l38QlK dOgUqbK/0kIpBPldwG3o6J8s9nYdf4gOYYxN38s2GYeTteKHY40RnG7CIcj4JLYw B8oIO2VRYnxbxG0+Z1V4H2EBOcVnm25M96tbS5k8MRSn0aWphlf6EobYVGvjA7P1 4pg0OQopuB+pjQF42kwORyqhJThuxSa06cXYk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=MMdwwgeXxdK1lKa snjIXg+SilEA=; b=iEkbY1bLL/lrImn5LeYm1ff1x6/bYDtOV6sboY0jE+0wluo WLbTOgwhQI0V0+pOxUgQdivNYiNojx3E50KgRXHknZC8A0/9FplHRWTCWGkWzgCs +p8H/cMG3TSZNMKn1U5bUPUTtAdr8kY+QDd7HcT8ttKLDBdApxHKGty0oFhE= Received: by web2.nyi.internal (Postfix, from userid 99) id 3FE24540540; Fri, 4 Dec 2015 08:47:56 -0500 (EST) Message-Id: <1449236876.216680.458015521.42999C02@webmail.messagingengine.com> X-Sasl-Enc: FeDty+cxjjhaAplOb+qQd8oNyML0sRFl6WDLUFfL8/Pq 1449236876 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: fsong , storagesync MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 Date: Fri, 04 Dec 2015 14:47:56 +0100 In-Reply-To: <2015120411270531225432@bjtu.edu.cn> References: <1449177286.2507848.457409737.10AEAB2B@webmail.messagingengine.com> <2015120411270531225432@bjtu.edu.cn> Archived-At: Cc: mellon Subject: Re: [Storagesync] Mechanisms to synchronize client file systems with Internet-based data storage services X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 13:47:59 -0000 On Fri, Dec 4, 2015, at 04:27 AM, Fei Song wrote: > Hi Hugo, >=20 > I think the condition mentioned by Ted is more generic.(please correct me > here) > It would be useful to discuss a common scenario. > Do you have any good approaches (or some examples) to separate the > metadata and data? >=20 There are already synchronisation platforms built on top of such concept. Usually, an object storage service like Amazon S3/ OpenStack Swift/Ceph RadosGW is used just to keep binary data in a fast flat namespace. Then, a supporting component, detached from the data store, keeps track of which metadata is attached to the data. This metadata includes mtimes, Etags, paths and platform ACLs among others. I know some products that use this approach: - ownCloud when configured to use an Object Storage as the Primary User Storage. (Metadata is handled by a MySQL database) - CERN EOS Storage System. (Metadata is handled in high performance in-memory structures). - DropBox. (As far as I know it uses S3 behind. For metadata it is unknown, but probably not on S3). - ClawIO will have an implementation of this approach in the next phase using Swift. > -------------- > Fei Song > > > >>Thursday, Dec 3, 2015 1:41 PM Jakub Moscicki wrote: > >>Could you please explain why you think it does not scale? There are sch= emes in which you do not need to propfind >the entire remote tree to discov= er changes, only a sequence of propfinds in a direct path leading to a chan= ged >entity. That=E2=80=99s not optimal for sure (several calls needed, dep= ending on the depth of the change) but if it comes to >WebDAV itself, apart= from a bloated XML representation, I do not see much problem. > > > >>It doesn't scale because you've just described a lockstep process for l= ocating changes; instead of there being one >transaction to get the set of = changes from a known common version, you have multiple steps, and the numbe= r of >steps increases at least logarithmically (I am guessing, since I don'= t know your algorithm) as the number of >changes since last sync increases = or the size of the tree increases. If you are syncing continuously this m= ay not >be a big deal, but I don't think that's a reasonable assumption. > > > >This depends on which part of your system you want to put the > >synchronisation logic. The approach Jakub has described delegates the > >sync responsibility to clients and the server does not do too much job > >and can scale to handle the blast of possible PROPFIND requests. > >On the other hand, as you mentioned, the server can facilitate the sync > >job to clients creating snapshots of the system in a given moment and > >give the clients a delta. This approach puts much more load on the > >server and it is more difficult to scale. > >Both types of sync has their own benefits and drawbacks and the election > >should be made on the use case you want for your business. > > > >>This also has the problem that you have no separation of metadata and d= ata, and no versioning, which means that >you have to have a client-server = model, and you can't have a distributed peer model. > > > >I totally disagree here, you can have your metadata fully detached from > >the data and be able to sync. Also, you can expose versions trough > >WebDAV creating your own logic or use WebDAV extensions that deal with > >that. The RFC https://www.ietf.org/rfc/rfc3253.txt gives GIT-like > >version control to WebDAV Resources. > > > >>Okey, but what you need to remember the client state and pass it on to = the server to calculate the diff state. Any >good ideas how to do that? > > > >>Keep the metadata sorted (e.g. by modification time), and do a diff whe= never a new version is generated. Versions >that have never been shared w= ith other peers should be trimmed once they are not the head version. Whe= n peer >A wants to sync with peer B, it announces the version it has and th= e version it last remembers syncing with peer B. >If Peer B remembers tha= t version, then the difference can be computed trivially, O(n), and is mini= mal (n*2 at worst), >where n is the number of changes. If Peer B has lost= its memory, then it has to send the complete inventory of its >head versio= n, which Peer A can then compare with its head to see what's changed. > > > >_______________________________________________ > >Storagesync mailing list > >Storagesync@ietf.org > >https://www.ietf.org/mailman/listinfo/storagesync From nobody Fri Dec 4 06:34:57 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927891A6FFC for ; Fri, 4 Dec 2015 06:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omMvLebdzRIj for ; Fri, 4 Dec 2015 06:34:53 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2631A6FF6 for ; Fri, 4 Dec 2015 06:34:52 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492396895770.6240086636971682" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <1449236876.216680.458015521.42999C02@webmail.messagingengine.com> References: <1449177286.2507848.457409737.10AEAB2B@webmail.messagingengine.com> <2015120411270531225432@bjtu.edu.cn> <1449236876.216680.458015521.42999C02@webmail.messagingengine.com> Date: Fri, 04 Dec 2015 14:34:49 +0000 Message-Id: <1449239689891-13379e89-8a9153c2-3597d400@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Mechanisms to synchronize client file systems with Internet-based data storage services X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 14:34:55 -0000 ------sinikael-?=_1-14492396895770.6240086636971682 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Friday, Dec 4, 2015 8:47 AM Hugo Gonz=C3=A1lez Labrador wrote: > There are already synchronisation platforms built on top of such > concept. > [...] > - ownCloud when configured to use an Object Storage as the Primary User > Storage. (Metadata is handled by a MySQL database) > - CERN EOS Storage System. (Metadata is handled in high performance > in-memory structures). Oh, that's very interesting. Thanks for pointing that out. I'm (a) glad= to know that it's not just me, and (b) interested in what ownCloud and = Cern have done. I had looked at ownCloud a while back and decided that I = wasn't interested, but now I'm curious again. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14492396895770.6240086636971682 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYaSKCRAMw8Nu0HeKywAA7YoIAJS+eKk/2fgU8ZBjx6BE uZenYcCUVrJvBhowHTXXdfjQQZx3SCZOGpZSul2sgNYT+M8TyrnDr9U5eFiD SKm2gWddUjRI4chmsR1AKyJDZl5wMsbG+7koP1bHZdvh4dzmZ0+CSiGVF/Gb Q2L5+BdPmhtpNKzOnXofadJ7YJ3i9t0AB7xgXtyR0eTSEgKDodAwS8mPNbX/ bJyHjRxlt2MvSe9MgqFUDds/pk7l7oHsH8eMm8d/Cbhi8/YuMaB1dMN3aAAC w/C/WFhegy4j650TUMVJt7FI+Zy4B17+dwXBMMmueuuF8e/lkOjsBEEuPkbr Ldxrw3B2CmHKg8vj0qBHBu8= =5KQ3 -----END PGP SIGNATURE----- ------sinikael-?=_1-14492396895770.6240086636971682-- From nobody Fri Dec 4 07:19:34 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286C51A8825 for ; Fri, 4 Dec 2015 07:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA0fQyuOkUDe for ; Fri, 4 Dec 2015 07:19:29 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0471A87C9 for ; Fri, 4 Dec 2015 07:18:54 -0800 (PST) Received: by wmww144 with SMTP id w144so68983250wmw.0 for ; Fri, 04 Dec 2015 07:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rW/Iq4k5G+zOvWh0+o38rV3//TNMU3+VxC0oY0dMbMg=; b=H5jEiv2ooByHURFFXp+sNvSrOLhNvuaasZg0bL0QO4AL+51/pUgCm74onvWRyLFMeP lRi2FV6nlB1D3z6NP3unnvjiPoAOiuIdZb+sOICC4qfv6BeLZkPBDOp4IxmP/R7PFt8L PhaJ0r37xPijaUUgohAz4MQUCb4MmyXpObURiqMl1arfvEKEArnRMCGnkZWJw1fQNedb 92t5YXznJhxSHCHhRAsrbsEHAf6OfAeOVBhuDp03HBhw5Ms8QTTOlK33StknfantGaQ3 4xSiBlBib4CF8k0zIEqNTJsfrNKJcHKfOkG3QR5vfLM4UnsoEDzA9U3YE33FD4171JbZ iTtg== X-Received: by 10.28.15.194 with SMTP id 185mr6048055wmp.9.1449242333195; Fri, 04 Dec 2015 07:18:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Fri, 4 Dec 2015 07:18:33 -0800 (PST) In-Reply-To: <1449236876.216680.458015521.42999C02@webmail.messagingengine.com> References: <1449177286.2507848.457409737.10AEAB2B@webmail.messagingengine.com> <2015120411270531225432@bjtu.edu.cn> <1449236876.216680.458015521.42999C02@webmail.messagingengine.com> From: Linhui Sun Date: Fri, 4 Dec 2015 23:18:33 +0800 Message-ID: To: =?UTF-8?Q?Hugo_Gonz=C3=A1lez_Labrador?= Content-Type: multipart/alternative; boundary=001a11469edc76b19505261406a3 Archived-At: Cc: fsong , storagesync , mellon Subject: Re: [Storagesync] Mechanisms to synchronize client file systems with Internet-based data storage services X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:19:33 -0000 --001a11469edc76b19505261406a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-12-04 21:47 GMT+08:00 Hugo Gonz=C3=A1lez Labrador : > > > On Fri, Dec 4, 2015, at 04:27 AM, Fei Song wrote: > > Hi Hugo, > > > > I think the condition mentioned by Ted is more generic.(please correct = me > > here) > > It would be useful to discuss a common scenario. > > Do you have any good approaches (or some examples) to separate the > > metadata and data? > > > > There are already synchronisation platforms built on top of such > concept. > > Usually, an object storage service like Amazon S3/ OpenStack Swift/Ceph > RadosGW is used just to keep binary data in a fast flat namespace. > > Then, a supporting component, detached from the data store, keeps track > of which metadata is attached to the data. This metadata includes > mtimes, Etags, paths and platform ACLs among others. > > I know some products that use this approach: > > - ownCloud when configured to use an Object Storage as the Primary User > Storage. (Metadata is handled by a MySQL database) > - CERN EOS Storage System. (Metadata is handled in high performance > in-memory structures). > - DropBox. (As far as I know it uses S3 behind. For metadata it is > unknown, but probably not on S3). > Yes, Dropbox uses its own control server for metadata management and S3 for content data. See http://annasperotto.org/papers/2012/imc140-drago.pdf > - ClawIO will have an implementation of this approach in the next phase > using Swift. > > > -------------- > > Fei Song > > > > > >>Thursday, Dec 3, 2015 1:41 PM Jakub Moscicki wrote: > > >>Could you please explain why you think it does not scale? There are > schemes in which you do not need to propfind >the entire remote tree to > discover changes, only a sequence of propfinds in a direct path leading t= o > a changed >entity. That=E2=80=99s not optimal for sure (several calls nee= ded, > depending on the depth of the change) but if it comes to >WebDAV itself, > apart from a bloated XML representation, I do not see much problem. > > > > > >>It doesn't scale because you've just described a lockstep process for > locating changes; instead of there being one >transaction to get the set = of > changes from a known common version, you have multiple steps, and the > number of >steps increases at least logarithmically (I am guessing, since= I > don't know your algorithm) as the number of >changes since last sync > increases or the size of the tree increases. If you are syncing > continuously this may not >be a big deal, but I don't think that's a > reasonable assumption. > > > > > >This depends on which part of your system you want to put the > > >synchronisation logic. The approach Jakub has described delegates the > > >sync responsibility to clients and the server does not do too much job > > >and can scale to handle the blast of possible PROPFIND requests. > > >On the other hand, as you mentioned, the server can facilitate the syn= c > > >job to clients creating snapshots of the system in a given moment and > > >give the clients a delta. This approach puts much more load on the > > >server and it is more difficult to scale. > > >Both types of sync has their own benefits and drawbacks and the electi= on > > >should be made on the use case you want for your business. > > > > > >>This also has the problem that you have no separation of metadata and > data, and no versioning, which means that >you have to have a client-serv= er > model, and you can't have a distributed peer model. > > > > > >I totally disagree here, you can have your metadata fully detached fro= m > > >the data and be able to sync. Also, you can expose versions trough > > >WebDAV creating your own logic or use WebDAV extensions that deal with > > >that. The RFC https://www.ietf.org/rfc/rfc3253.txt gives GIT-like > > >version control to WebDAV Resources. > > > > > >>Okey, but what you need to remember the client state and pass it on t= o > the server to calculate the diff state. Any >good ideas how to do that? > > > > > >>Keep the metadata sorted (e.g. by modification time), and do a diff > whenever a new version is generated. Versions >that have never been > shared with other peers should be trimmed once they are not the head > version. When peer >A wants to sync with peer B, it announces the versi= on > it has and the version it last remembers syncing with peer B. >If Peer = B > remembers that version, then the difference can be computed trivially, > O(n), and is minimal (n*2 at worst), >where n is the number of changes. > If Peer B has lost its memory, then it has to send the complete inventor= y > of its >head version, which Peer A can then compare with its head to see > what's changed. > > > > > >_______________________________________________ > > >Storagesync mailing list > > >Storagesync@ietf.org > > >https://www.ietf.org/mailman/listinfo/storagesync > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > --001a11469edc76b19505261406a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-04 21:47 GMT+08:00 Hugo Gonz=C3=A1lez Labrador <ietf@hugo.= labkode.com>:


On Fri, Dec 4, 2015, at 04:27 AM, Fei Song wrote:
> Hi Hugo,
>
> I think the condition mentioned by Ted is more generic.(please correct= me
> here)
> It would be useful to discuss a common scenario.
> Do you have any good approaches (or some examples) to separate = the
> metadata and data?
>

There are already synchronisation platforms built on top of such
concept.

Usually, an object storage service like Amazon S3/ OpenStack Swift/Ceph
RadosGW is used just to keep binary data in a fast flat namespace.

Then, a supporting component, detached from the data store, keeps track
of which metadata is attached to the data. This metadata includes
mtimes, Etags, paths and platform ACLs among others.

I know some products that use this approach:

- ownCloud when configured to use an Object Storage as the Primary User
Storage. (Metadata is handled by a MySQL database)
- CERN EOS Storage System. (Metadata is handled in high performance
in-memory structures).
- DropBox. (As far as I know it uses S3 behind. For metadata it is
unknown, but probably not on S3).
Yes, Dropbox uses it= s own control server for metadata management and S3 for content data. See= =C2=A0http= ://annasperotto.org/papers/2012/imc140-drago.pdf
- ClawIO will have an implementation of this approach in the next phase
using Swift.

> --------------
> Fei Song
> >
> >>Thursday, Dec 3, 2015 1:41 PM Jakub Moscicki wrote:
> >>Could you please explain why you think it does not scale? Ther= e are schemes in which you do not need to propfind >the entire remote tr= ee to discover changes, only a sequence of propfinds in a direct path leadi= ng to a changed >entity. That=E2=80=99s not optimal for sure (several ca= lls needed, depending on the depth of the change) but if it comes to >We= bDAV itself, apart from a bloated XML representation, I do not see much pro= blem.
> >
> >>It doesn't scale because you've just described a locks= tep process for locating changes; instead of there being one >transactio= n to get the set of changes from a known common version, you have multiple = steps, and the number of >steps increases at least logarithmically (I am= guessing, since I don't know your algorithm) as the number of >chan= ges since last sync increases or the size of the tree increases.=C2=A0 =C2= =A0If you are syncing continuously this may not >be a big deal, but I do= n't think that's a reasonable assumption.
> >
> >This depends on which part of your system you want to put the
> >synchronisation logic. The approach Jakub has described delegates = the
> >sync responsibility to clients and the server does not do too much= job
> >and can scale=C2=A0 to handle the blast of possible PROPFIND reque= sts.
> >On the other hand, as you mentioned, the server can facilitate the= sync
> >job to clients creating snapshots of the system in a given moment = and
> >give the clients a delta. This approach puts much more load on the=
> >server and it is more difficult to scale.
> >Both types of sync has their own benefits and drawbacks and the el= ection
> >should be made on the use case you want for your business.
> >
> >>This also has the problem that you have no separation of metad= ata and data, and no versioning, which means that >you have to have a cl= ient-server model, and you can't have a distributed peer model.
> >
> >I totally disagree here, you can have your metadata fully detached= from
> >the data and be able to sync. Also, you can expose versions trough=
> >WebDAV creating your own logic or use WebDAV extensions that deal = with
> >that. The RFC https://www.ietf.org/rfc/rfc3253.txt = gives GIT-like
> >version control to WebDAV Resources.
> >
> >>Okey, but what you need to remember the client state and pass = it on to the server to calculate the diff state. Any >good ideas how to = do that?
> >
> >>Keep the metadata sorted (e.g. by modification time), and do a= diff whenever a new version is generated.=C2=A0 =C2=A0Versions >that ha= ve never been shared with other peers should be trimmed once they are not t= he head version.=C2=A0 =C2=A0When peer >A wants to sync with peer B, it = announces the version it has and the version it last remembers syncing with= peer B.=C2=A0 =C2=A0>If Peer B remembers that version, then the differe= nce can be computed trivially, O(n), and is minimal (n*2 at worst), >whe= re n is the number of changes.=C2=A0 =C2=A0If Peer B has lost its memory, t= hen it has to send the complete inventory of its >head version, which Pe= er A can then compare with its head to see what's changed.
> >
> >_______________________________________________
> >Storagesync mailing list
> >Storagesync@ietf.org > >https://www.ietf.org/mailman/listinfo/sto= ragesync

_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync

--001a11469edc76b19505261406a3-- From nobody Fri Dec 4 07:27:07 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D3E1A87AE for ; Fri, 4 Dec 2015 07:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4HCJArSnC-t for ; Fri, 4 Dec 2015 07:27:04 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A9C1A888E for ; Fri, 4 Dec 2015 07:23:57 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DA8DF206A8 for ; Fri, 4 Dec 2015 10:23:56 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute5.internal (MEProxy); Fri, 04 Dec 2015 10:23:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=cGrE8bHL5nDkU+2e01ZHQuAkbVw=; b=dQ+xf6 3QAYN3qTo595dF0mLwwaGUOL/w40wb9A9t2ey0ed9MjJZ2lKMyLi2TPoIMXf6b3n jspjOxhb0JeEpt73GipMWxrK1kM3MoQlkfVA9rOtilvD6fJURU++3QdpE0YiNolc wmW/2i60a4cPGWk94kTws+/+1cUY0S/sYJfAE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=cGrE8bHL5nDkU+2 e01ZHQuAkbVw=; b=KoKcaZ0RRBY8Dd5U2GgvPaWIKNMIvpuvP3yJUGtrHEXAvn2 Oa07bH+ugI1/c2d2Ozrkwgsyday1xvarSm+2ld4KiJpcqV5KRvSys0SkU4qMIuM5 iJLqzx7x28ryc1crfWiAsMzI1OQzPYvGz13XQmhuBiS0Q2IeHAIdMkqqkqTc= Received: by web2.nyi.internal (Postfix, from userid 99) id 9EFD2540541; Fri, 4 Dec 2015 10:23:56 -0500 (EST) Message-Id: <1449242636.238506.458104225.0E52F458@webmail.messagingengine.com> X-Sasl-Enc: m2mXqW9yqd1PpsRGKzKE5f3uyY3kQSotw/FgyDdo+sbj 1449242636 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: storagesync@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 In-Reply-To: References: Date: Fri, 04 Dec 2015 16:23:56 +0100 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 29 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:27:06 -0000 As promised I=B4ve created a GitHub repo to keep track of supporting documents. Repo: https://github.com/labkode/Internet-Storage-Sync I took some liberty to create a basic structure. Please feel free to change it using the methods described in the repo or ask me directly. I gave the name: Applicability of using WebDAV as a synchronisation protocol meanwhile the name it's decided. We should start filling the gaps regarding this topic. Best, Hugo On Fri, Dec 4, 2015, at 03:34 PM, storagesync-request@ietf.org wrote: > Send Storagesync mailing list submissions to > storagesync@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/storagesync > or, via email, send a message with subject or body 'help' to > storagesync-request@ietf.org >=20 > You can reach the person managing the list at > storagesync-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Storagesync digest..." > Today's Topics: >=20 > 1. Re: Storagesync Digest, Vol 5, Issue 1 (Linhui Sun) > 2. Re: Mechanisms to synchronize client file systems with > Internet-based data storage services > (Ted Lemon) > 3. recent issues discussed (Fei Song) > 4. Re: Mechanisms to synchronize client file systems with > Internet-based data storage services > (Hugo Gonz?lez Labrador) > 5. Re: Mechanisms to synchronize client file systems with > Internet-based data storage services > (Ted Lemon) > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > Email had 5 attachments: > + Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 > 8k (message/rfc822) > + Re: [Storagesync] Mechanisms to synchronize client file systems with > Internet-based data storage services > 3k (message/rfc822) > + [Storagesync] recent issues discussed > 2k (message/rfc822) > + Re: [Storagesync] Mechanisms to synchronize client file systems with > Internet-based data storage services > 5k (message/rfc822) > + Re: [Storagesync] Mechanisms to synchronize client file systems with > Internet-based data storage services > 2k (message/rfc822) From nobody Fri Dec 4 08:29:39 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21EB1A8A4A for ; Fri, 4 Dec 2015 08:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7y-MiiISwBE for ; Fri, 4 Dec 2015 08:29:35 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id B82251A8A07 for ; Fri, 4 Dec 2015 08:29:34 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492465712410.12320886040106416" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> Date: Fri, 04 Dec 2015 16:29:31 +0000 Message-Id: <1449246571559-58500bfc-f92fedd1-047d217b@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:29:36 -0000 ------sinikael-?=_1-14492465712410.12320886040106416 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thursday, Dec 3, 2015 10:53 PM Linhui Sun wrote: > Separation of metadata and data is better. But I don't understand why we > need a distributed peer model. C/S model could still work fine with such > separation. This is correct. I want the distributed peer model because it's a better = model, not because the client/server model wouldn't work. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14492465712410.12320886040106416 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYb9rCRAMw8Nu0HeKywAAY2wIAL58sFWPg3cso0jqA2q+ 9HQXwihuHtCXPChCf6+H2184EhkYpLcPudpNIKFng8ppvup9R3dyXN163DJE TePgdEoFJ9SrMrMl0fNy9lvais024Jhf33h8lsO6FPpAaIgx3XpW/i+QnZvA 1XeTM8S2yC8qLx2+cUhWC3HRKHoS1ZPfsyRo5rc7JdLU3umyd0X4yG9atsf2 BnJO8lGxV6KY1jPqBmerdL8KJf90aZL/mvcipekK7D2QaRn50Ai3Ri2SQGAw RANFd0wvx/BkwMmtgISMZ34uuE6hyQY+HoKS9eQ/qnhm9CeQzkhhAqB94d7Z BP9mqxWd1S47BcWxzac4noU= =Oa4D -----END PGP SIGNATURE----- ------sinikael-?=_1-14492465712410.12320886040106416-- From nobody Fri Dec 4 10:11:23 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAC21A92AF for ; Fri, 4 Dec 2015 10:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51kPPC4sOv2G for ; Fri, 4 Dec 2015 10:11:19 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4121AC3FD for ; Fri, 4 Dec 2015 10:11:14 -0800 (PST) Received: (qmail 22810 invoked from network); 4 Dec 2015 18:11:12 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 4 Dec 2015 18:11:12 -0000 Date: Fri, 4 Dec 2015 19:11:10 +0100 From: Markus Unterwaditzer To: Ted Lemon Message-ID: <20151204181110.GA2418@localhost.localdomain> References: <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 18:11:22 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 03, 2015 at 02:38:05PM +0000, Ted Lemon wrote: > Thursday, Dec 3, 2015 6:00 AM Linhui Sun wrote: > > However I'd prefer HTTP rather than WebDAV. Since I still think WebDAV = is > > not suitable for today's sync service. The frequency of operations is f= ar > > higher than what WebDAV expects. For example, frequently sending propfi= nd > > to detect changes is not a good way in my view. >=20 > WebDAV is HTTP. However, your point about propfind is correct--that doe= sn't > scale. What you want is a separate layer for dealing with synchronizati= on > of metadata. You could use HTTP transport to do this, but not propfind. We do have that separate layer in the form of https://www.ietf.org/rfc/rfc6578.txt and so far only a handful of FOSS serv= ers have implemented it. The fully-interopable way to synchronize servers still includes a fallback to a full PROPFIND. ETags on folder listings are arguably simpler to implement than a partial transaction history. remoteStorage requires those, and consequently all ser= vers must implement it. >=20 >=20 > -- > Sent from Whiteout Mail - https://whiteout.io >=20 > My PGP key: https://keys.whiteout.io/mellon@fugue.com > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync --gKMricLos+KVdGMg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYdc5AAoJEDHp7/n6rHiMqikIANgLJft4sn2UwfkcHCgPTI4b PcEuH8iCXeK495joIPJ4jSjfDWjSXgmsBoIpNv2q5tLjb/3fpe9UH6YRkeLrM949 WvNCHsIdHrLhr9q33UPztcvHm0VW9wT/VQ+ftkAC7J3t+5Y1rn5GqfelavBBtH16 cxUM3NMaumtty5ibjnZuIEgN5RHmllnbNjHtYWJABmFFxy5Bl8Hx6z5QEy3iicKC 3dDpG8K9UqgaBJvIuFm78EjvvYpWy4vVQiKK/v0mAnvML26mrTPGKKGTx1SrE8Zv qhyIyFCrwgZmKyB3Mb/N73OIhnwD8JmM0xtanpvygeg51M2WcoO8YixbXZUpS8w= =R+kN -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From nobody Fri Dec 4 10:18:59 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651A1ACC8A for ; Fri, 4 Dec 2015 10:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHpNrKRcQExg for ; Fri, 4 Dec 2015 10:18:56 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C7D1B2BBC for ; Fri, 4 Dec 2015 10:18:55 -0800 (PST) Received: (qmail 22891 invoked from network); 4 Dec 2015 18:18:53 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 4 Dec 2015 18:18:53 -0000 Date: Fri, 4 Dec 2015 19:18:50 +0100 From: Markus Unterwaditzer To: Hugo =?iso-8859-1?Q?Gonz=E1lez?= Labrador Message-ID: <20151204181850.GB2418@localhost.localdomain> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Linhui Sun , storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 18:18:57 -0000 On Wed, Dec 02, 2015 at 11:28:48AM +0100, Hugo González Labrador wrote: > Of course, the remoteStorage is targeted to browsers, so syncing does > not make too much sense in this case. With the rise of Linux container > micro-service based architectures, the deployment of  such highly > complex systems should become easier and faster. It is not exclusively targeted at browsers, although the browser's Origin-based security model is required for sane client identification. You can totally access remoteStorage accounts using desktop apps, a proof-of-concept exists at https://github.com/untitaker/vdirsyncer. Synchronization is a completely unrelated topic. I don't see how it's related to whether the protocol is targeted at browser applications, in either case offline sync has to work. And it does. I don't understand what you mean with "linux container micro-service based architectures", or how it is related to this discussion. -- Markus > > Best, > > Hugo > > > Regards, Linhui > >> > >> > >>> Regards, Linhui > >>>> one from the CERN EOS project (management, disk and queue servers). > >>>> > >>>> The Phase I has implemented the ownCloud Sync Protocol and Phase II > >>>> will implement the SeaFile Sync Protocol. The choice of these > >>>> protocols among others is because they are really opposed to each > >>>> other in terms of syncing (delta vs non-delta, state-based vs log/event/git- > >>>> based sync …), so finding a common approach is more challenging. > >>>> > >>>> Providing a base specification/architecture to measure the > >>>> feasibility of this draft is one of the objectives of the project. > >>>> > >>>> I believe that the work being done here and in ClawIO are > >>>> supplementary to each other and I think mutual collaboration could > >>>> be beneficial for both sides. > >>>> > >>>> Also, if there is interest, the remoteStorage API can be added to > >>>> ClawIO. > >>>> > >>>> Best regards, > >>>> > >>>> Hugo Gonzalez Labrador > >>>> > >>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org > >>>> wrote: > >>>> > Send Storagesync mailing list submissions to > >>>> > storagesync@ietf.org > >>>> > > >>>> > To subscribe or unsubscribe via the World Wide Web, visit > >>>> > https://www.ietf.org/mailman/listinfo/storagesync or, via email, > >>>> > send a message with subject or body 'help' to       storagesync- > >>>> > request@ietf.org > >>>> > > >>>> > You can reach the person managing the list at       storagesync- > >>>> > owner@ietf.org > >>>> > > >>>> > When replying, please edit your Subject line so it is more > >>>> > specific than "Re: Contents of Storagesync digest..." Today's > >>>> > Topics: > >>>> > > >>>> >1. New version of draft-dejong-remotestorage    Internet-Draft > >>>> >available (Michiel de Jong)    2. Re: New version of draft-dejong- > >>>> >remotestorage Internet-Draft       available (Gihan Dias)    3. > >>>> >Re: New version of draft-dejong-remotestorage Internet-Draft > >>>> >available (Fei Song) > >>>> > _______________________________________________ > >>>> > Storagesync mailing list Storagesync@ietf.org > >>>> > https://www.ietf.org/mailman/listinfo/storagesync Email had 3 > >>>> > attachments: > >>>> > + [Storagesync] New version of draft-dejong-remotestorage Internet- > >>>> > Draft available   2k (message/rfc822) > >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage Internet- > >>>> > Draft available   1k (message/rfc822) > >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage Internet- > >>>> > Draft available   2k (message/rfc822) > >>>> > >>>> _______________________________________________ > >>>> Storagesync mailing list Storagesync@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/storagesync > >> > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Fri Dec 4 11:01:00 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA621B325E for ; Fri, 4 Dec 2015 11:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww51WSf6DCVQ for ; Fri, 4 Dec 2015 11:00:58 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3D1B325C for ; Fri, 4 Dec 2015 11:00:57 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492556544220.8448359307367355" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <20151204181110.GA2418@localhost.localdomain> References: <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> Date: Fri, 04 Dec 2015 19:00:54 +0000 Message-Id: <1449255654746-36498631-5591108f-793d865a@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 19:01:00 -0000 ------sinikael-?=_1-14492556544220.8448359307367355 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Friday, Dec 4, 2015 1:11 PM Markus Unterwaditzer wrote: > We do have that separate layer in the form of > https://www.ietf.org/rfc/rfc6578.txt and so far only a handful of FOSS = servers > have implemented it. The fully-interopable way to synchronize servers = still > includes a fallback to a full PROPFIND. Oh wow, thank you. I hadn't seen this RFC before. This is definitely = closer to what I want. I'll have to look at it in a bit more detail to = see if I can make it work for my application, but if it wouldn't work = exactly as is, it's certainly a big step in the right direction. > ETags on folder listings are arguably simpler to implement than a = partial > transaction history. remoteStorage requires those, and consequently all = servers > must implement it. I think etags for folders would be a little painful other than for a = read-only client. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14492556544220.8448359307367355 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYeLmCRAMw8Nu0HeKywAAPoYH/3y4sFgHCxwB3UIeW8qM idyNUhI5wICdKCw7Bj3pTSQMKGWhAOWdHPJPQJahxWJA5jNjQJ567o+zObjU IN3L/CElSfO9sTcXJ+oUSynC/jQ67tuMDBZJAFNuvpJQw6FtnQN8qwBngSLx gZSOTXZC5+y3n3SPuLF/3A4DDzHfYr0qENwC8+uHGxGI3As2cb4gcXoXMCcB s4HXuquQjNkqcPTSDs6umBv4frG2YlRN6lnq8R9otbvQU+yf4QUnH+xHGh/P b2tnnXvgxUSPZsmDQiQeWoj0l//ivCb6/oh72tVqHEkZJvTjjhxDpwXLtC1j 6+G00c0gtGiVypvb6hyCiZc= =OWVM -----END PGP SIGNATURE----- ------sinikael-?=_1-14492556544220.8448359307367355-- From nobody Fri Dec 4 12:30:26 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60001A044F for ; Fri, 4 Dec 2015 12:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1n-QT8sBNjk for ; Fri, 4 Dec 2015 12:30:22 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB181A044E for ; Fri, 4 Dec 2015 12:30:22 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AE67E209CD for ; Fri, 4 Dec 2015 15:30:21 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Fri, 04 Dec 2015 15:30:21 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Zix4q/sZWZhX+t+GEpxurbd6Rqs=; b=y3swO6 C53tdYlazbnDQjiejqNwQ2yCJ6SFkL2ZkpS9Gwywr+leANGmrFufCnfh3B3mAZcM aUx11ZP58elX5+2KKv4BGoSBDSqWYrF4L+0xHLDAfwKFqk327ircv3eBiTCRsFSi tClSrIVNipKQMB/pO3HjPft9bK2rWYC+qKWK8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Zix4q/sZWZhX+t+ GEpxurbd6Rqs=; b=DRkyqPFQ4P2jGvoae/MjJhlLvcjQ9xxVMlwQvQ9CoA1d+n+ QaCCWBjUccMgaSpyjXd83K0K4cMxb4XwZ7tKqGK18RB+pDpdySPxJOFXzW1qRyob ttGlPS+iPouK9VyKZk0LOZ/PWuEXafEnZd6BXC/npEL+i/mkO/IVUP2uHNOc= Received: by web2.nyi.internal (Postfix, from userid 99) id 6C2D7540117; Fri, 4 Dec 2015 15:30:21 -0500 (EST) Message-Id: <1449261021.2660424.458369441.7C6FBE34@webmail.messagingengine.com> X-Sasl-Enc: ET6XMnRv/OZrezDvkX8bMMuxQu+VFInBczqOnkB/RRBG 1449261021 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: Markus Unterwaditzer MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 In-Reply-To: <20151204181850.GB2418@localhost.localdomain> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <20151204181850.GB2418@localhost.localdomain> Date: Fri, 04 Dec 2015 21:30:21 +0100 Archived-At: Cc: Linhui Sun , storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 20:30:25 -0000 On Fri, Dec 4, 2015, at 07:18 PM, Markus Unterwaditzer wrote: > On Wed, Dec 02, 2015 at 11:28:48AM +0100, Hugo Gonz=C3=A1lez Labrador wro= te: > > Of course, the remoteStorage is targeted to browsers, so syncing does > > not make too much sense in this case. With the rise of Linux container > > micro-service based architectures, the deployment of =C2=A0such highly > > complex systems should become easier and faster. >=20 > It is not exclusively targeted at browsers, although the browser's > Origin-based > security model is required for sane client identification. You can > totally > access remoteStorage accounts using desktop apps, a proof-of-concept > exists at > https://github.com/untitaker/vdirsyncer. >=20 That's great to hear. If this is achievable maybe will be good to clarify this aspect in the spec. >From the abstract This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. it is difficult to infer that the spec is also targeted to non-web apps as there are no mentions to server-side or desktop apps. As far as I know the OAuth authentication flow works in client-side web applications, have you managed to use such mechanism in your non-web project ? That would be a really interesting achievement. Maybe this is the cause why remoteStorage does not mention non-web apps in their abstract. Summoning Michiel to clarify this aspect. > Synchronisation is a completely unrelated topic. I don't see how it's > related > to whether the protocol is targeted at browser applications, in either > case > offline sync has to work. And it does. >=20 > I don't understand what you mean with "linux container micro-service > based > architectures", or how it is related to this discussion. >=20 That was said to give an example of how using Docker Containers can help to manage non-monolithic applications. Of course, that is not directly related to sync. > -- Markus >=20 > >=20 > > Best, > >=20 > > Hugo > >=20 > > > Regards, Linhui > > >> > > >> > > >>> Regards, Linhui > > >>>> one from the CERN EOS project (management, disk and queue servers). > > >>>> > > >>>> The Phase I has implemented the ownCloud Sync Protocol and Phase II > > >>>> will implement the SeaFile Sync Protocol. The choice of these > > >>>> protocols among others is because they are really opposed to each > > >>>> other in terms of syncing (delta vs non-delta, state-based vs log/= event/git- > > >>>> based sync =E2=80=A6), so finding a common approach is more challe= nging. > > >>>> > > >>>> Providing a base specification/architecture to measure the > > >>>> feasibility of this draft is one of the objectives of the project. > > >>>> > > >>>> I believe that the work being done here and in ClawIO are > > >>>> supplementary to each other and I think mutual collaboration could > > >>>> be beneficial for both sides. > > >>>> > > >>>> Also, if there is interest, the remoteStorage API can be added to > > >>>> ClawIO. > > >>>> > > >>>> Best regards, > > >>>> > > >>>> Hugo Gonzalez Labrador > > >>>> > > >>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org > > >>>> wrote: > > >>>> > Send Storagesync mailing list submissions to > > >>>> > storagesync@ietf.org > > >>>> > > > >>>> > To subscribe or unsubscribe via the World Wide Web, visit > > >>>> > https://www.ietf.org/mailman/listinfo/storagesync or, via email, > > >>>> > send a message with subject or body 'help' to=C2=A0 =C2=A0 =C2= =A0 =C2=A0storagesync- > > >>>> > request@ietf.org > > >>>> > > > >>>> > You can reach the person managing the list at=C2=A0 =C2=A0 =C2= =A0 =C2=A0storagesync- > > >>>> > owner@ietf.org > > >>>> > > > >>>> > When replying, please edit your Subject line so it is more > > >>>> > specific than "Re: Contents of Storagesync digest..." Today's > > >>>> > Topics: > > >>>> > > > >>>> >1. New version of draft-dejong-remotestorage=C2=A0 =C2=A0 Interne= t-Draft > > >>>> >available (Michiel de Jong)=C2=A0 =C2=A0 2. Re: New version of dr= aft-dejong- > > >>>> >remotestorage Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0available = (Gihan Dias)=C2=A0 =C2=A0 3. > > >>>> >Re: New version of draft-dejong-remotestorage Internet-Draft > > >>>> >available (Fei Song) > > >>>> > _______________________________________________ > > >>>> > Storagesync mailing list Storagesync@ietf.org > > >>>> > https://www.ietf.org/mailman/listinfo/storagesync Email had 3 > > >>>> > attachments: > > >>>> > + [Storagesync] New version of draft-dejong-remotestorage Intern= et- > > >>>> > Draft available=C2=A0 =C2=A02k (message/rfc822) > > >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage In= ternet- > > >>>> > Draft available=C2=A0 =C2=A01k (message/rfc822) > > >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage In= ternet- > > >>>> > Draft available=C2=A0 =C2=A02k (message/rfc822) > > >>>> > > >>>> _______________________________________________ > > >>>> Storagesync mailing list Storagesync@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/storagesync > > >> >=20 > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync >=20 From nobody Fri Dec 4 13:14:26 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7551A906F for ; Fri, 4 Dec 2015 13:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv4DXvSc9pUo for ; Fri, 4 Dec 2015 13:14:23 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B361A906B for ; Fri, 4 Dec 2015 13:14:23 -0800 (PST) Received: (qmail 7790 invoked from network); 4 Dec 2015 21:14:19 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 4 Dec 2015 21:14:19 -0000 Date: Fri, 4 Dec 2015 22:14:11 +0100 From: Markus Unterwaditzer To: Hugo =?iso-8859-1?Q?Gonz=E1lez?= Labrador Message-ID: <20151204211411.GA9979@localhost.localdomain> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <20151204181850.GB2418@localhost.localdomain> <1449261021.2660424.458369441.7C6FBE34@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1449261021.2660424.458369441.7C6FBE34@webmail.messagingengine.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Linhui Sun , storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 21:14:26 -0000 > it is difficult to infer that the spec is also targeted to non-web apps > as there are no mentions to server-side or desktop apps. (Apologies to skippe and others who've had this discussion with me already) I'll have to back-paddle a bit. Yes, it's possible. It is possible AND secure if the server requires stricter methods for app identification, which is stated in the spec as a MAY. The spec does focus on web applications, and they're the supported usecase. The way I've made my particular desktop application work is sort-of a hack, but may be less fragile if the application has full control over the browser window (e.g. WebView on Android, or bundled webkit browser for desktop apps) > > Synchronisation is a completely unrelated topic. I don't see how it's > > related > > to whether the protocol is targeted at browser applications, in either > > case > > offline sync has to work. And it does. > > > > I don't understand what you mean with "linux container micro-service > > based > > architectures", or how it is related to this discussion. > > > > That was said to give an example of how using Docker Containers can help > to manage non-monolithic applications. Of course, that is not directly > related to sync. > > > -- Markus > > > > > > > > Best, > > > > > > Hugo > > > > > > > Regards, Linhui > > > >> > > > >> > > > >>> Regards, Linhui > > > >>>> one from the CERN EOS project (management, disk and queue servers). > > > >>>> > > > >>>> The Phase I has implemented the ownCloud Sync Protocol and Phase II > > > >>>> will implement the SeaFile Sync Protocol. The choice of these > > > >>>> protocols among others is because they are really opposed to each > > > >>>> other in terms of syncing (delta vs non-delta, state-based vs log/event/git- > > > >>>> based sync …), so finding a common approach is more challenging. > > > >>>> > > > >>>> Providing a base specification/architecture to measure the > > > >>>> feasibility of this draft is one of the objectives of the project. > > > >>>> > > > >>>> I believe that the work being done here and in ClawIO are > > > >>>> supplementary to each other and I think mutual collaboration could > > > >>>> be beneficial for both sides. > > > >>>> > > > >>>> Also, if there is interest, the remoteStorage API can be added to > > > >>>> ClawIO. > > > >>>> > > > >>>> Best regards, > > > >>>> > > > >>>> Hugo Gonzalez Labrador > > > >>>> > > > >>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org > > > >>>> wrote: > > > >>>> > Send Storagesync mailing list submissions to > > > >>>> > storagesync@ietf.org > > > >>>> > > > > >>>> > To subscribe or unsubscribe via the World Wide Web, visit > > > >>>> > https://www.ietf.org/mailman/listinfo/storagesync or, via email, > > > >>>> > send a message with subject or body 'help' to       storagesync- > > > >>>> > request@ietf.org > > > >>>> > > > > >>>> > You can reach the person managing the list at       storagesync- > > > >>>> > owner@ietf.org > > > >>>> > > > > >>>> > When replying, please edit your Subject line so it is more > > > >>>> > specific than "Re: Contents of Storagesync digest..." Today's > > > >>>> > Topics: > > > >>>> > > > > >>>> >1. New version of draft-dejong-remotestorage    Internet-Draft > > > >>>> >available (Michiel de Jong)    2. Re: New version of draft-dejong- > > > >>>> >remotestorage Internet-Draft       available (Gihan Dias)    3. > > > >>>> >Re: New version of draft-dejong-remotestorage Internet-Draft > > > >>>> >available (Fei Song) > > > >>>> > _______________________________________________ > > > >>>> > Storagesync mailing list Storagesync@ietf.org > > > >>>> > https://www.ietf.org/mailman/listinfo/storagesync Email had 3 > > > >>>> > attachments: > > > >>>> > + [Storagesync] New version of draft-dejong-remotestorage Internet- > > > >>>> > Draft available   2k (message/rfc822) > > > >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage Internet- > > > >>>> > Draft available   1k (message/rfc822) > > > >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage Internet- > > > >>>> > Draft available   2k (message/rfc822) > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Storagesync mailing list Storagesync@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/storagesync > > > >> > > > > > _______________________________________________ > > > Storagesync mailing list > > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > From nobody Fri Dec 4 13:28:41 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9C71A90C9 for ; Fri, 4 Dec 2015 13:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2KwfWOeptvm for ; Fri, 4 Dec 2015 13:28:33 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A201A90C0 for ; Fri, 4 Dec 2015 13:28:33 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 78A232051E for ; Fri, 4 Dec 2015 16:28:32 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute4.internal (MEProxy); Fri, 04 Dec 2015 16:28:32 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=labkode.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=9ieMlPyvDpLqAJDHv4oVbZQVin0=; b=APN/of XIgWN85+WDrgr65ZgrQ+++3mIgZgs93mP7lz27U9WgoOR6/06bpt+1UcqRrYUQ5b 399NBzTWnMtcRUKMX/SNSTW/whZUgDjgz52p3JV1Iczwwmy8mAYd/sYwWrnXyATj 1uZ+c/VTeSiuiOmAmTsuzm/ZM6IJxyDLu2ZNo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=9ieMlPyvDpLqAJD Hv4oVbZQVin0=; b=TmFPn7Y1QQTr/YycMAybHV+Qv0je8wXl8IZ5D6wSAa4QKK0 Vsx5xZ5Pv7zDS3BiAtro1ZCkC0IZya5V74fmKxLdW9h9ChqSNqLWYiHhj2vgXTiH vDK4mcaXskuMj3gddW6f8MZbhY67CdJmwtBEvml34JjILIAjWdm78e2IZVcM= Received: by web2.nyi.internal (Postfix, from userid 99) id 27EF3540141; Fri, 4 Dec 2015 16:28:32 -0500 (EST) Message-Id: <1449264512.2853440.458418905.051FE0CD@webmail.messagingengine.com> X-Sasl-Enc: 4dAEvGqVCRygVq+mNGxPEBFkaKWFj3F1j7WJQrmLBjrI 1449264512 From: =?ISO-8859-1?Q?Hugo=20Gonz=E1lez=20Labrador?= To: Markus Unterwaditzer MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 Date: Fri, 04 Dec 2015 22:28:32 +0100 In-Reply-To: <20151204211411.GA9979@localhost.localdomain> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <20151204181850.GB2418@localhost.localdomain> <1449261021.2660424.458369441.7C6FBE34@webmail.messagingengine.com> <20151204211411.GA9979@localhost.localdomain> Archived-At: Cc: Linhui Sun , storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 21:28:37 -0000 On Fri, Dec 4, 2015, at 10:14 PM, Markus Unterwaditzer wrote: > > it is difficult to infer that the spec is also targeted to non-web apps > > as there are no mentions to server-side or desktop apps. >=20 > (Apologies to skippe and others who've had this discussion with me > already) >=20 > I'll have to back-paddle a bit. >=20 > Yes, it's possible. It is possible AND secure if the server requires > stricter > methods for app identification, which is stated in the spec as a MAY. The > spec > does focus on web applications, and they're the supported usecase. >=20 > The way I've made my particular desktop application work is sort-of a > hack, but > may be less fragile if the application has full control over the browser > window > (e.g. WebView on Android, or bundled webkit browser for desktop apps) >=20 Okay, I see. So, web applications are the supported use case by remoteStorage but there are alternatives, as you have explained, that make it possible to connect from non web apps using embedded browsers.=20 I would like to hear Michiel opinion on this subject to see if remoteStorage will have non web apps as a supported use case in the future or if it is out of scope. Best, Hugo > > > Synchronisation is a completely unrelated topic. I don't see how it's > > > related > > > to whether the protocol is targeted at browser applications, in either > > > case > > > offline sync has to work. And it does. > > >=20 > > > I don't understand what you mean with "linux container micro-service > > > based > > > architectures", or how it is related to this discussion. > > >=20 > >=20 > > That was said to give an example of how using Docker Containers can help > > to manage non-monolithic applications. Of course, that is not directly > > related to sync. > >=20 > > > -- Markus > > >=20 > > > >=20 > > > > Best, > > > >=20 > > > > Hugo > > > >=20 > > > > > Regards, Linhui > > > > >> > > > > >> > > > > >>> Regards, Linhui > > > > >>>> one from the CERN EOS project (management, disk and queue serv= ers). > > > > >>>> > > > > >>>> The Phase I has implemented the ownCloud Sync Protocol and Pha= se II > > > > >>>> will implement the SeaFile Sync Protocol. The choice of these > > > > >>>> protocols among others is because they are really opposed to e= ach > > > > >>>> other in terms of syncing (delta vs non-delta, state-based vs = log/event/git- > > > > >>>> based sync =E2=80=A6), so finding a common approach is more ch= allenging. > > > > >>>> > > > > >>>> Providing a base specification/architecture to measure the > > > > >>>> feasibility of this draft is one of the objectives of the proj= ect. > > > > >>>> > > > > >>>> I believe that the work being done here and in ClawIO are > > > > >>>> supplementary to each other and I think mutual collaboration c= ould > > > > >>>> be beneficial for both sides. > > > > >>>> > > > > >>>> Also, if there is interest, the remoteStorage API can be added= to > > > > >>>> ClawIO. > > > > >>>> > > > > >>>> Best regards, > > > > >>>> > > > > >>>> Hugo Gonzalez Labrador > > > > >>>> > > > > >>>> On Tue, Dec 1, 2015, at 09:00 PM, storagesync-request@ietf.org > > > > >>>> wrote: > > > > >>>> > Send Storagesync mailing list submissions to > > > > >>>> > storagesync@ietf.org > > > > >>>> > > > > > >>>> > To subscribe or unsubscribe via the World Wide Web, visit > > > > >>>> > https://www.ietf.org/mailman/listinfo/storagesync or, via em= ail, > > > > >>>> > send a message with subject or body 'help' to=C2=A0 =C2=A0 = =C2=A0 =C2=A0storagesync- > > > > >>>> > request@ietf.org > > > > >>>> > > > > > >>>> > You can reach the person managing the list at=C2=A0 =C2=A0 = =C2=A0 =C2=A0storagesync- > > > > >>>> > owner@ietf.org > > > > >>>> > > > > > >>>> > When replying, please edit your Subject line so it is more > > > > >>>> > specific than "Re: Contents of Storagesync digest..." Today's > > > > >>>> > Topics: > > > > >>>> > > > > > >>>> >1. New version of draft-dejong-remotestorage=C2=A0 =C2=A0 Int= ernet-Draft > > > > >>>> >available (Michiel de Jong)=C2=A0 =C2=A0 2. Re: New version o= f draft-dejong- > > > > >>>> >remotestorage Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0availa= ble (Gihan Dias)=C2=A0 =C2=A0 3. > > > > >>>> >Re: New version of draft-dejong-remotestorage Internet-Draft > > > > >>>> >available (Fei Song) > > > > >>>> > _______________________________________________ > > > > >>>> > Storagesync mailing list Storagesync@ietf.org > > > > >>>> > https://www.ietf.org/mailman/listinfo/storagesync Email had 3 > > > > >>>> > attachments: > > > > >>>> > + [Storagesync] New version of draft-dejong-remotestorage In= ternet- > > > > >>>> > Draft available=C2=A0 =C2=A02k (message/rfc822) > > > > >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorag= e Internet- > > > > >>>> > Draft available=C2=A0 =C2=A01k (message/rfc822) > > > > >>>> > + Re: [Storagesync] New version of draft-dejong-remotestorag= e Internet- > > > > >>>> > Draft available=C2=A0 =C2=A02k (message/rfc822) > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> Storagesync mailing list Storagesync@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/storagesync > > > > >> > > >=20 > > > > _______________________________________________ > > > > Storagesync mailing list > > > > Storagesync@ietf.org > > > > https://www.ietf.org/mailman/listinfo/storagesync > > >=20 From nobody Fri Dec 4 14:24:25 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939211AC3F8 for ; Fri, 4 Dec 2015 14:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvL439gxEiW8 for ; Fri, 4 Dec 2015 14:24:22 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD89F1AC3F4 for ; Fri, 4 Dec 2015 14:24:22 -0800 (PST) Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 02B3D17209D for ; Fri, 4 Dec 2015 23:24:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id sdNcHVdaNKMM for ; Fri, 4 Dec 2015 23:24:19 +0100 (CET) X-Originating-IP: 80.26.255.92 Received: from [192.168.168.2] (92.red-80-26-255.adsl.dynamic.ccgg.telefonica.net [80.26.255.92]) (Authenticated sender: sebastian@kip.pe) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 7D21D1720A3 for ; Fri, 4 Dec 2015 23:24:19 +0100 (CET) To: storagesync@ietf.org References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <20151204181850.GB2418@localhost.localdomain> <1449261021.2660424.458369441.7C6FBE34@webmail.messagingengine.com> From: Sebastian Kippe Message-ID: <56621292.8010901@kip.pe> Date: Fri, 4 Dec 2015 22:24:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1449261021.2660424.458369441.7C6FBE34@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 22:24:24 -0000 Hi, > As far as I know the OAuth authentication flow works in client-side web > applications, have you managed to use such mechanism in your non-web > project ? That would be a really interesting achievement. Maybe this is > the cause why remoteStorage does not mention non-web apps in their > abstract. There are many programs doing this in some way today, usually involving a Web View component of some kind. Check out Gnome Online Accounts for example. Or many Android apps. In fact, the remoteStorage.js library has support for doing it in Cordova apps via the in-app-browser plugin. Cheers, Sebastian From nobody Fri Dec 4 21:29:11 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F04A1A0335 for ; Fri, 4 Dec 2015 21:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZLFkC_KmfWX for ; Fri, 4 Dec 2015 21:29:08 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F941A0302 for ; Fri, 4 Dec 2015 21:29:08 -0800 (PST) Received: by wmuu63 with SMTP id u63so85048164wmu.0 for ; Fri, 04 Dec 2015 21:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wzc52UqEpvKbj/jH5GNDYi/qA4oRFCEHsbbnvMa78Q0=; b=RnQdRN3es7+afHr+3RbcdGFkZ/0eRwQQDTvmnU6X4V5iEPAZZU7+42Mp/gojZiHzaW iM8LDh9EhsMPQeabYHk6+TTfqwvU5L8cRTXG1E+mwAIduqmlsFc09TomrZtOMjnMYd/P bKw/nlG0s9NIa8RUiY6R1FWmG7udK3rTf7hTUU0FZxjX2GMqDY3MoKKKN5dkI9o/ok3l ZMtznld5EMhG1rlja4jR15oqIcJg7s5N8VlIcVblfOxFa+OYATFcm43g8NrQ4kCKDOcn 5ubnIVGhiOiTJrGRO1IA66K16plsFyXrrFpCKB6xPziL3ACxpd6uAaCwtsdwEx4ZeeeQ doyA== X-Received: by 10.194.79.72 with SMTP id h8mr23393018wjx.136.1449293346747; Fri, 04 Dec 2015 21:29:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Fri, 4 Dec 2015 21:28:47 -0800 (PST) In-Reply-To: <1449246571559-58500bfc-f92fedd1-047d217b@fugue.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> <1449246571559-58500bfc-f92fedd1-047d217b@fugue.com> From: Linhui Sun Date: Sat, 5 Dec 2015 13:28:47 +0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bb0499e1bbad005261fe740 Archived-At: Cc: storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 05:29:10 -0000 --047d7bb0499e1bbad005261fe740 Content-Type: text/plain; charset=UTF-8 2015-12-05 0:29 GMT+08:00 Ted Lemon : > Thursday, Dec 3, 2015 10:53 PM Linhui Sun wrote: > > Separation of metadata and data is better. But I don't understand why we > > need a distributed peer model. C/S model could still work fine with such > > separation. > > This is correct. I want the distributed peer model because it's a better > model, not because the client/server model wouldn't work. > I'm not very familiar with the distributed peer model (I view it as p2p, please correct me if I am wrong). From the example you have provided previously, it seems that it works fine with 2 participants. But I don't know whether it works well when multiple participants are willing to share a file/folder. I'm asking this question since we need to know which model should the iss probably employ. > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mellon@fugue.com > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --047d7bb0499e1bbad005261fe740 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-05 0:29 GMT+08:00 Ted Lemon <mellon@fugue.com>:
Thursday, Dec 3, 2015 10:= 53 PM Linhui Sun wrote:
> Separation of metadata and data is better. But I don't understand = why we
> need a distributed peer model. C/S model could still work fine with su= ch
> separation.

This is correct.=C2=A0 =C2=A0I want the distributed peer model becau= se it's a better model, not because the client/server model wouldn'= t work.
I'm not very familiar with the distributed= peer model (I view it as p2p, please correct me if I am wrong). From the e= xample you have provided previously, it seems that it works fine with 2 par= ticipants. But I don't know whether it works well when multiple partici= pants are willing to share a file/folder. I'm asking this question sinc= e we need to know which model should the iss probably employ.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com

_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync


--047d7bb0499e1bbad005261fe740-- From nobody Fri Dec 4 21:47:47 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D9C1A0091 for ; Fri, 4 Dec 2015 21:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K51o9kVqhPK for ; Fri, 4 Dec 2015 21:47:44 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id AC79A1A0087 for ; Fri, 4 Dec 2015 21:47:43 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492944609720.2587213853839785" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> <1449246571559-58500bfc-f92fedd1-047d217b@fugue.com> Date: Sat, 05 Dec 2015 05:47:40 +0000 Message-Id: <1449294461284-b55dffbc-67521f90-03218253@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 05:47:46 -0000 ------sinikael-?=_1-14492944609720.2587213853839785 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Saturday, Dec 5, 2015 12:28 AM Linhui Sun wrote: > I'm not very familiar with the distributed peer model (I view it as p2p, > please correct me if I am wrong). From the example you have provided > previously, it seems that it works fine with 2 participants. But I don't > know whether it works well when multiple participants are willing to = share > a file/folder. I'm asking this question since we need to know which = model > should the iss probably employ. The distributed peer model simply means that there is no server. There = are only instances of the database. Any instance can be modified, and the= changes will be propagated to other instances when they sync. A change = made on one instance may propagate to another instance through a third = instance. Importantly, this avoids the situation where the metadata is lost on the = server, and as a consequence the data is all removed from the client. = Since there is no server, and no client, but only peers, neither peer is = considered authoritative, so a metadata loss on either peer can result in a= safe recovery without data loss. In practice, in most cases there will be one or more instances that are = treated as servers, and then one or more that are treated more as clients, = but now you can have two or three =22servers=22 and it doesn't matter which= one the =22client=22 syncs to; the new information will propagate to the = other two =22servers.=22 -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14492944609720.2587213853839785 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYnp9CRAMw8Nu0HeKywAA1VsH+wayoCJ6Bd8aLGG5aIDu oJ11AOSiI2DsJzggdlnA7S+Xu/DCWovvvB1ucb9EtPk+48VojoFM2E1Khf3P uA7+srvWh0BH3pBxOhU16u4E7b3tTj5omwAvKCBMr7tKDSN8U/SAX6+cn/0R AfD7eglWD4Okw8qRdHkkgsvRb03NQrimRa31TBMCLxJDx3nODApe2tef1hB6 pzdjF6tLZpzXOudis/naMpUdOW9VW45MOds0gPjF+ceNJJswZO5atV2ovy2D 8HAklEYKeW2AsNrBcW6AIO9PRAjZ1/cukTpXxfO3GL3UXThPGP5PmjwpTWmr 1MAbGcCxQJrtZ87dLW51cOQ= =wqvj -----END PGP SIGNATURE----- ------sinikael-?=_1-14492944609720.2587213853839785-- From nobody Fri Dec 4 22:09:34 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415F1A1A90 for ; Fri, 4 Dec 2015 22:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtzGUddcjne1 for ; Fri, 4 Dec 2015 22:09:30 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42421A1A91 for ; Fri, 4 Dec 2015 22:09:29 -0800 (PST) Received: by wmvv187 with SMTP id v187so101990591wmv.1 for ; Fri, 04 Dec 2015 22:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zhuRQ5Dk+3e0pFdI1AtBsTZrlLL2FEz2eEEpP3Zj18I=; b=0e8iCBgwPM4h2OvhXN4QCzdYQuD/pc/HizyR+ivBYUXQ5NVK4xlp3E56OAW5VyzqfL 1BZYzmC1ie+nSIfoGRTH3KirkgNBsXX3B87JCo2tNLh8NcxT1l8F/BBntnNiE3DanHd4 xGYYKijshw/m+73deiTXxzOjH7idReX1rAtpx9O7YcURYoS1WQxzLg1E3rrG/LxjLuE6 ZERoSrODJRgS4Rd4ZLgM/5VVqDqAsbyEjbKk9EP0RLmAd8ZdPCwMfIzbxo525T7KxTTE wgaGA0YKN5GL5v1WZYJUGBsXtawGzw8Og0aA+UzLpMCEU5vdqMu/i+ksrBHFqOGRP7sq ImeQ== X-Received: by 10.28.89.137 with SMTP id n131mr9452861wmb.9.1449295768504; Fri, 04 Dec 2015 22:09:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Fri, 4 Dec 2015 22:09:08 -0800 (PST) In-Reply-To: <1449294461284-b55dffbc-67521f90-03218253@fugue.com> References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> <1449246571559-58500bfc-f92fedd1-047d217b@fugue.com> <1449294461284-b55dffbc-67521f90-03218253@fugue.com> From: Linhui Sun Date: Sat, 5 Dec 2015 14:09:08 +0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1140cdb874d0df05262077de Archived-At: Cc: storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 06:09:32 -0000 --001a1140cdb874d0df05262077de Content-Type: text/plain; charset=UTF-8 2015-12-05 13:47 GMT+08:00 Ted Lemon : > Saturday, Dec 5, 2015 12:28 AM Linhui Sun wrote: > > I'm not very familiar with the distributed peer model (I view it as p2p, > > please correct me if I am wrong). From the example you have provided > > previously, it seems that it works fine with 2 participants. But I don't > > know whether it works well when multiple participants are willing to > share > > a file/folder. I'm asking this question since we need to know which model > > should the iss probably employ. > > The distributed peer model simply means that there is no server. There > are only instances of the database. Any instance can be modified, and the > changes will be propagated to other instances when they sync. A change > made on one instance may propagate to another instance through a third > instance. > > Importantly, this avoids the situation where the metadata is lost on the > server, and as a consequence the data is all removed from the client. > Since there is no server, and no client, but only peers, neither peer is > considered authoritative, so a metadata loss on either peer can result in a > safe recovery without data loss. > > In practice, in most cases there will be one or more instances that are > treated as servers, and then one or more that are treated more as clients, > but now you can have two or three "servers" and it doesn't matter which one > the "client" syncs to; the new information will propagate to the other two > "servers." > It sounds like this could resolve your IMAP issue to some extent. I'm wondering could we understand this in another way for the practical application: we have a group of servers and a group of clients. Inside the group of servers, they use a explicit distributed peer model and any new info will be propagated to the group members. Between the server group and client group, it is simply C/S model but a client can sync to arbitrary one from the server group. However inside the group of clients, they have no communications since I don't want my client to talk to anyone else. > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mellon@fugue.com > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --001a1140cdb874d0df05262077de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-05 13:47 GMT+08:00 Ted Lemon <mellon@fugue.com>:<= br>
Saturday, Dec 5, 2015 12= :28 AM Linhui Sun wrote:
> I'm not very familiar with the distributed peer model (I view it a= s p2p,
> please correct me if I am wrong). From the example you have provided > previously, it seems that it works fine with 2 participants. But I don= 't
> know whether it works well when multiple participants are willing to s= hare
> a file/folder. I'm asking this question since we need to know whic= h model
> should the iss probably employ.

The distributed peer model simply means that there is no server.=C2= =A0 =C2=A0There are only instances of the database.=C2=A0 =C2=A0Any instanc= e can be modified, and the changes will be propagated to other instances wh= en they sync.=C2=A0 =C2=A0A change made on one instance may propagate to an= other instance through a third instance.

Importantly, this avoids the situation where the metadata is lost on the se= rver, and as a consequence the data is all removed from the client.=C2=A0 = =C2=A0Since there is no server, and no client, but only peers, neither peer= is considered authoritative, so a metadata loss on either peer can result = in a safe recovery without data loss.

In practice, in most cases there will be one or more instances that are tre= ated as servers, and then one or more that are treated more as clients, but= now you can have two or three "servers" and it doesn't matte= r which one the "client" syncs to; the new information will propa= gate to the other two "servers."
It sounds l= ike this could resolve your IMAP issue to some extent. I'm wondering co= uld we understand this in another way for the practical application: we hav= e a group of servers and a group of clients. Inside the group of servers, t= hey use a explicit distributed peer model and any new info will be propagat= ed to the group members. Between the server group and client group, it is s= imply C/S model but a client can sync to arbitrary one from the server grou= p. However inside the group of clients, they have no communications since I= don't want my client to talk to anyone else.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com

_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync


--001a1140cdb874d0df05262077de-- From nobody Sat Dec 5 06:56:11 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7E91B2A87 for ; Sat, 5 Dec 2015 06:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09zWN-6-JkXl for ; Sat, 5 Dec 2015 06:56:09 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 333101B2A88 for ; Sat, 5 Dec 2015 06:56:08 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14493273642820.7448489863891155" From: Ted Lemon To: lh.sunlinh@gmail.com In-Reply-To: References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> <1449246571559-58500bfc-f92fedd1-047d217b@fugue.com> <1449294461284-b55dffbc-67521f90-03218253@fugue.com> Date: Sat, 05 Dec 2015 14:56:04 +0000 Message-Id: <1449327364595-79ead32f-910f9aed-8ffc5256@fugue.com> MIME-Version: 1.0 Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 14:56:10 -0000 ------sinikael-?=_1-14493273642820.7448489863891155 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Saturday, Dec 5, 2015 1:09 AM Linhui Sun wrote: > It sounds like this could resolve your IMAP issue to some extent. I'm > wondering could we understand this in another way for the practical > application: we have a group of servers and a group of clients. Inside = the > group of servers, they use a explicit distributed peer model and any new > info will be propagated to the group members. Between the server group = and > client group, it is simply C/S model but a client can sync to arbitrary = one > from the server group. However inside the group of clients, they have no > communications since I don't want my client to talk to anyone else. Any two devices that share the same server and can update it, whether they = use a peer-to-peer protocol to talk to the server or a client-server = protocol, are communicating. However, if you just mean that you don't = want to do the work to set up the communication, but you want to use the = same protocol in all cases, then yes, this is a good example of a = configuration that could work with the peer-to-peer sync model: what = peer-to-peer means in this context is simply that it in principle for any = two participants can communicate, not that they are configured so that they= =5Factually=5F communicate. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14493273642820.7448489863891155 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWYvsECRAMw8Nu0HeKywAAwoYH/RbAP1iOxscmbyFVYsUV 2bsVE+fUH2zuLq4BvjsbrEqVk8Lyl4gLkyHPlrwPA2SoSbaSrb3CBle4rf9l OfA0x98s29vysV4Pid2mQJ0lDCfblWGKu2DW/D6tSUhIjXxzz64RAKXw0oz+ xRkikdTdegDygXCHjqX7KHVFdWNbGBNdVJyZlzOb1mkQ/XAYpEnM80QHDyBM PRGPAWQTTQoOZ44e46hMYlF0e861nBeWSVuxDV/2+1PS6IvUX3LerKdrurv+ fHATcuYWnf9xXoPcoSZE03Zj1DPLTGpLibT0FrNZM3mLyFgZa56ng1KULz9A wYVKXrR9+PJGvIly39r1iTs= =mdwg -----END PGP SIGNATURE----- ------sinikael-?=_1-14493273642820.7448489863891155-- From nobody Sat Dec 5 15:44:18 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25041AC400 for ; Sat, 5 Dec 2015 15:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5pt_W8_T3GR for ; Sat, 5 Dec 2015 15:44:15 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4AF91AC3F8 for ; Sat, 5 Dec 2015 15:44:14 -0800 (PST) Received: (qmail 29084 invoked from network); 5 Dec 2015 23:44:11 -0000 Received: from localhost (HELO ?192.168.0.3?) (127.0.0.1) by draco.uberspace.de with SMTP; 5 Dec 2015 23:44:11 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <1449255654746-36498631-5591108f-793d865a@fugue.com> References: <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Markus Unterwaditzer Date: Sun, 06 Dec 2015 00:44:09 +0100 To: Ted Lemon ,storagesync@ietf.org Message-ID: <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 23:44:17 -0000 On 4 December 2015 20:00:54 CET, Ted Lemon wrote: >I think etags for folders would be a little painful other than for a >read-only client. > I don't see what's wrong with it. -- Sent from my phone. Please excuse my brevity. From nobody Sat Dec 5 18:38:10 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BA61B2F2D for ; Sat, 5 Dec 2015 18:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USOBV6fFTCDj for ; Sat, 5 Dec 2015 18:38:07 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41A21B2F2C for ; Sat, 5 Dec 2015 18:38:06 -0800 (PST) Received: by wmec201 with SMTP id c201so122195478wme.0 for ; Sat, 05 Dec 2015 18:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i7eCNB0rdC5rrgrsY1Zqwjm1dFeiAwkqPzGVXy9UIGI=; b=dTxsZ5X2NmP01yxTQnsd4IQPAsMGlJVZhDzliobzpCXptNdoei1FRWTUAhcfvEoIdv vVqLiJbBuMOSJJazf0RBMbrkSBpx7H/3p9JMGkEWwODB/Yl8kgibGxtE3tYDr0YO/kIA mE1FYioTdau4ibTvs110Kq3LUzkRpVi2R8hyk9ZOQJ6fsJ0AYG+UMZxz3k4hHIpmxP+8 zJGTV9ITClpT0PdNUnrkK4t0E0SbZKcdgPxP36KRY/Ui6yjE53dnQoeaIhI73NCmomhb 65dB3jTNrl/CakHSGUPgIiuIJYo62kxreY7+eAfBfw3BkmoMYbWYvFoQH/xQjmUOJY63 W37A== X-Received: by 10.194.84.4 with SMTP id u4mr29959884wjy.149.1449369485544; Sat, 05 Dec 2015 18:38:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Sat, 5 Dec 2015 18:37:45 -0800 (PST) In-Reply-To: <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> References: <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> From: Linhui Sun Date: Sun, 6 Dec 2015 10:37:45 +0800 Message-ID: To: Markus Unterwaditzer Content-Type: multipart/alternative; boundary=047d7bb04d3655938c052631a10f Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 02:38:08 -0000 --047d7bb04d3655938c052631a10f Content-Type: text/plain; charset=UTF-8 2015-12-06 7:44 GMT+08:00 Markus Unterwaditzer : > > > On 4 December 2015 20:00:54 CET, Ted Lemon wrote: > >I think etags for folders would be a little painful other than for a > >read-only client. > > > > I don't see what's wrong with it. > IMO, etag is designed for client side cache. A typical usage: if the file on the server has no actual change, the client will use the cache and the server does not need to send the file content again. While for a storage service, we also need some some similar mechanism at server side. In this way, the client do not need to upload unchanged content to the server. > -- > Sent from my phone. Please excuse my brevity. > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > --047d7bb04d3655938c052631a10f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-12-06 7:44 GMT+08:00 Markus Unterwaditzer <markus@unterwaditze= r.net>:


On 4 December 2015 20:00:54 CET, Ted Lemon <mellon@fugue.com> wrote:
>I think etags for folders would be a little painful other than for a >read-only client.
>

I don't see what's wrong with it.
IMO, = etag is designed for client side cache. A typical usage: if the file on the= server has no actual change, the client will use the cache and the server = does not need to send the file content again. While for a storage service, = we also need some some similar mechanism at server side. In this way, the c= lient do not need to upload unchanged content to the server.=C2=A0
--
Sent from my phone. Please excuse my brevity.

_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync

--047d7bb04d3655938c052631a10f-- From nobody Sat Dec 5 19:25:35 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6840D1B2FE8 for ; Sat, 5 Dec 2015 19:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.988 X-Spam-Level: ** X-Spam-Status: No, score=2.988 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtLCKgGs1eLM for ; Sat, 5 Dec 2015 19:25:31 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id CC0631B2FDE for ; Sat, 5 Dec 2015 19:25:29 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygAnDv9Cq2NWS8cDAA--.8106S2; Sun, 06 Dec 2015 11:28:02 +0800 (CST) Date: Sun, 6 Dec 2015 11:25:18 +0800 From: "Fei Song" To: =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= , storagesync References: <1449177286.2507848.457409737.10AEAB2B@webmail.messagingengine.com> <2015120411270531225432@bjtu.edu.cn>, <1449236876.216680.458015521.42999C02@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120611251742131059@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygAnDv9Cq2NWS8cDAA--.8106S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCF17ZF4DJr48tF17CFWktFb_yoWrKr48pF yftFy2ka1DJr4xAw1vyw17XFW0yr93Jw4UJFn8Kr1xC3sxuFy2gry2yw4ruF9rJryfJw4j vryF9F13C34vyFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUyK hFDUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: mellon Subject: Re: [Storagesync] Mechanisms to synchronize client file systems with Internet-based data storage services X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 03:25:33 -0000 SGkgSHVnbywNCg0KSXQncyBxdWl0ZSBuaWNlIHRvIGtub3cgdGhlc2UuIFRoYW5rcyBmb3Igc2hh cmluZ34gRXNwZWNpYWxseSB0aGUgZXhhbXBsZSBwYXJ0DQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZl aSBTb25nDQo+DQo+DQo+T24gRnJpLCBEZWMgNCwgMjAxNSwgYXQgMDQ6MjcgQU0sIEZlaSBTb25n IHdyb3RlOg0KPj4gSGkgSHVnbywNCj4+IA0KPj4gSSB0aGluayB0aGUgY29uZGl0aW9uIG1lbnRp b25lZCBieSBUZWQgaXMgbW9yZSBnZW5lcmljLihwbGVhc2UgY29ycmVjdCBtZQ0KPj4gaGVyZSkN Cj4+IEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBkaXNjdXNzIGEgY29tbW9uIHNjZW5hcmlvLg0KPj4g RG8geW91IGhhdmUgYW55IGdvb2QgYXBwcm9hY2hlcyAob3Igc29tZSBleGFtcGxlcykgdG8gc2Vw YXJhdGUgdGhlDQo+PiBtZXRhZGF0YSBhbmQgZGF0YT8NCj4+IA0KPg0KPlRoZXJlIGFyZSBhbHJl YWR5IHN5bmNocm9uaXNhdGlvbiBwbGF0Zm9ybXMgYnVpbHQgb24gdG9wIG9mIHN1Y2gNCj5jb25j ZXB0Lg0KPg0KPlVzdWFsbHksIGFuIG9iamVjdCBzdG9yYWdlIHNlcnZpY2UgbGlrZSBBbWF6b24g UzMvIE9wZW5TdGFjayBTd2lmdC9DZXBoDQo+UmFkb3NHVyBpcyB1c2VkIGp1c3QgdG8ga2VlcCBi aW5hcnkgZGF0YSBpbiBhIGZhc3QgZmxhdCBuYW1lc3BhY2UuDQo+DQo+VGhlbiwgYSBzdXBwb3J0 aW5nIGNvbXBvbmVudCwgZGV0YWNoZWQgZnJvbSB0aGUgZGF0YSBzdG9yZSwga2VlcHMgdHJhY2sN Cj5vZiB3aGljaCBtZXRhZGF0YSBpcyBhdHRhY2hlZCB0byB0aGUgZGF0YS4gVGhpcyBtZXRhZGF0 YSBpbmNsdWRlcw0KPm10aW1lcywgRXRhZ3MsIHBhdGhzIGFuZCBwbGF0Zm9ybSBBQ0xzIGFtb25n IG90aGVycy4NCj4NCj5JIGtub3cgc29tZSBwcm9kdWN0cyB0aGF0IHVzZSB0aGlzIGFwcHJvYWNo Og0KPg0KPi0gb3duQ2xvdWQgd2hlbiBjb25maWd1cmVkIHRvIHVzZSBhbiBPYmplY3QgU3RvcmFn ZSBhcyB0aGUgUHJpbWFyeSBVc2VyDQo+U3RvcmFnZS4gKE1ldGFkYXRhIGlzIGhhbmRsZWQgYnkg YSBNeVNRTCBkYXRhYmFzZSkNCj4tIENFUk4gRU9TIFN0b3JhZ2UgU3lzdGVtLiAoTWV0YWRhdGEg aXMgaGFuZGxlZCBpbiBoaWdoIHBlcmZvcm1hbmNlDQo+aW4tbWVtb3J5IHN0cnVjdHVyZXMpLg0K Pi0gRHJvcEJveC4gKEFzIGZhciBhcyBJIGtub3cgaXQgdXNlcyBTMyBiZWhpbmQuIEZvciBtZXRh ZGF0YSBpdCBpcw0KPnVua25vd24sIGJ1dCBwcm9iYWJseSBub3Qgb24gUzMpLg0KPi0gQ2xhd0lP IHdpbGwgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIGFwcHJvYWNoIGluIHRoZSBuZXh0 IHBoYXNlDQo+dXNpbmcgU3dpZnQuDQo+DQo+PiAtLS0tLS0tLS0tLS0tLQ0KPj4gRmVpIFNvbmcN Cj4+ID4NCj4+ID4+VGh1cnNkYXksIERlYyAzLCAyMDE1IDE6NDEgUE0gSmFrdWIgTW9zY2lja2kg d3JvdGU6DQo+PiA+PkNvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiB3aHkgeW91IHRoaW5rIGl0IGRv ZXMgbm90IHNjYWxlPyBUaGVyZSBhcmUgc2NoZW1lcyBpbiB3aGljaCB5b3UgZG8gbm90IG5lZWQg dG8gcHJvcGZpbmQgPnRoZSBlbnRpcmUgcmVtb3RlIHRyZWUgdG8gZGlzY292ZXIgY2hhbmdlcywg b25seSBhIHNlcXVlbmNlIG9mIHByb3BmaW5kcyBpbiBhIGRpcmVjdCBwYXRoIGxlYWRpbmcgdG8g YSBjaGFuZ2VkID5lbnRpdHkuIFRoYXShr3Mgbm90IG9wdGltYWwgZm9yIHN1cmUgKHNldmVyYWwg Y2FsbHMgbmVlZGVkLCBkZXBlbmRpbmcgb24gdGhlIGRlcHRoIG9mIHRoZSBjaGFuZ2UpIGJ1dCBp ZiBpdCBjb21lcyB0byA+V2ViREFWIGl0c2VsZiwgYXBhcnQgZnJvbSBhIGJsb2F0ZWQgWE1MIHJl cHJlc2VudGF0aW9uLCBJIGRvIG5vdCBzZWUgbXVjaCBwcm9ibGVtLg0KPj4gPg0KPj4gPj5JdCBk b2Vzbid0IHNjYWxlIGJlY2F1c2UgeW91J3ZlIGp1c3QgZGVzY3JpYmVkIGEgbG9ja3N0ZXAgcHJv Y2VzcyBmb3IgbG9jYXRpbmcgY2hhbmdlczsgaW5zdGVhZCBvZiB0aGVyZSBiZWluZyBvbmUgPnRy YW5zYWN0aW9uIHRvIGdldCB0aGUgc2V0IG9mIGNoYW5nZXMgZnJvbSBhIGtub3duIGNvbW1vbiB2 ZXJzaW9uLCB5b3UgaGF2ZSBtdWx0aXBsZSBzdGVwcywgYW5kIHRoZSBudW1iZXIgb2YgPnN0ZXBz IGluY3JlYXNlcyBhdCBsZWFzdCBsb2dhcml0aG1pY2FsbHkgKEkgYW0gZ3Vlc3NpbmcsIHNpbmNl IEkgZG9uJ3Qga25vdyB5b3VyIGFsZ29yaXRobSkgYXMgdGhlIG51bWJlciBvZiA+Y2hhbmdlcyBz aW5jZSBsYXN0IHN5bmMgaW5jcmVhc2VzIG9yIHRoZSBzaXplIG9mIHRoZSB0cmVlIGluY3JlYXNl cy4gICBJZiB5b3UgYXJlIHN5bmNpbmcgY29udGludW91c2x5IHRoaXMgbWF5IG5vdCA+YmUgYSBi aWcgZGVhbCwgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGEgcmVhc29uYWJsZSBhc3N1bXB0aW9u Lg0KPj4gPg0KPj4gPlRoaXMgZGVwZW5kcyBvbiB3aGljaCBwYXJ0IG9mIHlvdXIgc3lzdGVtIHlv dSB3YW50IHRvIHB1dCB0aGUNCj4+ID5zeW5jaHJvbmlzYXRpb24gbG9naWMuIFRoZSBhcHByb2Fj aCBKYWt1YiBoYXMgZGVzY3JpYmVkIGRlbGVnYXRlcyB0aGUNCj4+ID5zeW5jIHJlc3BvbnNpYmls aXR5IHRvIGNsaWVudHMgYW5kIHRoZSBzZXJ2ZXIgZG9lcyBub3QgZG8gdG9vIG11Y2ggam9iDQo+ PiA+YW5kIGNhbiBzY2FsZSAgdG8gaGFuZGxlIHRoZSBibGFzdCBvZiBwb3NzaWJsZSBQUk9QRklO RCByZXF1ZXN0cy4NCj4+ID5PbiB0aGUgb3RoZXIgaGFuZCwgYXMgeW91IG1lbnRpb25lZCwgdGhl IHNlcnZlciBjYW4gZmFjaWxpdGF0ZSB0aGUgc3luYw0KPj4gPmpvYiB0byBjbGllbnRzIGNyZWF0 aW5nIHNuYXBzaG90cyBvZiB0aGUgc3lzdGVtIGluIGEgZ2l2ZW4gbW9tZW50IGFuZA0KPj4gPmdp dmUgdGhlIGNsaWVudHMgYSBkZWx0YS4gVGhpcyBhcHByb2FjaCBwdXRzIG11Y2ggbW9yZSBsb2Fk IG9uIHRoZQ0KPj4gPnNlcnZlciBhbmQgaXQgaXMgbW9yZSBkaWZmaWN1bHQgdG8gc2NhbGUuDQo+ PiA+Qm90aCB0eXBlcyBvZiBzeW5jIGhhcyB0aGVpciBvd24gYmVuZWZpdHMgYW5kIGRyYXdiYWNr cyBhbmQgdGhlIGVsZWN0aW9uDQo+PiA+c2hvdWxkIGJlIG1hZGUgb24gdGhlIHVzZSBjYXNlIHlv dSB3YW50IGZvciB5b3VyIGJ1c2luZXNzLg0KPj4gPg0KPj4gPj5UaGlzIGFsc28gaGFzIHRoZSBw cm9ibGVtIHRoYXQgeW91IGhhdmUgbm8gc2VwYXJhdGlvbiBvZiBtZXRhZGF0YSBhbmQgZGF0YSwg YW5kIG5vIHZlcnNpb25pbmcsIHdoaWNoIG1lYW5zIHRoYXQgPnlvdSBoYXZlIHRvIGhhdmUgYSBj bGllbnQtc2VydmVyIG1vZGVsLCBhbmQgeW91IGNhbid0IGhhdmUgYSBkaXN0cmlidXRlZCBwZWVy IG1vZGVsLg0KPj4gPg0KPj4gPkkgdG90YWxseSBkaXNhZ3JlZSBoZXJlLCB5b3UgY2FuIGhhdmUg eW91ciBtZXRhZGF0YSBmdWxseSBkZXRhY2hlZCBmcm9tDQo+PiA+dGhlIGRhdGEgYW5kIGJlIGFi bGUgdG8gc3luYy4gQWxzbywgeW91IGNhbiBleHBvc2UgdmVyc2lvbnMgdHJvdWdoDQo+PiA+V2Vi REFWIGNyZWF0aW5nIHlvdXIgb3duIGxvZ2ljIG9yIHVzZSBXZWJEQVYgZXh0ZW5zaW9ucyB0aGF0 IGRlYWwgd2l0aA0KPj4gPnRoYXQuIFRoZSBSRkMgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjL3Jm YzMyNTMudHh0IGdpdmVzIEdJVC1saWtlDQo+PiA+dmVyc2lvbiBjb250cm9sIHRvIFdlYkRBViBS ZXNvdXJjZXMuDQo+PiA+DQo+PiA+Pk9rZXksIGJ1dCB3aGF0IHlvdSBuZWVkIHRvIHJlbWVtYmVy IHRoZSBjbGllbnQgc3RhdGUgYW5kIHBhc3MgaXQgb24gdG8gdGhlIHNlcnZlciB0byBjYWxjdWxh dGUgdGhlIGRpZmYgc3RhdGUuIEFueSA+Z29vZCBpZGVhcyBob3cgdG8gZG8gdGhhdD8NCj4+ID4N Cj4+ID4+S2VlcCB0aGUgbWV0YWRhdGEgc29ydGVkIChlLmcuIGJ5IG1vZGlmaWNhdGlvbiB0aW1l KSwgYW5kIGRvIGEgZGlmZiB3aGVuZXZlciBhIG5ldyB2ZXJzaW9uIGlzIGdlbmVyYXRlZC4gICBW ZXJzaW9ucyA+dGhhdCBoYXZlIG5ldmVyIGJlZW4gc2hhcmVkIHdpdGggb3RoZXIgcGVlcnMgc2hv dWxkIGJlIHRyaW1tZWQgb25jZSB0aGV5IGFyZSBub3QgdGhlIGhlYWQgdmVyc2lvbi4gICBXaGVu IHBlZXIgPkEgd2FudHMgdG8gc3luYyB3aXRoIHBlZXIgQiwgaXQgYW5ub3VuY2VzIHRoZSB2ZXJz aW9uIGl0IGhhcyBhbmQgdGhlIHZlcnNpb24gaXQgbGFzdCByZW1lbWJlcnMgc3luY2luZyB3aXRo IHBlZXIgQi4gICA+SWYgUGVlciBCIHJlbWVtYmVycyB0aGF0IHZlcnNpb24sIHRoZW4gdGhlIGRp ZmZlcmVuY2UgY2FuIGJlIGNvbXB1dGVkIHRyaXZpYWxseSwgTyhuKSwgYW5kIGlzIG1pbmltYWwg KG4qMiBhdCB3b3JzdCksID53aGVyZSBuIGlzIHRoZSBudW1iZXIgb2YgY2hhbmdlcy4gICBJZiBQ ZWVyIEIgaGFzIGxvc3QgaXRzIG1lbW9yeSwgdGhlbiBpdCBoYXMgdG8gc2VuZCB0aGUgY29tcGxl dGUgaW52ZW50b3J5IG9mIGl0cyA+aGVhZCB2ZXJzaW9uLCB3aGljaCBQZWVyIEEgY2FuIHRoZW4g Y29tcGFyZSB3aXRoIGl0cyBoZWFkIHRvIHNlZSB3aGF0J3MgY2hhbmdlZC4NCj4+ID4NCj4+ID5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPlN0b3Jh Z2VzeW5jIG1haWxpbmcgbGlzdA0KPj4gPlN0b3JhZ2VzeW5jQGlldGYub3JnDQo+PiA+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFp bGluZyBsaXN0DQo+U3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5j From nobody Sat Dec 5 19:37:52 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E438A1B2FE6 for ; Sat, 5 Dec 2015 19:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QqNr9vIP9d1 for ; Sat, 5 Dec 2015 19:37:49 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA7A1B2FE1 for ; Sat, 5 Dec 2015 19:37:48 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygCnhS0nrmNWQgAAAA--.1S2; Sun, 06 Dec 2015 11:40:23 +0800 (CST) Date: Sun, 6 Dec 2015 11:37:37 +0800 From: "Fei Song" To: mellon , storagesync References: <1449177286.2507848.457409737.10AEAB2B@webmail.messagingengine.com> <2015120411270531225432@bjtu.edu.cn> <1449236876.216680.458015521.42999C02@webmail.messagingengine.com>, <1449239689891-13379e89-8a9153c2-3597d400@fugue.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120611373768722760@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygCnhS0nrmNWQgAAAA--.1S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Gr17Jr4Uur45uw17uF1fCrg_yoWDWFcE9a yxAa9YkFn8JF9I9a18uFs7JFsIg3y5WFnrCFWDKF42qas8Z3ZYvFykWrs5ua4SvryjkrsI yr9avw1UGr1akjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbxxYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8Jr0_ Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU4T KuDUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Mechanisms to synchronize client file systems with Internet-based data storage services X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 03:37:51 -0000 SGkgVGVkLA0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5GcmlkYXksIERlYyA0LCAyMDE1 IDg6NDcgQU0gSHVnbyBHb256qKJsZXogTGFicmFkb3Igd3JvdGU6DQo+PiBUaGVyZSBhcmUgYWxy ZWFkeSBzeW5jaHJvbmlzYXRpb24gcGxhdGZvcm1zIGJ1aWx0IG9uIHRvcCBvZiBzdWNoDQo+PiBj b25jZXB0Lg0KPj4gWy4uLl0NCj4+IC0gb3duQ2xvdWQgd2hlbiBjb25maWd1cmVkIHRvIHVzZSBh biBPYmplY3QgU3RvcmFnZSBhcyB0aGUgUHJpbWFyeSBVc2VyDQo+PiBTdG9yYWdlLiAoTWV0YWRh dGEgaXMgaGFuZGxlZCBieSBhIE15U1FMIGRhdGFiYXNlKQ0KPj4gLSBDRVJOIEVPUyBTdG9yYWdl IFN5c3RlbS4gKE1ldGFkYXRhIGlzIGhhbmRsZWQgaW4gaGlnaCBwZXJmb3JtYW5jZQ0KPj4gaW4t bWVtb3J5IHN0cnVjdHVyZXMpLg0KPg0KPk9oLCB0aGF0J3MgdmVyeSBpbnRlcmVzdGluZy4gICBU aGFua3MgZm9yIHBvaW50aW5nIHRoYXQgb3V0LiAgIEknbSAoYSkgZ2xhZCB0byBrbm93IHRoYXQg aXQncyBub3QganVzdCBtZSwgYW5kIChiKSBpbnRlcmVzdGVkIGluIHdoYXQgb3duQ2xvdWQgYW5k IENlcm4gaGF2ZSBkb25lLiAgIEkgaGFkIGxvb2tlZCBhdCBvd25DbG91ZCBhIHdoaWxlIGJhY2sg YW5kIGRlY2lkZWQgdGhhdCBJIHdhc24ndCBpbnRlcmVzdGVkLCBidXQgbm93IEknbSBjdXJpb3Vz IGFnYWluLg0KDQpJbiB0aGlzIG1haWxpbmcgbGlzdCwgdGhlcmUgd2FzIGEgdG9waWMgbmFtZWQg obBbU3RvcmFnZXN5bmNdIFNvbWUgcHJlbGltaW5hcnkgaW52ZXN0aWdhdGlvbnMgb24gb3duQ2xv dWShsSBpbml0aWFsZWQgYnkgTGluaHVpIGFuZCBjb250cmlidXRlZCBieSBKYWt1Yi4NCkEgVVJM IGh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwgd2FzIGFsc28gcG9pbnRlZC4NCg0KPg0K Pg0KPi0tDQo+U2VudCBmcm9tIFdoaXRlb3V0IE1haWwgLSBodHRwczovL3doaXRlb3V0LmlvDQo+ DQo+TXkgUEdQIGtleTogaHR0cHM6Ly9rZXlzLndoaXRlb3V0LmlvL21lbGxvbkBmdWd1ZS5jb20= From nobody Sat Dec 5 20:05:21 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C101B3060 for ; Sat, 5 Dec 2015 20:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLG5bEfu_UMB for ; Sat, 5 Dec 2015 20:05:18 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id CA5051B305F for ; Sat, 5 Dec 2015 20:05:17 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygB3mPyatGNWQtUDAA--.8351S2; Sun, 06 Dec 2015 12:07:55 +0800 (CST) Date: Sun, 6 Dec 2015 12:05:11 +0800 From: "Fei Song" To: =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= , storagesync References: , <1449242636.238506.458104225.0E52F458@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120612051050002662@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygB3mPyatGNWQtUDAA--.8351S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXr47Kw1rCryfCF1fWw45Jrb_yoW5WryDpr 47JwsrGrZ8JF4rZwsF9F1IkrW8urykCrW7KFs0qw1fGa45CFyYgr17tr4rCa9rJry5Gw1j qr1FgFs8Gw4FqFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gryl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU0 eOJ7UUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 29 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 04:05:19 -0000 VGhlIGNvbnRlbnQgaXMgdmVyeSBjb21wcmVoZW5zaXZlLCBpbmNsdWRpbmcgIlRvcGljcyBvZiBp bnRlcmVzdCIgYW5kICJSZWxhdGVkIHByb2plY3RzIGFuZCBvcmdhbmlzYXRpb25zIg0KVGhhbmtz IEh1Z29+DQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+QXMgcHJvbWlzZWQgSaHkdmUg Y3JlYXRlZCBhIEdpdEh1YiByZXBvIHRvIGtlZXAgdHJhY2sgb2Ygc3VwcG9ydGluZw0KPmRvY3Vt ZW50cy4NCj4NCj5SZXBvOiBodHRwczovL2dpdGh1Yi5jb20vbGFia29kZS9JbnRlcm5ldC1TdG9y YWdlLVN5bmMNCj4NCj5JIHRvb2sgc29tZSBsaWJlcnR5IHRvIGNyZWF0ZSBhIGJhc2ljIHN0cnVj dHVyZS4gUGxlYXNlIGZlZWwgZnJlZSB0bw0KPmNoYW5nZSBpdCB1c2luZyB0aGUgbWV0aG9kcyBk ZXNjcmliZWQgaW4gdGhlIHJlcG8gb3IgYXNrIG1lIGRpcmVjdGx5Lg0KPg0KPkkgZ2F2ZSB0aGUg bmFtZTogQXBwbGljYWJpbGl0eSBvZiB1c2luZyBXZWJEQVYgYXMgYSBzeW5jaHJvbmlzYXRpb24N Cj5wcm90b2NvbCBtZWFud2hpbGUgdGhlIG5hbWUgaXQncyBkZWNpZGVkLg0KPg0KPldlIHNob3Vs ZCBzdGFydCBmaWxsaW5nIHRoZSBnYXBzIHJlZ2FyZGluZyB0aGlzIHRvcGljLg0KPg0KPkJlc3Qs DQo+DQo+SHVnbw0KPg0KPk9uIEZyaSwgRGVjIDQsIDIwMTUsIGF0IDAzOjM0IFBNLCBzdG9yYWdl c3luYy1yZXF1ZXN0QGlldGYub3JnIHdyb3RlOg0KPj4gU2VuZCBTdG9yYWdlc3luYyBtYWlsaW5n IGxpc3Qgc3VibWlzc2lvbnMgdG8NCj4+IAlzdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4gDQo+PiBU byBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQN Cj4+IAlodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+ PiBvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVs cCcgdG8NCj4+IAlzdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnDQo+PiANCj4+IFlvdSBjYW4g cmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KPj4gCXN0b3JhZ2VzeW5jLW93 bmVyQGlldGYub3JnDQo+PiANCj4+IFdoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3Vi amVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCj4+IHRoYW4gIlJlOiBDb250ZW50cyBv ZiBTdG9yYWdlc3luYyBkaWdlc3QuLi4iDQo+PiBUb2RheSdzIFRvcGljczoNCj4+IA0KPj4gICAg MS4gUmU6IFN0b3JhZ2VzeW5jIERpZ2VzdCwgVm9sIDUsIElzc3VlIDEgKExpbmh1aSBTdW4pDQo+ PiAgICAyLiBSZTogTWVjaGFuaXNtcyB0byBzeW5jaHJvbml6ZSBjbGllbnQgZmlsZSBzeXN0ZW1z IHdpdGgNCj4+ICAgICAgIEludGVybmV0LWJhc2VkIGRhdGEgc3RvcmFnZSBzZXJ2aWNlcyA8c3Rv cmFnZXN5bmMuaWV0Zi5vcmc+DQo+PiAgICAgICAoVGVkIExlbW9uKQ0KPj4gICAgMy4gIHJlY2Vu dCBpc3N1ZXMgZGlzY3Vzc2VkIChGZWkgU29uZykNCj4+ICAgIDQuIFJlOiBNZWNoYW5pc21zIHRv IHN5bmNocm9uaXplIGNsaWVudCBmaWxlIHN5c3RlbXMgd2l0aA0KPj4gICAgICAgSW50ZXJuZXQt YmFzZWQgZGF0YSBzdG9yYWdlIHNlcnZpY2VzIDxzdG9yYWdlc3luYy5pZXRmLm9yZz4NCj4+ICAg ICAgIChIdWdvIEdvbno/bGV6IExhYnJhZG9yKQ0KPj4gICAgNS4gUmU6IE1lY2hhbmlzbXMgdG8g c3luY2hyb25pemUgY2xpZW50IGZpbGUgc3lzdGVtcyB3aXRoDQo+PiAgICAgICBJbnRlcm5ldC1i YXNlZCBkYXRhIHN0b3JhZ2Ugc2VydmljZXMgPHN0b3JhZ2VzeW5jLmlldGYub3JnPg0KPj4gICAg ICAgKFRlZCBMZW1vbikNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNCj4+IFN0b3JhZ2VzeW5jQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2Vz eW5jDQo+PiBFbWFpbCBoYWQgNSBhdHRhY2htZW50czoNCj4+ICsgUmU6IFtTdG9yYWdlc3luY10g U3RvcmFnZXN5bmMgRGlnZXN0LCBWb2wgNSwgSXNzdWUgMQ0KPj4gICA4ayAobWVzc2FnZS9yZmM4 MjIpDQo+PiArIFJlOiBbU3RvcmFnZXN5bmNdIE1lY2hhbmlzbXMgdG8gc3luY2hyb25pemUgY2xp ZW50IGZpbGUgc3lzdGVtcyB3aXRoDQo+PiBJbnRlcm5ldC1iYXNlZCBkYXRhIHN0b3JhZ2Ugc2Vy dmljZXMgPHN0b3JhZ2VzeW5jLmlldGYub3JnPg0KPj4gICAzayAobWVzc2FnZS9yZmM4MjIpDQo+ PiArIFtTdG9yYWdlc3luY10gIHJlY2VudCBpc3N1ZXMgZGlzY3Vzc2VkDQo+PiAgIDJrIChtZXNz YWdlL3JmYzgyMikNCj4+ICsgUmU6IFtTdG9yYWdlc3luY10gTWVjaGFuaXNtcyB0byBzeW5jaHJv bml6ZSBjbGllbnQgZmlsZSBzeXN0ZW1zIHdpdGgNCj4+IEludGVybmV0LWJhc2VkIGRhdGEgc3Rv cmFnZSBzZXJ2aWNlcyA8c3RvcmFnZXN5bmMuaWV0Zi5vcmc+DQo+PiAgIDVrIChtZXNzYWdlL3Jm YzgyMikNCj4+ICsgUmU6IFtTdG9yYWdlc3luY10gTWVjaGFuaXNtcyB0byBzeW5jaHJvbml6ZSBj bGllbnQgZmlsZSBzeXN0ZW1zIHdpdGgNCj4+IEludGVybmV0LWJhc2VkIGRhdGEgc3RvcmFnZSBz ZXJ2aWNlcyA8c3RvcmFnZXN5bmMuaWV0Zi5vcmc+DQo+PiAgIDJrIChtZXNzYWdlL3JmYzgyMikN Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlN0 b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPlN0b3JhZ2VzeW5jQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw== From nobody Sat Dec 5 20:14:11 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5661B308C for ; Sat, 5 Dec 2015 20:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ves3Df3ZxgFC for ; Sat, 5 Dec 2015 20:14:09 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id C63F81B308A for ; Sat, 5 Dec 2015 20:14:08 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygD3WXautmNWCQAAAA--.1S2; Sun, 06 Dec 2015 12:16:46 +0800 (CST) Date: Sun, 6 Dec 2015 12:14:08 +0800 From: "Fei Song" To: "Markus Unterwaditzer" References: <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com>, <20151204181110.GA2418@localhost.localdomain> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120612140798437464@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygD3WXautmNWCQAAAA--.1S2 X-Coremail-Antispam: 1UD129KBjvJXoW7uryfAw4xGF43Ary3KrW8Xrb_yoW8Xr4DpF WSyF13Ka1Utr4Fvw409ry7uw10vws5XrW7GF1rJw1Iya4UA3s0gr10yr4F9rW7uryfGryj vry0g34kWw4jy3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gryl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 WlkDUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 04:14:10 -0000 SGksDQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+T24gVGh1LCBEZWMgMDMsIDIwMTUg YXQgMDI6Mzg6MDVQTSArMDAwMCwgVGVkIExlbW9uIHdyb3RlOg0KPj4gVGh1cnNkYXksIERlYyAz LCAyMDE1IDY6MDAgQU0gTGluaHVpIFN1biB3cm90ZToNCj4+ID4gSG93ZXZlciBJJ2QgcHJlZmVy IEhUVFAgcmF0aGVyIHRoYW4gV2ViREFWLiBTaW5jZSBJIHN0aWxsIHRoaW5rIFdlYkRBViBpcw0K Pj4gPiBub3Qgc3VpdGFibGUgZm9yIHRvZGF5J3Mgc3luYyBzZXJ2aWNlLiBUaGUgZnJlcXVlbmN5 IG9mIG9wZXJhdGlvbnMgaXMgZmFyDQo+PiA+IGhpZ2hlciB0aGFuIHdoYXQgV2ViREFWIGV4cGVj dHMuIEZvciBleGFtcGxlLCBmcmVxdWVudGx5IHNlbmRpbmcgcHJvcGZpbmQNCj4+ID4gdG8gZGV0 ZWN0IGNoYW5nZXMgaXMgbm90IGEgZ29vZCB3YXkgaW4gbXkgdmlldy4NCj4+IA0KPj4gV2ViREFW IGlzIEhUVFAuICAgSG93ZXZlciwgeW91ciBwb2ludCBhYm91dCBwcm9wZmluZCBpcyBjb3JyZWN0 LS10aGF0IGRvZXNuJ3QNCj4+IHNjYWxlLiAgIFdoYXQgeW91IHdhbnQgaXMgYSBzZXBhcmF0ZSBs YXllciBmb3IgZGVhbGluZyB3aXRoIHN5bmNocm9uaXphdGlvbg0KPj4gb2YgbWV0YWRhdGEuICAg WW91IGNvdWxkIHVzZSBIVFRQIHRyYW5zcG9ydCB0byBkbyB0aGlzLCBidXQgbm90IHByb3BmaW5k Lg0KPg0KPldlIGRvIGhhdmUgdGhhdCBzZXBhcmF0ZSBsYXllciBpbiB0aGUgZm9ybSBvZg0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL3JmYy9yZmM2NTc4LnR4dCBhbmQgc28gZmFyIG9ubHkgYSBoYW5k ZnVsIG9mIEZPU1Mgc2VydmVycw0KPmhhdmUgaW1wbGVtZW50ZWQgaXQuIFRoZSBmdWxseS1pbnRl cm9wYWJsZSB3YXkgdG8gc3luY2hyb25pemUgc2VydmVycyBzdGlsbA0KPmluY2x1ZGVzIGEgZmFs bGJhY2sgdG8gYSBmdWxsIFBST1BGSU5ELg0KPg0KPkVUYWdzIG9uIGZvbGRlciBsaXN0aW5ncyBh cmUgYXJndWFibHkgc2ltcGxlciB0byBpbXBsZW1lbnQgdGhhbiBhIHBhcnRpYWwNCj50cmFuc2Fj dGlvbiBoaXN0b3J5LiByZW1vdGVTdG9yYWdlIHJlcXVpcmVzIHRob3NlLCBhbmQgY29uc2VxdWVu dGx5IGFsbCBzZXJ2ZXJzDQo+bXVzdCBpbXBsZW1lbnQgaXQuDQoNCmFoLCBkbyB5b3UgdGhpbmsg aXQgd2lsbCB0cmlnZ2VyIG11Y2ggZXh0cmEgYnVyZGVucyBmb3IgdGhlIHNlcnZlcnM/DQoNCj4N Cj4+IA0KPj4gDQo+PiAtLQ0KPj4gU2VudCBmcm9tIFdoaXRlb3V0IE1haWwgLSBodHRwczovL3do aXRlb3V0LmlvDQo+PiANCj4+IE15IFBHUCBrZXk6IGh0dHBzOi8va2V5cy53aGl0ZW91dC5pby9t ZWxsb25AZnVndWUuY29tDQo+DQo+DQo+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+PiBTdG9y YWdlc3luY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zdG9yYWdlc3luYw0KPg0KPg== From nobody Sat Dec 5 20:20:49 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272411B30AE for ; Sat, 5 Dec 2015 20:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sW8Pn3u9Q6C for ; Sat, 5 Dec 2015 20:20:46 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1E05A1B30B0 for ; Sat, 5 Dec 2015 20:20:45 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygAH7v4+uGNWG9oDAA--.8587S2; Sun, 06 Dec 2015 12:23:26 +0800 (CST) Date: Sun, 6 Dec 2015 12:20:42 +0800 From: "Fei Song" To: "Markus Unterwaditzer" , =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com>, <20151204181850.GB2418@localhost.localdomain> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120612204143708566@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygAH7v4+uGNWG9oDAA--.8587S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZw4UKF4rJrWfGry8Aw17trb_yoWrZrWDpF 17JF1UKr4UJr4rGw1vqF17uw10vryDGrW7X3Z8Xr1xJ3s0qF98Gr17Jr1ruFW7Jry5Jr1U tr1F9r13Gr48Jr7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gryl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07 jrMa5UUUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Linhui Sun , storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 04:20:48 -0000 DQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+T24gV2VkLCBEZWMgMDIsIDIwMTUgYXQg MTE6Mjg6NDhBTSArMDEwMCwgSHVnbyBHb256qKJsZXogTGFicmFkb3Igd3JvdGU6DQo+PiBPZiBj b3Vyc2UsIHRoZSByZW1vdGVTdG9yYWdlIGlzIHRhcmdldGVkIHRvIGJyb3dzZXJzLCBzbyBzeW5j aW5nIGRvZXMNCj4+IG5vdCBtYWtlIHRvbyBtdWNoIHNlbnNlIGluIHRoaXMgY2FzZS4gV2l0aCB0 aGUgcmlzZSBvZiBMaW51eCBjb250YWluZXINCj4+IG1pY3JvLXNlcnZpY2UgYmFzZWQgYXJjaGl0 ZWN0dXJlcywgdGhlIGRlcGxveW1lbnQgb2YgP3N1Y2ggaGlnaGx5DQo+PiBjb21wbGV4IHN5c3Rl bXMgc2hvdWxkIGJlY29tZSBlYXNpZXIgYW5kIGZhc3Rlci4NCj4NCj5JdCBpcyBub3QgZXhjbHVz aXZlbHkgdGFyZ2V0ZWQgYXQgYnJvd3NlcnMsIGFsdGhvdWdoIHRoZSBicm93c2VyJ3MgT3JpZ2lu LWJhc2VkDQo+c2VjdXJpdHkgbW9kZWwgaXMgcmVxdWlyZWQgZm9yIHNhbmUgY2xpZW50IGlkZW50 aWZpY2F0aW9uLiBZb3UgY2FuIHRvdGFsbHkNCj5hY2Nlc3MgcmVtb3RlU3RvcmFnZSBhY2NvdW50 cyB1c2luZyBkZXNrdG9wIGFwcHMsIGEgcHJvb2Ytb2YtY29uY2VwdCBleGlzdHMgYXQNCj5odHRw czovL2dpdGh1Yi5jb20vdW50aXRha2VyL3ZkaXJzeW5jZXIuDQo+DQo+U3luY2hyb25pemF0aW9u IGlzIGEgY29tcGxldGVseSB1bnJlbGF0ZWQgdG9waWMuIEkgZG9uJ3Qgc2VlIGhvdyBpdCdzIHJl bGF0ZWQNCj50byB3aGV0aGVyIHRoZSBwcm90b2NvbCBpcyB0YXJnZXRlZCBhdCBicm93c2VyIGFw cGxpY2F0aW9ucywgaW4gZWl0aGVyIGNhc2UNCj5vZmZsaW5lIHN5bmMgaGFzIHRvIHdvcmsuIEFu ZCBpdCBkb2VzLg0KDQpUaGF0IGlzIHdoeSBpdCBzaG91bGQgYmUgY2xhcmlmaWVkIGF0IHRoZSBi ZWdpbm5pbmcgb2YgZG9jdW1lbnQuLi5lbXBoYXNpemUgdGhlIHRhcmdldCB1c2FnZSBzY2VuYXJp b3MuIA0KDQo+DQo+SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gd2l0aCAibGludXgg Y29udGFpbmVyIG1pY3JvLXNlcnZpY2UgYmFzZWQNCj5hcmNoaXRlY3R1cmVzIiwgb3IgaG93IGl0 IGlzIHJlbGF0ZWQgdG8gdGhpcyBkaXNjdXNzaW9uLg0KPg0KPi0tIE1hcmt1cw0KPg0KPj4gDQo+ PiBCZXN0LA0KPj4gDQo+PiBIdWdvDQo+PiANCj4+ID4gUmVnYXJkcywgTGluaHVpDQo+PiA+Pg0K Pj4gPj4NCj4+ID4+PiBSZWdhcmRzLCBMaW5odWkNCj4+ID4+Pj4gb25lIGZyb20gdGhlIENFUk4g RU9TIHByb2plY3QgKG1hbmFnZW1lbnQsIGRpc2sgYW5kIHF1ZXVlIHNlcnZlcnMpLg0KPj4gPj4+ Pg0KPj4gPj4+PiBUaGUgUGhhc2UgSSBoYXMgaW1wbGVtZW50ZWQgdGhlIG93bkNsb3VkIFN5bmMg UHJvdG9jb2wgYW5kIFBoYXNlIElJDQo+PiA+Pj4+IHdpbGwgaW1wbGVtZW50IHRoZSBTZWFGaWxl IFN5bmMgUHJvdG9jb2wuIFRoZSBjaG9pY2Ugb2YgdGhlc2UNCj4+ID4+Pj4gcHJvdG9jb2xzIGFt b25nIG90aGVycyBpcyBiZWNhdXNlIHRoZXkgYXJlIHJlYWxseSBvcHBvc2VkIHRvIGVhY2gNCj4+ ID4+Pj4gb3RoZXIgaW4gdGVybXMgb2Ygc3luY2luZyAoZGVsdGEgdnMgbm9uLWRlbHRhLCBzdGF0 ZS1iYXNlZCB2cyBsb2cvZXZlbnQvZ2l0LQ0KPj4gPj4+PiBiYXNlZCBzeW5jIKGtKSwgc28gZmlu ZGluZyBhIGNvbW1vbiBhcHByb2FjaCBpcyBtb3JlIGNoYWxsZW5naW5nLg0KPj4gPj4+Pg0KPj4g Pj4+PiBQcm92aWRpbmcgYSBiYXNlIHNwZWNpZmljYXRpb24vYXJjaGl0ZWN0dXJlIHRvIG1lYXN1 cmUgdGhlDQo+PiA+Pj4+IGZlYXNpYmlsaXR5IG9mIHRoaXMgZHJhZnQgaXMgb25lIG9mIHRoZSBv YmplY3RpdmVzIG9mIHRoZSBwcm9qZWN0Lg0KPj4gPj4+Pg0KPj4gPj4+PiBJIGJlbGlldmUgdGhh dCB0aGUgd29yayBiZWluZyBkb25lIGhlcmUgYW5kIGluIENsYXdJTyBhcmUNCj4+ID4+Pj4gc3Vw cGxlbWVudGFyeSB0byBlYWNoIG90aGVyIGFuZCBJIHRoaW5rIG11dHVhbCBjb2xsYWJvcmF0aW9u IGNvdWxkDQo+PiA+Pj4+IGJlIGJlbmVmaWNpYWwgZm9yIGJvdGggc2lkZXMuDQo+PiA+Pj4+DQo+ PiA+Pj4+IEFsc28sIGlmIHRoZXJlIGlzIGludGVyZXN0LCB0aGUgcmVtb3RlU3RvcmFnZSBBUEkg Y2FuIGJlIGFkZGVkIHRvDQo+PiA+Pj4+IENsYXdJTy4NCj4+ID4+Pj4NCj4+ID4+Pj4gQmVzdCBy ZWdhcmRzLA0KPj4gPj4+Pg0KPj4gPj4+PiBIdWdvIEdvbnphbGV6IExhYnJhZG9yDQo+PiA+Pj4+ DQo+PiA+Pj4+IE9uIFR1ZSwgRGVjIDEsIDIwMTUsIGF0IDA5OjAwIFBNLCBzdG9yYWdlc3luYy1y ZXF1ZXN0QGlldGYub3JnDQo+PiA+Pj4+IHdyb3RlOg0KPj4gPj4+PiA+IFNlbmQgU3RvcmFnZXN5 bmMgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQo+PiA+Pj4+ID4gc3RvcmFnZXN5bmNAaWV0 Zi5vcmcNCj4+ID4+Pj4gPg0KPj4gPj4+PiA+IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2 aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KPj4gPj4+PiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMgb3IsIHZpYSBlbWFpbCwNCj4+ID4+Pj4g PiBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8/ID8gPyA/c3Rv cmFnZXN5bmMtDQo+PiA+Pj4+ID4gcmVxdWVzdEBpZXRmLm9yZw0KPj4gPj4+PiA+DQo+PiA+Pj4+ ID4gWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0PyA/ID8gP3N0 b3JhZ2VzeW5jLQ0KPj4gPj4+PiA+IG93bmVyQGlldGYub3JnDQo+PiA+Pj4+ID4NCj4+ID4+Pj4g PiBXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBt b3JlDQo+PiA+Pj4+ID4gc3BlY2lmaWMgdGhhbiAiUmU6IENvbnRlbnRzIG9mIFN0b3JhZ2VzeW5j IGRpZ2VzdC4uLiIgVG9kYXkncw0KPj4gPj4+PiA+IFRvcGljczoNCj4+ID4+Pj4gPg0KPj4gPj4+ PiA+MS4gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2U/ID8gSW50ZXJu ZXQtRHJhZnQNCj4+ID4+Pj4gPmF2YWlsYWJsZSAoTWljaGllbCBkZSBKb25nKT8gPyAyLiBSZTog TmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLQ0KPj4gPj4+PiA+cmVtb3Rlc3RvcmFnZSBJbnRl cm5ldC1EcmFmdD8gPyA/ID9hdmFpbGFibGUgKEdpaGFuIERpYXMpPyA/IDMuDQo+PiA+Pj4+ID5S ZTogTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgSW50ZXJuZXQtRHJh ZnQNCj4+ID4+Pj4gPmF2YWlsYWJsZSAoRmVpIFNvbmcpDQo+PiA+Pj4+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+Pj4gPiBTdG9yYWdlc3lu YyBtYWlsaW5nIGxpc3QgU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+ID4+Pj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jIEVtYWlsIGhhZCAzDQo+PiA+ Pj4+ID4gYXR0YWNobWVudHM6DQo+PiA+Pj4+ID4gKyBbU3RvcmFnZXN5bmNdIE5ldyB2ZXJzaW9u IG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlIEludGVybmV0LQ0KPj4gPj4+PiA+ICAgRHJh ZnQgYXZhaWxhYmxlPyA/MmsgKG1lc3NhZ2UvcmZjODIyKQ0KPj4gPj4+PiA+ICsgUmU6IFtTdG9y YWdlc3luY10gTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLXJlbW90ZXN0b3JhZ2UgSW50ZXJu ZXQtDQo+PiA+Pj4+ID4gICBEcmFmdCBhdmFpbGFibGU/ID8xayAobWVzc2FnZS9yZmM4MjIpDQo+ PiA+Pj4+ID4gKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmct cmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC0NCj4+ID4+Pj4gPiAgIERyYWZ0IGF2YWlsYWJsZT8gPzJr IChtZXNzYWdlL3JmYzgyMikNCj4+ID4+Pj4NCj4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+Pj4gU3RvcmFnZXN5bmMgbWFpbGluZyBs aXN0IFN0b3JhZ2VzeW5jQGlldGYub3JnDQo+PiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+ID4+DQo+DQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gU3RvcmFnZXN5bmMgbWFpbGluZyBs aXN0DQo+PiBTdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+U3RvcmFn ZXN5bmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 b3JhZ2VzeW5j From nobody Sun Dec 6 01:35:03 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105371A1EFE for ; Sun, 6 Dec 2015 01:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz_2ELsaTTlQ for ; Sun, 6 Dec 2015 01:34:58 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id DB3B41A1EFD for ; Sun, 6 Dec 2015 01:34:57 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygD309HhAWRWSAAAAA--.20S2; Sun, 06 Dec 2015 17:37:37 +0800 (CST) Date: Sun, 6 Dec 2015 17:34:51 +0800 From: "Fei Song" To: =?gb2312?B?SHVnbyBHb256qKJsZXogTGFicmFkb3I=?= , "Markus Unterwaditzer" References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <20151204181850.GB2418@localhost.localdomain>, <1449261021.2660424.458369441.7C6FBE34@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120617345009328567@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygD309HhAWRWSAAAAA--.20S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Xr17Aw18Zr4DXr1kZFW7XFb_yoW7uF13pF W3JF47Kr4DJr4rAw1qqr17Zw10vry8GrW7Xrn8Jr17J3s0vF98Kr1Utr1ruFW7Jry5Gr1j qr4YgF13Grs5JF7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_GFWl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUxe HqDUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Linhui Sun , storagesync , Michiel de Jong Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 09:35:01 -0000 KzENCg0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj4NCj4NCj5PbiBGcmksIERlYyA0LCAy MDE1LCBhdCAwNzoxOCBQTSwgTWFya3VzIFVudGVyd2FkaXR6ZXIgd3JvdGU6DQo+PiBPbiBXZWQs IERlYyAwMiwgMjAxNSBhdCAxMToyODo0OEFNICswMTAwLCBIdWdvIEdvbnqoomxleiBMYWJyYWRv ciB3cm90ZToNCj4+ID4gT2YgY291cnNlLCB0aGUgcmVtb3RlU3RvcmFnZSBpcyB0YXJnZXRlZCB0 byBicm93c2Vycywgc28gc3luY2luZyBkb2VzDQo+PiA+IG5vdCBtYWtlIHRvbyBtdWNoIHNlbnNl IGluIHRoaXMgY2FzZS4gV2l0aCB0aGUgcmlzZSBvZiBMaW51eCBjb250YWluZXINCj4+ID4gbWlj cm8tc2VydmljZSBiYXNlZCBhcmNoaXRlY3R1cmVzLCB0aGUgZGVwbG95bWVudCBvZiA/c3VjaCBo aWdobHkNCj4+ID4gY29tcGxleCBzeXN0ZW1zIHNob3VsZCBiZWNvbWUgZWFzaWVyIGFuZCBmYXN0 ZXIuDQo+PiANCj4+IEl0IGlzIG5vdCBleGNsdXNpdmVseSB0YXJnZXRlZCBhdCBicm93c2Vycywg YWx0aG91Z2ggdGhlIGJyb3dzZXIncw0KPj4gT3JpZ2luLWJhc2VkDQo+PiBzZWN1cml0eSBtb2Rl bCBpcyByZXF1aXJlZCBmb3Igc2FuZSBjbGllbnQgaWRlbnRpZmljYXRpb24uIFlvdSBjYW4NCj4+ IHRvdGFsbHkNCj4+IGFjY2VzcyByZW1vdGVTdG9yYWdlIGFjY291bnRzIHVzaW5nIGRlc2t0b3Ag YXBwcywgYSBwcm9vZi1vZi1jb25jZXB0DQo+PiBleGlzdHMgYXQNCj4+IGh0dHBzOi8vZ2l0aHVi LmNvbS91bnRpdGFrZXIvdmRpcnN5bmNlci4NCj4+IA0KPg0KPlRoYXQncyBncmVhdCB0byBoZWFy LiBJZiB0aGlzIGlzIGFjaGlldmFibGUgbWF5YmUgd2lsbCBiZSBnb29kIHRvDQo+Y2xhcmlmeSB0 aGlzIGFzcGVjdCBpbiB0aGUgc3BlYy4NCj4NCj4+RnJvbSB0aGUgYWJzdHJhY3QNCj4NCj4gICAg VGhpcyBkcmFmdCBkZXNjcmliZXMgYSBwcm90b2NvbCBieSB3aGljaCBjbGllbnQtc2lkZSBhcHBs aWNhdGlvbnMsDQo+ICAgIHJ1bm5pbmcgaW5zaWRlIGEgd2ViIGJyb3dzZXIsIGNhbiBjb21tdW5p Y2F0ZSB3aXRoIGEgZGF0YSBzdG9yYWdlDQo+ICAgIHNlcnZlciB0aGF0IGlzIGhvc3RlZCBvbiBh IGRpZmZlcmVudCBkb21haW4gbmFtZS4gVGhpcyB3YXksIHRoZQ0KPiAgICBwcm92aWRlciBvZiBh IHdlYiBhcHBsaWNhdGlvbiBuZWVkIG5vdCBhbHNvIHBsYXkgdGhlIHJvbGUgb2YgZGF0YQ0KPiAg ICBzdG9yYWdlIHByb3ZpZGVyLiBUaGUgcHJvdG9jb2wgc3VwcG9ydHMgc3RvcmluZywgcmV0cmll dmluZywgYW5kDQo+ICAgIHJlbW92aW5nIGluZGl2aWR1YWwgZG9jdW1lbnRzLCBhcyB3ZWxsIGFz IGxpc3RpbmcgdGhlIGNvbnRlbnRzIG9mIGFuDQo+ICAgIGluZGl2aWR1YWwgZm9sZGVyLCBhbmQg YWNjZXNzIGNvbnRyb2wgaXMgYmFzZWQgb24gYmVhcmVyIHRva2Vucy4NCj4NCj4NCj5pdCBpcyBk aWZmaWN1bHQgdG8gaW5mZXIgdGhhdCB0aGUgc3BlYyBpcyBhbHNvIHRhcmdldGVkIHRvIG5vbi13 ZWIgYXBwcw0KPmFzIHRoZXJlIGFyZSBubyBtZW50aW9ucyB0byBzZXJ2ZXItc2lkZSBvciBkZXNr dG9wIGFwcHMuDQo+DQo+QXMgZmFyIGFzIEkga25vdyB0aGUgT0F1dGggYXV0aGVudGljYXRpb24g ZmxvdyB3b3JrcyBpbiBjbGllbnQtc2lkZSB3ZWINCj5hcHBsaWNhdGlvbnMsIGhhdmUgeW91IG1h bmFnZWQgdG8gdXNlIHN1Y2ggbWVjaGFuaXNtIGluIHlvdXIgbm9uLXdlYg0KPnByb2plY3QgPyBU aGF0IHdvdWxkIGJlIGEgcmVhbGx5IGludGVyZXN0aW5nIGFjaGlldmVtZW50LiBNYXliZSB0aGlz IGlzDQo+dGhlIGNhdXNlIHdoeSByZW1vdGVTdG9yYWdlIGRvZXMgbm90IG1lbnRpb24gbm9uLXdl YiBhcHBzIGluIHRoZWlyDQo+YWJzdHJhY3QuDQo+DQo+DQo+U3VtbW9uaW5nIE1pY2hpZWwgdG8g Y2xhcmlmeSB0aGlzIGFzcGVjdC4NCj4NCj4+IFN5bmNocm9uaXNhdGlvbiBpcyBhIGNvbXBsZXRl bHkgdW5yZWxhdGVkIHRvcGljLiBJIGRvbid0IHNlZSBob3cgaXQncw0KPj4gcmVsYXRlZA0KPj4g dG8gd2hldGhlciB0aGUgcHJvdG9jb2wgaXMgdGFyZ2V0ZWQgYXQgYnJvd3NlciBhcHBsaWNhdGlv bnMsIGluIGVpdGhlcg0KPj4gY2FzZQ0KPj4gb2ZmbGluZSBzeW5jIGhhcyB0byB3b3JrLiBBbmQg aXQgZG9lcy4NCj4+IA0KPj4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gd2l0aCAi bGludXggY29udGFpbmVyIG1pY3JvLXNlcnZpY2UNCj4+IGJhc2VkDQo+PiBhcmNoaXRlY3R1cmVz Iiwgb3IgaG93IGl0IGlzIHJlbGF0ZWQgdG8gdGhpcyBkaXNjdXNzaW9uLg0KPj4gDQo+DQo+VGhh dCB3YXMgc2FpZCB0byBnaXZlIGFuIGV4YW1wbGUgb2YgaG93IHVzaW5nIERvY2tlciBDb250YWlu ZXJzIGNhbiBoZWxwDQo+dG8gbWFuYWdlIG5vbi1tb25vbGl0aGljIGFwcGxpY2F0aW9ucy4gT2Yg Y291cnNlLCB0aGF0IGlzIG5vdCBkaXJlY3RseQ0KPnJlbGF0ZWQgdG8gc3luYy4NCj4NCj4+IC0t IE1hcmt1cw0KPj4gDQo+PiA+IA0KPj4gPiBCZXN0LA0KPj4gPiANCj4+ID4gSHVnbw0KPj4gPiAN Cj4+ID4gPiBSZWdhcmRzLCBMaW5odWkNCj4+ID4gPj4NCj4+ID4gPj4NCj4+ID4gPj4+IFJlZ2Fy ZHMsIExpbmh1aQ0KPj4gPiA+Pj4+IG9uZSBmcm9tIHRoZSBDRVJOIEVPUyBwcm9qZWN0IChtYW5h Z2VtZW50LCBkaXNrIGFuZCBxdWV1ZSBzZXJ2ZXJzKS4NCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+IFRo ZSBQaGFzZSBJIGhhcyBpbXBsZW1lbnRlZCB0aGUgb3duQ2xvdWQgU3luYyBQcm90b2NvbCBhbmQg UGhhc2UgSUkNCj4+ID4gPj4+PiB3aWxsIGltcGxlbWVudCB0aGUgU2VhRmlsZSBTeW5jIFByb3Rv Y29sLiBUaGUgY2hvaWNlIG9mIHRoZXNlDQo+PiA+ID4+Pj4gcHJvdG9jb2xzIGFtb25nIG90aGVy cyBpcyBiZWNhdXNlIHRoZXkgYXJlIHJlYWxseSBvcHBvc2VkIHRvIGVhY2gNCj4+ID4gPj4+PiBv dGhlciBpbiB0ZXJtcyBvZiBzeW5jaW5nIChkZWx0YSB2cyBub24tZGVsdGEsIHN0YXRlLWJhc2Vk IHZzIGxvZy9ldmVudC9naXQtDQo+PiA+ID4+Pj4gYmFzZWQgc3luYyChrSksIHNvIGZpbmRpbmcg YSBjb21tb24gYXBwcm9hY2ggaXMgbW9yZSBjaGFsbGVuZ2luZy4NCj4+ID4gPj4+Pg0KPj4gPiA+ Pj4+IFByb3ZpZGluZyBhIGJhc2Ugc3BlY2lmaWNhdGlvbi9hcmNoaXRlY3R1cmUgdG8gbWVhc3Vy ZSB0aGUNCj4+ID4gPj4+PiBmZWFzaWJpbGl0eSBvZiB0aGlzIGRyYWZ0IGlzIG9uZSBvZiB0aGUg b2JqZWN0aXZlcyBvZiB0aGUgcHJvamVjdC4NCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+IEkgYmVsaWV2 ZSB0aGF0IHRoZSB3b3JrIGJlaW5nIGRvbmUgaGVyZSBhbmQgaW4gQ2xhd0lPIGFyZQ0KPj4gPiA+ Pj4+IHN1cHBsZW1lbnRhcnkgdG8gZWFjaCBvdGhlciBhbmQgSSB0aGluayBtdXR1YWwgY29sbGFi b3JhdGlvbiBjb3VsZA0KPj4gPiA+Pj4+IGJlIGJlbmVmaWNpYWwgZm9yIGJvdGggc2lkZXMuDQo+ PiA+ID4+Pj4NCj4+ID4gPj4+PiBBbHNvLCBpZiB0aGVyZSBpcyBpbnRlcmVzdCwgdGhlIHJlbW90 ZVN0b3JhZ2UgQVBJIGNhbiBiZSBhZGRlZCB0bw0KPj4gPiA+Pj4+IENsYXdJTy4NCj4+ID4gPj4+ Pg0KPj4gPiA+Pj4+IEJlc3QgcmVnYXJkcywNCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+IEh1Z28gR29u emFsZXogTGFicmFkb3INCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+IE9uIFR1ZSwgRGVjIDEsIDIwMTUs IGF0IDA5OjAwIFBNLCBzdG9yYWdlc3luYy1yZXF1ZXN0QGlldGYub3JnDQo+PiA+ID4+Pj4gd3Jv dGU6DQo+PiA+ID4+Pj4gPiBTZW5kIFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9u cyB0bw0KPj4gPiA+Pj4+ID4gc3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+ID4gPj4+PiA+DQo+PiA+ ID4+Pj4gPiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdl YiwgdmlzaXQNCj4+ID4gPj4+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3RvcmFnZXN5bmMgb3IsIHZpYSBlbWFpbCwNCj4+ID4gPj4+PiA+IHNlbmQgYSBtZXNzYWdl IHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bz8gPyA/ID9zdG9yYWdlc3luYy0NCj4+ID4g Pj4+PiA+IHJlcXVlc3RAaWV0Zi5vcmcNCj4+ID4gPj4+PiA+DQo+PiA+ID4+Pj4gPiBZb3UgY2Fu IHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQ/ID8gPyA/c3RvcmFnZXN5bmMt DQo+PiA+ID4+Pj4gPiBvd25lckBpZXRmLm9yZw0KPj4gPiA+Pj4+ID4NCj4+ID4gPj4+PiA+IFdo ZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUN Cj4+ID4gPj4+PiA+IHNwZWNpZmljIHRoYW4gIlJlOiBDb250ZW50cyBvZiBTdG9yYWdlc3luYyBk aWdlc3QuLi4iIFRvZGF5J3MNCj4+ID4gPj4+PiA+IFRvcGljczoNCj4+ID4gPj4+PiA+DQo+PiA+ ID4+Pj4gPjEuIE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlPyA/IElu dGVybmV0LURyYWZ0DQo+PiA+ID4+Pj4gPmF2YWlsYWJsZSAoTWljaGllbCBkZSBKb25nKT8gPyAy LiBSZTogTmV3IHZlcnNpb24gb2YgZHJhZnQtZGVqb25nLQ0KPj4gPiA+Pj4+ID5yZW1vdGVzdG9y YWdlIEludGVybmV0LURyYWZ0PyA/ID8gP2F2YWlsYWJsZSAoR2loYW4gRGlhcyk/ID8gMy4NCj4+ ID4gPj4+PiA+UmU6IE5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWRlam9uZy1yZW1vdGVzdG9yYWdlIElu dGVybmV0LURyYWZ0DQo+PiA+ID4+Pj4gPmF2YWlsYWJsZSAoRmVpIFNvbmcpDQo+PiA+ID4+Pj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiA+ Pj4+ID4gU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0IFN0b3JhZ2VzeW5jQGlldGYub3JnDQo+PiA+ ID4+Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5j IEVtYWlsIGhhZCAzDQo+PiA+ID4+Pj4gPiBhdHRhY2htZW50czoNCj4+ID4gPj4+PiA+ICsgW1N0 b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRl cm5ldC0NCj4+ID4gPj4+PiA+ICAgRHJhZnQgYXZhaWxhYmxlPyA/MmsgKG1lc3NhZ2UvcmZjODIy KQ0KPj4gPiA+Pj4+ID4gKyBSZTogW1N0b3JhZ2VzeW5jXSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1k ZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC0NCj4+ID4gPj4+PiA+ICAgRHJhZnQgYXZhaWxh YmxlPyA/MWsgKG1lc3NhZ2UvcmZjODIyKQ0KPj4gPiA+Pj4+ID4gKyBSZTogW1N0b3JhZ2VzeW5j XSBOZXcgdmVyc2lvbiBvZiBkcmFmdC1kZWpvbmctcmVtb3Rlc3RvcmFnZSBJbnRlcm5ldC0NCj4+ ID4gPj4+PiA+ICAgRHJhZnQgYXZhaWxhYmxlPyA/MmsgKG1lc3NhZ2UvcmZjODIyKQ0KPj4gPiA+ Pj4+DQo+PiA+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ID4gPj4+PiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QgU3RvcmFnZXN5bmNAaWV0 Zi5vcmcNCj4+ID4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 b3JhZ2VzeW5jDQo+PiA+ID4+DQo+PiANCj4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ID4gU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+PiA+ IFN0b3JhZ2VzeW5jQGlldGYub3JnDQo+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+IA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+U3RvcmFn ZXN5bmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 b3JhZ2VzeW5j From nobody Sun Dec 6 02:13:49 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398871ACCFE for ; Sun, 6 Dec 2015 02:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.489 X-Spam-Level: *** X-Spam-Status: No, score=3.489 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4BcICDem4CZ for ; Sun, 6 Dec 2015 02:13:47 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id BCCDF1ACCF4 for ; Sun, 6 Dec 2015 02:13:46 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygD3hKsBC2RWBwAAAA--.0S2; Sun, 06 Dec 2015 18:16:33 +0800 (CST) Date: Sun, 6 Dec 2015 18:13:47 +0800 From: "Fei Song" To: "Sebastian Kippe" , storagesync References: <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <20151204181850.GB2418@localhost.localdomain> <1449261021.2660424.458369441.7C6FBE34@webmail.messagingengine.com>, <56621292.8010901@kip.pe> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120618134693725971@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygD3hKsBC2RWBwAAAA--.0S2 X-Coremail-Antispam: 1UD129KBjvdXoWrtFykCr45CF1UGFWkKryfJFb_yoWDJFX_CF y8tF1xJw1UGrW5tw45tF15trnrJw4jgF1UJ34kJanFgw1xZ34kGr4xJrZ0v3WxXry8XFn8 ur93Ar18t3yYvjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbxxYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8Jr0_ Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8twCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUcT mhDUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 10:13:48 -0000 SGkgU2ViYXN0aWFuDQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+SGksDQo+DQo+PiBB cyBmYXIgYXMgSSBrbm93IHRoZSBPQXV0aCBhdXRoZW50aWNhdGlvbiBmbG93IHdvcmtzIGluIGNs aWVudC1zaWRlIHdlYg0KPj4gYXBwbGljYXRpb25zLCBoYXZlIHlvdSBtYW5hZ2VkIHRvIHVzZSBz dWNoIG1lY2hhbmlzbSBpbiB5b3VyIG5vbi13ZWINCj4+IHByb2plY3QgPyBUaGF0IHdvdWxkIGJl IGEgcmVhbGx5IGludGVyZXN0aW5nIGFjaGlldmVtZW50LiBNYXliZSB0aGlzIGlzDQo+PiB0aGUg Y2F1c2Ugd2h5IHJlbW90ZVN0b3JhZ2UgZG9lcyBub3QgbWVudGlvbiBub24td2ViIGFwcHMgaW4g dGhlaXINCj4+IGFic3RyYWN0Lg0KPg0KPlRoZXJlIGFyZSBtYW55IHByb2dyYW1zIGRvaW5nIHRo aXMgaW4gc29tZSB3YXkgdG9kYXksIHVzdWFsbHkgaW52b2x2aW5nDQo+YSBXZWIgVmlldyBjb21w b25lbnQgb2Ygc29tZSBraW5kLiBDaGVjayBvdXQgR25vbWUgT25saW5lIEFjY291bnRzIGZvcg0K PmV4YW1wbGUuIE9yIG1hbnkgQW5kcm9pZCBhcHBzLiBJbiBmYWN0LCB0aGUgcmVtb3RlU3RvcmFn ZS5qcyBsaWJyYXJ5IGhhcw0KPnN1cHBvcnQgZm9yIGRvaW5nIGl0IGluIENvcmRvdmEgYXBwcyB2 aWEgdGhlIGluLWFwcC1icm93c2VyIHBsdWdpbi4NCg0KVGhhbmtzIGZvciBzaGFyaW5nLiBJdCBp cyBncmVhdCB0byBrbm93IHRoZXNlIHByb2dyYW1zLg0KVGhlIGV4dGVuc2lvbiB1c2FnZSBvZiBy ZW1vdGVTdG9yYWdlIGxpYnJhcnkgbWlnaHQgYmUgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZHJhZnQu DQoNCj4NCj5DaGVlcnMsDQo+U2ViYXN0aWFuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5TdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNCj5TdG9y YWdlc3luY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3RvcmFnZXN5bmM= From nobody Sun Dec 6 02:25:32 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02E81ACD8D for ; Sun, 6 Dec 2015 02:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.089 X-Spam-Level: **** X-Spam-Status: No, score=4.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkve_A-27JbK for ; Sun, 6 Dec 2015 02:25:28 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id AFC141ACD86 for ; Sun, 6 Dec 2015 02:25:26 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygAHJfC+DWRWCAAAAA--.0S2; Sun, 06 Dec 2015 18:28:14 +0800 (CST) Date: Sun, 6 Dec 2015 18:25:28 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120618252842112773@bjtu.edu.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart030116828743_=----" X-CM-TRANSID: M55wygAHJfC+DWRWCAAAAA--.0S2 X-Coremail-Antispam: 1UD129KBjvJXoW7uw4rJrW5Wry3Xr1fArykGrg_yoW8Aw1kpa yxAws8Ka1qq3yaqr1kWws29r48ZFn5Ga13tFs5Gw47Cwn0gas2gFyIvr4SgFW7JryxAasF vF4Yvas8ZFyDZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUHGb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2x7xS6r1j6r4UMc02F40E57IF 67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r4j6ryUMc02F40E42I26xC2a48xMc02F40Ex7 xS67I2xxkvbII20VAFz48EcVAYj21l5I8CrVC2j2CEjI02ccxYII8I62kEc4x0xVAYj21l Yx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbV WUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy2 6I8I3I1lc2xSY4AK67AK6r4DMxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_Jr Wlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxG rwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8Jw CI42IY6xAIw20EY4v20xvaj40_Zr0_Wr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvj xU2HqcUUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed (html) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 10:25:29 -0000 This is a multi-part message in MIME format. ------=_001_NextPart030116828743_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24uIEkgY2xhc3NpZmllZCB0aGVtIGEgYml0LiBQbGVh c2UgZW1haWwgbWUgaWYgYW55dGhpbmcgaXMgbWlzc2VkOg0KIA0KMS4gICAgICAgICBUaGUgZGVz aWduIHRhcmdldHMgb2YgV2ViREFWLCByc3luYyBhbmQgb3RoZXIgZXhpc3RpbmcgYXBwcm9hY2hl cz8NCjIuICAgICAgICAgVGhlIHBvdGVudGlhbCB1c2UgY2FzZXMgb2YgSVNTLCBzdWNoIGFzIGNs aWVudC9zZXJ2ZXIsIGdpdC1saWtlIHBhdHRlcm4sIHN2biwgZXRjLg0KMy4gICAgICAgICBUaGUg ZWZmaWNpZW5jeSBpbXByb3ZlbWVudHMgbWlnaHQgYmUgdGhlIHNlY29uZCBnb2FsIGZvciBzdGFu ZGFyZGl6aW5nIElTUyBwcm90b2NvbA0KNC4gICAgICAgICBDT1JTIGhlYWRlcnMgb24gc3RvcmFn ZSBzeW5jIEFQSXMNCjUuICAgICAgICAgV2hhdCBpcyBuZWVkZWQgZm9yIHRoZSBJU1M6IGEgc3lu YyBwcm90b2NvbCBvciBhIGdlbmVyYWxpemVkIEFQSQ0KNi4gICAgICAgICByZW1vdGVTdG9yYWdl IGRyYWZ0IGRpc2N1c3Npb24NCmEpICAgICAgICAgcmVsYXRpb25zaGlwIHZzIFdlYkRBVg0KYikg ICAgICAgICBNT1ZFIGFjdGlvbiAoc3luY2hyb25pemF0aW9uKSBzaG91bGQgYmUgYWRkZWQgb3Ig bm90DQpjKSAgICAgICAgIEJlc2lkZSB3ZWIgYnJvd3NlciwgZGVza3RvcCBhcHBzIChieSBoYWNr aW5nIHdheSkNCmQpICAgICAgICAgY29taWNzIG9mIG5ldyBzdGFuZGFyZA0KZSkgICAgICAgICBl dGFnIGlzIG1haW5seSBmb3IgaWRlbnRpZnlpbmcgd2hldGhlciBhIGRvY3VtZW50IGlzIGNoYW5n ZWQgb3Igbm90DQpmKSAgICAgICAgICB0aGUgZGlzdHJpYnV0ZWQgcGVlciBtb2RlbCAobm8gc2Vy dmVyKSBhbmQgQy9TIG1vZGUNCjcuICAgICAgICAgR2l0SHViIGluc3RlYWQgb2YgZW1haWwgbWVz c2FnZXMgKGhhcyBiZWVuIGNyZWF0ZWQpIHdpdGggZm9sbG93aW5nIFVSTDoNCmh0dHBzOi8vZ2l0 aHViLmNvbS9sYWJrb2RlL0ludGVybmV0LVN0b3JhZ2UtU3luYw0KYSkgICAgICAgICBXaGF0IGlz IHRoZSB0b3BpYz8gDQogICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIFdo ZXRoZXIgaXQgaXMgc3VpdGFibGUgdG8gYnVpbGQgb24gV2ViREFWDQogICAgICAgICAgICAgICAg ICAgICAgIGlpLiAgICAgICAgICAgICAgV2ViREFWIHZzIHJlbW90ZVN0b3JhZ2UNCiAgICAgICAg ICAgICAgICAgICAgICBpaWkuICAgICAgICAgICAgICBBZHZhbnRhZ2VzIHZzIGRpc2FkdmFudGFn ZXMgb2YgV2ViREFWDQo4LiAgICAgICAgIE1ldGFkYXRhIGFuZCBkYXRhIHNlcGFyYXRpb24gc2No ZW1lIGFuZCBwbGF0Zm9ybSBmb3Igc3luY2hyb25pemF0aW9uDQphKSAgICAgICAgIG93bkNsb3Vk IHdoZW4gY29uZmlndXJlZCB0byB1c2UgYW4gT2JqZWN0IFN0b3JhZ2UgYXMgdGhlIFByaW1hcnkg VXNlciBTdG9yYWdlLiAoTWV0YWRhdGEgaXMgaGFuZGxlZCBieSBhIE15U1FMIGRhdGFiYXNlKQ0K YikgICAgICAgICBDRVJOIEVPUyBTdG9yYWdlIFN5c3RlbS4gKE1ldGFkYXRhIGlzIGhhbmRsZWQg aW4gaGlnaCBwZXJmb3JtYW5jZSBpbi1tZW1vcnkgc3RydWN0dXJlcykuDQpjKSAgICAgICAgIERy b3BCb3guIChBcyBmYXIgYXMgSSBrbm93IGl0IHVzZXMgUzMgYmVoaW5kLiBGb3IgbWV0YWRhdGEg aXQgaXMgdW5rbm93biwgYnV0IHByb2JhYmx5IG5vdCBvbiBTMykuIA0KUGFwZXIgZm9yIGFuYWx5 emluZyBEcm9wQm94Og0KaHR0cDovL2FubmFzcGVyb3R0by5vcmcvcGFwZXJzLzIwMTIvaW1jMTQw LWRyYWdvLnBkZg0KZCkgICAgICAgICBDbGF3SU8gd2lsbCBoYXZlIGFuIGltcGxlbWVudGF0aW9u IG9mIHRoaXMgYXBwcm9hY2ggaW4gdGhlIG5leHQgcGhhc2UgdXNpbmcgU3dpZnQuDQogDQogDQpT b21lIHJlbGF0ZWQgb3JnYW5pemF0aW9ucywgZXZlbnRzLCBwcm9qZWN0cywgZXRjLjogDQpHRUFO VCBjb21tdW5pdHksIE9wZW5DbG91ZE1lc2gsIG93bkNsb3VkLCBDUzMsIHJlbW90ZVN0b3JhZ2Us IENsYXdJTywgY3Jvc3NjbG91ZCwgRHJvcGJveCwgQ0VSTiBFT1MgU3RvcmFnZSBTeXN0ZW0sdG8g YmUgYWRkZWShrQ== ------=_001_NextPart030116828743_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Here is the latest version. I classified them a bit. Please= email=20 me if anything is missed:

 

1.      =   =20 The = design=20 targets of WebDAV, rsync and other existing approaches?

2.      =   =20 The = potential=20 use cases of ISS, such as client/server, git-like pattern, svn,=20 etc.

3.      =   =20 The = efficiency=20 improvements might be the second goal for standardizing ISS=20 protocol

4.      =   =20 CORS= headers on=20 storage sync APIs

5.      =   =20 What= is needed=20 for the ISS: a sync protocol or a generalized API

6.      =   =20 remo= teStorage=20 draft discussion

a)      =   =20 rela= tionship vs=20 WebDAV

b)      =   =20 MOVE= action=20 (synchronization) should be added or not

c)      =   =20 Besi= de web=20 browser, desktop apps (by hacking way)

d)      =   =20 comi= cs of new=20 standard

e)      =   =20 etag= is mainly=20 for identifying whether a document is changed or not

f)      =    =20 the = distributed=20 peer model (no server) and C/S mode

7.      =   =20 GitH= ub instead=20 of email messages (has been created) with following URL:

<= FONT=20 size=3D3=20 face=3DCalibri>https://github.com/labkode/Internet-Storage-Sync

a)      =   =20 What= is the=20 topic?

      =             &n= bsp;     =20 i.      =        =20 Whet= her it is=20 suitable to build on WebDAV

      =             &n= bsp;   =20 ii.      =        =20 WebD= AV vs=20 remoteStorage

      =             &n= bsp;  =20 iii.      =        =20 Adva= ntages vs=20 disadvantages of WebDAV

8.      =   =20 Meta= data and=20 data separation scheme and platform for synchronization

a)      =   =20 ownCloud=20 when configured to use an Object Storage as the Primary User Storage. (Met= adata=20 is handled by a MySQL database)

b)      =   =20 CERN EOS=20 Storage System. (Metadata is handled in high performance in-memory=20 structures).

c)      =   =20 Drop= Box. (As far=20 as I know it uses S3 behind. For metadata it is unknown, but probably not = on=20 S3).

= Paper for=20 analyzing DropBox:

<= FONT=20 size=3D3=20 face=3DCalibri>http://annasperotto.org/papers/2012/imc140-drago.pdf=

d)      =   =20 Claw= IO will have=20 an implementation of this approach in the next phase using=20 Swift.

 

 

Some related organizations, events, projects, etc.:=20

GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorag= e,=20 ClawIO, crosscloud, Dropbox, CERN EOS Storage System,to be=20 added=A1=AD

------=_001_NextPart030116828743_=------ From nobody Sun Dec 6 09:23:34 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527021A6FF0 for ; Sun, 6 Dec 2015 09:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwQiBpEO6Iph for ; Sun, 6 Dec 2015 09:23:30 -0800 (PST) Received: from smtp.mrt.ac.lk (smtp.mrt.ac.lk [192.248.8.101]) by ietfa.amsl.com (Postfix) with ESMTP id ED4961A6FE9 for ; Sun, 6 Dec 2015 09:23:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.mrt.ac.lk (Postfix) with ESMTP id E84B8242395 for ; Sun, 6 Dec 2015 22:53:27 +0530 (IST) X-Virus-Scanned: amavisd-new at uom.lk Received: from smtp.mrt.ac.lk ([127.0.0.1]) by localhost (smtp.mrt.ac.lk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk_or-bXlESl for ; Sun, 6 Dec 2015 22:53:27 +0530 (IST) Received-SPF: none (cse.mrt.ac.lk: No applicable sender policy available) receiver=smtp.mrt.ac.lk; identity=mailfrom; envelope-from="gihan@cse.mrt.ac.lk"; helo=submit.uom.lk; client-ip=192.248.8.107 Received: from submit.uom.lk (inrelay.mrt.ac.lk [192.248.8.107]) by smtp.mrt.ac.lk (Postfix) with ESMTP id 7A82824236D for ; Sun, 6 Dec 2015 22:53:26 +0530 (IST) Received: from [192.168.1.8] (unknown [112.134.168.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gihan) by submit.uom.lk (Postfix) with ESMTPSA id 2943F5FD6F for ; Sun, 6 Dec 2015 22:53:26 +0530 (IST) To: storagesync@ietf.org References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <2015120618252842112773@bjtu.edu.cn> From: Gihan Dias Organization: University of Morauwa Message-ID: <5664697B.2070604@cse.mrt.ac.lk> Date: Sun, 6 Dec 2015 22:29:39 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2015120618252842112773@bjtu.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Storagesync] recent issues discussed (html) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 17:23:33 -0000 On 2015-12-06 ප.ව. 3:55, Fei Song wrote: > > Here is the latest version. I classified them a bit. Please email me > if anything is missed: > Fei, Thanks. Looks quite extensive. Gihan From nobody Sun Dec 6 09:36:54 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42601A86DF for ; Sun, 6 Dec 2015 09:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3icZb8RSrfz for ; Sun, 6 Dec 2015 09:36:52 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23541A86E2 for ; Sun, 6 Dec 2015 09:36:51 -0800 (PST) Received: (qmail 355 invoked from network); 6 Dec 2015 17:36:48 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 6 Dec 2015 17:36:48 -0000 Date: Sun, 6 Dec 2015 18:36:46 +0100 From: Markus Unterwaditzer To: Linhui Sun Message-ID: <20151206173646.GA6290@localhost.localdomain> References: <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 17:36:54 -0000 > IMO, etag is designed for client side cache. A typical usage: if the file > on the server has no actual change, the client will use the cache and the > server does not need to send the file content again. While for a storage > service, we also need some some similar mechanism at server side. In this > way, the client do not need to upload unchanged content to the server. There is no "true-and-only" usecase for etags, and no, you do not need anything more than etags for synchronization. Using a additional "metadata" file, the client can cheaply determine whether local content changed and whether server content changed, and that's all that is required for (in this case) file synchronization. Sync conflicts are a different story, and the solution to that heavily depends on the kind of data you're syncing. > > > -- > > Sent from my phone. Please excuse my brevity. > > > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Sun Dec 6 09:39:43 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F941A8714 for ; Sun, 6 Dec 2015 09:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHjiBVh8KizC for ; Sun, 6 Dec 2015 09:39:40 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181681A870C for ; Sun, 6 Dec 2015 09:39:39 -0800 (PST) Received: (qmail 24521 invoked from network); 6 Dec 2015 17:39:38 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 6 Dec 2015 17:39:38 -0000 Date: Sun, 6 Dec 2015 18:39:36 +0100 From: Markus Unterwaditzer To: Fei Song Message-ID: <20151206173936.GB6290@localhost.localdomain> References: <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <2015120612140798437464@bjtu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2015120612140798437464@bjtu.edu.cn> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 17:39:42 -0000 On Sun, Dec 06, 2015 at 12:14:08PM +0800, Fei Song wrote: > Hi, > > > -------------- > Fei Song > >On Thu, Dec 03, 2015 at 02:38:05PM +0000, Ted Lemon wrote: > >> Thursday, Dec 3, 2015 6:00 AM Linhui Sun wrote: > >> > However I'd prefer HTTP rather than WebDAV. Since I still think WebDAV is > >> > not suitable for today's sync service. The frequency of operations is far > >> > higher than what WebDAV expects. For example, frequently sending propfind > >> > to detect changes is not a good way in my view. > >> > >> WebDAV is HTTP. However, your point about propfind is correct--that doesn't > >> scale. What you want is a separate layer for dealing with synchronization > >> of metadata. You could use HTTP transport to do this, but not propfind. > > > >We do have that separate layer in the form of > >https://www.ietf.org/rfc/rfc6578.txt and so far only a handful of FOSS servers > >have implemented it. The fully-interopable way to synchronize servers still > >includes a fallback to a full PROPFIND. > > > >ETags on folder listings are arguably simpler to implement than a partial > >transaction history. remoteStorage requires those, and consequently all servers > >must implement it. > > ah, do you think it will trigger much extra burdens for the servers? What do you mean by "it"? ETags are simpler to implement than the above RFC, and ETags are also required in WebDAV. - WebDAV: Etags AND a sync protocol - remoteStorage: just etags The latter is simpler, although you'll have to fetch the full folder listing for each sync when something in that folder changed. > > > > >> > >> > >> -- > >> Sent from Whiteout Mail - https://whiteout.io > >> > >> My PGP key: https://keys.whiteout.io/mellon@fugue.com > > > > > > > >> _______________________________________________ > >> Storagesync mailing list > >> Storagesync@ietf.org > >> https://www.ietf.org/mailman/listinfo/storagesync > > > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Sun Dec 6 10:27:00 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C3B1ACDBB for ; Sun, 6 Dec 2015 10:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_E1RVQ9FhU7 for ; Sun, 6 Dec 2015 10:26:58 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 029331ACD49 for ; Sun, 6 Dec 2015 10:26:57 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494264144760.414380902890116" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <20151206173936.GB6290@localhost.localdomain> References: <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <2015120612140798437464@bjtu.edu.cn> <20151206173936.GB6290@localhost.localdomain> Date: Sun, 06 Dec 2015 18:26:54 +0000 Message-Id: <1449426414825-9cdbb6fe-86b1149f-71354c71@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 18:27:00 -0000 ------sinikael-?=_1-14494264144760.414380902890116 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Dec 6, 2015 12:39 PM Markus Unterwaditzer wrote: > What do you mean by =22it=22=3F ETags are simpler to implement than the = above RFC, > and ETags are also required in WebDAV. Etags are not really much simpler than a metadata versioning sync protocol,= and they are a lot less efficient. Having to fetch the whole directory = for every directory that contains a change is expensive, both for the = server and the client, unless changes are infrequent. And because the = server is the sole source of truth, it's a lot more fragile. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494264144760.414380902890116 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZH3uCRAMw8Nu0HeKywAAMv8H/RT1ztwv/QHomZi6USJ4 i5y/bfaOVsyn6A9P2tee3HovgKtsBdMREB8KVca3DLtXvKKswoQShe3WPk7z +C6vhw9rkSHhaGtMemGqJkEf6QENE3SFJUorc/Nbv6DzOaKMQwZmk5koC2Zs vqU8gxK/w8y2J5lnTaRrvQ0TXGS0FfeCY58OnY7aB37DN1oYeolRRPxDRdDq KpoMFduuJarpjCPpChUliUMX9ZqtlD8XAmugpPit7H0mSG2knNKE8cicB0VN mMrBXI8Fiw07ytp+CKnWTAJIvdzd929T42YoSzIES3Hbzw6b3A3wzMWicL2E x29hbLMaUjwTcj98Etpfe0M= =djt8 -----END PGP SIGNATURE----- ------sinikael-?=_1-14494264144760.414380902890116-- From nobody Sun Dec 6 13:55:07 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF3C1B33F6 for ; Sun, 6 Dec 2015 13:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJls4Q2da5qy for ; Sun, 6 Dec 2015 13:55:04 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089EA1B33F5 for ; Sun, 6 Dec 2015 13:55:03 -0800 (PST) Received: (qmail 31489 invoked from network); 6 Dec 2015 21:55:00 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 6 Dec 2015 21:55:00 -0000 Date: Sun, 6 Dec 2015 22:54:58 +0100 From: Markus Unterwaditzer To: Ted Lemon Message-ID: <20151206215458.GA6619@localhost.localdomain> References: <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <2015120612140798437464@bjtu.edu.cn> <20151206173936.GB6290@localhost.localdomain> <1449426414825-9cdbb6fe-86b1149f-71354c71@fugue.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <1449426414825-9cdbb6fe-86b1149f-71354c71@fugue.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2015 21:55:06 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Etags are *much* simpler to implement on the server side than the WebDAV sy= nc protocol because they do not require the server to keep sync tokens and metadata history. Note that the server has to keep metadata of *deleted* fi= les to correctly implement WebDAV's sync protocol. Etags are less efficient in terms of network usage of course, but that's the tradeoff to be made. I don't know what you mean with the last sentence. On Sun, Dec 06, 2015 at 06:26:54PM +0000, Ted Lemon wrote: > Sunday, Dec 6, 2015 12:39 PM Markus Unterwaditzer wrote: > > What do you mean by "it"? ETags are simpler to implement than the above= RFC, > > and ETags are also required in WebDAV. >=20 > Etags are not really much simpler than a metadata versioning sync protoco= l, and they are a lot less efficient. Having to fetch the whole directory= for every directory that contains a change is expensive, both for the serv= er and the client, unless changes are infrequent. And because the server = is the sole source of truth, it's a lot more fragile. >=20 >=20 > -- > Sent from Whiteout Mail - https://whiteout.io >=20 > My PGP key: https://keys.whiteout.io/mellon@fugue.com > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWZK6tAAoJEDHp7/n6rHiMJmcIAMhKqroJ/Uc99ONPiKQYwihQ +Pa7PWBum35UhgcwgD0Q+P0TJrn9Uo0o1a+1NKb794i59UxgX1BAICY01Tca8KfC 7Za+NbrpMyMwDLQhZYHz66cmn/mcJJ1J0Q5Jp8k728EJtyqbfAwbno5T4gIQsX2i FhR7EAE3DFj43q9+SzRPsF36UUj8fjcXm9PnGRNLTdC4r7fMkgDsfCIqHNsCPSTe 1xGRNaWC8Bgm4Ta6+HWovGxUrE0/NgE9tgRlLkrdR7f8JBAXlBRdQyTlfKdPl4oF r46yHUYY6I5IGBUDoXpxh58ULbMzNc7LuXv9dm/NNmjGA2sUfoTxHftNybIDyKY= =zrfV -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From nobody Sun Dec 6 16:17:36 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD19F1A8A7B for ; Sun, 6 Dec 2015 16:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvHnkGltqYOT for ; Sun, 6 Dec 2015 16:17:33 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BF11A8A78 for ; Sun, 6 Dec 2015 16:17:32 -0800 (PST) Received: by qgea14 with SMTP id a14so131945758qge.0 for ; Sun, 06 Dec 2015 16:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=XAHq+p7oJj4XQlnthsjC4DrGdGt9VZTUW8vNPvpm4TE=; b=yqZPJNyTpzjviED+fCXruPxHOR5YcAnuzG92mXyicXrIj3ZIHRtUB9DDKs7Q9vuUNy 9VtiREAthGqz5enFW8vnsweCbSjEAPFP7wMHKSikzcmqqozoVOdgg3Q/2goBlgIOI15E HUQdPzUKT0HDYDkwcTWzBmdxcLd9A7hBrgYCOeTUTOI43iBqTJlcoRP+HwgmCcgyXglQ q/HazebzhuLirmntKE2q7KiPE4EEtbCGGH6waUu3lvy9TqoZI4hY23310reRegIhLDJ8 df1OkJTzGDmjcXGppe+pDp5d0OO3aaBmCdt7rroE8cDm7qUjjKVLq0N0zUowraIDZHcj yHeA== X-Received: by 10.140.240.196 with SMTP id l187mr35529621qhc.69.1449447452171; Sun, 06 Dec 2015 16:17:32 -0800 (PST) Received: from [127.0.0.1] (ec2-54-210-254-233.compute-1.amazonaws.com. [54.210.254.233]) by smtp.gmail.com with ESMTPSA id a15sm10511853qge.18.2015.12.06.16.17.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 16:17:30 -0800 (PST) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14494474503410.7830279266927391" From: Linhui Sun To: Markus Unterwaditzer In-Reply-To: <20151206173646.GA6290@localhost.localdomain> References: <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> Date: Mon, 07 Dec 2015 08:17:26 +0800 X-Cm-Message-Id: 1449447450168631ae3914fb36c97c4e8595adc2eb26c08f5664d01a293671311414861 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0NDk0NDc0NDYwMDAiLCJjIiwiMTUxOTM5MTI5MTk2ODkzMDAyMCIsInYiLDFd X-Mailer: CloudMagic Message-Id: <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> MIME-Version: 1.0 Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 00:17:34 -0000 ------sinikael-?=_1-14494474503410.7830279266927391 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, Markus Unterwaditzer = wrote: > IMO, etag is designed for client side = cache. A typical usage: if the file > on the server has no actual change, = the client will use the cache and the > server does not need to send the = file content again. While for a storage > service, we also need some some = similar mechanism at server side. In this > way, the client do not need to = upload unchanged content to the server. There is no "true-and-only" = usecase for etags, and no, you do not need anything more than etags for synchronization. Using a additional "metadata" file, = the client can cheaply determine whether local content changed and whether = server content changed, and that's all that is required for (in this case) = file synchronization. Sync conflicts are a different story, and the = solution to that heavily depends on the kind of data you're syncing. I'm a = little bit confused here: if I have a metadata file, why do I still need the etag? The metadata file should contain something equivalent to the etag= . > > > -- > > Sent from my phone. Please excuse my brevity. > > > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > > > _______________________________________________ > Storagesync mailing = list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storage= sync ------sinikael-?=_1-14494474503410.7830279266927391 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, Markus= Unterwaditzer <markus@unterwaditzer.net> wrote:
> IMO, etag is designed = for client side cache. A typical usage: if the file
> on the server = has no actual change, the client will use the cache and the
> server = does not need to send the file content again. While for a storage
> = service, we also need some some similar mechanism at server side. In = this
> way, the client do not need to upload unchanged content to the= server.

There is no "true-and-only" usecase for etags, and no, you = do not need anything
more than etags for synchronization. Using a = additional "metadata" file, the
client can cheaply determine whether = local content changed and whether server
content changed, and that's all= that is required for (in this case) file
synchronization. 
Sync conflicts are a = different story, and the solution to that
heavily depends on the kind of= data you're syncing.
I'm a little= bit confused here: if I have a metadata file, why do I still need the etag= ? The metadata file should contain something equivalent to the etag.=


>=
> > --
> > Sent from my phone. Please excuse my brevity= .
> >
> > _______________________________________________=
> > Storagesync mailing list
> > Storagesync@ietf.= org
> > https://www.ietf.org/mailman/listinfo/storagesync
> = >

> _______________________________________________
> = Storagesync mailing list
> Storagesync@ietf.org
> https://www.= ietf.org/mailman/listinfo/storagesync

=
=20 ------sinikael-?=_1-14494474503410.7830279266927391-- From nobody Sun Dec 6 16:20:32 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248CB1A8A9A for ; Sun, 6 Dec 2015 16:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzqRxEoZTVNw for ; Sun, 6 Dec 2015 16:20:29 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3C31A8A9D for ; Sun, 6 Dec 2015 16:20:28 -0800 (PST) Received: (qmail 31423 invoked from network); 7 Dec 2015 00:20:26 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 7 Dec 2015 00:20:26 -0000 Date: Mon, 7 Dec 2015 01:20:20 +0100 From: Markus Unterwaditzer To: Linhui Sun Message-ID: <20151207002020.GA5002@localhost.localdomain> References: <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 00:20:31 -0000 You need to store the etags from the last sync to see which ones have changed. I'm doing this in vdirsyncer (https://github.com/untitaker/vdirsyncer), a remoteStorage and CalDAV/CardDAV sync client and probably should do a high-level blogpost about it. On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote: > On 周一, 12月 7, 2015 at 01:36, Markus Unterwaditzer > wrote: > > IMO, etag is designed for client side cache. A typical usage: if the file > > on the server has no actual change, the client will use the cache and the > > server does not need to send the file content again. While for a storage > > service, we also need some some similar mechanism at server side. In this > > way, the client do not need to upload unchanged content to the server. > > There is no "true-and-only" usecase for etags, and no, you do not need anything > more than etags for synchronization. Using a additional "metadata" file, the > client can cheaply determine whether local content changed and whether server > content changed, and that's all that is required for (in this case) file > synchronization. Sync conflicts are a different story, and the solution to that > heavily depends on the kind of data you're syncing. I'm a little bit confused here: if I have a metadata file, why do I still need > the etag? The metadata file should contain something equivalent to the etag. > > > > > > -- > > > Sent from my phone. Please excuse my brevity. > > > > > > _______________________________________________ > > > Storagesync mailing list > > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Sun Dec 6 16:32:48 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD2B1A8AF3 for ; Sun, 6 Dec 2015 16:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz9XCP91ZHl5 for ; Sun, 6 Dec 2015 16:32:44 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9021A8AF2 for ; Sun, 6 Dec 2015 16:32:44 -0800 (PST) Received: by qkcb135 with SMTP id b135so17212226qkc.3 for ; Sun, 06 Dec 2015 16:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=aTuWOjkPlzichk5is9qCjK6bAlHUutiz6WV+8rSD5F8=; b=u4bMJjddXdDseQRJwYSyUsQgaZtxl/gx3vOqIdLfEJujmykuQ8RGNPLt5B+mfwSLbN BKFbFfbGG5rD1dg7MhiYHAht32fZEBU/GnvtSyrNJcBhQ7sj7BClo/rJxTB2h/lw/RKU Gz9SzRd380VDNu8w7lonm2KAX+Da90ORZnw0oOJiVMwcO+AQ6TionOpcdAGX9327yJqs YspTSagfctWSE6e9H9dVDIToSq/kxkKuypGA2qi6ixNjfYAi4oNUeAUbnRSiAO+nAl6Z rA+y0hkuC8iMXMVgd3ZHdLqLTg4KXqC3ga+c47lJppeShKMBxTUQu65Zoly6sQwSZspq n7bQ== X-Received: by 10.55.197.195 with SMTP id k64mr25202995qkl.25.1449448363671; Sun, 06 Dec 2015 16:32:43 -0800 (PST) Received: from [127.0.0.1] (ec2-54-210-254-173.compute-1.amazonaws.com. [54.210.254.173]) by smtp.gmail.com with ESMTPSA id x44sm10562833qgx.44.2015.12.06.16.32.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 16:32:42 -0800 (PST) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14494483621370.48003450175747275" From: Linhui Sun To: Markus Unterwaditzer In-Reply-To: <20151207002020.GA5002@localhost.localdomain> References: <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> Date: Mon, 07 Dec 2015 08:31:55 +0800 X-Cm-Message-Id: 1449448362034300ae3914fb36c97c4e8595adc2eb26c08f5664d3aa086b12085433226 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0NDk0NDgzMTUwMDAiLCJjIiwiMTUxOTM5MTI5MTk2ODkzMDAyMCIsInYiLDFd X-Mailer: CloudMagic Message-Id: <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> MIME-Version: 1.0 Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 00:32:46 -0000 ------sinikael-?=_1-14494483621370.48003450175747275 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 08:20, Markus Unterwaditzer = wrote: You need to store the etags from the last= sync to see which ones have changed. The server only need to know the = latest version in my view. They don't need to be able to identify last sync= or change, just to check whether metadata file is latest is enough. I'm doing this in vdirsyncer (https://github.com/untitaker/vdirsyncer), a remoteStorage and CalDAV/CardDAV sync client and probably should do a high-level blogpost about it. On Mon, Dec 07, 2015 at 08:17:26AM +0800, = Linhui Sun wrote: > On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, = Markus Unterwaditzer > wrote: > > IMO, etag is designed for client side cache. A typical usage: if the = file > > on the server has no actual change, the client will use the cache = and the > > server does not need to send the file content again. While for = a storage > > service, we also need some some similar mechanism at server = side. In this > > way, the client do not need to upload unchanged content = to the server. > > There is no "true-and-only" usecase for etags, and no, = you do not need anything > more than etags for synchronization. Using a = additional "metadata" file, the > client can cheaply determine whether = local content changed and whether server > content changed, and that's all = that is required for (in this case) file > synchronization. Sync conflicts = are a different story, and the solution to that > heavily depends on the = kind of data you're syncing. I'm a little bit confused here: if I have a metadata file, why do I still need > the etag? The metadata file should contain something equivalent to the = etag. > > > > > > -- > > > Sent from my phone. Please excuse my brevity. > > > > > > _______________________________________________ > > > Storagesync mailing list > > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > _______________________________________________ > Storagesync mailing = list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storage= sync ------sinikael-?=_1-14494483621370.48003450175747275 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 08:20, Markus= Unterwaditzer <markus@unterwaditzer.net> wrote:
You need to store the etags= from the last sync to see which ones have changed.
The server only need to know the latest version in = my view. They don't need to be able to identify last sync or change, just = to check whether metadata file is latest is enough.

I'm doing this in = vdirsyncer (https://github.com/untitaker/vdirsyncer), a
remoteStorage = and CalDAV/CardDAV sync client and probably should do a
high-level = blogpost about it.

On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui = Sun wrote:
> On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, = Markus Unterwaditzer <markus@unterwaditzer.net>
> = wrote:
> > IMO, etag is designed for client side cache. A typical = usage: if the file
> > on the server has no actual change, the = client will use the cache and the
> > server does not need to send= the file content again. While for a storage
> > service, we also = need some some similar mechanism at server side. In this
> > way, = the client do not need to upload unchanged content to the server.
> =
> There is no "true-and-only" usecase for etags, and no, you do not = need anything
> more than etags for synchronization. Using a = additional "metadata" file, the
> client can cheaply determine = whether local content changed and whether server
> content changed, = and that's all that is required for (in this case) file
> = synchronization. Sync conflicts are a different story, and the solution to = that
> heavily depends on the kind of data you're syncing. I'm a = little bit confused here: if I have a metadata file, why do I still = need
> the etag? The metadata file should contain something = equivalent to the etag.
>
> >
> > > --
> = > > Sent from my phone. Please excuse my brevity.
> > = >
> > > _______________________________________________
&= gt; > > Storagesync mailing list
> > > Storagesync@ietf.= org
> > > https://www.ietf.org/mailman/listinfo/storagesync
= > > >
>
> > ______________________________________= _________
> > Storagesync mailing list
> > = Storagesync@ietf.org
> > https://www.ietf.org/mailman/listinfo/sto= ragesync

> _______________________________________________
>= ; Storagesync mailing list
> Storagesync@ietf.org
> https://www= .ietf.org/mailman/listinfo/storagesync

=
=20 ------sinikael-?=_1-14494483621370.48003450175747275-- From nobody Sun Dec 6 16:38:22 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552801A8BBF for ; Sun, 6 Dec 2015 16:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSPVFA5Vb5aH for ; Sun, 6 Dec 2015 16:38:20 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CEF1A8BBE for ; Sun, 6 Dec 2015 16:38:19 -0800 (PST) Received: (qmail 11029 invoked from network); 7 Dec 2015 00:38:17 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 7 Dec 2015 00:38:17 -0000 Date: Mon, 7 Dec 2015 01:38:10 +0100 From: Markus Unterwaditzer To: Linhui Sun Message-ID: <20151207003810.GA24130@localhost.localdomain> References: <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 00:38:21 -0000 On Mon, Dec 07, 2015 at 08:31:55AM +0800, Linhui Sun wrote: > The server only need to know the latest version in my view. They don't need to > be able to identify last sync or change, just to check whether metadata file is > latest is enough. The metadata file contains all etags *for all files* from the previous sync. It is stored on the clientside and is never sent to the server. > > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote: > > On 周一, 12月 7, 2015 at 01:36, Markus Unterwaditzer > > wrote: > > > IMO, etag is designed for client side cache. A typical usage: if the file > > > on the server has no actual change, the client will use the cache and the > > > server does not need to send the file content again. While for a storage > > > service, we also need some some similar mechanism at server side. In this > > > way, the client do not need to upload unchanged content to the server. > > > > There is no "true-and-only" usecase for etags, and no, you do not need > anything > > more than etags for synchronization. Using a additional "metadata" file, the > > client can cheaply determine whether local content changed and whether server > > content changed, and that's all that is required for (in this case) file > > synchronization. Sync conflicts are a different story, and the solution to > that > > heavily depends on the kind of data you're syncing. I'm a little bit confused > here: if I have a metadata file, why do I still need > > the etag? The metadata file should contain something equivalent to the etag. > > > > > > > > > -- > > > > Sent from my phone. Please excuse my brevity. > > > > > > > > _______________________________________________ > > > > Storagesync mailing list > > > > Storagesync@ietf.org > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > > > _______________________________________________ > > > Storagesync mailing list > > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync From nobody Sun Dec 6 16:50:10 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC61A902F for ; Sun, 6 Dec 2015 16:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9arHuQzHKXmw for ; Sun, 6 Dec 2015 16:50:06 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772AD1A902B for ; Sun, 6 Dec 2015 16:50:06 -0800 (PST) Received: by qgec40 with SMTP id c40so132444265qge.2 for ; Sun, 06 Dec 2015 16:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=/JWyaYTix63qNwTWNflvwrsx9Tupdk2i881NCB8vr8A=; b=J3Kfrz3I4cd9Jhbsxquz+pvdlenWsKl2v6Pk/lIOU1rrGzrVB1P8OQJXO6g1ZLsqq9 wPMP63YQZXXJJJmiwN9qStDJJN1+aHENTu+jt2D1fYKojY+HJasobbHhDVbMeE1BwWHO p3M4NXz180PvE5jto+0L5dZqLktSG2wTDFGhLtx05ZwwBgfsHgvsuSEomXgNiTn7542p Fto3WtPx+8kWQzKzw4y8mzrlGZzU8xMGRYQuX7eTxmK2HR54B5MRP3GVxWPSaKAPYLTU dFzfIHiDVSBkGZOA+5ARW78KnskcwrIDcZmxmNZfzWR3MRuFtkGSDSmYZLmf5dHrUD9H PqKg== X-Received: by 10.140.96.45 with SMTP id j42mr33224035qge.92.1449449405710; Sun, 06 Dec 2015 16:50:05 -0800 (PST) Received: from [127.0.0.1] (ec2-54-210-254-233.compute-1.amazonaws.com. [54.210.254.233]) by smtp.gmail.com with ESMTPSA id 89sm10555185qgz.7.2015.12.06.16.50.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 16:50:04 -0800 (PST) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14494494043100.158579922048375" From: Linhui Sun To: Markus Unterwaditzer In-Reply-To: <20151207003810.GA24130@localhost.localdomain> References: <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> Date: Mon, 07 Dec 2015 08:50:00 +0800 X-Cm-Message-Id: 1449449404221470ae3914fb36c97c4e8595adc2eb26c08f5664d7bc361cf422912907 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0NDk0NDk0MDAwMDAiLCJjIiwiMTUxOTM5MTI5MTk2ODkzMDAyMCIsInYiLDFd X-Mailer: CloudMagic Message-Id: <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> MIME-Version: 1.0 Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 00:50:08 -0000 ------sinikael-?=_1-14494494043100.158579922048375 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 08:38, Markus Unterwaditzer = wrote: On Mon, Dec 07, 2015 at 08:31:55AM +0800,= Linhui Sun wrote: > The server only need to know the latest version in my = view. They don't need to > be able to identify last sync or change, just to= check whether metadata file is > latest is enough. The metadata file contains all etags *for all files* from the previous sync= . It is stored on the clientside and is never sent to the server. So the = local metadata file is for client to decide whether to send a content. But what if the file has been changed during two sync processes by another participant who also shares the file. > > On Mon, Dec 07, 2015 at = 08:17:26AM +0800, Linhui Sun wrote: > > On =E5=91=A8=E4=B8=80, 12=E6=9C=88 = 7, 2015 at 01:36, Markus Unterwaditzer > > wrote: > > > IMO, etag is designed for client side cache. A typical = usage: if the file > > > on the server has no actual change, the client = will use the cache and the > > > server does not need to send the file = content again. While for a storage > > > service, we also need some some = similar mechanism at server side. In this > > > way, the client do not need= to upload unchanged content to the server. > > > > There is no = "true-and-only" usecase for etags, and no, you do not need > anything > > more than etags for synchronization. Using a additional "metadata" file= , the > > client can cheaply determine whether local content changed and = whether server > > content changed, and that's all that is required for (in= this case) file > > synchronization. Sync conflicts are a different story,= and the solution to > that > > heavily depends on the kind of data you're = syncing. I'm a little bit confused > here: if I have a metadata file, why = do I still need > > the etag? The metadata file should contain something = equivalent to the etag. > > > > > > > > > -- > > > > Sent from my phone. = Please excuse my brevity. > > > > > > > > _________________________________= ______________ > > > > Storagesync mailing list > > > > Storagesync@ietf.= org > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > > > _______________________________________________ > > > Storagesync mailing list > > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync > > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync ------sinikael-?=_1-14494494043100.158579922048375 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 08:38, Markus= Unterwaditzer <markus@unterwaditzer.net> wrote:
On Mon, Dec 07, 2015 at = 08:31:55AM +0800, Linhui Sun wrote:
> The server only need to know = the latest version in my view. They don't need to
> be able to = identify last sync or change, just to check whether metadata file = is
> latest is enough.

The metadata file contains all etags = *for all files* from the previous sync. It
is stored on the clientside = and is never sent to the server.
S= o the local metadata file is for client to decide whether to send a content= . But what if the file has been changed during two sync processes by = another participant who also shares the file.


>
> On Mon, Dec 07, = 2015 at 08:17:26AM +0800, Linhui Sun wrote:
> > On = =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, Markus Unterwaditzer = <markus@unterwaditzer.net>
> > wrote:
> > > IMO,= etag is designed for client side cache. A typical usage: if the = file
> > > on the server has no actual change, the client will = use the cache and the
> > > server does not need to send the = file content again. While for a storage
> > > service, we also = need some some similar mechanism at server side. In this
> > > = way, the client do not need to upload unchanged content to the server.=
> >
> > There is no "true-and-only" usecase for etags, = and no, you do not need
> anything
> > more than etags for = synchronization. Using a additional "metadata" file, the
> > = client can cheaply determine whether local content changed and whether = server
> > content changed, and that's all that is required for = (in this case) file
> > synchronization. Sync conflicts are a = different story, and the solution to
> that
> > heavily = depends on the kind of data you're syncing. I'm a little bit = confused
> here: if I have a metadata file, why do I still = need
> > the etag? The metadata file should contain something = equivalent to the etag.
> >
> > >
> > > = > --
> > > > Sent from my phone. Please excuse my brevity= .
> > > >
> > > > ___________________________= ____________________
> > > > Storagesync mailing = list
> > > > Storagesync@ietf.org
> > > > = https://www.ietf.org/mailman/listinfo/storagesync
> > > = >
> >
> > > _______________________________________= ________
> > > Storagesync mailing list
> > > = Storagesync@ietf.org
> > > https://www.ietf.= org/mailman/listinfo/storagesync
>
> > = _______________________________________________
> > Storagesync = mailing list
> > Storagesync@ietf.org
> > https://www.= ietf.org/mailman/listinfo/storagesync
=
=20 ------sinikael-?=_1-14494494043100.158579922048375-- From nobody Sun Dec 6 16:54:39 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F42B1A904D for ; Sun, 6 Dec 2015 16:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da_CCzMR9roC for ; Sun, 6 Dec 2015 16:54:36 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17281A904C for ; Sun, 6 Dec 2015 16:54:35 -0800 (PST) Received: (qmail 28040 invoked from network); 7 Dec 2015 00:54:33 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 7 Dec 2015 00:54:33 -0000 Date: Mon, 7 Dec 2015 01:54:26 +0100 From: Markus Unterwaditzer To: Linhui Sun Message-ID: <20151207005426.GA29483@localhost.localdomain> References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 00:54:37 -0000 On Mon, Dec 07, 2015 at 08:50:00AM +0800, Linhui Sun wrote: > But what if the file has been changed during two sync processes by another > participant who also shares the file. Those are sync conflicts, how to deal with then depends on the kind of data you deal with. > > > > > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote: > > > On 周一, 12月 7, 2015 at 01:36, Markus Unterwaditzer > > > wrote: > > > > IMO, etag is designed for client side cache. A typical usage: if the file > > > > on the server has no actual change, the client will use the cache and the > > > > server does not need to send the file content again. While for a storage > > > > service, we also need some some similar mechanism at server side. In this > > > > way, the client do not need to upload unchanged content to the server. > > > > > > There is no "true-and-only" usecase for etags, and no, you do not need > > anything > > > more than etags for synchronization. Using a additional "metadata" file, the > > > client can cheaply determine whether local content changed and whether > server > > > content changed, and that's all that is required for (in this case) file > > > synchronization. Sync conflicts are a different story, and the solution to > > that > > > heavily depends on the kind of data you're syncing. I'm a little bit > confused > > here: if I have a metadata file, why do I still need > > > the etag? The metadata file should contain something equivalent to the etag. > > > > > > > > > > > > -- > > > > > Sent from my phone. Please excuse my brevity. > > > > > > > > > > _______________________________________________ > > > > > Storagesync mailing list > > > > > Storagesync@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > > > > > > _______________________________________________ > > > > Storagesync mailing list > > > > Storagesync@ietf.org > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > _______________________________________________ > > > Storagesync mailing list > > > Storagesync@ietf.org > > > https://www.ietf.org/mailman/listinfo/storagesync From nobody Sun Dec 6 17:09:35 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F1B1A909C for ; Sun, 6 Dec 2015 17:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUJi4H09-fMZ for ; Sun, 6 Dec 2015 17:09:32 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06CD1A9098 for ; Sun, 6 Dec 2015 17:09:31 -0800 (PST) Received: by wmww144 with SMTP id w144so130844887wmw.0 for ; Sun, 06 Dec 2015 17:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xZoY+sF+IIjKPSPU1B1OhrKPNZr5KFDW/8mgDyPkF/8=; b=pkid1IE4NwUp1fQRuw/kn87z4EmDaF3cgOuLYShBtadLCO55ZrrPTAwJtPtVQOFzug u3QxmY3OBUCh3naBpQ/cpo2eXjbcthPLle8MjSh4CC80twLrS1t3/8rNNpjcmbN5ynIy 8HozG1NApVL66UkXfTbX1tP2ZcyJSyAviaZJNDYT93D55sAcIc3ZyqVPjwRYrOvvh2mr 2VPP0DUb7jvBWQnrkeJqFmjh+B0DF+tOM/cBEXXZ78TWzfyDfvFpOHp/UPAvKxRUFgpQ AWDhu1wRkTZZeAv9a7zvJ8bF1lTYhqQf9xzilbThCLNpqmtDeWAKpByYZkq5uHfpm4Em 93gQ== X-Received: by 10.194.84.4 with SMTP id u4mr35392631wjy.149.1449450570481; Sun, 06 Dec 2015 17:09:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Sun, 6 Dec 2015 17:09:08 -0800 (PST) In-Reply-To: <20151207005426.GA29483@localhost.localdomain> References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> From: Linhui Sun Date: Mon, 7 Dec 2015 09:09:08 +0800 Message-ID: To: Markus Unterwaditzer Content-Type: multipart/alternative; boundary=047d7bb04d365f844a052644827d Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 01:09:34 -0000 --047d7bb04d365f844a052644827d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-12-07 8:54 GMT+08:00 Markus Unterwaditzer : > On Mon, Dec 07, 2015 at 08:50:00AM +0800, Linhui Sun wrote: > > But what if the file has been changed during two sync processes by > another > > participant who also shares the file. > > Those are sync conflicts, how to deal with then depends on the kind of > data you > deal with. > That works, but do you think this could make the things complicated? It sounds like different situations have different mechanisms. Why not just make the metadata exchanged, any disadvantage for doing that? > > > > > > > > > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote: > > > > On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, Markus Unterwa= ditzer < > markus@unterwaditzer.net> > > > > wrote: > > > > > IMO, etag is designed for client side cache. A typical usage: if > the file > > > > > on the server has no actual change, the client will use the cache > and the > > > > > server does not need to send the file content again. While for a > storage > > > > > service, we also need some some similar mechanism at server side. > In this > > > > > way, the client do not need to upload unchanged content to the > server. > > > > > > > > There is no "true-and-only" usecase for etags, and no, you do not > need > > > anything > > > > more than etags for synchronization. Using a additional "metadata" > file, the > > > > client can cheaply determine whether local content changed and > whether > > server > > > > content changed, and that's all that is required for (in this case) > file > > > > synchronization. Sync conflicts are a different story, and the > solution to > > > that > > > > heavily depends on the kind of data you're syncing. I'm a little bi= t > > confused > > > here: if I have a metadata file, why do I still need > > > > the etag? The metadata file should contain something equivalent to > the etag. > > > > > > > > > > > > > > > -- > > > > > > Sent from my phone. Please excuse my brevity. > > > > > > > > > > > > _______________________________________________ > > > > > > Storagesync mailing list > > > > > > Storagesync@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > > > > > > > > > _______________________________________________ > > > > > Storagesync mailing list > > > > > Storagesync@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > _______________________________________________ > > > > Storagesync mailing list > > > > Storagesync@ietf.org > > > > https://www.ietf.org/mailman/listinfo/storagesync > --047d7bb04d365f844a052644827d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-07 8:54 GMT+08:00 Markus Unterwaditzer <markus@unterwad= itzer.net>:
On Mon, Dec 07, 2015 at 08:50:00AM +0800, Linhui Sun wrote:
> But what if the file has been changed during two sync processes by ano= ther
> participant who also shares the file.

Those are sync conflicts, how to deal with then depends on the kind = of data you
deal with.
That works, but do you think this could mak= e the things complicated? It sounds like different situations have differen= t mechanisms. Why not just make the metadata exchanged, any disadvantage fo= r doing that?

>
> >
> > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote:
> > > On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, Markus = Unterwaditzer <markus@unterw= aditzer.net>
> > > wrote:
> > > > IMO, etag is designed for client side cache. A typical = usage: if the file
> > > > on the server has no actual change, the client will use= the cache and the
> > > > server does not need to send the file content again. Wh= ile for a storage
> > > > service, we also need some some similar mechanism at se= rver side. In this
> > > > way, the client do not need to upload unchanged content= to the server.
> > >
> > > There is no "true-and-only" usecase for etags, and= no, you do not need
> > anything
> > > more than etags for synchronization. Using a additional &quo= t;metadata" file, the
> > > client can cheaply determine whether local content changed a= nd whether
> server
> > > content changed, and that's all that is required for (in= this case) file
> > > synchronization. Sync conflicts are a different story, and t= he solution to
> > that
> > > heavily depends on the kind of data you're syncing. I= 9;m a little bit
> confused
> > here: if I have a metadata file, why do I still need
> > > the etag? The metadata file should contain something equival= ent to the etag.
> > >
> > > >
> > > > > --
> > > > > Sent from my phone. Please excuse my brevity.
> > > > >
> > > > > _______________________________________________ > > > > > Storagesync mailing list
> > > > > Storagesyn= c@ietf.org
> > > > > https://www.ietf.org/mailm= an/listinfo/storagesync
> > > > >
> > >
> > > > _______________________________________________
> > > > Storagesync mailing list
> > > > Storagesync@iet= f.org
> > > > https://www.ietf.org/mailman/li= stinfo/storagesync
> >
> > > _______________________________________________
> > > Storagesync mailing list
> > > Storagesync@ietf.org=
> > > https://www.ietf.org/mailman/listinf= o/storagesync

--047d7bb04d365f844a052644827d-- From nobody Sun Dec 6 17:20:54 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16CF1A90C8 for ; Sun, 6 Dec 2015 17:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwMo39unacxO for ; Sun, 6 Dec 2015 17:20:52 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id C8FDA1A90C5 for ; Sun, 6 Dec 2015 17:20:51 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494512482910.5486012112814933" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <20151206215458.GA6619@localhost.localdomain> References: <566014EA.2010705@tuxed.net> <56601F18.8030409@tuxed.net> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <2015120612140798437464@bjtu.edu.cn> <20151206173936.GB6290@localhost.localdomain> <1449426414825-9cdbb6fe-86b1149f-71354c71@fugue.com> <20151206215458.GA6619@localhost.localdomain> Date: Mon, 07 Dec 2015 01:20:48 +0000 Message-Id: <1449451248586-f6bee07c-02d25585-e61e622f@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 01:20:54 -0000 ------sinikael-?=_1-14494512482910.5486012112814933 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Dec 6, 2015 4:54 PM Markus Unterwaditzer wrote: > Etags are *much* simpler to implement on the server side than the WebDAV = sync > protocol because they do not require the server to keep sync tokens and > metadata history. Note that the server has to keep metadata of *deleted* = files > to correctly implement WebDAV's sync protocol. Etags are less efficient = in > terms of network usage of course, but that's the tradeoff to be made. There's nothing hard about keeping metadata history. > I don't know what you mean with the last sentence. If you use etags, there's no way to tell whether a file disappeared from = the server because it was deleted or because the server got damaged. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494512482910.5486012112814933 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZN7wCRAMw8Nu0HeKywAAHaMH/18RgvrKogEysnPHYg0m fnSVAF7TBgwbN69vpRAEevAX7UZIXCknFNapWohu5Qb19OOuYYQrRxp7gwO5 Nn6JACZtQyTHPbTjGLJNG1OIFF5uA0hD7YJT9tAlh948shn8q6KDzC+n8t91 4Q3laLa1TXBGZ932J6iTa+Gw2m0GOpTqBa2GyZuyIj7pefu1zxZda1tBem6o 0WytbsJ4sFLmmxCjVVF8hBhggqQj+ZzwB9YBKF6whRzgvV8a2WKeLA8nk96f KVTlqnUG2UKtFgxxE/TfJoN5+vzWm9muJwWCGdS6VneQRjQD3nw6AR5RuHM3 RICExLmnkxz5o8Xz4McX/mg= =4WaF -----END PGP SIGNATURE----- ------sinikael-?=_1-14494512482910.5486012112814933-- From nobody Sun Dec 6 17:23:05 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5343D1A90D1 for ; Sun, 6 Dec 2015 17:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Arj-OlzMOg6N for ; Sun, 6 Dec 2015 17:23:02 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92C91A90D4 for ; Sun, 6 Dec 2015 17:23:01 -0800 (PST) Received: (qmail 14026 invoked from network); 7 Dec 2015 01:22:59 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 7 Dec 2015 01:22:59 -0000 Date: Mon, 7 Dec 2015 02:22:53 +0100 From: Markus Unterwaditzer To: Linhui Sun Message-ID: <20151207012253.GA10858@localhost.localdomain> References: <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 01:23:04 -0000 On Mon, Dec 07, 2015 at 09:09:08AM +0800, Linhui Sun wrote: > 2015-12-07 8:54 GMT+08:00 Markus Unterwaditzer : > > > On Mon, Dec 07, 2015 at 08:50:00AM +0800, Linhui Sun wrote: > > > But what if the file has been changed during two sync processes by > > another > > > participant who also shares the file. > > > > Those are sync conflicts, how to deal with then depends on the kind of > > data you > > deal with. > > > That works, but do you think this could make the things complicated? It > sounds like different situations have different mechanisms. Why not just > make the metadata exchanged, any disadvantage for doing that? I don't know what that means. > > > > > > > > > > > > > > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote: > > > > > On 周一, 12月 7, 2015 at 01:36, Markus Unterwaditzer < > > markus@unterwaditzer.net> > > > > > wrote: > > > > > > IMO, etag is designed for client side cache. A typical usage: if > > the file > > > > > > on the server has no actual change, the client will use the cache > > and the > > > > > > server does not need to send the file content again. While for a > > storage > > > > > > service, we also need some some similar mechanism at server side. > > In this > > > > > > way, the client do not need to upload unchanged content to the > > server. > > > > > > > > > > There is no "true-and-only" usecase for etags, and no, you do not > > need > > > > anything > > > > > more than etags for synchronization. Using a additional "metadata" > > file, the > > > > > client can cheaply determine whether local content changed and > > whether > > > server > > > > > content changed, and that's all that is required for (in this case) > > file > > > > > synchronization. Sync conflicts are a different story, and the > > solution to > > > > that > > > > > heavily depends on the kind of data you're syncing. I'm a little bit > > > confused > > > > here: if I have a metadata file, why do I still need > > > > > the etag? The metadata file should contain something equivalent to > > the etag. > > > > > > > > > > > > > > > > > > -- > > > > > > > Sent from my phone. Please excuse my brevity. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Storagesync mailing list > > > > > > > Storagesync@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Storagesync mailing list > > > > > > Storagesync@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > > > > > _______________________________________________ > > > > > Storagesync mailing list > > > > > Storagesync@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/storagesync > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Sun Dec 6 17:32:03 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCBA1A90EB for ; Sun, 6 Dec 2015 17:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N0KQi0UMnEh for ; Sun, 6 Dec 2015 17:32:02 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE281A90EA for ; Sun, 6 Dec 2015 17:32:01 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494519173440.2833807640708983" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <20151207003810.GA24130@localhost.localdomain> References: <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> Date: Mon, 07 Dec 2015 01:31:57 +0000 Message-Id: <1449451917710-5e6e9f52-e22aca39-c4065b40@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 01:32:03 -0000 ------sinikael-?=_1-14494519173440.2833807640708983 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Dec 6, 2015 7:38 PM Markus Unterwaditzer wrote: > On Mon, Dec 07, 2015 at 08:31:55AM +0800, Linhui Sun wrote: >> The server only need to know the latest version in my view. They don't = need to >> be able to identify last sync or change, just to check whether metadata = file is >> latest is enough. >=20 > The metadata file contains all etags *for all files* from the previous = sync. It > is stored on the clientside and is never sent to the server. This may be how your system works, but what I want is for the each peer to = remember every version that it has shared with another peer. This allows = two peers to agree on a common version and send only the metadata that's = changed since that version, rather than sending a complete metadata = snapshot or, as I think would be required in your case, Markus, scanning = the WebDAV server to see what's changed. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494519173440.2833807640708983 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZOGNCRAMw8Nu0HeKywAAH9wIAJVzwaFwgE4jpvQ+CZfR c4xCvCqNj7QfkjbMZ/3Y+TzpjDVqOg/PGlZmJYcHX2CYpxUZ1FWx1lZe/7PT dKuw36WqBuk3XsWahzUrxX1Xr0qAEFpIBU4y1nhl7HHIkeCbd4yw09BNtJub fvVhHdIW0MbQe2m5VduZJQnL4RQSo3JIqyKzV9nsOVJzztqKFOjmvNistNlZ PBES2KTc0Uvos9FCSnfr3tvo8MoDb9ob2tyYuiv7YiwjezIEndq4EzeNEIGX HD00NpzMi7FjeqlWF2QeRADEUSLup5axEkYDyLgQEVXqNPzc3ZTGSnuuu7db gHAjSxyikHJhw6AFEgkvdYk= =kcHi -----END PGP SIGNATURE----- ------sinikael-?=_1-14494519173440.2833807640708983-- From nobody Sun Dec 6 17:33:17 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0581A90F6 for ; Sun, 6 Dec 2015 17:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmv_MUAsnjg0 for ; Sun, 6 Dec 2015 17:33:14 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 399141A90F4 for ; Sun, 6 Dec 2015 17:33:14 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygCX6AGA4mRWkQAAAA--.4S2; Mon, 07 Dec 2015 09:36:01 +0800 (CST) Date: Mon, 7 Dec 2015 09:33:13 +0800 From: "Fei Song" To: storagesync X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120709331295395077@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygCX6AGA4mRWkQAAAA--.4S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZw18Gw1rWFyruF1UKF1Utrb_yoWDZFc_Wr 1kA348Cw1kGrZIq3WfJFs3WrsrJay5GFy8Ka4UtFZFv3y8urn5AF4kWr97ua4agFy8Jrnr GFZ3Kry5Gr43GjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb4xYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW0oVCq 3wA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3w AS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IY x2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4 x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCY 02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I0E74 80Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0 I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04 k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY 1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jO8nOUUU UU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] Fw: Re: Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 01:33:16 -0000 WWVzLCBJcyBpdCBvbmUgb2YgdGhlIHJlYXNvbnMgd2h5IHlvdSBsaWtlIGRpc3RyaWJ1dGVkIG1v ZGUgKGNvbXBhcmluZyB3aXRoIEMvUyBtb2RlKT8gOikNCkkgYWdyZWUgdGhhdCB0aGUgZXZhbHVh dGlvbiBvZiBFdGFncyBzaG91bGQgZGVwb25kIG9uIHRoZSBzaXR1YXRpb24gKGZyZXF1ZW50IGNo YW5nZXMsIFN5bmMgY29uZmxpY3RzLCBldGMuKQ0KQW5kIHRoZSBidXJkZW5zIGluIGJvdGggbmV0 d29yayBzaWRlIGFuZCBzZXJ2ZXIgc2lkZXMgc2hvdWxkIGJlIGNvbnNpZGVyIHNpbXVsdGFuZW91 c2x5Lg0KDQoNCkZlaSBTb25nDQoNCkZyb206IFRlZCBMZW1vbg0KRGF0ZTogMjAxNS0xMi0wNyAw MjoyNg0KVG86IHN0b3JhZ2VzeW5jDQpTdWJqZWN0OiBSZTogW1N0b3JhZ2VzeW5jXSBTdG9yYWdl c3luYyBEaWdlc3QsIFZvbCA1LCBJc3N1ZSAxDQoNCkV0YWdzIGFyZSBub3QgcmVhbGx5IG11Y2gg c2ltcGxlciB0aGFuIGEgbWV0YWRhdGEgdmVyc2lvbmluZyBzeW5jIHByb3RvY29sLCBhbmQgdGhl eSBhcmUgYSBsb3QgbGVzcyBlZmZpY2llbnQuICAgSGF2aW5nIHRvIGZldGNoIHRoZSB3aG9sZSBk aXJlY3RvcnkgZm9yIGV2ZXJ5IGRpcmVjdG9yeSB0aGF0IGNvbnRhaW5zIGEgY2hhbmdlIGlzIGV4 cGVuc2l2ZSwgYm90aCBmb3IgdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudCwgdW5sZXNzIGNoYW5n ZXMgYXJlIGluZnJlcXVlbnQuICAgQW5kIGJlY2F1c2UgdGhlIHNlcnZlciBpcyB0aGUgc29sZSBz b3VyY2Ugb2YgdHJ1dGgsIGl0J3MgYSBsb3QgbW9yZSBmcmFnaWxlLg0KDQoNCi0tDQpTZW50IGZy b20gV2hpdGVvdXQgTWFpbCAtIGh0dHBzOi8vd2hpdGVvdXQuaW8NCg0KTXkgUEdQIGtleTogaHR0 cHM6Ly9rZXlzLndoaXRlb3V0LmlvL21lbGxvbkBmdWd1ZS5jb20NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3RvcmFnZXN5bmMgbWFpbGluZyBs aXN0DQpTdG9yYWdlc3luY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdG9yYWdlc3luYw== From nobody Sun Dec 6 17:35:45 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8061A9109 for ; Sun, 6 Dec 2015 17:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV8yYqL4aIEj for ; Sun, 6 Dec 2015 17:35:43 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 2E87A1A9108 for ; Sun, 6 Dec 2015 17:35:42 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494521394890.6165189987514168" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> Date: Mon, 07 Dec 2015 01:35:39 +0000 Message-Id: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 01:35:44 -0000 ------sinikael-?=_1-14494521394890.6165189987514168 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Dec 6, 2015 8:09 PM Linhui Sun wrote: >> Those are sync conflicts, how to deal with then depends on the kind of >> data you >> deal with. >> > That works, but do you think this could make the things complicated=3F = It > sounds like different situations have different mechanisms. Why not just > make the metadata exchanged, any disadvantage for doing that=3F Right. Conflict resolution is a layer above syncing. Could be automatic= , could require human intervention (although that's best avoided if = possible). Ideally you have a way to go back and undo a change if = something important was lost or overwritten. This is another reason why = keeping a versioned metadata store is good. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494521394890.6165189987514168 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZOJrCRAMw8Nu0HeKywAAel4IAKqUFSRrPMZzebaRWCOZ 3/QyyT+2wIeU9WXjiGnAfKOWUSjwAaV9YNJd3ouVCSsYkUu50vlvrMSozflk aDzxqSmLYAZJJtl6fo/6huYZrjfotN6kt648c2SOiuBuH0+ywgEvdAzZ0ugj dCC5IEGPqDXH/mo4pQ5P63bHGaDg7F5nJCwN/4yXU7Xjt/bfUJU9nLwKN57p 4c8JiznFYm72ZLMmCcbiIFXgte8hAYlQ623DMsZwXtjLe+PFXE/xQUQU7XZ6 GNO6qHoQjGkZApjwPkutjuNf7Vg2rtHiwT3qtv3+zu06b2E3sndHTLqkyBfJ /1t2LDCAfml/mjFPPeOzRJ0= =1T0W -----END PGP SIGNATURE----- ------sinikael-?=_1-14494521394890.6165189987514168-- From nobody Sun Dec 6 18:06:06 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E09E1A92F0 for ; Sun, 6 Dec 2015 18:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCtABYzwueqH for ; Sun, 6 Dec 2015 18:06:02 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907B11A92EE for ; Sun, 6 Dec 2015 18:06:02 -0800 (PST) Received: by qkek142 with SMTP id k142so26134764qke.2 for ; Sun, 06 Dec 2015 18:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=EkRFkwXfJt+XQOeAuvT3RBQ0aRCP4SFYosoNEuZosVg=; b=umDab3HRQzE9doit0kicGIJyegz/CNHeGZvAC0bqq++y1mfLGBfRYX95Od5rEZM/QM HIBRpWaJf4u1BSEUSq82xXnweI5bPNNqvKXj/f7zdoJLK8MYICCSyq1sw3tGQhnLPvlr 8B4FchIuus1oQmpkS0jx2l7NR3OV08CKYSPUFCldz0ToBix51mftY/0fDJMF97WV7O20 GiuagV1pCO6WFMNxpJho7Ep1cn2mcaqrcZZxC5Nh2SnBrj0z40NHVSqs9hugNkkLXCpH so1yiKkr+8ATI4eOZAjGR8aKnte3sn5t6sCS8NcZfe8mwkOhRK4S2cZIpepKD+BEV8dT tLgA== X-Received: by 10.55.79.141 with SMTP id d135mr33240817qkb.41.1449453961778; Sun, 06 Dec 2015 18:06:01 -0800 (PST) Received: from [127.0.0.1] (ec2-54-210-254-233.compute-1.amazonaws.com. [54.210.254.233]) by smtp.gmail.com with ESMTPSA id b204sm10663006qhb.21.2015.12.06.18.06.00 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 18:06:00 -0800 (PST) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14494539600620.460493445629254" From: Linhui Sun To: Markus Unterwaditzer In-Reply-To: <20151207012253.GA10858@localhost.localdomain> References: <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <20151207012253.GA10858@localhost.localdomain> Date: Mon, 07 Dec 2015 10:05:56 +0800 X-Cm-Message-Id: 1449453959895882ae3914fb36c97c4e8595adc2eb26c08f5664e987dac3d1133387358 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0NDk0NTM5NTYwMDAiLCJjIiwiMTUxOTM5MTI5MTk2ODkzMDAyMCIsInYiLDFd X-Mailer: CloudMagic Message-Id: <1449453960221-fd85c35a-83d0a351-b60f3237@gmail.com> MIME-Version: 1.0 Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 02:06:05 -0000 ------sinikael-?=_1-14494539600620.460493445629254 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 09:22, Markus Unterwaditzer = wrote: On Mon, Dec 07, 2015 at 09:09:08AM +0800,= Linhui Sun wrote: > 2015-12-07 8:54 GMT+08:00 Markus Unterwaditzer = : > > > On Mon, Dec 07, 2015 at 08:50:00AM +0800,= Linhui Sun wrote: > > > But what if the file has been changed during two = sync processes by > > another > > > participant who also shares the file. > > > > Those are sync conflicts, how to deal with then depends on the kind= of > > data you > > deal with. > > > That works, but do you think this = could make the things complicated? It > sounds like different situations = have different mechanisms. Why not just > make the metadata exchanged, any = disadvantage for doing that? I don't know what that means. The question is= why you just keep the metadata locally at client side but not exchange the metadata between client and server to make both of them (both peers) have the latest metadata store in time. > > > > > > > > > > > > > > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote: > > > > > On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, Markus = Unterwaditzer < > > markus@unterwaditzer.net> > > > > > wrote: > > > > > > IMO, etag is designed for client side cache. A typical usage: = if > > the file > > > > > > on the server has no actual change, the client = will use the cache > > and the > > > > > > server does not need to send the= file content again. While for a > > storage > > > > > > service, we also = need some some similar mechanism at server side. > > In this > > > > > > way, the client do not need to upload unchanged content to the > > server. > > > > > > > > > > There is no "true-and-only" usecase for = etags, and no, you do not > > need > > > > anything > > > > > more than etags for synchronization. Using a additional = "metadata" > > file, the > > > > > client can cheaply determine whether = local content changed and > > whether > > > server > > > > > content = changed, and that's all that is required for (in this case) > > file > > > > > synchronization. Sync conflicts are a different story, and the > > solution to > > > > that > > > > > heavily depends on the kind of data = you're syncing. I'm a little bit > > > confused > > > > here: if I have a = metadata file, why do I still need > > > > > the etag? The metadata file = should contain something equivalent to > > the etag. > > > > > > > > > > > > > > > > > > -- > > > > > > > Sent from my phone. Please excuse my brevity= . > > > > > > > > > > > > > > _____________________________________________= __ > > > > > > > Storagesync mailing list > > > > > > > Storagesync@ietf.= org > > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] = https://www.ietf.org/mailman/listinfo/storagesync [https://www.ietf.= org/mailman/listinfo/storagesync] > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Storagesync mailing list > > > > > > Storagesync@ietf.org > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www= .ietf.org/mailman/listinfo/storagesync [https://www.ietf.= org/mailman/listinfo/storagesync] > > > > > > > > > = _______________________________________________ > > > > > Storagesync = mailing list > > > > > Storagesync@ietf.org > > > > > [https://www.ietf.= org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/sto= ragesync [https://www.ietf.org/mailman/listinfo/storagesync] > > > _______________________________________________ > Storagesync mailing = list > Storagesync@ietf.org > [https://www.ietf.org/mailman/listinfo/storag= esync] https://www.ietf.org/mailman/listinfo/storagesync [https://www.ietf.org/mailman/listinfo/storagesync] ------sinikael-?=_1-14494539600620.460493445629254 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 09:22, Markus = Unterwaditzer <markus@unterwaditzer.net> wrote:
On Mon, Dec 07, 2015 at 09:09:08AM +0800, = Linhui Sun wrote:
> 2015-12-07 8:54 GMT+08:00 Markus Unterwaditzer = <markus@unterwaditzer.net>:
>
> > On Mon, Dec 07, = 2015 at 08:50:00AM +0800, Linhui Sun wrote:
> > > But what if = the file has been changed during two sync processes by
> > = another
> > > participant who also shares the file.
> = >
> > Those are sync conflicts, how to deal with then depends = on the kind of
> > data you
> > deal with.
> = >
> That works, but do you think this could make the things = complicated? It
> sounds like different situations have different = mechanisms. Why not just
> make the metadata exchanged, any = disadvantage for doing that?

I don't know what that means.=
The question is why you just keep the metadata locally at= client side but not exchange the metadata between client and server to = make both of them (both peers) have the latest metadata store in time.=


>
> = >
> > >
> > > >
> > > > On Mon= , Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote:
> > > = > > On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 01:36, Markus = Unterwaditzer <
> > markus@unterwaditzer.net>
> > = > > > wrote:
> > > > > > IMO, etag is = designed for client side cache. A typical usage: if
> > the = file
> > > > > > on the server has no actual change, = the client will use the cache
> > and the
> > > > = > > server does not need to send the file content again. While for = a
> > storage
> > > > > > service, we also = need some some similar mechanism at server side.
> > In = this
> > > > > > way, the client do not need to upload= unchanged content to the
> > server.
> > > > = >
> > > > > There is no "true-and-only" usecase for = etags, and no, you do not
> > need
> > > > = anything
> > > > > more than etags for synchronization. = Using a additional "metadata"
> > file, the
> > > >= > client can cheaply determine whether local content changed = and
> > whether
> > > server
> > > > = > content changed, and that's all that is required for (in this = case)
> > file
> > > > > synchronization. Sync = conflicts are a different story, and the
> > solution to
> = > > > that
> > > > > heavily depends on the kind= of data you're syncing. I'm a little bit
> > > = confused
> > > > here: if I have a metadata file, why do I = still need
> > > > > the etag? The metadata file should = contain something equivalent to
> > the etag.
> > > = > >
> > > > > >
> > > > > >= > --
> > > > > > > Sent from my phone. Please = excuse my brevity.
> > > > > > >
> > > = > > > > _______________________________________________
>= > > > > > > Storagesync mailing list
> > > = > > > > Storagesync@ietf.org
> > > > > > = > https://www.ietf= .org/mailman/listinfo/storagesync
> > > > > > = >
> > > > >
> > > > > > = _______________________________________________
> > > > >= > Storagesync mailing list
> > > > > > = Storagesync@ietf.org
> > > > > > https://www.ietf= .org/mailman/listinfo/storagesync
> > > >
> > = > > > _______________________________________________
> >= > > > Storagesync mailing list
> > > > > = Storagesync@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/sto= ragesync
> >

> _____________________________________= __________
> Storagesync mailing list
> Storagesync@ietf.= org
> <= /a>https://ww= w.ietf.org/mailman/listinfo/storagesync

=20 ------sinikael-?=_1-14494539600620.460493445629254-- From nobody Sun Dec 6 18:16:24 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A01AC3D3 for ; Sun, 6 Dec 2015 18:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrRhohDYuenx for ; Sun, 6 Dec 2015 18:16:22 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545271AC3CF for ; Sun, 6 Dec 2015 18:16:22 -0800 (PST) Received: by qgcc31 with SMTP id c31so133332911qgc.3 for ; Sun, 06 Dec 2015 18:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:from:to:cc:in-reply-to:references:subject:date :message-id:mime-version; bh=WsLrVpLbIXXnMwaIrUkus2jqxBnpThmykJI78YTrQ/E=; b=q3Zkj5Sr4pYqX50Hf3QQVEQ34smpTC5IiuuqB54xFWgRPxCOK5UAsHaQS14pIC5PGi YNKsjfCVhRJuLlV0tYC1isIIwMSlvsstpH8e5QgLEscs1q/wFDZLVmT2udYzmIt4EGy/ dWLw6V5r3PEJ3Meo6oU/riFGdTxBPpAjnKAmskhTWBEtSTXpRs5QBYuB/Eg3vLZz1wzj KuNQKkYY4orkNSse6H3dA4+bpTW1k+7FwzXXXLtTZEaVpRk6mLwQ8zk0Z0p08x5656M/ Im1DifH0z9cXH1ugUItKOCDNGcf85LFPZvgeGdF4ahoV73btWpaTBY2VyijXvMPjPkQq Fo+g== X-Received: by 10.140.217.211 with SMTP id n202mr36142076qhb.26.1449454581618; Sun, 06 Dec 2015 18:16:21 -0800 (PST) Received: from [127.0.0.1] (ec2-54-210-254-233.compute-1.amazonaws.com. [54.210.254.233]) by smtp.gmail.com with ESMTPSA id u59sm10720090qge.0.2015.12.06.18.16.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 18:16:20 -0800 (PST) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14494545799720.6955633715260774" From: Linhui Sun To: Ted Lemon In-Reply-To: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> Date: Mon, 07 Dec 2015 10:16:17 +0800 X-Cm-Message-Id: 1449454579807462ae3914fb36c97c4e8595adc2eb26c08f5664ebf3c52e2933383508 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0NDk0NTQ1NzcwMDAiLCJjIiwiMTUxOTM5MTI5MTk2ODkzMDAyMCIsInYiLDFd X-Mailer: CloudMagic Message-Id: <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com> MIME-Version: 1.0 Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 02:16:24 -0000 ------sinikael-?=_1-14494545799720.6955633715260774 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 09:35, Ted Lemon = wrote: Sunday, Dec 6, 2015 8:09 PM Linhui Sun wrote: >> Those are sync conflicts, how to deal with then depends on the kind of >> data you >> deal with. >> > That works, but do you think this could make= the things complicated? It > sounds like different situations have = different mechanisms. Why not just > make the metadata exchanged, any = disadvantage for doing that? Right. Conflict resolution is a layer above = syncing. Could be automatic, could require human intervention (although = that's best avoided if possible). Concurrent conflict (e.g. Real-time edit)= might/should require human intervention. But the non-concurrent conflict = (e.g. modification caused by different peers but not at the same time) = should be automatically resolved by the system. Ideally you have a way to = go back and undo a change if something important was lost or overwritten. This is another reason why keeping a versioned = metadata store is good. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494545799720.6955633715260774 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On =E5=91=A8=E4=B8=80, 12=E6=9C=88 7, 2015 at 09:35, Ted = Lemon <mellon@fugue.com> wrote:
Sunday, Dec 6, 2015 8:09 PM= Linhui Sun wrote:
>> Those are sync conflicts, how to deal with = then depends on the kind of
>> data you
>> deal with.=
>>
> That works, but do you think this could make the = things complicated? It
> sounds like different situations have = different mechanisms. Why not just
> make the metadata exchanged, any= disadvantage for doing that?

Right. Conflict resolution is a = layer above syncing. Could be automatic, could require human intervention= (although that's best avoided if possible).
Concurrent conflict (e.g. Real-time edit) =  might/should require human intervention. But the non-concurrent = conflict (e.g. modification caused by different peers but not at the same = time) should be automatically resolved by the system.
Ideally you have a way to go= back and undo a change if something important was lost or overwritten. = This is another reason why keeping a versioned metadata store is good.=


--
Sent from Whiteout Mail - https://whiteout.io

My = PGP key: https://keys.whiteout.io/mellon@fugue.com
=
=20 ------sinikael-?=_1-14494545799720.6955633715260774-- From nobody Sun Dec 6 18:27:33 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909BC1AC40E for ; Sun, 6 Dec 2015 18:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr-fV0JrBofL for ; Sun, 6 Dec 2015 18:27:30 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 73A7B1AC406 for ; Sun, 6 Dec 2015 18:27:29 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494552455690.6162782441824675" From: Ted Lemon To: lh.sunlinh@gmail.com In-Reply-To: <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com> References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com> Date: Mon, 07 Dec 2015 02:27:25 +0000 Message-Id: <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> MIME-Version: 1.0 Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 02:27:31 -0000 ------sinikael-?=_1-14494552455690.6162782441824675 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Dec 6, 2015 9:16 PM Linhui Sun wrote: > Right. Conflict resolution is a layer above syncing. Could be automatic, = could > require human intervention (although that's best avoided if possible). = Concurrent conflict (e.g. Real-time edit) might/should require human > intervention. But the non-concurrent conflict (e.g. modification caused = by > different peers but not at the same time) should be automatically = resolved by > the system. Ideally you have a way to go back and undo a change if = something important was > lost or overwritten. This is another reason why keeping a versioned = metadata > store is good. Nope, this doesn't always work. E.g., peer A is acting as the central = server, and peers B and C are disconnected, and while disconnected, both = modify file F. When they reconnect, it's not the case that the later = modification to file F can be considered to supersede the earlier = modification. Because both clients modified the same version of the file,= what you probably want is for the changes that B made and the changes that= C made to be merged. Often this can be done automatically, but not if = both changes are to the same part of the file, and are not the same change.= Merges can also be a problem if there are cross-file dependencies. So the bottom line is that you do need to be able to run a conflict = resolution process after an update. But it's not part of the update--it's = a separate step, which may result in =5Fanother=5F update once it's = completed. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494552455690.6162782441824675 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZO6OCRAMw8Nu0HeKywAAWsEIAKyMgQkbDoN+7CDYYgNf K7AkS7EIjQt5urRbRoqrLije++hRVlZhXOLrNnIJMTx3ErMoRyLyHGifZTFO tlESRYxIMhaeztZaXh0nPAW2iiv1tBfrePXtU59SqZhzc2mMjpTOlIuoxNqq 0vX8mC77UnWcPr+ouO971FbiVm+B10x9kiUCM+u5So/i/KwTSDrP+3w+8MD4 i1BOb1UgxtQI5d2lLxfi6ifwfPsCwrceM25/eBJH+CGY+0N76euiAvn0P3GA ksB/ljoqzBMoHiO5nyn8TNDJfFHJF/UdT68ykxy5QMK/WI9nvGyWqUetkqNQ +6rXkXFFyeNKYz+ifdBQHhw= =+F6I -----END PGP SIGNATURE----- ------sinikael-?=_1-14494552455690.6162782441824675-- From nobody Sun Dec 6 18:38:14 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2611ACD32 for ; Sun, 6 Dec 2015 18:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7Hah_D-OqZN for ; Sun, 6 Dec 2015 18:38:11 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30D1ACD30 for ; Sun, 6 Dec 2015 18:38:10 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygCnCuaw8WRWNAAAAA--.8S2; Mon, 07 Dec 2015 10:40:48 +0800 (CST) Date: Mon, 7 Dec 2015 10:38:08 +0800 From: "Fei Song" To: storagesync X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120710380820341179@bjtu.edu.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart267711440563_=----" X-CM-TRANSID: Mp5wygCnCuaw8WRWNAAAAA--.8S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zr1fWF4rJF1kGFyrKr4kWFg_yoW8CF48pr WUGFyfGF4Dtr4fX3ykZw129340yrn8W3y7Jwn5Jw13t34rGFW2gF10kr15CrZ7W398GF10 qr4Ygw1UGw4DXF7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkqb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAF wI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0x vY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc2xSY4AK 67AK6r4UMxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwV AFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv2 0xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4 v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E 14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8qXd5UUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 02:38:13 -0000 This is a multi-part message in MIME format. ------=_001_NextPart267711440563_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTWFya3VzLA0KDQpTbywgaW4gcmVtb3RlU3RvcmFnZSwgd2hhdCBzaG91bGQgYmUgc3RvcmVk IGF0IHRoZSBib3RoIGNsaWVudCBhbmQgc2VydmVyIHNpZGU/DQpFdGFncyBvciBtZXRhZGF0YSBv ciBtZXRhZGF0YSBoaXN0b3J5IG9yIG90aGVyIHRoaW5ncz8NCmJhc2VkIG9uIHRoZSBkcmFmdCwg aXQgc2VlbXMgdGhhdCBvbmx5IEV0YWcgaXMgZW5vdWdoLCBidXQgdGhlIGNvbnRleHQgaW4gdGhp cyBtYWlsaW5nIGxpc3QgY29uZnVzZWQgbWUuLi4NCg0KDQoNCg0KRmVpIFNvbmcNCg0KRnJvbTog TWFya3VzIFVudGVyd2FkaXR6ZXINCkRhdGU6IDIwMTUtMTItMDcgMDU6NTQNClRvOiBUZWQgTGVt b24NCkNDOiBzdG9yYWdlc3luYw0KU3ViamVjdDogUmU6IFtTdG9yYWdlc3luY10gU3RvcmFnZXN5 bmMgRGlnZXN0LCBWb2wgNSwgSXNzdWUgMQ0KRXRhZ3MgYXJlICptdWNoKiBzaW1wbGVyIHRvIGlt cGxlbWVudCBvbiB0aGUgc2VydmVyIHNpZGUgdGhhbiB0aGUgV2ViREFWIHN5bmMNCnByb3RvY29s IGJlY2F1c2UgdGhleSBkbyBub3QgcmVxdWlyZSB0aGUgc2VydmVyIHRvIGtlZXAgc3luYyB0b2tl bnMgYW5kDQptZXRhZGF0YSBoaXN0b3J5LiBOb3RlIHRoYXQgdGhlIHNlcnZlciBoYXMgdG8ga2Vl cCBtZXRhZGF0YSBvZiAqZGVsZXRlZCogZmlsZXMNCnRvIGNvcnJlY3RseSBpbXBsZW1lbnQgV2Vi REFWJ3Mgc3luYyBwcm90b2NvbC4gRXRhZ3MgYXJlIGxlc3MgZWZmaWNpZW50IGluDQp0ZXJtcyBv ZiBuZXR3b3JrIHVzYWdlIG9mIGNvdXJzZSwgYnV0IHRoYXQncyB0aGUgdHJhZGVvZmYgdG8gYmUg bWFkZS4NCg0KSSBkb24ndCBrbm93IHdoYXQgeW91IG1lYW4gd2l0aCB0aGUgbGFzdCBzZW50ZW5j ZS4NCg0KT24gU3VuLCBEZWMgMDYsIDIwMTUgYXQgMDY6MjY6NTRQTSArMDAwMCwgVGVkIExlbW9u IHdyb3RlOg0KPiBTdW5kYXksIERlYyA2LCAyMDE1IDEyOjM5IFBNIE1hcmt1cyBVbnRlcndhZGl0 emVyIHdyb3RlOg0KPiA+IFdoYXQgZG8geW91IG1lYW4gYnkgIml0Ij8gRVRhZ3MgYXJlIHNpbXBs ZXIgdG8gaW1wbGVtZW50IHRoYW4gdGhlIGFib3ZlIFJGQywNCj4gPiBhbmQgRVRhZ3MgYXJlIGFs c28gcmVxdWlyZWQgaW4gV2ViREFWLg0KPiANCj4gRXRhZ3MgYXJlIG5vdCByZWFsbHkgbXVjaCBz aW1wbGVyIHRoYW4gYSBtZXRhZGF0YSB2ZXJzaW9uaW5nIHN5bmMgcHJvdG9jb2wsIGFuZCB0aGV5 IGFyZSBhIGxvdCBsZXNzIGVmZmljaWVudC4gICBIYXZpbmcgdG8gZmV0Y2ggdGhlIHdob2xlIGRp cmVjdG9yeSBmb3IgZXZlcnkgZGlyZWN0b3J5IHRoYXQgY29udGFpbnMgYSBjaGFuZ2UgaXMgZXhw ZW5zaXZlLCBib3RoIGZvciB0aGUgc2VydmVyIGFuZCB0aGUgY2xpZW50LCB1bmxlc3MgY2hhbmdl cyBhcmUgaW5mcmVxdWVudC4gICBBbmQgYmVjYXVzZSB0aGUgc2VydmVyIGlzIHRoZSBzb2xlIHNv dXJjZSBvZiB0cnV0aCwgaXQncyBhIGxvdCBtb3JlIGZyYWdpbGUuDQo+IA0KPiANCj4gLS0NCj4g U2VudCBmcm9tIFdoaXRlb3V0IE1haWwgLSBodHRwczovL3doaXRlb3V0LmlvDQo+IA0KPiBNeSBQ R1Aga2V5OiBodHRwczovL2tleXMud2hpdGVvdXQuaW8vbWVsbG9uQGZ1Z3VlLmNvbQ0KDQoNCg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTdG9y YWdlc3luYyBtYWlsaW5nIGxpc3QNCj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3RvcmFnZXN5bmMgbWFp bGluZyBsaXN0DQpTdG9yYWdlc3luY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw== ------=_001_NextPart267711440563_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Markus,
 
So, in remoteStorage, what should be stored at the both client and se= rver=20 side?
Etags or metadata or metadata history or other things?
based on the draft, it seems that only Etag is enough, but the contex= t in=20 this mailing list confused me...
 
Fei Song
 
Date: 2015-12-07 05:54
Etags are *much* simpler to implement o= n the server side than the WebDAV sync<= /DIV>
protocol because they do not require th= e server to keep sync tokens and
metadata history. Note that the server = has to keep metadata of *deleted* files
to correctly implement WebDAV's sync protoco= l. Etags are less efficient in
terms of network usage of course, but&n= bsp;that's the tradeoff to be made.
 
I don't know what you mean with th= e last sentence.
 
On Sun, Dec 06, 2015 at 06:26:54PM = ;+0000, Ted Lemon wrote:
> Sunday, Dec 6, 2015 12:39 PM = Markus Unterwaditzer wrote:
> > What do you mean by "it"= ? ETags are simpler to implement than t= he above RFC,
> > and ETags are also required&n= bsp;in WebDAV.
> 
> Etags are not really much simpler&= nbsp;than a metadata versioning sync protocol,&nb= sp;and they are a lot less efficient. &= nbsp; Having to fetch the whole directory&nb= sp;for every directory that contains a chang= e is expensive, both for the server and=  the client, unless changes are infrequent.&= nbsp;  And because the server is the&nb= sp;sole source of truth, it's a lot mor= e fragile.
> 
> 
> --
> Sent from Whiteout Mail - https://= whiteout.io
> 
> My PGP key: https://keys.whiteout.io/mellon@= fugue.com
 
 
 
> _______________________________________________
> Storagesync mailing list
> Storagesync@ietf.org
> https://www.ietf.org/mailman/listinfo/storagesync
 
 
 
 
_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync
 
------=_001_NextPart267711440563_=------ From nobody Sun Dec 6 19:17:11 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914531B2C46 for ; Sun, 6 Dec 2015 19:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3K4BtM3TqE5 for ; Sun, 6 Dec 2015 19:17:07 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id E0BD11B2C3D for ; Sun, 6 Dec 2015 19:17:06 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygDn7_fY+mRW_GoFAA--.10748S2; Mon, 07 Dec 2015 11:19:52 +0800 (CST) Date: Mon, 7 Dec 2015 11:17:06 +0800 From: "Fei Song" To: storagesync References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com>, <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120711170621874681@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygDn7_fY+mRW_GoFAA--.10748S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zr15tFWUCw4fXrWDAFykGrg_yoW8Zr4xpF W3KFnakayqywn29a4xA3WxuF48Zw4kXr43GF15Krn3Z3y7KrW8tF1IgrWxCFyxW3s3ur1j vrWavwnrCw10va7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUxm L9DUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 03:17:08 -0000 DQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KPlN1bmRheSwgRGVjIDYsIDIwMTUgOToxNiBQ TSBMaW5odWkgU3VuIHdyb3RlOg0KPj4gUmlnaHQuIENvbmZsaWN0IHJlc29sdXRpb24gaXMgYSBs YXllciBhYm92ZSBzeW5jaW5nLiBDb3VsZCBiZSBhdXRvbWF0aWMsIGNvdWxkDQo+PiByZXF1aXJl IGh1bWFuIGludGVydmVudGlvbiAoYWx0aG91Z2ggdGhhdCdzIGJlc3QgYXZvaWRlZCBpZiBwb3Nz aWJsZSkuIENvbmN1cnJlbnQgY29uZmxpY3QgKGUuZy4gUmVhbC10aW1lIGVkaXQpIG1pZ2h0L3No b3VsZCByZXF1aXJlIGh1bWFuDQo+PiBpbnRlcnZlbnRpb24uIEJ1dCB0aGUgbm9uLWNvbmN1cnJl bnQgY29uZmxpY3QgKGUuZy4gbW9kaWZpY2F0aW9uIGNhdXNlZCBieQ0KPj4gZGlmZmVyZW50IHBl ZXJzIGJ1dCBub3QgYXQgdGhlIHNhbWUgdGltZSkgc2hvdWxkIGJlIGF1dG9tYXRpY2FsbHkgcmVz b2x2ZWQgYnkNCj4+IHRoZSBzeXN0ZW0uIElkZWFsbHkgeW91IGhhdmUgYSB3YXkgdG8gZ28gYmFj ayBhbmQgdW5kbyBhIGNoYW5nZSBpZiBzb21ldGhpbmcgaW1wb3J0YW50IHdhcw0KPj4gbG9zdCBv ciBvdmVyd3JpdHRlbi4gVGhpcyBpcyBhbm90aGVyIHJlYXNvbiB3aHkga2VlcGluZyBhIHZlcnNp b25lZCBtZXRhZGF0YQ0KPj4gc3RvcmUgaXMgZ29vZC4NCj4NCj5Ob3BlLCB0aGlzIGRvZXNuJ3Qg YWx3YXlzIHdvcmsuICAgRS5nLiwgcGVlciBBIGlzIGFjdGluZyBhcyB0aGUgY2VudHJhbCBzZXJ2 ZXIsIGFuZCBwZWVycyBCIGFuZCBDIGFyZSBkaXNjb25uZWN0ZWQsIGFuZCB3aGlsZSBkaXNjb25u ZWN0ZWQsIGJvdGggbW9kaWZ5IGZpbGUgRi4gICBXaGVuIHRoZXkgcmVjb25uZWN0LCBpdCdzIG5v dCB0aGUgY2FzZSB0aGF0IHRoZSBsYXRlciBtb2RpZmljYXRpb24gdG8gZmlsZSBGIGNhbiBiZSBj b25zaWRlcmVkIHRvIHN1cGVyc2VkZSB0aGUgZWFybGllciBtb2RpZmljYXRpb24uICAgQmVjYXVz ZSBib3RoIGNsaWVudHMgbW9kaWZpZWQgdGhlIHNhbWUgdmVyc2lvbiBvZiB0aGUgZmlsZSwgd2hh dCB5b3UgcHJvYmFibHkgd2FudCBpcyBmb3IgdGhlIGNoYW5nZXMgdGhhdCBCIG1hZGUgYW5kIHRo ZSBjaGFuZ2VzIHRoYXQgQyBtYWRlIHRvIGJlIG1lcmdlZC4gICBPZnRlbiB0aGlzIGNhbiBiZSBk b25lIGF1dG9tYXRpY2FsbHksIGJ1dCBub3QgaWYgYm90aCBjaGFuZ2VzIGFyZSB0byB0aGUgc2Ft ZSBwYXJ0IG9mIHRoZSBmaWxlLCBhbmQgYXJlIG5vdCB0aGUgc2FtZSBjaGFuZ2UuDQoNCkNhbiB3 ZSBqdXN0IHRyZWF0IHRoZSByZXF1ZXN0cyBzZW50IGJ5IHBlZXIgQiBhbmQgcGVlciBDIGJhc2Vk IG9uIHRoZWlyIHRpbWVzdGFtcHMgKGFycml2aW5nIGF0IHRoZSBzZXJ2ZXIpLg0KSWYgdGhlIGZp bGUgbXVzdCBiZSBrZXB0IGFzIHRoZSBzYW1lIHZlcnNpb24sIGRpZmZlcmVudCBtb2RpZmljYXRp b24gcmVwb3J0cyBjYW4gYmUgZ2VuZXJhdGVkIGluZGVwZW5kZW50bHkgd2l0aCBGQ0ZTIG1vZGUu DQpJZiB0aGlzIGNhbiBub3QgYmUgZmluaXNoZWQgYXV0b21hdGljYWxseSwgYSBodW1hbiBpbnRl cnZlbnRpb24gd2lsbCBiZSBuZWVkZWQuDQoNCj4NCj5NZXJnZXMgY2FuIGFsc28gYmUgYSBwcm9i bGVtIGlmIHRoZXJlIGFyZSBjcm9zcy1maWxlIGRlcGVuZGVuY2llcy4NCg0KaW5kZWVkLg0KDQo+ DQo+U28gdGhlIGJvdHRvbSBsaW5lIGlzIHRoYXQgeW91IGRvIG5lZWQgdG8gYmUgYWJsZSB0byBy dW4gYSBjb25mbGljdCByZXNvbHV0aW9uIHByb2Nlc3MgYWZ0ZXIgYW4gdXBkYXRlLiAgQnV0IGl0 J3Mgbm90IHBhcnQgb2YgdGhlIHVwZGF0ZS0taXQncyBhIHNlcGFyYXRlIHN0ZXAsIHdoaWNoIG1h eSByZXN1bHQgaW4gX2Fub3RoZXJfIHVwZGF0ZSBvbmNlIGl0J3MgY29tcGxldGVkLg0KPg0KPg0K Pi0tDQo+U2VudCBmcm9tIFdoaXRlb3V0IE1haWwgLSBodHRwczovL3doaXRlb3V0LmlvDQo+DQo+ TXkgUEdQIGtleTogaHR0cHM6Ly9rZXlzLndoaXRlb3V0LmlvL21lbGxvbkBmdWd1ZS5jb20= From nobody Sun Dec 6 19:40:27 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840AF1B2D26 for ; Sun, 6 Dec 2015 19:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbNzHm8KZ2Rf for ; Sun, 6 Dec 2015 19:40:25 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 44B9B1B2D25 for ; Sun, 6 Dec 2015 19:40:24 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494596157930.7679847076069564" From: Ted Lemon To: fsong@bjtu.edu.cn In-Reply-To: <2015120711170621874681@bjtu.edu.cn> References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> Date: Mon, 07 Dec 2015 03:40:15 +0000 Message-Id: <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> MIME-Version: 1.0 Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 03:40:26 -0000 ------sinikael-?=_1-14494596157930.7679847076069564 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Dec 6, 2015 10:17 PM Fei Song wrote: > Can we just treat the requests sent by peer B and peer C based on their = timestamps (arriving at the server). > If the file must be kept as the same version, different modification = reports can be generated independently with FCFS mode. > If this can not be finished automatically, a human intervention will be = needed. No, this doesn't work even if you don't care about wiping out changes. = Think about this sequence: 0: File F is at version 0 1: Client A syncs to server 2: Client B syncs to server 3: File f changed on Client A -> Version 0.A 4: File f changed on Client B -> Version 0.B 5: Client B syncs to server, updating file F to version 0.B, modified time = =3D 4 6: Client A syncs to server: what happens=3F a: File updated to version 0.A, modified time=3D3 b: Server overwrites version 0.A with version 0.B, changes in 0.A lost c: Conflict resolution combines versions 0.A and 0.B, producing version = 1, mod time=3D6 I think C is the only right answer. We want conflict resolution to be = automatic whenever possible, but we do want to do conflict resolution, and = not just wipe out changes, because those changes may contain real work that= the user on client A did. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494596157930.7679847076069564 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZP+gCRAMw8Nu0HeKywAAUxgH/2nvoox8eD4CQm97SXc9 ikeimvuMweMqMtEpeu/omIF7OODKEO6kpgfUx1/NOC4GjTiimh5NguovyUTW zrmJRZwxrvZP4E478dUaqP6cwYkjDb5h7/+MnZhrkHp6HRzlITbTjR/VWGqt nnxsbgAwzQm7aWuQoCKVu+SXHHhHMKoTxnP/ysVPxWPJOXN0aqf8yv3f4j5+ dawGpFGzIBdN6q4dXCIsyOEjpf7g1Skkk5jzQ9G1Gzm+kkkYs7tGfjnGceAN ZgsVVWwdVEzXhfJagpjcqYNIv1A3ziJ8wSCb5PPHH8PXDAVF8K5rvRjwSHIn jpEuHcPgUmwiQPt1UKI1GgM= =TacX -----END PGP SIGNATURE----- ------sinikael-?=_1-14494596157930.7679847076069564-- From nobody Sun Dec 6 20:02:30 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BC31B2C31 for ; Sun, 6 Dec 2015 20:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaPPteFrzI-Y for ; Sun, 6 Dec 2015 20:02:29 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id B93531B2BCA for ; Sun, 6 Dec 2015 20:02:25 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494609406210.39082355983555317" From: Ted Lemon To: fsong@bjtu.edu.cn In-Reply-To: <2015120711591198474787@bjtu.edu.cn> References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn,> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <2015120711591198474787@bjtu.edu.cn> Date: Mon, 07 Dec 2015 04:02:20 +0000 Message-Id: <1449460940935-350ed1d5-a3d32a34-254205b2@fugue.com> MIME-Version: 1.0 Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] =?utf-8?b?5Zue5aSNOiBTdG9yYWdlc3luYyBEaWdlc3QsIFZv?= =?utf-8?q?l_5=2C_Issue_1?= X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 04:02:30 -0000 ------sinikael-?=_1-14494609406210.39082355983555317 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sunday, Dec 6, 2015 10:59 PM Fei Song wrote: >>0: File F is at version 0 >>1: Client A syncs to server >>2: Client B syncs to server >>3: File f changed on Client A -> Version 0.A >>4: File f changed on Client B -> Version 0.B >>5: Client B syncs to server, updating file F to version 0.B, modified = time =3D 4 >>6: Client A syncs to server: what happens=3F >> a: File updated to version 0.A, modified time=3D3 >> b: Server overwrites version 0.A with version 0.B, changes in 0.A = lost >> c: Conflict resolution combines versions 0.A and 0.B, producing = version 1, mod time=3D6 >>I think C is the only right answer. We want conflict resolution to be = automatic whenever possible, but we do want to do conflict resolution, and = not just wipe out changes, because those changes may contain real work that= the user on client A did. >=20 > These =22middle=22 changes are important. Yeah. they should be stroed at = the server side. > Wiping out changes is just a simple appoach. > I also think c is a good option. Then we need to consider a suitable time= window. > e.g. how long should be consider as a =22simultaneous=22 updating. > otherwise F might be updated as Version 1 directly. In option C, the time doesn't matter at all. It's the fact that the two = versions are different that triggers the conflict resolution process. So = there's no timing race to worry about: the first client to update just = succeeds, and the second client to update has to do conflict resolution. = Doesn't matter which client updates first, or when the updates happen. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14494609406210.39082355983555317 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZQTNCRAMw8Nu0HeKywAA7AoIAK149y5Tsivj7Zzrv4zz CT/af6dUvzEg6WxU/Xzxr7mgyz+B9zU9rb46F4pv8I0wMxqIaVp6y0JI5gDg PY7dtRaY2yJvHYT7o24N21jPRDFDp4h5HcCMNOFhFQkwwKRYtn9UriBt+V3U CNPTIWYqHqD5KSRfnB5Z7cg9mkn7iEV8HzQV4AHGsVL9l5bZC3veMxa0vW/K js/u6UwVZTTdbz55bljHL9LExbLATV1FU5arX29k7hPH4GXAEnofbmDrG9VK ePWSOesjzi0UQcs6l3KqLVVaeFtGKcVYAlbNUCBn189sXZGvq4sD6xo9mK2B OOAJCdSMZpCHN/vkA5b7WHQ= =LUBW -----END PGP SIGNATURE----- ------sinikael-?=_1-14494609406210.39082355983555317-- From nobody Sun Dec 6 22:45:49 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365421B3016 for ; Sun, 6 Dec 2015 22:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TudNbzC325go for ; Sun, 6 Dec 2015 22:45:45 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDFC1B2FEF for ; Sun, 6 Dec 2015 22:45:45 -0800 (PST) Received: by wmvv187 with SMTP id v187so151479517wmv.1 for ; Sun, 06 Dec 2015 22:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jiyLkUcwwfVb7nosHC9/qECUQzW1HZQG9GK57/CH7bE=; b=fkPzWeb0s9jomGS3LdRVjiKdUNKrhiIQ3ScDxMV1zi/3cSFuKSgzRFqpsDVAR+PsTc AuczvblPkWPByoSqj16xQBIfIvq0xrx3m9qCsEhlORhTu1ZrE6PlQCX+VZxVN4CK9lBY REzSKHYhpMTbXIVMBpQgnSHtdQQ71k9hvvl6b0Nel9L55TdkYT0qmi2tkvAzOnTo/Diq zxROOFvipcWLQQ9yR3ntQDznh/TSPbLjxHl62TskLoUEwNT1gUJbXkWZY0olpnzRmv/3 iiMAykJY17rjU+4DfNvDRR2AgzrYYsm9vpQxlCDeaBQshsKEFghZWjYhCFZF/cunyakr K2TQ== X-Received: by 10.28.89.137 with SMTP id n131mr20017476wmb.9.1449470743956; Sun, 06 Dec 2015 22:45:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Sun, 6 Dec 2015 22:45:24 -0800 (PST) In-Reply-To: <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> From: Linhui Sun Date: Mon, 7 Dec 2015 14:45:24 +0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1140cdb8ce519d052649342f Archived-At: Cc: fsong , storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 06:45:49 -0000 --001a1140cdb8ce519d052649342f Content-Type: text/plain; charset=UTF-8 2015-12-07 11:40 GMT+08:00 Ted Lemon : > Sunday, Dec 6, 2015 10:17 PM Fei Song wrote: > > Can we just treat the requests sent by peer B and peer C based on their > timestamps (arriving at the server). > > If the file must be kept as the same version, different modification > reports can be generated independently with FCFS mode. > > If this can not be finished automatically, a human intervention will be > needed. > > No, this doesn't work even if you don't care about wiping out changes. > Think about this sequence: > > 0: File F is at version 0 > 1: Client A syncs to server > 2: Client B syncs to server > 3: File f changed on Client A -> Version 0.A > 4: File f changed on Client B -> Version 0.B > 5: Client B syncs to server, updating file F to version 0.B, modified time > = 4 > 6: Client A syncs to server: what happens? > a: File updated to version 0.A, modified time=3 > b: Server overwrites version 0.A with version 0.B, changes in 0.A lost > c: Conflict resolution combines versions 0.A and 0.B, producing version > 1, mod time=6 > > I think C is the only right answer. We want conflict resolution to be > automatic whenever possible, but we do want to do conflict resolution, and > not just wipe out changes, because those changes may contain real work that > the user on client A did. > Do you mean you want the conflict resolution to be performed every time? If so, I think this might be a little bit unnecessary since a version conflict is not very frequently happened (especially for some personal users). The case you mentioned should definitely be resolved and such offline-to-online switch could be treated as concurrent conflict in my view. But a more frequent case is that people update their file just to replace the previous one, even though there are multiple people working on the same file. In this case, replacing file according to modification time seems reasonable. So the key point is how to justify which two/more versions should trigger the conflict resolution to avoid wiping out real work. As for the conflict resolution itself, it is very hard to achieve since the system needs to handle different types of file. GoogleDocs performs well since it only focuses on the documents. But for a storage service, we don't know what else types of file will be stored. A popular way I've seen is just to keep all the conflicted versions (named by different peers) in the storage. > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mellon@fugue.com > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --001a1140cdb8ce519d052649342f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-12-07 11:40 GMT+08:00 Ted Lemon <mellon@fugue.com>:<= br>
Sunday, Dec 6, 2015 10:1= 7 PM Fei Song wrote:
> Can we just treat the requests sent by peer B and peer C based on thei= r timestamps (arriving at the server).
> If the file must be kept as the same version, different modification r= eports can be generated independently with FCFS mode.
> If this can not be finished automatically, a human intervention will b= e needed.

No, this doesn't work even if you don't care about wiping ou= t changes.=C2=A0 =C2=A0Think about this sequence:

0: File F is at version 0
1: Client A syncs to server
2: Client B syncs to server
3: File f changed on Client A -> Version 0.A
4: File f changed on Client B -> Version 0.B
5: Client B syncs to server, updating file F to version 0.B, modified time = =3D 4
6: Client A syncs to server: what happens?
=C2=A0 =C2=A0a: File updated to version 0.A, modified time=3D3
=C2=A0 =C2=A0b: Server overwrites version 0.A with version 0.B, changes in = 0.A lost
=C2=A0 =C2=A0c: Conflict resolution combines versions 0.A and 0.B, producin= g version 1, mod time=3D6

I think C is the only right answer.=C2=A0 =C2=A0We want conflict resolution= to be automatic whenever possible, but we do want to do conflict resolutio= n, and not just wipe out changes, because those changes may contain real wo= rk that the user on client A did.
Do you mean you want= the conflict resolution to be performed every time? If so, I think this mi= ght be a little bit unnecessary since a version conflict is not very freque= ntly happened (especially for some personal users). The case you mentioned = should definitely be resolved and such offline-to-online switch could be tr= eated as concurrent conflict in my view.

But a mor= e frequent case is that people update their file just to replace the previo= us one, even though there are multiple people working on the same file. In = this case, replacing file according to modification time seems reasonable. = So the key point is how to justify which two/more versions should trigger t= he conflict resolution to avoid wiping out real work.

<= div>As for the conflict resolution itself, it is very hard to achieve since= the system needs to handle different types of file. GoogleDocs performs we= ll since it only focuses on the documents. But for a storage service, we do= n't know what else types of file will be stored. A popular way I've= seen is just to keep all the conflicted versions (named by different peers= ) in the storage.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com

_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync


--001a1140cdb8ce519d052649342f-- From nobody Sun Dec 6 23:28:40 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983F11B309B for ; Sun, 6 Dec 2015 23:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suJqsX73p5S6 for ; Sun, 6 Dec 2015 23:28:38 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 35B181B3097 for ; Sun, 6 Dec 2015 23:28:36 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygD3eIzHNWVWzvsFAA--.10702S2; Mon, 07 Dec 2015 15:31:19 +0800 (CST) Date: Mon, 7 Dec 2015 15:28:31 +0800 From: "Fei Song" To: "Linhui Sun" , mellon References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120715283107870294@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygD3eIzHNWVWzvsFAA--.10702S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGrWxZw4kAFW8Gr45WrWxWFg_yoW5urW7pr W5tF47Kr4kJw4fJ348Ar12gF4FyrZ5Jr18JF98tw18Z34DWayjgryIyrWYkry7X3s5Wryj qF4S9343Ww1qvrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_GF4l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 ubytUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 07:28:39 -0000 DQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KPjIwMTUtMTItMDcgMTE6NDAgR01UKzA4OjAw IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT46DQo+DQo+PiBTdW5kYXksIERlYyA2LCAyMDE1 IDEwOjE3IFBNIEZlaSBTb25nIHdyb3RlOg0KPj4gPiBDYW4gd2UganVzdCB0cmVhdCB0aGUgcmVx dWVzdHMgc2VudCBieSBwZWVyIEIgYW5kIHBlZXIgQyBiYXNlZCBvbiB0aGVpcg0KPj4gdGltZXN0 YW1wcyAoYXJyaXZpbmcgYXQgdGhlIHNlcnZlcikuDQo+PiA+IElmIHRoZSBmaWxlIG11c3QgYmUg a2VwdCBhcyB0aGUgc2FtZSB2ZXJzaW9uLCBkaWZmZXJlbnQgbW9kaWZpY2F0aW9uDQo+PiByZXBv cnRzIGNhbiBiZSBnZW5lcmF0ZWQgaW5kZXBlbmRlbnRseSB3aXRoIEZDRlMgbW9kZS4NCj4+ID4g SWYgdGhpcyBjYW4gbm90IGJlIGZpbmlzaGVkIGF1dG9tYXRpY2FsbHksIGEgaHVtYW4gaW50ZXJ2 ZW50aW9uIHdpbGwgYmUNCj4+IG5lZWRlZC4NCj4+DQo+PiBObywgdGhpcyBkb2Vzbid0IHdvcmsg ZXZlbiBpZiB5b3UgZG9uJ3QgY2FyZSBhYm91dCB3aXBpbmcgb3V0IGNoYW5nZXMuDQo+PiAgVGhp bmsgYWJvdXQgdGhpcyBzZXF1ZW5jZToNCj4+DQo+PiAwOiBGaWxlIEYgaXMgYXQgdmVyc2lvbiAw DQo+PiAxOiBDbGllbnQgQSBzeW5jcyB0byBzZXJ2ZXINCj4+IDI6IENsaWVudCBCIHN5bmNzIHRv IHNlcnZlcg0KPj4gMzogRmlsZSBmIGNoYW5nZWQgb24gQ2xpZW50IEEgLT4gVmVyc2lvbiAwLkEN Cj4+IDQ6IEZpbGUgZiBjaGFuZ2VkIG9uIENsaWVudCBCIC0+IFZlcnNpb24gMC5CDQo+PiA1OiBD bGllbnQgQiBzeW5jcyB0byBzZXJ2ZXIsIHVwZGF0aW5nIGZpbGUgRiB0byB2ZXJzaW9uIDAuQiwg bW9kaWZpZWQgdGltZQ0KPj4gPSA0DQo+PiA2OiBDbGllbnQgQSBzeW5jcyB0byBzZXJ2ZXI6IHdo YXQgaGFwcGVucz8NCj4+ICAgIGE6IEZpbGUgdXBkYXRlZCB0byB2ZXJzaW9uIDAuQSwgbW9kaWZp ZWQgdGltZT0zDQo+PiAgICBiOiBTZXJ2ZXIgb3ZlcndyaXRlcyB2ZXJzaW9uIDAuQSB3aXRoIHZl cnNpb24gMC5CLCBjaGFuZ2VzIGluIDAuQSBsb3N0DQo+PiAgICBjOiBDb25mbGljdCByZXNvbHV0 aW9uIGNvbWJpbmVzIHZlcnNpb25zIDAuQSBhbmQgMC5CLCBwcm9kdWNpbmcgdmVyc2lvbg0KPj4g MSwgbW9kIHRpbWU9Ng0KPj4NCj4+IEkgdGhpbmsgQyBpcyB0aGUgb25seSByaWdodCBhbnN3ZXIu ICAgV2Ugd2FudCBjb25mbGljdCByZXNvbHV0aW9uIHRvIGJlDQo+PiBhdXRvbWF0aWMgd2hlbmV2 ZXIgcG9zc2libGUsIGJ1dCB3ZSBkbyB3YW50IHRvIGRvIGNvbmZsaWN0IHJlc29sdXRpb24sIGFu ZA0KPj4gbm90IGp1c3Qgd2lwZSBvdXQgY2hhbmdlcywgYmVjYXVzZSB0aG9zZSBjaGFuZ2VzIG1h eSBjb250YWluIHJlYWwgd29yayB0aGF0DQo+PiB0aGUgdXNlciBvbiBjbGllbnQgQSBkaWQuDQo+ Pg0KPkRvIHlvdSBtZWFuIHlvdSB3YW50IHRoZSBjb25mbGljdCByZXNvbHV0aW9uIHRvIGJlIHBl cmZvcm1lZCBldmVyeSB0aW1lPyBJZg0KPnNvLCBJIHRoaW5rIHRoaXMgbWlnaHQgYmUgYSBsaXR0 bGUgYml0IHVubmVjZXNzYXJ5IHNpbmNlIGEgdmVyc2lvbiBjb25mbGljdA0KPmlzIG5vdCB2ZXJ5 IGZyZXF1ZW50bHkgaGFwcGVuZWQgKGVzcGVjaWFsbHkgZm9yIHNvbWUgcGVyc29uYWwgdXNlcnMp LiBUaGUNCj5jYXNlIHlvdSBtZW50aW9uZWQgc2hvdWxkIGRlZmluaXRlbHkgYmUgcmVzb2x2ZWQg YW5kIHN1Y2ggb2ZmbGluZS10by1vbmxpbmUNCj5zd2l0Y2ggY291bGQgYmUgdHJlYXRlZCBhcyBj b25jdXJyZW50IGNvbmZsaWN0IGluIG15IHZpZXcuDQoNCkZvciB0aGUgY29sbGFib3JhdGl2ZSB3 b3JraW5nLCBwZXJoYXBzIHdlIGhhdmUgdG8gZG8gdGhhdC4NCg0KPg0KPkJ1dCBhIG1vcmUgZnJl cXVlbnQgY2FzZSBpcyB0aGF0IHBlb3BsZSB1cGRhdGUgdGhlaXIgZmlsZSBqdXN0IHRvIHJlcGxh Y2UNCj50aGUgcHJldmlvdXMgb25lLCBldmVuIHRob3VnaCB0aGVyZSBhcmUgbXVsdGlwbGUgcGVv cGxlIHdvcmtpbmcgb24gdGhlIHNhbWUNCj5maWxlLiBJbiB0aGlzIGNhc2UsIHJlcGxhY2luZyBm aWxlIGFjY29yZGluZyB0byBtb2RpZmljYXRpb24gdGltZSBzZWVtcw0KPnJlYXNvbmFibGUuIFNv IHRoZSBrZXkgcG9pbnQgaXMgaG93IHRvIGp1c3RpZnkgd2hpY2ggdHdvL21vcmUgdmVyc2lvbnMN Cj5zaG91bGQgdHJpZ2dlciB0aGUgY29uZmxpY3QgcmVzb2x1dGlvbiB0byBhdm9pZCB3aXBpbmcg b3V0IHJlYWwgd29yay4NCg0KU3VyZSwgaW4gdW4tY29sbGFib3JhdGl2ZSBjYXNlIChqdXN0IGZv ciB5b3VyIG93biBmaWxlKSwgaXQncyBPSy4NCldoZW4gbXVsdGlwbGUgcGVvcGxlIHdvcmtpbmcg b24gdGhlIHNhbWUgZmlsZSAobGlrZSBhIHNvdXJjZSBjb2RlIGZpbGUpLCBzb21lIHdvcmsgc2hv dWxkIGJlIHNhdmVkIGV2ZW4gdGhleSBhcmUgbm90IGluY2x1ZGVkIGluIHRoZSBmaW5hbCB2ZXJz aW9uLg0KVGhpcyBpcyBpbmRlZWQgdXNlZnVsIGFuZCBtYXkgY29udHJpYnV0ZSBhcyB3ZWxsLg0K DQo+DQo+QXMgZm9yIHRoZSBjb25mbGljdCByZXNvbHV0aW9uIGl0c2VsZiwgaXQgaXMgdmVyeSBo YXJkIHRvIGFjaGlldmUgc2luY2UgdGhlDQo+c3lzdGVtIG5lZWRzIHRvIGhhbmRsZSBkaWZmZXJl bnQgdHlwZXMgb2YgZmlsZS4gR29vZ2xlRG9jcyBwZXJmb3JtcyB3ZWxsDQo+c2luY2UgaXQgb25s eSBmb2N1c2VzIG9uIHRoZSBkb2N1bWVudHMuIEJ1dCBmb3IgYSBzdG9yYWdlIHNlcnZpY2UsIHdl IGRvbid0DQo+a25vdyB3aGF0IGVsc2UgdHlwZXMgb2YgZmlsZSB3aWxsIGJlIHN0b3JlZC4gQSBw b3B1bGFyIHdheSBJJ3ZlIHNlZW4gaXMNCj5qdXN0IHRvIGtlZXAgYWxsIHRoZSBjb25mbGljdGVk IHZlcnNpb25zIChuYW1lZCBieSBkaWZmZXJlbnQgcGVlcnMpIGluIHRoZQ0KPnN0b3JhZ2UuDQoN CkkgYWdyZWUhIFRoZSB0YXJnZXQgb2YgSVNTLCBJIHRoaW5rLCBzaG91bGQgYWxzbyBjb25zaWRl ciBkaWZmZXJlbnQgdHlwZSBvZiBmaWxlczogZG9jdW1lbnRzLCB2aWRlbywgYXVkaW8sIGRhdGFi YXNlcywgZXRjLg0KSG93IHRvIGRvIHRoZSBzeW5jIGFtb25nIHRoZW0gaXMgdmVyeSBjaGFsbGVu Z2luZyBhbmQgc2lnbmlmaWNhbnQuDQoNCg0KPg0KPj4NCj4+DQo+PiAtLQ0KPj4gU2VudCBmcm9t IFdoaXRlb3V0IE1haWwgLSBodHRwczovL3doaXRlb3V0LmlvDQo+Pg0KPj4gTXkgUEdQIGtleTog aHR0cHM6Ly9rZXlzLndoaXRlb3V0LmlvL21lbGxvbkBmdWd1ZS5jb20NCj4+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gU3RvcmFnZXN5bmMg bWFpbGluZyBsaXN0DQo+PiBTdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPj4NCj4+DQo+ From nobody Mon Dec 7 04:33:30 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019391ACD5E for ; Mon, 7 Dec 2015 04:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jjGoeqNVYev for ; Mon, 7 Dec 2015 04:33:26 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440A61ACD05 for ; Mon, 7 Dec 2015 04:33:25 -0800 (PST) Received: (qmail 7040 invoked from network); 7 Dec 2015 12:33:22 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 7 Dec 2015 12:33:22 -0000 Date: Mon, 7 Dec 2015 13:33:20 +0100 From: Markus Unterwaditzer To: Linhui Sun Message-ID: <20151207123320.GA2748@localhost.localdomain> References: <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <20151207012253.GA10858@localhost.localdomain> <1449453960221-fd85c35a-83d0a351-b60f3237@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1449453960221-fd85c35a-83d0a351-b60f3237@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 12:33:29 -0000 > > That works, but do you think this could make the things complicated? It > > sounds like different situations have different mechanisms. Why not just > > make the metadata exchanged, any disadvantage for doing that? > > > I don't know what that means. > The question is why you just keep the metadata locally at client side but not > exchange the metadata between client and server to make both of them (both > peers) have the latest metadata store in time. I think we have a misunderstanding here. We have a server storage that has an etag for each file. We have a client storage that has an etag for each file. The sync client accesses those *and* a "status" file that contains a list of all files + etags for *both* sides, as they were after the previous sync. This is similar to the algorithm described in http://blog.ezyang.com/2012/08/how-offlineimap-works/, except that one doesn't deal with files being modified. As said, this warrants a longer blogpost, but I don't have the time to write one now. > > > > > > > > > > > > > > > > > > > > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote: > > > > > > On 周一, 12月 7, 2015 at 01:36, Markus Unterwaditzer < > > > markus@unterwaditzer.net> > > > > > > wrote: > > > > > > > IMO, etag is designed for client side cache. A typical usage: if > > > the file > > > > > > > on the server has no actual change, the client will use the cache > > > and the > > > > > > > server does not need to send the file content again. While for a > > > storage > > > > > > > service, we also need some some similar mechanism at server side. > > > In this > > > > > > > way, the client do not need to upload unchanged content to the > > > server. > > > > > > > > > > > > There is no "true-and-only" usecase for etags, and no, you do not > > > need > > > > > anything > > > > > > more than etags for synchronization. Using a additional "metadata" > > > file, the > > > > > > client can cheaply determine whether local content changed and > > > whether > > > > server > > > > > > content changed, and that's all that is required for (in this case) > > > file > > > > > > synchronization. Sync conflicts are a different story, and the > > > solution to > > > > > that > > > > > > heavily depends on the kind of data you're syncing. I'm a little bit > > > > confused > > > > > here: if I have a metadata file, why do I still need > > > > > > the etag? The metadata file should contain something equivalent to > > > the etag. > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Sent from my phone. Please excuse my brevity. > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Storagesync mailing list > > > > > > > > Storagesync@ietf.org > > > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync > [https://www.ietf.org/mailman/listinfo/storagesync] > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Storagesync mailing list > > > > > > > Storagesync@ietf.org > > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync > [https://www.ietf.org/mailman/listinfo/storagesync] > > > > > > > > > > > _______________________________________________ > > > > > > Storagesync mailing list > > > > > > Storagesync@ietf.org > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync > [https://www.ietf.org/mailman/listinfo/storagesync] > > > > > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync > [https://www.ietf.org/mailman/listinfo/storagesync] From nobody Mon Dec 7 04:34:07 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F411ACD88 for ; Mon, 7 Dec 2015 04:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ond01soPmTqQ for ; Mon, 7 Dec 2015 04:34:05 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A362B1ACD86 for ; Mon, 7 Dec 2015 04:34:04 -0800 (PST) Received: (qmail 9076 invoked from network); 7 Dec 2015 12:34:02 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 7 Dec 2015 12:34:02 -0000 Date: Mon, 7 Dec 2015 13:34:00 +0100 From: Markus Unterwaditzer To: Fei Song Message-ID: <20151207123359.GA9854@localhost.localdomain> References: <2015120710380820341179@bjtu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2015120710380820341179@bjtu.edu.cn> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 12:34:06 -0000 Hello Fei, see my response to Lihui Sun. On Mon, Dec 07, 2015 at 10:38:08AM +0800, Fei Song wrote: > Hi Markus, > > So, in remoteStorage, what should be stored at the both client and server side? > Etags or metadata or metadata history or other things? > based on the draft, it seems that only Etag is enough, but the context in this mailing list confused me... > > > > > Fei Song > > From: Markus Unterwaditzer > Date: 2015-12-07 05:54 > To: Ted Lemon > CC: storagesync > Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 > Etags are *much* simpler to implement on the server side than the WebDAV sync > protocol because they do not require the server to keep sync tokens and > metadata history. Note that the server has to keep metadata of *deleted* files > to correctly implement WebDAV's sync protocol. Etags are less efficient in > terms of network usage of course, but that's the tradeoff to be made. > > I don't know what you mean with the last sentence. > > On Sun, Dec 06, 2015 at 06:26:54PM +0000, Ted Lemon wrote: > > Sunday, Dec 6, 2015 12:39 PM Markus Unterwaditzer wrote: > > > What do you mean by "it"? ETags are simpler to implement than the above RFC, > > > and ETags are also required in WebDAV. > > > > Etags are not really much simpler than a metadata versioning sync protocol, and they are a lot less efficient. Having to fetch the whole directory for every directory that contains a change is expensive, both for the server and the client, unless changes are infrequent. And because the server is the sole source of truth, it's a lot more fragile. > > > > > > -- > > Sent from Whiteout Mail - https://whiteout.io > > > > My PGP key: https://keys.whiteout.io/mellon@fugue.com > > > > > _______________________________________________ > > Storagesync mailing list > > Storagesync@ietf.org > > https://www.ietf.org/mailman/listinfo/storagesync > > > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync From nobody Mon Dec 7 04:36:32 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED61ACDC2 for ; Mon, 7 Dec 2015 04:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zffKMOi1HGad for ; Mon, 7 Dec 2015 04:36:29 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF071ACDC4 for ; Mon, 7 Dec 2015 04:36:28 -0800 (PST) Received: (qmail 18106 invoked from network); 7 Dec 2015 12:36:26 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 7 Dec 2015 12:36:26 -0000 Date: Mon, 7 Dec 2015 13:36:23 +0100 From: Markus Unterwaditzer To: Linhui Sun Message-ID: <20151207123623.GA10831@localhost.localdomain> References: <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <20151207012253.GA10858@localhost.localdomain> <1449453960221-fd85c35a-83d0a351-b60f3237@gmail.com> <20151207123320.GA2748@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20151207123320.GA2748@localhost.localdomain> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: storagesync , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 12:36:30 -0000 Note that this is not specific to remoteStorage. This is how WebDAV sync clients work in practice (not via the sync protocol, which is not popular enough), it is how remoteStorage sync clients work in practice. At least in terms of the kind of data they access from server and client, the exact algorithm may be different. On Mon, Dec 07, 2015 at 01:33:20PM +0100, Markus Unterwaditzer wrote: > > > That works, but do you think this could make the things complicated? It > > > sounds like different situations have different mechanisms. Why not just > > > make the metadata exchanged, any disadvantage for doing that? > > > > > I don't know what that means. > > > The question is why you just keep the metadata locally at client side but not > > exchange the metadata between client and server to make both of them (both > > peers) have the latest metadata store in time. > > I think we have a misunderstanding here. > > We have a server storage that has an etag for each file. We have a client > storage that has an etag for each file. > > The sync client accesses those *and* a "status" file that contains a list of > all files + etags for *both* sides, as they were after the previous sync. This > is similar to the algorithm described in > http://blog.ezyang.com/2012/08/how-offlineimap-works/, except that one doesn't > deal with files being modified. As said, this warrants a longer blogpost, but I > don't have the time to write one now. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote: > > > > > > > On 周一, 12月 7, 2015 at 01:36, Markus Unterwaditzer < > > > > markus@unterwaditzer.net> > > > > > > > wrote: > > > > > > > > IMO, etag is designed for client side cache. A typical usage: if > > > > the file > > > > > > > > on the server has no actual change, the client will use the cache > > > > and the > > > > > > > > server does not need to send the file content again. While for a > > > > storage > > > > > > > > service, we also need some some similar mechanism at server side. > > > > In this > > > > > > > > way, the client do not need to upload unchanged content to the > > > > server. > > > > > > > > > > > > > > There is no "true-and-only" usecase for etags, and no, you do not > > > > need > > > > > > anything > > > > > > > more than etags for synchronization. Using a additional "metadata" > > > > file, the > > > > > > > client can cheaply determine whether local content changed and > > > > whether > > > > > server > > > > > > > content changed, and that's all that is required for (in this case) > > > > file > > > > > > > synchronization. Sync conflicts are a different story, and the > > > > solution to > > > > > > that > > > > > > > heavily depends on the kind of data you're syncing. I'm a little bit > > > > > confused > > > > > > here: if I have a metadata file, why do I still need > > > > > > > the etag? The metadata file should contain something equivalent to > > > > the etag. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Sent from my phone. Please excuse my brevity. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Storagesync mailing list > > > > > > > > > Storagesync@ietf.org > > > > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync > > [https://www.ietf.org/mailman/listinfo/storagesync] > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Storagesync mailing list > > > > > > > > Storagesync@ietf.org > > > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync > > [https://www.ietf.org/mailman/listinfo/storagesync] > > > > > > > > > > > > > _______________________________________________ > > > > > > > Storagesync mailing list > > > > > > > Storagesync@ietf.org > > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync > > [https://www.ietf.org/mailman/listinfo/storagesync] > > > > > > > > > _______________________________________________ > > > Storagesync mailing list > > > Storagesync@ietf.org > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync > > [https://www.ietf.org/mailman/listinfo/storagesync] From nobody Mon Dec 7 09:57:59 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C43F1AD2C0 for ; Mon, 7 Dec 2015 09:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-6Ezw7fsCjb for ; Mon, 7 Dec 2015 09:57:46 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 8928F1AD272 for ; Mon, 7 Dec 2015 09:57:45 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14495110621180.03891570772975683" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> Date: Mon, 07 Dec 2015 17:57:42 +0000 Message-Id: <1449511062426-94cdee34-064ef498-327458b6@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 17:57:48 -0000 ------sinikael-?=_1-14495110621180.03891570772975683 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Monday, Dec 7, 2015 1:45 AM Linhui Sun wrote: > 2015-12-07 11:40 GMT+08:00 Ted Lemon : >> I think C is the only right answer. We want conflict resolution to be >> automatic whenever possible, but we do want to do conflict resolution, = and >> not just wipe out changes, because those changes may contain real work = that >> the user on client A did. > Do you mean you want the conflict resolution to be performed every = time=3F If > so, I think this might be a little bit unnecessary since a version = conflict > is not very frequently happened (especially for some personal users). = The > case you mentioned should definitely be resolved and such = offline-to-online > switch could be treated as concurrent conflict in my view. It really depends on the use case. > But a more frequent case is that people update their file just to = replace > the previous one, even though there are multiple people working on the = same > file. In this case, replacing file according to modification time seems > reasonable. So the key point is how to justify which two/more versions > should trigger the conflict resolution to avoid wiping out real work. This use case is a common use case for folders that are used informally as = a way to transfer files between users. Typically each version of the file= actually has some kind of version in the filename -- e.g., =22SoW = 2015/11/1 10am Ted=22 and we just expect the users to manage versions. In= this use model, you definitely don't need to do anything fancy. However, this is a really broken use model, which exists because the tools = don't work well enough to do something sensible. They don't allow you to = track versions, they don't allow multiple committers, and they don't have a= mechanism for resolving conflicts when two people change the same version = of the file and try to upload the change. > As for the conflict resolution itself, it is very hard to achieve since = the > system needs to handle different types of file. GoogleDocs performs well > since it only focuses on the documents. But for a storage service, we = don't > know what else types of file will be stored. A popular way I've seen is > just to keep all the conflicted versions (named by different peers) in = the > storage. I think this is a valid conservative way of approaching the problem. But = what makes sense to me is that the sync service be able to identify = conflicts, and that there be a conflict resolution process at a layer above= the sync service. The conflict resolution process could do something = trivial like resolving the conflict by making a new file with the same name= plus a well-understood notation like =22conflict Ted/Sun 15/11/7=22.=20 This would be similar to what people would do if there were no conflict = resolution layer. But if you have a file type for which there is already = an automatic conflict resolution process, then the conflict resolution = process can just do that resolution. There's no reason to pick a = one-size-fits-all approach to this problem. What matters is the ability = to know that a conflict has occurred based on the versioning information in= the metadata. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14495110621180.03891570772975683 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZciWCRAMw8Nu0HeKywAA1P8IANu1Jtt1EjMzjg0d5yhr yaz6y0oA9tyZcyvigYHfp7WPY35kdO9ebkXRB+AHurikp0FFNeXiZAul5tLa d4NiIvno+oVNQsb6QTYUsK9rmQNT76ZToI5fKXRdhWe8DAhcCIoN5/gASol7 nSkPt+DNoMMb9X76KcnfFtdyBa8btpCj7w5a1zAzj7WsVk5PnDHQNgSr2Fnr HJsiYjJuLNaoEztB2c24pMLbZajwKPUeckrcNeNgmvwsHAVNcpX3gj4eBIJO ZcARhHtp5zOS1NRiycEqPQirwk1OseiQfLerJD7AqdFLhh0oaVc5sxoQS7s2 cdwzzuO0HoPly6+hM2akCLk= =hK+c -----END PGP SIGNATURE----- ------sinikael-?=_1-14495110621180.03891570772975683-- From nobody Mon Dec 7 16:24:58 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C2E1A894B for ; Mon, 7 Dec 2015 16:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXW08eNlmCEU for ; Mon, 7 Dec 2015 16:24:55 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 813851A8946 for ; Mon, 7 Dec 2015 16:24:53 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygD3WmjfI2ZWCgAAAA--.0S2; Tue, 08 Dec 2015 08:27:11 +0800 (CST) Date: Tue, 8 Dec 2015 08:24:29 +0800 From: "Fei Song" To: "Markus Unterwaditzer" References: <2015120710380820341179@bjtu.edu.cn>, <20151207123359.GA9854@localhost.localdomain> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120808242929692497@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygD3WmjfI2ZWCgAAAA--.0S2 X-Coremail-Antispam: 1UD129KBjvJXoWxurWUWr1xKFyxKr1DKryxAFb_yoW5Gw1kpr yfJ3WrGF4DJr4fZw4qvr12kw10yryDJ3y7Xws8tw13t3s0yFyYgF18Kr1rur9rXrW5Gr1U tr1Ygw47Gw4DZF7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_twCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU4l 19UUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 00:24:56 -0000 SGkgTWFya3VzLA0KDQpUaGFua3MuIG5vdyBJIGNhbiByb3VnaGx5IHVuZGVyc3RhbmQgd2hhdCBp cyBpbnNpZGUgdGhlIHJlbW90ZVN0b3JhZ2Ugb3Igb3RoZXIgc2ltaWxhciBzY2hlbWVzLg0KSXQg d291bGQgYmUgZ3JlYXQgaWYgd2UgY2FuIHNlZSBtb3JlIGRldGFpbHMgd2hlbiB5b3UgaGF2ZSB0 aW1lIDopIA0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5IZWxsbyBGZWksIHNlZSBteSBy ZXNwb25zZSB0byBMaWh1aSBTdW4uDQo+DQo+T24gTW9uLCBEZWMgMDcsIDIwMTUgYXQgMTA6Mzg6 MDhBTSArMDgwMCwgRmVpIFNvbmcgd3JvdGU6DQo+PiBIaSBNYXJrdXMsDQo+PiANCj4+IFNvLCBp biByZW1vdGVTdG9yYWdlLCB3aGF0IHNob3VsZCBiZSBzdG9yZWQgYXQgdGhlIGJvdGggY2xpZW50 IGFuZCBzZXJ2ZXIgc2lkZT8NCj4+IEV0YWdzIG9yIG1ldGFkYXRhIG9yIG1ldGFkYXRhIGhpc3Rv cnkgb3Igb3RoZXIgdGhpbmdzPw0KPj4gYmFzZWQgb24gdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0 IG9ubHkgRXRhZyBpcyBlbm91Z2gsIGJ1dCB0aGUgY29udGV4dCBpbiB0aGlzIG1haWxpbmcgbGlz dCBjb25mdXNlZCBtZS4uLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBGZWkgU29uZw0KPj4gDQo+ PiBGcm9tOiBNYXJrdXMgVW50ZXJ3YWRpdHplcg0KPj4gRGF0ZTogMjAxNS0xMi0wNyAwNTo1NA0K Pj4gVG86IFRlZCBMZW1vbg0KPj4gQ0M6IHN0b3JhZ2VzeW5jDQo+PiBTdWJqZWN0OiBSZTogW1N0 b3JhZ2VzeW5jXSBTdG9yYWdlc3luYyBEaWdlc3QsIFZvbCA1LCBJc3N1ZSAxDQo+PiBFdGFncyBh cmUgKm11Y2gqIHNpbXBsZXIgdG8gaW1wbGVtZW50IG9uIHRoZSBzZXJ2ZXIgc2lkZSB0aGFuIHRo ZSBXZWJEQVYgc3luYw0KPj4gcHJvdG9jb2wgYmVjYXVzZSB0aGV5IGRvIG5vdCByZXF1aXJlIHRo ZSBzZXJ2ZXIgdG8ga2VlcCBzeW5jIHRva2VucyBhbmQNCj4+IG1ldGFkYXRhIGhpc3RvcnkuIE5v dGUgdGhhdCB0aGUgc2VydmVyIGhhcyB0byBrZWVwIG1ldGFkYXRhIG9mICpkZWxldGVkKiBmaWxl cw0KPj4gdG8gY29ycmVjdGx5IGltcGxlbWVudCBXZWJEQVYncyBzeW5jIHByb3RvY29sLiBFdGFn cyBhcmUgbGVzcyBlZmZpY2llbnQgaW4NCj4+IHRlcm1zIG9mIG5ldHdvcmsgdXNhZ2Ugb2YgY291 cnNlLCBidXQgdGhhdCdzIHRoZSB0cmFkZW9mZiB0byBiZSBtYWRlLg0KPj4gDQo+PiBJIGRvbid0 IGtub3cgd2hhdCB5b3UgbWVhbiB3aXRoIHRoZSBsYXN0IHNlbnRlbmNlLg0KPj4gDQo+PiBPbiBT dW4sIERlYyAwNiwgMjAxNSBhdCAwNjoyNjo1NFBNICswMDAwLCBUZWQgTGVtb24gd3JvdGU6DQo+ PiA+IFN1bmRheSwgRGVjIDYsIDIwMTUgMTI6MzkgUE0gTWFya3VzIFVudGVyd2FkaXR6ZXIgd3Jv dGU6DQo+PiA+ID4gV2hhdCBkbyB5b3UgbWVhbiBieSAiaXQiPyBFVGFncyBhcmUgc2ltcGxlciB0 byBpbXBsZW1lbnQgdGhhbiB0aGUgYWJvdmUgUkZDLA0KPj4gPiA+IGFuZCBFVGFncyBhcmUgYWxz byByZXF1aXJlZCBpbiBXZWJEQVYuDQo+PiA+IA0KPj4gPiBFdGFncyBhcmUgbm90IHJlYWxseSBt dWNoIHNpbXBsZXIgdGhhbiBhIG1ldGFkYXRhIHZlcnNpb25pbmcgc3luYyBwcm90b2NvbCwgYW5k IHRoZXkgYXJlIGEgbG90IGxlc3MgZWZmaWNpZW50LiAgIEhhdmluZyB0byBmZXRjaCB0aGUgd2hv bGUgZGlyZWN0b3J5IGZvciBldmVyeSBkaXJlY3RvcnkgdGhhdCBjb250YWlucyBhIGNoYW5nZSBp cyBleHBlbnNpdmUsIGJvdGggZm9yIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQsIHVubGVzcyBj aGFuZ2VzIGFyZSBpbmZyZXF1ZW50LiAgIEFuZCBiZWNhdXNlIHRoZSBzZXJ2ZXIgaXMgdGhlIHNv bGUgc291cmNlIG9mIHRydXRoLCBpdCdzIGEgbG90IG1vcmUgZnJhZ2lsZS4NCj4+ID4gDQo+PiA+ IA0KPj4gPiAtLQ0KPj4gPiBTZW50IGZyb20gV2hpdGVvdXQgTWFpbCAtIGh0dHBzOi8vd2hpdGVv dXQuaW8NCj4+ID4gDQo+PiA+IE15IFBHUCBrZXk6IGh0dHBzOi8va2V5cy53aGl0ZW91dC5pby9t ZWxsb25AZnVndWUuY29tDQo+PiANCj4+IA0KPj4gDQo+PiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlz dA0KPj4gPiBTdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBTdG9yYWdlc3lu YyBtYWlsaW5nIGxpc3QNCj4+IFN0b3JhZ2VzeW5jQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+DQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gU3RvcmFnZXN5bmMgbWFpbGlu ZyBsaXN0DQo+PiBTdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+U3Rv cmFnZXN5bmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0b3JhZ2VzeW5j From nobody Mon Dec 7 20:46:40 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3981A8754 for ; Mon, 7 Dec 2015 20:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.089 X-Spam-Level: **** X-Spam-Status: No, score=4.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 284Qf-OzKaXi for ; Mon, 7 Dec 2015 20:46:36 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4E69A1A8741 for ; Mon, 7 Dec 2015 20:46:33 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygDHz_s0YWZWacIHAA--.1204S2; Tue, 08 Dec 2015 12:48:53 +0800 (CST) Date: Tue, 8 Dec 2015 12:46:02 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015120812455826565698@bjtu.edu.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart824166633356_=----" X-CM-TRANSID: d55wygDHz_s0YWZWacIHAA--.1204S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tFy7WryDJr4xuFWDCF47twb_yoW5Jry3pF yxJws8Kayqq3yaqrWkWF4I9r40qFn3Gw43tFsxGw47Arn0gas29F1IvF4F9FZ7JryUZw1q qr1Yvas8CF1DZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmEb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2x7xS6r1j6r4UMc02F40E57IF 67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F40E42I26xC2a48xMc02F40Ex7 xS67I2xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE 14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k042 43AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6r45MxAIw28IcxkI7VAK I48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7 AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE 2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAY jxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU5Wmh7UUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed (html) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 04:46:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart824166633356_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24uIFBsZWFzZSBlbWFpbCBtZSBpZiBhbnl0aGluZyBp cyBtaXNzaW5nOg0KIA0KMS4gICAgICAgICBUaGUgZGVzaWduIHRhcmdldHMgb2YgV2ViREFWLCBy c3luYyBhbmQgb3RoZXIgZXhpc3RpbmcgYXBwcm9hY2hlcz8NCjIuICAgICAgICAgVGhlIHBvdGVu dGlhbCB1c2UgY2FzZXMgb2YgSVNTLCBzdWNoIGFzIGNsaWVudC9zZXJ2ZXIsIGdpdC1saWtlIHBh dHRlcm4sIHN2biwgZXRjLg0KMy4gICAgICAgICBUaGUgZWZmaWNpZW5jeSBpbXByb3ZlbWVudHMg bWlnaHQgYmUgdGhlIHNlY29uZCBnb2FsIGZvciBzdGFuZGFyZGl6aW5nIElTUyBwcm90b2NvbA0K NC4gICAgICAgICBDT1JTIGhlYWRlcnMgb24gc3RvcmFnZSBzeW5jIEFQSXMNCjUuICAgICAgICAg V2hhdCBpcyBuZWVkZWQgZm9yIHRoZSBJU1M6IGEgc3luYyBwcm90b2NvbCBvciBhIGdlbmVyYWxp emVkIEFQSQ0KNi4gICAgICAgICByZW1vdGVTdG9yYWdlIGRyYWZ0IGRpc2N1c3Npb24NCmEpICAg ICAgICAgcmVsYXRpb25zaGlwIHZzIFdlYkRBVg0KYikgICAgICAgICBNT1ZFIGFjdGlvbiAoc3lu Y2hyb25pemF0aW9uKSBzaG91bGQgYmUgYWRkZWQgb3Igbm90DQpjKSAgICAgICAgIEJlc2lkZSB3 ZWIgYnJvd3NlciwgZGVza3RvcCBhcHBzIChieSBoYWNraW5nIHdheSkNCmQpICAgICAgICAgY29t aWNzIG9mIG5ldyBzdGFuZGFyZA0KZSkgICAgICAgICBldGFnIGlzc3Vlcw0KICAgICAgICAgICAg ICAgICAgICAgICAgIGkuICAgICAgICAgICAgICBpcyBtYWlubHkgZm9yIGlkZW50aWZ5aW5nIHdo ZXRoZXIgYSBkb2N1bWVudCBpcyBjaGFuZ2VkIG9yIG5vdA0KICAgICAgICAgICAgICAgICAgICAg ICBpaS4gICAgICAgICAgICAgIGlzIGVhc3kgdG8gaW1wbGVtZW50IHRoYW4gdGhhdCBvZiBXZWJE QVYgc3luYyBwcm90b2NvbCBvciBub3QNCiAgICAgICAgICAgICAgICAgICAgICBpaWkuICAgICAg ICAgICAgICB0aGUgbWV0YWRhdGEgZmlsZSBjb250YWlucyBhbGwgZXRhZ3MgZm9yIGFsbCBmaWxl cyBhdCBib3RoIGNsaWVudCBhbmQgc2VydmVyIHNpZGUgb3Igbm90DQpmKSAgICAgICAgICB0aGUg ZGlzdHJpYnV0ZWQgcGVlciBtb2RlbCAobm8gc2VydmVyKSBhbmQgQy9TIG1vZGUNCmcpICAgICAg ICAgYSBmYW5jeSBleGFtcGxlICh3aXRoIHBpY3MpIG9mIE9mZmxpbmVJTUFQoa9zIHN5bmMgcHJv Y2VzcyBpbiBmb2xsb3dpbmcgVVJMDQpodHRwOi8vYmxvZy5lenlhbmcuY29tLzIwMTIvMDgvaG93 LW9mZmxpbmVpbWFwLXdvcmtzLw0KNy4gICAgICAgICBHaXRIdWIgKGluc3RlYWQgb2YgZW1haWwg bWVzc2FnZXMpIGhhcyBiZWVuIGNyZWF0ZWQ6DQpodHRwczovL2dpdGh1Yi5jb20vbGFia29kZS9J bnRlcm5ldC1TdG9yYWdlLVN5bmMNCmEpICAgICAgICAgV2hhdCBpcyB0aGUgdG9waWM/IA0KICAg ICAgICAgICAgICAgICAgICAgICAgIGkuICAgICAgICAgICAgICBXaGV0aGVyIGl0IGlzIHN1aXRh YmxlIHRvIGJ1aWxkIG9uIFdlYkRBVg0KICAgICAgICAgICAgICAgICAgICAgICBpaS4gICAgICAg ICAgICAgIFdlYkRBViB2cyByZW1vdGVTdG9yYWdlDQogICAgICAgICAgICAgICAgICAgICAgaWlp LiAgICAgICAgICAgICAgQWR2YW50YWdlcyB2cyBkaXNhZHZhbnRhZ2VzIG9mIFdlYkRBVg0KOC4g ICAgICAgICBNZXRhZGF0YSBhbmQgZGF0YSBzZXBhcmF0aW9uIHNjaGVtZSBhbmQgcGxhdGZvcm0g Zm9yIHN5bmNocm9uaXphdGlvbg0KYSkgICAgICAgICBvd25DbG91ZCB3aGVuIGNvbmZpZ3VyZWQg dG8gdXNlIGFuIE9iamVjdCBTdG9yYWdlIGFzIHRoZSBQcmltYXJ5IFVzZXIgU3RvcmFnZS4gKE1l dGFkYXRhIGlzIGhhbmRsZWQgYnkgYSBNeVNRTCBkYXRhYmFzZSkNCmIpICAgICAgICAgQ0VSTiBF T1MgU3RvcmFnZSBTeXN0ZW0uIChNZXRhZGF0YSBpcyBoYW5kbGVkIGluIGhpZ2ggcGVyZm9ybWFu Y2UgaW4tbWVtb3J5IHN0cnVjdHVyZXMpLg0KYykgICAgICAgICBEcm9wQm94LiAoQXMgZmFyIGFz IEkga25vdyBpdCB1c2VzIFMzIGJlaGluZC4gRm9yIG1ldGFkYXRhIGl0IGlzIHVua25vd24sIGJ1 dCBwcm9iYWJseSBub3Qgb24gUzMpLiANClBhcGVyIGZvciBhbmFseXppbmcgRHJvcEJveDoNCmh0 dHA6Ly9hbm5hc3Blcm90dG8ub3JnL3BhcGVycy8yMDEyL2ltYzE0MC1kcmFnby5wZGYNCmQpICAg ICAgICAgQ2xhd0lPIHdpbGwgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIGFwcHJvYWNo IGluIHRoZSBuZXh0IHBoYXNlIHVzaW5nIFN3aWZ0Lg0KOS4gICAgICAgICBXaGV0aGVyIHdlIHNo b3VsZCBrZWVwIG1ldGFkYXRhIGhpc3Rvcnkgb3IgbW9kaWZpY2F0aW9uIGhpc3Rvcnkgb3IgYWN0 aW9uIGhpc3RvcnkgYXQgc2VydmVyIHNpZGUgKG9yIG90aGVyIHBsYWNlcykNCjEwLiAgICAgSG93 IHRvIGhhbmRsZSB0aGUgobBjb25mbGljdCByZXNvbHV0aW9uobEgaXNzdWVzDQphKSAgICAgICAg IEEgZ29vZCBkZW1vbnN0cmF0aW9uIG9mIHRoaXMgaXNzdWUgd2FzIGdpdmVuIGluIGRldGFpbHMg KEZpbGUgRiwgQ2xpZW50IEEsIENsaWVudCBCLCBldGMuKQ0KYikgICAgICAgICBTaG91bGQgaXQg YmUgYSBsYXllciBhYm92ZSBzeW5jaW5nDQpjKSAgICAgICAgIFNob3VsZCBpdCBkZXBlbmQgb24g dGhlIHVzZSBjYXNlDQpkKSAgICAgICAgIFNob3VsZCBpdCBiZSBhIG9uZS1zaXplLWZpdHMtYWxs IGFwcHJvYWNoDQogDQogDQpTb21lIHJlbGF0ZWQgb3JnYW5pemF0aW9ucywgZXZlbnRzLCBwcm9q ZWN0cywgZXRjLjogDQpHRUFOVCBjb21tdW5pdHksIE9wZW5DbG91ZE1lc2gsIG93bkNsb3VkLCBD UzMsIHJlbW90ZVN0b3JhZ2UsIENsYXdJTywgY3Jvc3NjbG91ZCwgRHJvcGJveCwgQ0VSTiBFT1Mg U3RvcmFnZSBTeXN0ZW0sdG8gYmUgYWRkZWShrQ== ------=_001_NextPart824166633356_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Here is the latest version. Please email me if anything is=20 missing:

 

1.      =   =20 The = design=20 targets of WebDAV, rsync and other existing approaches?

2.      =   =20 The = potential=20 use cases of ISS, such as client/server, git-like pattern, svn,=20 etc.

3.      =   =20 The = efficiency=20 improvements might be the second goal for standardizing ISS=20 protocol

4.      =   =20 CORS= headers on=20 storage sync APIs

5.      =   =20 What= is needed=20 for the ISS: a sync protocol or a generalized API

6.      =   =20 remo= teStorage=20 draft discussion

a)      =   =20 rela= tionship vs=20 WebDAV

b)      =   =20 MOVE= action=20 (synchronization) should be added or not

c)      =   =20 Besi= de web=20 browser, desktop apps (by hacking way)

d)      =   =20 comi= cs of new=20 standard

e)      =   =20 etag= =20 issues

      =             &n= bsp;     =20 i.      =        =20 is m= ainly for=20 identifying whether a document is changed or not

      =             &n= bsp;   =20 ii.      =        =20 is e= asy to=20 implement than that of WebDAV sync protocol or not

      =             &n= bsp;  =20 iii.      =        =20 the = metadata=20 file contains all etags for all files at both client and server side or=20 not

f)      =    =20 the = distributed=20 peer model (no server) and C/S mode

g)      =   =20 a fa= ncy example=20 (with pics) of OfflineIMAP=A1=AFs sync process in following URL

http://blog.ezyang.com/2012/08/how-offlineimap-works/

7.      =   =20 GitH= ub (instead=20 of email messages) has been created:

<= FONT=20 size=3D3=20 face=3DCalibri>https://github.com/labkode/Internet-Storage-Sync

a)      =   =20 What= is the=20 topic?

      =             &n= bsp;     =20 i.      =        =20 Whet= her it is=20 suitable to build on WebDAV

      =             &n= bsp;   =20 ii.      =        =20 WebD= AV vs=20 remoteStorage

      =             &n= bsp;  =20 iii.      =        =20 Adva= ntages vs=20 disadvantages of WebDAV

8.      =   =20 Meta= data and=20 data separation scheme and platform for synchronization

a)      =   =20 ownC= loud when=20 configured to use an Object Storage as the Primary User Storage. (Metadata= is=20 handled by a MySQL database)

b)      =   =20 CERN= EOS Storage=20 System. (Metadata is handled in high performance in-memory=20 structures).

c)      =   =20 Drop= Box. (As far=20 as I know it uses S3 behind. For metadata it is unknown, but probably not = on=20 S3).

= Paper for=20 analyzing DropBox:

<= FONT=20 size=3D3=20 face=3DCalibri>http://annasperotto.org/papers/2012/imc140-drago.pdf=

d)      =   =20 Claw= IO will have=20 an implementation of this approach in the next phase using=20 Swift.

9.      =   =20 Whet= her we=20 should keep metadata history or modification history or action history at = server=20 side (or other places)

10.    =20 How = to handle=20 the =A1=B0conflict resolution=A1=B1 issues

a)      =   =20 A go= od=20 demonstration of this issue was given in details (File F, Client A, Client= B,=20 etc.)

b)      =   =20 Shou= ld it be a=20 layer above syncing

c)      =   =20 Shou= ld it depend=20 on the use case

d)      =   =20 Shou= ld it be a=20 one-size-fits-all approach

 

 

Some related organizations, events, projects, etc.:=20

GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorag= e,=20 ClawIO, crosscloud, Dropbox, CERN EOS Storage System,to be=20 added=A1=AD

 
------=_001_NextPart824166633356_=------ From nobody Mon Dec 7 22:29:39 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D71F1B33AE for ; Mon, 7 Dec 2015 22:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwiTSYsj-d02 for ; Mon, 7 Dec 2015 22:29:32 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0666.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::666]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6B31B33B9 for ; Mon, 7 Dec 2015 22:29:31 -0800 (PST) Received: from VI1PR06CA0061.eurprd06.prod.outlook.com (10.163.160.29) by DBXPR06MB416.eurprd06.prod.outlook.com (10.141.14.154) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 8 Dec 2015 06:29:10 +0000 Received: from AM1FFO11OLC003.protection.gbl (2a01:111:f400:7e00::197) by VI1PR06CA0061.outlook.office365.com (2a01:111:e400:533c::29) with Microsoft SMTP Server (TLS) id 15.1.337.19 via Frontend Transport; Tue, 8 Dec 2015 06:29:10 +0000 Authentication-Results: spf=pass (sender IP is 188.184.36.50) smtp.mailfrom=cern.ch; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=cern.ch; Received-SPF: Pass (protection.outlook.com: domain of cern.ch designates 188.184.36.50 as permitted sender) receiver=protection.outlook.com; client-ip=188.184.36.50; helo=CERNMX11.cern.ch; Received: from CERNMX11.cern.ch (188.184.36.50) by AM1FFO11OLC003.mail.protection.outlook.com (10.174.65.78) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Tue, 8 Dec 2015 06:29:09 +0000 Received: from cernfe02.cern.ch (188.184.36.47) by cernmxgwlb4.cern.ch (188.184.36.50) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Dec 2015 07:29:08 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE02.cern.ch ([fe80::bc89:8f4e:8731:2c47%13]) with mapi id 14.03.0174.001; Tue, 8 Dec 2015 07:29:08 +0100 From: Jakub Moscicki To: fsong Thread-Topic: [Storagesync] Some preliminary investigations on ownCloud Thread-Index: AQHRMYG+wLGLtem8a0ytuPlWJEoYog== Date: Tue, 8 Dec 2015 06:29:08 +0000 Message-ID: <42E30C86-1142-4A20-BC3D-D1B22029247A@cern.ch> References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <03A07C3E-9B3B-4886-9131-2CAF0A7B3F85@cern.ch> <9A7E1A04-8C4A-40BE-933D-6814ACDB135C@cern.ch> <201512021107151258829@bjtu.edu.cn> In-Reply-To: <201512021107151258829@bjtu.edu.cn> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.28.197.96] Content-Type: multipart/alternative; boundary="_000_42E30C8611424A20BC3DD1B22029247Acernch_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11OLC003; 1:nd+FM4uhcx5z3tJwmPNcc2SlcP5an7OYuDoiuYQB627O30oTFrL9DGI9UlhN9m8pYzO/Y2VUH7UVBwABmhxaj0o7WTBO6xxMf/3nitEnOnQw9Ubnl9Mi7FNfuOvVVdLp3lxbD+qHYmssA0TeY+FRsHcOcHTQsTkZbUyUqEnPJAT/kjClgC6twY0bKEU5L+TP/fe/YOdhrl27mTv9/Nhyx8HjSvT/ZcQ6kyvnlaEiNil0DX6BZWmpuxELztZw66gaIbUXBVtrjotgtf4auzMTDMwveh2IxkkmCTvvMeh6NVyfgz/Vlnn66Y4ROx/ISyQGK3Y3wU1POcLzrMniILquI6Nl/IHsHdiSs6l9mOqFWbSeT3mVkRssP8EM79c8txKSD31luspSRCtVA0M9PbhSuBWsi28S3wn2+5e2qi6QD7A= X-Forefront-Antispam-Report: CIP:188.184.36.50; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(2980300002)(438002)(24454002)(53754006)(199003)(189002)(377424004)(74482002)(15975445007)(5003600100002)(82746002)(83716003)(84326002)(6116002)(33656002)(86362001)(16297215004)(102836003)(87936001)(54356999)(19580395003)(16796002)(5250100002)(2171001)(512874002)(66066001)(76176999)(300700001)(19580405001)(586003)(92566002)(53416004)(110136002)(2950100001)(2900100001)(36756003)(106116001)(3846002)(106466001)(26826002)(93886004)(19617315012)(16236675004)(5001970100001)(4001150100001)(6806005)(5004730100002)(11100500001)(5008740100001)(1220700001)(189998001)(1096002)(50986999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR06MB416; H:CERNMX11.cern.ch; FPR:; SPF:Pass; PTR:cernmx11.cern.ch; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB416; 2:MAR55Kh/MvPEiAdy7b+7I6lJdS+qFuKQBsfzWtnYlWusN6UPIcT0/rW1fGCzdCxIPGgl8swNtlTGB4LJcuUb/3eiuJGCL6i9696y/nE8YH4SN5DjsImageZLcW4NSVdXEm21n2KEKgx3H9goA84aJA==; 3:uc+Rvzhf5fmctM+MBdCIDnCN08vcOdQCZZlmQ3QO//ID2d0e21xnOoJNDg8AUDdPT95tXQMTYkiWtjZDSFYCUiqtXZGmY0aGoMpnOKlMTHsHwY+kGX0kdO8StH+ZtJo4Wwp8cdyhwPe4B1H644GxF5FaMhZOXMAKwNJjkso3QWWLqKNTpK9QvPrvcV47qycCVPOZuqvI/i+gM38D3rx2ijkxWdrUbIzi01Vm/ETq5/ciJ6St2Wzaquxk3I0QUeFKN38sWzRSW5N/5LRyiWEY7w==; 25:RUwzB7ZtTgn+wRMgUrWm7LMnTtfYE+X435lDXXx5ahc4W8ShDcUE6tGpVbVXXjylpAwN5DC6Ryz2FN7DdhFIysqU0vwftTH9xZWzU1D0LL9UZx4VCMsvsCNdj2RQTwKL9+SHG4nKCKUvn1GitLq9/Q9aAjDnSXTpEimz4RY+4eUHkCc+yrn2L4cMQDS/jVnm9lN+JkhbbTJIIW5dsE3ZS+ajaYE7TS60PFSjwIioXNqrM+KG1htJpzcoYkf/iXf5aK9XKvc5OZdiPEV569wRyw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DBXPR06MB416; X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB416; 20:idWSjsVX2GQ2q/SktrLcvQ6Vf9ap692JsLAgCphAAUljiUJHmRpieVpW4GOwUvXbzHV5En47F7RY7NtZY0ifCe/x74CbB6KbqKSJZFbELGAtHi9d9fUub5h7Fgo79V8axOk22eidvM1ezqUq3tnZHV54L+XnAEzHCyIwcliWi6NOvz6vD4J4DRfAw8f69OAxMlrrTFbbtRjHjVBVDRFHKbNkjK8Q91svgMdQUzkbPce2keh9Q15uAqE9wWOuei/QEBWh0tLoQX3vGtD9MmnbyE3A+GoxCrV8/1s0eAkCQDSzb/o6wuIPjNJYrFaGi5v/hIt1Kf3spUkrxifRmcgnVg4ITFbGQXy5itnhP1UtrZHRYMYXgfT62OxTWWFvvzhxPHq1f1bZ+g4ZumlseEHCSuoo2sidaHDhZ1iKHSsUUi3GOEXs/QFi4oI5B4XmExUbmIxi4605rDpsNqd24NNIKyJrGiTbNZPBjPoyboiTtCJEWTD14oDLSDcmwrfxNTW8 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(19113083728360)(109460225580195); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:DBXPR06MB416; BCL:0; PCL:0; RULEID:; SRVR:DBXPR06MB416; X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB416; 4:aCs5Gjs8z/wKekGqY2sVo09b9iA0c7gE0ouN4co3dj0AYXTV+FS/sShjpu+/CC/E1304Igc8Rb6sjTbI1OHtIf/lV6FH2JC4aaeFFaQ3lH4g5EWnOHaa8q4eXTc13Gn2OILC2b2ZATx5jl7DtIo4FGiE2pgDvgZ7oGDa+/Cn2OgtPkCabBke5Nc9w6JbP4OTjzD85Ci+SNLRCVDFLJ//VUWQRefkPdxsH4AqC5G/GhhwK+pqCPmC6rTj1Ip60IFpf/RbhLDhqpOHsRTXt8ZsSJM16fn52HYZ+A87KTkHkhc4oJk0xPU4eOmAzwdBxChWyH8PhFf4wjrwBOKO42p1O9kmeFRkmEfFavR9/WKqJaMK1N2ao5GBBiTd4aDOWuf0Se+GwovBJ7op1tlKE2dCalvRPcEAPmy9VMTe43JB+aDAv2aAIBrRLa79MatjHfPg9nKptRwDVHTFJOi2sGlI0Q== X-Forefront-PRVS: 0784C803FD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DBXPR06MB416; 23:PuBZ8mBF7eaYXZaHqExhDrmIsv0x1E9jwB020SgvEw?= =?us-ascii?Q?H2+Uf5HWOfCCl9Jv0iRsYspbGmvJfDL1Wi1lCaYv/cUUsx6c4S5DFrrmAJAZ?= =?us-ascii?Q?dnPr+l84Bgr29/tq5rARPwngP5sQOGXGGYvplLrihRA50HImVXzG16szw4bA?= =?us-ascii?Q?blXFKF0PG2KGS8QPIv5RmzLFyOswDJqQ+1inWd99nhbNBiwDrIeVteN4mnob?= =?us-ascii?Q?TeR2DoXFahgKLJzIWefCCytUjXjKdNqQQyoGzJ07HDTvtt7N8Nyv9sh6Tid4?= =?us-ascii?Q?xwfSjywrqD41IvtD/ujVm4bNjzxTawFD2qFrIebR++K8OUli0p+EWsXLpCKS?= =?us-ascii?Q?Q5QQRvezvZV7ViecsyKGrM4KHCW1TfgG8HBkeF15Rdy+lG1HM3Zv45NOBVEV?= =?us-ascii?Q?XTuffB8tY2Ouy5zOPOPoSGc1kQNwOGK7n+pmA3nNiq1xb8ulOhBqE3+2h36k?= =?us-ascii?Q?ipcf8wkCpwfAqLzQWUYWpsl8tB/4D7tXvPWDwvH3vBWmrsmI6LSoPQ13oTtx?= =?us-ascii?Q?nCxJB4aYJuZpvPmU3mvWcX4BvpAlMETnmeLiCOyc9pfHXIqoTSmTcZPLWxek?= =?us-ascii?Q?Uq9mtinshmYdP7iGDIsIhU3M8Bhz5GwcfKsYJyadEcjjS+momABnPX8OJSx6?= =?us-ascii?Q?Icg4QRswT+Mrr02Sr/LNLMPWlLDMsF3yCNRpEleaI/yYW9QqLQK9QY30MhHO?= =?us-ascii?Q?T7X50yZJFMmfyzYou32jJTuMCaJA0hmFH+PGYKYDpxhpSbiWdFkgTlAX0Cwj?= =?us-ascii?Q?KAB9u/kIPBTHTK0cSzMgX4nRGOirrpaTrwuBExcEv1ZWOE3ItiyJNsq8jDir?= =?us-ascii?Q?fu5LTzYSgYjWfRxzb0DFdzf6/kMROJ+rXqOCzqEXPg0tz2rXp5VXbKGIEfdO?= =?us-ascii?Q?LYtSRgyi4dFrpxtrpRHB3PirXhv4GkRDSMiGxEnolaVbM5MYCTCTcfqJlknI?= =?us-ascii?Q?dIIZD8Vc8pr9X5t+dFUtfDmN11lhpZQ0mvCTyk+8EFWxjDWGxL2mCqlSNvLr?= =?us-ascii?Q?A2Tc3DnnuT1qW9kSoz1k1isymQ2BC/NoWhLJTB/MtlLpZ0m0FDNOjBTzm8op?= =?us-ascii?Q?AUug2NM/fC/P522ztg4GghAMuNUoK9WHKxiNdg3nu8rOVx0XyhFh07t1lLvi?= =?us-ascii?Q?5N9HboYnaweFKV3oiQvUO/egT1vLYS5asUuU7Nle12riJrxM5oeXSb9CaJ+8?= =?us-ascii?Q?eV82KwJyfrmybhmToFN+Mq0lE2YfDzyuzHCjtfRPIQQyi66R+yt1veZ5x8M2?= =?us-ascii?Q?trnYMeu+KP+LfwWZU/IkHZw9m+J7I/Q6eCIDLZRITCijZYgdTkkBza59VLPY?= =?us-ascii?Q?zu0baw15ypQ2feUmiaOI78S0C8n6P+mHgcTIfxyNwyOhfuoQnp9SS9AWpjrv?= =?us-ascii?Q?5TXliFGriTJsuw8DfBhvvhsBnEZEqkHnrD+fjNmX27ILGmTeTG0wp56SwfCl?= =?us-ascii?Q?uW2kXa3A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB416; 5:K8Gl/ot5YK61EVqOfsOwLG3iy4nUaELXh6hPsUcP/IFSn8L327m4Gr7UE8e0AapcVq+OitSGvbSdyt+LmvpbZEzA8QKAGkZqKLayWinbtynoI2oKVbSKuimjsmR8dGW/PIc+uxIJpnOSfwevRn104w==; 24:WFqAgTCYCLYaONy2aGSkt1BLB2mERFR+Bb6R66fPqBGPDG1MYubfOmtMamq7jw0kGC8oKafm9e1U01DHIlspW5a+8rIluznnw2tce7So43s= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2015 06:29:09.7199 (UTC) X-MS-Exchange-CrossTenant-Id: c80d3499-4a40-4a8c-986e-abce017d6b19 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c80d3499-4a40-4a8c-986e-abce017d6b19; Ip=[188.184.36.50]; Helo=[CERNMX11.cern.ch] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR06MB416 Archived-At: Cc: storagesync Subject: Re: [Storagesync] Some preliminary investigations on ownCloud X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 06:29:38 -0000 --_000_42E30C8611424A20BC3DD1B22029247Acernch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkhlcmUgaXMgdGhlIHB1YmxpY2F0aW9uIHNjaGVkdWxlICh3aWxsIGJlIHVwZGF0 ZWQgc29vbiBvbmxpbmU6IGh0dHA6Ly93d3cuam91cm5hbHMuZWxzZXZpZXIuY29tL2Z1dHVyZS1n ZW5lcmF0aW9uLWNvbXB1dGVyLXN5c3RlbXMvY2FsbC1mb3ItcGFwZXJzL3NwZWNpYWwtc2VjdGlv bi1jbG91ZC1zdG9yYWdlLXNlcnZpY2VzLWZpbGUtc3luY2hyb25pemF0aW9uLykuDQoNCkltcG9y dGFudCBEYXRlcw0KDQpTdWJtaXNzaW9uIER1ZSBBcHJpbCAxLCAyMDE2DQoxc3QgUm91bmQgTm90 aWZpY2F0aW9uIEF1Z3VzdCAxLCAyMDE2DQpSZXZpc2lvbiBPY3RvYmVyIDEsIDIwMTYNClB1Ymxp Y2F0aW9uIChleHBlY3RlZCkgTGF0ZSAyMDE2IG9yIEVhcmx5IDIwMTcNCg0KQmVzdCByZWdhcmRz LA0KDQprdWJhDQoNCuKAlA0KDQoNCk9uIDAyIERlYyAyMDE1LCBhdCAwNDowNywgRmVpIFNvbmcg PGZzb25nQGJqdHUuZWR1LmNuPG1haWx0bzpmc29uZ0BianR1LmVkdS5jbj4+IHdyb3RlOg0KDQpI aSBKYWt1YiwNCg0KSSBub3RpY2UgdGhhdCB0aGlzIGlzIGEgIlNwZWNpYWwgU2VjdGlvbiIsDQph bnkgZGVhZGxpbmUgZm9yIGl0PyBvciBpdCB3aWxsIGJlIGF2YWlsYWJsZSBmb3IgYSBsb25nIHRp bWU/DQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQpCVFcsIGhlcmUgaXMgdGhlIHB1Ymxp YyBDRlAgZm9yIEZHQ1M6IGh0dHA6Ly9jczMuZXRoei5jaC9wdWJsaWNhdGlvbnMuaHRtbA0KDQpC ZXN0IHJlZ2FyZHMsDQoNCkpha3ViIE1vc2NpY2tpDQoNCuKAlQ0KDQpPbiAyNiBOb3YgMjAxNSwg YXQgMDQ6MjksIEpha3ViIE1vc2NpY2tpIDxKYWt1Yi5Nb3NjaWNraUBjZXJuLmNoPG1haWx0bzpK YWt1Yi5Nb3NjaWNraUBjZXJuLmNoPjxtYWlsdG86SmFrdWIuTW9zY2lja2lAY2Vybi5jaD4+IHdy b3RlOg0KDQoyMDE1LTExLTI2IDExOjI4IEdNVCswODowMCBGZWkgU29uZyA8ZnNvbmdAYmp0dS5l ZHUuY248bWFpbHRvOmZzb25nQGJqdHUuZWR1LmNuPjxtYWlsdG86ZnNvbmdAYmp0dS5lZHUuY24+ PjoNCkJUVywgQmFzZWQgb24gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgbGFzdCBlbWFpbDoiVGhlIGlu dGVudGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJlbnQgc3Rh dGUgb2YgdXNpbmcgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRv IGJlIGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIgd2UgbmVlZCBuZXcgcHJvdG9jb2xzIg0KDQpU aGUgb3V0Y29tZSBoZS9zaGUgd2FudGVkIG1pZ2h0IGJlIGp1c3QgdGhlIGxpbmtzIGxpa2UgaHR0 cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbCA6KQ0KSW4gYW5vdGhlciB3b3JkLCBJIHRoaW5r IHdoYXQgSSB3YW50IGZpbmFsbHkgbWlnaHQgYmUgYSBkaXNjdXNzaW9uIGFib3V0ICJXaGF0IGlz IG5lZWRlZCBmb3IgdGhlIElTUzogYSBzeW5jIHByb3RvY29sIG9yIGEgZ2VuZXJhbGl6ZWQgQVBJ Ii4gU29ycnkgZm9yIHRoZSBwb29yIGV4cHJlc3Npb24gOiApDQoNCkkgdGhpbmsgdGhpcyBpcyBh IHJlbGV2YW50IHF1ZXN0aW9uIGluZGVlZCAod2VsbCwgYWN0dWFsbHkgYWxzbyBpZiB0aGVyZSBp cyBhbnkgc3RhbmRhcmQgbmVlZGVkIGF0IGFsbCBpbiB0aGUgZmlyc3QgcGxhY2UpLiBCeSB0aGUg Z2VuZXJhbGl6ZWQgQVBJIGRvIHlvdSBtZWFuIGEgSFRUUC1zdHlsZSBBUEkgKGxpa2UgUkVTVCk/ IEluIHRoYXQgY2FzZSB5b3UgbWF5IGNvbnNpZGVyIFdlYkRBViBxdWl0ZSBjbG9zZSBhbmQgdGhl IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgcHJvdG9jb2wgYW5kIHRoZSBBUEkgYmx1cnMgZm9yIHBy YWN0aWNhbCBwdXJwb3Nlcy4NCg0KV2hpbGUgSSBhZ3JlZSB0aGF0IFdlYkRBViBtYXkgaGF2ZSBk aXNhZHZhbnRhZ2VzIHRoZXJlIGlzIGEgZ29vZCBudW1iZXIgb2YgaW5zdGFsbGF0aW9ucyB1c2lu ZyB0aGlzIGFscmVhZHkgaW4gb3VyIGNvbW11bml0eSAocmVzZWFyY2ggbGFicyBtYWlubHkgaW4s IGJ1dCBub3QgbGltaXRlZCB0bywgRXVyb3BlKS4gSSB0aGluayB0aGUgaW50ZXJlc3RpbmcgcG9p bnQgYWJvdXQgV2ViREFWL0hUVFAgaXMgZXh0ZW5zaWJpbGl0eSBhbmQgbWF5YmUgaXQgaXMgd29y dGggaXMgdGhhdCB0aGVzZSBleHRlbnNpb25zIGdvIGJ5IGEg4oCcc3RhbmRhcmTigJ0uIEhvd2V2 ZXIsIHlvdSBzaG91bGQgY29uc2lkZXIgdGhhdCBmb3IgcmVhc29uYWJseSBlZmZpY2llbnQgc3lu YyBzY2VuYXJpbyB0aGUgc2VydmVyIHNob3VsZCBhbHNvIGV4aGliaXQgY2VydGFpbiBiZWhhdmlv dXIuIFRoYXQgaXMsIGluIGNhc2Ugb2Ygb3duY2xvdWQgZm9yIGV4YW1wbGUsIGEgc2VydmVyIHNo b3VsZCBiZSBhYmxlIHRvIGVmZmljaWVudGx5IHByb3BhZ2F0ZSB0aGUgRVRBRyBjaGFuZ2VzIHVw IHRoZSBkaXJlY3RvcnkgdHJlZSAobGlrZSB0aGUgTWVya2xlIFRyZWUpIHNvIHRoYXQgdGhlIGNs aWVudCBtYXkgdXNlIHByb3BmaW5kIGVmZmljaWVudGx5LiBUaGlzIGlzIG5vdCBhIGhhcmQgc3Bl YyByZXF1aXJlbWVudCBidXQgb3RoZXJ3aXNlIHByb3BmaW5kaW5nIHRoZSBlbnRpcmUgcmVtb3Rl IHRyZWUgZWFjaCB0aW1lIHdvdWxkIGJlIGltcHJhY3RpY2FsbHkgaW5lZmZpY2llbnQuIFNvIHRo aXMgcmVhbGx5IGdvZXMgYSBsaXR0bGUgYml0IGJleW9uZCBqdXN0IGFuIEFQSS4NCg0KWW91IHNo b3VsZCBhbHNvIGNvbnNpZGVyIHRoYXQgdGhlIE9wZW5DbG91ZE1lc2ggKHVuZGVyIEdFQU5UIHVt YnJlbGxhKSBpcyBhbiBpbml0aWF0aXZlIHdpdGggdGhlIGludGVudCBpcyB0byBtYWtlIGNyb3Nz LXNlcnZpY2Ugc2hhcmluZyB2ZXJ5IGVhc3kuIFRoZXNlIHNoYXJlcyBtYXkgYWxzbyBiZSBzeW5j aHJvbml6ZWQgYXV0b21hdGljYWxseS4gSSBjdXJyZW50bHkgaGF2ZSBubyBldmlkZW5jZSwgaG93 ZXZlciwgdGhhdCBvdGhlciBzb2Z0d2FyZSBwcm92aWRlcnMgd2l0aCB0aGUgZXhjZXB0aW9uIG9m IG93bmNsb3VkIGFyZSBpbnRlcmVzdGVkIGluIGRldmVsb3Bpbmcgc3VjaCBzdGFuZGFyZC4gSWYg dGhlcmUgaXMgbm8gYm90dG9tIHVwIGludGVyZXN0IGZyb20gdGhlIHVzZXJzIHRoZW4gaXQgd29u 4oCZdCBoYXBwZW4gKGluIG15IG9waW5pb24pLg0KDQpXaXRoIHRoZSBsaW5rIEkgd2FudGVkIHRv IHBvaW50IHlvdSB0byB0aGUgZmFjdCB0aGF0IHdoYXQgeW91IGRpc2N1c3MgaW4gdGhpcyBtYWls aW5nIGxpc3Qgd2lsbCBiZSBhbHNvIGRpc2N1c3NlZCBhdCB0aGUgdXBjb21pbmcgQ1MzIGV2ZW50 IEkgbGlua2VkIGluLiBUaGUgaW50ZW50IGlzIHRvIGRvIHRoaXMgZGlzY3Vzc2luZyB0b2dldGhl ciBiZXR3ZWVuIHNlcnZpY2UgcHJvdmlkZXJzLCBkZXZlbG9wZXJzIGFuZCByZXNlYXJjaGVycyB0 b2dldGhlciDigJUgc28gdGhhdCBpdCBkb2VzIG5vdCBvbmx5IGVuZCB1cCBhcyBhbiBhY2FkZW1p YyBleGVyY2lzZSBidXQgYmFja2VkIHVwIGJ5IGEgY3JpdGljYWwgbWFzcyBpZiB0aGVyZSBpcyBz b21lIHBvdGVudGlhbCBpbiBzdGFuZGFyZGlzYXRpb24sIGF0IGxlYXN0IGluIG91ciBjb21tdW5p dHkuIEkgaG9wZSB0aGlzIGNvdWxkIGJlIG9mIGludGVyZXN0IHRvIElFVEYgY29tbXVuaXR5LCBh cyBtZW50aW9uZWQgb24gdGhlIHByb2dyYW0gcGFnZS4NCg0KU2VsZWN0ZWQgcGFwZXJzIHdpbGwg YmUgcHVibGlzaGVkIGluIEZHQ1MgYWZ0ZXIgdGhlIGV2ZW50LCBzbyBwbGVhc2Ugc3RhbmQgYnks IG9yIGF0dGVuZCB0aGUgZXZlbnQgaWYgeW91IHdhbnQgdG8gYmUgcGFydCBvZiB0aGlzIGRpc2N1 c3Npb24gaGVyZS4gQlRXLiB0aGUgYWJzdHJhY3Qgc3VibWlzc2lvbiBkZWFkbGluZSBpcyBwYXN0 IGJ1dCBvbmUgZXhjZXB0aW9uYWxseSBnb29kIGNvbnRyaWJ1dGlvbiBjb3VsZCBzdGlsbCBwb3Nz aWJseSBiZSBhY2NvbW1vZGF0ZWQgaWYgc3VibWl0dGVkIHJhcGlkbHkuDQoNCkkgd291bGQgYmUg bm9uZXRoZWxlc3MgaGFwcHkgdG8gY29udGludWUgY29udHJpYnV0aW5nIHRvIHRoZSBkaXNjdXNz aW9uIGluIHRoaXMgbWFpbGluZyBsaXN0Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkpha3ViIE1vc2Np Y2tpDQoNCi0tDQoNCg0KUmVnYXJkcywNCkxpbmh1aQ0KDQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkg U29uZw0KSGVsbG8sDQoNCldoYXQga2luZCBvZiBvdXRjb21lIGFyZSB5b3UgbG9va2luZyBmb3Ig d2l0aCB0aGlzIGFuYWx5c2lzPyBTb21lIHJlc2VhcmNoIGluIHRoaXMgYXJlYSBoYXMgYWxyZWFk eSBiZWVuIGRvbmUgb3IgaXMgYmVpbmcgZG9uZSBhcyB3ZSBzcGVhaw0KDQplLmcuICJBIHN0dWR5 IG9mIGRlbHRhLXN5bmMgYW5kIG90aGVyIG9wdGltaXNhdGlvbiBpbiBIVFRQL1dlYmRhdiBzeW5j aG9uaXNhdGlvbiBwcm90b2NvbHMiDQoNCnNlZSAiVGVjaG5vbG9neSBhbmQgUmVzZWFyY2giOg0K DQpodHRwOi8vY3MzLmV0aHouY2gvcHJvZ3JhbS5odG1sDQoNCkl0IHdvdWxkIGJlIGludGVyZXN0 aW5nIHRvIHNlZSBpZiB0aGVyZSBpcyBhIHBvdGVudGlhbCBmb3IgY29sbGFib3JhdGlvbi4gT3Ig bWF5YmUgd2UgYWxyZWFkeSBoYXZlIHNvbWUgaW5mb3JtYXRpb24geW91IGFyZSBsb29raW5nIGZv ci4NCg0KQmVzdCByZWdhcmRzLA0KDQpKYWt1YiBNb3NjaWNraQ0KDQrigJUNCg0KDQpPbiAyNSBO b3YgMjAxNSwgYXQgMTE6NDUsIExpbmh1aSBTdW4gPGxoLnN1bmxpbmhAZ21haWwuY29tPG1haWx0 bzpsaC5zdW5saW5oQGdtYWlsLmNvbT48bWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tPG1haWx0 bzpsaC5zdW5saW5oQGdtYWlsLmNvbT4+PiB3cm90ZToNCg0KSGkgYWxsLA0KDQpBcyBJIG1lbnRp b25lZCBiZWZvcmUsIEkgdGhpbmsgdGhlIGRldmVsb3BlcnMgY291bGQgYmVuZWZpdCBmcm9tIHRo ZSBJRVRGIHN0YW5kYXJkcy4gVGhlIG93bkNsb3VkIChodHRwczovL293bmNsb3VkLm9yZy8pIGlz IGp1c3QgYW4gZXhhbXBsZS4gSXQgaXMgZGV2ZWxvcGVkIGZvciB0aG9zZSB3aG8gZG8gbm90IHRy dXN0IGNvbW1lcmNpYWwgc3RvcmFnZSBzZXJ2aWNlcyBhbmQgd2FudCB0byBidWlsZCB0aGVpciBv d24gbmV0d29yay1iYXNlZCBzdG9yYWdlIHNlcnZpY2VzLiBUaGUgb3duQ2xvdWQgaXMgdXNpbmcg V2ViREFWIChSRkM0OTE4KSB0byBhY2hpZXZlIHRoZSBkYXRhIHN5bmMuIElNTywgdGhlIFdlYkRB ViBpcyBkZXNpZ25lZCBmb3IgZGlzdHJpYnV0ZWQgd29yayBidXQgbm90IGZvciB0aGUgc3luYy4g VGh1cywgSSBtYWRlIHNvbWUgcHJlbGltaW5hcnkgaW52ZXN0aWdhdGlvbnMgb24gaG93IHRoZSBv d25DbG91ZCB1c2VzIFdlYkRBViBmb3Igc3luYyBwdXJwb3Nlcy4gQSBicmllZiBzdW1tYXJ5IG9m IHdoYXQgSSd2ZSBmb3VuZCBpcyBpbiB0aGUgZm9sbG93aW5nLCBwbGVhc2UgY29ycmVjdCBtZSBp ZiBJIGFtIHdyb25nLg0KDQpJIGluc3RhbGxlZCB0aGUgb3duQ2xvdWQgc2VydmVyICh2OC4yLjEp IG9uIHRoZSBDZW50T1M3LCBhbmQgdGhlIGNsaWVudCBpcyBhIGRlc2t0b3AgY2xpZW50IG9uIFdp bmRvd3MuDQoNCjEuIFRvIGZpbmQgd2hldGhlciB0aGVyZSBpcyBhIGNoYW5nZSB0byB0aGUgc3lu Y2VkIGRpcmVjdG9yeSwgdGhlIGNsaWVudCBjb250aW51b3VzbHkgc2VuZHMgUFJPUEZJTkQgdG8g dGhlIHNlcnZlciBhdCByZWd1bGFyIGludGVydmFscyAoYXJvdW5kIDM0IHNlY29uZHMgdW5kZXIg bXkgb2JzZXJ2YXRpb24pLiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwNyBNdWx0aS1TdGF0 dXMgUmVzcG9uc2UgdG8gdGVsbCB3aGV0aGVyIHRoZSBtYWluIGRpcmVjdG9yeSBoYXMgYmVlbiBj aGFuZ2VkLiBUbyBwZXJmb3JtIHRoaXMgcmVndWxhciBjaGVjaywgdGhlIGNsaWVudCB3aWxsIG9w ZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gdG8gc2VuZCB0aGUgUFJPUEZJTkQsIHRoZSBzZXJ2ZXIg d2lsbCBjbG9zZSB0aGUgZXhpc3RpbmcgVENQIGNvbm5lY3Rpb24gYWZ0ZXIgcmVzcG9uZGluZyB0 aGUgMjA3IE11bHRpLVN0YXR1cyBSZXNwb25zZS4gRm9yIHRoZSBuZXh0IGNoZWNrLCB0aGUgY2xp ZW50IHdpbGwgb3BlbiBhbm90aGVyIG5ldyBUQ1AgY29ubmVjdGlvbi4NCg0KMi4gRXZlcnkgdGlt ZSBhZGRpbmcgKG9yIGNyZWF0aW5nKSBhIG5ldyBmaWxlIHRvIHRoZSBsb2NhbCBmb2xkZXIsIHRo ZSBjbGllbnQgd2lsbCBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIChpZiB0aGVyZSBpcyBubyBj b25uZWN0aW9uIGV4aXN0aW5nKSB0byBzZW5kIHRoZSBmaWxlIGFzYXAuIFRoZSBjbGllbnQgd2ls bCBmaXJzdCBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIHN1Yi1kaXJl Y3RvcnkgaGFzIGJlZW4gY2hhbmdlZC4gQW5kIHRoZW4gaXQgc2VuZHMgdGhlIGZpbGUgdXNpbmcg UFVULiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwMSBDcmVhdGVkIFJlc3BvbnNlIGFuZCB0 aGVuIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4gQ3VycmVudGx5LCBJIGhhdmVuJ3QgZm91bmQg YW55IGFwcGxpY2F0aW9uIGxheWVyIGNodW5raW5nLCBhbGwgdGhlIHNlZ21lbnRhdGlvbiBhcmUg cGVyZm9ybWVkIGJ5IFRDUC4NCg0KMy4gRXZlcnkgdGltZSBJIGRlbGV0ZSAob3IgcmVuYW1lKSBh IGZpbGUgbG9jYWxseSwgdGhlIGNsaWVudCB3aWxsIGFsc28gb3BlbiBhIG5ldyBUQ1AgY29ubmVj dGlvbiB0byBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIGZpbGUgaGFz IGJlZW4gcmVtb3ZlZCAob3IgcmVuYW1lZCkuIFRoZW4gaXQgd2lsbCBzZW5kIERFTEVURSAob3Ig TU9WRSkuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA0IE5vIENvbnRlbnQgUmVzcG9uc2Ug KG9yIDIwMSBDcmVhdGVkIFJlc3BvbnNlKSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rp b24uDQoNCjQuIEkgb3BlbiBhIGZpbGUgYW5kIGZyZXF1ZW50bHkgZWRpdCBhbmQgc2F2ZSBpdCAo YWN0dWFsbHkgdGhpcyBpcyB3aGF0IEkgdXN1YWxseSBkbyB3aXRoIHRoZSBEcm9wYm94KS4gVGhl IGNsaWVudCB3aWxsIHNlbmQgdGhlIHdob2xlIGZpbGUgdG8gdGhlIHNlcnZlciBldmVyeSB0aW1l IEkgc2F2ZSB0aGUgZmlsZS4NCg0KVG8gc3VtbWFyaXplLCBpdCBzZWVtcyB0aGF0IHRoZSBvd25D bG91ZCBtYWtlcyBoZWF2aWx5IHVzZSBvZiBQUk9QRklORCB0byBhY2hpZXZlIHRoZSBzeW5jIHBy b2Nlc3MuIEVhY2ggc3luYyBvcGVyYXRpb24gKGUuZy4gdXBsb2FkLCBtb2RpZnkgYW5kIGV0Yy4p IHdpbGwgc3RhcnQgd2l0aCBzZW5kaW5nIG9uZSBvciBtb3JlIFBST1BGSU5Ecy4gQW5kIGN1cnJl bnRseSwgaWYgSSBhZGQgYSBmaWxlIHRvIHRoZSBzZXJ2ZXIgKGRpcmVjdGx5IGZyb20gdGhlIHNl cnZlciBzaWRlIHZpYSB3ZWIgaW50ZXJmYWNlKSwgdGhlIGNsaWVudCBjYW5ub3QgZmluZCB0aGUg Y2hhbmdlLiBJIG5lZWQgdG8gaW50ZXJydXB0IHRoZSBzeW5jIGFuZCByZWNvdmVyIGl0IHRvIG1h a2UgdGhlIGNsaWVudCBiZSBhd2FyZSBvZiB0aGUgY2hhbmdlIGFuZCBkb3dubG9hZCB0aGUgbmV3 bHkgYWRkZWQgZmlsZS4gSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBpcyBjYXVzZWQgYnkgdGhl IHN5bmMgbWVjaGFuaXNtIG9yIGFuIGltcHJvcGVyIHNlcnZlciBjb25maWd1cmF0aW9uLiBJIG5l ZWQgdG8gaW52ZXN0aWdhdGUgdGhpcyBmdXJ0aGVyIGFuZCBhbHNvIGhvdyB0aGUgb3duQ2xvdWQg d29ya3MgZm9yIG11bHRpcGxlIGNsaWVudHMgKG9yIGRldmljZXMpLg0KDQpGb3IgSVNTLCBJIHRo aW5rIG93bkNsb3VkIGhhcyBkZW1vbnN0cmF0ZWQgdG8gc29tZSBleHRlbnQgdGhhdCBzaW1pbGFy IElFVEYgcHJvdG9jb2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3llZC4gVGhlIGludGVu dGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJlbnQgc3RhdGUg b2YgdXNpbmcgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRvIGJl IGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIgd2UgbmVlZCBuZXcgcHJvdG9jb2xzLg0KDQpDb21t ZW50cyBhcmUgd2VsY29tZSA6ICkNCg0KUmVnYXJkcywNCkxpbmh1aQ0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTdG9yYWdlc3luYyBtYWlsaW5n IGxpc3QNClN0b3JhZ2VzeW5jQGlldGYub3JnPG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZz48 bWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYub3JnPG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZz4+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTdG9yYWdlc3lu YyBtYWlsaW5nIGxpc3QNClN0b3JhZ2VzeW5jQGlldGYub3JnPG1haWx0bzpTdG9yYWdlc3luY0Bp ZXRmLm9yZz48bWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNClN0 b3JhZ2VzeW5jQGlldGYub3JnPG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCg0K --_000_42E30C8611424A20BC3DD1B22029247Acernch_ Content-Type: text/html; charset="utf-8" Content-ID: <598F40E5AE2EEA46A825A1F60019B127@cern.ch> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5IZXJlIGlzIHRoZSBwdWJsaWNh dGlvbiBzY2hlZHVsZSAod2lsbCBiZSB1cGRhdGVkIHNvb24gb25saW5lOiA8YSBocmVmPSJodHRw Oi8vd3d3LmpvdXJuYWxzLmVsc2V2aWVyLmNvbS9mdXR1cmUtZ2VuZXJhdGlvbi1jb21wdXRlci1z eXN0ZW1zL2NhbGwtZm9yLXBhcGVycy9zcGVjaWFsLXNlY3Rpb24tY2xvdWQtc3RvcmFnZS1zZXJ2 aWNlcy1maWxlLXN5bmNocm9uaXphdGlvbi8iIGNsYXNzPSIiPg0KaHR0cDovL3d3dy5qb3VybmFs cy5lbHNldmllci5jb20vZnV0dXJlLWdlbmVyYXRpb24tY29tcHV0ZXItc3lzdGVtcy9jYWxsLWZv ci1wYXBlcnMvc3BlY2lhbC1zZWN0aW9uLWNsb3VkLXN0b3JhZ2Utc2VydmljZXMtZmlsZS1zeW5j aHJvbml6YXRpb24vPC9hPikuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbXBvcnRhbnQgRGF0ZXMmbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlN1Ym1pc3Npb24gRHVl IEFwcmlsIDEsIDIwMTYmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MXN0IFJvdW5kIE5vdGlm aWNhdGlvbiBBdWd1c3QgMSwgMjAxNiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZXZpc2lv biBPY3RvYmVyIDEsIDIwMTYmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UHVibGljYXRpb24g KGV4cGVjdGVkKSBMYXRlIDIwMTYgb3IgRWFybHkgMjAxNzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmVzdCByZWdhcmRzLDwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+a3ViYTwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ 4oCUPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDAyIERlYyAyMDE1LCBhdCAwNDowNywgRmVpIFNvbmcgJmx0 OzxhIGhyZWY9Im1haWx0bzpmc29uZ0BianR1LmVkdS5jbiIgY2xhc3M9IiI+ZnNvbmdAYmp0dS5l ZHUuY248L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut bmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPkhpIEpha3ViLDxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkkgbm90aWNlIHRoYXQgdGhpcyBpcyBhICZxdW90O1NwZWNpYWwgU2VjdGlvbiZxdW90 OywgPGJyIGNsYXNzPSIiPg0KYW55IGRlYWRsaW5lIGZvciBpdD8gb3IgaXQgd2lsbCBiZSBhdmFp bGFibGUgZm9yIGEgbG9uZyB0aW1lPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KRmVpIFNvbmc8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5CVFcsIGhlcmUgaXMgdGhlIHB1 YmxpYyBDRlAgZm9yIEZHQ1M6IDxhIGhyZWY9Imh0dHA6Ly9jczMuZXRoei5jaC9wdWJsaWNhdGlv bnMuaHRtbCIgY2xhc3M9IiI+DQpodHRwOi8vY3MzLmV0aHouY2gvcHVibGljYXRpb25zLmh0bWw8 L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQmVzdCByZWdhcmRzLDxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCkpha3ViIE1vc2NpY2tpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0K4oCVPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gMjYgTm92IDIwMTUsIGF0 IDA0OjI5LCBKYWt1YiBNb3NjaWNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkpha3ViLk1vc2NpY2tp QGNlcm4uY2giIGNsYXNzPSIiPkpha3ViLk1vc2NpY2tpQGNlcm4uY2g8L2E+Jmx0OzxhIGhyZWY9 Im1haWx0bzpKYWt1Yi5Nb3NjaWNraUBjZXJuLmNoIiBjbGFzcz0iIj5tYWlsdG86SmFrdWIuTW9z Y2lja2lAY2Vybi5jaDwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQoyMDE1LTExLTI2IDExOjI4IEdNVCYjNDM7MDg6MDAgRmVpIFNvbmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpmc29uZ0BianR1LmVkdS5jbiIgY2xhc3M9IiI+ZnNvbmdAYmp0dS5lZHUuY248L2E+ Jmx0OzxhIGhyZWY9Im1haWx0bzpmc29uZ0BianR1LmVkdS5jbiIgY2xhc3M9IiI+bWFpbHRvOmZz b25nQGJqdHUuZWR1LmNuPC9hPiZndDsmZ3Q7OjxiciBjbGFzcz0iIj4NCkJUVywgQmFzZWQgb24g dGhlIGxhc3Qgc2VudGVuY2Ugb2YgbGFzdCBlbWFpbDomcXVvdDtUaGUgaW50ZW50aW9uIG9mIHRo aXMgbWVzc2FnZSBpcyB0byBpbnZlc3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB1c2luZyBX ZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQg aGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldyBwcm90b2NvbHMmcXVvdDs8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGUgb3V0Y29tZSBoZS9zaGUgd2FudGVkIG1pZ2h0IGJlIGp1c3Qg dGhlIGxpbmtzIGxpa2UgPGEgaHJlZj0iaHR0cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbCIg Y2xhc3M9IiI+DQpodHRwOi8vY3MzLmV0aHouY2gvcHJvZ3JhbS5odG1sPC9hPiA6KTxiciBjbGFz cz0iIj4NCkluIGFub3RoZXIgd29yZCwgSSB0aGluayB3aGF0IEkgd2FudCBmaW5hbGx5IG1pZ2h0 IGJlIGEgZGlzY3Vzc2lvbiBhYm91dCAmcXVvdDtXaGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzog YSBzeW5jIHByb3RvY29sIG9yIGEgZ2VuZXJhbGl6ZWQgQVBJJnF1b3Q7LiBTb3JyeSBmb3IgdGhl IHBvb3IgZXhwcmVzc2lvbiA6ICk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHRoaW5r IHRoaXMgaXMgYSByZWxldmFudCBxdWVzdGlvbiBpbmRlZWQgKHdlbGwsIGFjdHVhbGx5IGFsc28g aWYgdGhlcmUgaXMgYW55IHN0YW5kYXJkIG5lZWRlZCBhdCBhbGwgaW4gdGhlIGZpcnN0IHBsYWNl KS4gQnkgdGhlIGdlbmVyYWxpemVkIEFQSSBkbyB5b3UgbWVhbiBhIEhUVFAtc3R5bGUgQVBJIChs aWtlIFJFU1QpPyBJbiB0aGF0IGNhc2UgeW91IG1heSBjb25zaWRlciBXZWJEQVYgcXVpdGUgY2xv c2UgYW5kIHRoZSBkaWZmZXJlbmNlDQogYmV0d2VlbiB0aGUgcHJvdG9jb2wgYW5kIHRoZSBBUEkg Ymx1cnMgZm9yIHByYWN0aWNhbCBwdXJwb3Nlcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpXaGlsZSBJIGFncmVlIHRoYXQgV2ViREFWIG1heSBoYXZlIGRpc2FkdmFudGFnZXMgdGhlcmUg aXMgYSBnb29kIG51bWJlciBvZiBpbnN0YWxsYXRpb25zIHVzaW5nIHRoaXMgYWxyZWFkeSBpbiBv dXIgY29tbXVuaXR5IChyZXNlYXJjaCBsYWJzIG1haW5seSBpbiwgYnV0IG5vdCBsaW1pdGVkIHRv LCBFdXJvcGUpLiBJIHRoaW5rIHRoZSBpbnRlcmVzdGluZyBwb2ludCBhYm91dCBXZWJEQVYvSFRU UCBpcyBleHRlbnNpYmlsaXR5IGFuZCBtYXliZSBpdA0KIGlzIHdvcnRoIGlzIHRoYXQgdGhlc2Ug ZXh0ZW5zaW9ucyBnbyBieSBhIOKAnHN0YW5kYXJk4oCdLiBIb3dldmVyLCB5b3Ugc2hvdWxkIGNv bnNpZGVyIHRoYXQgZm9yIHJlYXNvbmFibHkgZWZmaWNpZW50IHN5bmMgc2NlbmFyaW8gdGhlIHNl cnZlciBzaG91bGQgYWxzbyBleGhpYml0IGNlcnRhaW4gYmVoYXZpb3VyLiBUaGF0IGlzLCBpbiBj YXNlIG9mIG93bmNsb3VkIGZvciBleGFtcGxlLCBhIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBl ZmZpY2llbnRseQ0KIHByb3BhZ2F0ZSB0aGUgRVRBRyBjaGFuZ2VzIHVwIHRoZSBkaXJlY3Rvcnkg dHJlZSAobGlrZSB0aGUgTWVya2xlIFRyZWUpIHNvIHRoYXQgdGhlIGNsaWVudCBtYXkgdXNlIHBy b3BmaW5kIGVmZmljaWVudGx5LiBUaGlzIGlzIG5vdCBhIGhhcmQgc3BlYyByZXF1aXJlbWVudCBi dXQgb3RoZXJ3aXNlIHByb3BmaW5kaW5nIHRoZSBlbnRpcmUgcmVtb3RlIHRyZWUgZWFjaCB0aW1l IHdvdWxkIGJlIGltcHJhY3RpY2FsbHkgaW5lZmZpY2llbnQuIFNvIHRoaXMNCiByZWFsbHkgZ29l cyBhIGxpdHRsZSBiaXQgYmV5b25kIGp1c3QgYW4gQVBJLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCllvdSBzaG91bGQgYWxzbyBjb25zaWRlciB0aGF0IHRoZSBPcGVuQ2xvdWRNZXNoICh1 bmRlciBHRUFOVCB1bWJyZWxsYSkgaXMgYW4gaW5pdGlhdGl2ZSB3aXRoIHRoZSBpbnRlbnQgaXMg dG8gbWFrZSBjcm9zcy1zZXJ2aWNlIHNoYXJpbmcgdmVyeSBlYXN5LiBUaGVzZSBzaGFyZXMgbWF5 IGFsc28gYmUgc3luY2hyb25pemVkIGF1dG9tYXRpY2FsbHkuIEkgY3VycmVudGx5IGhhdmUgbm8g ZXZpZGVuY2UsIGhvd2V2ZXIsIHRoYXQgb3RoZXIgc29mdHdhcmUNCiBwcm92aWRlcnMgd2l0aCB0 aGUgZXhjZXB0aW9uIG9mIG93bmNsb3VkIGFyZSBpbnRlcmVzdGVkIGluIGRldmVsb3Bpbmcgc3Vj aCBzdGFuZGFyZC4gSWYgdGhlcmUgaXMgbm8gYm90dG9tIHVwIGludGVyZXN0IGZyb20gdGhlIHVz ZXJzIHRoZW4gaXQgd29u4oCZdCBoYXBwZW4gKGluIG15IG9waW5pb24pLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCldpdGggdGhlIGxpbmsgSSB3YW50ZWQgdG8gcG9pbnQgeW91IHRvIHRo ZSBmYWN0IHRoYXQgd2hhdCB5b3UgZGlzY3VzcyBpbiB0aGlzIG1haWxpbmcgbGlzdCB3aWxsIGJl IGFsc28gZGlzY3Vzc2VkIGF0IHRoZSB1cGNvbWluZyBDUzMgZXZlbnQgSSBsaW5rZWQgaW4uIFRo ZSBpbnRlbnQgaXMgdG8gZG8gdGhpcyBkaXNjdXNzaW5nIHRvZ2V0aGVyIGJldHdlZW4gc2Vydmlj ZSBwcm92aWRlcnMsIGRldmVsb3BlcnMgYW5kIHJlc2VhcmNoZXJzIHRvZ2V0aGVyDQog4oCVIHNv IHRoYXQgaXQgZG9lcyBub3Qgb25seSBlbmQgdXAgYXMgYW4gYWNhZGVtaWMgZXhlcmNpc2UgYnV0 IGJhY2tlZCB1cCBieSBhIGNyaXRpY2FsIG1hc3MgaWYgdGhlcmUgaXMgc29tZSBwb3RlbnRpYWwg aW4gc3RhbmRhcmRpc2F0aW9uLCBhdCBsZWFzdCBpbiBvdXIgY29tbXVuaXR5LiBJIGhvcGUgdGhp cyBjb3VsZCBiZSBvZiBpbnRlcmVzdCB0byBJRVRGIGNvbW11bml0eSwgYXMgbWVudGlvbmVkIG9u IHRoZSBwcm9ncmFtIHBhZ2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VsZWN0ZWQg cGFwZXJzIHdpbGwgYmUgcHVibGlzaGVkIGluIEZHQ1MgYWZ0ZXIgdGhlIGV2ZW50LCBzbyBwbGVh c2Ugc3RhbmQgYnksIG9yIGF0dGVuZCB0aGUgZXZlbnQgaWYgeW91IHdhbnQgdG8gYmUgcGFydCBv ZiB0aGlzIGRpc2N1c3Npb24gaGVyZS4gQlRXLiB0aGUgYWJzdHJhY3Qgc3VibWlzc2lvbiBkZWFk bGluZSBpcyBwYXN0IGJ1dCBvbmUgZXhjZXB0aW9uYWxseSBnb29kIGNvbnRyaWJ1dGlvbiBjb3Vs ZCBzdGlsbCBwb3NzaWJseSBiZQ0KIGFjY29tbW9kYXRlZCBpZiBzdWJtaXR0ZWQgcmFwaWRseS48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHdvdWxkIGJlIG5vbmV0aGVsZXNzIGhhcHB5 IHRvIGNvbnRpbnVlIGNvbnRyaWJ1dGluZyB0byB0aGUgZGlzY3Vzc2lvbiBpbiB0aGlzIG1haWxp bmcgbGlzdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0IHJlZ2FyZHMsPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSmFrdWIgTW9zY2lja2k8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQotLTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KTGluaHVpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpGZWkgU29uZzxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkhlbGxvLDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldoYXQga2luZCBvZiBvdXRjb21lIGFyZSB5b3UgbG9v a2luZyBmb3Igd2l0aCB0aGlzIGFuYWx5c2lzPyBTb21lIHJlc2VhcmNoIGluIHRoaXMgYXJlYSBo YXMgYWxyZWFkeSBiZWVuIGRvbmUgb3IgaXMgYmVpbmcgZG9uZSBhcyB3ZSBzcGVhazxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCmUuZy4gJnF1b3Q7QSBzdHVkeSBvZiBkZWx0YS1zeW5jIGFu ZCBvdGhlciBvcHRpbWlzYXRpb24gaW4gSFRUUC9XZWJkYXYgc3luY2hvbmlzYXRpb24gcHJvdG9j b2xzJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0Kc2VlICZxdW90O1RlY2hub2xv Z3kgYW5kIFJlc2VhcmNoJnF1b3Q7OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwiIGNsYXNzPSIiPmh0dHA6Ly9jczMu ZXRoei5jaC9wcm9ncmFtLmh0bWw8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSXQg d291bGQgYmUgaW50ZXJlc3RpbmcgdG8gc2VlIGlmIHRoZXJlIGlzIGEgcG90ZW50aWFsIGZvciBj b2xsYWJvcmF0aW9uLiBPciBtYXliZSB3ZSBhbHJlYWR5IGhhdmUgc29tZSBpbmZvcm1hdGlvbiB5 b3UgYXJlIGxvb2tpbmcgZm9yLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJlc3QgcmVn YXJkcyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpKYWt1YiBNb3NjaWNraTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCuKAlTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCk9uIDI1IE5vdiAyMDE1LCBhdCAxMTo0NSwgTGluaHVpIFN1biAmbHQ7bGgu c3VubGluaEBnbWFpbC5jb20mbHQ7bWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tJmd0OyZsdDtt YWlsdG86bGguc3VubGluaEBnbWFpbC5jb20mbHQ7bWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29t Jmd0OyZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhpIGFsbCw8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBcyBJIG1lbnRpb25lZCBiZWZvcmUsIEkgdGhp bmsgdGhlIGRldmVsb3BlcnMgY291bGQgYmVuZWZpdCBmcm9tIHRoZSBJRVRGIHN0YW5kYXJkcy4g VGhlIG93bkNsb3VkIChodHRwczovL293bmNsb3VkLm9yZy8pIGlzIGp1c3QgYW4gZXhhbXBsZS4g SXQgaXMgZGV2ZWxvcGVkIGZvciB0aG9zZSB3aG8gZG8gbm90IHRydXN0IGNvbW1lcmNpYWwgc3Rv cmFnZSBzZXJ2aWNlcyBhbmQgd2FudCB0byBidWlsZCB0aGVpciBvd24gbmV0d29yay1iYXNlZCBz dG9yYWdlDQogc2VydmljZXMuIFRoZSBvd25DbG91ZCBpcyB1c2luZyBXZWJEQVYgKFJGQzQ5MTgp IHRvIGFjaGlldmUgdGhlIGRhdGEgc3luYy4gSU1PLCB0aGUgV2ViREFWIGlzIGRlc2lnbmVkIGZv ciBkaXN0cmlidXRlZCB3b3JrIGJ1dCBub3QgZm9yIHRoZSBzeW5jLiBUaHVzLCBJIG1hZGUgc29t ZSBwcmVsaW1pbmFyeSBpbnZlc3RpZ2F0aW9ucyBvbiBob3cgdGhlIG93bkNsb3VkIHVzZXMgV2Vi REFWIGZvciBzeW5jIHB1cnBvc2VzLiBBIGJyaWVmIHN1bW1hcnkNCiBvZiB3aGF0IEkndmUgZm91 bmQgaXMgaW4gdGhlIGZvbGxvd2luZywgcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGluc3RhbGxlZCB0aGUgb3duQ2xvdWQgc2Vy dmVyICh2OC4yLjEpIG9uIHRoZSBDZW50T1M3LCBhbmQgdGhlIGNsaWVudCBpcyBhIGRlc2t0b3Ag Y2xpZW50IG9uIFdpbmRvd3MuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KMS4gVG8gZmlu ZCB3aGV0aGVyIHRoZXJlIGlzIGEgY2hhbmdlIHRvIHRoZSBzeW5jZWQgZGlyZWN0b3J5LCB0aGUg Y2xpZW50IGNvbnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2VydmVyIGF0IHJlZ3Vs YXIgaW50ZXJ2YWxzIChhcm91bmQgMzQgc2Vjb25kcyB1bmRlciBteSBvYnNlcnZhdGlvbikuIFRo ZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA3IE11bHRpLVN0YXR1cyBSZXNwb25zZSB0byB0ZWxs IHdoZXRoZXIgdGhlIG1haW4gZGlyZWN0b3J5DQogaGFzIGJlZW4gY2hhbmdlZC4gVG8gcGVyZm9y bSB0aGlzIHJlZ3VsYXIgY2hlY2ssIHRoZSBjbGllbnQgd2lsbCBvcGVuIGEgbmV3IFRDUCBjb25u ZWN0aW9uIHRvIHNlbmQgdGhlIFBST1BGSU5ELCB0aGUgc2VydmVyIHdpbGwgY2xvc2UgdGhlIGV4 aXN0aW5nIFRDUCBjb25uZWN0aW9uIGFmdGVyIHJlc3BvbmRpbmcgdGhlIDIwNyBNdWx0aS1TdGF0 dXMgUmVzcG9uc2UuIEZvciB0aGUgbmV4dCBjaGVjaywgdGhlIGNsaWVudCB3aWxsIG9wZW4gYW5v dGhlcg0KIG5ldyBUQ1AgY29ubmVjdGlvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoy LiBFdmVyeSB0aW1lIGFkZGluZyAob3IgY3JlYXRpbmcpIGEgbmV3IGZpbGUgdG8gdGhlIGxvY2Fs IGZvbGRlciwgdGhlIGNsaWVudCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gKGlmIHRo ZXJlIGlzIG5vIGNvbm5lY3Rpb24gZXhpc3RpbmcpIHRvIHNlbmQgdGhlIGZpbGUgYXNhcC4gVGhl IGNsaWVudCB3aWxsIGZpcnN0IHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZCBvdXQgd2hp Y2ggc3ViLWRpcmVjdG9yeSBoYXMgYmVlbiBjaGFuZ2VkLg0KIEFuZCB0aGVuIGl0IHNlbmRzIHRo ZSBmaWxlIHVzaW5nIFBVVC4gVGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDEgQ3JlYXRlZCBS ZXNwb25zZSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24uIEN1cnJlbnRseSwgSSBo YXZlbid0IGZvdW5kIGFueSBhcHBsaWNhdGlvbiBsYXllciBjaHVua2luZywgYWxsIHRoZSBzZWdt ZW50YXRpb24gYXJlIHBlcmZvcm1lZCBieSBUQ1AuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KMy4gRXZlcnkgdGltZSBJIGRlbGV0ZSAob3IgcmVuYW1lKSBhIGZpbGUgbG9jYWxseSwgdGhl IGNsaWVudCB3aWxsIGFsc28gb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiB0byBzZW5kIHNldmVy YWwgUFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIGZpbGUgaGFzIGJlZW4gcmVtb3ZlZCAob3Ig cmVuYW1lZCkuIFRoZW4gaXQgd2lsbCBzZW5kIERFTEVURSAob3IgTU9WRSkuIFRoZSBzZXJ2ZXIg d2lsbCByZXNwb25kIGEgMjA0IE5vIENvbnRlbnQgUmVzcG9uc2UNCiAob3IgMjAxIENyZWF0ZWQg UmVzcG9uc2UpIGFuZCB0aGVuIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo0LiBJIG9wZW4gYSBmaWxlIGFuZCBmcmVxdWVudGx5IGVkaXQgYW5k IHNhdmUgaXQgKGFjdHVhbGx5IHRoaXMgaXMgd2hhdCBJIHVzdWFsbHkgZG8gd2l0aCB0aGUgRHJv cGJveCkuIFRoZSBjbGllbnQgd2lsbCBzZW5kIHRoZSB3aG9sZSBmaWxlIHRvIHRoZSBzZXJ2ZXIg ZXZlcnkgdGltZSBJIHNhdmUgdGhlIGZpbGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K VG8gc3VtbWFyaXplLCBpdCBzZWVtcyB0aGF0IHRoZSBvd25DbG91ZCBtYWtlcyBoZWF2aWx5IHVz ZSBvZiBQUk9QRklORCB0byBhY2hpZXZlIHRoZSBzeW5jIHByb2Nlc3MuIEVhY2ggc3luYyBvcGVy YXRpb24gKGUuZy4gdXBsb2FkLCBtb2RpZnkgYW5kIGV0Yy4pIHdpbGwgc3RhcnQgd2l0aCBzZW5k aW5nIG9uZSBvciBtb3JlIFBST1BGSU5Ecy4gQW5kIGN1cnJlbnRseSwgaWYgSSBhZGQgYSBmaWxl IHRvIHRoZSBzZXJ2ZXIgKGRpcmVjdGx5IGZyb20NCiB0aGUgc2VydmVyIHNpZGUgdmlhIHdlYiBp bnRlcmZhY2UpLCB0aGUgY2xpZW50IGNhbm5vdCBmaW5kIHRoZSBjaGFuZ2UuIEkgbmVlZCB0byBp bnRlcnJ1cHQgdGhlIHN5bmMgYW5kIHJlY292ZXIgaXQgdG8gbWFrZSB0aGUgY2xpZW50IGJlIGF3 YXJlIG9mIHRoZSBjaGFuZ2UgYW5kIGRvd25sb2FkIHRoZSBuZXdseSBhZGRlZCBmaWxlLiBJJ20g bm90IHN1cmUgd2hldGhlciB0aGlzIGlzIGNhdXNlZCBieSB0aGUgc3luYyBtZWNoYW5pc20gb3Ig YW4NCiBpbXByb3BlciBzZXJ2ZXIgY29uZmlndXJhdGlvbi4gSSBuZWVkIHRvIGludmVzdGlnYXRl IHRoaXMgZnVydGhlciBhbmQgYWxzbyBob3cgdGhlIG93bkNsb3VkIHdvcmtzIGZvciBtdWx0aXBs ZSBjbGllbnRzIChvciBkZXZpY2VzKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpGb3Ig SVNTLCBJIHRoaW5rIG93bkNsb3VkIGhhcyBkZW1vbnN0cmF0ZWQgdG8gc29tZSBleHRlbnQgdGhh dCBzaW1pbGFyIElFVEYgcHJvdG9jb2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3llZC4g VGhlIGludGVudGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJl bnQgc3RhdGUgb2YgdXNpbmcgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzIHRvIHNlZSB3aGF0IG5l ZWRzIHRvIGJlIGltcHJvdmVkIGhlcmUgYW5kDQogd2hldGhlciB3ZSBuZWVkIG5ldyBwcm90b2Nv bHMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ29tbWVudHMgYXJlIHdlbGNvbWUgOiAp PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmVnYXJkcyw8YnIgY2xhc3M9IiI+DQpMaW5o dWk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClN0b3Jh Z2VzeW5jIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NClN0b3JhZ2VzeW5jQGlldGYub3JnJmx0 O21haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZyZndDsmbHQ7bWFpbHRvOlN0b3JhZ2VzeW5jQGll dGYub3JnJmx0O21haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYzxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KU3RvcmFnZXN5bmMg bWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlN0b3JhZ2VzeW5jQGll dGYub3JnIiBjbGFzcz0iIj5TdG9yYWdlc3luY0BpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFp bHRvOlN0b3JhZ2VzeW5jQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86U3RvcmFnZXN5bmNAaWV0 Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmM8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+DQpTdG9yYWdlc3luY0BpZXRmLm9yZyZsdDttYWlsdG86U3RvcmFnZXN5bmNAaWV0 Zi5vcmcmZ3Q7PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zdG9yYWdlc3luYzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_42E30C8611424A20BC3DD1B22029247Acernch_-- From nobody Tue Dec 8 01:06:42 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F4A1A911D for ; Tue, 8 Dec 2015 01:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxIqLDeJ4PrR for ; Tue, 8 Dec 2015 01:06:39 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3F01A9117 for ; Tue, 8 Dec 2015 01:06:39 -0800 (PST) Received: by wmww144 with SMTP id w144so172619881wmw.1 for ; Tue, 08 Dec 2015 01:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W2gQhL5ox8zzjf3LRMfQ7ZfcdRMjH7KJoBuFN7K3NcY=; b=cVBNX2NeR4sprdB84FOW/VUuDXajUZPZuHCZkXOFXbd8W609bqrLrbm3mIKd11ix5k B38rsTwhCcv3Dkdl0wCihTXdYDPBcB+OM9VOAXM8nWX1pk6dAshxYAWakRYM6bIvRbf7 rA4r6CBl0+NBD4VVDip8mH0PHcIj4tscgLazpnBHjIZxhDbdvYUa+YWFZZauQZ0xTNO7 eCP0C25a2gy1S6Dj7UTyU+5YnietprmCqbx7T+E/tYMY21OEDXHfOY8KK7y2YwFJzqd5 0hE1b/fY3cTYm89JsPqIrvzzUa9266+KLT2PL43RH83+ycYM7RtxQy2g0u4qAXZYiuAq sWSw== X-Received: by 10.28.103.84 with SMTP id b81mr3033104wmc.39.1449565597745; Tue, 08 Dec 2015 01:06:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Tue, 8 Dec 2015 01:06:17 -0800 (PST) In-Reply-To: <1449511062426-94cdee34-064ef498-327458b6@fugue.com> References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> From: Linhui Sun Date: Tue, 8 Dec 2015 17:06:17 +0800 Message-ID: To: storagesync Content-Type: multipart/alternative; boundary=001a114b679c88482505265f4a2e Archived-At: Cc: Markus Unterwaditzer , Ted Lemon Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 09:06:41 -0000 --001a114b679c88482505265f4a2e Content-Type: text/plain; charset=UTF-8 2015-12-08 1:57 GMT+08:00 Ted Lemon : > Monday, Dec 7, 2015 1:45 AM Linhui Sun wrote: > > 2015-12-07 11:40 GMT+08:00 Ted Lemon : > >> I think C is the only right answer. We want conflict resolution to be > >> automatic whenever possible, but we do want to do conflict resolution, > and > >> not just wipe out changes, because those changes may contain real work > that > >> the user on client A did. > > Do you mean you want the conflict resolution to be performed every time? > If > > so, I think this might be a little bit unnecessary since a version > conflict > > is not very frequently happened (especially for some personal users). The > > case you mentioned should definitely be resolved and such > offline-to-online > > switch could be treated as concurrent conflict in my view. > > It really depends on the use case. > > > But a more frequent case is that people update their file just to replace > > the previous one, even though there are multiple people working on the > same > > file. In this case, replacing file according to modification time seems > > reasonable. So the key point is how to justify which two/more versions > > should trigger the conflict resolution to avoid wiping out real work. > > This use case is a common use case for folders that are used informally as > a way to transfer files between users. Typically each version of the file > actually has some kind of version in the filename -- e.g., "SoW 2015/11/1 > 10am Ted" and we just expect the users to manage versions. In this use > model, you definitely don't need to do anything fancy. > > However, this is a really broken use model, which exists because the tools > don't work well enough to do something sensible. They don't allow you to > track versions, they don't allow multiple committers, and they don't have a > mechanism for resolving conflicts when two people change the same version > of the file and try to upload the change. > Yes, and this use case should be considered. > > > As for the conflict resolution itself, it is very hard to achieve since > the > > system needs to handle different types of file. GoogleDocs performs well > > since it only focuses on the documents. But for a storage service, we > don't > > know what else types of file will be stored. A popular way I've seen is > > just to keep all the conflicted versions (named by different peers) in > the > > storage. > > I think this is a valid conservative way of approaching the problem. But > what makes sense to me is that the sync service be able to identify > conflicts, and that there be a conflict resolution process at a layer above > the sync service. The conflict resolution process could do something > trivial like resolving the conflict by making a new file with the same name > plus a well-understood notation like "conflict Ted/Sun 15/11/7". > > This would be similar to what people would do if there were no conflict > resolution layer. But if you have a file type for which there is already > an automatic conflict resolution process, then the conflict resolution > process can just do that resolution. There's no reason to pick a > one-size-fits-all approach to this problem. What matters is the ability > to know that a conflict has occurred based on the versioning information in > the metadata. > That's better. It seems that a separate layer for conflict resolution is well accepted. But for etag and versioning metadata, which to employ still needs to be discussed. Any comments for that? > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mellon@fugue.com > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --001a114b679c88482505265f4a2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-12-08 1:57 GMT+08:00 Ted Lemon <mellon@fugue.com>:
Monday, Dec 7, 2015 1:45 AM Linhui Sun wrot= e:
> 2015-12-07 11:40 GMT+08:00 Ted Lemon <mellon@fugue.com>:
>> I think C is the only right answer.=C2=A0 = =C2=A0We want conflict resolution to be
>> automatic whenever possible, but we do want to do conflict resolut= ion, and
>> not just wipe out changes, because those changes may contain real = work that
>> the user on client A did.
> Do you mean you want the conflict resolution to be performed every tim= e? If
> so, I think this might be a little bit unnecessary since a version con= flict
> is not very frequently happened (especially for some personal users). = The
> case you mentioned should definitely be resolved and such offline-to-o= nline
> switch could be treated as concurrent conflict in my view.

It really depends on the use case.

> But a more frequent case is that people update their file just to repl= ace
> the previous one, even though there are multiple people working on the= same
> file. In this case, replacing file according to modification time seem= s
> reasonable. So the key point is how to justify which two/more versions=
> should trigger the conflict resolution to avoid wiping out real work.<= br>
This use case is a common use case for folders that are used informa= lly as a way to transfer files between users.=C2=A0 =C2=A0Typically each ve= rsion of the file actually has some kind of version in the filename -- e.g.= , "SoW 2015/11/1 10am Ted" and we just expect the users to manage= versions.=C2=A0 =C2=A0In this use model, you definitely don't need to = do anything fancy.

However, this is a really broken use model, which exists because the tools = don't work well enough to do something sensible.=C2=A0 =C2=A0They don&#= 39;t allow you to track versions, they don't allow multiple committers,= and they don't have a mechanism for resolving conflicts when two peopl= e change the same version of the file and try to upload the change.
Yes, and this use case shoul= d be considered.=C2=A0=C2=A0

> As for the conflict resolution itself, it is very hard to achieve sinc= e the
> system needs to handle different types of file. GoogleDocs performs we= ll
> since it only focuses on the documents. But for a storage service, we = don't
> know what else types of file will be stored. A popular way I've se= en is
> just to keep all the conflicted versions (named by different peers) in= the
> storage.

I think this is a valid conservative way of approaching the problem.= =C2=A0 But what makes sense to me is that the sync service be able to ident= ify conflicts, and that there be a conflict resolution process at a layer a= bove the sync service.=C2=A0 =C2=A0The conflict resolution process could do= something trivial like resolving the conflict by making a new file with th= e same name plus a well-understood notation like "conflict Ted/Sun 15/= 11/7".

This would be similar to what people would do if there were no conflict res= olution layer.=C2=A0 =C2=A0But if you have a file type for which there is a= lready an automatic conflict resolution process, then the conflict resoluti= on process can just do that resolution.=C2=A0 =C2=A0There's no reason t= o pick a one-size-fits-all approach to this problem.=C2=A0 =C2=A0What matte= rs is the ability to know that a conflict has occurred based on the version= ing information in the metadata.
That's better. It seems that a separate layer for conflict = resolution is well accepted. But for etag and versioning metadata, which to= employ still needs to be discussed. Any comments for that?


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com

_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync


--001a114b679c88482505265f4a2e-- From nobody Tue Dec 8 08:54:47 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E6D1A877F for ; Tue, 8 Dec 2015 08:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtxquIw-n4uR for ; Tue, 8 Dec 2015 08:54:44 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9F91B305F for ; Tue, 8 Dec 2015 08:54:06 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14495936418780.5364736954215914" From: Ted Lemon To: lh.sunlinh@gmail.com In-Reply-To: References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> Date: Tue, 08 Dec 2015 16:54:01 +0000 Message-Id: <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> MIME-Version: 1.0 Archived-At: Cc: storagesync@ietf.org, markus@unterwaditzer.net Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 16:54:46 -0000 ------sinikael-?=_1-14495936418780.5364736954215914 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 8, 2015 4:06 AM Linhui Sun wrote: > That's better. It seems that a separate layer for conflict resolution is > well accepted. But for etag and versioning metadata, which to employ = still > needs to be discussed. Any comments for that=3F Both can be made to work in theory, but etag is missing explicit versioning= , so in order to get conflict detection and avoid amnesiac servers erasing = data on clients, you pretty much need to build up a metadata versioning = system anyway. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14495936418780.5364736954215914 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZwsqCRAMw8Nu0HeKywAAU3wH/i9l6EEKnlPU/JJEbbsl WgHBYago4K37uY27gJ9x7/ylTVkG3M3reuUiN+DgHluY+KNbp22qyV7eHy9m Jr9nW++bnpSjL+MCfxv8Nhk0Dkf092xeb6M8jB291HDR6fsAsJ7xtwWBxvjF wOUln7M35w0VqFVtOT0sczEQGCPQnwlOYnueVU59Jdceww6X9nQSaKpGeKu0 pniHXY3JPYbUtLHQIKQt1Bufd4GcChWLtObgUbeu0InX31rsl3hlOqjZyevS M3i14ksAUCtGV0VVaSWcFe55cy1ZONGeuwQNak4/HCUlySXVPzLda/jWlRb7 2FNTD0MNGd6//4fXGQV4IlE= =uPX4 -----END PGP SIGNATURE----- ------sinikael-?=_1-14495936418780.5364736954215914-- From nobody Tue Dec 8 10:59:32 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35991A1B5A for ; Tue, 8 Dec 2015 10:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgDPkriLqQjx for ; Tue, 8 Dec 2015 10:59:28 -0800 (PST) Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2994F1A1B59 for ; Tue, 8 Dec 2015 10:59:27 -0800 (PST) Received: (qmail 3380 invoked from network); 8 Dec 2015 18:59:24 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 8 Dec 2015 18:59:24 -0000 Date: Tue, 8 Dec 2015 19:59:22 +0100 From: Markus Unterwaditzer To: Ted Lemon Message-ID: <20151208185922.GA9531@localhost.localdomain> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: lh.sunlinh@gmail.com, storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 18:59:31 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 08, 2015 at 04:54:01PM +0000, Ted Lemon wrote: > Tuesday, Dec 8, 2015 4:06 AM Linhui Sun wrote: > > That's better. It seems that a separate layer for conflict resolution is > > well accepted. But for etag and versioning metadata, which to employ st= ill > > needs to be discussed. Any comments for that? >=20 > Both can be made to work in theory, but etag is missing explicit versioni= ng, > so in order to get conflict detection and avoid amnesiac servers erasing = data > on clients, you pretty much need to build up a metadata versioning system > anyway. Per-file conflicts can be detected with just etags. In the case of file-sync this is often the only thing you can do, since conflict-resolution depends = on the filetype. Dropbox stores both copies in such cases. I'd say this is reasonably efficient for average usecases. Something like a three-way merge could also be done with just etags, but doubles storage usage on the clientside. >=20 >=20 > -- > Sent from Whiteout Mail - https://whiteout.io >=20 > My PGP key: https://keys.whiteout.io/mellon@fugue.com > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWZyiJAAoJEDHp7/n6rHiM4pkH/3f+7N2O9m++whOu26Ki6Pl/ 0aXYuMUVcOOhv09SM8AEb7p7n9HkONk7kLsaB3W6YoiW0HHDnd+QuDsAyMrDCOHX sLNz47PE4ZOhaciR5/rxNG7JR8cJb4ScG4VzEC8QUOF9pdldnQrb9q2ejoDKEUBL SM4H9SeqCtMKohy9lseDj4zhfp8pnYLibZrlziOOneh/lTRDNrsHh2YBcqyly9up Q6ldrk9dVl0Ij9dS01MFQgri+1zxbCCNE5I67B9ttm2c/11FWKxuiUCHsTKOFHV5 x7KuVEBiq4DwjzKFaUa+d+ugr5hjjyQyB417jlP4Gv0zMpIfiOy7KA+AKbfQVJk= =91H4 -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From nobody Tue Dec 8 13:25:45 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE301A87C7 for ; Tue, 8 Dec 2015 13:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuQr4VSHkyxt for ; Tue, 8 Dec 2015 13:25:42 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 02F491A8789 for ; Tue, 8 Dec 2015 13:25:41 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14496099374990.12356394552625716" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <20151208185922.GA9531@localhost.localdomain> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> Date: Tue, 08 Dec 2015 21:25:37 +0000 Message-Id: <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:25:44 -0000 ------sinikael-?=_1-14496099374990.12356394552625716 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tuesday, Dec 8, 2015 1:59 PM Markus Unterwaditzer wrote: > Per-file conflicts can be detected with just etags. In the case of = file-sync > this is often the only thing you can do, since conflict-resolution = depends on > the filetype. Dropbox stores both copies in such cases. I'd say this is > reasonably efficient for average usecases. Can you explain how per-file conflicts can be detected using etags=3F -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14496099374990.12356394552625716 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWZ0rSCRAMw8Nu0HeKywAAKpgIAItRaPzgIQqhuwlYPTIk QnpOfHNQ8kH1kxtRo62U4m+0+9a9AyNtED7Z8IufcMKXSXqYdkYsh4fCXjii NUkyefp9AwToI5b+B89BOKb5MlSdfMw9vD11t2eD1d2DZTIWBmhnDMuMLOfL j+8ta3ygLWN2bFlD3eQs/59njJRgZGJmOz4HLUwKdkUXDBXHi7i6cWqaKjS7 71Ug23vQ1VNDZhZTGcDWXPts1OlacWbWpw3m1LZ/9//O9gi+EtF2jpLuRG8Y i3n0R8XJWLnedHsGbVewgE5/FE6IN3CfSgjI8DLBSPJ1n4OUPwWVnein8cz8 E/R8FB3erM1w7mKPAHwDhKc= =JLbb -----END PGP SIGNATURE----- ------sinikael-?=_1-14496099374990.12356394552625716-- From nobody Wed Dec 9 06:11:10 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FCD1B2BA2 for ; Wed, 9 Dec 2015 06:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmFwesWMKG_b for ; Wed, 9 Dec 2015 06:11:07 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id CEC841B2B99 for ; Wed, 9 Dec 2015 06:11:06 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14496702624510.8249951843172312" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> Date: Wed, 09 Dec 2015 14:11:02 +0000 Message-Id: <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:11:09 -0000 ------sinikael-?=_1-14496702624510.8249951843172312 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 9, 2015 7:22 AM Markus Unterwaditzer wrote: > By file-conflict I mean just the condition that both remote (the server) = and local (the sync client) have changed since the last sync, and it is = therefore undecidable which version of the file to use. Sure. This takes care of the most trivial case of a conflict, but does = not retain enough information to detect interleaved conflicts, where for = example one client makes a change based on version X of the file, a second = makes a change based on version X+1, the second one commits, and then the = first one commits. In your case, automatic conflict detection would undo = changes in the file that had been made between versions X and X+1, because = neither the client nor the server has any record of what the sequence of = changes was. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14496702624510.8249951843172312 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWaDZ2CRAMw8Nu0HeKywAA+TEIANOpF8d76ea6jyleCWFt JQw6IDk1Rf53qJWiQW/Xk837LQuYf9fy2OQQlHMy1MsiMHy9hdP0qzo4CzZN DWkUCU/9S09G2wyzR5BxEgEAhSJCkM6BXXkgKMQ3mycjQ0+xmZUyrzCTh0Li 4madgkh+TTU1dKXmkJMk1tA8jRhrc1M4LIVfnxv18lxfBab7stenf9NSDPJf bvSotr/wK2u6sQoLfkRveTPhd/URFfR6Sp2/xwUafFcEicQ6kn5wlKn9cZOp fSys44KMwu6+r2FshL4+aMBdD6AtNgLihsjuWZs/P4oac+bYtT5q5zupQyOo dOAoruSvE58UxZRVgoAplQ0= =gMLM -----END PGP SIGNATURE----- ------sinikael-?=_1-14496702624510.8249951843172312-- From nobody Wed Dec 9 06:22:42 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39351B2BD7 for ; Wed, 9 Dec 2015 06:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCPxQAJgUExn for ; Wed, 9 Dec 2015 06:22:36 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0605.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::605]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92E21B2BD5 for ; Wed, 9 Dec 2015 06:22:35 -0800 (PST) Received: from DB4PR06CA0034.eurprd06.prod.outlook.com (10.160.40.162) by DB4PR06MB412.eurprd06.prod.outlook.com (10.141.236.21) with Microsoft SMTP Server (TLS) id 15.1.337.19; Wed, 9 Dec 2015 14:22:14 +0000 Received: from DB3FFO11FD026.protection.gbl (2a01:111:f400:7e04::184) by DB4PR06CA0034.outlook.office365.com (2a01:111:e400:9851::34) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Wed, 9 Dec 2015 14:22:14 +0000 Authentication-Results: spf=pass (sender IP is 188.184.36.48) smtp.mailfrom=cern.ch; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=cern.ch; Received-SPF: Pass (protection.outlook.com: domain of cern.ch designates 188.184.36.48 as permitted sender) receiver=protection.outlook.com; client-ip=188.184.36.48; helo=CERNMX12.cern.ch; Received: from CERNMX12.cern.ch (188.184.36.48) by DB3FFO11FD026.mail.protection.outlook.com (10.47.217.57) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Wed, 9 Dec 2015 14:22:13 +0000 Received: from cernfe02.cern.ch (188.184.36.47) by cernmxgwlb4.cern.ch (188.184.36.48) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Dec 2015 15:21:59 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE02.cern.ch ([fe80::bc89:8f4e:8731:2c47%13]) with mapi id 14.03.0174.001; Wed, 9 Dec 2015 15:21:58 +0100 From: Jakub Moscicki To: Ted Lemon Thread-Topic: [Storagesync] Storagesync Digest, Vol 5, Issue 1 Thread-Index: AQHRLH0+7gCKX1UFx02QDZgdWy/v7563OhsAgAArgwCAAAZPgIAAAsoAgAAiFACAAVlOAIAACqEAgAACRoCAAAS6AIAAC86AgAAAVQCAAAIgAIAAPLWAgAHN3gCAAA3lAIAB4XiAgAAwgYCAAPsvAIAAb/IAgAAAzwCAAAM9gIAAAb8AgAADTgCAAAE9AIAABBwAgAAHaICAAAtbgIAAAxyAgAAesin///WngIAAM7sAgAC71wCAAP3bgIAAgq+AgAAjBgCAACjcgIABKcH+///yNgA= Date: Wed, 9 Dec 2015 14:21:58 +0000 Message-ID: <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> In-Reply-To: <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:1458:202:225::101:5ec0] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD026; 1:n6CbvtbkC0a+dqU8WmnxJzQyde320nkSaXZ7pGDc9FgApgbmWUdSZgonk8sD5bSvjtxr6S6wo9rB0qaSXMy1Gl+1mhxl8ITJHg/0gOBZ7dZudqhflljB7/wFqUjzkBGnbr/cOIU1OtB1KNyRLyRFAVU0kBQaSbKx2NAhqYq+5YanM7bcsWKe7C+ldie3NkY6l7oJROTL0Ga78s3nu7Jd9PYPja5KncgT2tvlJQL8KdNfKV4oVSejD+OPcL3RkpB0/E2QQkuql95iy1mLUMv/S4NTX4U1s7Rcl3NmYA2p0u8Ljtn2sIMzmlFFOFTERHMnHk18qp6hiMDiZMycq4M8QLUGziBZIkYFGQGL8NE0B8fHBWfKGqTfDrbeU6cPXjsQtG1zIW0rdXZujbJCRm+VqDCKCXjOY33GAVQlIha2I+E= X-Forefront-Antispam-Report: CIP:188.184.36.48; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(10533003)(24454002)(199003)(18543002)(189002)(5403001)(377454003)(5001970100001)(2900100001)(5008740100001)(86362001)(93886004)(50986999)(2950100001)(6806005)(83716003)(76176999)(5004730100002)(15975445007)(5250100002)(586003)(74482002)(16796002)(87936001)(19580405001)(82746002)(5003600100002)(54356999)(1220700001)(19580395003)(23676002)(53416004)(26826002)(36756003)(1096002)(92566002)(189998001)(110136002)(6116002)(50466002)(11100500001)(47776003)(33656002)(106116001)(102836003)(106466001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR06MB412; H:CERNMX12.cern.ch; FPR:; SPF:Pass; PTR:cernmx12.cern.ch; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB412; 2:G62YWOmCVcJvF+axzjtnY3CzqLbVGzQHBkAa+RAn5V5KW9+KxduYPR2OhQW5HLWf/RkfMT9DBHwN/jcRrEAABDlzC9nPaMttmxpH1cqGeIuD/JoCZkwWtzuPQhnYUNWYwYp0gdndCqXjzWG6ip7F/A==; 3:r4vUXzUrho+3psS729Ei5WCmvoUGUwY/oZozHZyRAEGpZdy10FVPIzo22rraIzu8Ea2KFMfS7y2xbzrd5yACFpYUn9e8TEDrt8fBrFl59s4JMX8NDKz2XDsUQFAX47E5C63MmuioyKm8+dPLoMFi2xmPAO1x8wzVpBKiC/1FP3fRmCDILA4R9g7bkPrIe6Fq4giZoVGP7HpuGHj3f2s5tRXlRr/UwwquWTGxxXsqUhWQvVb2lrmP/ASs/HqyWV60wTev5ankwBvd/WbWcXMhlQ==; 25:kZmjst2P5rACsS1nbukC2JLTPk8+zjiPCsA8uERSinNkzpg7YJUR/Bb2TNRLQ2PbMzoqCSsRFlh9uo066xa0qaxMSVqING/utx2WHf7pRArsLku3TzwPu8ZjCFgaKg5zgyklnaHus5Baq8xdHOKw5iL+abMQxHTqVgBr7ejf9wJ6Qzn2fVEyv0w0CLjNLSGaqYebptmWMImHIbIu9zOuvLN3P4xe07RheOQLtQYqkv4nJtxXxLf+NQIP807dfHOil1ogVgKK51191NxEHkDCpA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DB4PR06MB412; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB412; 20:STr3feXLXQ/ClpqKQmK9JD2eR73aJ+lvaRRUR1q4Y4Nm0w/7UfYxvUeVAVeh2wsxIsb6BzMiDb6gt/ZG1rNjvsKMT9YAEHD0taxkJhWKSh5V10MX5OL6gOafarFBDPJgdO+9TQEjzt4pQjLJ4kf0y9ABWBOaL8sPHhi2Ye47/FbZuWbjVjCrBqDvKJMyQRFMti4x9xKa+Nyte4Z2nr7FRVwH+q2s65v62iDewhjjefGU2X76nrXirG+Tw0yRv7oWMj9wzH7iro5RgLfC6v85tQk1WaVwgC/zylJB13HDsMo/RQY22ej28+EtApFqzHMeaXLSLJZbQjYHE+K7hrfHNIX2GAyXLcA84NLb3+gQu7e70iD1TH4W8LlRXnQRVF/XwC2J4Duda7Xxw4AKqmGzvPx84a8AeeGnzzf6uODNyL8oFAv/y7hLcSpEHmvRN++FkfSRCLQT3ZiZTGfJNsxwWkWUTdEDASJxy3KOUcFe8vPkpo7mFLS74BGDMKOQ27FG; 4:VGPN2x4bu5Ut4/6TfLUvR19pBCEi5qoQvJlBCvjkO14i7wbR24LReMl1hlU8DK+9M84d72jtd0xeLBs5fcZLD62ms9g8VrPkn990+dhQoDXlZyAS5ZDJQ1fMleChBrJ01Muz+w1zt++WJI24AK5VWZ9qkHYig7zXd1RRfc4OMDtkjctoIIdjj4/C9EuwB6QqPYHlCCvE2P0nNCVVeY+aOJceDi3ZA2Sys5Xt5DbbjkORSWOX1HvGFnG6qODpWLO3n3H/dhY8cewfC2dleRaOpUGNIB6jJFZ4IoS7Yy4iMCyXSnqUr+zpgy9kXX/3C9XrEqE16dXSs0ZuSG3VjJXZOkWLe+IjP+xG+MVWn13stqQtHC4frOznbQ4XhgggQxJ8 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:DB4PR06MB412; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB412; X-Forefront-PRVS: 0785459C39 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjRQUjA2TUI0MTI7MjM6S01Vdkh5bGxxcmRHU2o4Tm4zZGkrV1YxeHcz?= =?utf-8?B?TXlpdi9pa3pvSFJITmZoc1I3ZWx2V203RjYveFRJekVzYi9jYUpmZHhHaFBP?= =?utf-8?B?ZTNrUXh1SG1yV2xpS3VCV3MyQTNRbzZVaWRJUHY1KzU1bUNXZ1dGcUpmcm0x?= =?utf-8?B?Q3JhcytZK1NVd0lWdmQ1d0d2d2ZYODRWRm1WY2NRUVNZVVhiVUkvOXp1c3lU?= =?utf-8?B?cVc3YkZDalhxc0h5RDcxVS9ORVhIQ0Rxc21wemcyMVdzWDFldGhwWWJWMVox?= =?utf-8?B?YmphcmVRS1FxT0F6TUowRnAxbVhoQ1IzNExjaXV4ZTZxWVNLeEhJQTFjZ1lQ?= =?utf-8?B?bk0waEtRZld6RW1TK3hzM1NoWGo0VDJsMWdKTDgvV1g3QWRmMUhXbUlHMEYr?= =?utf-8?B?U3ArZUJTZ1lkbzE2MUVwd2RVWlE1K1pFVzRNS1VTdkJDUmxuM3dheUkzaEZQ?= =?utf-8?B?RUszRnh5ckErUUNEeVNsSnZFSEJiTWNvSkI2WDNEcHdPVUhpeWhPTnpqS0JO?= =?utf-8?B?MG1XblJOY1lMTzZCdDJHQzhpKzEvWi9wWnZLRDE4TTcyN3g4WitTd2tzSk5z?= =?utf-8?B?RGlFSkJPYUFuVVEzc2VVZ2cxRnFTa2cvL3FtM3hWUjVRQmJlZlNYRXlxNFRr?= =?utf-8?B?VjdwOFBMUWYyYkdMdWlTVHZmODVJeUpzRDhhS3FPaGI2MWU3UThsdVdPT0FO?= =?utf-8?B?Ly81R01Sa1FzVWtaNlg2NnNTazh5Z3ptbUdub0JVM3BzOGcrTmhPd3lRYUhy?= =?utf-8?B?QUEyRjlYVTZON0Y4YmFJRGVrNWMya3dVV1VDdHAzMFFHTjZFT1htckx1TkFP?= =?utf-8?B?OFE5QjdHa01CSGtENlg1S0dQa2J0OWpZaGd4OVhBdThqd0hsSEVJSGlVS1RV?= =?utf-8?B?clNGQm1RZ0tqYjFSTERlb1p4VDF4ZUhyU3ZPcVp1UFowTkp6OGR0Vm5uek1m?= =?utf-8?B?UnlRQUx2eXhqaDNpbi91T3d6eHRBc3J1TEZ3NVFCbkJBRURkaHJkRStsWUNF?= =?utf-8?B?dWRMaWxjaXVBSlc4UkFLYkczVXVOZXllWFYwKy9uVWFwV09ZVkdLby9yTXlX?= =?utf-8?B?REhlM1c5aENGai95SlR0VGxSMzVXMmtVakI1cS84UVJLNTRZMldweXFYcWI2?= =?utf-8?B?bE5yUVRKL2crakVTN1RYUmhtZUFHdy9UK21TK1JuTkRpbjhOdkh3Q3lrSkpR?= =?utf-8?B?WkRkOTVmZVR1ZEFEckdqaHBVanJpMnk1eEdKZXBTWGIzcVJoNW1CS0hwcHBq?= =?utf-8?B?aE9Rb0tYdFdVVUdkL29XMWlrM3FPRkI5MnlNaGJDcnN1NVRqbXdsajJTSE1q?= =?utf-8?B?K1NVeC85ZkQ2NDc2OGsyeGVqUm5zUUZiY2FrUHFJZmJKQ0xjZXF2WmtsVlcx?= =?utf-8?B?VjlOc1FZbTRSMm9uRVlGdWJUaXVrVzJyWE1na1p1R0p6VUk0MndRTUE4b3Zk?= =?utf-8?B?aGorUzBJN0lUR1I4VjIycWwxcXlKeFV6VGNxdC95Zk1pcjRXTFIzRlorbHpB?= =?utf-8?B?WjhIRnFESEZwcDhBdkZKZHpyNWNLUVRMenVUODBETVhPdVVKZ3RSYTdsaTJr?= =?utf-8?B?MFlOVU9jY1JXR2RzV1k4bTdVWDkzZ2h0bEVBRjI4S0Q5clBVcU56SmFoNkw4?= =?utf-8?B?eE40d3hkT0JYdENiY0hsY1dvNHNzbnBIVUN5UjRQZlJTeXV3ZWd5YlJVakJk?= =?utf-8?B?ak5VTXlrSzdTMnVQcmxMbWxoSVBDUFh1clM4RnJKcWR2UEcrQnZTS1N1djRs?= =?utf-8?Q?PRQCu+ccgs33A0528/hI55Ed0yhv0YaNSAt8=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB412; 5:peUKAAp/kEos1bRl71smsJ+AP+E+JYOo8865kTsWspo7QykQgBf7M1panng1FFZ30tmelJm3hE2GGNfH8zNY44dpbYpeXO7K1qeOkBT845YIu264zUHos328xeJ9KsVLoH5JDatBYaAewPbD9PcEiA==; 24:mBwcGEHyQ1IHfRgm2h/69I/P+rvQn/ktus1c83X8RtwXI6NQBp/3lcJNHYimdWhUQb5u4sZj3ikftCscVxmIlYmDgCW0IfgSzP7ssroZmXI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2015 14:22:13.7852 (UTC) X-MS-Exchange-CrossTenant-Id: c80d3499-4a40-4a8c-986e-abce017d6b19 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c80d3499-4a40-4a8c-986e-abce017d6b19; Ip=[188.184.36.48]; Helo=[CERNMX12.cern.ch] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB412 Archived-At: Cc: "storagesync@ietf.org" Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:22:41 -0000 VW5sZXNzIHlvdSB3YW50IHRvIGRpZyBpbnRvIHRoZSB0eXBlIG9mIHRoZSBmaWxlIGFuZCBleHBs b3JlIGl04oCZcyBpbnRlcm5hbCBzdHJ1Y3R1cmUgdG8gbWVyZ2UsIHRoZSBiZXN0IHlvdSBjYW4g ZG8gaXMgdG8gbWFrZSBzdXJlIGEgdmVyc2lvbiBvbiB0aGUgc2VydmVyIGlzIGdlbmVyYXRlZCBm b3IgZWFjaCBjb25mbGljdCBmaWxlIGFuZCB0aGVzZSBtYXkgYmUgZWFzaWx5IGFjY2Vzc2libGUg Zm9yIG1hbnVhbCBtZXJnZSBieSB0aGUgaW50ZXJlc3RlZCB1c2Vycy4gRm9yIHRoaXMgZXRhZ3Mg YXJlIHN1ZmZpY2llbnQuIEZyb20gdGhpcyBwb2ludCBvZiB2aWV3IHRoZXJlIGlzIG5vIGRpZmZl cmVuY2UgYmV0d2VlbiBjb25mbGljdHMgd2hpY2ggYXJlIGdlbmVyYXRlZCBiZWNhdXNlIHR3byBj bGllbnRzIHVwZGF0ZSB0aGUgZmlsZSBhdCB0aGUgc2FtZSB0aW1lIChzbyBjb25mbGljdGluZyB1 cGxvYWRzIG92ZXJsYXBwaW5nIGluIHRpbWUpIGFuZCBhIGNhc2Ugb2Ygb2ZmbGluZSBjbGllbnQg d2hpY2ggZWRpdHMgbG9jYWxseSBvdXRkYXRlZCB2ZXJzaW9uIChuZXdlciB2ZXJzaW9uIGF2YWls YWJsZSBtZWFud2hpbGUgb24gdGhlIHNlcnZlcikgYW5kIGNvbnNlcXVlbnRseSB1cGxvYWRpbmcg aXQgd2hlbiBvbmxpbmUgYWdhaW4gKHNvIGNvbmZsaWN0aW5nIHVwbG9hZHMgbm90IG92ZXJsYXBw aW5nIGluIHRpbWUpLiBJbiBib3RoIGNhc2VzIGl0IGxvb2tzIHRvIG1lIGdvb2QgZW5vdWdoIGlm IHRoZXkgZW5kIHVwIGFzIHZlcnNpb25zIG9uIHRoZSBzZXJ2ZXIgZm9yIG1hbnVhbCB1c2VyIG1l cmdlL3JldmVydC4NCg0Ka3ViYQ0KDQotLQ0KDQo+IE9uIDA5IERlYyAyMDE1LCBhdCAxNToxMSwg VGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPiB3cm90ZToNCj4gDQo+IFdlZG5lc2RheSwgRGVj IDksIDIwMTUgNzoyMiBBTSBNYXJrdXMgVW50ZXJ3YWRpdHplciB3cm90ZToNCj4+IEJ5IGZpbGUt Y29uZmxpY3QgSSBtZWFuIGp1c3QgdGhlIGNvbmRpdGlvbiB0aGF0IGJvdGggcmVtb3RlICh0aGUg c2VydmVyKSBhbmQgbG9jYWwgKHRoZSBzeW5jIGNsaWVudCkgaGF2ZSBjaGFuZ2VkIHNpbmNlIHRo ZSBsYXN0IHN5bmMsIGFuZCBpdCBpcyB0aGVyZWZvcmUgdW5kZWNpZGFibGUgd2hpY2ggdmVyc2lv biBvZiB0aGUgZmlsZSB0byB1c2UuDQo+IA0KPiBTdXJlLiAgIFRoaXMgdGFrZXMgY2FyZSBvZiB0 aGUgbW9zdCB0cml2aWFsIGNhc2Ugb2YgYSBjb25mbGljdCwgYnV0IGRvZXMgbm90IHJldGFpbiBl bm91Z2ggaW5mb3JtYXRpb24gdG8gZGV0ZWN0IGludGVybGVhdmVkIGNvbmZsaWN0cywgd2hlcmUg Zm9yIGV4YW1wbGUgb25lIGNsaWVudCBtYWtlcyBhIGNoYW5nZSBiYXNlZCBvbiB2ZXJzaW9uIFgg b2YgdGhlIGZpbGUsIGEgc2Vjb25kIG1ha2VzIGEgY2hhbmdlIGJhc2VkIG9uIHZlcnNpb24gWCsx LCB0aGUgc2Vjb25kIG9uZSBjb21taXRzLCBhbmQgdGhlbiB0aGUgZmlyc3Qgb25lIGNvbW1pdHMu ICAgSW4geW91ciBjYXNlLCBhdXRvbWF0aWMgY29uZmxpY3QgZGV0ZWN0aW9uIHdvdWxkIHVuZG8g Y2hhbmdlcyBpbiB0aGUgZmlsZSB0aGF0IGhhZCBiZWVuIG1hZGUgYmV0d2VlbiB2ZXJzaW9ucyBY IGFuZCBYKzEsIGJlY2F1c2UgbmVpdGhlciB0aGUgY2xpZW50IG5vciB0aGUgc2VydmVyIGhhcyBh bnkgcmVjb3JkIG9mIHdoYXQgdGhlIHNlcXVlbmNlIG9mIGNoYW5nZXMgd2FzLg0KPiANCj4gDQo+ IC0tDQo+IFNlbnQgZnJvbSBXaGl0ZW91dCBNYWlsIC0gaHR0cHM6Ly93aGl0ZW91dC5pbw0KPiAN Cj4gTXkgUEdQIGtleTogaHR0cHM6Ly9rZXlzLndoaXRlb3V0LmlvL21lbGxvbkBmdWd1ZS5jb21f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTdG9yYWdl c3luYyBtYWlsaW5nIGxpc3QNCj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KDQo= From nobody Wed Dec 9 06:35:44 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852FB1B2BFA for ; Wed, 9 Dec 2015 06:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_GJRpFzgVBL for ; Wed, 9 Dec 2015 06:35:41 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id D5AE81B2C03 for ; Wed, 9 Dec 2015 06:35:39 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14496717330090.24760120688006282" From: Ted Lemon To: Jakub.Moscicki@cern.ch In-Reply-To: <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> Date: Wed, 09 Dec 2015 14:35:33 +0000 Message-Id: <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> MIME-Version: 1.0 Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:35:42 -0000 ------sinikael-?=_1-14496717330090.24760120688006282 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wednesday, Dec 9, 2015 9:21 AM Jakub Moscicki wrote: > Unless you want to dig into the type of the file and explore it=E2=80=99s= internal structure to merge, the best you can do is to make sure a version= on the server is generated for each conflict file and these may be easily = accessible for manual merge by the interested users. For this etags are = sufficient. From this point of view there is no difference between = conflicts which are generated because two clients update the file at the = same time (so conflicting uploads overlapping in time) and a case of = offline client which edits locally outdated version (newer version = available meanwhile on the server) and consequently uploading it when = online again (so conflicting uploads not overlapping in time). In both = cases it looks to me good enough if they end up as versions on the server = for manual user merge/revert. Most files are text files, which are easy to merge, so yes, I do want to be= able to dig into the structure of the file. Even when the file isn't = =22easy to merge,=22 e.g. a sound file or a drawing, knowing the order of = the changes can be very helpful when someone is doing a manual merge. And= you can build merge tools for commonly-merged files; if conflict detection= is a feature of the data store, then there's an incentive to build such = tools, whereas if everybody is accustomed to dumb data stores that don't = provide this feature, there's no point in making merge easy. The absence of this feature is a serious problem in my workflows; I don't = know if your experience is similar. I don't really see any point in = inventing =22yet another=22 storage sync mechanism that doesn't provide = this feature. E.g., do you really want a calendaring system that = automatically re-adds files that have been deleted on one client when a = second client connects that hasn't seen the deletion=3F An address book = that backs out updates=3F A mail system that undeletes deleted messages, = or deletes messages on the client that were lost on the server due to a = crash=3F The use case of a small collection of large files used entirely = sequentially is easy to address, but (a) not very interesting and (b) not = actually a common use model. It =5Fseems=5F common because we don't = provide anything better, and so people make do with it, but it doesn't = actually fit with what they are doing. If it did, we wouldn't see the = proliferation of manually-labeled versions of the same file that is so = common in such data stores. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14496717330090.24760120688006282 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWaDw1CRAMw8Nu0HeKywAA0MYIALSsyv/j/VGzb7UcK9oA pPZJpKNT9mo4YfInvkdL/qwjXobDqEjuVyx7Gdjcp1SmlfEeaDy4C0PBwC// z70MoJCsNQXUF3gpJmKy2zj+9T8EmwCKO44AqeX6SOgZ1pxlGnzDO2M09pFw rANJcq0bpKwpd6S/v9pRCql+e1cGBenODPDGwQiugPyJUq/wI6N/Y9cGZqd2 ZypaxZDQRuSin4mGGIzccKykkzjNpg+76ARMCvDEd1Jv8K0bSitRGh0EiQ0z gq0VIJMjR3bTze8Oi3iOkHOY4D8S2ubEch2zUlSaBZcF1Sb2CDatITTzlNTH +BKwv6lZ3aC50aiY6Sa32mI= =ZH9h -----END PGP SIGNATURE----- ------sinikael-?=_1-14496717330090.24760120688006282-- From nobody Wed Dec 9 06:43:43 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF551B2C60 for ; Wed, 9 Dec 2015 06:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idQbT6v_WSdq for ; Wed, 9 Dec 2015 06:43:39 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id A44211B2C42 for ; Wed, 9 Dec 2015 06:43:13 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14496721898680.6299764064606279" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> Date: Wed, 09 Dec 2015 14:43:09 +0000 Message-Id: <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:43:41 -0000 ------sinikael-?=_1-14496721898680.6299764064606279 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable BTW, it occurs to me that at CERN you deal a lot in very large data sets = which are created once and never modified, because they are records of = physical events. So the idea of merging might not seem all that important,= because you will never do it on these data sets. However, one thing that a good versioning system allows for that I think = you should consider important is the ability to avoid accidentally losing = data. When you have really big data archives, one of the things that you = want to do for redundancy is keep multiple copies. If one instance gets = corrupted, you want to be able to detect that, and you want to be able to = avoid losing other instances of the file if the file is lost from an = instance of a folder. The most reliable way to avoid that is to keep = versioning metadata. Multiple copies of versioning metadata are very = useful for forensic analysis when something goes wrong, as well. Additionally, while the bulk of the actual =5Fdata=5F that CERN stores is = really big files, the little files matter just as much--the work = researchers are doing, particularly collaboratively. Enabling efficient = collaboration on articles in progress, enabling effective sharing of code, = and so on, all are very important despite representing a tiny percentage of= the total data stored. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14496721898680.6299764064606279 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWaD3+CRAMw8Nu0HeKywAAxTgIAJ9z+Y27WiNQrLX2M/HH h5BJe98J1vmJANY3KqfWJlDEdEneMIANCmtatZRKEix9SfL7GW2Fq9zTnGr5 Iz0kpMZZjgYUCOaZbhj8LuEbC7BytZWVUiSs7CSeLcJL8joC+S75nm9Bryw2 maKZTsJw6ME0p/4+qyCkcpQz0ufcC/O0swYVpp0kt9pCREtbDXNBPlRuHj8r GdbtXQsIO32SuqvHqqCVaCSIZ7lG+SiGy7cMpwEVVNUawx8vyZJw+9FvRyWP 6SZ/BBBqs+GnhgjsrXcgFrB4QbIBwNI+44i7TPSer00q4ED0rrw8VL2w0D78 ussPU0K8wbP6P3o5Lgy7aUY= =fcef -----END PGP SIGNATURE----- ------sinikael-?=_1-14496721898680.6299764064606279-- From nobody Wed Dec 9 06:44:56 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B311B2C30 for ; Wed, 9 Dec 2015 06:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4myj-JeLw6t for ; Wed, 9 Dec 2015 06:44:51 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CFCCF1B2C8A for ; Wed, 9 Dec 2015 06:44:03 -0800 (PST) Received: from [192.168.1.111] (modemcable093.65-160-184.mc.videotron.ca [184.160.65.93]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2919347670; Wed, 9 Dec 2015 09:44:03 -0500 (EST) From: "Marc Blanchet" To: "Ted Lemon" Date: Wed, 09 Dec 2015 09:44:02 -0500 Message-ID: <3A341032-4229-485C-9107-275968F581D1@viagenie.ca> In-Reply-To: <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_28B2CF00-030D-427E-B26C-C3FB97FCEF93_=" X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: Jakub.Moscicki@cern.ch, storagesync@ietf.org Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:44:53 -0000 --=_MailMate_28B2CF00-030D-427E-B26C-C3FB97FCEF93_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable On 9 Dec 2015, at 9:35, Ted Lemon wrote: > Wednesday, Dec 9, 2015 9:21 AM Jakub Moscicki wrote: >> Unless you want to dig into the type of the file and explore it=E2=80=99= s = >> internal structure to merge, the best you can do is to make sure a = >> version on the server is generated for each conflict file and these = >> may be easily accessible for manual merge by the interested users. = >> For this etags are sufficient. From this point of view there is no = >> difference between conflicts which are generated because two clients = >> update the file at the same time (so conflicting uploads overlapping = >> in time) and a case of offline client which edits locally outdated = >> version (newer version available meanwhile on the server) and = >> consequently uploading it when online again (so conflicting uploads = >> not overlapping in time). In both cases it looks to me good enough if = >> they end up as versions on the server for manual user merge/revert. > > Most files are text files, which are easy to merge, I don=E2=80=99t agree with that statement. A lot of files nowadays are = complex text files in a complex format (docx, odt, =E2=80=A6). Not easy t= o = merge. Not at all. (I don=E2=80=99t have statistics, but my guess is that= 90% = of shared files are not plain text files) > so yes, I do want to be able to dig into the structure of the file. = > Even when the file isn't "easy to merge," e.g. a sound file or a = > drawing, knowing the order of the changes can be very helpful when = > someone is doing a manual merge. And you can build merge tools for = > commonly-merged files; if conflict detection is a feature of the data = > store, then there's an incentive to build such tools, whereas if = > everybody is accustomed to dumb data stores that don't provide this = > feature, there's no point in making merge easy. > > The absence of this feature is a serious problem in my workflows; I = > don't know if your experience is similar. I don't really see any = > point in inventing "yet another" storage sync mechanism that doesn't = > provide this feature. E.g., do you really want a calendaring system = > that automatically re-adds files that have been deleted on one client = > when a second client connects that hasn't seen the deletion? An = > address book that backs out updates? A mail system that undeletes = > deleted messages, or deletes messages on the client that were lost on = > the server due to a crash? you are giving a good example of something vastly different. Calendering = is a very well structured and very limited dataset (compared to free = text) that was made by design with sync considerations. The latest = version of vcard was also designed with sync considerations, and it took = a lot of time to get it right, (I can tell you I was the chair of = vcarddav when we did this). And a vcard is a pretty simple dataset and = very structured. So I think your point just shows the inverse. Merging complex, free, not = structured-limited-dataset files is very very difficult. I guess your goal is great, but to me, that is for research. So if = people want to do this work, I would split it into two working groups: - one on the IRTF side about generic sync-merge algorithms - one on the IETF side for the protocol components. Marc. > > The use case of a small collection of large files used entirely = > sequentially is easy to address, but (a) not very interesting and (b) = > not actually a common use model. It _seems_ common because we don't = > provide anything better, and so people make do with it, but it doesn't = > actually fit with what they are doing. If it did, we wouldn't see = > the proliferation of manually-labeled versions of the same file that = > is so common in such data stores. > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: = > https://keys.whiteout.io/mellon@fugue.com______________________________= _________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync --=_MailMate_28B2CF00-030D-427E-B26C-C3FB97FCEF93_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 9 Dec 2015, at 9:35, Ted Lemon wrote:

Wednesday, Dec 9, 2015 9:21 AM Jakub Moscicki wrote:

Unless you want to dig into the type of the file and expl= ore it=E2=80=99s internal structure to merge, the best you can do is to m= ake sure a version on the server is generated for each conflict file and = these may be easily accessible for manual merge by the interested users. = For this etags are sufficient. From this point of view there is no differ= ence between conflicts which are generated because two clients update the= file at the same time (so conflicting uploads overlapping in time) and a= case of offline client which edits locally outdated version (newer versi= on available meanwhile on the server) and consequently uploading it when = online again (so conflicting uploads not overlapping in time). In both ca= ses it looks to me good enough if they end up as versions on the server f= or manual user merge/revert.

Most files are text files, which are easy to merge,

I don=E2=80=99t agree with that statement. A lot of files= nowadays are complex text files in a complex format (docx, odt, =E2=80=A6= ). Not easy to merge. Not at all. (I don=E2=80=99t have statistics, but m= y guess is that 90% of shared files are not plain text files)

so yes, I do want to be able to dig into the structure of= the file. Even when the file isn't "easy to merge," e.g. a sound file = or a drawing, knowing the order of the changes can be very helpful when s= omeone is doing a manual merge. And you can build merge tools for commo= nly-merged files; if conflict detection is a feature of the data store, t= hen there's an incentive to build such tools, whereas if everybody is acc= ustomed to dumb data stores that don't provide this feature, there's no p= oint in making merge easy.

The absence of this feature is a serious problem in my wo= rkflows; I don't know if your experience is similar. I don't really see= any point in inventing "yet another" storage sync mechanism that doesn't= provide this feature. E.g., do you really want a calendaring system th= at automatically re-adds files that have been deleted on one client when = a second client connects that hasn't seen the deletion? An address book= that backs out updates? A mail system that undeletes deleted messages,= or deletes messages on the client that were lost on the server due to a = crash?

you are giving a good example of something vastly differe= nt. Calendering is a very well structured and very limited dataset (compa= red to free text) that was made by design with sync considerations. The l= atest version of vcard was also designed with sync considerations, and it= took a lot of time to get it right, (I can tell you I was the chair of v= carddav when we did this). And a vcard is a pretty simple dataset and ver= y structured.

So I think your point just shows the inverse. Merging com= plex, free, not structured-limited-dataset files is very very difficult.<= /p>

I guess your goal is great, but to me, that is for resear= ch. So if people want to do this work, I would split it into two working = groups:
- one on the IRTF side about generic sync-merge algorithms
- one on the IETF side for the protocol components.

Marc.

The use case of a small collection of large files used en= tirely sequentially is easy to address, but (a) not very interesting and = (b) not actually a common use model. It seems common because w= e don't provide anything better, and so people make do with it, but it do= esn't actually fit with what they are doing. If it did, we wouldn't see= the proliferation of manually-labeled versions of the same file that is = so common in such data stores.

--
Sent from Whiteout Mail - https://whiteou= t.io

My PGP key: https://keys.whit= eout.io/mellon@fugue.com_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www= =2Eietf.org/mailman/listinfo/storagesync

--=_MailMate_28B2CF00-030D-427E-B26C-C3FB97FCEF93_=-- From nobody Wed Dec 9 06:59:35 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0DA1AC3FC for ; Wed, 9 Dec 2015 06:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1WYy1Uunzew for ; Wed, 9 Dec 2015 06:59:33 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 9E41A1A92FD for ; Wed, 9 Dec 2015 06:59:32 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14496731699020.4103765564505011" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <3A341032-4229-485C-9107-275968F581D1@viagenie.ca> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <3A341032-4229-485C-9107-275968F581D1@viagenie.ca> Date: Wed, 09 Dec 2015 14:59:29 +0000 Message-Id: <1449673170228-ae3692c4-a5a3f9d4-edf70abe@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:59:34 -0000 ------sinikael-?=_1-14496731699020.4103765564505011 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Marc, I agree that generalized merge is a research problem. However, if = the underlying protocol doesn't provide metadata that can be used to detect= conflicts, there is no way to do the research. Saying =22don't do this = obvious thing that will be needed in order to make things better=22 is a = recipe for stasis. We already have webdav. If what we want is the = feature set that webdav provides, why are we even talking about this=3F -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14496731699020.4103765564505011 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWaEHSCRAMw8Nu0HeKywAA0GwIANYc/hmq5IAipNWCbTYh CyYHnogll8LOwamwKLkEeDyXysjwhLecLZWdR2X31TnSf2KXXoc5nAruKHsD hWW8ELQmUjs5Zi68v7QbFwRL5P1tTyotnBXosAES7Go4usD/0G/74KAvIjYY PMlOYp6QMlzjpQ8zaaJUIgDs1iQ665pkiTNcj9nH3mfCOeLixfPsobM8K3fI ideBfpJMaS4pUiIe+gkxAuDpNE8HT/z/BqF4i58jDDQQCMxB486s1PW7dMlu pbYN/w+15hQNBKlg+w4K1oZtaM6n1ClN/uF0t/KoMBKl5PEmwtZprlpdIpFn X+glgNiA0Gm3Mz7lbEi8l/o= =ID8n -----END PGP SIGNATURE----- ------sinikael-?=_1-14496731699020.4103765564505011-- From nobody Wed Dec 9 13:13:49 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881431B2DC3 for ; Wed, 9 Dec 2015 13:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C2xEIWr8soH for ; Wed, 9 Dec 2015 13:13:45 -0800 (PST) Received: from kerio.owncloud.com (kerio.owncloud.com [216.250.117.59]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351251B2D99 for ; Wed, 9 Dec 2015 13:13:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=owncloud.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=v/OJcNr+Bw9P6QVRA46MXxQ4fvMYjUn8HL85kEws718=; b=lr5kfmRnE2w7M4+409Pqp2LG2Dfh/GhreeP2J9n+LGv0JsXPU39+bPtbwu+Dw9SiBpJzfXsyS2ghv 9ey8ja2ttfDDvDO0Nuuhg5zMPKZNxl4VnjIoqK3CoG7WAdiQ0b2tySaRxqFNk27H4xCmhgUJqiorJn EXt/BV9CYCkevG5Z9Rxf1CfcGxaOCLIvohAFzYHZyvS1/QIh3yZvSAQRg3hVIvHqopKlboiEQ2kXF/ xkaD3gRQLOANSvNA+NK5Ws5z2x92d2LcxgMP9VdSWD5hH111DT8j+E9ooRfCAzHLxeQbJVhbSwlTMf z5zgzyjxvkpGDMTLLgw2N2vMjBryqIQ== X-Footer: b3duY2xvdWQuY29t Received: from [192.168.178.75] ([87.148.194.49]) (authenticated user freitag@owncloud.com) by kerio.owncloud.com (Kerio Connect 9.0.0) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for storagesync@ietf.org; Wed, 9 Dec 2015 16:13:53 -0500 To: storagesync@ietf.org References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> From: Klaas Freitag X-Enigmail-Draft-Status: N1110 Message-ID: <56689982.3040901@owncloud.com> Date: Wed, 9 Dec 2015 22:13:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 21:13:48 -0000 Am 09.12.2015 um 15:35 schrieb Ted Lemon: > Wednesday, Dec 9, 2015 9:21 AM Jakub Moscicki wrote: >> Unless you want to dig into the type of the file and explore it’s internal structure to merge, the best you can do is to make sure a version on the server is generated for each conflict file and these may be easily accessible for manual merge by the interested users. For this etags are sufficient. From this point of view there is no difference between conflicts which are generated because two clients update the file at the same time (so conflicting uploads overlapping in time) and a case of offline client which edits locally outdated version (newer version available meanwhile on the server) and consequently uploading it when online again (so conflicting uploads not overlapping in time). In both cases it looks to me good enough if they end up as versions on the server for manual user merge/revert. > > Most files are text files, which are easy to merge, so yes, I do want to be able to dig into the structure of the file. Even when the file isn't "easy to merge," e.g. a sound file or a drawing, knowing the order of the changes can be very helpful when someone is doing a manual merge. And you can build merge tools for commonly-merged files; if conflict detection is a feature of the data store, then there's an incentive to build such tools, whereas if everybody is accustomed to dumb data stores that don't provide this feature, there's no point in making merge easy. Automatically mergeable or not, I don't think resolving conflicts shoudl be part of the sync protocol. Of course conflicts must be detected and hooks should exist to plug in code to work with it, but I doubt it should be part of the sync layer to interpret and resolve them. And even if there is an automatic resolving of conflicts for some file types (that is obviously possible if that is wanted from a higher level point of view) there always remains the possibility of not at all automatically mergeable conflicts. I am also not sure about the importance of the sequence of changes, as there are situations caused for example by offline work, where changes happen in parallel, these cause a conflict, and it's not really important which change was before or after. Important is that both versions can be found again, but not necessarily in timely order. I do not understand why Kuba said "Etags are sufficient" in this context, but maybe I lack context because I am late to the party... regards, Klaas > > The absence of this feature is a serious problem in my workflows; I don't know if your experience is similar. I don't really see any point in inventing "yet another" storage sync mechanism that doesn't provide this feature. E.g., do you really want a calendaring system that automatically re-adds files that have been deleted on one client when a second client connects that hasn't seen the deletion? An address book that backs out updates? A mail system that undeletes deleted messages, or deletes messages on the client that were lost on the server due to a crash? > > The use case of a small collection of large files used entirely sequentially is easy to address, but (a) not very interesting and (b) not actually a common use model. It _seems_ common because we don't provide anything better, and so people make do with it, but it doesn't actually fit with what they are doing. If it did, we wouldn't see the proliferation of manually-labeled versions of the same file that is so common in such data stores. > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mellon@fugue.com > From nobody Wed Dec 9 13:26:05 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3691A7014 for ; Wed, 9 Dec 2015 13:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHColAZ2xDXO for ; Wed, 9 Dec 2015 13:25:59 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0638.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::638]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25D01A7009 for ; Wed, 9 Dec 2015 13:25:58 -0800 (PST) Received: from AM3PR06CA023.eurprd06.prod.outlook.com (10.141.192.141) by HE1PR06MB1418.eurprd06.prod.outlook.com (10.163.177.20) with Microsoft SMTP Server (TLS) id 15.1.337.19; Wed, 9 Dec 2015 21:25:36 +0000 Received: from AM1FFO11FD016.protection.gbl (2a01:111:f400:7e00::119) by AM3PR06CA023.outlook.office365.com (2a01:111:e400:882b::13) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Wed, 9 Dec 2015 21:25:37 +0000 Authentication-Results: spf=pass (sender IP is 188.184.36.48) smtp.mailfrom=cern.ch; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=cern.ch; Received-SPF: Pass (protection.outlook.com: domain of cern.ch designates 188.184.36.48 as permitted sender) receiver=protection.outlook.com; client-ip=188.184.36.48; helo=CERNMX12.cern.ch; Received: from CERNMX12.cern.ch (188.184.36.48) by AM1FFO11FD016.mail.protection.outlook.com (10.174.64.94) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Wed, 9 Dec 2015 21:25:35 +0000 Received: from cernfe02.cern.ch (188.184.36.47) by cernmxgwlb4.cern.ch (188.184.36.48) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Dec 2015 22:25:02 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE02.cern.ch ([fe80::bc89:8f4e:8731:2c47%13]) with mapi id 14.03.0174.001; Wed, 9 Dec 2015 22:25:01 +0100 From: Jakub Moscicki To: Ted Lemon Thread-Topic: [Storagesync] Storagesync Digest, Vol 5, Issue 1 Thread-Index: AQHRLH0+7gCKX1UFx02QDZgdWy/v7563OhsAgAArgwCAAAZPgIAAAsoAgAAiFACAAVlOAIAACqEAgAACRoCAAAS6AIAAC86AgAAAVQCAAAIgAIAAPLWAgAHN3gCAAA3lAIAB4XiAgAAwgYCAAPsvAIAAb/IAgAAAzwCAAAM9gIAAAb8AgAADTgCAAAE9AIAABBwAgAAHaICAAAtbgIAAAxyAgAAesin///WngIAAM7sAgAC71wCAAP3bgIAAgq+AgAAjBgCAACjcgIABKcH+///yNgCAAAPMgIAAAh+AgABwRoA= Date: Wed, 9 Dec 2015 21:25:00 +0000 Message-ID: References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> In-Reply-To: <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.28.197.96] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD016; 1:7NwAcARhqgxEmtmMjAPjyAdDmeuyCcdkU+3Vm6+0QvyvsNLogDx0I0SlMHA+2o1UY/A9tQIue+90XAuX6VPXQf37eRIgoga8418mKw2MaXbbELmUmkXdc+eBtlxQYDH1a9w9xCDfgDtZON315diAgYG36MU1wN+g4J53Xdh4XtIx23AXEjbS1/zwJyHl88xX7SyIZREzx1u9dWQLVewPuE46HCyuYzgMWiiac1cGCTbMLEk2Rd61LusnBzuy1LoDg23JImo2e95270jQolXO2F5GkvbVWGj7aYX7d0M2BG5Y+eMD0XXISDU1xMjJ+bpRBPwRvK2vlKfDNUt6ae/GaOrXfspHXcfc32z5MJzQ+PJhSS0IW5vLyuOs0Nx0JnDi+uyBmXPQ8sdq/gN+G6VyIoD6c/d4Z/W6sicQfsWtUfk= X-Forefront-Antispam-Report: CIP:188.184.36.48; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(5403001)(189002)(10533003)(18543002)(199003)(24454002)(102836003)(15975445007)(110136002)(86362001)(6806005)(23676002)(66066001)(74482002)(53416004)(106466001)(36756003)(5003600100002)(47776003)(82746002)(50986999)(54356999)(92566002)(189998001)(50466002)(1220700001)(106116001)(16796002)(87936001)(33656002)(76176999)(19580405001)(5004730100002)(1096002)(2900100001)(26826002)(93886004)(5001970100001)(3846002)(5008740100001)(586003)(2950100001)(5250100002)(83716003)(6116002)(19580395003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR06MB1418; H:CERNMX12.cern.ch; FPR:; SPF:Pass; PTR:cernmx12.cern.ch; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; HE1PR06MB1418; 2:IFFsNPMtMs2u3uapWNaoLdelslyfEREYhglv1h9cIjlS/V4CQP3NJmszJ8ttbO4FubdR7por9hrLEuxXSBkWgq1qnvuC6zd+SmeLPrebrvlcabkmRtV1CmTUtB0flBgpDj+jrkGafP/UbEhRV1WvMA==; 3:yJIS1gPl70y2XnLHrViAYDOjvmq7b7gaNZeilA9oai5P00gup2ngHUAA6io85fQ32tNRHJRQCcNSq5g0/NhYOpopt65vjelS3tJo33hLHCxGuKTEiuSZSeO5rXzS37j0/pnDNVYF+A+gANW1WU7ncpWc+3LcUtv50toaBgXw45vJ3+HzF4FqPEGy79eYEO5wDFTDyF8E3kz6C+RHLTSK7DuHD/dBdh5GuvavVHD+vFKOXyy8QEy5cKVClQG0OGVOFq5H+9ybdUJ0cK96lBlBBA==; 25:zJ4goy73qple9piQrUNuIqterluQ2q5up377jGGfBsxJ8tCTbxzwicl4girMARlT/MdYWs8kEEeYNd5QDF4t9zsMBP/jDhp1wmZKVaEgH0YFG115qFC7wjCWBXmD0Ckg0i1kuDuCVlLaR0GjGXcG/Fw4qPafVn3lABmf1tLnpWZwqihL9ih9x2TvGmVzuO8d/HC3cUgyLrn2cleD7Zmrvr+fEvnLEfzVcVEQuef/WLTd4stH0FheW84GnL/frU6Ir5NbfUJxEYuYmD9L5HH2Bg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:HE1PR06MB1418; X-Microsoft-Exchange-Diagnostics: 1; HE1PR06MB1418; 20:4LgNkIH7U+owagYNEl3j+gwlSPxlYGiscOTeAPwBxeU1/dJfEIYUcI6WGvDAN6ablRf0xVwn3Z3Hkieck/Kc7YyPScAeE3qVWBIri2azjbXN8v1SXSv9EEyk5Vf06HuhsUPs8rnNsuy8q+pjEccfLpgERsDAhGx99IZ+OTRNPOgRkqSQsVMX3Sg17JUfdcefOoc9vOtnZuRoDS9u2JyqQupWCG+ieb6afh4jM/pw8mf+xc9jx++h7lgTQqNOccUie0Mv/PNcM821y0gVazUkcKSteAKtucbmjhUxOIC3Bn6G31u7kz5xw9o437lG/vc8F90at9DVh9urG3EBcqQZWZNt9Wx5jFj45Ytw16sbUgW0v+kJDD6bNqyfA7FGUBx/fe2OSEoU9FOTP1EA1JbRweCzBDdUQ8mGx+0J7NdYagRlXZUGJP4+D59Z7sdRZRxrMR5P2pouUxSE1LBzB35iirjI752vIIhyokUe/mLeHFNLZB/nVpea1xHwamHo40Pw; 4:E9SPB8EMUM/DNJkBinQHPfPS12i/aZvEQ9PR5wy6jS6ceJ8hx1/ie8yHewS4F+9No39XlpbB5a3oxPh2LL7ZbtVHuh7mbkUTtcA9m3Y7Kyxv9YQWtJ4Sbny7Pl+YaMT/TG0MaGDwQQMUENtcBZF9yj/mZ1O0uKt2MI/TUGeQ7TobPs1XygFwgzBjKynwi73K3hf/XGFu51Yh+Vsn+zg35kL8lMFgW7R9lV1vTiBm72uxTtunsI8Pjsv1pwquot52D3hV6ADSliwkTPRPR6h1Im0FY3DjUFwO8gGL5+OlVB4/91yGFqKJq+jrElryhatZDR2Gpjjbu/4ycLUnMrj1d2Mc1EiRnePQEPHNySHo+8YS4LbOgJ5gNeGJwpIYNehi X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:HE1PR06MB1418; BCL:0; PCL:0; RULEID:; SRVR:HE1PR06MB1418; X-Forefront-PRVS: 0785459C39 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA2TUIxNDE4OzIzOkNPM3N5anowSG9sS3FPa0NMNnpSUGZBblBX?= =?utf-8?B?bElGTGpTRDlqdFBCSmNaa2NxRWdsUDBrOCtxMENtZ1ZlTEExTHNLVHdZZjdZ?= =?utf-8?B?Rm5zcmpjcU9rSkNRcjNjNlVxczNmbTd1eGx3MWQzdTliT0E0aGQ3NzZVLzNs?= =?utf-8?B?dUNUSEtKdHB1SWRIdTBnQWV3d2xFclNvdzJBdldBOU1CTis3SXJSYnlqSzkx?= =?utf-8?B?ckY4U0ZRb2RPUzllc3lRdm5ad0IxeGpzNUtkNjFFR09mTDlwdjlVSDF4T08w?= =?utf-8?B?NXlpM1gvU2t6cy93RzhFNVQzeHN1YTZDNmZEOXJJK2E2SC9vT3UxSGJweUVm?= =?utf-8?B?b2k3M3RLdk1CZnFtWkNTTnFRZjBlM2ZNeGZlN3Vqczd3VkpOS2IyOWpIempr?= =?utf-8?B?QTFzeE9LMHRRaU9HMnExdFRZdWdsbmluMUVuMWZaQ2V1THBvazNSeUd2blMv?= =?utf-8?B?SHlWSExFWHJHVWkrVk10NFNseUx0VnU3SFJxeXpuMU1CTHVzS05qV3ZMZnF4?= =?utf-8?B?dUhWR0Q2KzhpQW5MSjFCam42eDZvbjBVaGptcDNBcGpTd1Uwb05jTmdrejRH?= =?utf-8?B?T3h6NFZ5Vm94aGs1Z2FuRWQ2dFkwTkZleHV0NUN2QmdWOStFUFUvb3BwQ3No?= =?utf-8?B?dUJSa3ovQzRtZWFMY08xY3NRWkt2VjU5TXdESXpjcjYyQmo5Q2daekt2UGF2?= =?utf-8?B?VjdIWEhiSk5vbkFTRlF1eURseU1lS0ZCYVN3Z0VpRFZmY21mVitIK3Bjem5Z?= =?utf-8?B?dUEwM1NSRTN5c1lrbFVjWDJYSjAzcnV5ZGpKNGJZdjZGOGxoTE02RVhjZk4v?= =?utf-8?B?WTV6M2ZGYkJYWWVKQmJ3d1diL2wzNmY4QllxSzZLblgrclNLQzU4RUpEOUlD?= =?utf-8?B?V3A2d1dFVDYrQUlCdVpxRTg3a21oanlBaHp5eGVEc3UzQ2g3ZExaNkhpdENL?= =?utf-8?B?MGVEWE9WVlBPUytoQmRFU3VXd21wMlBqZlNNRlI5R0dXTmRXRnpQMExkQ3Rr?= =?utf-8?B?aHNmT3FiUkJXb1BJaWZKOEpsWVdYWjBxbHJRSXhDMTExY1Z3TGU0WkxOUm8z?= =?utf-8?B?dzEzeTVPK2srdEhGY1Z0Q2ZYODBZQnlEL2IzQWlHd3ZJU3UyU3NNa3hlSDlF?= =?utf-8?B?WGswQWJwaDZuMG8zMDNpQURYZDg3VGFzUDdoYWJ4bU9YNkNpTmNmVmRrTnVN?= =?utf-8?B?Z2h3d0toRmwvNkJKNUIrVXN6MGpJMnVGVWhkazI0MjVCWWdrNEtxL2tBUG5y?= =?utf-8?B?WHRuVWd4NVZOZ0hKRlZJd01UYU5Cam1SZ3k3S0lHYUtzQVN2cTJXQnhLdk5Y?= =?utf-8?B?RlgvN3BlTkhJQkc1bzJKaWlLVDhiOUR3Myt5d1dsMlBaTHcwcGt1VXBLblp6?= =?utf-8?B?QzJZTlE1WGluWFdaWWZ4a1Zpc1JZcXRjR0hLbUFnOEw3eVAxak5QNFlqVVUy?= =?utf-8?B?V3VxTTBKZWJhRUtzSUJtNk9VS0F6OFNGNklOVkIxS2V2dXJINnloTzA5WFNW?= =?utf-8?B?QmFKMzAzbHYwdk5sNU5jcVJRTmNkdU5RZEUxUmptQkZvRnpmYkhPcGNnMGJS?= =?utf-8?B?UVFpRDhLcEYvU0poWHdFWHhsVUZVZWhscjFlVXN4M3kwY2VPSEtsSm5yZjdz?= =?utf-8?B?OVBjRmd1aFhJSXdHZjc1bzNlbUVGV1B6dUw0WlRMWkdhOG1SbXFjaWhIY0U5?= =?utf-8?B?YVc0aURuNHZKbVN3UzVxeUxYY1BBREsvZWJSeERmS2NlNkV6NEdjcWVqbVJX?= =?utf-8?B?YlJQbnVNcGs3TnBuam9rQT09?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR06MB1418; 5:PfLuly4EOkWTwouXtQ0jOLe3MPmX9ytdOa6vm6OsBBbm8tF549Y+ITIGTIrfp8mOCoCsN5CV6IgjjCkoaJji2DClQDAhXYPKqZvTK4xFOKzCAzJppXZOkk9xMnv7Nx3RDAtsPfzus0aa0R/XE6Pykg==; 24:t7xDZLUNi8x7jZCTfFPHJQVmff5z6GI7QxRDepwajIAC+eRNijC3bn3pqVQGFQqke2FWdLBcVvaPN6ltEuePRMKuR0rkMABnWbD65wmeS34= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2015 21:25:35.9677 (UTC) X-MS-Exchange-CrossTenant-Id: c80d3499-4a40-4a8c-986e-abce017d6b19 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c80d3499-4a40-4a8c-986e-abce017d6b19; Ip=[188.184.36.48]; Helo=[CERNMX12.cern.ch] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR06MB1418 Archived-At: Cc: "storagesync@ietf.org" Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 21:26:04 -0000 SGVsbG8sDQoNCkxhc3QgdGltZSBJIGxvb2tlZCBhdCB0aGlzIGluIGNlcm5ib3ggd2UgaGFkIG1v cmUgdGhhbiAxMDAwIGZpbGUgZXh0ZW5zaW9ucyBhbmQgcXVpdGUgYSBsYXJnZSBmcmFjdGlvbiBv ZiDigJx0eXBpY2FsIGRyb3Bib3jigJ0gdHlwZXMgb2YgZmlsZXMgKGRvY3VtZW50cyBvZiBkaWZm ZXJlbnQgc29ydHMsIGxhdGV4IHNvdXJjZSBmaWxlcyBvZiBhcnRpY2xlcywgaVdvcmsgZmlsZXMs IE9mZmljZSBmaWxlcywgaW1hZ2VzLCBwZGZzLCBzb3VyY2UgY29kZSAoISksIGV0YykuIFdlIGFs c28gaGF2ZSBhbiBpbmNyZWFzaW5nIG51bWJlciBvZiBwaHlzaWNzIGRhdGFzZXRzIGFuZCB3ZSB3 aWxsIGhhdmUgbWFueSBtb3JlIGFzIHdlIHByb3ZpZGUgZGlyZWN0IGNvbm5lY3Rpb24gdmlhIHN5 bmMvc2hhcmUgdG8gdGhlIGFscmVhZHkgZXhpc3RpbmcgaHVnZSBjb2xsZWN0aW9ucyBvZiB0aGVz ZSBkYXRhc2V0cy4gRm9yIHRoZSBkYXRhIGZpbGVzIGF0IENFUk4sIHllcyB5b3UgYXJlIHJpZ2h0 LCB0aGVyZSBpcyBubyBwb2ludCBvZiBtZXJnaW5nIHRoZW0gYW5kIHRoZXkgcXVpdGUgb2Z0ZW4g YXJlIG5ldmVyIG1vZGlmaWVkLiBCdXQgSSB3b3VsZCBhbHNvIHRlbmQgdG8gZGlzYWdyZWUgd2l0 aCB5b3VyIHN0YXRlbWVudCB0aGF0IG1vc3Qgb2YgZmlsZXMgYXJlIHRleHQgZmlsZXMg4oCUIGFz IHdhcyBleHBsYWluZWQgYnkgTWFyYyBCbGFuY2hldCDigJQgaW4gZ2VuZXJhbCBpdCBpcyBub3Qg dGhlIGNhc2UsIG5vdCBvbmx5IGZvciBDRVJOLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCmt1YmENCg0K LS0NCg0KPiBPbiAwOSBEZWMgMjAxNSwgYXQgMTU6NDMsIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3Vl LmNvbT4gd3JvdGU6DQo+IA0KPiBCVFcsIGl0IG9jY3VycyB0byBtZSB0aGF0IGF0IENFUk4geW91 IGRlYWwgYSBsb3QgaW4gdmVyeSBsYXJnZSBkYXRhIHNldHMgd2hpY2ggYXJlIGNyZWF0ZWQgb25j ZSBhbmQgbmV2ZXIgbW9kaWZpZWQsIGJlY2F1c2UgdGhleSBhcmUgcmVjb3JkcyBvZiBwaHlzaWNh bCBldmVudHMuICBTbyB0aGUgaWRlYSBvZiBtZXJnaW5nIG1pZ2h0IG5vdCBzZWVtIGFsbCB0aGF0 IGltcG9ydGFudCwgYmVjYXVzZSB5b3Ugd2lsbCBuZXZlciBkbyBpdCBvbiB0aGVzZSBkYXRhIHNl dHMuDQo+IA0KPiBIb3dldmVyLCBvbmUgdGhpbmcgdGhhdCBhIGdvb2QgdmVyc2lvbmluZyBzeXN0 ZW0gYWxsb3dzIGZvciB0aGF0IEkgdGhpbmsgeW91IHNob3VsZCBjb25zaWRlciBpbXBvcnRhbnQg aXMgdGhlIGFiaWxpdHkgdG8gYXZvaWQgYWNjaWRlbnRhbGx5IGxvc2luZyBkYXRhLiAgIFdoZW4g eW91IGhhdmUgcmVhbGx5IGJpZyBkYXRhIGFyY2hpdmVzLCBvbmUgb2YgdGhlIHRoaW5ncyB0aGF0 IHlvdSB3YW50IHRvIGRvIGZvciByZWR1bmRhbmN5IGlzIGtlZXAgbXVsdGlwbGUgY29waWVzLiAg IElmIG9uZSBpbnN0YW5jZSBnZXRzIGNvcnJ1cHRlZCwgeW91IHdhbnQgdG8gYmUgYWJsZSB0byBk ZXRlY3QgdGhhdCwgYW5kIHlvdSB3YW50IHRvIGJlIGFibGUgdG8gYXZvaWQgbG9zaW5nIG90aGVy IGluc3RhbmNlcyBvZiB0aGUgZmlsZSBpZiB0aGUgZmlsZSBpcyBsb3N0IGZyb20gYW4gaW5zdGFu Y2Ugb2YgYSBmb2xkZXIuICAgVGhlIG1vc3QgcmVsaWFibGUgd2F5IHRvIGF2b2lkIHRoYXQgaXMg dG8ga2VlcCB2ZXJzaW9uaW5nIG1ldGFkYXRhLiAgIE11bHRpcGxlIGNvcGllcyBvZiB2ZXJzaW9u aW5nIG1ldGFkYXRhIGFyZSB2ZXJ5IHVzZWZ1bCBmb3IgZm9yZW5zaWMgYW5hbHlzaXMgd2hlbiBz b21ldGhpbmcgZ29lcyB3cm9uZywgYXMgd2VsbC4NCj4gDQo+IEFkZGl0aW9uYWxseSwgd2hpbGUg dGhlIGJ1bGsgb2YgdGhlIGFjdHVhbCBfZGF0YV8gdGhhdCBDRVJOIHN0b3JlcyBpcyByZWFsbHkg YmlnIGZpbGVzLCB0aGUgbGl0dGxlIGZpbGVzIG1hdHRlciBqdXN0IGFzIG11Y2gtLXRoZSB3b3Jr IHJlc2VhcmNoZXJzIGFyZSBkb2luZywgcGFydGljdWxhcmx5IGNvbGxhYm9yYXRpdmVseS4gICBF bmFibGluZyBlZmZpY2llbnQgY29sbGFib3JhdGlvbiBvbiBhcnRpY2xlcyBpbiBwcm9ncmVzcywg ZW5hYmxpbmcgZWZmZWN0aXZlIHNoYXJpbmcgb2YgY29kZSwgYW5kIHNvIG9uLCBhbGwgYXJlIHZl cnkgaW1wb3J0YW50IGRlc3BpdGUgcmVwcmVzZW50aW5nIGEgdGlueSBwZXJjZW50YWdlIG9mIHRo ZSB0b3RhbCBkYXRhIHN0b3JlZC4NCj4gDQo+IA0KPiAtLQ0KPiBTZW50IGZyb20gV2hpdGVvdXQg TWFpbCAtIGh0dHBzOi8vd2hpdGVvdXQuaW8NCj4gDQo+IE15IFBHUCBrZXk6IGh0dHBzOi8va2V5 cy53aGl0ZW91dC5pby9tZWxsb25AZnVndWUuY29tX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+IFN0b3Jh Z2VzeW5jQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3RvcmFnZXN5bmMNCg0K From nobody Wed Dec 9 14:05:24 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747A41B2E58 for ; Wed, 9 Dec 2015 14:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx_-twBP_jt7 for ; Wed, 9 Dec 2015 14:05:21 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id B4E5F1B2CD4 for ; Wed, 9 Dec 2015 14:05:20 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14496987178250.07082593231461942" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: <56689982.3040901@owncloud.com> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <56689982.3040901@owncloud.com> Date: Wed, 09 Dec 2015 22:05:17 +0000 Message-Id: <1449698718120-5228f72d-575bb833-81b4c859@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 22:05:23 -0000 ------sinikael-?=_1-14496987178250.07082593231461942 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Wednesday, Dec 9, 2015 4:13 PM Klaas Freitag wrote: > Automatically mergeable or not, I don't think resolving conflicts shoudl > be part of the sync protocol. Of course conflicts must be detected and > hooks should exist to plug in code to work with it, but I doubt it > should be part of the sync layer to interpret and resolve them. I agree, as I said to Marc. But the sync protocol has to =5Fsupport=5F = the accurate detection of conflicts, or there's no way to resolve them, = because you don't know about them (until your change has been overwritten, = at which point it's too late). > And even if there is an automatic resolving of conflicts for some file > types (that is obviously possible if that is wanted from a higher level > point of view) there always remains the possibility of not at all > automatically mergeable conflicts. Yes, I think we all agree that this is a problem. Marc mentioned that he = thinks it's a research problem. I think a general solution is a research = problem, and not a very interesting one: all I really want is a way to know= that the conflict exists and what the sequence of events was; if an = automatic merge is possible, that's great, but not required. > I am also not sure about the importance of the sequence of changes, as > there are situations caused for example by offline work, where changes > happen in parallel, these cause a conflict, and it's not really > important which change was before or after. Important is that both > versions can be found again, but not necessarily in timely order. Not remembering the order in which the changes occurred is an optimization = which gains you almost no efficiency and costs you greatly in terms of = functionality. > I do not understand why Kuba said =22Etags are sufficient=22 in this > context, but maybe I lack context because I am late to the party... Etags are sufficient if you just want to see if what you have is more = recent in time than what's on the server. They don't allow you to detect = interleaved updates. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14496987178250.07082593231461942 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWaKWeCRAMw8Nu0HeKywAAc+sH/A16PnQQXBbQcKY+VEqz 19KPX2g0tw+SdKtxxlxtZQhm+R2MqEyUQu7w8CgIyiXHwNI7Dmpl2iz848Ix XdoutCcHhcAqaSGhFrOj2gCtvPMEcNDBHIfXqD2YP3yZIQSd5AR5l2GfIoBh UD3oN4iFVLSdrzWn9YBNeKnV+d825dyfTvXP8GkZ7Nt0T9RFtPed6CYI4M25 Sj+q3vjv17fBcF90ORJdip9wV7Um7a3FUm+YR9wmcnCRsL7GcL6xyZJafnsK l4chW9aruHtdHCeP6mjEJS3+I3Y/RfBf/KekcTFqPBmybyIjgH8/zoaASBGb x/gDK0UJO3K/Us6jzEORDbo= =9A31 -----END PGP SIGNATURE----- ------sinikael-?=_1-14496987178250.07082593231461942-- From nobody Wed Dec 9 14:08:35 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781631B2E8B for ; Wed, 9 Dec 2015 14:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9cBkqCz9vGa for ; Wed, 9 Dec 2015 14:08:32 -0800 (PST) Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF081B2CD4 for ; Wed, 9 Dec 2015 14:08:31 -0800 (PST) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14496989095130.4715336225926876" From: Ted Lemon To: storagesync@ietf.org In-Reply-To: References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> Date: Wed, 09 Dec 2015 22:08:29 +0000 Message-Id: <1449698909826-ee50bf82-5c16ad1d-d704bcec@fugue.com> MIME-Version: 1.0 Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 22:08:33 -0000 ------sinikael-?=_1-14496989095130.4715336225926876 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wednesday, Dec 9, 2015 4:25 PM Jakub Moscicki wrote: > But I would also tend to disagree with your statement that most of files = are text files =E2=80=94 as was explained by Marc Blanchet =E2=80=94 in = general it is not the case, not only for CERN. I think you and Marc misunderstood what I mean by =22text files,=22 but = that's immaterial. Whether merges can be accomplished automatically or = not, knowing that a conflict has occurred, and when, and why, is (IMHO) = important. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.= com ------sinikael-?=_1-14496989095130.4715336225926876 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.2.0 Comment: Whiteout Mail - https://whiteout.io wsBcBAEBCAAQBQJWaKZeCRAMw8Nu0HeKywAA8TkIAMy9SrK76G9oHVHT8SUZ qrxjWmGYOVjFKd6tmqM1c8NeC1oI5cLzg9I/2QB+EWgesSaIgupodckgoEqZ RRF0QmY2iZPakLxuw2ICOAs4yH441avTPLLFhoSyeAlMNjipWjUpjPTTq4/G GXlTgJ2Be7Jd94nIWez1RJsDPlrRB6qlFSz42KAQKcPWJKFCFKr8xBlDSnkT Cc0hCXHipfKdxlYZe0CY0k89djxtjVX7ciYA0g948Tku1k/X5Uwc4OkTmur8 DkkqO/B7BGqZ8aFeUikR3mPpDpVjYLK74/LFkJCxxdBm1BLCcpzwChUCMeWD pdqitTmuHo0wGXfCm3mTiFc= =n2+G -----END PGP SIGNATURE----- ------sinikael-?=_1-14496989095130.4715336225926876-- From nobody Wed Dec 9 19:31:56 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AA91ACE6D for ; Wed, 9 Dec 2015 19:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1FtU-6_UAzk for ; Wed, 9 Dec 2015 19:31:49 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72E61ACE6C for ; Wed, 9 Dec 2015 19:31:48 -0800 (PST) Received: by wmec201 with SMTP id c201so7141554wme.1 for ; Wed, 09 Dec 2015 19:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ZwzVQT1dwe+9G+3WLvL3qrXv1/95mgMJaZUjTx8pe7w=; b=MR/7/YP9Dq6BnLMD4sR8I8o+QsZKNo82Q8P03lYfUg5wMqJqaSGYJs15Yb5C9dJbFB EwkI6TX8B42HUeHEbthQ/7SPWV1yMY8PT0LBRLD+bu6FkVstRYZ0zQYdfswc/gYnay3c wcAX77+UzKqSN0GPSodm3rAPp1ffp3sY8iAS6bgrc+WXYXnhShy9hmln2AQR3FOtfxBL 8HYezE/1LDg7mNmSnmFSSW2r08OiM1gIJUHBalCvLfHr7AAYGjcLgpvRIj+/8bHttq9T UPBcVIRVhbxk8q6J3f8T3w4Jw+aAAY9ONssH8RsWG4BFehzcau3vMYOZQyfIgUQrE+iM 0t6Q== X-Received: by 10.28.141.140 with SMTP id p134mr39193526wmd.6.1449718307353; Wed, 09 Dec 2015 19:31:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 9 Dec 2015 19:31:27 -0800 (PST) In-Reply-To: <1449698909826-ee50bf82-5c16ad1d-d704bcec@fugue.com> References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> <1449698909826-ee50bf82-5c16ad1d-d704bcec@fugue.com> From: Linhui Sun Date: Thu, 10 Dec 2015 11:31:27 +0800 Message-ID: To: storagesync Content-Type: multipart/alternative; boundary=001a1146a0b0bbf928052682d8af Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 03:31:54 -0000 --001a1146a0b0bbf928052682d8af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, >From the previous messages, I think we all agree that the conflict resolution should be another layer's problem, whether to enable an automatic merging might be a research problem or a further use case. But I think the problem belongs to this list is whether we need to detect more on the conflicts (not resolving them). Just knowing there are conflicts OR knowing what are those conflicts, when and where do they come from (e.g. the sequence of different conflict versions). Personally I prefer the latter. Just imagine when we reconnect our device and see multiple conflict versions but don't know anything about that. How to handle them? Which one should we begin with? IMHO, this is a discussion on which is enough, etag or metadata? Conflict detection is just one of the related use cases. Regards, Linhui 2015-12-10 6:08 GMT+08:00 Ted Lemon : > Wednesday, Dec 9, 2015 4:25 PM Jakub Moscicki wrote: > > But I would also tend to disagree with your statement that most of file= s > are text files =E2=80=94 as was explained by Marc Blanchet =E2=80=94 in g= eneral it is not > the case, not only for CERN. > > I think you and Marc misunderstood what I mean by "text files," but that'= s > immaterial. Whether merges can be accomplished automatically or not, > knowing that a conflict has occurred, and when, and why, is (IMHO) > important. > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mellon@fugue.com > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > --001a1146a0b0bbf928052682d8af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

From the previous messages, I= think we all agree that the conflict resolution should be another layer= 9;s problem, whether to enable an automatic merging might be a research pro= blem or a further use case. But I think the problem belongs to this list is= whether we need to detect more on the conflicts (not resolving them). Just= knowing there are conflicts OR knowing what are those conflicts, when and = where do they come from (e.g. the sequence of different conflict versions).= Personally I prefer the latter.=C2=A0Just imagine when we reconnect our de= vice and see multiple conflict versions but don't know anything about t= hat. How to handle them? Which one should we begin with?

IMHO, this is a discussion on which is enough, etag or metadata? Conflict = detection is just one of the related use cases.

Regards,
Linhui

2015-12-10 6:08= GMT+08:00 Ted Lemon <mellon@fugue.com>:
= Wednesday, Dec 9, 2015 4:25 PM Jakub Moscicki wrote:
> But I would also tend to disagree with your statement that most of fil= es are text files =E2=80=94 as was explained by Marc Blanchet =E2=80=94 in = general it is not the case, not only for CERN.

I think you and Marc misunderstood what I mean by "text files,&= quot; but that's immaterial.=C2=A0 =C2=A0Whether merges can be accompli= shed automatically or not, knowing that a conflict has occurred, and when, = and why, is (IMHO) important.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com

_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync


--001a1146a0b0bbf928052682d8af-- From nobody Wed Dec 9 23:57:32 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3931A1B1C for ; Wed, 9 Dec 2015 23:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uqiW1bUiBaR for ; Wed, 9 Dec 2015 23:57:25 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0677.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::677]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E3C1A1AA8 for ; Wed, 9 Dec 2015 23:57:24 -0800 (PST) Received: from AM3PR06CA057.eurprd06.prod.outlook.com (10.141.192.175) by AMSPR06MB072.eurprd06.prod.outlook.com (10.242.90.152) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 10 Dec 2015 07:57:03 +0000 Received: from DB3FFO11FD040.protection.gbl (2a01:111:f400:7e04::144) by AM3PR06CA057.outlook.office365.com (2a01:111:e400:882b::47) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Thu, 10 Dec 2015 07:57:03 +0000 Authentication-Results: spf=pass (sender IP is 188.184.36.50) smtp.mailfrom=cern.ch; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=cern.ch; Received-SPF: Pass (protection.outlook.com: domain of cern.ch designates 188.184.36.50 as permitted sender) receiver=protection.outlook.com; client-ip=188.184.36.50; helo=CERNMX11.cern.ch; Received: from CERNMX11.cern.ch (188.184.36.50) by DB3FFO11FD040.mail.protection.outlook.com (10.47.217.71) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Thu, 10 Dec 2015 07:57:02 +0000 Received: from cernfe06.cern.ch (188.184.36.49) by cernmxgwlb4.cern.ch (188.184.36.50) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Dec 2015 08:56:48 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE06.cern.ch ([fe80::64b8:95fa:42bc:1ef5%11]) with mapi id 14.03.0174.001; Thu, 10 Dec 2015 08:56:48 +0100 From: Jakub Moscicki To: Klaas Freitag Thread-Topic: [Storagesync] Storagesync Digest, Vol 5, Issue 1 Thread-Index: AQHRLH0+7gCKX1UFx02QDZgdWy/v7563OhsAgAArgwCAAAZPgIAAAsoAgAAiFACAAVlOAIAACqEAgAACRoCAAAS6AIAAC86AgAAAVQCAAAIgAIAAPLWAgAHN3gCAAA3lAIAB4XiAgAAwgYCAAPsvAIAAb/IAgAAAzwCAAAM9gIAAAb8AgAADTgCAAAE9AIAABBwAgAAHaICAAAtbgIAAAxyAgAAesin///WngIAAM7sAgAC71wCAAP3bgIAAgq+AgAAjBgCAACjcgIABKcH+///yNgCAAAPMgIAAbzkAgACzsAA= Date: Thu, 10 Dec 2015 07:56:47 +0000 Message-ID: References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <56689982.3040901@owncloud.com> In-Reply-To: <56689982.3040901@owncloud.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:1458:202:225::102:5ec0] Content-Type: multipart/alternative; boundary="_000_A639311CA08E4E7FB317FDA14224CAA3cernch_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD040; 1:hFfbhceODRvWiAtXWhuO6TSbX4Fd3AGbTRos8Lr9MOacr3WVmB8BhDUbL/m2AWmUhJJwfHLXpeP3hy6M/jZ02bDL/TQeNbNSZpJu9Rd/lIJ0jaiUut59RjsvJK7UwQ03KlV5fLKaDM9pDWoUeA4kP8jomSXbR4O/7z3HJwyejg1Y6smIjvwKTi/kILKKDks4Z0COFsAdfdnVMbCg3Y0dSKPFZqm0unpkknCnpUBw81okU0CBPMm6v07wYAMEkDTaiofgKAG0d9sonhheS5TzXDUilUqL1GzPu5ERkr0/qDDeD0mspwgxuu7iWNVFENT2pBHeNqevv8YV46Qcb6b3rWp80Uirc3qzMM3bCK+5l/+uGx3rbnZLtKEc8S75cPJFQU9M8flsBIFgcFsQDsxFPX3xqJP3hgD8CSavGiXswkA= X-Forefront-Antispam-Report: CIP:188.184.36.50; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(2980300002)(438002)(5403001)(189002)(18543002)(10533003)(199003)(2950100001)(54356999)(5004730100002)(16796002)(586003)(84326002)(102836003)(19617315012)(6116002)(83716003)(87936001)(11100500001)(82746002)(6806005)(300700001)(1220700001)(1096002)(5250100002)(5008740100001)(86362001)(93886004)(106116001)(106466001)(76176999)(50986999)(2900100001)(110136002)(5003600100002)(189998001)(92566002)(16236675004)(5001970100001)(15975445007)(74482002)(26826002)(33656002)(512944002)(36756003)(19580405001)(19580395003)(53416004)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR06MB072; H:CERNMX11.cern.ch; FPR:; SPF:Pass; PTR:cernmx11.cern.ch; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB072; 2:UyXcQ2xwm4O5tXB+ZV+KviNF9+hEQKpXBBhawdVrvacTnVVAI3ZpYNFstJVqEsGXEZujrB9X0AVBlY5MDfYbk80EkF44vgbWqJp3Sh/IqPtNps2aS+IBbWs4kCiXZ+xoeOTwffQANmdeUszJ1eGD2A==; 3:3dJbA9SF6S6QysrqUlJLfLmheytFvdAo7lPYd4HbHohCGzGGaHm5dzIwbfI6gBZIf2bp27+TNl8ZO7/Swjit//o4NnS9txD3fC8Zq0cZy/JgoNNll56Nw91mkstp8JN/ygB9VdTLGEYO3RSe7KwyGMmxFa+zsbRCQEbUZ+CLw6a4ZquofWQqZrwr2678QW3+oUtbUdx1wKZVTfpJKjQqoLnwwbrGzelZD5kABogmpDfYCGMn6eh9sjj5ouKYil0UB8TOIDHcZqQ7I+mlqCEWhQ==; 25:p2Au4VPIA+J4SzTBnJxasZ8q3TpCg3er3/EeMnN3qaD8ZRoSmLRKnuPONxG/tCZEF5BtCr9hzwpveDUFNhZEq7CJqTyjaRSUicz3FtPswHtnwcJvBk52W0iuOyxdUhbzl4Nf3UvHQCChN7TwDTZoXRJSjTzfzojwlTjfGG2ebDERneCEGtY6KTYS8FnRhp7C1K4rxOmUHivLwURQglW29BPJlPiwAgvCeSCuMRkpCB8aRjvfkx9R/9NrgWdHO6aEgaRGAU/60C1Lk3ebPSpoyQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AMSPR06MB072; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB072; 20:b+kEgtg39RWgHO5+CIU0O7kHDP9ek20GLO+IUp6uoEwUUeWVhgWoKNrBdvoq1rPrxRQJn7KBUoFRrOx+1BJex2N+4zXVSIXzg/xR5Vo3+UREpMj1z+Zp9u1jecGOvLoUcO4COESuZoW5J6X/IANPeS3CszTfXWexgBTE2asU6NfGNBFxzzzU/pmXT6w94shgdf56EyZlI3uLK1bYJVtl+yxdClontvY4TdwxP6+0wC9hqGfxNW+KHBr3wnM1pTx9CZ5fRAEfsowasPD/L7cEARCOMFuBGQrYLr7NMAGmpFMh2mh+HT9oDAYrPMej90Q5G5mTc8YX3M553TCZWiqkebAXJxs/JT/iWerneEGk6k73//XqKgzruiagUGwIzfsmnas+2Ww7ZFe7DPAYOUvAuz0E+DMtr1SXsgI4LyZyfBUwSrRNhY2A35NjghmqBXmfpyrTm3ZUk809VXh4azLI6hkVNpckPL/WNy6Ako8B2uhn3Ob8/L7+ueLf9z4eKFJK; 4:/NA7oVdqTF+RgphLmZLh6X0r/HiXoKuS96wYftE7eoR4x4QAJhoiHRw4TGCtFpSH2bkkLjOOUAov8A5eBkLidt0T2BWK7ayggBUQgN+gUaUKeKeqtp1+9pKR6R3XL7BQGBS3hMG5+QYmmyVH1FAfIRKf0V10JGEJcIVkoDlO6Up0xYJmCFpmZotP1NtirnPyMYWzBlGJTJ/rZToxOEXrcRTyjvZDIhpMIKyI1y6maLRu/prUf1Ur8iW5b988s3ek1i5GUaQwqR9lJq8yiXSdIsAtUYBGzRoya/s2wMfU7wA29/GEqfK58J/1ThfXQx4OPJBaw/JC7qvhw/jhux5o9aJ5ESQQWmpjEXDqoBh6dSpG6LGuJh4qXf5DJrlZto4vjTZUv3SaMECOfJ9vUyKaC784CT4WZcUMjIJ+DO1xnPAHDNAzCia0X9Wry1j5Q02I X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(109460225580195); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR06MB072; BCL:0; PCL:0; RULEID:; SRVR:AMSPR06MB072; X-Forefront-PRVS: 078693968A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMSPR06MB072; 23:ayKolb5NNIf31TEA8stSBRC5F7R97kBkyWM7nOLptU?= =?us-ascii?Q?Hou9SG5N5VimphLgof0ul5L43K6oA5RAaFn7E8buICOte66tIg0NK/9Y1AxD?= =?us-ascii?Q?NSLB6kNcxC4AzIlzQCaSJSZdjDFjprVnIgVI2U4ciOZCB4NfoTkV44+UwFCe?= =?us-ascii?Q?/690gYXXqYX7I2pxkQHFRt900JHjjVmCtPuPUir1hG+91j4aK0VD/XJc3vUv?= =?us-ascii?Q?kRZ1I+/sy3CxQXnU154ESbtLrZB3/LANpeX7Y3cdGGQIgtpU/1ddI4bL9gx2?= =?us-ascii?Q?HFqD1ctaDd89pMnj9wjgEpkWxJYjl5kKRD+iA/GEcualcWXWR7y2+yi+57Ne?= =?us-ascii?Q?cCQNvlqOxOzBC46qRZAsb5TY3yAqdp5nntNPpCalMEMJpel8Stj65bxSLXJN?= =?us-ascii?Q?TP0Wd7mg8pV71ERiUDiLsMLFj2xnZzi52yjZ8GnrLARsfkJr+lFfFNmOOoRN?= =?us-ascii?Q?IJI7AZ7/x1gY9BmoUPSmQ1mpLNZkgpIU4ijasEkk/jGwRNbrLgO2f5jasXDO?= =?us-ascii?Q?pv+eJwzRZMrqh8B68bbQCh9jLtYAnAtWyzk4GHB0CKW4USLfr3RI7sRHt+LA?= =?us-ascii?Q?laPLxPhGIs4nUtHL69ZULREtCcucYDi31XhjTofXMgfO6jWOxhQ2JcQzmvtF?= =?us-ascii?Q?xzZg4hYgcY3jxVxfwbm39BdCx3jzIfVYO/DGRG1o7LvDIeh2nQo6cR8byKfQ?= =?us-ascii?Q?haAAOqqB97GjCsEH+MvqXS2VPK+IRjN8A1Tvi8HMosubbKESiaJf4RrEtZOh?= =?us-ascii?Q?xfHf0cFv8NS4/NqjsF3L5BA859MT7QL9fdPQoM3rz2Eklc52NNh3FOr5bEjb?= =?us-ascii?Q?6n3BlVPadMIcNpmcy+DrAGnDg3ZmL1MUVY/bjTjAKrhurKN5nFCE96P2aB19?= =?us-ascii?Q?B2gd+n1O7tGexaIz7+NCIQLoZ9hbA2T6MSzo9zqlr+m7F6hfHdn53EL3rfi2?= =?us-ascii?Q?6AAjsWLZmjBTn+S3oaC855+Xp+AvUkNC71afn8CNO4CEzf22/ktdi2E2nIGO?= =?us-ascii?Q?O7HEII4RhvD4p4FkQhdRzyyK+vobfarYFgoVwngzwQf2IyZy4/I5iL9UUkfJ?= =?us-ascii?Q?9rrspIiuEGbNflmYOQxdFufxj+hAPEhoZdX9iX86jkh6NuUPWb1t4TmceI2i?= =?us-ascii?Q?HckFrM7shOc/PvNrZMIqhFtNbS631bGsnzmTC1rzUTxjT48GZI5COcDKQk7U?= =?us-ascii?Q?g+ZSdZeSJto55b8qonmXb8/87R6YjmcPg9rpEnMBSUKh3pharvNy0zfCxjHE?= =?us-ascii?Q?3wtZLA/4O/GW7KZZctrDmk6qyjBYjaUMsAY8pnrq1BINZu20oo3zTR8+vgne?= =?us-ascii?Q?YwwPAlbij7bAxOXMEFnCU=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB072; 5:mbDEo2AS90ZEg2jTqHgr2S/nZjBsRI6LTdJ7TFWDIOp8VNJvpnYmQjBQweR1wLOJSqiw+gAcnmcbqEwu49EsGAMBK3DKNeoOX8IwJyaT8OkLdGYJE6o1DuQ01//SvvImv3Rso+bxteeUnWnK5JQ6bg==; 24:aKPY131PtoSpFuorwsXl6E2+bek+W4VchgH0NE1vXI2e6qtCP/yDkPNVas2J9YWOk8wF+Vz+4A2WJoRD1T2mjbxBGSGWTm+9rJ23prHKUVw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2015 07:57:02.9810 (UTC) X-MS-Exchange-CrossTenant-Id: c80d3499-4a40-4a8c-986e-abce017d6b19 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c80d3499-4a40-4a8c-986e-abce017d6b19; Ip=[188.184.36.50]; Helo=[CERNMX11.cern.ch] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR06MB072 Archived-At: Cc: "storagesync@ietf.org" Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 07:57:30 -0000 --_000_A639311CA08E4E7FB317FDA14224CAA3cernch_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Automatically mergeable or not, I don't think resolving conflicts shoudl be part of the sync protocol. Of course conflicts must be detected and hooks should exist to plug in code to work with it, but I doubt it should be part of the sync layer to interpret and resolve them. And even if there is an automatic resolving of conflicts for some file types (that is obviously possible if that is wanted from a higher level point of view) there always remains the possibility of not at all automatically mergeable conflicts. I am also not sure about the importance of the sequence of changes, as there are situations caused for example by offline work, where changes happen in parallel, these cause a conflict, and it's not really important which change was before or after. Important is that both versions can be found again, but not necessarily in timely order. I tend to agree with what you said above. I do not understand why Kuba said "Etags are sufficient" in this context, but maybe I lack context because I am late to the party=85 Meaning: in the view what you said above the opaque etags (e.g. md5 or uui= ds) should be sufficient as there is no need to reason about the order of c= hanges or version numbers, etc. [Plug: all people passionate about discussing these things should consider = to come to CS3 in January and do it there :-) ] Best regards, kuba -- regards, Klaas The absence of this feature is a serious problem in my workflows; I don't k= now if your experience is similar. I don't really see any point in invent= ing "yet another" storage sync mechanism that doesn't provide this feature.= E.g., do you really want a calendaring system that automatically re-adds= files that have been deleted on one client when a second client connects t= hat hasn't seen the deletion? An address book that backs out updates? A= mail system that undeletes deleted messages, or deletes messages on the cl= ient that were lost on the server due to a crash? The use case of a small collection of large files used entirely sequentiall= y is easy to address, but (a) not very interesting and (b) not actually a c= ommon use model. It _seems_ common because we don't provide anything bett= er, and so people make do with it, but it doesn't actually fit with what th= ey are doing. If it did, we wouldn't see the proliferation of manually-la= beled versions of the same file that is so common in such data stores. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mellon@fugue.com _______________________________________________ Storagesync mailing list Storagesync@ietf.org https://www.ietf.org/mailman/listinfo/storagesync --_000_A639311CA08E4E7FB317FDA14224CAA3cernch_ Content-Type: text/html; charset="Windows-1252" Content-ID: <348420BE11701D449C7FC9162E79904E@cern.ch> Content-Transfer-Encoding: quoted-printable Hi,

Automatically mergeable or not, I don't think resolving conflicts shoudl
be part of the sync protocol. Of course conflicts must be detected and=
hooks should exist to plug in code to work with it, but I doubt it
should be part of the sync layer to interpret and resolve them.

And even if there is an automatic resolving of conflicts for some file<= br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo= nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh= t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo= rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex= t-stroke-width: 0px;" class=3D""> types (that is obviously possible if that is wanted from a higher level point of view) there always remains the possibility of not at all
automatically mergeable conflicts.

I am also not sure about the importance of the sequence of changes, as
there are situations caused for example by offline work, where changes happen in parallel, these cause a conflict, and it's not really
important which change was before or after. Important is that both
versions can be found again, but not necessarily in timely order.

I tend to agree with what you said above. 

I do not understand why Kuba said "Etags are sufficient" in this
context, but maybe I lack context because I am late to the party=85

Meaning:  in the view what you said above the opaque etags (e.g. = md5 or uuids) should be sufficient as there is no need to reason about the = order of changes or version numbers, etc.

[Plug: all people passionate about discussing these things should cons= ider to come to CS3 in January and do it there :-) ]

Best regards,

kuba

--


regards,

Klaas



The absence of this feature is a serious problem in my workflows; I don't k= now if your experience is similar.   I don't really see any point= in inventing "yet another" storage sync mechanism that doesn't p= rovide this feature.   E.g., do you really want a calendaring system that automatically re-adds files that have been deleted on one clie= nt when a second client connects that hasn't seen the deletion?   = ;An address book that backs out updates?   A mail system that und= eletes deleted messages, or deletes messages on the client that were lost on the server due to a crash?

The use case of a small collection of large files used entirely sequentiall= y is easy to address, but (a) not very interesting and (b) not actually a c= ommon use model.   It _seems_ common because we don't provide any= thing better, and so people make do with it, but it doesn't actually fit with what they are doing.   If it di= d, we wouldn't see the proliferation of manually-labeled versions of the sa= me file that is so common in such data stores.


--
Sent from Whiteout Mail - https:= //whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com


_______________________________________________
Storagesync mailing list
Stora= gesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync

--_000_A639311CA08E4E7FB317FDA14224CAA3cernch_-- From nobody Sat Dec 12 05:12:58 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA71A8749 for ; Sat, 12 Dec 2015 05:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amvR8MUuvFzB for ; Sat, 12 Dec 2015 05:12:55 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 997D01A8747 for ; Sat, 12 Dec 2015 05:12:52 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygDXXDj_HWxWiWsDAA--.4239S2; Sat, 12 Dec 2015 21:15:43 +0800 (CST) Date: Sat, 12 Dec 2015 21:13:35 +0800 From: "Fei Song" To: mellon , storagesync References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com>, <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121221133476519222@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygDXXDj_HWxWiWsDAA--.4239S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Kr4rZF1ftry8Jw1UKr4kJFb_yoW8Aw1xpF WfAF43Kr4DXFnY9340yw4xXFW8trs7J39rW3WUJryxAwsYya1Ikr4xKrWFvF9xu3s8XF40 vr1Yq3Wjva98ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBSb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0 F24lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Xr4l42xK82IYc2Ij64vIr41l4I8I3I 0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWU GVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI 0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0 rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr 0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUIBOJDUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 13:12:57 -0000 DQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+QlRXLCBpdCBvY2N1cnMgdG8gbWUgdGhh dCBhdCBDRVJOIHlvdSBkZWFsIGEgbG90IGluIHZlcnkgbGFyZ2UgZGF0YSBzZXRzIHdoaWNoIGFy ZSBjcmVhdGVkIG9uY2UgYW5kIG5ldmVyIG1vZGlmaWVkLCBiZWNhdXNlIHRoZXkgYXJlIHJlY29y ZHMgb2YgcGh5c2ljYWwgZXZlbnRzLiAgU28gdGhlIGlkZWEgb2YgbWVyZ2luZyBtaWdodCBub3Qg c2VlbSBhbGwgdGhhdCBpbXBvcnRhbnQsIGJlY2F1c2UgeW91IHdpbGwgbmV2ZXIgZG8gaXQgb24g dGhlc2UgZGF0YSBzZXRzLg0KPg0KPkhvd2V2ZXIsIG9uZSB0aGluZyB0aGF0IGEgZ29vZCB2ZXJz aW9uaW5nIHN5c3RlbSBhbGxvd3MgZm9yIHRoYXQgSSB0aGluayB5b3Ugc2hvdWxkIGNvbnNpZGVy IGltcG9ydGFudCBpcyB0aGUgYWJpbGl0eSB0byBhdm9pZCBhY2NpZGVudGFsbHkgbG9zaW5nIGRh dGEuICAgV2hlbiB5b3UgaGF2ZSByZWFsbHkgYmlnIGRhdGEgYXJjaGl2ZXMsIG9uZSBvZiB0aGUg dGhpbmdzIHRoYXQgeW91IHdhbnQgdG8gZG8gZm9yIHJlZHVuZGFuY3kgaXMga2VlcCBtdWx0aXBs ZSBjb3BpZXMuICAgSWYgb25lIGluc3RhbmNlIGdldHMgY29ycnVwdGVkLCB5b3Ugd2FudCB0byBi ZSBhYmxlIHRvIGRldGVjdCB0aGF0LCBhbmQgeW91IHdhbnQgdG8gYmUgYWJsZSB0byBhdm9pZCBs b3Npbmcgb3RoZXIgaW5zdGFuY2VzIG9mIHRoZSBmaWxlIGlmIHRoZSBmaWxlIGlzIGxvc3QgZnJv bSBhbiBpbnN0YW5jZSBvZiBhIGZvbGRlci4gICBUaGUgbW9zdCByZWxpYWJsZSB3YXkgdG8gYXZv aWQgdGhhdCBpcyB0byBrZWVwIHZlcnNpb25pbmcgbWV0YWRhdGEuICAgTXVsdGlwbGUgY29waWVz IG9mIHZlcnNpb25pbmcgbWV0YWRhdGEgYXJlIHZlcnkgdXNlZnVsIGZvciBmb3JlbnNpYyBhbmFs eXNpcyB3aGVuIHNvbWV0aGluZyBnb2VzIHdyb25nLCBhcyB3ZWxsLg0KPg0KPkFkZGl0aW9uYWxs eSwgd2hpbGUgdGhlIGJ1bGsgb2YgdGhlIGFjdHVhbCBfZGF0YV8gdGhhdCBDRVJOIHN0b3JlcyBp cyByZWFsbHkgYmlnIGZpbGVzLCB0aGUgbGl0dGxlIGZpbGVzIG1hdHRlciBqdXN0IGFzIG11Y2gt LXRoZSB3b3JrIHJlc2VhcmNoZXJzIGFyZSBkb2luZywgcGFydGljdWxhcmx5IGNvbGxhYm9yYXRp dmVseS4gICBFbmFibGluZyBlZmZpY2llbnQgY29sbGFib3JhdGlvbiBvbiBhcnRpY2xlcyBpbiBw cm9ncmVzcywgZW5hYmxpbmcgZWZmZWN0aXZlIHNoYXJpbmcgb2YgY29kZSwgYW5kIHNvIG9uLCBh bGwgYXJlIHZlcnkgaW1wb3J0YW50IGRlc3BpdGUgcmVwcmVzZW50aW5nIGEgdGlueSBwZXJjZW50 YWdlIG9mIHRoZSB0b3RhbCBkYXRhIHN0b3JlZC4NCg0KSSBhZ3JlZSB0aGF0IGVmZmljaWVudCBj b2xsYWJvcmF0aW9uIGFuZCBvdGhlciBzaW1pbGFyIHdvcmtzIGluIHN5bmMgaXMgaW1wb3J0YW50 Lg0KSGVyZSwgSSBnb3QgYSBxdWVzdGlvbi4gSWYgdGhlIGRhdGEgaXMgdXNlZCBmb3IgcmVjb3Jk aW5nIHBoeXNpY2FsIGV2ZW50IGFuZCBuZXZlciBtb2RpZmllZC4NCkNvdWxkIHdlIGp1c3QgbWFy ayAicmVhZCBvbmx5IiBhbmQgcHJvaGliaXQgdXBkYXRlcyBmb3IgYWxsIG11bHRpcGxlIGNvcGll cyBhZnRlciB0aGUgZmlyc3Qgc3luYyBpcyBmaW5pc2hlZC4NCldoYXQgaXMgdGhlIGJlbmVmaXQg Zm9yIHVzaW5nIHZlcnNpb25pbmcgbWV0YWRhdGEgc3lzdGVtIGZvciB0aGlzIGNhc2U/DQoNCj4N Cj4NCj4tLQ0KPlNlbnQgZnJvbSBXaGl0ZW91dCBNYWlsIC0gaHR0cHM6Ly93aGl0ZW91dC5pbw0K Pg0KPk15IFBHUCBrZXk6IGh0dHBzOi8va2V5cy53aGl0ZW91dC5pby9tZWxsb25AZnVndWUuY29t From nobody Sat Dec 12 05:35:03 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3E01A875D for ; Sat, 12 Dec 2015 05:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKx0V-jFVj9H for ; Sat, 12 Dec 2015 05:35:01 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id ACDD41A0174 for ; Sat, 12 Dec 2015 05:35:00 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygDHaJ7mImxWPDQEAA--.9224S2; Sat, 12 Dec 2015 21:36:39 +0800 (CST) Date: Sat, 12 Dec 2015 21:34:39 +0800 From: "Fei Song" To: "Marc Blanchet" , mellon References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com>, <3A341032-4229-485C-9107-275968F581D1@viagenie.ca> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121221343932874725@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygDHaJ7mImxWPDQEAA--.9224S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZw17CrWfCr1xArWfXF1xAFb_yoWkCrc_CF WFg3s7tw15GFW3X3W3K3y3urZ7tay5CF17GryDtw1qg340y3WDA393trZ3ZFnaqrWrKFnx KwnFq3Z3Z39F9jkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbh8YjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC 0wACY4xI67k04243AVC20s07MxkIecxEwVAFwVW5GwCF04k20xvY0x0EwIxGrwCFx2IqxV CFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r10 6r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxV WUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG 6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr 0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUxBTYUUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Jakub Moscicki , storagesync Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 13:35:02 -0000 DQoNCg0KDQo+eW91IGFyZSBnaXZpbmcgYSBnb29kIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHZhc3Rs eSBkaWZmZXJlbnQuIENhbGVuZGVyaW5nIA0KPmlzIGEgdmVyeSB3ZWxsIHN0cnVjdHVyZWQgYW5k IHZlcnkgbGltaXRlZCBkYXRhc2V0IChjb21wYXJlZCB0byBmcmVlIA0KPnRleHQpIHRoYXQgd2Fz IG1hZGUgYnkgZGVzaWduIHdpdGggc3luYyBjb25zaWRlcmF0aW9ucy4gVGhlIGxhdGVzdCANCj52 ZXJzaW9uIG9mIHZjYXJkIHdhcyBhbHNvIGRlc2lnbmVkIHdpdGggc3luYyBjb25zaWRlcmF0aW9u cywgYW5kIGl0IHRvb2sgDQo+YSBsb3Qgb2YgdGltZSB0byBnZXQgaXQgcmlnaHQsIChJIGNhbiB0 ZWxsIHlvdSBJIHdhcyB0aGUgY2hhaXIgb2YgDQo+dmNhcmRkYXYgd2hlbiB3ZSBkaWQgdGhpcyku IEFuZCBhIHZjYXJkIGlzIGEgcHJldHR5IHNpbXBsZSBkYXRhc2V0IGFuZCANCj52ZXJ5IHN0cnVj dHVyZWQuDQoNCkdvb2QgdG8ga25vdyB0aGF0fg0KSWYgaXQgaXMgc28gaGFyZCBmb3Igc3VjaCBz aW1wbGUgYW5kIHdlbGwtc3RydWN0dXJlZCB2Y2FyZCBjYXNlLCBzaG91bGQgd2UgaGFuZGxlIHRo aXMgaXNzdWUgYnkgc2VwZXJhdGluZyBmaWxlIGJhc2VkIG9uIHRoZWlyIHByb3BlcnR5Pw0KVGhl IHNpdHVhdGlvbiBtaWdodCBiZSBlYXNpZXIuIA0KVGhlbiB0aGUgdXNlciBjYW4gZGVjaWRlIGF0 IHRoZSB2ZXJ5IGJlZ2lubmluZzogSSB3YW50IHRvIHNvbHZlICJGaWxlIGxldmVsIGNvbmZsaWN0 cyIgb3IgIkludGVybGVhdmVkIGxldmVsIGNvbmZsaWN0cyINCg0KPg0KPlNvIEkgdGhpbmsgeW91 ciBwb2ludCBqdXN0IHNob3dzIHRoZSBpbnZlcnNlLiBNZXJnaW5nIGNvbXBsZXgsIGZyZWUsIG5v dCANCj5zdHJ1Y3R1cmVkLWxpbWl0ZWQtZGF0YXNldCBmaWxlcyBpcyB2ZXJ5IHZlcnkgZGlmZmlj dWx0Lg0KPg0KPkkgZ3Vlc3MgeW91ciBnb2FsIGlzIGdyZWF0LCBidXQgdG8gbWUsIHRoYXQgaXMg Zm9yIHJlc2VhcmNoLiBTbyBpZiANCj5wZW9wbGUgd2FudCB0byBkbyB0aGlzIHdvcmssIEkgd291 bGQgc3BsaXQgaXQgaW50byB0d28gd29ya2luZyBncm91cHM6DQo+LSBvbmUgb24gdGhlIElSVEYg c2lkZSBhYm91dCBnZW5lcmljIHN5bmMtbWVyZ2UgYWxnb3JpdGhtcw0KPi0gb25lIG9uIHRoZSBJ RVRGIHNpZGUgZm9yIHRoZSBwcm90b2NvbCBjb21wb25lbnRzLg0KPg0KPk1hcmMuDQoNCkZlaSBT b25n From nobody Sat Dec 12 05:48:18 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4E01A8789 for ; Sat, 12 Dec 2015 05:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjdTx4pP_AA5 for ; Sat, 12 Dec 2015 05:48:15 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 058071A877D for ; Sat, 12 Dec 2015 05:48:14 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygAX7nAkJmxWujcEAA--.11067S2; Sat, 12 Dec 2015 21:50:28 +0800 (CST) Date: Sat, 12 Dec 2015 21:48:29 +0800 From: "Fei Song" To: mellon , storagesync References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <56689982.3040901@owncloud.com>, <1449698718120-5228f72d-575bb833-81b4c859@fugue.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121221482912563828@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygAX7nAkJmxWujcEAA--.11067S2 X-Coremail-Antispam: 1UD129KBjvJXoW7uryxZr1DAw4fZw4rZF1kKrg_yoW8tw1DpF W3K3W3Kr4qvr1rAr1xJw1Ig3WFy3yktr15Zw15Kr15A3y5XryxXF4qgw4jkFZ5u395uFyF qFZaqwnru3s0vaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBqb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0 F24lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Xr4l42xK82IYc2Ij64vIr41l4I8I3I 0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWU GVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI 0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0 rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r 1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8Za9DUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 13:48:17 -0000 DQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+V2VkbmVzZGF5LCBEZWMgOSwgMjAxNSA0 OjEzIFBNIEtsYWFzIEZyZWl0YWcgd3JvdGU6DQo+PiBBdXRvbWF0aWNhbGx5IG1lcmdlYWJsZSBv ciBub3QsIEkgZG9uJ3QgdGhpbmsgcmVzb2x2aW5nIGNvbmZsaWN0cyBzaG91ZGwNCj4+IGJlIHBh cnQgb2YgdGhlIHN5bmMgcHJvdG9jb2wuIE9mIGNvdXJzZSBjb25mbGljdHMgbXVzdCBiZSBkZXRl Y3RlZCBhbmQNCj4+IGhvb2tzIHNob3VsZCBleGlzdCB0byBwbHVnIGluIGNvZGUgdG8gd29yayB3 aXRoIGl0LCBidXQgSSBkb3VidCBpdA0KPj4gc2hvdWxkIGJlIHBhcnQgb2YgdGhlIHN5bmMgbGF5 ZXIgdG8gaW50ZXJwcmV0IGFuZCByZXNvbHZlIHRoZW0uDQo+DQo+SSBhZ3JlZSwgYXMgSSBzYWlk IHRvIE1hcmMuICAgQnV0IHRoZSBzeW5jIHByb3RvY29sIGhhcyB0byBfc3VwcG9ydF8gdGhlIGFj Y3VyYXRlIGRldGVjdGlvbiBvZiBjb25mbGljdHMsIG9yIHRoZXJlJ3Mgbm8gd2F5IHRvIHJlc29s dmUgdGhlbSwgYmVjYXVzZSB5b3UgZG9uJ3Qga25vdyBhYm91dCB0aGVtICh1bnRpbCB5b3VyIGNo YW5nZSBoYXMgYmVlbiBvdmVyd3JpdHRlbiwgYXQgd2hpY2ggcG9pbnQgaXQncyB0b28gbGF0ZSku DQoNCisxDQo+DQo+PiBBbmQgZXZlbiBpZiB0aGVyZSBpcyBhbiBhdXRvbWF0aWMgcmVzb2x2aW5n IG9mIGNvbmZsaWN0cyBmb3Igc29tZSBmaWxlDQo+PiB0eXBlcyAodGhhdCBpcyBvYnZpb3VzbHkg cG9zc2libGUgaWYgdGhhdCBpcyB3YW50ZWQgZnJvbSBhIGhpZ2hlciBsZXZlbA0KPj4gcG9pbnQg b2YgdmlldykgdGhlcmUgYWx3YXlzIHJlbWFpbnMgdGhlIHBvc3NpYmlsaXR5IG9mIG5vdCBhdCBh bGwNCj4+IGF1dG9tYXRpY2FsbHkgbWVyZ2VhYmxlIGNvbmZsaWN0cy4NCj4NCj5ZZXMsIEkgdGhp bmsgd2UgYWxsIGFncmVlIHRoYXQgdGhpcyBpcyBhIHByb2JsZW0uICAgTWFyYyBtZW50aW9uZWQg dGhhdCBoZSB0aGlua3MgaXQncyBhIHJlc2VhcmNoIHByb2JsZW0uICAgSSB0aGluayBhIGdlbmVy YWwgc29sdXRpb24gaXMgYSByZXNlYXJjaCBwcm9ibGVtLCBhbmQgbm90IGEgdmVyeSBpbnRlcmVz dGluZyBvbmU6IGFsbCBJIHJlYWxseSB3YW50IGlzIGEgd2F5IHRvIGtub3cgdGhhdCB0aGUgY29u ZmxpY3QgZXhpc3RzIGFuZCB3aGF0IHRoZSBzZXF1ZW5jZSBvZiBldmVudHMgd2FzOyBpZiBhbiBh dXRvbWF0aWMgbWVyZ2UgaXMgcG9zc2libGUsIHRoYXQncyBncmVhdCwgYnV0IG5vdCByZXF1aXJl ZC4NCj4NCj4+IEkgYW0gYWxzbyBub3Qgc3VyZSBhYm91dCB0aGUgaW1wb3J0YW5jZSBvZiB0aGUg c2VxdWVuY2Ugb2YgY2hhbmdlcywgYXMNCj4+IHRoZXJlIGFyZSBzaXR1YXRpb25zIGNhdXNlZCBm b3IgZXhhbXBsZSBieSBvZmZsaW5lIHdvcmssIHdoZXJlIGNoYW5nZXMNCj4+IGhhcHBlbiBpbiBw YXJhbGxlbCwgdGhlc2UgY2F1c2UgYSBjb25mbGljdCwgYW5kIGl0J3Mgbm90IHJlYWxseQ0KPj4g aW1wb3J0YW50IHdoaWNoIGNoYW5nZSB3YXMgYmVmb3JlIG9yIGFmdGVyLiBJbXBvcnRhbnQgaXMg dGhhdCBib3RoDQo+PiB2ZXJzaW9ucyBjYW4gYmUgZm91bmQgYWdhaW4sIGJ1dCBub3QgbmVjZXNz YXJpbHkgaW4gdGltZWx5IG9yZGVyLg0KPg0KPk5vdCByZW1lbWJlcmluZyB0aGUgb3JkZXIgaW4g d2hpY2ggdGhlIGNoYW5nZXMgb2NjdXJyZWQgaXMgYW4gb3B0aW1pemF0aW9uIHdoaWNoIGdhaW5z IHlvdSBhbG1vc3Qgbm8gZWZmaWNpZW5jeSBhbmQgY29zdHMgeW91IGdyZWF0bHkgaW4gdGVybXMg b2YgZnVuY3Rpb25hbGl0eS4NCg0KVGhlIG9yZGVyIG9mIGNoYW5nZXMgaXMgc2lnbmlmaWNhbnQg Zm9yIHNvbWUgY2FzZXMuIEluIG15IHJvdXRpbmUgd29yaywgZS5nLiBzb3VyY2UgY29kZSwgbGF0 ZXggZmlsZSwgZXRjLiBqdXN0IGJlbG9uZyB0byB0aGVzZSBjYXNlcy4NCg0KPg0KPj4gSSBkbyBu b3QgdW5kZXJzdGFuZCB3aHkgS3ViYSBzYWlkICJFdGFncyBhcmUgc3VmZmljaWVudCIgaW4gdGhp cw0KPj4gY29udGV4dCwgYnV0IG1heWJlIEkgbGFjayBjb250ZXh0IGJlY2F1c2UgSSBhbSBsYXRl IHRvIHRoZSBwYXJ0eS4uLg0KPg0KPkV0YWdzIGFyZSBzdWZmaWNpZW50IGlmIHlvdSBqdXN0IHdh bnQgdG8gc2VlIGlmIHdoYXQgeW91IGhhdmUgaXMgbW9yZSByZWNlbnQgaW4gdGltZSB0aGFuIHdo YXQncyBvbiB0aGUgc2VydmVyLiAgIFRoZXkgZG9uJ3QgYWxsb3cgeW91IHRvIGRldGVjdCBpbnRl cmxlYXZlZCB1cGRhdGVzLg0KPg0KPg0KPi0tDQo+U2VudCBmcm9tIFdoaXRlb3V0IE1haWwgLSBo dHRwczovL3doaXRlb3V0LmlvDQo+DQo+TXkgUEdQIGtleTogaHR0cHM6Ly9rZXlzLndoaXRlb3V0 LmlvL21lbGxvbkBmdWd1ZS5jb20= From nobody Sat Dec 12 06:07:25 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBED1A87CA for ; Sat, 12 Dec 2015 06:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mylWBTji_cg9 for ; Sat, 12 Dec 2015 06:07:23 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 73D381A87C5 for ; Sat, 12 Dec 2015 06:07:22 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygBnM1ezKmxW9jwEAA--.9255S2; Sat, 12 Dec 2015 22:09:55 +0800 (CST) Date: Sat, 12 Dec 2015 22:07:56 +0800 From: "Fei Song" To: "Linhui Sun" , storagesync References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> <1449698909826-ee50bf82-5c16ad1d-d704bcec@fugue.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121222075614049034@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygBnM1ezKmxW9jwEAA--.9255S2 X-Coremail-Antispam: 1UD129KBjvJXoW7KrWDuF1UGF18uFW3Xw18Zrb_yoW8Zr43pF W3Ka17Kr4kKr4Svwn3Aw1fWF4Yy3y8Kr43W3s5Gr17A345XFy7tr4kKr4F9ryDX3s5WF1Y qFs3Kwnxuw1DZFDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPmb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0 F24lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Xryl42xK82IYc2Ij64vIr41l4I8I3I 0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWU GwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI4 8JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4U MIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42 IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZE Xa7IU8lzutUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 14:07:24 -0000 DQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+SGksDQo+DQo+PkZyb20gdGhlIHByZXZp b3VzIG1lc3NhZ2VzLCBJIHRoaW5rIHdlIGFsbCBhZ3JlZSB0aGF0IHRoZSBjb25mbGljdA0KPnJl c29sdXRpb24gc2hvdWxkIGJlIGFub3RoZXIgbGF5ZXIncyBwcm9ibGVtLCB3aGV0aGVyIHRvIGVu YWJsZSBhbg0KPmF1dG9tYXRpYyBtZXJnaW5nIG1pZ2h0IGJlIGEgcmVzZWFyY2ggcHJvYmxlbSBv ciBhIGZ1cnRoZXIgdXNlIGNhc2UuIEJ1dCBJDQo+dGhpbmsgdGhlIHByb2JsZW0gYmVsb25ncyB0 byB0aGlzIGxpc3QgaXMgd2hldGhlciB3ZSBuZWVkIHRvIGRldGVjdCBtb3JlIG9uDQo+dGhlIGNv bmZsaWN0cyAobm90IHJlc29sdmluZyB0aGVtKS4gSnVzdCBrbm93aW5nIHRoZXJlIGFyZSBjb25m bGljdHMgT1INCj5rbm93aW5nIHdoYXQgYXJlIHRob3NlIGNvbmZsaWN0cywgd2hlbiBhbmQgd2hl cmUgZG8gdGhleSBjb21lIGZyb20gKGUuZy4NCj50aGUgc2VxdWVuY2Ugb2YgZGlmZmVyZW50IGNv bmZsaWN0IHZlcnNpb25zKS4gUGVyc29uYWxseSBJIHByZWZlciB0aGUNCj5sYXR0ZXIuIEp1c3Qg aW1hZ2luZSB3aGVuIHdlIHJlY29ubmVjdCBvdXIgZGV2aWNlIGFuZCBzZWUgbXVsdGlwbGUgY29u ZmxpY3QNCj52ZXJzaW9ucyBidXQgZG9uJ3Qga25vdyBhbnl0aGluZyBhYm91dCB0aGF0LiBIb3cg dG8gaGFuZGxlIHRoZW0/IFdoaWNoIG9uZQ0KPnNob3VsZCB3ZSBiZWdpbiB3aXRoPw0KPg0KPklN SE8sIHRoaXMgaXMgYSBkaXNjdXNzaW9uIG9uIHdoaWNoIGlzIGVub3VnaCwgZXRhZyBvciBtZXRh ZGF0YT8gQ29uZmxpY3QNCj5kZXRlY3Rpb24gaXMganVzdCBvbmUgb2YgdGhlIHJlbGF0ZWQgdXNl IGNhc2VzLg0KDQpJdCBzZWVtcyB0aGF0IG1ldGFkYXRhIHdpbGwgYmUgcmVxdWlyZWQgaWYgdGhl IHNlY29uZCBnb2FsIGlzIHNlbGVjdGVkLg0KSSB0aGluayB0aGUgY29uZmxpY3QgZGlzY292ZXJ5 IChyZXNvbHV0aW9uKSBzaG91bGQgYmUgYW4gaW1wb3J0YW50IHdvcmsgZm9yIElTUywgc2luY2Ug d2UgaGF2ZSBub3QgZ2V0IGNvbnNlbnN1cyBhYm91dCB3aGV0aGVyIGl0IHNob3VsZCBiZSBpbmNs dWRlZCBpbiBzeW5jIHByb3RvY29scy4NCg0KPg0KPlJlZ2FyZHMsDQo+TGluaHVpDQo+DQo+MjAx NS0xMi0xMCA2OjA4IEdNVCswODowMCBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+Og0KPg0K Pj4gV2VkbmVzZGF5LCBEZWMgOSwgMjAxNSA0OjI1IFBNIEpha3ViIE1vc2NpY2tpIHdyb3RlOg0K Pj4gPiBCdXQgSSB3b3VsZCBhbHNvIHRlbmQgdG8gZGlzYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVu dCB0aGF0IG1vc3Qgb2YgZmlsZXMNCj4+IGFyZSB0ZXh0IGZpbGVzIKGqIGFzIHdhcyBleHBsYWlu ZWQgYnkgTWFyYyBCbGFuY2hldCChqiBpbiBnZW5lcmFsIGl0IGlzIG5vdA0KPj4gdGhlIGNhc2Us IG5vdCBvbmx5IGZvciBDRVJOLg0KPj4NCj4+IEkgdGhpbmsgeW91IGFuZCBNYXJjIG1pc3VuZGVy c3Rvb2Qgd2hhdCBJIG1lYW4gYnkgInRleHQgZmlsZXMsIiBidXQgdGhhdCdzDQo+PiBpbW1hdGVy aWFsLiAgIFdoZXRoZXIgbWVyZ2VzIGNhbiBiZSBhY2NvbXBsaXNoZWQgYXV0b21hdGljYWxseSBv ciBub3QsDQo+PiBrbm93aW5nIHRoYXQgYSBjb25mbGljdCBoYXMgb2NjdXJyZWQsIGFuZCB3aGVu LCBhbmQgd2h5LCBpcyAoSU1ITykNCj4+IGltcG9ydGFudC4NCj4+DQo+Pg0KPj4gLS0NCj4+IFNl bnQgZnJvbSBXaGl0ZW91dCBNYWlsIC0gaHR0cHM6Ly93aGl0ZW91dC5pbw0KPj4NCj4+IE15IFBH UCBrZXk6IGh0dHBzOi8va2V5cy53aGl0ZW91dC5pby9tZWxsb25AZnVndWUuY29tDQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFN0b3Jh Z2VzeW5jIG1haWxpbmcgbGlzdA0KPj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+DQo+Pg0KPg== From nobody Sat Dec 12 06:10:12 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3401A1A87CB for ; Sat, 12 Dec 2015 06:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cvU_5SOk111 for ; Sat, 12 Dec 2015 06:10:09 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id F1E641A87CA for ; Sat, 12 Dec 2015 06:10:08 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygAHjTh5K2xWc3sDAA--.10634S2; Sat, 12 Dec 2015 22:13:14 +0800 (CST) Date: Sat, 12 Dec 2015 22:11:06 +0800 From: "Fei Song" To: "Linhui Sun" , storagesync References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> <1449698909826-ee50bf82-5c16ad1d-d704bcec@fugue.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121222110581219435@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygAHjTh5K2xWc3sDAA--.10634S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zry7Zw1fKryrtw4rXFWrZrb_yoW8Aw17pF W3Ka17Kr4ktr4Svw1kAwn7Wr1Yyr48tr47W345Kr17Aas8Xry7Jr4vgr4F9r9rX3s5WFyY qFs5Kw17uw1UZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPvb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0 F24lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Xryl42xK82IYc2Ij64vIr41l4I8I3I 0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWU GwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI4 8JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4U MIIF0xvE42xK8VAvwI8IcIk0rVW3JVWrJr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcV C2z280aVCY1x0267AKxVW8JVW8Jr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuY vjxU2BOJDUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1 X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 14:10:11 -0000 QSBxdWljayBzdXBwbGVtZW50OiB0aGUgZXRhZyBpcyBhbHNvIGdyZWF0IGlmIGZpbGUtbGV2ZWwg Y29uZmxpY3QgaXMgdGhlIHRhcmdldH4NCg0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5I aSwNCj4NCj4+RnJvbSB0aGUgcHJldmlvdXMgbWVzc2FnZXMsIEkgdGhpbmsgd2UgYWxsIGFncmVl IHRoYXQgdGhlIGNvbmZsaWN0DQo+cmVzb2x1dGlvbiBzaG91bGQgYmUgYW5vdGhlciBsYXllcidz IHByb2JsZW0sIHdoZXRoZXIgdG8gZW5hYmxlIGFuDQo+YXV0b21hdGljIG1lcmdpbmcgbWlnaHQg YmUgYSByZXNlYXJjaCBwcm9ibGVtIG9yIGEgZnVydGhlciB1c2UgY2FzZS4gQnV0IEkNCj50aGlu ayB0aGUgcHJvYmxlbSBiZWxvbmdzIHRvIHRoaXMgbGlzdCBpcyB3aGV0aGVyIHdlIG5lZWQgdG8g ZGV0ZWN0IG1vcmUgb24NCj50aGUgY29uZmxpY3RzIChub3QgcmVzb2x2aW5nIHRoZW0pLiBKdXN0 IGtub3dpbmcgdGhlcmUgYXJlIGNvbmZsaWN0cyBPUg0KPmtub3dpbmcgd2hhdCBhcmUgdGhvc2Ug Y29uZmxpY3RzLCB3aGVuIGFuZCB3aGVyZSBkbyB0aGV5IGNvbWUgZnJvbSAoZS5nLg0KPnRoZSBz ZXF1ZW5jZSBvZiBkaWZmZXJlbnQgY29uZmxpY3QgdmVyc2lvbnMpLiBQZXJzb25hbGx5IEkgcHJl ZmVyIHRoZQ0KPmxhdHRlci4gSnVzdCBpbWFnaW5lIHdoZW4gd2UgcmVjb25uZWN0IG91ciBkZXZp Y2UgYW5kIHNlZSBtdWx0aXBsZSBjb25mbGljdA0KPnZlcnNpb25zIGJ1dCBkb24ndCBrbm93IGFu eXRoaW5nIGFib3V0IHRoYXQuIEhvdyB0byBoYW5kbGUgdGhlbT8gV2hpY2ggb25lDQo+c2hvdWxk IHdlIGJlZ2luIHdpdGg/DQo+DQo+SU1ITywgdGhpcyBpcyBhIGRpc2N1c3Npb24gb24gd2hpY2gg aXMgZW5vdWdoLCBldGFnIG9yIG1ldGFkYXRhPyBDb25mbGljdA0KPmRldGVjdGlvbiBpcyBqdXN0 IG9uZSBvZiB0aGUgcmVsYXRlZCB1c2UgY2FzZXMuDQo+DQo+UmVnYXJkcywNCj5MaW5odWkNCj4N Cj4yMDE1LTEyLTEwIDY6MDggR01UKzA4OjAwIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT46 DQo+DQo+PiBXZWRuZXNkYXksIERlYyA5LCAyMDE1IDQ6MjUgUE0gSmFrdWIgTW9zY2lja2kgd3Jv dGU6DQo+PiA+IEJ1dCBJIHdvdWxkIGFsc28gdGVuZCB0byBkaXNhZ3JlZSB3aXRoIHlvdXIgc3Rh dGVtZW50IHRoYXQgbW9zdCBvZiBmaWxlcw0KPj4gYXJlIHRleHQgZmlsZXMgoaogYXMgd2FzIGV4 cGxhaW5lZCBieSBNYXJjIEJsYW5jaGV0IKGqIGluIGdlbmVyYWwgaXQgaXMgbm90DQo+PiB0aGUg Y2FzZSwgbm90IG9ubHkgZm9yIENFUk4uDQo+Pg0KPj4gSSB0aGluayB5b3UgYW5kIE1hcmMgbWlz dW5kZXJzdG9vZCB3aGF0IEkgbWVhbiBieSAidGV4dCBmaWxlcywiIGJ1dCB0aGF0J3MNCj4+IGlt bWF0ZXJpYWwuICAgV2hldGhlciBtZXJnZXMgY2FuIGJlIGFjY29tcGxpc2hlZCBhdXRvbWF0aWNh bGx5IG9yIG5vdCwNCj4+IGtub3dpbmcgdGhhdCBhIGNvbmZsaWN0IGhhcyBvY2N1cnJlZCwgYW5k IHdoZW4sIGFuZCB3aHksIGlzIChJTUhPKQ0KPj4gaW1wb3J0YW50Lg0KPj4NCj4+DQo+PiAtLQ0K Pj4gU2VudCBmcm9tIFdoaXRlb3V0IE1haWwgLSBodHRwczovL3doaXRlb3V0LmlvDQo+Pg0KPj4g TXkgUEdQIGtleTogaHR0cHM6Ly9rZXlzLndoaXRlb3V0LmlvL21lbGxvbkBmdWd1ZS5jb20NCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+PiBTdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPj4NCj4+DQo+ From nobody Sat Dec 12 06:15:48 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4579F1A0100 for ; Sat, 12 Dec 2015 06:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.588 X-Spam-Level: X-Spam-Status: No, score=0.588 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiCeLZsopWUE for ; Sat, 12 Dec 2015 06:15:44 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7E1A00B5 for ; Sat, 12 Dec 2015 06:15:42 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygD3eIy_LGxWnJUQAA--.26993S2; Sat, 12 Dec 2015 22:18:39 +0800 (CST) Date: Sat, 12 Dec 2015 22:16:31 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121222163146812636@bjtu.edu.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart262841775067_=----" X-CM-TRANSID: d55wygD3eIy_LGxWnJUQAA--.26993S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWr47AFWrXFykuw4UXF48Crg_yoW5tF17pF WfJwsxKayDX3yYv3ykXr4xurWFyFs3Gw45XFnxGw4xAwn8XFy0gF4xtr4ruFZ7Jry7Zw1q qr4Yvas8Ca4DZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQ0b7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2x7xS6r1j6r4UMc02F40E57IF 67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F40E42I26xC2a48xMc02F40Ex7 xS67I2xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE 14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k042 43AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6ry5MxAIw28IcxkI7VAK I48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7 AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE 2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIx AIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8Jr1l6VACY4xI 67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUgz6zUUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed (html) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 14:15:46 -0000 This is a multi-part message in MIME format. ------=_001_NextPart262841775067_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24uIFBsZWFzZSBlbWFpbCBtZSBpZiBhbnl0aGluZyBp cyBtaXNzZWQ6DQogDQoxLiAgICAgICAgIFRoZSBkZXNpZ24gdGFyZ2V0cyBvZiBXZWJEQVYsIHJz eW5jIGFuZCBvdGhlciBleGlzdGluZyBhcHByb2FjaGVzPw0KMi4gICAgICAgICBUaGUgcG90ZW50 aWFsIHVzZSBjYXNlcyBvZiBJU1MsIHN1Y2ggYXMgY2xpZW50L3NlcnZlciwgZ2l0LWxpa2UgcGF0 dGVybiwgc3ZuLCBldGMuDQozLiAgICAgICAgIFRoZSBlZmZpY2llbmN5IGltcHJvdmVtZW50cyBt aWdodCBiZSB0aGUgc2Vjb25kIGdvYWwgZm9yIHN0YW5kYXJkaXppbmcgSVNTIHByb3RvY29sDQo0 LiAgICAgICAgIENPUlMgaGVhZGVycyBvbiBzdG9yYWdlIHN5bmMgQVBJcw0KNS4gICAgICAgICBX aGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzogYSBzeW5jIHByb3RvY29sIG9yIGEgZ2VuZXJhbGl6 ZWQgQVBJDQo2LiAgICAgICAgIHJlbW90ZVN0b3JhZ2UgZHJhZnQgZGlzY3Vzc2lvbg0KYSkgICAg ICAgICByZWxhdGlvbnNoaXAgdnMgV2ViREFWDQpiKSAgICAgICAgIE1PVkUgYWN0aW9uIChzeW5j aHJvbml6YXRpb24pIHNob3VsZCBiZSBhZGRlZCBvciBub3QNCmMpICAgICAgICAgQmVzaWRlIHdl YiBicm93c2VyLCBkZXNrdG9wIGFwcHMgKGJ5IGhhY2tpbmcgd2F5KQ0KZCkgICAgICAgICBjb21p Y3Mgb2YgbmV3IHN0YW5kYXJkDQplKSAgICAgICAgIGV0YWcgaXNzdWVzIHZzIG1ldGFkYXRhDQog ICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIGlzIG1haW5seSBmb3IgaWRl bnRpZnlpbmcgd2hldGhlciBhIGRvY3VtZW50IGlzIGNoYW5nZWQgb3Igbm90DQogICAgICAgICAg ICAgICAgICAgICAgIGlpLiAgICAgICAgICAgICAgaXMgZWFzeSB0byBpbXBsZW1lbnQgdGhhbiB0 aGF0IG9mIFdlYkRBViBzeW5jIHByb3RvY29sIG9yIG5vdA0KICAgICAgICAgICAgICAgICAgICAg IGlpaS4gICAgICAgICAgICAgIHRoZSBtZXRhZGF0YSBmaWxlIGNvbnRhaW5zIGFsbCBldGFncyBm b3IgYWxsIGZpbGVzIGF0IGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgc2lkZSBvciBub3QNCmYpICAg ICAgICAgIHRoZSBkaXN0cmlidXRlZCBwZWVyIG1vZGVsIChubyBzZXJ2ZXIpIGFuZCBDL1MgbW9k ZQ0KZykgICAgICAgICBhIGZhbmN5IGV4YW1wbGUgKHdpdGggcGljcykgb2YgT2ZmbGluZUlNQVCh r3Mgc3luYyBwcm9jZXNzIGluIGZvbGxvd2luZyBVUkwNCmh0dHA6Ly9ibG9nLmV6eWFuZy5jb20v MjAxMi8wOC9ob3ctb2ZmbGluZWltYXAtd29ya3MvDQo3LiAgICAgICAgIEdpdEh1YiAoaW5zdGVh ZCBvZiBlbWFpbCBtZXNzYWdlcykgaGFzIGJlZW4gY3JlYXRlZDoNCmh0dHBzOi8vZ2l0aHViLmNv bS9sYWJrb2RlL0ludGVybmV0LVN0b3JhZ2UtU3luYw0KYSkgICAgICAgICBXaGF0IGlzIHRoZSB0 b3BpYz8gDQogICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIFdoZXRoZXIg aXQgaXMgc3VpdGFibGUgdG8gYnVpbGQgb24gV2ViREFWDQogICAgICAgICAgICAgICAgICAgICAg IGlpLiAgICAgICAgICAgICAgV2ViREFWIHZzIHJlbW90ZVN0b3JhZ2UNCiAgICAgICAgICAgICAg ICAgICAgICBpaWkuICAgICAgICAgICAgICBBZHZhbnRhZ2VzIHZzIGRpc2FkdmFudGFnZXMgb2Yg V2ViREFWDQo4LiAgICAgICAgIE1ldGFkYXRhIGFuZCBkYXRhIHNlcGFyYXRpb24gc2NoZW1lIGFu ZCBwbGF0Zm9ybSBmb3Igc3luY2hyb25pemF0aW9uDQphKSAgICAgICAgIG93bkNsb3VkIHdoZW4g Y29uZmlndXJlZCB0byB1c2UgYW4gT2JqZWN0IFN0b3JhZ2UgYXMgdGhlIFByaW1hcnkgVXNlciBT dG9yYWdlLiAoTWV0YWRhdGEgaXMgaGFuZGxlZCBieSBhIE15U1FMIGRhdGFiYXNlKQ0KYikgICAg ICAgICBDRVJOIEVPUyBTdG9yYWdlIFN5c3RlbS4gKE1ldGFkYXRhIGlzIGhhbmRsZWQgaW4gaGln aCBwZXJmb3JtYW5jZSBpbi1tZW1vcnkgc3RydWN0dXJlcykuDQpjKSAgICAgICAgIERyb3BCb3gu IChBcyBmYXIgYXMgSSBrbm93IGl0IHVzZXMgUzMgYmVoaW5kLiBGb3IgbWV0YWRhdGEgaXQgaXMg dW5rbm93biwgYnV0IHByb2JhYmx5IG5vdCBvbiBTMykuIA0KUGFwZXIgZm9yIGFuYWx5emluZyBE cm9wQm94Og0KaHR0cDovL2FubmFzcGVyb3R0by5vcmcvcGFwZXJzLzIwMTIvaW1jMTQwLWRyYWdv LnBkZg0KZCkgICAgICAgICBDbGF3SU8gd2lsbCBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIHRo aXMgYXBwcm9hY2ggaW4gdGhlIG5leHQgcGhhc2UgdXNpbmcgU3dpZnQuDQo5LiAgICAgICAgIFdo ZXRoZXIgd2Ugc2hvdWxkIGtlZXAgbWV0YWRhdGEgaGlzdG9yeSBvciBtb2RpZmljYXRpb24gaGlz dG9yeSBvciBhY3Rpb24gaGlzdG9yeSBhdCBzZXJ2ZXIgc2lkZSAob3Igb3RoZXIgcGxhY2VzKQ0K MTAuICAgICBIb3cgdG8gaGFuZGxlIHRoZSChsGNvbmZsaWN0IGRpc2NvdmVyeSAocmVzb2x1dGlv bimhsSBpc3N1ZXMNCmEpICAgICAgICAgQSBnb29kIGRlbW9uc3RyYXRpb24gb2YgdGhpcyBpc3N1 ZSB3YXMgZ2l2ZW4gaW4gZGV0YWlscyAoRmlsZSBGLCBDbGllbnQgQSwgQ2xpZW50IEIsIGV0Yy4p DQpiKSAgICAgICAgIFNob3VsZCBpdCBiZSBhIGxheWVyIGFib3ZlIHN5bmNpbmc/DQpjKSAgICAg ICAgIFNob3VsZCBpdCBkZXBlbmQgb24gdGhlIHVzZSBjYXNlPw0KZCkgICAgICAgICBTaG91bGQg aXQgYmUgYSBvbmUtc2l6ZS1maXRzLWFsbCBhcHByb2FjaD8NCmUpICAgICAgICAgSG93IG1hbnkg ZGlmZmVyZW50IGtpbmRzIG9mIGNvbmZsaWN0Pw0KICAgICAgICAgICAgICAgICAgICAgICAgIGku ICAgICAgICAgICAgICBGaWxlIGxldmVsIGNvbmZsaWN0cywgZS5nLiBib3RoIHJlbW90ZSAoc2Vy dmVyKSBhbmQgbG9jYWwgKGNsaWVudCkgaGF2ZSBjaGFuZ2VkIHNpbmNlIGxhc3Qgc3luYy4NCiAg ICAgICAgICAgICAgICAgICAgICAgaWkuICAgICAgICAgICAgICBJbnRlcmxlYXZlZCBsZXZlbCBj b25mbGljdHMsIGUuZy4gb25lIGNsaWVudCBtYWtlcyBhIGNoYW5nZSBiYXNlZCBvbiB2ZXJzaW9u IFggb2YgdGhlIGZpbGUsIGEgc2Vjb25kIG1ha2VzIGEgY2hhbmdlIGJhc2VkIG9uIHZlcnNpb24g WCsxLCB0aGUgc2Vjb25kIG9uZSBjb21taXRzLCBhbmQgdGhlbiB0aGUgZmlyc3Qgb25lIGNvbW1p dHMuDQogICAgICAgICAgICAgICAgICAgICAgaWlpLiAgICAgICAgICAgICAgoa0NCmYpICAgICAg ICAgIFRoZSBzZXF1ZW5jZSAob3JkZXIpIG9mIGNoYW5nZXMgaW4gb25lIGZpbGUgaXMgaW1wb3J0 YW50IG9yIG5vdCAocXVpdGUgc2ltaWxhciB3aXRoIKGwaXRlbSA5obEgaW4gdGhpcyBsaXN0KSwg cGVyaGFwcyBkZXBlbmRzIG9uIHRoZSBmaWxlIHR5cGUgKG9yIHVzZSBjYXNlcyk6DQogICAgICAg ICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIEl0IG1heSBiZSBpbXBvcnRhbnQgZm9y OiBzb3VuZCBmaWxlLCBkcmF3aW5nIGZpbGUsIGxhdGV4IHNvdXJjZSBmaWxlcyBvZiBhcnRpY2xl cywgaVdvcmsgZmlsZXMsIE9mZmljZSBmaWxlcywgaW1hZ2VzLCBwZGZzLCBzb3VyY2UgY29kZSwg ZXRjLg0KICAgICAgICAgICAgICAgICAgICAgICBpaS4gICAgICAgICAgICAgIEl0IG1heSBiZSBu b3QgaW1wb3J0YW50IGZvcjogUGh5c2ljcyBkYXRhLg0KZykgICAgICAgICBXaGV0aGVyIHRvIGVu YWJsZSBhbiBhdXRvbWF0aWMgbWVyZ2luZyBtaWdodCBiZSBhIHJlc2VhcmNoIHByb2JsZW0gb3Ig YSBmdXJ0aGVyIHVzZSBjYXNlPw0KaCkgICAgICAgICBJZiBJdCBpcyBzbyBoYXJkIHRvIGRvIGNv bmZsaWN0IHJlc29sdXRpb24gZXZlbiBmb3Igc2ltcGxlIGFuZCB3ZWxsLXN0cnVjdHVyZWQgobB2 Y2FyZCBjYXNlobEsIHNob3VsZCB3ZSBoYW5kbGUgdGhpcyBpc3N1ZSBieSBzZXBhcmF0aW5nIGZp bGVzIGJhc2VkIG9uIHRoZWlyIHByb3BlcnR5Pw0KICANClNvbWUgcmVsYXRlZCBvcmdhbml6YXRp b25zLCBldmVudHMsIHByb2plY3RzLCBldGMuOiANCkdFQU5UIGNvbW11bml0eSwgT3BlbkNsb3Vk TWVzaCwgb3duQ2xvdWQsIENTMywgcmVtb3RlU3RvcmFnZSwgQ2xhd0lPLCBjcm9zc2Nsb3VkLCBE cm9wYm94LCBDRVJOIEVPUyBTdG9yYWdlIFN5c3RlbSx0byBiZSBhZGRlZKGt ------=_001_NextPart262841775067_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Here is the latest version. Please email me if anything is=20 missed:

 

1.      =   =20 The = design=20 targets of WebDAV, rsync and other existing approaches?

2.      =   =20 The = potential=20 use cases of ISS, such as client/server, git-like pattern, svn,=20 etc.

3.      =   =20 The = efficiency=20 improvements might be the second goal for standardizing ISS=20 protocol

4.      =   =20 CORS= headers on=20 storage sync APIs

5.      =   =20 What= is needed=20 for the ISS: a sync protocol or a generalized API

6.      =   =20 remo= teStorage=20 draft discussion

a)      =   =20 rela= tionship vs=20 WebDAV

b)      =   =20 MOVE= action=20 (synchronization) should be added or not

c)      =   =20 Besi= de web=20 browser, desktop apps (by hacking way)

d)      =   =20 comi= cs of new=20 standard

e)      =   =20 etag= issues vs=20 metadata

      =             &n= bsp;     =20 i.      =        =20 is m= ainly for=20 identifying whether a document is changed or not

      =             &n= bsp;   =20 ii.      =        =20 is e= asy to=20 implement than that of WebDAV sync protocol or not

      =             &n= bsp;  =20 iii.      =        =20 the = metadata=20 file contains all etags for all files at both client and server side or=20 not

f)      =    =20 the = distributed=20 peer model (no server) and C/S mode

g)      =   =20 a fa= ncy example=20 (with pics) of OfflineIMAP=A1=AFs sync process in following URL

http://blog.ezyang.com/2012/08/how-offlineimap-works/

7.      =   =20 GitH= ub (instead=20 of email messages) has been created:

<= FONT=20 size=3D3=20 face=3DCalibri>https://github.com/labkode/Internet-Storage-Sync

a)      =   =20 What= is the=20 topic?

      =             &n= bsp;     =20 i.      =        =20 Whet= her it is=20 suitable to build on WebDAV

      =             &n= bsp;   =20 ii.      =        =20 WebD= AV vs=20 remoteStorage

      =             &n= bsp;  =20 iii.      =        =20 Adva= ntages vs=20 disadvantages of WebDAV

8.      =   =20 Meta= data and=20 data separation scheme and platform for synchronization

a)      =   =20 ownC= loud when=20 configured to use an Object Storage as the Primary User Storage. (Metadata= is=20 handled by a MySQL database)

b)      =   =20 CERN= EOS Storage=20 System. (Metadata is handled in high performance in-memory=20 structures).

c)      =   =20 Drop= Box. (As far=20 as I know it uses S3 behind. For metadata it is unknown, but probably not = on=20 S3).

= Paper for=20 analyzing DropBox:

<= FONT=20 size=3D3=20 face=3DCalibri>http://annasperotto.org/papers/2012/imc140-drago.pdf=

d)      =   =20 Claw= IO will have=20 an implementation of this approach in the next phase using=20 Swift.

9.      =   =20 Whet= her we=20 should keep metadata history or modification history or action history at = server=20 side (or other places)

10.    =20 How = to handle=20 the =A1=B0conflict discovery (resolution)=A1=B1 issues

a)      =   =20 A go= od=20 demonstration of this issue was given in details (File F, Client A, Client= B,=20 etc.)

b)      =   =20 Shou= ld it be a=20 layer above syncing?

c)      =   =20 Shou= ld it depend=20 on the use case?

d)      =   =20 Shou= ld it be a=20 one-size-fits-all approach?

e)      =   =20 How = many=20 different kinds of conflict?

      =             &n= bsp;     =20 i.      =        =20 File= level=20 conflicts, e.g. both remote (server) and local (client) have changed since= last=20 sync.

      =             &n= bsp;   =20 ii.      =        =20 Inte= rleaved=20 level conflicts, e.g. one client makes a change based on version X of the = file,=20 a second makes a change based on version X+1, the second one commits, and = then=20 the first one commits.

      =             &n= bsp;  =20 iii.      =        =20 =A1=AD

f)      =    =20 The = sequence=20 (order) of changes in one file is important or not (quite similar with =A1= =B0item 9=A1=B1=20 in this list), perhaps depends on the file type (or use=20 cases):

      =             &n= bsp;     =20 i.      =        =20 It m= ay be=20 important for: sound file, drawing file, latex source files of articles, i= Work=20 files, Office files, images, pdfs, source code, etc.

      =             &n= bsp;   =20 ii.      =        =20 It m= ay be not=20 important for: Physics data.

g)      =   =20 Whet= her to=20 enable an automatic merging might be a research problem or a further use=20 case?

h)      =   =20 If I= t is so hard=20 to do conflict resolution even for simple and well-structured =A1=B0vcard = case=A1=B1,=20 should we handle this issue by separating files based on their=20 property?

 =  

Some related organizations, events, projects, etc.:=20

GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorag= e,=20 ClawIO, crosscloud, Dropbox, CERN EOS Storage System,to be=20 added=A1=AD

------=_001_NextPart262841775067_=------ From nobody Sat Dec 12 06:21:20 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BCE1A1A93 for ; Sat, 12 Dec 2015 06:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.989 X-Spam-Level: **** X-Spam-Status: No, score=4.989 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_62=0.6, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqOnr50Iuexp for ; Sat, 12 Dec 2015 06:21:17 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 91B571A0275 for ; Sat, 12 Dec 2015 06:21:16 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygDn7vYULmxW_4wQAA--.14064S2; Sat, 12 Dec 2015 22:24:20 +0800 (CST) Date: Sat, 12 Dec 2015 22:22:14 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121222221445314637@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygDn7vYULmxW_4wQAA--.14064S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWr47AFWrXFykuw4UXF48Crg_yoW5tF17pF WfJwsxKayDX3yYv3ykXr4xurWFyFs3Gw45XFnxGw4xAwn8XFy0gF4xtr4ruFZ7Jry7Zw1q qr4Yvas8Ca4DZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Xryl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07 jYKZAUUUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed (plain text) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 14:21:18 -0000 SGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24uIFBsZWFzZSBlbWFpbCBtZSBpZiBhbnl0aGluZyBp cyBtaXNzZWQ6DQoNCjEuVGhlIGRlc2lnbiB0YXJnZXRzIG9mIFdlYkRBViwgcnN5bmMgYW5kIG90 aGVyIGV4aXN0aW5nIGFwcHJvYWNoZXM/DQoyLlRoZSBwb3RlbnRpYWwgdXNlIGNhc2VzIG9mIElT Uywgc3VjaCBhcyBjbGllbnQvc2VydmVyLCBnaXQtbGlrZSBwYXR0ZXJuLCBzdm4sIGV0Yy4NCjMu VGhlIGVmZmljaWVuY3kgaW1wcm92ZW1lbnRzIG1pZ2h0IGJlIHRoZSBzZWNvbmQgZ29hbCBmb3Ig c3RhbmRhcmRpemluZyBJU1MgcHJvdG9jb2wNCjQuQ09SUyBoZWFkZXJzIG9uIHN0b3JhZ2Ugc3lu YyBBUElzDQo1LldoYXQgaXMgbmVlZGVkIGZvciB0aGUgSVNTOiBhIHN5bmMgcHJvdG9jb2wgb3Ig YSBnZW5lcmFsaXplZCBBUEkNCjYucmVtb3RlU3RvcmFnZSBkcmFmdCBkaXNjdXNzaW9uDQogIGEp cmVsYXRpb25zaGlwIHZzIFdlYkRBVg0KICBiKU1PVkUgYWN0aW9uIChzeW5jaHJvbml6YXRpb24p IHNob3VsZCBiZSBhZGRlZCBvciBub3QNCiAgYylCZXNpZGUgd2ViIGJyb3dzZXIsIGRlc2t0b3Ag YXBwcyAoYnkgaGFja2luZyB3YXkpDQogIGQpY29taWNzIG9mIG5ldyBzdGFuZGFyZA0KICBlKWV0 YWcgaXNzdWVzIHZzIG1ldGFkYXRhDQogICAgaS5pcyBtYWlubHkgZm9yIGlkZW50aWZ5aW5nIHdo ZXRoZXIgYSBkb2N1bWVudCBpcyBjaGFuZ2VkIG9yIG5vdA0KICAgIGlpLmlzIGVhc3kgdG8gaW1w bGVtZW50IHRoYW4gdGhhdCBvZiBXZWJEQVYgc3luYyBwcm90b2NvbCBvciBub3QNCiAgICBpaWku dGhlIG1ldGFkYXRhIGZpbGUgY29udGFpbnMgYWxsIGV0YWdzIGZvciBhbGwgZmlsZXMgYXQgYm90 aCBjbGllbnQgYW5kIHNlcnZlciBzaWRlIG9yIG5vdA0KICBmKXRoZSBkaXN0cmlidXRlZCBwZWVy IG1vZGVsIChubyBzZXJ2ZXIpIGFuZCBDL1MgbW9kZQ0KICBnKWEgZmFuY3kgZXhhbXBsZSAod2l0 aCBwaWNzKSBvZiBPZmZsaW5lSU1BUKGvcyBzeW5jIHByb2Nlc3MgaW4gZm9sbG93aW5nIFVSTA0K ICAgIGh0dHA6Ly9ibG9nLmV6eWFuZy5jb20vMjAxMi8wOC9ob3ctb2ZmbGluZWltYXAtd29ya3Mv DQo3LkdpdEh1YiAoaW5zdGVhZCBvZiBlbWFpbCBtZXNzYWdlcykgaGFzIGJlZW4gY3JlYXRlZDoN CiAgaHR0cHM6Ly9naXRodWIuY29tL2xhYmtvZGUvSW50ZXJuZXQtU3RvcmFnZS1TeW5jDQogIGEp V2hhdCBpcyB0aGUgdG9waWM/IA0KICAgIGkuV2hldGhlciBpdCBpcyBzdWl0YWJsZSB0byBidWls ZCBvbiBXZWJEQVYNCiAgICBpaS5XZWJEQVYgdnMgcmVtb3RlU3RvcmFnZQ0KICAgIGlpaS5BZHZh bnRhZ2VzIHZzIGRpc2FkdmFudGFnZXMgb2YgV2ViREFWDQo4Lk1ldGFkYXRhIGFuZCBkYXRhIHNl cGFyYXRpb24gc2NoZW1lIGFuZCBwbGF0Zm9ybSBmb3Igc3luY2hyb25pemF0aW9uDQogIGEpb3du Q2xvdWQgd2hlbiBjb25maWd1cmVkIHRvIHVzZSBhbiBPYmplY3QgU3RvcmFnZSBhcyB0aGUgUHJp bWFyeSBVc2VyIFN0b3JhZ2UuIChNZXRhZGF0YSBpcyBoYW5kbGVkIGJ5IGEgTXlTUUwgZGF0YWJh c2UpDQogIGIpQ0VSTiBFT1MgU3RvcmFnZSBTeXN0ZW0uIChNZXRhZGF0YSBpcyBoYW5kbGVkIGlu IGhpZ2ggcGVyZm9ybWFuY2UgaW4tbWVtb3J5IHN0cnVjdHVyZXMpLg0KICBjKURyb3BCb3guIChB cyBmYXIgYXMgSSBrbm93IGl0IHVzZXMgUzMgYmVoaW5kLiBGb3IgbWV0YWRhdGEgaXQgaXMgdW5r bm93biwgYnV0IHByb2JhYmx5IG5vdCBvbiBTMykuIA0KICAgIFBhcGVyIGZvciBhbmFseXppbmcg RHJvcEJveDoNCiAgICBodHRwOi8vYW5uYXNwZXJvdHRvLm9yZy9wYXBlcnMvMjAxMi9pbWMxNDAt ZHJhZ28ucGRmDQogIGQpQ2xhd0lPIHdpbGwgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlz IGFwcHJvYWNoIGluIHRoZSBuZXh0IHBoYXNlIHVzaW5nIFN3aWZ0Lg0KOS5XaGV0aGVyIHdlIHNo b3VsZCBrZWVwIG1ldGFkYXRhIGhpc3Rvcnkgb3IgbW9kaWZpY2F0aW9uIGhpc3Rvcnkgb3IgYWN0 aW9uIGhpc3RvcnkgYXQgc2VydmVyIHNpZGUgKG9yIG90aGVyIHBsYWNlcykNCjEwLkhvdyB0byBo YW5kbGUgdGhlIKGwY29uZmxpY3QgZGlzY292ZXJ5IChyZXNvbHV0aW9uKaGxIGlzc3Vlcw0KICBh KUEgZ29vZCBkZW1vbnN0cmF0aW9uIG9mIHRoaXMgaXNzdWUgd2FzIGdpdmVuIGluIGRldGFpbHMg KEZpbGUgRiwgQ2xpZW50IEEsIENsaWVudCBCLCBldGMuKQ0KICBiKVNob3VsZCBpdCBiZSBhIGxh eWVyIGFib3ZlIHN5bmNpbmc/DQogIGMpU2hvdWxkIGl0IGRlcGVuZCBvbiB0aGUgdXNlIGNhc2U/ DQogIGQpU2hvdWxkIGl0IGJlIGEgb25lLXNpemUtZml0cy1hbGwgYXBwcm9hY2g/DQogIGUpSG93 IG1hbnkgZGlmZmVyZW50IGtpbmRzIG9mIGNvbmZsaWN0Pw0KICAgIGkuRmlsZSBsZXZlbCBjb25m bGljdHMsIGUuZy4gYm90aCByZW1vdGUgKHNlcnZlcikgYW5kIGxvY2FsIChjbGllbnQpIGhhdmUg Y2hhbmdlZCBzaW5jZSBsYXN0IHN5bmMuDQogICAgaWkuSW50ZXJsZWF2ZWQgbGV2ZWwgY29uZmxp Y3RzLCBlLmcuIG9uZSBjbGllbnQgbWFrZXMgYSBjaGFuZ2UgYmFzZWQgb24gdmVyc2lvbiBYIG9m IHRoZSBmaWxlLCBhIHNlY29uZCBtYWtlcyBhIGNoYW5nZSBiYXNlZCBvbiB2ZXJzaW9uIFgrMSwg dGhlIHNlY29uZCBvbmUgY29tbWl0cywgYW5kIHRoZW4gdGhlIGZpcnN0IG9uZSBjb21taXRzLg0K ICAgIGlpaS6hrQ0KICBmKVRoZSBzZXF1ZW5jZSAob3JkZXIpIG9mIGNoYW5nZXMgaW4gb25lIGZp bGUgaXMgaW1wb3J0YW50IG9yIG5vdCAocXVpdGUgc2ltaWxhciB3aXRoIKGwaXRlbSA5obEgaW4g dGhpcyBsaXN0KSwgcGVyaGFwcyBkZXBlbmRzIG9uIHRoZSBmaWxlIHR5cGUgKG9yIHVzZSBjYXNl cyk6DQogICAgaS5JdCBtYXkgYmUgaW1wb3J0YW50IGZvcjogc291bmQgZmlsZSwgZHJhd2luZyBm aWxlLCBsYXRleCBzb3VyY2UgZmlsZXMgb2YgYXJ0aWNsZXMsIGlXb3JrIGZpbGVzLCBPZmZpY2Ug ZmlsZXMsIGltYWdlcywgcGRmcywgc291cmNlIGNvZGUsIGV0Yy4NCiAgICBpaS5JdCBtYXkgYmUg bm90IGltcG9ydGFudCBmb3I6IFBoeXNpY3MgZGF0YS4NCiAgZylXaGV0aGVyIHRvIGVuYWJsZSBh biBhdXRvbWF0aWMgbWVyZ2luZyBtaWdodCBiZSBhIHJlc2VhcmNoIHByb2JsZW0gb3IgYSBmdXJ0 aGVyIHVzZSBjYXNlPw0KICBoKUlmIEl0IGlzIHNvIGhhcmQgdG8gZG8gY29uZmxpY3QgcmVzb2x1 dGlvbiBldmVuIGZvciBzaW1wbGUgYW5kIHdlbGwtc3RydWN0dXJlZCChsHZjYXJkIGNhc2WhsSwg c2hvdWxkIHdlIGhhbmRsZSB0aGlzIGlzc3VlIGJ5IHNlcGFyYXRpbmcgZmlsZXMgYmFzZWQgb24g dGhlaXIgcHJvcGVydHk/DQoNCg0KU29tZSByZWxhdGVkIG9yZ2FuaXphdGlvbnMsIGV2ZW50cywg cHJvamVjdHMsIGV0Yy46IA0KR0VBTlQgY29tbXVuaXR5LCBPcGVuQ2xvdWRNZXNoLCBvd25DbG91 ZCwgQ1MzLCByZW1vdGVTdG9yYWdlLCBDbGF3SU8sIGNyb3NzY2xvdWQsIERyb3Bib3gsIENFUk4g RU9TIFN0b3JhZ2UgU3lzdGVtLHRvIGJlIGFkZGVkoa0NCg== From nobody Sat Dec 12 23:57:23 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2901AC3BE for ; Sat, 12 Dec 2015 23:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFcTjUrY-tOP for ; Sat, 12 Dec 2015 23:57:13 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0681.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::681]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF211AC3B8 for ; Sat, 12 Dec 2015 23:57:11 -0800 (PST) Received: from DB4PR06CA0006.eurprd06.prod.outlook.com (2a01:111:e400:9866::16) by AM3PR06MB050.eurprd06.prod.outlook.com (2a01:111:e400:8805::24) with Microsoft SMTP Server (TLS) id 15.1.355.16; Sun, 13 Dec 2015 07:56:52 +0000 Received: from AM1FFO11FD018.protection.gbl (2a01:111:f400:7e00::183) by DB4PR06CA0006.outlook.office365.com (2a01:111:e400:9866::16) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Sun, 13 Dec 2015 07:56:52 +0000 Authentication-Results: spf=pass (sender IP is 188.184.36.48) smtp.mailfrom=cern.ch; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=cern.ch; Received-SPF: Pass (protection.outlook.com: domain of cern.ch designates 188.184.36.48 as permitted sender) receiver=protection.outlook.com; client-ip=188.184.36.48; helo=CERNMX12.cern.ch; Received: from CERNMX12.cern.ch (188.184.36.48) by AM1FFO11FD018.mail.protection.outlook.com (10.174.64.207) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Sun, 13 Dec 2015 07:56:52 +0000 Received: from CERNFE25.cern.ch (137.138.203.208) by cernmxgwlb4.cern.ch (188.184.36.48) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 13 Dec 2015 08:56:35 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE25.cern.ch ([fe80::2cd7:dab6:37a7:ce81%10]) with mapi id 14.03.0174.001; Sun, 13 Dec 2015 08:56:35 +0100 From: Jakub Moscicki To: fsong Thread-Topic: [Storagesync] recent issues discussed (html) Thread-Index: AQHRNOef7oC/x3UBPEaZ+1qHcoBay57IfP8A Date: Sun, 13 Dec 2015 07:56:34 +0000 Message-ID: <41F39F50-E49A-4C2B-BF09-B182580008DF@cern.ch> References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <2015121222163146812636@bjtu.edu.cn> In-Reply-To: <2015121222163146812636@bjtu.edu.cn> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.28.197.96] Content-Type: multipart/alternative; boundary="_000_41F39F50E49A4C2BBF09B182580008DFcernch_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD018; 1:0oT9fX1t3IJBwEVrDsewL73LFdl5cnOC+PbVIqVkNQ/UwDsL5Q4Mu9+oYrVdbICJv3KO1uBQtADHwlSMYpMx0upWbIGLR9wSELhtl8xfJqxhnuVaFl7GOlrkWAanFdb4GWXqASViy5nH2z15oWhBVNNf1hyguY5Qt+mkBcZp0Xft+o9ReJttdj8IRKB48iptBbSEMrzhu72HJcbx/pEusdk9Pg27H4fPUf/PYf9U3GvKFWp5CkgHk0Xc0oiaaR4ZOeoUe+FKj8XnJfCObz9b/w8rKd29RYoPimDAoqZxdClbv5Dd4gN4n4kcKQXt8Ch5ZxnxlLuiG/hL26/Tg5j1qquCM/fcGSxyve+5oNC4g1jbR6pDq3J3nPHAvp+b5s0YYGNcD+/fDbEtmwDjczDsVREE0BziyKd5CsCcLkWBc5w= X-Forefront-Antispam-Report: CIP:188.184.36.48; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(2980300002)(438002)(189002)(199003)(24454002)(243025005)(1096002)(76176999)(54356999)(83716003)(86362001)(53416004)(19617315012)(16236675004)(106116001)(2171001)(87936001)(16796002)(93886004)(5004730100002)(106466001)(82746002)(92566002)(66066001)(2900100001)(74482002)(84326002)(11100500001)(15975445007)(50986999)(2950100001)(3846002)(1220700001)(26826002)(102836003)(189998001)(19580395003)(5001970100001)(36756003)(15395725005)(110136002)(5008740100001)(300700001)(6116002)(512874002)(5003600100002)(6806005)(586003)(5250100002)(19580405001)(33656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR06MB050; H:CERNMX12.cern.ch; FPR:; SPF:Pass; PTR:cernmx12.cern.ch; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB050; 2:lOasew/Kncrj2pKAErhTjPpaPwJEJUfzrv1oNTaZatfoClsvA8p39O/iK8JJPC0CecolNVmhHEQYpKXR2Nx+VN+sWLY+l1RnF3pCN4j+QDYh5KeikEOhV7grlZRkn/sEiZmp1ndh96o3/8ThLiXK6w==; 3:cLg67OJt0CatwE/lepxEH0cJQSOOjD9ZsQpo+4SPEPKYNNSoEY08UfiLBp6ZrPD7gWeylXeKeuUmHmQPMgYt+k0o+fMewhhsSh0ztFfzIKpuI8MgibFMCUXyMQZB3tPtTZkccvxL9UORyhswFRLXL13cjwYN2aqJCNsqZ2Z5We59D0PJPZqe7uXWw3hmXQyrhrEQk7ZTUkHMiX69YIAzpSfRKrZ4q6akIBiAFIJkgQ/yig2t6CPFWFrK3yrsi3QssdDUMuQpZET7JlhoFFu1vw==; 25:fCFBojaqDAvtYSkUJ+P0mq5wJqbpEmB3B46Nz9jUC5vEDlMmHdvAWJWrasgCdaP4hMewDT5SYb50vnfwX1RXRf132qXij9TnOpQHXj4opWLAxztnGqYEG6gr+v9Qv/kM2fk1bYj9+RKJCdzMB7ThzE1lH+/ZCOz90/KRVXHzBjsCZPu2blgvygcV4tLqmRyaeRP0rPN3D+h5Jt9mLXi+RPMBotkKJTlbf1GG/Qp1nxAWGVhgWg07Vtbxn7GZ4NP6cF4MYI8i2JK5n1EpPa+ZeA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AM3PR06MB050; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB050; 20:sBbYyyNAXZHfTaxqPWdDG6PjaqfGfRaoNzYdrnmSgxyDe9srD4HEjlwlui38AKuSoB6J+OJEjswWBxBZCryYsS4jeTARKwjhe4O0nFghluGs0l9A6bpxHzTi/bLq0h81wtIdfFzLpR1q3zYr9kQtNVF//mR4sG4xNITru6vGHExr9Sce+CKHi/EHgCXssP6bjhIJj2mLFAxZ1oIh1C2mjxlieLJQ0iiIsvY2rz743RO0JfrL70033KB0tb0PDctAZnRLOZxKUQmgFXS9RQBb5OkB/R0+1gVLXWhAdiIiIy1/gDujs9dyJ9mKm5GmUOUkEPltYe6YDE1G2oe+E9u2tIh1VWFnqvu9EK1XwIO8aXVSwAXGRtO3NBRYlZNm3t42PVXfxRyzp0VmCUOxb65BCVefQr7YDOxiNN9Nvux5bquguPglvcafbhQS3E8dMJ/wSvdUTVsN2hwKCEj7XSwIE2FRCXEiiae7TuVauIONiNwSv1yhmjI+9W/TALH58yQ+; 4:PafApNgZWTnv4tH3L2hAWxSAEMYqYNN/oIj1u+BjSGrSEmLcLOMxi8+EUzhuFkpvjZLj6uFMcGI1VMcNSyYp8fVmqSgVrA7dMULTVjS/bxc95CKxc8ND3rxjbIPArOt94jIpvJrQPC5KmZI2SyCGUAlrz8ezXcBb3eJFIGR8RVkHeLBnTLHJ0p4i6SgZ3SkEaeMeP+vokhklLGlv+Sqvi6drvmSc6NxJ6TYgMwPYsyNQFFYuE0GlpLzcr9BedxxrgAkLg0MynTcKb7AFPjCwM710JOTl7IZd5BH59H4DSQ4REXXewK+mVtl/80XAd7FfbNUzLYxvsfppij77d1GM2u4fLR2lqQL6XiNGt9YEVhyWKAtatozjq9WzTi64kr57WCVyUAo2yzMhiHRMYJDlFF0OHavxc23WJZebYxQBKyyHbgEpcY4ZzELwjh3/N2vE X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(109460225580195); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:AM3PR06MB050; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB050; X-Forefront-PRVS: 07891BF289 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3PR06MB050; 23:tEvzs0Hdfuub+WnRx8xa13qzGAvfjMIiRWiyRggDma?= =?us-ascii?Q?Jv3Rlq0ZG2sg8NjRNucAsHnkJKIxfLIWPcRLMve3fSpb3qZLjOLdf6rRlL0T?= =?us-ascii?Q?gxScWwtjMeVznRtc1y0Gsura5/762oxASEhdTIZQGoauvoYBdjPqflj0YV2A?= =?us-ascii?Q?l3OTXASD3AGUOpjBOU8bye6ZsFs12KWUCBZuc1Z0sbzIyyjUctXsXY7Zj4Na?= =?us-ascii?Q?NPxcPfk8JUi43ZNeJmKTWA3iEku6cEjhe54rvV1ZcLzMR7flmcjRyw9utxbx?= =?us-ascii?Q?munmijNEiiJWj2kjHoF1zPjObRurTV5wkEN2rcZBe/A3AiD2QFAuddi7g4/o?= =?us-ascii?Q?6IxqhRqDESbgzasH9thaNHFBBKvF0z/eRqxcxzkY5NwiBLME2lC1XvJBAR9f?= =?us-ascii?Q?voHm4XLtR1au+lhmOehma55UTp1BG6/YzklIeaF52XInqg5c9C2BNB7rqol2?= =?us-ascii?Q?wYA/o7c+XY5n1UbSW4DQdbtxTJci7/lKgrUfNPucSd8F5gnN1Bl495XAra0o?= =?us-ascii?Q?/326DOuOH2Zi/YzappJToKPMnMoXYLIJkks1JNpJCNpHIm11kF9yKLWTPeko?= =?us-ascii?Q?7Ed8Om8tA5w/TBpgHhBHgQZFY5AhQzGZ3shNRdgpuJKZpO/xMC7vNKkiNEq1?= =?us-ascii?Q?FtkK8n1susmRQPmBnMQNBlKUOHbcl5n+SeH+CODxdba+Zq9LpEyc3kvbtXYu?= =?us-ascii?Q?qaciVh0TDETRCcOA8pGjCrEY8UzGYdlpD7eEYdoAdpR+S63UCAiPu97VBrT0?= =?us-ascii?Q?ta5i+gnzYmKR7rjBhLVvBx9cAK44aqDeISPDnz74qrXWIl+SNH/KaLhCiI9P?= =?us-ascii?Q?XX/doLKnEBYaIfk6QeeHf8btmuvywXZESNdFF71vlFiA7xYKW2KW8k8rdvNh?= =?us-ascii?Q?DjJWp38XN728tatJQRHkgIGn++UQMZ+e16+9fh9DAmvBOtS994wef7rI+xkh?= =?us-ascii?Q?GUTW95QFFBdwOokTIxkyZlq+e9r33Xx6g8A/ByaWrYr5/S1ax4pyX0Uerow9?= =?us-ascii?Q?2A0sqr2qvigbby40dc3NJTcDkBr3TBf8rLK1DYi5NbGBVTog7e4mzQm2ZjLf?= =?us-ascii?Q?QL/3b7mdvHOVDgSjqqHFVopBq8w6VYiV9kwAiH5ZwOX1EY9ZDkNTbKL8KSEU?= =?us-ascii?Q?gIhZitXr5BiBjZKu2D0l2oKlKJFe0A/5zuDN47e4WcRxbjMZDASHkb5TdMut?= =?us-ascii?Q?DwWL7WIj33VtBaF9Nqlle/a1+fgWh4UTa3IB6IOlWRFk4dJrcsJnccs3yGM1?= =?us-ascii?Q?Pt+uwft7nVhvF5FKLUZpImsQ+yxLWehhOOM4LSse8iWesYxMM25E2JAYuyEQ?= =?us-ascii?Q?4FQPYzVEnEkrW7BPZTZuTTMM6ggxNcDlzgbH6JqzyH1WxM9bcSQIuLUUWbfU?= =?us-ascii?Q?FAcQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB050; 5:nzXrGGNdoG0KrLmaHoEVQat8yEALPXIfqfN1wSMNIgUpVQJU6hZAJR6e7iF/rjWblc0UZcVreJ912OY3kxBQ3GUOTTcjGp3XrcQ5xQ61SBHV1Eg618mVOINZpMEDmm3ac8nc5NwABBCECVxPY432YQ==; 24:wLjMjZIhicty+E6aYIywBaPg5Yu1Ysn1OmdUxuzUw1t9OvFOiS5MUcVH3+RhBBOokl04OI5A3sXhjaNPoJM/fYV69eXhRfMab3HwFEN/GKc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2015 07:56:52.3106 (UTC) X-MS-Exchange-CrossTenant-Id: c80d3499-4a40-4a8c-986e-abce017d6b19 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c80d3499-4a40-4a8c-986e-abce017d6b19; Ip=[188.184.36.48]; Helo=[CERNMX12.cern.ch] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB050 Archived-At: Cc: storagesync Subject: Re: [Storagesync] recent issues discussed (html) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 07:57:21 -0000 --_000_41F39F50E49A4C2BBF09B182580008DFcernch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCllvdSBtYXkgYWxzbyBjb25zaWRlciB0byBhZGQgdG8gdGhpcyBsaXN0IHRoaXMg ZGUtZmFjdG8gc3luYyBwcm90b2NvbCBkZXNjcmlwdGlvbiB1c2VkIGJ5IG93bmNsb3VkIHN5bmMg Y2xpZW50cyAoYW5kIHNvbWUgZm9vdG5vdGUgZGlzY3Vzc2lvbiBvbiBmdXR1cmUgZGV2ZWxvcG1l bnQgZGlyZWN0aW9ucyk6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZXJuYm94L3NtYXNoYm94L2Js b2IvbWFzdGVyL3Byb3RvY29sL3Byb3RvY29sLm1kDQoNClRoaXMgZG9jdW1lbnQgY29tZXMgd2l0 aCBhIHRlc3Qgc3VpdGUgKHBhcnRpYWxseSBpbXBsZW1lbnRlZCkgdGhhdCB2ZXJpZmllcyBpZiBh IHNlcnZlciBhZGhlcmVzIHRvIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KQmVzdCByZWdhcmRzLA0K DQprdWJhDQoNCi0tDQoNCg0KT24gMTIgRGVjIDIwMTUsIGF0IDE1OjE2LCBGZWkgU29uZyA8ZnNv bmdAYmp0dS5lZHUuY248bWFpbHRvOmZzb25nQGJqdHUuZWR1LmNuPj4gd3JvdGU6DQoNCkhlcmUg aXMgdGhlIGxhdGVzdCB2ZXJzaW9uLiBQbGVhc2UgZW1haWwgbWUgaWYgYW55dGhpbmcgaXMgbWlz c2VkOg0KDQoxLiAgICAgICAgIFRoZSBkZXNpZ24gdGFyZ2V0cyBvZiBXZWJEQVYsIHJzeW5jIGFu ZCBvdGhlciBleGlzdGluZyBhcHByb2FjaGVzPw0KMi4gICAgICAgICBUaGUgcG90ZW50aWFsIHVz ZSBjYXNlcyBvZiBJU1MsIHN1Y2ggYXMgY2xpZW50L3NlcnZlciwgZ2l0LWxpa2UgcGF0dGVybiwg c3ZuLCBldGMuDQozLiAgICAgICAgIFRoZSBlZmZpY2llbmN5IGltcHJvdmVtZW50cyBtaWdodCBi ZSB0aGUgc2Vjb25kIGdvYWwgZm9yIHN0YW5kYXJkaXppbmcgSVNTIHByb3RvY29sDQo0LiAgICAg ICAgIENPUlMgaGVhZGVycyBvbiBzdG9yYWdlIHN5bmMgQVBJcw0KNS4gICAgICAgICBXaGF0IGlz IG5lZWRlZCBmb3IgdGhlIElTUzogYSBzeW5jIHByb3RvY29sIG9yIGEgZ2VuZXJhbGl6ZWQgQVBJ DQo2LiAgICAgICAgIHJlbW90ZVN0b3JhZ2UgZHJhZnQgZGlzY3Vzc2lvbg0KYSkgICAgICAgICBy ZWxhdGlvbnNoaXAgdnMgV2ViREFWDQpiKSAgICAgICAgIE1PVkUgYWN0aW9uIChzeW5jaHJvbml6 YXRpb24pIHNob3VsZCBiZSBhZGRlZCBvciBub3QNCmMpICAgICAgICAgQmVzaWRlIHdlYiBicm93 c2VyLCBkZXNrdG9wIGFwcHMgKGJ5IGhhY2tpbmcgd2F5KQ0KZCkgICAgICAgICBjb21pY3Mgb2Yg bmV3IHN0YW5kYXJkDQplKSAgICAgICAgIGV0YWcgaXNzdWVzIHZzIG1ldGFkYXRhDQogICAgICAg ICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIGlzIG1haW5seSBmb3IgaWRlbnRpZnlp bmcgd2hldGhlciBhIGRvY3VtZW50IGlzIGNoYW5nZWQgb3Igbm90DQogICAgICAgICAgICAgICAg ICAgICAgIGlpLiAgICAgICAgICAgICAgaXMgZWFzeSB0byBpbXBsZW1lbnQgdGhhbiB0aGF0IG9m IFdlYkRBViBzeW5jIHByb3RvY29sIG9yIG5vdA0KICAgICAgICAgICAgICAgICAgICAgIGlpaS4g ICAgICAgICAgICAgIHRoZSBtZXRhZGF0YSBmaWxlIGNvbnRhaW5zIGFsbCBldGFncyBmb3IgYWxs IGZpbGVzIGF0IGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgc2lkZSBvciBub3QNCmYpICAgICAgICAg IHRoZSBkaXN0cmlidXRlZCBwZWVyIG1vZGVsIChubyBzZXJ2ZXIpIGFuZCBDL1MgbW9kZQ0KZykg ICAgICAgICBhIGZhbmN5IGV4YW1wbGUgKHdpdGggcGljcykgb2YgT2ZmbGluZUlNQVDigJlzIHN5 bmMgcHJvY2VzcyBpbiBmb2xsb3dpbmcgVVJMDQpodHRwOi8vYmxvZy5lenlhbmcuY29tLzIwMTIv MDgvaG93LW9mZmxpbmVpbWFwLXdvcmtzLw0KNy4gICAgICAgICBHaXRIdWIgKGluc3RlYWQgb2Yg ZW1haWwgbWVzc2FnZXMpIGhhcyBiZWVuIGNyZWF0ZWQ6DQpodHRwczovL2dpdGh1Yi5jb20vbGFi a29kZS9JbnRlcm5ldC1TdG9yYWdlLVN5bmMNCmEpICAgICAgICAgV2hhdCBpcyB0aGUgdG9waWM/ DQogICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIFdoZXRoZXIgaXQgaXMg c3VpdGFibGUgdG8gYnVpbGQgb24gV2ViREFWDQogICAgICAgICAgICAgICAgICAgICAgIGlpLiAg ICAgICAgICAgICAgV2ViREFWIHZzIHJlbW90ZVN0b3JhZ2UNCiAgICAgICAgICAgICAgICAgICAg ICBpaWkuICAgICAgICAgICAgICBBZHZhbnRhZ2VzIHZzIGRpc2FkdmFudGFnZXMgb2YgV2ViREFW DQo4LiAgICAgICAgIE1ldGFkYXRhIGFuZCBkYXRhIHNlcGFyYXRpb24gc2NoZW1lIGFuZCBwbGF0 Zm9ybSBmb3Igc3luY2hyb25pemF0aW9uDQphKSAgICAgICAgIG93bkNsb3VkIHdoZW4gY29uZmln dXJlZCB0byB1c2UgYW4gT2JqZWN0IFN0b3JhZ2UgYXMgdGhlIFByaW1hcnkgVXNlciBTdG9yYWdl LiAoTWV0YWRhdGEgaXMgaGFuZGxlZCBieSBhIE15U1FMIGRhdGFiYXNlKQ0KYikgICAgICAgICBD RVJOIEVPUyBTdG9yYWdlIFN5c3RlbS4gKE1ldGFkYXRhIGlzIGhhbmRsZWQgaW4gaGlnaCBwZXJm b3JtYW5jZSBpbi1tZW1vcnkgc3RydWN0dXJlcykuDQpjKSAgICAgICAgIERyb3BCb3guIChBcyBm YXIgYXMgSSBrbm93IGl0IHVzZXMgUzMgYmVoaW5kLiBGb3IgbWV0YWRhdGEgaXQgaXMgdW5rbm93 biwgYnV0IHByb2JhYmx5IG5vdCBvbiBTMykuDQpQYXBlciBmb3IgYW5hbHl6aW5nIERyb3BCb3g6 DQpodHRwOi8vYW5uYXNwZXJvdHRvLm9yZy9wYXBlcnMvMjAxMi9pbWMxNDAtZHJhZ28ucGRmDQpk KSAgICAgICAgIENsYXdJTyB3aWxsIGhhdmUgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcyBhcHBy b2FjaCBpbiB0aGUgbmV4dCBwaGFzZSB1c2luZyBTd2lmdC4NCjkuICAgICAgICAgV2hldGhlciB3 ZSBzaG91bGQga2VlcCBtZXRhZGF0YSBoaXN0b3J5IG9yIG1vZGlmaWNhdGlvbiBoaXN0b3J5IG9y IGFjdGlvbiBoaXN0b3J5IGF0IHNlcnZlciBzaWRlIChvciBvdGhlciBwbGFjZXMpDQoxMC4gICAg IEhvdyB0byBoYW5kbGUgdGhlIOKAnGNvbmZsaWN0IGRpc2NvdmVyeSAocmVzb2x1dGlvbinigJ0g aXNzdWVzDQphKSAgICAgICAgIEEgZ29vZCBkZW1vbnN0cmF0aW9uIG9mIHRoaXMgaXNzdWUgd2Fz IGdpdmVuIGluIGRldGFpbHMgKEZpbGUgRiwgQ2xpZW50IEEsIENsaWVudCBCLCBldGMuKQ0KYikg ICAgICAgICBTaG91bGQgaXQgYmUgYSBsYXllciBhYm92ZSBzeW5jaW5nPw0KYykgICAgICAgICBT aG91bGQgaXQgZGVwZW5kIG9uIHRoZSB1c2UgY2FzZT8NCmQpICAgICAgICAgU2hvdWxkIGl0IGJl IGEgb25lLXNpemUtZml0cy1hbGwgYXBwcm9hY2g/DQplKSAgICAgICAgIEhvdyBtYW55IGRpZmZl cmVudCBraW5kcyBvZiBjb25mbGljdD8NCiAgICAgICAgICAgICAgICAgICAgICAgICBpLiAgICAg ICAgICAgICAgRmlsZSBsZXZlbCBjb25mbGljdHMsIGUuZy4gYm90aCByZW1vdGUgKHNlcnZlcikg YW5kIGxvY2FsIChjbGllbnQpIGhhdmUgY2hhbmdlZCBzaW5jZSBsYXN0IHN5bmMuDQogICAgICAg ICAgICAgICAgICAgICAgIGlpLiAgICAgICAgICAgICAgSW50ZXJsZWF2ZWQgbGV2ZWwgY29uZmxp Y3RzLCBlLmcuIG9uZSBjbGllbnQgbWFrZXMgYSBjaGFuZ2UgYmFzZWQgb24gdmVyc2lvbiBYIG9m IHRoZSBmaWxlLCBhIHNlY29uZCBtYWtlcyBhIGNoYW5nZSBiYXNlZCBvbiB2ZXJzaW9uIFgrMSwg dGhlIHNlY29uZCBvbmUgY29tbWl0cywgYW5kIHRoZW4gdGhlIGZpcnN0IG9uZSBjb21taXRzLg0K ICAgICAgICAgICAgICAgICAgICAgIGlpaS4gICAgICAgICAgICAgIOKApg0KZikgICAgICAgICAg VGhlIHNlcXVlbmNlIChvcmRlcikgb2YgY2hhbmdlcyBpbiBvbmUgZmlsZSBpcyBpbXBvcnRhbnQg b3Igbm90IChxdWl0ZSBzaW1pbGFyIHdpdGgg4oCcaXRlbSA54oCdIGluIHRoaXMgbGlzdCksIHBl cmhhcHMgZGVwZW5kcyBvbiB0aGUgZmlsZSB0eXBlIChvciB1c2UgY2FzZXMpOg0KICAgICAgICAg ICAgICAgICAgICAgICAgIGkuICAgICAgICAgICAgICBJdCBtYXkgYmUgaW1wb3J0YW50IGZvcjog c291bmQgZmlsZSwgZHJhd2luZyBmaWxlLCBsYXRleCBzb3VyY2UgZmlsZXMgb2YgYXJ0aWNsZXMs IGlXb3JrIGZpbGVzLCBPZmZpY2UgZmlsZXMsIGltYWdlcywgcGRmcywgc291cmNlIGNvZGUsIGV0 Yy4NCiAgICAgICAgICAgICAgICAgICAgICAgaWkuICAgICAgICAgICAgICBJdCBtYXkgYmUgbm90 IGltcG9ydGFudCBmb3I6IFBoeXNpY3MgZGF0YS4NCmcpICAgICAgICAgV2hldGhlciB0byBlbmFi bGUgYW4gYXV0b21hdGljIG1lcmdpbmcgbWlnaHQgYmUgYSByZXNlYXJjaCBwcm9ibGVtIG9yIGEg ZnVydGhlciB1c2UgY2FzZT8NCmgpICAgICAgICAgSWYgSXQgaXMgc28gaGFyZCB0byBkbyBjb25m bGljdCByZXNvbHV0aW9uIGV2ZW4gZm9yIHNpbXBsZSBhbmQgd2VsbC1zdHJ1Y3R1cmVkIOKAnHZj YXJkIGNhc2XigJ0sIHNob3VsZCB3ZSBoYW5kbGUgdGhpcyBpc3N1ZSBieSBzZXBhcmF0aW5nIGZp bGVzIGJhc2VkIG9uIHRoZWlyIHByb3BlcnR5Pw0KDQpTb21lIHJlbGF0ZWQgb3JnYW5pemF0aW9u cywgZXZlbnRzLCBwcm9qZWN0cywgZXRjLjoNCkdFQU5UIGNvbW11bml0eSwgT3BlbkNsb3VkTWVz aCwgb3duQ2xvdWQsIENTMywgcmVtb3RlU3RvcmFnZSwgQ2xhd0lPLCBjcm9zc2Nsb3VkLCBEcm9w Ym94LCBDRVJOIEVPUyBTdG9yYWdlIFN5c3RlbSx0byBiZSBhZGRlZOKApg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClN0b3JhZ2VzeW5jIG1haWxpbmcg bGlzdA0KU3RvcmFnZXN5bmNAaWV0Zi5vcmc8bWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KDQo= --_000_41F39F50E49A4C2BBF09B182580008DFcernch_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Zb3UgbWF5IGFsc28gY29uc2lk ZXIgdG8gYWRkIHRvIHRoaXMgbGlzdCB0aGlzIGRlLWZhY3RvIHN5bmMgcHJvdG9jb2wgZGVzY3Jp cHRpb24gdXNlZCBieSBvd25jbG91ZCBzeW5jIGNsaWVudHMgKGFuZCBzb21lIGZvb3Rub3RlIGRp c2N1c3Npb24gb24gZnV0dXJlIGRldmVsb3BtZW50IGRpcmVjdGlvbnMpOjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL2Nlcm5ib3gvc21hc2hib3gvYmxvYi9tYXN0ZXIvcHJvdG9jb2wvcHJv dG9jb2wubWQiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9jZXJuYm94L3NtYXNoYm94L2Js b2IvbWFzdGVyL3Byb3RvY29sL3Byb3RvY29sLm1kPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBkb2N1bWVudCBjb21lcyB3 aXRoIGEgdGVzdCBzdWl0ZSAocGFydGlhbGx5IGltcGxlbWVudGVkKSB0aGF0IHZlcmlmaWVzIGlm IGEgc2VydmVyIGFkaGVyZXMgdG8gdGhpcyBzcGVjaWZpY2F0aW9uLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmVzdCByZWdhcmRzLDwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ a3ViYTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+LS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTIgRGVjIDIwMTUsIGF0IDE1OjE2LCBGZWkgU29u ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZzb25nQGJqdHUuZWR1LmNuIiBjbGFzcz0iIj5mc29uZ0Bi anR1LmVkdS5jbjwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog 5a6L5L2TOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiAyMHB4OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsiIGNsYXNz PSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxp YnJpIiBjbGFzcz0iIj5IZXJlIGlzIHRoZSBsYXRlc3QgdmVyc2lvbi4gUGxlYXNlIGVtYWlsIG1l IGlmIGFueXRoaW5nIGlzIG1pc3NlZDo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDBwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0i Ij48bzpwIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPiZu YnNwOzwvZm9udD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMHB0IDIxcHQ7IHRleHQtaW5kZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVO LVVTIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJp IiBjbGFzcz0iIj4xLjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNz PSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFu Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i Q2FsaWJyaSIgY2xhc3M9IiI+VGhlDQogZGVzaWduIHRhcmdldHMgb2YgV2ViREFWLCByc3luYyBh bmQgb3RoZXIgZXhpc3RpbmcgYXBwcm9hY2hlcz88L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCAyMXB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFz cz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+Mi48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxm b250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPlRoZQ0KIHBvdGVudGlhbCB1c2Ug Y2FzZXMgb2YgSVNTLCBzdWNoIGFzIGNsaWVudC9zZXJ2ZXIsIGdpdC1saWtlIHBhdHRlcm4sIHN2 biwgZXRjLjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MHB0IDIxcHQ7IHRleHQtaW5kZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVT IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBj bGFzcz0iIj4zLjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2Fs aWJyaSIgY2xhc3M9IiI+VGhlDQogZWZmaWNpZW5jeSBpbXByb3ZlbWVudHMgbWlnaHQgYmUgdGhl IHNlY29uZCBnb2FsIGZvciBzdGFuZGFyZGl6aW5nIElTUyBwcm90b2NvbDwvZm9udD48L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0IDIxcHQ7IHRleHQtaW5kZW50 OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48c3BhbiBjbGFz cz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj40LjwvZm9udD48c3Bh biBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+Q09SUw0K IGhlYWRlcnMgb24gc3RvcmFnZSBzeW5jIEFQSXM8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCAyMXB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFz cz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+NS48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxm b250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPldoYXQNCiBpcyBuZWVkZWQgZm9y IHRoZSBJU1M6IGEgc3luYyBwcm90b2NvbCBvciBhIGdlbmVyYWxpemVkIEFQSTwvZm9udD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0IDIxcHQ7IHRleHQtaW5k ZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48c3BhbiBj bGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj42LjwvZm9udD48 c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+cmVt b3RlU3RvcmFnZQ0KIGRyYWZ0IGRpc2N1c3Npb248L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCA0MnB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFz cz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+YSk8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxm b250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPnJlbGF0aW9uc2hpcA0KIHZzIFdl YkRBVjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0 IDQycHQ7IHRleHQtaW5kZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBj bGFzcz0iIj48c3BhbiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFz cz0iIj5iKTwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJy aSIgY2xhc3M9IiI+TU9WRQ0KIGFjdGlvbiAoc3luY2hyb25pemF0aW9uKSBzaG91bGQgYmUgYWRk ZWQgb3Igbm90PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwcHQgNDJwdDsgdGV4dC1pbmRlbnQ6IC0yMXB0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4t VVMiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmki IGNsYXNzPSIiPmMpPC9mb250PjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9 IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJD YWxpYnJpIiBjbGFzcz0iIj5CZXNpZGUNCiB3ZWIgYnJvd3NlciwgZGVza3RvcCBhcHBzIChieSBo YWNraW5nIHdheSk8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDBwdCA0MnB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFzcz0iIj48c3BhbiBsYW5nPSJF Ti1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJy aSIgY2xhc3M9IiI+ZCk8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFz cz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9 IkNhbGlicmkiIGNsYXNzPSIiPmNvbWljcw0KIG9mIG5ldyBzdGFuZGFyZDwvZm9udD48L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0IDQycHQ7IHRleHQtaW5kZW50 OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48c3BhbiBjbGFz cz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj5lKTwvZm9udD48c3Bh biBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+ZXRhZw0K IGlzc3VlcyB2cyBtZXRhZGF0YTwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMHB0IDYzcHQ7IHRleHQtaW5kZW50OiAtNjNwdDsiIGNsYXNzPSIiPjxzcGFu IGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg Zm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+aS48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGli cmkiIGNsYXNzPSIiPmlzDQogbWFpbmx5IGZvciBpZGVudGlmeWluZyB3aGV0aGVyIGEgZG9jdW1l bnQgaXMgY2hhbmdlZCBvciBub3Q8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDBwdCA2M3B0OyB0ZXh0LWluZGVudDogLTYzcHQ7IiBjbGFzcz0iIj48c3Bh biBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxmb250IHNpemU9IjMiIGZh Y2U9IkNhbGlicmkiIGNsYXNzPSIiPmlpLjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1z aXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9 IiI+aXMNCiBlYXN5IHRvIGltcGxlbWVudCB0aGFuIHRoYXQgb2YgV2ViREFWIHN5bmMgcHJvdG9j b2wgb3Igbm90PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwcHQgNjNwdDsgdGV4dC1pbmRlbnQ6IC02M3B0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4t VVMiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6 IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFz cz0iIj5paWkuPC9mb250PjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFz cz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj50aGUNCiBtZXRhZGF0 YSBmaWxlIGNvbnRhaW5zIGFsbCBldGFncyBmb3IgYWxsIGZpbGVzIGF0IGJvdGggY2xpZW50IGFu ZCBzZXJ2ZXIgc2lkZSBvciBub3Q8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDBwdCA0MnB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFzcz0iIj48c3Bh biBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iQ2FsaWJyaSIgY2xhc3M9IiI+Zik8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6 ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250 IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPnRoZQ0KIGRpc3RyaWJ1dGVkIHBlZXIg bW9kZWwgKG5vIHNlcnZlcikgYW5kIEMvUyBtb2RlPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQgNDJwdDsgdGV4dC1pbmRlbnQ6IC0yMXB0OyIgY2xh c3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxmb250IHNp emU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPmcpPC9mb250PjxzcGFuIHN0eWxlPSJmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj5hDQogZmFuY3kgZXhhbXBsZSAo d2l0aCBwaWNzKSBvZiBPZmZsaW5lSU1BUOKAmXMgc3luYyBwcm9jZXNzIGluIGZvbGxvd2luZyBV Ukw8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCA0 MnB0OyB0ZXh0LWluZGVudDogMGNtOyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNz PSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6 Ly9ibG9nLmV6eWFuZy5jb20vMjAxMi8wOC9ob3ctb2ZmbGluZWltYXAtd29ya3MvIiBjbGFzcz0i Ij5odHRwOi8vYmxvZy5lenlhbmcuY29tLzIwMTIvMDgvaG93LW9mZmxpbmVpbWFwLXdvcmtzLzwv YT48L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCAy MXB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xh c3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9 IiI+Ny48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdo dDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmki IGNsYXNzPSIiPkdpdEh1Yg0KIChpbnN0ZWFkIG9mIGVtYWlsIG1lc3NhZ2VzKSBoYXMgYmVlbiBj cmVhdGVkOjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MHB0IDIxcHQ7IHRleHQtaW5kZW50OiAwY207IiBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIg Y2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2xhYmtvZGUvSW50ZXJuZXQtU3Rv cmFnZS1TeW5jIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHdpbmRvd3RleHQ7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmki IGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9sYWJrb2RlL0ludGVybmV0LVN0b3JhZ2UtU3lu YzwvZm9udD48L3NwYW4+PC9hPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwcHQgNDJwdDsgdGV4dC1pbmRlbnQ6IC0yMXB0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0i RU4tVVMiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGli cmkiIGNsYXNzPSIiPmEpPC9mb250PjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNl PSJDYWxpYnJpIiBjbGFzcz0iIj5XaGF0DQogaXMgdGhlIHRvcGljPzxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCA2M3B0OyB0ZXh0LWluZGVudDogLTYzcHQ7IiBj bGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPmkuPC9mb250Pjxz cGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48Zm9udCBzaXplPSIz IiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj5XaGV0aGVyDQogaXQgaXMgc3VpdGFibGUgdG8gYnVp bGQgb24gV2ViREFWPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwcHQgNjNwdDsgdGV4dC1pbmRlbnQ6IC02M3B0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0i RU4tVVMiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNp emU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxp YnJpIiBjbGFzcz0iIj5paS48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0 OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBj bGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPldlYkRB Vg0KIHZzIHJlbW90ZVN0b3JhZ2U8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDBwdCA2M3B0OyB0ZXh0LWluZGVudDogLTYzcHQ7IiBjbGFzcz0iIj48c3Bh biBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxmb250IHNpemU9IjMiIGZhY2U9IkNh bGlicmkiIGNsYXNzPSIiPmlpaS48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTog N3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7 IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPkFk dmFudGFnZXMNCiB2cyBkaXNhZHZhbnRhZ2VzIG9mIFdlYkRBVjwvZm9udD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0IDIxcHQ7IHRleHQtaW5kZW50OiAtMjFw dDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj44LjwvZm9udD48c3BhbiBzdHls ZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xh c3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+TWV0YWRhdGENCiBh bmQgZGF0YSBzZXBhcmF0aW9uIHNjaGVtZSBhbmQgcGxhdGZvcm0gZm9yIHN5bmNocm9uaXphdGlv bjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0IDQy cHQ7IHRleHQtaW5kZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0i Ij5hKTwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIg Y2xhc3M9IiI+b3duQ2xvdWQNCiB3aGVuIGNvbmZpZ3VyZWQgdG8gdXNlIGFuIE9iamVjdCBTdG9y YWdlIGFzIHRoZSBQcmltYXJ5IFVzZXIgU3RvcmFnZS4gKE1ldGFkYXRhIGlzIGhhbmRsZWQgYnkg YSBNeVNRTCBkYXRhYmFzZSk8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDBwdCA0MnB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFzcz0iIj48c3BhbiBs YW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i Q2FsaWJyaSIgY2xhc3M9IiI+Yik8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTog N3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7 IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9IjMi IGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPkNFUk4NCiBFT1MgU3RvcmFnZSBTeXN0ZW0uIChNZXRh ZGF0YSBpcyBoYW5kbGVkIGluIGhpZ2ggcGVyZm9ybWFuY2UgaW4tbWVtb3J5IHN0cnVjdHVyZXMp LjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0IDQy cHQ7IHRleHQtaW5kZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0i Ij5jKTwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIg Y2xhc3M9IiI+RHJvcEJveC4NCiAoQXMgZmFyIGFzIEkga25vdyBpdCB1c2VzIFMzIGJlaGluZC4g Rm9yIG1ldGFkYXRhIGl0IGlzIHVua25vd24sIGJ1dCBwcm9iYWJseSBub3Qgb24gUzMpLjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCA0MnB0OyB0ZXh0LWluZGVu dDogMGNtOyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9 IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPlBhcGVyIGZvciBhbmFseXppbmcgRHJvcEJveDo8 L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCA0MnB0 OyB0ZXh0LWluZGVudDogMGNtOyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIi PjxhIGhyZWY9Imh0dHA6Ly9hbm5hc3Blcm90dG8ub3JnL3BhcGVycy8yMDEyL2ltYzE0MC1kcmFn by5wZGYiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogd2luZG93dGV4dDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xh c3M9IiI+aHR0cDovL2FubmFzcGVyb3R0by5vcmcvcGFwZXJzLzIwMTIvaW1jMTQwLWRyYWdvLnBk ZjwvZm9udD48L3NwYW4+PC9hPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwcHQgNDJwdDsgdGV4dC1pbmRlbnQ6IC0yMXB0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0i RU4tVVMiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGli cmkiIGNsYXNzPSIiPmQpPC9mb250PjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNl PSJDYWxpYnJpIiBjbGFzcz0iIj5DbGF3SU8NCiB3aWxsIGhhdmUgYW4gaW1wbGVtZW50YXRpb24g b2YgdGhpcyBhcHByb2FjaCBpbiB0aGUgbmV4dCBwaGFzZSB1c2luZyBTd2lmdC48L2ZvbnQ+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCAyMXB0OyB0ZXh0LWlu ZGVudDogLTIxcHQ7IiBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4g Y2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+OS48L2ZvbnQ+ PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPldo ZXRoZXINCiB3ZSBzaG91bGQga2VlcCBtZXRhZGF0YSBoaXN0b3J5IG9yIG1vZGlmaWNhdGlvbiBo aXN0b3J5IG9yIGFjdGlvbiBoaXN0b3J5IGF0IHNlcnZlciBzaWRlIChvciBvdGhlciBwbGFjZXMp PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQgMjFw dDsgdGV4dC1pbmRlbnQ6IC0yMXB0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNz PSIiPjxzcGFuIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIi PjEwLjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9 IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+SG93DQogdG8gaGFuZGxl IHRoZSDigJxjb25mbGljdCBkaXNjb3ZlcnkgKHJlc29sdXRpb24p4oCdIGlzc3VlczwvZm9udD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0IDQycHQ7IHRleHQt aW5kZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48c3Bh biBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj5hKTwvZm9u dD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+ QQ0KIGdvb2QgZGVtb25zdHJhdGlvbiBvZiB0aGlzIGlzc3VlIHdhcyBnaXZlbiBpbiBkZXRhaWxz IChGaWxlIEYsIENsaWVudCBBLCBDbGllbnQgQiwgZXRjLik8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCA0MnB0OyB0ZXh0LWluZGVudDogLTIxcHQ7 IiBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+Yik8L2ZvbnQ+PHNwYW4gc3R5bGU9 ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNz PSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPlNob3VsZA0KIGl0IGJl IGEgbGF5ZXIgYWJvdmUgc3luY2luZz88L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDBwdCA0MnB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFzcz0iIj48 c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+Yyk8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQt c2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250IHNp emU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPlNob3VsZA0KIGl0IGRlcGVuZCBvbiB0aGUg dXNlIGNhc2U/PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwcHQgNDJwdDsgdGV4dC1pbmRlbnQ6IC0yMXB0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4t VVMiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmki IGNsYXNzPSIiPmQpPC9mb250PjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9 IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJD YWxpYnJpIiBjbGFzcz0iIj5TaG91bGQNCiBpdCBiZSBhIG9uZS1zaXplLWZpdHMtYWxsIGFwcHJv YWNoPzwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0 IDQycHQ7IHRleHQtaW5kZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBj bGFzcz0iIj48c3BhbiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFz cz0iIj5lKTwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJy aSIgY2xhc3M9IiI+SG93DQogbWFueSBkaWZmZXJlbnQga2luZHMgb2YgY29uZmxpY3Q/PC9mb250 Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQgNjNwdDsgdGV4 dC1pbmRlbnQ6IC02M3B0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxz cGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBj bGFzcz0iIj5pLjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xh c3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+RmlsZQ0KIGxldmVs IGNvbmZsaWN0cywgZS5nLiBib3RoIHJlbW90ZSAoc2VydmVyKSBhbmQgbG9jYWwgKGNsaWVudCkg aGF2ZSBjaGFuZ2VkIHNpbmNlIGxhc3Qgc3luYy48L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCA2M3B0OyB0ZXh0LWluZGVudDogLTYzcHQ7IiBjbGFz cz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxmb250IHNp emU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPmlpLjwvZm9udD48c3BhbiBzdHlsZT0iZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJy aSIgY2xhc3M9IiI+SW50ZXJsZWF2ZWQNCiBsZXZlbCBjb25mbGljdHMsIGUuZy4gb25lIGNsaWVu dCBtYWtlcyBhIGNoYW5nZSBiYXNlZCBvbiB2ZXJzaW9uIFggb2YgdGhlIGZpbGUsIGEgc2Vjb25k IG1ha2VzIGEgY2hhbmdlIGJhc2VkIG9uIHZlcnNpb24gWCYjNDM7MSwgdGhlIHNlY29uZCBvbmUg Y29tbWl0cywgYW5kIHRoZW4gdGhlIGZpcnN0IG9uZSBjb21taXRzLjwvZm9udD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0IDYzcHQ7IHRleHQtaW5kZW50OiAt NjNwdDsiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+aWlpLjwvZm9udD48c3BhbiBzdHls ZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kzsiIGNsYXNzPSIiPjxmb250 IHNpemU9IjMiIGNsYXNzPSIiPuKApjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMHB0IDQycHQ7IHRleHQtaW5kZW50OiAtMjFwdDsiIGNsYXNzPSIiPjxz cGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBm YWNlPSJDYWxpYnJpIiBjbGFzcz0iIj5mKTwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1z aXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+VGhlDQogc2VxdWVuY2UgKG9yZGVy KSBvZiBjaGFuZ2VzIGluIG9uZSBmaWxlIGlzIGltcG9ydGFudCBvciBub3QgKHF1aXRlIHNpbWls YXIgd2l0aCDigJxpdGVtIDnigJ0gaW4gdGhpcyBsaXN0KSwgcGVyaGFwcyBkZXBlbmRzIG9uIHRo ZSBmaWxlIHR5cGUgKG9yIHVzZSBjYXNlcyk6PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQgNjNwdDsgdGV4dC1pbmRlbnQ6IC02M3B0OyIgY2xhc3M9 IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj5pLjwvZm9udD48c3BhbiBz dHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iQ2FsaWJyaSIgY2xhc3M9IiI+SXQNCiBtYXkgYmUgaW1wb3J0YW50IGZvcjogc291bmQgZmls ZSwgZHJhd2luZyBmaWxlLCBsYXRleCBzb3VyY2UgZmlsZXMgb2YgYXJ0aWNsZXMsIGlXb3JrIGZp bGVzLCBPZmZpY2UgZmlsZXMsIGltYWdlcywgcGRmcywgc291cmNlIGNvZGUsIGV0Yy48L2ZvbnQ+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdCA2M3B0OyB0ZXh0 LWluZGVudDogLTYzcHQ7IiBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNw YW4gY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdo dDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPmlpLjwv Zm9udD48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+SXQNCiBtYXkgYmUgbm90IGltcG9ydGFu dCBmb3I6IFBoeXNpY3MgZGF0YS48L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDBwdCA0MnB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFzcz0iIj48c3Bh biBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iQ2FsaWJyaSIgY2xhc3M9IiI+Zyk8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6 ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9 IjMiIGZhY2U9IkNhbGlicmkiIGNsYXNzPSIiPldoZXRoZXINCiB0byBlbmFibGUgYW4gYXV0b21h dGljIG1lcmdpbmcgbWlnaHQgYmUgYSByZXNlYXJjaCBwcm9ibGVtIG9yIGEgZnVydGhlciB1c2Ug Y2FzZT88L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBw dCA0MnB0OyB0ZXh0LWluZGVudDogLTIxcHQ7IiBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xh c3M9IiI+aCk8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhl aWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGli cmkiIGNsYXNzPSIiPklmDQogSXQgaXMgc28gaGFyZCB0byBkbyBjb25mbGljdCByZXNvbHV0aW9u IGV2ZW4gZm9yIHNpbXBsZSBhbmQgd2VsbC1zdHJ1Y3R1cmVkIOKAnHZjYXJkIGNhc2XigJ0sIHNo b3VsZCB3ZSBoYW5kbGUgdGhpcyBpc3N1ZSBieSBzZXBhcmF0aW5nIGZpbGVzIGJhc2VkIG9uIHRo ZWlyIHByb3BlcnR5PzwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMHB0OyIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSIgY2xhc3M9IiI+Jm5ic3A7PC9mb250 PjwvbzpwPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIiBjbGFzcz0iIj4mbmJzcDs8L2ZvbnQ+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsiIGNsYXNzPSIi PjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJp IiBjbGFzcz0iIj5Tb21lIHJlbGF0ZWQgb3JnYW5pemF0aW9ucywgZXZlbnRzLCBwcm9qZWN0cywg ZXRjLjo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9m b250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IiBjbGFz cz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2Fs aWJyaSIgY2xhc3M9IiI+R0VBTlQgY29tbXVuaXR5LCBPcGVuQ2xvdWRNZXNoLCBvd25DbG91ZCwg Q1MzLCByZW1vdGVTdG9yYWdlLCBDbGF3SU8sIGNyb3NzY2xvdWQsIERyb3Bib3gsIENFUk4gRU9T IFN0b3JhZ2UgU3lzdGVtLHRvIGJlIGFkZGVk4oCmPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTNweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IDIwcHg7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTog aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZM7 IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IDIwcHg7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAx M3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogMjBweDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlN0b3JhZ2VzeW5jDQogbWFpbGlu ZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAx M3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogMjBweDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiDl rovkvZM7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IDIwcHg7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+U3RvcmFnZXN5bmNAaWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250LWZh bWlseTog5a6L5L2TOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiAyMHB4OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZM7IGZv bnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IDIwcHg7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYzwv YT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_41F39F50E49A4C2BBF09B182580008DFcernch_-- From nobody Sun Dec 13 17:49:41 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABA31A9041 for ; Sun, 13 Dec 2015 17:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZMiCNCvQEFS for ; Sun, 13 Dec 2015 17:49:36 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 35CE51A903F for ; Sun, 13 Dec 2015 17:49:33 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygCnLTnbIG5WPekFAA--.20050S2; Mon, 14 Dec 2015 09:52:27 +0800 (CST) Date: Mon, 14 Dec 2015 09:50:16 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121409501521844540@bjtu.edu.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart268517077240_=----" X-CM-TRANSID: M55wygCnLTnbIG5WPekFAA--.20050S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWr47AFWrXFykuw4UXF48Crg_yoWrGF1fpF WfGwsxKa4kJ3yav3ykXr4xurWrtFs3Kw43JFn3Gw4xAws8XFy0gF4xtr4rur97Jry7Z34q qr4Yvas8Cw1DZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUdab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2 x7xS6r1j6r4UMc02F40E57IF67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F4 0E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAF wI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0x vY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc2xSY4AK 67AK6w4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67 AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIY rxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14 v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2Kf nxnUUI43ZEXa7IU5-SdPUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed (html) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 01:49:39 -0000 This is a multi-part message in MIME format. ------=_001_NextPart268517077240_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24uIFBsZWFzZSBlbWFpbCBtZSBpZiBhbnl0aGluZyBp cyBtaXNzZWQ6DQogDQoxLiAgICAgICAgIFRoZSBkZXNpZ24gdGFyZ2V0cyBvZiBXZWJEQVYsIHJz eW5jIGFuZCBvdGhlciBleGlzdGluZyBhcHByb2FjaGVzPw0KMi4gICAgICAgICBUaGUgcG90ZW50 aWFsIHVzZSBjYXNlcyBvZiBJU1MsIHN1Y2ggYXMgY2xpZW50L3NlcnZlciwgZ2l0LWxpa2UgcGF0 dGVybiwgc3ZuLCBldGMuDQozLiAgICAgICAgIFRoZSBlZmZpY2llbmN5IGltcHJvdmVtZW50cyBt aWdodCBiZSB0aGUgc2Vjb25kIGdvYWwgZm9yIHN0YW5kYXJkaXppbmcgSVNTIHByb3RvY29sDQo0 LiAgICAgICAgIENPUlMgaGVhZGVycyBvbiBzdG9yYWdlIHN5bmMgQVBJcw0KNS4gICAgICAgICBX aGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzogYSBzeW5jIHByb3RvY29sIG9yIGEgZ2VuZXJhbGl6 ZWQgQVBJDQo2LiAgICAgICAgIHJlbW90ZVN0b3JhZ2UgZHJhZnQgZGlzY3Vzc2lvbg0KYSkgICAg ICAgICByZWxhdGlvbnNoaXAgdnMgV2ViREFWDQpiKSAgICAgICAgIE1PVkUgYWN0aW9uIChzeW5j aHJvbml6YXRpb24pIHNob3VsZCBiZSBhZGRlZCBvciBub3QNCmMpICAgICAgICAgQmVzaWRlIHdl YiBicm93c2VyLCBkZXNrdG9wIGFwcHMgKGJ5IGhhY2tpbmcgd2F5KQ0KZCkgICAgICAgICBjb21p Y3Mgb2YgbmV3IHN0YW5kYXJkDQplKSAgICAgICAgIGV0YWcgaXNzdWVzIHZzIG1ldGFkYXRhDQog ICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIGlzIG1haW5seSBmb3IgaWRl bnRpZnlpbmcgd2hldGhlciBhIGRvY3VtZW50IGlzIGNoYW5nZWQgb3Igbm90DQogICAgICAgICAg ICAgICAgICAgICAgIGlpLiAgICAgICAgICAgICAgaXMgZWFzeSB0byBpbXBsZW1lbnQgdGhhbiB0 aGF0IG9mIFdlYkRBViBzeW5jIHByb3RvY29sIG9yIG5vdA0KICAgICAgICAgICAgICAgICAgICAg IGlpaS4gICAgICAgICAgICAgIHRoZSBtZXRhZGF0YSBmaWxlIGNvbnRhaW5zIGFsbCBldGFncyBm b3IgYWxsIGZpbGVzIGF0IGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgc2lkZSBvciBub3QNCmYpICAg ICAgICAgIHRoZSBkaXN0cmlidXRlZCBwZWVyIG1vZGVsIChubyBzZXJ2ZXIpIGFuZCBDL1MgbW9k ZQ0KZykgICAgICAgICBhIGZhbmN5IGV4YW1wbGUgKHdpdGggcGljcykgb2YgT2ZmbGluZUlNQVCh r3Mgc3luYyBwcm9jZXNzIGluIGZvbGxvd2luZyBVUkwNCmh0dHA6Ly9ibG9nLmV6eWFuZy5jb20v MjAxMi8wOC9ob3ctb2ZmbGluZWltYXAtd29ya3MvDQo3LiAgICAgICAgIEdpdEh1YiAoaW5zdGVh ZCBvZiBlbWFpbCBtZXNzYWdlcykgaGFzIGJlZW4gY3JlYXRlZDoNCmh0dHBzOi8vZ2l0aHViLmNv bS9sYWJrb2RlL0ludGVybmV0LVN0b3JhZ2UtU3luYw0KYSkgICAgICAgICBXaGF0IGlzIHRoZSB0 b3BpYz8gDQogICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIFdoZXRoZXIg aXQgaXMgc3VpdGFibGUgdG8gYnVpbGQgb24gV2ViREFWDQogICAgICAgICAgICAgICAgICAgICAg IGlpLiAgICAgICAgICAgICAgV2ViREFWIHZzIHJlbW90ZVN0b3JhZ2UNCiAgICAgICAgICAgICAg ICAgICAgICBpaWkuICAgICAgICAgICAgICBBZHZhbnRhZ2VzIHZzIGRpc2FkdmFudGFnZXMgb2Yg V2ViREFWDQo4LiAgICAgICAgIE1ldGFkYXRhIGFuZCBkYXRhIHNlcGFyYXRpb24gc2NoZW1lIGFu ZCBwbGF0Zm9ybSBmb3Igc3luY2hyb25pemF0aW9uDQphKSAgICAgICAgIG93bkNsb3VkIHdoZW4g Y29uZmlndXJlZCB0byB1c2UgYW4gT2JqZWN0IFN0b3JhZ2UgYXMgdGhlIFByaW1hcnkgVXNlciBT dG9yYWdlLiAoTWV0YWRhdGEgaXMgaGFuZGxlZCBieSBhIE15U1FMIGRhdGFiYXNlKQ0KYikgICAg ICAgICBDRVJOIEVPUyBTdG9yYWdlIFN5c3RlbS4gKE1ldGFkYXRhIGlzIGhhbmRsZWQgaW4gaGln aCBwZXJmb3JtYW5jZSBpbi1tZW1vcnkgc3RydWN0dXJlcykuDQpjKSAgICAgICAgIERyb3BCb3gu IChBcyBmYXIgYXMgSSBrbm93IGl0IHVzZXMgUzMgYmVoaW5kLiBGb3IgbWV0YWRhdGEgaXQgaXMg dW5rbm93biwgYnV0IHByb2JhYmx5IG5vdCBvbiBTMykuIA0KUGFwZXIgZm9yIGFuYWx5emluZyBE cm9wQm94Og0KaHR0cDovL2FubmFzcGVyb3R0by5vcmcvcGFwZXJzLzIwMTIvaW1jMTQwLWRyYWdv LnBkZg0KZCkgICAgICAgICBDbGF3SU8gd2lsbCBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIHRo aXMgYXBwcm9hY2ggaW4gdGhlIG5leHQgcGhhc2UgdXNpbmcgU3dpZnQuDQo5LiAgICAgICAgIFdo ZXRoZXIgd2Ugc2hvdWxkIGtlZXAgbWV0YWRhdGEgaGlzdG9yeSBvciBtb2RpZmljYXRpb24gaGlz dG9yeSBvciBhY3Rpb24gaGlzdG9yeSBhdCBzZXJ2ZXIgc2lkZSAob3Igb3RoZXIgcGxhY2VzKQ0K MTAuICAgICBIb3cgdG8gaGFuZGxlIHRoZSChsGNvbmZsaWN0IGRpc2NvdmVyeSAocmVzb2x1dGlv bimhsSBpc3N1ZXMNCmEpICAgICAgICAgQSBnb29kIGRlbW9uc3RyYXRpb24gb2YgdGhpcyBpc3N1 ZSB3YXMgZ2l2ZW4gaW4gZGV0YWlscyAoRmlsZSBGLCBDbGllbnQgQSwgQ2xpZW50IEIsIGV0Yy4p DQpiKSAgICAgICAgIFNob3VsZCBpdCBiZSBhIGxheWVyIGFib3ZlIHN5bmNpbmc/DQpjKSAgICAg ICAgIFNob3VsZCBpdCBkZXBlbmQgb24gdGhlIHVzZSBjYXNlPw0KZCkgICAgICAgICBTaG91bGQg aXQgYmUgYSBvbmUtc2l6ZS1maXRzLWFsbCBhcHByb2FjaD8NCmUpICAgICAgICAgSG93IG1hbnkg ZGlmZmVyZW50IGtpbmRzIG9mIGNvbmZsaWN0Pw0KICAgICAgICAgICAgICAgICAgICAgICAgIGku ICAgICAgICAgICAgICBGaWxlIGxldmVsIGNvbmZsaWN0cywgZS5nLiBib3RoIHJlbW90ZSAoc2Vy dmVyKSBhbmQgbG9jYWwgKGNsaWVudCkgaGF2ZSBjaGFuZ2VkIHNpbmNlIGxhc3Qgc3luYy4NCiAg ICAgICAgICAgICAgICAgICAgICAgaWkuICAgICAgICAgICAgICBJbnRlcmxlYXZlZCBsZXZlbCBj b25mbGljdHMsIGUuZy4gb25lIGNsaWVudCBtYWtlcyBhIGNoYW5nZSBiYXNlZCBvbiB2ZXJzaW9u IFggb2YgdGhlIGZpbGUsIGEgc2Vjb25kIG1ha2VzIGEgY2hhbmdlIGJhc2VkIG9uIHZlcnNpb24g WCsxLCB0aGUgc2Vjb25kIG9uZSBjb21taXRzLCBhbmQgdGhlbiB0aGUgZmlyc3Qgb25lIGNvbW1p dHMuDQogICAgICAgICAgICAgICAgICAgICAgaWlpLiAgICAgICAgICAgICAgoa0NCmYpICAgICAg ICAgIFRoZSBzZXF1ZW5jZSAob3JkZXIpIG9mIGNoYW5nZXMgaW4gb25lIGZpbGUgaXMgaW1wb3J0 YW50IG9yIG5vdCAocXVpdGUgc2ltaWxhciB3aXRoIKGwaXRlbSA5obEgaW4gdGhpcyBsaXN0KSwg cGVyaGFwcyBkZXBlbmRzIG9uIHRoZSBmaWxlIHR5cGUgKG9yIHVzZSBjYXNlcyk6DQogICAgICAg ICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIEl0IG1heSBiZSBpbXBvcnRhbnQgZm9y OiBzb3VuZCBmaWxlLCBkcmF3aW5nIGZpbGUsIGxhdGV4IHNvdXJjZSBmaWxlcyBvZiBhcnRpY2xl cywgaVdvcmsgZmlsZXMsIE9mZmljZSBmaWxlcywgaW1hZ2VzLCBwZGZzLCBzb3VyY2UgY29kZSwg ZXRjLg0KICAgICAgICAgICAgICAgICAgICAgICBpaS4gICAgICAgICAgICAgIEl0IG1heSBiZSBu b3QgaW1wb3J0YW50IGZvcjogUGh5c2ljcyBkYXRhLg0KZykgICAgICAgICBXaGV0aGVyIHRvIGVu YWJsZSBhbiBhdXRvbWF0aWMgbWVyZ2luZyBtaWdodCBiZSBhIHJlc2VhcmNoIHByb2JsZW0gb3Ig YSBmdXJ0aGVyIHVzZSBjYXNlPw0KaCkgICAgICAgICBJZiBJdCBpcyBzbyBoYXJkIHRvIGRvIGNv bmZsaWN0IHJlc29sdXRpb24gZXZlbiBmb3Igc2ltcGxlIGFuZCB3ZWxsLXN0cnVjdHVyZWQgobB2 Y2FyZCBjYXNlobEsIHNob3VsZCB3ZSBoYW5kbGUgdGhpcyBpc3N1ZSBieSBzZXBhcmF0aW5nIGZp bGVzIGJhc2VkIG9uIHRoZWlyIHByb3BlcnR5Pw0KMTEuICAgICBBIGRlLWZhY3RvIHN5bmMgcHJv dG9jb2wgZGVzY3JpcHRpb24gdXNlZCBieSBvd25DbG91ZCBzeW5jIGNsaWVudHMgKGFuZCBzb21l IGZvb3Rub3RlIGRpc2N1c3Npb24gb24gZnV0dXJlIGRldmVsb3BtZW50IGRpcmVjdGlvbnMpLiBU aGlzIGRvY3VtZW50IGNvbWVzIHdpdGggYSB0ZXN0IHN1aXRlIChwYXJ0aWFsbHkgaW1wbGVtZW50 ZWQpIHRoYXQgdmVyaWZpZXMgaWYgYSBzZXJ2ZXIgYWRoZXJlcyB0byB0aGlzIHNwZWNpZmljYXRp b24uIFRoZSBVUkwgaXMgYXMgZm9sbG93Og0KaHR0cHM6Ly9naXRodWIuY29tL2Nlcm5ib3gvc21h c2hib3gvYmxvYi9tYXN0ZXIvcHJvdG9jb2wvcHJvdG9jb2wubWQNCiANCiANClNvbWUgcmVsYXRl ZCBvcmdhbml6YXRpb25zLCBldmVudHMsIHByb2plY3RzLCBldGMuOiANCkdFQU5UIGNvbW11bml0 eSwgT3BlbkNsb3VkTWVzaCwgb3duQ2xvdWQsIENTMywgcmVtb3RlU3RvcmFnZSwgQ2xhd0lPLCBj cm9zc2Nsb3VkLCBEcm9wYm94LCBDRVJOIEVPUyBTdG9yYWdlIFN5c3RlbSwgdG8gYmUgYWRkZWSh rQ== ------=_001_NextPart268517077240_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Here is the latest version. Please email me if anything is=20 missed:

 

1.      =   =20 The = design=20 targets of WebDAV, rsync and other existing approaches?

2.      =   =20 The = potential=20 use cases of ISS, such as client/server, git-like pattern, svn,=20 etc.

3.      =   =20 The = efficiency=20 improvements might be the second goal for standardizing ISS=20 protocol

4.      =   =20 CORS= headers on=20 storage sync APIs

5.      =   =20 What= is needed=20 for the ISS: a sync protocol or a generalized API

6.      =   =20 remo= teStorage=20 draft discussion

a)      =   =20 rela= tionship vs=20 WebDAV

b)      =   =20 MOVE= action=20 (synchronization) should be added or not

c)      =   =20 Besi= de web=20 browser, desktop apps (by hacking way)

d)      =   =20 comi= cs of new=20 standard

e)      =   =20 etag= issues vs=20 metadata

      =             &n= bsp;     =20 i.      =        =20 is m= ainly for=20 identifying whether a document is changed or not

      =             &n= bsp;   =20 ii.      =        =20 is e= asy to=20 implement than that of WebDAV sync protocol or not

      =             &n= bsp;  =20 iii.      =        =20 the = metadata=20 file contains all etags for all files at both client and server side or=20 not

f)      =    =20 the = distributed=20 peer model (no server) and C/S mode

g)      =   =20 a fa= ncy example=20 (with pics) of OfflineIMAP=A1=AFs sync process in following URL

http://blog.ezyang.com/2012/08/how-offlineimap-works/

7.      =   =20 GitH= ub (instead=20 of email messages) has been created:

<= FONT=20 size=3D3=20 face=3DCalibri>https://github.com/labkode/Internet-Storage-Sync

a)      =   =20 What= is the=20 topic?

      =             &n= bsp;     =20 i.      =        =20 Whet= her it is=20 suitable to build on WebDAV

      =             &n= bsp;   =20 ii.      =        =20 WebD= AV vs=20 remoteStorage

      =             &n= bsp;  =20 iii.      =        =20 Adva= ntages vs=20 disadvantages of WebDAV

8.      =   =20 Meta= data and=20 data separation scheme and platform for synchronization

a)      =   =20 ownC= loud when=20 configured to use an Object Storage as the Primary User Storage. (Metadata= is=20 handled by a MySQL database)

b)      =   =20 CERN= EOS Storage=20 System. (Metadata is handled in high performance in-memory=20 structures).

c)      =   =20 Drop= Box. (As far=20 as I know it uses S3 behind. For metadata it is unknown, but probably not = on=20 S3).

= Paper for=20 analyzing DropBox:

<= FONT=20 size=3D3=20 face=3DCalibri>http://annasperotto.org/papers/2012/imc140-drago.pdf=

d)      =   =20 Claw= IO will have=20 an implementation of this approach in the next phase using=20 Swift.

9.      =   =20 Whet= her we=20 should keep metadata history or modification history or action history at = server=20 side (or other places)

10.    =20 How = to handle=20 the =A1=B0conflict discovery (resolution)=A1=B1 issues

a)      =   =20 A go= od=20 demonstration of this issue was given in details (File F, Client A, Client= B,=20 etc.)

b)      =   =20 Shou= ld it be a=20 layer above syncing?

c)      =   =20 Shou= ld it depend=20 on the use case?

d)      =   =20 Shou= ld it be a=20 one-size-fits-all approach?

e)      =   =20 How = many=20 different kinds of conflict?

      =             &n= bsp;     =20 i.      =        =20 File= level=20 conflicts, e.g. both remote (server) and local (client) have changed since= last=20 sync.

      =             &n= bsp;   =20 ii.      =        =20 Inte= rleaved=20 level conflicts, e.g. one client makes a change based on version X of the = file,=20 a second makes a change based on version X+1, the second one commits, and = then=20 the first one commits.

      =             &n= bsp;  =20 iii.      =        =20 =A1=AD

f)      =    =20 The = sequence=20 (order) of changes in one file is important or not (quite similar with =A1= =B0item 9=A1=B1=20 in this list), perhaps depends on the file type (or use=20 cases):

      =             &n= bsp;     =20 i.      =        =20 It m= ay be=20 important for: sound file, drawing file, latex source files of articles, i= Work=20 files, Office files, images, pdfs, source code, etc.

      =             &n= bsp;   =20 ii.      =        =20 It m= ay be not=20 important for: Physics data.

g)      =   =20 Whet= her to=20 enable an automatic merging might be a research problem or a further use=20 case?

h)      =   =20 If I= t is so hard=20 to do conflict resolution even for simple and well-structured =A1=B0vcard = case=A1=B1,=20 should we handle this issue by separating files based on their=20 property?

11.    =20 A de= -facto sync=20 protocol description used by ownCloud sync clients (and some footnote disc= ussion=20 on future development directions). This document comes with a test suite=20 (partially implemented) that verifies if a server adheres to this specific= ation.=20 The URL is as follow:

https://github.com/cernbox/smashbox/blob/master/protocol/pr= otocol.md

 

 

Some related organizations, events, projects, etc.:=20

GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorag= e,=20 ClawIO, crosscloud, Dropbox, CERN EOS Storage System, to be=20 added=A1=AD

------=_001_NextPart268517077240_=------ From nobody Sun Dec 13 17:59:02 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277241A9060 for ; Sun, 13 Dec 2015 17:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.689 X-Spam-Level: * X-Spam-Status: No, score=1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_26=0.6, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glWH54QKwhy5 for ; Sun, 13 Dec 2015 17:58:59 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2851A905F for ; Sun, 13 Dec 2015 17:58:58 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygBHaPwfI25WnPkSAA--.32527S2; Mon, 14 Dec 2015 10:02:07 +0800 (CST) Date: Mon, 14 Dec 2015 09:59:57 +0800 From: "Fei Song" To: storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121409595759333241@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygBHaPwfI25WnPkSAA--.32527S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWr47AFWrXFykuw4UXF48Crg_yoWrGF1fpF WfGwsxKa4kJ3yav3ykXr4xurWrtFs3Kw43JFn3Gw4xAws8XFy0gF4xtr4rur97Jry7Z34q qr4Yvas8Cw1DZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 xHUPUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: [Storagesync] recent issues discussed (plain text) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 01:59:01 -0000 SGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24uIFBsZWFzZSBlbWFpbCBtZSBpZiBhbnl0aGluZyBp cyBtaXNzZWQ6DQoNCjEuVGhlIGRlc2lnbiB0YXJnZXRzIG9mIFdlYkRBViwgcnN5bmMgYW5kIG90 aGVyIGV4aXN0aW5nIGFwcHJvYWNoZXM/DQoyLlRoZSBwb3RlbnRpYWwgdXNlIGNhc2VzIG9mIElT Uywgc3VjaCBhcyBjbGllbnQvc2VydmVyLCBnaXQtbGlrZSBwYXR0ZXJuLCBzdm4sIGV0Yy4NCjMu VGhlIGVmZmljaWVuY3kgaW1wcm92ZW1lbnRzIG1pZ2h0IGJlIHRoZSBzZWNvbmQgZ29hbCBmb3Ig c3RhbmRhcmRpemluZyBJU1MgcHJvdG9jb2wNCjQuQ09SUyBoZWFkZXJzIG9uIHN0b3JhZ2Ugc3lu YyBBUElzDQo1LldoYXQgaXMgbmVlZGVkIGZvciB0aGUgSVNTOiBhIHN5bmMgcHJvdG9jb2wgb3Ig YSBnZW5lcmFsaXplZCBBUEkNCjYucmVtb3RlU3RvcmFnZSBkcmFmdCBkaXNjdXNzaW9uDQogIGEp cmVsYXRpb25zaGlwIHZzIFdlYkRBVg0KICBiKU1PVkUgYWN0aW9uIChzeW5jaHJvbml6YXRpb24p IHNob3VsZCBiZSBhZGRlZCBvciBub3QNCiAgYylCZXNpZGUgd2ViIGJyb3dzZXIsIGRlc2t0b3Ag YXBwcyAoYnkgaGFja2luZyB3YXkpDQogIGQpY29taWNzIG9mIG5ldyBzdGFuZGFyZA0KICBlKWV0 YWcgaXNzdWVzIHZzIG1ldGFkYXRhDQogICAgaS5pcyBtYWlubHkgZm9yIGlkZW50aWZ5aW5nIHdo ZXRoZXIgYSBkb2N1bWVudCBpcyBjaGFuZ2VkIG9yIG5vdA0KICAgIGlpLmlzIGVhc3kgdG8gaW1w bGVtZW50IHRoYW4gdGhhdCBvZiBXZWJEQVYgc3luYyBwcm90b2NvbCBvciBub3QNCiAgICBpaWku dGhlIG1ldGFkYXRhIGZpbGUgY29udGFpbnMgYWxsIGV0YWdzIGZvciBhbGwgZmlsZXMgYXQgYm90 aCBjbGllbnQgYW5kIHNlcnZlciBzaWRlIG9yIG5vdA0KICBmKXRoZSBkaXN0cmlidXRlZCBwZWVy IG1vZGVsIChubyBzZXJ2ZXIpIGFuZCBDL1MgbW9kZQ0KICBnKWEgZmFuY3kgZXhhbXBsZSAod2l0 aCBwaWNzKSBvZiBPZmZsaW5lSU1BUKGvcyBzeW5jIHByb2Nlc3MgaW4gZm9sbG93aW5nIFVSTA0K ICAgIGh0dHA6Ly9ibG9nLmV6eWFuZy5jb20vMjAxMi8wOC9ob3ctb2ZmbGluZWltYXAtd29ya3Mv DQo3LkdpdEh1YiAoaW5zdGVhZCBvZiBlbWFpbCBtZXNzYWdlcykgaGFzIGJlZW4gY3JlYXRlZDoN CiAgaHR0cHM6Ly9naXRodWIuY29tL2xhYmtvZGUvSW50ZXJuZXQtU3RvcmFnZS1TeW5jDQogIGEp V2hhdCBpcyB0aGUgdG9waWM/IA0KICAgIGkuV2hldGhlciBpdCBpcyBzdWl0YWJsZSB0byBidWls ZCBvbiBXZWJEQVYNCiAgICBpaS5XZWJEQVYgdnMgcmVtb3RlU3RvcmFnZQ0KICAgIGlpaS5BZHZh bnRhZ2VzIHZzIGRpc2FkdmFudGFnZXMgb2YgV2ViREFWDQo4Lk1ldGFkYXRhIGFuZCBkYXRhIHNl cGFyYXRpb24gc2NoZW1lIGFuZCBwbGF0Zm9ybSBmb3Igc3luY2hyb25pemF0aW9uDQogIGEpb3du Q2xvdWQgd2hlbiBjb25maWd1cmVkIHRvIHVzZSBhbiBPYmplY3QgU3RvcmFnZSBhcyB0aGUgUHJp bWFyeSBVc2VyIFN0b3JhZ2UuIChNZXRhZGF0YSBpcyBoYW5kbGVkIGJ5IGEgTXlTUUwgZGF0YWJh c2UpDQogIGIpQ0VSTiBFT1MgU3RvcmFnZSBTeXN0ZW0uIChNZXRhZGF0YSBpcyBoYW5kbGVkIGlu IGhpZ2ggcGVyZm9ybWFuY2UgaW4tbWVtb3J5IHN0cnVjdHVyZXMpLg0KICBjKURyb3BCb3guIChB cyBmYXIgYXMgSSBrbm93IGl0IHVzZXMgUzMgYmVoaW5kLiBGb3IgbWV0YWRhdGEgaXQgaXMgdW5r bm93biwgYnV0IHByb2JhYmx5IG5vdCBvbiBTMykuIA0KICAgIFBhcGVyIGZvciBhbmFseXppbmcg RHJvcEJveDoNCiAgICBodHRwOi8vYW5uYXNwZXJvdHRvLm9yZy9wYXBlcnMvMjAxMi9pbWMxNDAt ZHJhZ28ucGRmDQogIGQpQ2xhd0lPIHdpbGwgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlz IGFwcHJvYWNoIGluIHRoZSBuZXh0IHBoYXNlIHVzaW5nIFN3aWZ0Lg0KOS5XaGV0aGVyIHdlIHNo b3VsZCBrZWVwIG1ldGFkYXRhIGhpc3Rvcnkgb3IgbW9kaWZpY2F0aW9uIGhpc3Rvcnkgb3IgYWN0 aW9uIGhpc3RvcnkgYXQgc2VydmVyIHNpZGUgKG9yIG90aGVyIHBsYWNlcykNCjEwLkhvdyB0byBo YW5kbGUgdGhlIKGwY29uZmxpY3QgZGlzY292ZXJ5IChyZXNvbHV0aW9uKaGxIGlzc3Vlcw0KICBh KUEgZ29vZCBkZW1vbnN0cmF0aW9uIG9mIHRoaXMgaXNzdWUgd2FzIGdpdmVuIGluIGRldGFpbHMg KEZpbGUgRiwgQ2xpZW50IEEsIENsaWVudCBCLCBldGMuKQ0KICBiKVNob3VsZCBpdCBiZSBhIGxh eWVyIGFib3ZlIHN5bmNpbmc/DQogIGMpU2hvdWxkIGl0IGRlcGVuZCBvbiB0aGUgdXNlIGNhc2U/ DQogIGQpU2hvdWxkIGl0IGJlIGEgb25lLXNpemUtZml0cy1hbGwgYXBwcm9hY2g/DQogIGUpSG93 IG1hbnkgZGlmZmVyZW50IGtpbmRzIG9mIGNvbmZsaWN0Pw0KICAgIGkuRmlsZSBsZXZlbCBjb25m bGljdHMsIGUuZy4gYm90aCByZW1vdGUgKHNlcnZlcikgYW5kIGxvY2FsIChjbGllbnQpIGhhdmUg Y2hhbmdlZCBzaW5jZSBsYXN0IHN5bmMuDQogICAgaWkuSW50ZXJsZWF2ZWQgbGV2ZWwgY29uZmxp Y3RzLCBlLmcuIG9uZSBjbGllbnQgbWFrZXMgYSBjaGFuZ2UgYmFzZWQgb24gdmVyc2lvbiBYIG9m IHRoZSBmaWxlLCBhIHNlY29uZCBtYWtlcyBhIGNoYW5nZSBiYXNlZCBvbiB2ZXJzaW9uIFgrMSwg dGhlIHNlY29uZCBvbmUgY29tbWl0cywgYW5kIHRoZW4gdGhlIGZpcnN0IG9uZSBjb21taXRzLg0K ICAgIGlpaS6hrQ0KICBmKVRoZSBzZXF1ZW5jZSAob3JkZXIpIG9mIGNoYW5nZXMgaW4gb25lIGZp bGUgaXMgaW1wb3J0YW50IG9yIG5vdCAocXVpdGUgc2ltaWxhciB3aXRoIKGwaXRlbSA5obEgaW4g dGhpcyBsaXN0KSwgcGVyaGFwcyBkZXBlbmRzIG9uIHRoZSBmaWxlIHR5cGUgKG9yIHVzZSBjYXNl cyk6DQogICAgaS5JdCBtYXkgYmUgaW1wb3J0YW50IGZvcjogc291bmQgZmlsZSwgZHJhd2luZyBm aWxlLCBsYXRleCBzb3VyY2UgZmlsZXMgb2YgYXJ0aWNsZXMsIGlXb3JrIGZpbGVzLCBPZmZpY2Ug ZmlsZXMsIGltYWdlcywgcGRmcywgc291cmNlIGNvZGUsIGV0Yy4NCiAgICBpaS5JdCBtYXkgYmUg bm90IGltcG9ydGFudCBmb3I6IFBoeXNpY3MgZGF0YS4NCiAgZylXaGV0aGVyIHRvIGVuYWJsZSBh biBhdXRvbWF0aWMgbWVyZ2luZyBtaWdodCBiZSBhIHJlc2VhcmNoIHByb2JsZW0gb3IgYSBmdXJ0 aGVyIHVzZSBjYXNlPw0KICBoKUlmIEl0IGlzIHNvIGhhcmQgdG8gZG8gY29uZmxpY3QgcmVzb2x1 dGlvbiBldmVuIGZvciBzaW1wbGUgYW5kIHdlbGwtc3RydWN0dXJlZCChsHZjYXJkIGNhc2WhsSwg c2hvdWxkIHdlIGhhbmRsZSB0aGlzIGlzc3VlIGJ5IHNlcGFyYXRpbmcgZmlsZXMgYmFzZWQgb24g dGhlaXIgcHJvcGVydHk/DQoxMS5BIGRlLWZhY3RvIHN5bmMgcHJvdG9jb2wgZGVzY3JpcHRpb24g dXNlZCBieSBvd25DbG91ZCBzeW5jIGNsaWVudHMgKGFuZCBzb21lIGZvb3Rub3RlIGRpc2N1c3Np b24gb24gZnV0dXJlIGRldmVsb3BtZW50IGRpcmVjdGlvbnMpLiBUaGlzIGRvY3VtZW50IGNvbWVz IHdpdGggYSB0ZXN0IHN1aXRlIChwYXJ0aWFsbHkgaW1wbGVtZW50ZWQpIHRoYXQgdmVyaWZpZXMg aWYgYSBzZXJ2ZXIgYWRoZXJlcyB0byB0aGlzIHNwZWNpZmljYXRpb24uIFRoZSBVUkwgaXMgYXMg Zm9sbG93Og0KICBodHRwczovL2dpdGh1Yi5jb20vY2VybmJveC9zbWFzaGJveC9ibG9iL21hc3Rl ci9wcm90b2NvbC9wcm90b2NvbC5tZA0KDQoNClNvbWUgcmVsYXRlZCBvcmdhbml6YXRpb25zLCBl dmVudHMsIHByb2plY3RzLCBldGMuOiANCkdFQU5UIGNvbW11bml0eSwgT3BlbkNsb3VkTWVzaCwg b3duQ2xvdWQsIENTMywgcmVtb3RlU3RvcmFnZSwgQ2xhd0lPLCBjcm9zc2Nsb3VkLCBEcm9wYm94 LCBDRVJOIEVPUyBTdG9yYWdlIFN5c3RlbSwgdG8gYmUgYWRkZWShrQ== From nobody Sun Dec 13 18:09:37 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FDE1A908B for ; Sun, 13 Dec 2015 18:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRkInia9z-lx for ; Sun, 13 Dec 2015 18:09:34 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 192251A908A for ; Sun, 13 Dec 2015 18:09:33 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygBHbfCDJW5WjrIGAA--.18970S2; Mon, 14 Dec 2015 10:12:19 +0800 (CST) Date: Mon, 14 Dec 2015 10:10:16 +0800 From: "Fei Song" To: "Jakub Moscicki" References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <2015121222163146812636@bjtu.edu.cn>, <41F39F50-E49A-4C2B-BF09-B182580008DF@cern.ch> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015121410101651584543@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygBHbfCDJW5WjrIGAA--.18970S2 X-Coremail-Antispam: 1UD129KBjvJXoWxur18tr1kWry5XFy3AF15XFb_yoWrZFyrpF WfJwsrKaykJrW3Zw4kXw4I9rWFyFn5GrW7JFn3tw4xAr98XFy0gF4Igr4rur9rGry3Zw1q qr4Y9a45Cw1kZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBqb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0 F24lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41l4I8I3I 0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWU GVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI 0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0 rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r 1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8SPfJUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync Subject: Re: [Storagesync] recent issues discussed (html) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 02:09:36 -0000 SGkgSmFrdWIsDQoNCkl0IGhhcyBiZWVuIGFkZGVkLg0KSSBjcmVhdGVkIGEgbmV3IGl0ZW0gZm9y IHRoaXMgdXNlZnVsIGluZm9ybWF0aW9uIGluIHRoZSBsaXN0LiBQbGVhc2UgbGV0IG1lIGtub3cg aWYgeW91IHRoaW5rIGl0IHNob3VsZCBiZSB1bmRlciBvdGhlciBpdGVtcy4NClRoYW5rcyBmb3Ig dGhhdCENCg0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5IZWxsbywNCj4NCj5Zb3UgbWF5 IGFsc28gY29uc2lkZXIgdG8gYWRkIHRvIHRoaXMgbGlzdCB0aGlzIGRlLWZhY3RvIHN5bmMgcHJv dG9jb2wgZGVzY3JpcHRpb24gdXNlZCBieSBvd25jbG91ZCBzeW5jIGNsaWVudHMgKGFuZCBzb21l IGZvb3Rub3RlIGRpc2N1c3Npb24gb24gZnV0dXJlIGRldmVsb3BtZW50IGRpcmVjdGlvbnMpOg0K Pg0KPmh0dHBzOi8vZ2l0aHViLmNvbS9jZXJuYm94L3NtYXNoYm94L2Jsb2IvbWFzdGVyL3Byb3Rv Y29sL3Byb3RvY29sLm1kDQo+DQo+VGhpcyBkb2N1bWVudCBjb21lcyB3aXRoIGEgdGVzdCBzdWl0 ZSAocGFydGlhbGx5IGltcGxlbWVudGVkKSB0aGF0IHZlcmlmaWVzIGlmIGEgc2VydmVyIGFkaGVy ZXMgdG8gdGhpcyBzcGVjaWZpY2F0aW9uLg0KPg0KPkJlc3QgcmVnYXJkcywNCj4NCj5rdWJhDQo+ DQo+LS0NCj4NCj4NCj5PbiAxMiBEZWMgMjAxNSwgYXQgMTU6MTYsIEZlaSBTb25nIDxmc29uZ0Bi anR1LmVkdS5jbjxtYWlsdG86ZnNvbmdAYmp0dS5lZHUuY24+PiB3cm90ZToNCj4NCj5IZXJlIGlz IHRoZSBsYXRlc3QgdmVyc2lvbi4gUGxlYXNlIGVtYWlsIG1lIGlmIGFueXRoaW5nIGlzIG1pc3Nl ZDoNCj4NCj4xLiAgICAgICAgIFRoZSBkZXNpZ24gdGFyZ2V0cyBvZiBXZWJEQVYsIHJzeW5jIGFu ZCBvdGhlciBleGlzdGluZyBhcHByb2FjaGVzPw0KPjIuICAgICAgICAgVGhlIHBvdGVudGlhbCB1 c2UgY2FzZXMgb2YgSVNTLCBzdWNoIGFzIGNsaWVudC9zZXJ2ZXIsIGdpdC1saWtlIHBhdHRlcm4s IHN2biwgZXRjLg0KPjMuICAgICAgICAgVGhlIGVmZmljaWVuY3kgaW1wcm92ZW1lbnRzIG1pZ2h0 IGJlIHRoZSBzZWNvbmQgZ29hbCBmb3Igc3RhbmRhcmRpemluZyBJU1MgcHJvdG9jb2wNCj40LiAg ICAgICAgIENPUlMgaGVhZGVycyBvbiBzdG9yYWdlIHN5bmMgQVBJcw0KPjUuICAgICAgICAgV2hh dCBpcyBuZWVkZWQgZm9yIHRoZSBJU1M6IGEgc3luYyBwcm90b2NvbCBvciBhIGdlbmVyYWxpemVk IEFQSQ0KPjYuICAgICAgICAgcmVtb3RlU3RvcmFnZSBkcmFmdCBkaXNjdXNzaW9uDQo+YSkgICAg ICAgICByZWxhdGlvbnNoaXAgdnMgV2ViREFWDQo+YikgICAgICAgICBNT1ZFIGFjdGlvbiAoc3lu Y2hyb25pemF0aW9uKSBzaG91bGQgYmUgYWRkZWQgb3Igbm90DQo+YykgICAgICAgICBCZXNpZGUg d2ViIGJyb3dzZXIsIGRlc2t0b3AgYXBwcyAoYnkgaGFja2luZyB3YXkpDQo+ZCkgICAgICAgICBj b21pY3Mgb2YgbmV3IHN0YW5kYXJkDQo+ZSkgICAgICAgICBldGFnIGlzc3VlcyB2cyBtZXRhZGF0 YQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICBpLiAgICAgICAgICAgICAgaXMgbWFpbmx5IGZv ciBpZGVudGlmeWluZyB3aGV0aGVyIGEgZG9jdW1lbnQgaXMgY2hhbmdlZCBvciBub3QNCj4gICAg ICAgICAgICAgICAgICAgICAgIGlpLiAgICAgICAgICAgICAgaXMgZWFzeSB0byBpbXBsZW1lbnQg dGhhbiB0aGF0IG9mIFdlYkRBViBzeW5jIHByb3RvY29sIG9yIG5vdA0KPiAgICAgICAgICAgICAg ICAgICAgICBpaWkuICAgICAgICAgICAgICB0aGUgbWV0YWRhdGEgZmlsZSBjb250YWlucyBhbGwg ZXRhZ3MgZm9yIGFsbCBmaWxlcyBhdCBib3RoIGNsaWVudCBhbmQgc2VydmVyIHNpZGUgb3Igbm90 DQo+ZikgICAgICAgICAgdGhlIGRpc3RyaWJ1dGVkIHBlZXIgbW9kZWwgKG5vIHNlcnZlcikgYW5k IEMvUyBtb2RlDQo+ZykgICAgICAgICBhIGZhbmN5IGV4YW1wbGUgKHdpdGggcGljcykgb2YgT2Zm bGluZUlNQVChr3Mgc3luYyBwcm9jZXNzIGluIGZvbGxvd2luZyBVUkwNCj5odHRwOi8vYmxvZy5l enlhbmcuY29tLzIwMTIvMDgvaG93LW9mZmxpbmVpbWFwLXdvcmtzLw0KPjcuICAgICAgICAgR2l0 SHViIChpbnN0ZWFkIG9mIGVtYWlsIG1lc3NhZ2VzKSBoYXMgYmVlbiBjcmVhdGVkOg0KPmh0dHBz Oi8vZ2l0aHViLmNvbS9sYWJrb2RlL0ludGVybmV0LVN0b3JhZ2UtU3luYw0KPmEpICAgICAgICAg V2hhdCBpcyB0aGUgdG9waWM/DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGkuICAgICAgICAg ICAgICBXaGV0aGVyIGl0IGlzIHN1aXRhYmxlIHRvIGJ1aWxkIG9uIFdlYkRBVg0KPiAgICAgICAg ICAgICAgICAgICAgICAgaWkuICAgICAgICAgICAgICBXZWJEQVYgdnMgcmVtb3RlU3RvcmFnZQ0K PiAgICAgICAgICAgICAgICAgICAgICBpaWkuICAgICAgICAgICAgICBBZHZhbnRhZ2VzIHZzIGRp c2FkdmFudGFnZXMgb2YgV2ViREFWDQo+OC4gICAgICAgICBNZXRhZGF0YSBhbmQgZGF0YSBzZXBh cmF0aW9uIHNjaGVtZSBhbmQgcGxhdGZvcm0gZm9yIHN5bmNocm9uaXphdGlvbg0KPmEpICAgICAg ICAgb3duQ2xvdWQgd2hlbiBjb25maWd1cmVkIHRvIHVzZSBhbiBPYmplY3QgU3RvcmFnZSBhcyB0 aGUgUHJpbWFyeSBVc2VyIFN0b3JhZ2UuIChNZXRhZGF0YSBpcyBoYW5kbGVkIGJ5IGEgTXlTUUwg ZGF0YWJhc2UpDQo+YikgICAgICAgICBDRVJOIEVPUyBTdG9yYWdlIFN5c3RlbS4gKE1ldGFkYXRh IGlzIGhhbmRsZWQgaW4gaGlnaCBwZXJmb3JtYW5jZSBpbi1tZW1vcnkgc3RydWN0dXJlcykuDQo+ YykgICAgICAgICBEcm9wQm94LiAoQXMgZmFyIGFzIEkga25vdyBpdCB1c2VzIFMzIGJlaGluZC4g Rm9yIG1ldGFkYXRhIGl0IGlzIHVua25vd24sIGJ1dCBwcm9iYWJseSBub3Qgb24gUzMpLg0KPlBh cGVyIGZvciBhbmFseXppbmcgRHJvcEJveDoNCj5odHRwOi8vYW5uYXNwZXJvdHRvLm9yZy9wYXBl cnMvMjAxMi9pbWMxNDAtZHJhZ28ucGRmDQo+ZCkgICAgICAgICBDbGF3SU8gd2lsbCBoYXZlIGFu IGltcGxlbWVudGF0aW9uIG9mIHRoaXMgYXBwcm9hY2ggaW4gdGhlIG5leHQgcGhhc2UgdXNpbmcg U3dpZnQuDQo+OS4gICAgICAgICBXaGV0aGVyIHdlIHNob3VsZCBrZWVwIG1ldGFkYXRhIGhpc3Rv cnkgb3IgbW9kaWZpY2F0aW9uIGhpc3Rvcnkgb3IgYWN0aW9uIGhpc3RvcnkgYXQgc2VydmVyIHNp ZGUgKG9yIG90aGVyIHBsYWNlcykNCj4xMC4gICAgIEhvdyB0byBoYW5kbGUgdGhlIKGwY29uZmxp Y3QgZGlzY292ZXJ5IChyZXNvbHV0aW9uKaGxIGlzc3Vlcw0KPmEpICAgICAgICAgQSBnb29kIGRl bW9uc3RyYXRpb24gb2YgdGhpcyBpc3N1ZSB3YXMgZ2l2ZW4gaW4gZGV0YWlscyAoRmlsZSBGLCBD bGllbnQgQSwgQ2xpZW50IEIsIGV0Yy4pDQo+YikgICAgICAgICBTaG91bGQgaXQgYmUgYSBsYXll ciBhYm92ZSBzeW5jaW5nPw0KPmMpICAgICAgICAgU2hvdWxkIGl0IGRlcGVuZCBvbiB0aGUgdXNl IGNhc2U/DQo+ZCkgICAgICAgICBTaG91bGQgaXQgYmUgYSBvbmUtc2l6ZS1maXRzLWFsbCBhcHBy b2FjaD8NCj5lKSAgICAgICAgIEhvdyBtYW55IGRpZmZlcmVudCBraW5kcyBvZiBjb25mbGljdD8N Cj4gICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAgIEZpbGUgbGV2ZWwgY29u ZmxpY3RzLCBlLmcuIGJvdGggcmVtb3RlIChzZXJ2ZXIpIGFuZCBsb2NhbCAoY2xpZW50KSBoYXZl IGNoYW5nZWQgc2luY2UgbGFzdCBzeW5jLg0KPiAgICAgICAgICAgICAgICAgICAgICAgaWkuICAg ICAgICAgICAgICBJbnRlcmxlYXZlZCBsZXZlbCBjb25mbGljdHMsIGUuZy4gb25lIGNsaWVudCBt YWtlcyBhIGNoYW5nZSBiYXNlZCBvbiB2ZXJzaW9uIFggb2YgdGhlIGZpbGUsIGEgc2Vjb25kIG1h a2VzIGEgY2hhbmdlIGJhc2VkIG9uIHZlcnNpb24gWCsxLCB0aGUgc2Vjb25kIG9uZSBjb21taXRz LCBhbmQgdGhlbiB0aGUgZmlyc3Qgb25lIGNvbW1pdHMuDQo+ICAgICAgICAgICAgICAgICAgICAg IGlpaS4gICAgICAgICAgICAgIKGtDQo+ZikgICAgICAgICAgVGhlIHNlcXVlbmNlIChvcmRlcikg b2YgY2hhbmdlcyBpbiBvbmUgZmlsZSBpcyBpbXBvcnRhbnQgb3Igbm90IChxdWl0ZSBzaW1pbGFy IHdpdGggobBpdGVtIDmhsSBpbiB0aGlzIGxpc3QpLCBwZXJoYXBzIGRlcGVuZHMgb24gdGhlIGZp bGUgdHlwZSAob3IgdXNlIGNhc2VzKToNCj4gICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAg ICAgICAgICAgIEl0IG1heSBiZSBpbXBvcnRhbnQgZm9yOiBzb3VuZCBmaWxlLCBkcmF3aW5nIGZp bGUsIGxhdGV4IHNvdXJjZSBmaWxlcyBvZiBhcnRpY2xlcywgaVdvcmsgZmlsZXMsIE9mZmljZSBm aWxlcywgaW1hZ2VzLCBwZGZzLCBzb3VyY2UgY29kZSwgZXRjLg0KPiAgICAgICAgICAgICAgICAg ICAgICAgaWkuICAgICAgICAgICAgICBJdCBtYXkgYmUgbm90IGltcG9ydGFudCBmb3I6IFBoeXNp Y3MgZGF0YS4NCj5nKSAgICAgICAgIFdoZXRoZXIgdG8gZW5hYmxlIGFuIGF1dG9tYXRpYyBtZXJn aW5nIG1pZ2h0IGJlIGEgcmVzZWFyY2ggcHJvYmxlbSBvciBhIGZ1cnRoZXIgdXNlIGNhc2U/DQo+ aCkgICAgICAgICBJZiBJdCBpcyBzbyBoYXJkIHRvIGRvIGNvbmZsaWN0IHJlc29sdXRpb24gZXZl biBmb3Igc2ltcGxlIGFuZCB3ZWxsLXN0cnVjdHVyZWQgobB2Y2FyZCBjYXNlobEsIHNob3VsZCB3 ZSBoYW5kbGUgdGhpcyBpc3N1ZSBieSBzZXBhcmF0aW5nIGZpbGVzIGJhc2VkIG9uIHRoZWlyIHBy b3BlcnR5Pw0KPg0KPlNvbWUgcmVsYXRlZCBvcmdhbml6YXRpb25zLCBldmVudHMsIHByb2plY3Rz LCBldGMuOg0KPkdFQU5UIGNvbW11bml0eSwgT3BlbkNsb3VkTWVzaCwgb3duQ2xvdWQsIENTMywg cmVtb3RlU3RvcmFnZSwgQ2xhd0lPLCBjcm9zc2Nsb3VkLCBEcm9wYm94LCBDRVJOIEVPUyBTdG9y YWdlIFN5c3RlbSx0byBiZSBhZGRlZKGtDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5TdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNCj5TdG9yYWdlc3lu Y0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+DQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPg== From nobody Tue Dec 29 06:21:44 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9B41A8853 for ; Tue, 29 Dec 2015 06:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVSMCE99T7s0 for ; Tue, 29 Dec 2015 06:21:39 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0115.outbound.protection.outlook.com [104.47.125.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD12B1A8857 for ; Tue, 29 Dec 2015 06:21:31 -0800 (PST) Received: from SIXPR03MB0640.apcprd03.prod.outlook.com (10.160.174.16) by SIXPR03MB0640.apcprd03.prod.outlook.com (10.160.174.16) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 29 Dec 2015 14:21:16 +0000 Received: from SIXPR03MB0640.apcprd03.prod.outlook.com ([10.160.174.16]) by SIXPR03MB0640.apcprd03.prod.outlook.com ([10.160.174.16]) with mapi id 15.01.0361.006; Tue, 29 Dec 2015 14:21:16 +0000 From: "Somers-Harris, David | David | OPS" To: storagesync Thread-Topic: [Storagesync] Camlistore Thread-Index: AQHRQkQtpkpAKXhMJkm3PQrQ50O7fg== Date: Tue, 29 Dec 2015 14:21:16 +0000 Message-ID: References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <2015121222163146812636@bjtu.edu.cn>, <41F39F50-E49A-4C2B-BF09-B182580008DF@cern.ch>, <2015121410101651584543@bjtu.edu.cn> In-Reply-To: <2015121410101651584543@bjtu.edu.cn> Accept-Language: en-US, ja-JP Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.somers-harris@rakuten.com; x-originating-ip: [132.245.41.101] x-microsoft-exchange-diagnostics: 1; SIXPR03MB0640; 5:YOocGRiFL62MWuU2169arwGdNMi2usOfxt1rQk8ntFgrf5N29cgdb6xWodCUGG8TooDJaHD4BHLCVXKqDzssfrvecd+uUydYnwQr8l5t15KHlKXJ8phoZKxjMN0U+JCm794Z2sCS0g454nhucylBUQ==; 24:7GK8KB3TjBBRtf/lT/hPlhHDt8k6BGHxeJEHIUADw6uO+nTcH5+eyJy/O1Dk0cbNcvc0HHPM77O/h0gAb8fCFgUw4KAX9Ni/4omNqiBJS00=; 20:Y7dsgA0O02QfTVfw3qhfIes+1hAK2Huth4oLPUcOYZO1aT1yX0ifZB3sRRhqv2yaJW2dzxumgI9ym5nXEmBrAx2M/cGoyaS8Bb+janlBx+7hLXegsXb7fRt7Qh7UTp9lzM/37SpCQ3+UbLfD6cz6dp8ser402mtayCtjGQV5mF0gbwjcv6JdMJhzJ/X8c1r3wvrK5kULNdb+PFjzNEYkf91ghPJJ1Dk/IUj5AbADs0SVefLGQmWrZy10MEcgXwy0uMWRM7vZrF43e51ZXuguEAgS2o7JvEICQLTa0CjsxwojuB8dD+eSWalPv3/CKiS1xoH1g+GKkkxPRlcjdIR8PlASyhk09usrDVUtwc7GbN01a+DJrcZO8+h7jHp47lLsHMSXZVuls1ZkJzuNU6HCqCp9EchZK7yTqkRy9jewFg+svawguBK+OI5JNeixmC/wAxjNGcr/7gNM9c6LcSq33vkmAAAI9tAlHlKvgNoPLf2R0PXRVZ07gtz4iA3v/eLO x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SIXPR03MB0640; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:SIXPR03MB0640; BCL:0; PCL:0; RULEID:; SRVR:SIXPR03MB0640; x-forefront-prvs: 0805EC9467 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51444003)(6116002)(77096005)(5002640100001)(10400500002)(586003)(5004730100002)(66066001)(50986999)(189998001)(106116001)(105586002)(92566002)(229853001)(106356001)(74316001)(2900100001)(76176999)(2950100001)(54356999)(87936001)(101416001)(15975445007)(86362001)(450100001)(11100500001)(19580395003)(33656002)(122556002)(93886004)(40100003)(1096002)(76576001)(102836003)(5008740100001)(97736004)(3846002)(1220700001)(81156007)(5001960100002)(5003600100002)(110136002)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:SIXPR03MB0640; H:SIXPR03MB0640.apcprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rakuten.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rakuten.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2015 14:21:16.0928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53a8b0d9-d900-48cc-9d7e-5935dc8d5b17 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR03MB0640 Archived-At: Subject: [Storagesync] Camlistore X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 14:21:42 -0000 Hi, Has anybody here heard of Camlistore? https://camlistore.org/ >From what I gather it's a content agnostic CMS which provides "... a way to store, sync, share, model and back up content." Quoting the presenter describing his motivations for writing this:=20 "I'm sick of thinking about what the thing is - I just want a place to put = stuff" "I don't really like filesystems, I just want a kind of dumping ground" "I believe in protocols and standards ... not in companies" https://www.youtube.com/watch?v=3DkBCQq5hfsug There was some discussion in this BOF regarding problems which need to be s= olved in the content management layer of synchronization. However, it appears that work has been done already towards solving some o= f these problems. Since it was mentioned in this BOF that we should focus on the transport la= yer and not so much the application layer, I think that building on top of = work like this could be quite appropriate. I checked the thread and there wasn't any mention of Camlistore so hopefull= y this is helpful information for people here. If not, I apologize for the distraction :). David= From nobody Tue Dec 29 18:32:13 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89251A9097 for ; Tue, 29 Dec 2015 18:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.489 X-Spam-Level: *** X-Spam-Status: No, score=3.489 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAWShDawel-y for ; Tue, 29 Dec 2015 18:32:10 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4751A9094 for ; Tue, 29 Dec 2015 18:32:08 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygDnaIw4QoNWoDYwAA--.8137S2; Wed, 30 Dec 2015 10:32:24 +0800 (CST) Date: Wed, 30 Dec 2015 10:31:56 +0800 From: "Fei Song" To: =?gb2312?B?U29tZXJzLUhhcnJpcywgRGF2aWQgfCBEYXZpZCB8IE9QUw==?= , storagesync References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <2015121222163146812636@bjtu.edu.cn>, <41F39F50-E49A-4C2B-BF09-B182580008DF@cern.ch>, <2015121410101651584543@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201512301031565319224@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygDnaIw4QoNWoDYwAA--.8137S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw13CFWxKrWfKFyDtrWfGrg_yoW8GrWUpF yfKF4rKFW7tF48Zw1IqF18Cr1I9rs7J3ykXwn8Jry8ArW5JF93tr1xKr1rAa4Uuryayr1j qw4j9F1UJw1DZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 g6pJUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Subject: Re: [Storagesync] Camlistore X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 02:32:11 -0000 Tm90IHlldC4uLklzIGl0IGEgbmV3IG9uZT8NCg0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcN Cj5IaSwNCj4NCj5IYXMgYW55Ym9keSBoZXJlIGhlYXJkIG9mIENhbWxpc3RvcmU/DQo+aHR0cHM6 Ly9jYW1saXN0b3JlLm9yZy8NCj4NCj4+RnJvbSB3aGF0IEkgZ2F0aGVyIGl0J3MgYSBjb250ZW50 IGFnbm9zdGljIENNUyB3aGljaCBwcm92aWRlcw0KPiIuLi4gYSB3YXkgdG8gc3RvcmUsIHN5bmMs IHNoYXJlLCBtb2RlbCBhbmQgYmFjayB1cCBjb250ZW50LiINCj4NCj4NCj5RdW90aW5nIHRoZSBw cmVzZW50ZXIgZGVzY3JpYmluZyBoaXMgbW90aXZhdGlvbnMgZm9yIHdyaXRpbmcgdGhpczogDQo+ IkknbSBzaWNrIG9mIHRoaW5raW5nIGFib3V0IHdoYXQgdGhlIHRoaW5nIGlzIC0gSSBqdXN0IHdh bnQgYSBwbGFjZSB0byBwdXQgc3R1ZmYiDQo+IkkgZG9uJ3QgcmVhbGx5IGxpa2UgZmlsZXN5c3Rl bXMsIEkganVzdCB3YW50IGEga2luZCBvZiBkdW1waW5nIGdyb3VuZCINCj4iSSBiZWxpZXZlIGlu IHByb3RvY29scyBhbmQgc3RhbmRhcmRzIC4uLiBub3QgaW4gY29tcGFuaWVzIg0KPmh0dHBzOi8v d3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9a0JDUXE1aGZzdWcNCj4NCj5UaGVyZSB3YXMgc29tZSBk aXNjdXNzaW9uIGluIHRoaXMgQk9GIHJlZ2FyZGluZyBwcm9ibGVtcyB3aGljaCBuZWVkIHRvIGJl IHNvbHZlZCBpbiB0aGUgY29udGVudCBtYW5hZ2VtZW50IGxheWVyIG9mIHN5bmNocm9uaXphdGlv bi4NCj5Ib3dldmVyLCBpdCBhcHBlYXJzIHRoYXQgd29yayBoYXMgYmVlbiBkb25lIGFscmVhZHkg dG93YXJkcyBzb2x2aW5nICBzb21lIG9mIHRoZXNlIHByb2JsZW1zLg0KPlNpbmNlIGl0IHdhcyBt ZW50aW9uZWQgaW4gdGhpcyBCT0YgdGhhdCB3ZSBzaG91bGQgZm9jdXMgb24gdGhlIHRyYW5zcG9y dCBsYXllciBhbmQgbm90IHNvIG11Y2ggdGhlIGFwcGxpY2F0aW9uIGxheWVyLCBJIHRoaW5rIHRo YXQgYnVpbGRpbmcgb24gdG9wIG9mIHdvcmsgbGlrZSB0aGlzIGNvdWxkIGJlIHF1aXRlIGFwcHJv cHJpYXRlLg0KPg0KPkkgY2hlY2tlZCB0aGUgdGhyZWFkIGFuZCB0aGVyZSB3YXNuJ3QgYW55IG1l bnRpb24gb2YgQ2FtbGlzdG9yZSBzbyBob3BlZnVsbHkgdGhpcyBpcyBoZWxwZnVsIGluZm9ybWF0 aW9uIGZvciBwZW9wbGUgaGVyZS4NCj5JZiBub3QsIEkgYXBvbG9naXplIGZvciB0aGUgZGlzdHJh Y3Rpb24gOikuDQo+DQo+RGF2aWQNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPlN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPlN0b3JhZ2VzeW5jQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3lu Yw== From nobody Wed Dec 30 00:55:46 2015 Return-Path: X-Original-To: storagesync@ietfa.amsl.com Delivered-To: storagesync@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5E91A1AFB for ; Wed, 30 Dec 2015 00:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.989 X-Spam-Level: * X-Spam-Status: No, score=1.989 tagged_above=-999 required=5 tests=[BAYES_60=1.5, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMypsd94RY9M for ; Wed, 30 Dec 2015 00:55:44 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id C369B1A1AF6 for ; Wed, 30 Dec 2015 00:55:43 -0800 (PST) Received: from CNNIC-PC (unknown [218.241.103.142]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QDgHnINWRC4nCQ--.30947S2; Wed, 30 Dec 2015 16:55:36 +0800 (CST) Date: Wed, 30 Dec 2015 16:55:19 +0800 From: "qinxiaowei@cnnic.cn" To: storagesync X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015123016551968347627@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart117381802641_=----" X-CM-TRANSID: AQAAf0A5QDgHnINWRC4nCQ--.30947S2 X-Coremail-Antispam: 1UD129KBjvJXoWrur43tw1UCr47Zw4fCr1ftFb_yoW8Jr1rpr 13Jr17JF1DJ345Xr1UXw4xWrWUJF1xKw47XF18Jr18Jrn8ZF10gF17trWrAr9rJryUtw1j qr4Yqa45AF4UJaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmCb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kEwI0E Y4vaYxAvb48xMc02F40Ex2IqxVA2YxCjr7Iv64kEw24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr 4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxG rwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1l7480Y4vEI4kI2Ix0rV Aqx4xJMxkIecxEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8 JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1V AFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcV C2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF 0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jxJ5wUUUUU= X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: Re: [Storagesync] recent issues discussed (plain text) X-BeenThere: storagesync@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 08:55:46 -0000 This is a multi-part message in MIME format. ------=_001_NextPart117381802641_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 DQpoaaOsDQpFbmQgdXNlcnMgbWF5IGJlIG1vcmUgY29uY2VybmVkIGFib3V0IHRoZSBpbXByb3Zl bWVudCBvZiB0aGUgdXBsb2FkIHJhdGUuIEFjY29yZGluZyB0byB0aGUgcmVwb3J0IGluImh0dHA6 Ly90ZXN0bXlpcGhvbmUuY29tIiwgIHRoZSBhdmVyYWdlIGRvd25zdHJlYW0gdGhyb3VnaHB1dCBp cyBtb3JlIHRoYW4gNDQ5MCBLYnBzLCB0aGUgYXZlcmFnZSB1cHN0cmVhbSB0aHJvdWdocHV0IGlz IG9ubHkgYWJvdXQgODY5IEticHMuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24uIFBs ZWFzZSBlbWFpbCBtZSBpZiBhbnl0aGluZyBpcyBtaXNzZWQ6CjEuVGhlIGRlc2lnbiB0YXJnZXRz IG9mIFdlYkRBViwgcnN5bmMgYW5kIG90aGVyIGV4aXN0aW5nIGFwcHJvYWNoZXM/CjIuVGhlIHBv dGVudGlhbCB1c2UgY2FzZXMgb2YgSVNTLCBzdWNoIGFzIGNsaWVudC9zZXJ2ZXIsIGdpdC1saWtl IHBhdHRlcm4sIHN2biwgZXRjLgozLlRoZSBlZmZpY2llbmN5IGltcHJvdmVtZW50cyBtaWdodCBi ZSB0aGUgc2Vjb25kIGdvYWwgZm9yIHN0YW5kYXJkaXppbmcgSVNTIHByb3RvY29sCjQuQ09SUyBo ZWFkZXJzIG9uIHN0b3JhZ2Ugc3luYyBBUElzCjUuV2hhdCBpcyBuZWVkZWQgZm9yIHRoZSBJU1M6 IGEgc3luYyBwcm90b2NvbCBvciBhIGdlbmVyYWxpemVkIEFQSQo2LnJlbW90ZVN0b3JhZ2UgZHJh ZnQgZGlzY3Vzc2lvbgogIGEpcmVsYXRpb25zaGlwIHZzIFdlYkRBVgogIGIpTU9WRSBhY3Rpb24g KHN5bmNocm9uaXphdGlvbikgc2hvdWxkIGJlIGFkZGVkIG9yIG5vdAogIGMpQmVzaWRlIHdlYiBi cm93c2VyLCBkZXNrdG9wIGFwcHMgKGJ5IGhhY2tpbmcgd2F5KQogIGQpY29taWNzIG9mIG5ldyBz dGFuZGFyZAogIGUpZXRhZyBpc3N1ZXMgdnMgbWV0YWRhdGEKICAgIGkuaXMgbWFpbmx5IGZvciBp ZGVudGlmeWluZyB3aGV0aGVyIGEgZG9jdW1lbnQgaXMgY2hhbmdlZCBvciBub3QKICAgIGlpLmlz IGVhc3kgdG8gaW1wbGVtZW50IHRoYW4gdGhhdCBvZiBXZWJEQVYgc3luYyBwcm90b2NvbCBvciBu b3QKICAgIGlpaS50aGUgbWV0YWRhdGEgZmlsZSBjb250YWlucyBhbGwgZXRhZ3MgZm9yIGFsbCBm aWxlcyBhdCBib3RoIGNsaWVudCBhbmQgc2VydmVyIHNpZGUgb3Igbm90CiAgZil0aGUgZGlzdHJp YnV0ZWQgcGVlciBtb2RlbCAobm8gc2VydmVyKSBhbmQgQy9TIG1vZGUKICBnKWEgZmFuY3kgZXhh bXBsZSAod2l0aCBwaWNzKSBvZiBPZmZsaW5lSU1BUKGvcyBzeW5jIHByb2Nlc3MgaW4gZm9sbG93 aW5nIFVSTAoNCg0KDQoNCg== ------=_001_NextPart117381802641_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A

hi=A3=AC
<= div>End users may be more concerned about the improvement of the upload ra= te. According to the report in"http:/= /testmyiphone.com",  the average downstream throughput is more than = ;4490 Kbps, the average upstream throughput is only about 869 Kbps.


------= --------------------------------------------------------------------------= --------------------------------
Here is=
 the latest version. Please email me if anything is missed:=0A1.The design=
 targets of WebDAV, rsync and other existing approaches?=0A2.The potential=
 use cases of ISS, such as client/server, git-like pattern, svn, etc.=0A3.=
The efficiency improvements might be the second goal for standardizing ISS=
 protocol=0A4.CORS headers on storage sync APIs=0A5.What is needed for the=
 ISS: a sync protocol or a generalized API=0A6.remoteStorage draft discuss=
ion=0A  a)relationship vs WebDAV=0A  b)MOVE action (synchronization) shoul=
d be added or not=0A  c)Beside web browser, desktop apps (by hacking way)=
=0A  d)comics of new standard=0A  e)etag issues vs metadata=0A    i.is mai=
nly for identifying whether a document is changed or not=0A    ii.is easy =
to implement than that of WebDAV sync protocol or not=0A    iii.the metada=
ta file contains all etags for all files at both client and server side or=
 not=0A  f)the distributed peer model (no server) and C/S mode=0A  g)a fan=
cy example (with pics) of OfflineIMAP=A1=AFs sync process in following URL=
=0A
=0A

=0A
<= /span>
=0A ------=_001_NextPart117381802641_=------