From nobody Tue Nov 3 02:58: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 32BAF1B31E4 for ; Tue, 3 Nov 2015 02:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 6TqihdGkHwIQ for ; Tue, 3 Nov 2015 02:58:34 -0800 (PST) Received: from CERNMX11.cern.ch (cernmx11.cern.ch [188.184.36.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6F71B31CD for ; Tue, 3 Nov 2015 02:58:33 -0800 (PST) Received: from CERNFE24.cern.ch (137.138.203.202) by cernmxgwlb4.cern.ch (188.184.36.50) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Nov 2015 11:58:32 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE24.cern.ch ([fe80::6986:e87f:d6e9:b372%10]) with mapi id 14.03.0174.001; Tue, 3 Nov 2015 11:58:31 +0100 From: Jakub Moscicki To: "storagesync@ietf.org" Thread-Topic: [Storagesync] New version of "Internet Storage Sync: Problem Statement" Thread-Index: AQHQ/ElawS0t4zazrUyb6hnAwYsk5p6KQ88A Date: Tue, 3 Nov 2015 10:58:30 +0000 Message-ID: <8D38187A-3353-4D90-B2A5-E3EDA14096D4@cern.ch> References: <850CEC66-9592-4BF4-8B92-8297CE3050B4@tsinghua.edu.cn> In-Reply-To: <850CEC66-9592-4BF4-8B92-8297CE3050B4@tsinghua.edu.cn> 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: multipart/alternative; boundary="_000_8D38187A33534D90B2A5E3EDA14096D4cernch_" MIME-Version: 1.0 Archived-At: Cc: Peter Szegedi , Massimo Lamanna Subject: Re: [Storagesync] New version of "Internet Storage Sync: Problem Statement" 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, 03 Nov 2015 10:58:41 -0000 --_000_8D38187A33534D90B2A5E3EDA14096D4cernch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Here at CERN we are part of a GEANT community where sites deploy mostly own= Cloud but also Seafile and Powerfolder. So interoperability and vendor-neut= ral protocols and standards are of concern and interest. It seems that there are currently several research projects and initiatives= running concurrently both in area of synchronization as well as sharing in= IETF and GEANT research centers. I know of at least two research projects = in our community to improve Webdav-based synchronization protocol. There is= also the OpenCloudMesh initiative that recently came as a vendor proposal = for interoperable sharing. I would like to propose Interoperability for Synchronization and Sharing as= one of the topics of the upcoming CS3 Workshop in ETH Zurich in January 20= 16 (please see: http://cs3.ethz.ch/). The first edition of this vendor-neutral workshop was held at CERN last yea= r and industry was represented by ownCloud, Seafile, Powerfolder and PyDio.= Please consult the past programme here: https://indico.cern.ch/event/33675= 3/timetable/#all.detailed Besides the foundation technology for sync/share the scope of the workshop = also covers practical innovative applications with sync/share and academic = research on the subject. So feel free to forward this pointer to other coll= eagues who might be interested in presenting this topic or to present their= results. Please note that the abstract submission for the CS3 Workshop is = due soon. Best regards, Jakub Moscicki, CERN IT/DSS -- On 01 Oct 2015, at 15:01, Yong Cui > wrote: Dear all, We've updated the draft, Internet Storage Sync: Problem Statement. https://datatracker.ietf.org/doc/draft-cui-iss-problem/ Abstract: Internet storage services have become more and more popular. They attract a huge number of users and produce a significant share of Internet traffic. Most existing Internet storage services make use of proprietary sync protocols with different capabilities to achieve the data sync. However, a single Internet storage service using its proprietary sync protocols has intrinsic limitations on service usability and network performance. This document outlines the related problems caused by using proprietary sync protocols and missing key capabilities. It also shows a demand for designing a standard sync protocol to achieve better usability and sync performance. Compared to the earlier versions, this version emphasizes the very different protocol capabilities that different commercial services support, and also the understanding of sync protocol. You are welcome to comment! Thanks, Yong _______________________________________________ Storagesync mailing list Storagesync@ietf.org https://www.ietf.org/mailman/listinfo/storagesync --_000_8D38187A33534D90B2A5E3EDA14096D4cernch_ Content-Type: text/html; charset="us-ascii" Content-ID: <16168F781E395B4B8D59DD86AC9B90DE@cern.ch> Content-Transfer-Encoding: quoted-printable Hello,

Here at CERN we are part of a GEANT community where sites d= eploy mostly ownCloud but also Seafile and Powerfolder. So interoperability= and vendor-neutral protocols and standards are of concern and interest.

It seems that there are currently several research projects= and initiatives running concurrently both in area of synchronization as we= ll as sharing in IETF and GEANT research centers. I know of at least two re= search projects in our community to improve Webdav-based synchronization protocol. There is also the OpenCloud= Mesh initiative that recently came as a vendor proposal for interoperable s= haring.

I would like to propose Interoperability for Synchronizatio= n and Sharing as one of the topics of the upcoming CS3 Workshop in ETH Zuri= ch in January 2016 (please see: http://cs3.ethz.ch/).
The first edition of this vendor-neutral workshop was held = at CERN last year and industry was represented by ownCloud, Seafile, Powerf= older and PyDio. Please consult the past programme here: https= ://indico.cern.ch/event/336753/timetable/#all.detailed

Besides the foundation technology for sync/share the scope = of the workshop also covers practical innovative applications with sync/sha= re and academic research on the subject. So feel free to forward this point= er to other colleagues who might be interested in presenting this topic or to present their results. Please no= te that the abstract submission for the CS3 Workshop is due soon.

Best regards,

Jakub Moscicki, CERN IT/DSS

--

On 01 Oct 2015, at 15:01, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:
Dear all,

We've updated the draft, Internet Storage Sync: Problem Statement.

https://datatracker.ietf.org/doc/draft-cui-iss-problem/


Abstract:
  Internet storage services have become more and more popular. &n= bsp;They
  attract a huge number of users and produce a significant share = of
  Internet traffic.  Most existing Internet storage services= make use
  of proprietary sync protocols with different capabilities to ac= hieve
  the data sync.  However, a single Internet storage service= using its
  proprietary sync protocols has intrinsic limitations on service=
  usability and network performance.  This document outlines= the
  related problems caused by using proprietary sync protocols and=
  missing key capabilities.  It also shows a demand for desi= gning a
  standard sync protocol to achieve better usability and sync
  performance.

Compared to the earlier versions, this version emphasizes the very
different protocol capabilities that different commercial services
support, and also the understanding of sync protocol.

You are welcome to comment!

Thanks,

Yong

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

--_000_8D38187A33534D90B2A5E3EDA14096D4cernch_-- From nobody Tue Nov 3 04:53: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 A4C231B2F94 for ; Tue, 3 Nov 2015 00:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 P3OXmpyltC0Z for ; Tue, 3 Nov 2015 00:19:49 -0800 (PST) Received: from smtp.mrt.ac.lk (smtp.mrt.ac.lk [192.248.8.101]) by ietfa.amsl.com (Postfix) with ESMTP id ACBBE1B2FA7 for ; Tue, 3 Nov 2015 00:19:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.mrt.ac.lk (Postfix) with ESMTP id 744F2242451 for ; Tue, 3 Nov 2015 13:49:34 +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 OK0VNsqTddZJ for ; Tue, 3 Nov 2015 13:49:34 +0530 (IST) Received-SPF: pass (uom.lk: 192.248.8.107 is authorized to use 'gihan@uom.lk' in 'mfrom' identity (mechanism 'a:submit.uom.lk' matched)) receiver=smtp.mrt.ac.lk; identity=mailfrom; envelope-from="gihan@uom.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 F2BE62423C9 for ; Tue, 3 Nov 2015 13:49:30 +0530 (IST) Received: from [133.93.25.193] (dhcp-25-193.meeting.ietf94.jp [133.93.25.193]) (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 9EBE65FD6D for ; Tue, 3 Nov 2015 13:49:29 +0530 (IST) To: Storagesync@ietf.org From: Gihan Dias Message-ID: <56386DD7.5050802@uom.lk> Date: Tue, 3 Nov 2015 17:18:31 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 04:53:03 -0800 Subject: [Storagesync] happy to join the list 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, 03 Nov 2015 08:19:56 -0000 Hello All, This is Gihan Dias from University of Moratuwa, Sri Lanka. We have been working in this area for the past 4 years, and am glad to join the list. Hope that we can work together to develop this area. Gihan From nobody Tue Nov 3 13:09: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 B7A961A89C6 for ; Tue, 3 Nov 2015 13:09:25 -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, 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 gsHBGPbtxkM2 for ; Tue, 3 Nov 2015 13:09:23 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id D17171A89B3 for ; Tue, 3 Nov 2015 13:09:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6CA392CC5D for ; Tue, 3 Nov 2015 23:09:21 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfgQUN8mlwI8 for ; Tue, 3 Nov 2015 23:09:20 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id E57D12CC52 for ; Tue, 3 Nov 2015 23:09:19 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko X-Pgp-Agent: GPGMail 2.5.1 Content-Type: multipart/signed; boundary="Apple-Mail=_1F0B5752-C576-4CC0-BBCA-1CF81C464B46"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 4 Nov 2015 06:09:36 +0900 Message-Id: To: storagesync@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Storagesync] thoughts on the BOF and way forward 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, 03 Nov 2015 21:09:25 -0000 --Apple-Mail=_1F0B5752-C576-4CC0-BBCA-1CF81C464B46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I attended the BOF, and have followed the topic somewhat in previous months. I wanted to offer some thoughts after the BOF ended. The BOF focused on the right questions, and the discussion was spot on. I concur with many of the points made about what is important. =46rom my personal perspective, improvements in efficiency are interesting, but they are sort of secondary to the question of whether we should standardise something. In any case, updates of existing solutions happen fairly easily if the party in question realises they need and can improve efficiency. I also tend to think that extreme efficiency was never a key factor in any successful Internet technology deployment. Speed of deployment, flexibility, value for user, common market for something, and so on are far bigger issues. Functionality, e.g., ability to compose and move structured datasets and not just files, or ability to do multi-party synchronisation are definitely more interesting than pure efficiency, and perhaps that is something that can be considered. But even those are still somewhat secondary. What is really important in this case is the ability or desire to interoperate. That is the key question, i.e., do we want that, for some sufficiently interesting value of =93we=94. Quite rightly, the BOF asked whether there are folks who are interested in taking this on and deploying. At least some existing large storage vendors said that they have no interest. Understandably, the feeling in the room was pessimistic after that. But we have to be careful here. First off, this space is big, and the consumer-visible large-scale storage services are not the only important ones. Private clouds, enterprise markets, Internet of Things, secure storage services, etc. are also potentially interesting. Secondly, it has never been the case that everybody agrees we should develop new technology and that we all commit to using it once it is ready. Even if we had just one market, you may not be able to get the biggest players to commit or even take a positive view. Thirdly, there are often folks who are not in a position to say anything publicly, and trying to gauge a bit behind the scenes what the silent folks think might be useful. I don=92t think there=92s a requirement in this case (or in general) that you need buy-in from a large number of folks to use something. What you do need is _some_ folks who are interested and in a position to drive something that they would benefit from. Whether that something succeeds for them, and whether it eventually grows to something that a bigger set of people are interested in are questions for the future. I think setting the bar too high would be a mistake. I would also observe that vendors are not the only ones specifying what solutions should be. We often have a situation where users/customers want standards that they want to place in their RFPs so that they can create a more competitive environment for the services that they need. I certainly feel that this situation exists in this case from an enterprise user perspective, for instance. In short, I think what this effort needs is _some_ set of folks who are driving this from a business need. I see the researchers being interested; I see folks like Jakub from CERN interested; I see individual users like Ted interested. We definitely need some more for the work to be sensible, but I don=92t think we necessarily need the most visible brand names from the consumer market to go ahead. Jari --Apple-Mail=_1F0B5752-C576-4CC0-BBCA-1CF81C464B46 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWOSKRAAoJEM80gCTQU46qUcoQAKStTdyCFFg/aEa3gyaQaNkO jMkSvqNX/RB//dGiEBU/aqKaCzfime67BdKQIZcLpc2fKyeGwyIz1CG7RNtOBODe inAL7m8Ex7gLUuuc52TjTMjLhQc5NtCLrh/uSzJHhqw131R6Xvfk7pGrQ8fEGuzG lBrHUI9Qq/LyANQMzsvBkXYVVdVrsY8Wj31BfCvDxI+9x/EgWYPorIsCaQu32izO Ucv43LackrelHfa3FUVxb6yeaFGyLe23L6Rbk65rFjvSa/QSkyJQIW2qw3J5LTCO Tl5FpCqZ+Ql6DVmsdIclXWI1GPlnFu3AUMtEpspE2DTTyBQoEOBXuWJgATc0oE7f ZSzelyWTJ3wMYhlNAH6QbjDYdsNf9jYOy1yM6vZwV9zbiv3F9PyomnLl4aow0VD/ w3irN7p0WdMOR7yYXVJKuAgBe0q2aUlF9+OxewdCa4NY1WFlwu+4DlS2mwh7G1FZ 7NCPIdFOi8WcHssbRvLLhJvl4qQ7RAx4kOLmiIB6hSPu0LohxOOFvn4z+KUlc2ey Gne1oh9Es7kpFTol8tHKpxqi3ABRpfbBZgqJbGOu3uDXJdKum0v/le6o0uAt5uYS rtGdNJVOtle6+JBtN56iBobWfMogFAML7eCTPjfgX5nyT1//u9hPp+RufjlMUA6D lEf6mW1TNvzxbGtkZ89y =nRMV -----END PGP SIGNATURE----- --Apple-Mail=_1F0B5752-C576-4CC0-BBCA-1CF81C464B46-- From nobody Tue Nov 3 15:36: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 0DBE71B3615 for ; Tue, 3 Nov 2015 15:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.587 X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 UMEFhfqSDHjj for ; Tue, 3 Nov 2015 15:36:20 -0800 (PST) Received: from tsinghua.edu.cn (smtp08.tsinghua.edu.cn [166.111.204.37]) by ietfa.amsl.com (Postfix) with ESMTP id B9F391B3613 for ; Tue, 3 Nov 2015 15:36:19 -0800 (PST) Received: from dhcp-84-224.meeting.ietf94.jp (unknown [133.93.84.224]) by app6 (Coremail) with SMTP id D8xvpgDXizruRDlWKC9dAQ--.35469S3; Wed, 04 Nov 2015 07:36:16 +0800 (CST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Yong Cui In-Reply-To: Date: Wed, 4 Nov 2015 07:36:14 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1D1FD081-DB6B-49A2-A0C8-E09C78578905@tsinghua.edu.cn> References: To: Jari Arkko X-Mailer: Apple Mail (2.1508) X-CM-TRANSID: D8xvpgDXizruRDlWKC9dAQ--.35469S3 X-Coremail-Antispam: 1UD129KBjvJXoW7WFWDAw13CF43GryrCw18AFb_yoW8ury8pr W5KrZ8tFs8AFW0y348Jw40qFyfJrWrAr43AF98Gr4UAF45CFyagrZrtF4F9FZ3urs7WryY vr4jq3Z8Z3Z5ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUdab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_GcCE 3s1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s 1lnx0E84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_GcCE3s0E84ACjcxK6xIIjxv20xvE14v2 6w1j6s0q6x02cVCv0xWlnx0E84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_GcCE3s0E84ACjc xK6I8E87Iv67AKxVW0oVCq3VCjxxvEa2IrM2vj628EF7xvwVC0I7IYx2IY6xkF7I0E14v2 6rxl6s0q6x02cVCv0xWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I 8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCF s4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vEOx0_uwCF04k20xvY0x0EwI xGrwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF 1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6x IIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF 0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2Kf nxnUUI43ZEXa7xUUeRxUUUUUU== X-CM-SenderInfo: 5fxl50tqj632xlqjx3vdohv3gofq/ Archived-At: Cc: storagesync@ietf.org Subject: Re: [Storagesync] thoughts on the BOF and way forward 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, 03 Nov 2015 23:36:22 -0000 Please see in lines. > I also tend to think that extreme efficiency was never a key > factor in any successful Internet technology deployment. Speed of > deployment, flexibility, value for user, common market for something, > and so on are far bigger issues. I totally agree with you that the speed of deployment, flexibility, = value=20 for user and interoperability are much more important than the = performance=20 efficiency. > But we have to be careful here. First off, this space > is big, and the consumer-visible large-scale storage > services are not the only important ones. Private > clouds, enterprise markets, Internet of Things, > secure storage services, etc. are also potentially > interesting. That's the key here! We use more and more Google Doc rather than local Office software, where = Google Doc leverages Google Drive. There're also a lot of cloud-based = softwares on photo processing, document processing or even enterprise = softwares recently. So I think maybe in the future, the softwares you = use everyday could be installed in the cloud rather than on your client = PCs or smart phones. In that case, ISS service could be an important = platform.=20 > In short, I think what this effort needs is _some_ > set of folks who are driving this from a business > need. I see the researchers being interested; I > see folks like Jakub from CERN interested; I see > individual users like Ted interested. We > definitely need some more for the work to be > sensible, but I don=92t think we necessarily need > the most visible brand names from the consumer > market to go ahead. In addition to the scenario of enterprise/private ISS service, I see = most of the people personally like to see the interoperability between = the ISS services, while the third party app developers also hope to have = the standard. these are the customers of ISS service. If the costumers = are big/important enough, then vendors would like to think about this = issue or even implement the standard. Standard protocols here could = lower the entrance bar of third party apps over the ISS services. Cheers, Yong From nobody Thu Nov 5 20:50: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 85A191B3567 for ; Thu, 5 Nov 2015 20:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DATE_IN_PAST_12_24=1.049, 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 p4DmHrLYkARM for ; Thu, 5 Nov 2015 20:50:42 -0800 (PST) Received: from smtp.mrt.ac.lk (smtp.mrt.ac.lk [192.248.8.101]) by ietfa.amsl.com (Postfix) with ESMTP id C5E271B3563 for ; Thu, 5 Nov 2015 20:50:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.mrt.ac.lk (Postfix) with ESMTP id 4C77024235A for ; Fri, 6 Nov 2015 10:20:40 +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 ciWuz1ZFZ-HJ for ; Fri, 6 Nov 2015 10:20:39 +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 1A5942424D4 for ; Fri, 6 Nov 2015 10:20:37 +0530 (IST) Received: from [10.216.241.170] (unknown [175.157.12.208]) (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 A06E45FD62 for ; Fri, 6 Nov 2015 10:20:37 +0530 (IST) To: storagesync@ietf.org References: From: Gihan Dias Organization: University of Moratuwa Message-ID: <563AF9ED.5030507@cse.mrt.ac.lk> Date: Thu, 5 Nov 2015 15:40:45 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Storagesync] thoughts on the BOF and way forward 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, 06 Nov 2015 04:50:44 -0000 On 15/11/04 6:09 AM, Jari Arkko wrote: > I attended the BOF, and have followed the topic somewhat in previous months. I wanted to offer some thoughts after the BOF ended. Jari, Thanks. I agree with you. This is a new space, and though we think there is something we need to do, we don't yet know quite what. I think we should not focus on individual files, but entire file systems, and structured datasets. We should also consider not just two-party sync, but synchronising between multiple devices and clouds. However, to begin we may focus on a smaller problem. I suggest we first focus on agreeing on the system model, to ensure we are all talking about the same thing. As for technology and protocols, there are many papers - and some implementations - out there, so we don't have to do a lot of new research just select a good technology and implement it. Regards, Gihan From nobody Mon Nov 9 03: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 5BF4C1ACE84 for ; Mon, 9 Nov 2015 03:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 yca8v89RULAm for ; Mon, 9 Nov 2015 03:06:12 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 406051ACE96 for ; Mon, 9 Nov 2015 03:06:12 -0800 (PST) Received: by wicli17 with SMTP id li17so13060650wic.1 for ; Mon, 09 Nov 2015 03:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla_com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=kSxmVhfFzLeWKDZIiW/3fjY7OAChEfTbs9yMS5LvS0I=; b=hcEPqGbdbhbjwWlyWQb11c43Z0+89VQphHMXE1GH+UvcNkkQ3VTgT5fvV3cl0q8lhG KxIbXwLvkuz7m6DfL5PYBrtLU+HwGXLQ9nck6OEXA47kxPdyONbbikDLwAjJ0fCRvI/X bZKY2S/vK311gOY2AJ53wucSkD5t3sovfYlCwbkJlervZHBvXfAH+TPAC9W/u0oMkvGV OwOxcgVyROyQUyd0WVE2uh50SipmX9kyRIviNXSz/LjYxW0hybw43eU2jWb4q45ra44L +xdjDsmywJf9IBVr774Phykeuz8YAlCagPiWB6PFs+UH7ev3VAvd0Sp4+K+QH/Odggpp srDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=kSxmVhfFzLeWKDZIiW/3fjY7OAChEfTbs9yMS5LvS0I=; b=F5SxtoLymcriZauWxrFsoVvWOsv8NtqOSK3IIx1+002E2d07Pcamlm/HX2D6PFv0tV KG6xkJj9ShOzZMw97LlKQfgSHiSgZuL48f5pQ3/mns9gILt5415BHi8uPVLUIec0RKLq hnjTqM3j1CzBWKtLLg0CJqOswHtRda5D5B/C9/vu3tdOPThFsZNmUa6yjPFFak8n3VOW CNDkPZwVdrg4v8d0hMvCXfdpFFW4k1+fw4wQtpFB29GVCjfNM7HKMH84kf3uTV4y/d18 T0+yf+tozkzz7vtD686nD5WxpvO2qLawir/4doExjwGWWrsVgAAP1800chMTEllvRQf1 LIAw== X-Gm-Message-State: ALoCoQlkUEi4AHg2AR0TUK3h+MY0OG9Qkpk7ZHn1ZWq+VqJ8M4poGJ4C29NemF/i1VHtmxHe/Vwk MIME-Version: 1.0 X-Received: by 10.194.175.164 with SMTP id cb4mr29815719wjc.72.1447067170733; Mon, 09 Nov 2015 03:06:10 -0800 (PST) Received: by 10.194.151.230 with HTTP; Mon, 9 Nov 2015 03:06:10 -0800 (PST) Date: Mon, 9 Nov 2015 12:06:10 +0100 Message-ID: From: Michiel de Jong To: storagesync@ietf.org Content-Type: multipart/alternative; boundary=089e013d1f90ad9e2f0524199487 Archived-At: X-Mailman-Approved-At: Mon, 09 Nov 2015 03:07:24 -0800 Subject: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 09 Nov 2015 11:06:19 -0000 --089e013d1f90ad9e2f0524199487 Content-Type: text/plain; charset=UTF-8 Hi! I wanted to draw your attention to the situation where a web app, rather than an OS-native app, wants to sync data with a user's storage. In this case, it's necessary that the API of the storage server be served with CORS headers. [1] The following storage sync APIs already do this: * Dropbox * Google Drive (including YouTube) * Kinto (a Mozilla project) [2] * remoteStorage (an IETF I-D of which I'm a contributor) [3] * Hoodie http://hood.ie/ I work on data sync for Firefox OS [4] - a mobile OS where every application is a client-side web app, so CORS headers are important there. [1] http://enable-cors.org/ [2] http://kinto.readthedocs.org/en/latest/ [3] https://remotestorage.io/ [4] https://wiki.mozilla.org/Firefox_OS_Data_Sync Cheers, Michiel. --089e013d1f90ad9e2f0524199487 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

I wanted to draw your atten= tion to the situation where a web app, rather than an OS-native app, wants = to sync data with a user's storage.

In this case, it's= necessary that the API of the storage server be served with CORS headers. = [1] The following storage sync APIs already do this:

* Dropbox=
* Google Drive (including YouTube)
* Kinto (a Mozilla pr= oject) [2]
* remoteStorage (an IETF I-D of which I'm a contrib= utor) [3]
* Hoodie h= ttp://hood.ie/

I work on data sync for Firefox OS [4]= - a mobile OS where every application is a client-side web app, so CORS he= aders are important there.

[1] http://enable-cors.org/
Cheers,
Michiel.

--089e013d1f90ad9e2f0524199487-- From nobody Mon Nov 9 04:38: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 62D8D1B7C63 for ; Mon, 9 Nov 2015 04:38:03 -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 AkBTqojnBAki for ; Mon, 9 Nov 2015 04:38:01 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 82BA41B7C66 for ; Mon, 9 Nov 2015 04:38:01 -0800 (PST) Received: by wmec201 with SMTP id c201so76688315wme.0 for ; Mon, 09 Nov 2015 04:38:00 -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=FHZ6enDA4nxXePxagDmsWv9u002peeBjAm7auSR2qwc=; b=rO8F1ZB0iSPV7JzHIJzsGXHZUa7r5MKseujTI7LaQG7gJVO0j+6PJkkH7Xrx33ahFQ 0Ss0pDB+4LkGim9llW99yP6MixbJQaCAj7YmqsUuJctFbhA3AZYDW5CCpX9JoQCJqAWi VJgevTeN6pSa8ffH/YqLDogd1VVatn/TM5DG9IsP8/ywSGxx7ZlJJioUUM0H03FA+LCu +GILyn+5FHd46Vd0A5qMcSA8KdSnCsu37lugCIAuqq2Jnb62sswHrqWoMeG03v4Bn3pO plTyrvztn27yYqRrq0bArT9gk+Jfmg93k/OQrHIo6AuerzUony2yi66Ad3g3KzkjTU9a 6P+A== X-Received: by 10.194.78.15 with SMTP id x15mr33106071wjw.144.1447072680019; Mon, 09 Nov 2015 04:38:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.173.15 with HTTP; Mon, 9 Nov 2015 04:37:40 -0800 (PST) In-Reply-To: References: From: Linhui Sun Date: Mon, 9 Nov 2015 20:37:40 +0800 Message-ID: To: Michiel de Jong Content-Type: multipart/alternative; boundary=047d7bfcfd7a0e8cdf05241addab Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 09 Nov 2015 12:38:03 -0000 --047d7bfcfd7a0e8cdf05241addab Content-Type: text/plain; charset=UTF-8 2015-11-09 19:06 GMT+08:00 Michiel de Jong : > Hi! > > I wanted to draw your attention to the situation where a web app, rather > than an OS-native app, wants to sync data with a user's storage. > > In this case, it's necessary that the API of the storage server be served > with CORS headers. [1] The following storage sync APIs already do this: > > * Dropbox > * Google Drive (including YouTube) > * Kinto (a Mozilla project) [2] > * remoteStorage (an IETF I-D of which I'm a contributor) [3] > * Hoodie http://hood.ie/ > > I work on data sync for Firefox OS [4] - a mobile OS where every > application is a client-side web app, so CORS headers are important there. > I think we should also consider the sync among a web app, a native app and user's storage since we cannot force users to use a web app or a native app. However this should be discussed in the scope of the ISS work. > > [1] http://enable-cors.org/ > [2] http://kinto.readthedocs.org/en/latest/ > [3] https://remotestorage.io/ > [4] https://wiki.mozilla.org/Firefox_OS_Data_Sync > > Cheers, > Michiel. > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > Regards, Linhui --047d7bfcfd7a0e8cdf05241addab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -11-09 19:06 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>:
Hi!

I= wanted to draw your attention to the situation where a web app, rather tha= n an OS-native app, wants to sync data with a user's storage.

In this case, it's necessary that the API of the storage server be = served with CORS headers. [1] The following storage sync APIs already do th= is:

* Dropbox
* Google Drive (including YouTube)
<= /div>* Kinto (a Mozilla project) [2]
* remoteStorage (an IETF I-D = of which I'm a contributor) [3]
* Hoodie http://hood.ie/

I work on da= ta sync for Firefox OS [4] - a mobile OS where every application is a clien= t-side web app, so CORS headers are important there.=C2=A0
I think we should also consider the sync amo= ng a web app, a native app and user's storage since we cannot force use= rs to use a web app or a native app. However this should be discussed in th= e scope of the ISS work.=C2=A0

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

Regards,
Linhui
--047d7bfcfd7a0e8cdf05241addab-- From nobody Mon Nov 9 05:02: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 23FF31B2A74 for ; Mon, 9 Nov 2015 05:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 iYlBspAddU0p for ; Mon, 9 Nov 2015 05:02:40 -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 7CB171B2A73 for ; Mon, 9 Nov 2015 05:02:40 -0800 (PST) Received: by wmec201 with SMTP id c201so68653154wme.1 for ; Mon, 09 Nov 2015 05:02:39 -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=2rmvYEg3arSxxoJF+rrW3sPp0pWCvGZboGjgjGZhyXI=; b=v/Ml2PoQpy1fLKb9RWW4oxsGFy8rBFHeMxIXTdSdHZlreAV4vOFb40heo66lkkp738 mXejsWTUNE9YIvXzCD2tzSkuHXDC6lf8j1o079IDZHm0mNQU5pM1TUszOv34rICZ5r8M DmmBMBzwcrOKFTRQmo4szw/JreZkiWyeMMQn4T0d9y/CLCB81AmZeA7JjZLwLeEGOASg cMk8U3C9Bl2enOhBv/QhDBCWwVgEIpNs3a/ls+KyWPdOOSJ3eaZX6KbOJm85D8Z0bjpD fgmqv440pkGFjIJylC5MQ1ibjauhx4oFtHYK7JM6KFbdC9pACKjJrYzw8RHzvgOPYF06 AVlw== 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=2rmvYEg3arSxxoJF+rrW3sPp0pWCvGZboGjgjGZhyXI=; b=jl7vmO9yVzo6M++36YrXqDbs0pA4G7IRHSA1hLlcIkTr9Y8j9/4IywYSIlnreiWUMD K4NrBEZC3fuY4dQnPMSDIOOGyWB9dWeexwfbwUZP42bGFR+Fv3xMb2COY++12Wl0XatQ vt9HmJQY7dZCOLO8gmobWwcm513zuxWtSV+pj2bHkYuQlMiKytB0cu58TQpkTW5wrR/m p/5K1Q9IBKiFBiMmJWV0U6EjGuqi1TZStR4gd2tejOVBcpfCrJhkoMYLdGEkCzvyP8fk H33aVJk4NsKEe2mq2UCcfUtin+j0ZqgvIoH5FHZ7rGA0TukaqNowb8mbMJkrBkbPnw4X zu6Q== X-Gm-Message-State: ALoCoQnsfeF7IaMBlLEnLkktHwbKLwDh+jGXrbsVduZgKgvCn8NTjHPuooCBh2LSyR7EmhoZiORp MIME-Version: 1.0 X-Received: by 10.194.60.103 with SMTP id g7mr20007866wjr.73.1447074158998; Mon, 09 Nov 2015 05:02:38 -0800 (PST) Received: by 10.194.151.230 with HTTP; Mon, 9 Nov 2015 05:02:38 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Nov 2015 14:02:38 +0100 Message-ID: From: Michiel de Jong To: Linhui Sun Content-Type: multipart/alternative; boundary=047d7b86cfbc36143a05241b3533 Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 09 Nov 2015 13:02:43 -0000 --047d7b86cfbc36143a05241b3533 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun wrote: > 2015-11-09 19:06 GMT+08:00 Michiel de Jong : > >> Hi! >> >> I wanted to draw your attention to the situation where a web app, rather >> than an OS-native app, wants to sync data with a user's storage. >> >> In this case, it's necessary that the API of the storage server be served >> with CORS headers. [1] The following storage sync APIs already do this: >> >> * Dropbox >> * Google Drive (including YouTube) >> * Kinto (a Mozilla project) [2] >> * remoteStorage (an IETF I-D of which I'm a contributor) [3] >> * Hoodie http://hood.ie/ >> >> I work on data sync for Firefox OS [4] - a mobile OS where every >> application is a client-side web app, so CORS headers are important there. >> > I think we should also consider the sync among a web app, a native app and > user's storage since we cannot force users to use a web app or a native app. > ok, so then CORS headers are a must (otherwise you can only use OS-native apps). > However this should be discussed in the scope of the ISS work. > >> >> [1] http://enable-cors.org/ >> [2] http://kinto.readthedocs.org/en/latest/ >> [3] https://remotestorage.io/ >> [4] https://wiki.mozilla.org/Firefox_OS_Data_Sync >> >> Cheers, >> Michiel. >> >> >> _______________________________________________ >> Storagesync mailing list >> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/storagesync >> >> Regards, > Linhui > --047d7b86cfbc36143a05241b3533 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
2015-11-= 09 19:06 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>= :
Hi!

I wan= ted to draw your attention to the situation where a web app, rather than an= OS-native app, wants to sync data with a user's storage.

= In this case, it's necessary that the API of the storage server be serv= ed with CORS headers. [1] The following storage sync APIs already do this:<= br>
* Dropbox
* Google Drive (including YouTube)
* Kinto (a Mozilla project) [2]
* remoteStorage (an IETF I-D of w= hich I'm a contributor) [3]
* Hoodie http://hood.ie/

I work on data s= ync for Firefox OS [4] - a mobile OS where every application is a client-si= de web app, so CORS headers are important there.=C2=A0
I think we should also consider the sync = among a web app, a native app and user's storage since we cannot force = users to use a web app or a native app.

ok, so then CORS headers are a must (otherwise you can= only use OS-native apps).
=C2=A0
However this should be discussed in the scope of the ISS work.= =C2=A0

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

Regards,
Linhui

--047d7b86cfbc36143a05241b3533-- From nobody Tue Nov 10 02:54: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 BAC5E1A898C for ; Tue, 10 Nov 2015 02:54: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 xtE2bsXE1BST for ; Tue, 10 Nov 2015 02:54:39 -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 8F2E21A898B for ; Tue, 10 Nov 2015 02:54:39 -0800 (PST) Received: by wmec201 with SMTP id c201so127171628wme.0 for ; Tue, 10 Nov 2015 02:54:38 -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=cirVoAAc8+VKWMSWbH2WS/MyTUtA6pZvaVZQG0A6dqk=; b=lCgi5tffcvpiYqrmxm/EEbtHwzkp7D6OJd6uIX7jJvH1W+WyMXk8jZIE2MBphTb2YE Hn5jP0JcESqEHcuYtzc6CbN5WoGg9uuBzS55N+mnuJq5v3EqLW9yF4/kZ0tsUKj5YD66 Csw+wwZbi+YELCmDWRv7prANkVa6cm6dpbMZqLFlJZperq6dOYyjkaiI1ryGDUkpXwnb L+/sNf8BtfTZB+eEjhPoIMcFw67DqhB8AxDAT1aXZ9bXvCqJ/BEBjjVaH3Ex7MKuQU0m VNlkqE01o3iy5fDE2f20MbT7yo5xpQRSD32HF+BJOJQbc8fa7fABEYPKYVgzY1Nq+vda r4Xg== X-Received: by 10.28.87.21 with SMTP id l21mr4033467wmb.6.1447152878180; Tue, 10 Nov 2015 02:54:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.173.15 with HTTP; Tue, 10 Nov 2015 02:54:18 -0800 (PST) In-Reply-To: References: From: Linhui Sun Date: Tue, 10 Nov 2015 18:54:18 +0800 Message-ID: To: Michiel de Jong Content-Type: multipart/alternative; boundary=001a11444f223d617a05242d895b Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 10 Nov 2015 10:54:41 -0000 --001a11444f223d617a05242d895b Content-Type: text/plain; charset=UTF-8 2015-11-09 21:02 GMT+08:00 Michiel de Jong : > > > On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun wrote: > >> 2015-11-09 19:06 GMT+08:00 Michiel de Jong : >> >>> Hi! >>> >>> I wanted to draw your attention to the situation where a web app, rather >>> than an OS-native app, wants to sync data with a user's storage. >>> >>> In this case, it's necessary that the API of the storage server be >>> served with CORS headers. [1] The following storage sync APIs already do >>> this: >>> >>> * Dropbox >>> * Google Drive (including YouTube) >>> * Kinto (a Mozilla project) [2] >>> * remoteStorage (an IETF I-D of which I'm a contributor) [3] >>> * Hoodie http://hood.ie/ >>> >>> I work on data sync for Firefox OS [4] - a mobile OS where every >>> application is a client-side web app, so CORS headers are important there. >>> >> I think we should also consider the sync among a web app, a native app >> and user's storage since we cannot force users to use a web app or a native >> app. >> > > ok, so then CORS headers are a must (otherwise you can only use OS-native > apps). > Web sync is important when we have no access to our own laptops or computers. It may also play an important role in the mobile devices. But it is a frequently happened scenario that other devices or subscribers uses a native app. How would this (CORS header) work for native apps or a hybrid combination of native and web apps? IMO, the native apps also need the CORS header. Or not? Regards, Linhui --001a11444f223d617a05242d895b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-11-09 21:02 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>= ;:


On Mon, Nov 9, 2015 at 1:37 PM, Lin= hui Sun <lh.sunlinh@gmail.com> wrote:
2015-11-09 19:06 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com= >:
Hi!

=
I wanted to draw your attention to the situation where a web app, rat= her than an OS-native app, wants to sync data with a user's storage.
In this case, it's necessary that the API of the storage ser= ver be served with CORS headers. [1] The following storage sync APIs alread= y do this:

* Dropbox
* Google Drive (including YouTub= e)
* Kinto (a Mozilla project) [2]
* remoteStorage (an IE= TF I-D of which I'm a contributor) [3]
* Hoodie http://hood.ie/

I wor= k on data sync for Firefox OS [4] - a mobile OS where every application is = a client-side web app, so CORS headers are important there.=C2=A0
I think we should also conside= r the sync among a web app, a native app and user's storage since we ca= nnot force users to use a web app or a native app.
<= /blockquote>

ok, so then CORS headers are a must = (otherwise you can only use OS-native apps).
Web sync is important when we have no access to our own laptops = or computers. It may also play an important role in the mobile devices. But= it is a frequently happened scenario that other devices or subscribers use= s a native app. How would this (CORS header) work for native apps or a hybr= id combination of native and web apps? IMO, the native apps also need the C= ORS header. Or not?

Regards,
Linhui
--001a11444f223d617a05242d895b-- From nobody Tue Nov 10 03:55: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 6A44A1A88CE for ; Tue, 10 Nov 2015 03:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 mwHyhBNlAjfJ for ; Tue, 10 Nov 2015 03:55: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 C56A81A8A01 for ; Tue, 10 Nov 2015 03:55:17 -0800 (PST) Received: by wmec201 with SMTP id c201so129616239wme.0 for ; Tue, 10 Nov 2015 03:55:16 -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=oFNakE9sA0V650RPrSxQ4ErkFc6rsuvIRMhvR7fcddg=; b=Czvlm/514gfPgDfUse+5tlhzL6T2GWfPcs3lGQwwEqeh9Srj/dnjCICaqbqa7WL8jn hh6wNkaRG2GcAzk+HldoWol87sdS7xlA5Fz9snEdgEw/A5XWPB7CDcsxV02rAJGCSOS/ 4fToFKbF8vmuKtRNqsYyEg/8Ve2xYdm31Woy6NAHSW01BCMU1j0RTYiYhbnUG+2YKPSs DOqxlccb1OUNpwYj/Oazu2viiv9vSKSDrgLEnwfqj9wCNvA7IduONPQHe/CX2ROsFGKn ADzIeX32PpIgOwvqPH9QNZWlxAWoHJIuXurty2R3lnwkHwil00AD4NrS76Uw0HQVhTOk a0fg== 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=oFNakE9sA0V650RPrSxQ4ErkFc6rsuvIRMhvR7fcddg=; b=bewIaAqQOAVZcSTa1U0yINORSxyqMnzmWd4XNV+RVQgl65AIA8Gm53vL0jvzAiTNBE VQs3ZoxWCD6fhEBfMOmq4vN50QDi5ZHNoVMvMo/3m8bomOuZBqN5xU2eDNP9dZ8XwTnV zS4ZZg9/pb836FMwPziOve2Hdrcv9zE8dFm6LJMQ2ICK6Iv1xRWByguX2ldVX29T/2ZT 1MfL9uQhKHM/0SeUz8helCOuNp17Rov5v4OaD12qCxysmGnZjUXBFnaKflZ4lxdF0F3v IQRP4mN3OkK9rAvduihR06Nb0mTCvKabdojHIiKKG+ylCT3q79pziK/DugsTKcnovxz6 Slww== X-Gm-Message-State: ALoCoQnUy+7/+gRXcQiuZkCTjbxHSURxbNYK3lboKa9QYdps23JjG/Z+vxJvM8GDrC2KALlvIVwM MIME-Version: 1.0 X-Received: by 10.194.175.164 with SMTP id cb4mr3565994wjc.72.1447156515976; Tue, 10 Nov 2015 03:55:15 -0800 (PST) Received: by 10.194.151.230 with HTTP; Tue, 10 Nov 2015 03:55:15 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Nov 2015 12:55:15 +0100 Message-ID: From: Michiel de Jong To: Linhui Sun Content-Type: multipart/alternative; boundary=089e013d1f9011d70d05242e6212 Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 10 Nov 2015 11:55:20 -0000 --089e013d1f9011d70d05242e6212 Content-Type: text/plain; charset=UTF-8 No, for web apps CORS headers are necessary, but for native apps it doesn't make any difference if they are present or not. Cheers, Michiel. On Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun wrote: > > 2015-11-09 21:02 GMT+08:00 Michiel de Jong : > >> >> >> On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun wrote: >> >>> 2015-11-09 19:06 GMT+08:00 Michiel de Jong : >>> >>>> Hi! >>>> >>>> I wanted to draw your attention to the situation where a web app, >>>> rather than an OS-native app, wants to sync data with a user's storage. >>>> >>>> In this case, it's necessary that the API of the storage server be >>>> served with CORS headers. [1] The following storage sync APIs already do >>>> this: >>>> >>>> * Dropbox >>>> * Google Drive (including YouTube) >>>> * Kinto (a Mozilla project) [2] >>>> * remoteStorage (an IETF I-D of which I'm a contributor) [3] >>>> * Hoodie http://hood.ie/ >>>> >>>> I work on data sync for Firefox OS [4] - a mobile OS where every >>>> application is a client-side web app, so CORS headers are important there. >>>> >>> I think we should also consider the sync among a web app, a native app >>> and user's storage since we cannot force users to use a web app or a native >>> app. >>> >> >> ok, so then CORS headers are a must (otherwise you can only use OS-native >> apps). >> > Web sync is important when we have no access to our own laptops or > computers. It may also play an important role in the mobile devices. But it > is a frequently happened scenario that other devices or subscribers uses a > native app. How would this (CORS header) work for native apps or a hybrid > combination of native and web apps? IMO, the native apps also need the CORS > header. Or not? > > Regards, > Linhui > --089e013d1f9011d70d05242e6212 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, for web apps CORS headers are necessary, but= for native apps it doesn't make any difference if they are present or = not.


Cheers,
Michiel.

On Tue, Nov 10, 2015 at 11:54 AM, L= inhui Sun <lh.sunlinh@gmail.com> wrote:

2015-11-09 21:02 GMT+08:00 Michiel de Jon= g <mbdejong@mozilla.com>:


O= n Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun <lh.sunlinh@gmail.com>= wrote:
2015-11-09 19:06 GMT+08:00 Michiel de = Jong <mbdejong@mozilla.com>:
Hi!

I wanted to draw your attention t= o the situation where a web app, rather than an OS-native app, wants to syn= c data with a user's storage.

In this case, it's neces= sary that the API of the storage server be served with CORS headers. [1] Th= e following storage sync APIs already do this:

* Dropbox
* Google Drive (including YouTube)
* Kinto (a Mozilla project)= [2]
* remoteStorage (an IETF I-D of which I'm a contributor) = [3]
* Hoodie http://= hood.ie/

I work on data sync for Firefox OS [4] - a m= obile OS where every application is a client-side web app, so CORS headers = are important there.=C2=A0
I think we should also consider the sync among a web app, a native ap= p and user's storage since we cannot force users to use a web app or a = native app.

= ok, so then CORS headers are a must (otherwise you can only use OS-native a= pps).
Web sync is important= when we have no access to our own laptops or computers. It may also play a= n important role in the mobile devices. But it is a frequently happened sce= nario that other devices or subscribers uses a native app. How would this (= CORS header) work for native apps or a hybrid combination of native and web= apps? IMO, the native apps also need the CORS header. Or not?
Regards,
Linhui

--089e013d1f9011d70d05242e6212-- From nobody Tue Nov 10 04:11: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 4D29E1A90AB for ; Tue, 10 Nov 2015 04:11:54 -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 w3HgJHZoHJtQ for ; Tue, 10 Nov 2015 04:11:52 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 3CB101A901E for ; Tue, 10 Nov 2015 04:11:52 -0800 (PST) Received: by wmvv187 with SMTP id v187so4654533wmv.1 for ; Tue, 10 Nov 2015 04:11:50 -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=IUMZPCG6yRzxl5aznvn9u98uaxa1yg+FSrwpqH7Pskg=; b=NILtAGsSeSmRkNs8eCAn9KmLdPR8keYcg05oaktlGqjrbHxoTcgZWNv212hmpmW5JG 0XYsJPps9+ovAibRRgqVTx/CKsUfVko02tDhKjHZUOWVhvJ/Mkj1rGjABKoxwDq01+5A sF7DTaVteL0f4xRZQSVFC9XCBC5qJnJmAGURuavmlGkiZ6wMjfkBuRWO5o3ubrwSg0yL sPDRy3IKpajL5C7jhw9Gys00G0QWC7/OuE8FQ9ePPRLKoewYa4Rro3tnIDufJo6vFLhq lik2g5b+YHwAL0UoetVIaL9z1wNqeU9V1mjB3S+93ZrhZw2Twpu+fNB8rlrLbo2yVyl+ bFOQ== X-Received: by 10.28.6.142 with SMTP id 136mr34023583wmg.9.1447157510794; Tue, 10 Nov 2015 04:11:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.173.15 with HTTP; Tue, 10 Nov 2015 04:11:31 -0800 (PST) In-Reply-To: References: From: Linhui Sun Date: Tue, 10 Nov 2015 20:11:31 +0800 Message-ID: To: Michiel de Jong Content-Type: multipart/alternative; boundary=001a114427065d726905242e9dd5 Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 10 Nov 2015 12:11:54 -0000 --001a114427065d726905242e9dd5 Content-Type: text/plain; charset=UTF-8 2015-11-10 19:55 GMT+08:00 Michiel de Jong : > No, for web apps CORS headers are necessary, but for native apps it > doesn't make any difference if they are present or not. > I think I must miss something about the CORS, could you explain it a little more in detail why the CORS does not make any difference in the native apps. IMO, the native apps are still using HTTP connection and may also encounter a cross-domain access problem. Thanks, Linhui > > > Cheers, > Michiel. > > On Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun wrote: > >> >> 2015-11-09 21:02 GMT+08:00 Michiel de Jong : >> >>> >>> >>> On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun wrote: >>> >>>> 2015-11-09 19:06 GMT+08:00 Michiel de Jong : >>>> >>>>> Hi! >>>>> >>>>> I wanted to draw your attention to the situation where a web app, >>>>> rather than an OS-native app, wants to sync data with a user's storage. >>>>> >>>>> In this case, it's necessary that the API of the storage server be >>>>> served with CORS headers. [1] The following storage sync APIs already do >>>>> this: >>>>> >>>>> * Dropbox >>>>> * Google Drive (including YouTube) >>>>> * Kinto (a Mozilla project) [2] >>>>> * remoteStorage (an IETF I-D of which I'm a contributor) [3] >>>>> * Hoodie http://hood.ie/ >>>>> >>>>> I work on data sync for Firefox OS [4] - a mobile OS where every >>>>> application is a client-side web app, so CORS headers are important there. >>>>> >>>> I think we should also consider the sync among a web app, a native app >>>> and user's storage since we cannot force users to use a web app or a native >>>> app. >>>> >>> >>> ok, so then CORS headers are a must (otherwise you can only use >>> OS-native apps). >>> >> Web sync is important when we have no access to our own laptops or >> computers. It may also play an important role in the mobile devices. But it >> is a frequently happened scenario that other devices or subscribers uses a >> native app. How would this (CORS header) work for native apps or a hybrid >> combination of native and web apps? IMO, the native apps also need the CORS >> header. Or not? >> >> Regards, >> Linhui >> > > --001a114427065d726905242e9dd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-11-10 19:55 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>:
= No, for web apps CORS headers are necessary, but for native apps it doesn&#= 39;t make any difference if they are present or not.
<= /blockquote>
I think I must miss something about the CORS, could you ex= plain it a little more in detail why the CORS does not make any difference = in the native apps. IMO, the native apps are still using HTTP connection an= d may also encounter a cross-domain access problem.

Thanks,

On Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun <lh.sunl= inh@gmail.com> wrote:

2015-11-09 21:02 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com= >:


On Mon, Nov 9, 2015 at 1:37 PM, = Linhui Sun <lh.sunlinh@gmail.com> wrote:
= 2015-11-09 19:06 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com<= /a>>:
I think we should also cons= ider the sync among a web app, a native app and user's storage since we= cannot force users to use a web app or a native app.

ok, so then CORS headers are a mu= st (otherwise you can only use OS-native apps).
Web sync is important when we have no access to our ow= n laptops or computers. It may also play an important role in the mobile de= vices. But it is a frequently happened scenario that other devices or subsc= ribers uses a native app. How would this (CORS header) work for native apps= or a hybrid combination of native and web apps? IMO, the native apps also = need the CORS header. Or not?

Regards,
L= inhui


--001a114427065d726905242e9dd5-- From nobody Tue Nov 10 04:29: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 687B01ABD8F for ; Tue, 10 Nov 2015 04:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 BqCduWKMcN7U for ; Tue, 10 Nov 2015 04:29:16 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 365341A92F2 for ; Tue, 10 Nov 2015 04:29:16 -0800 (PST) Received: by wmww144 with SMTP id w144so73699521wmw.0 for ; Tue, 10 Nov 2015 04:29:14 -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=/OjXi1IyfnZO6eMAC3L9x44T/Wr0+9ItG2KoOx/j3VQ=; b=XAYUIn20+dvFtR5RTHmTtMxRMAjkKFEMYq+fsjGOfqU+OMJlVzBu8YSPmH4oYGuf2o TqjDWcXbDKhWHZgMVElX74TCQ9g+fo+oE0cmh6NHFSracOkM4lHVFeGvGtAVpcsBfmKo cfaPWJrNRtWZ+0XrOQyS6Zyzs4TLlKs65X5AzMzN6jObyNpaEGKN3m0SXrmSCGOxI69u 6KpXyKCDe4byzJVIXhpIujcoajyHRRFUqViOAb/HwmAJW3LllTky6SlKGdXhS9UHy0d1 KbO29rXeQqg7B0T671MuXofQql0rSWFx6ujd/8zKf0uQCoCBJpxgPELPBjdqmzPdRqhh 7OQg== 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=/OjXi1IyfnZO6eMAC3L9x44T/Wr0+9ItG2KoOx/j3VQ=; b=EL2uSotqa41MWpI3INsX/bZQ2Nx9YdWsjmLYAluuXvTolxeRmtNkOZvmZJlgTQHzXL NkQ3l4WelSv0dCGBCWZzWlOSSoevqBakNqsFbtNrUCwNW161plk9fBhPvWfaHdSaxw9y csIfS7ufZrTspytPj5oH7xMPMIlXDp2v03vZRMZxH1iYRbLRM1BkzBszG3z0Fe/neC1h 0UAW1Cp/WRM3T1kW7Yaws8e09KsZpmIP+PQ4LjXZUFvorMn1Yo1/Yd7kln1FLTvochdF FSPMOZmSU/rZgZE3DKduCgcW5zDvdQXIQIN+te89lIKp87xSMQa/xAd/F/j0OzeXdBom zp/A== X-Gm-Message-State: ALoCoQlOgZpcTIJkSXYJOuHZd0UmjS/twQVV1sxKzipoAze1hOuRdrWBXcrGOCyHzaYHSke9wdie MIME-Version: 1.0 X-Received: by 10.28.146.136 with SMTP id u130mr4607130wmd.91.1447158554756; Tue, 10 Nov 2015 04:29:14 -0800 (PST) Received: by 10.194.151.230 with HTTP; Tue, 10 Nov 2015 04:29:14 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Nov 2015 13:29:14 +0100 Message-ID: From: Michiel de Jong To: Linhui Sun Content-Type: multipart/alternative; boundary=001a1140153097271605242edb6c Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 10 Nov 2015 12:29:19 -0000 --001a1140153097271605242edb6c Content-Type: text/plain; charset=UTF-8 OK! "In the beginning" ;) there was HTTP. Then XMLHttpRequest was invented (also known as XHR or AJAX, later superseded by XHR2, and by the fetch API in the latest browser versions). Since XHR allows any website to make any HTTP request from the JavaScript that runs in your browser, the same-origin policy was applied to it (a similar policy already existed for Cookies and other things, and the same thing was also done for the HTTP client that was added to Flash at the time). This created a situation where a HTTP client is present in the browser's sandbox, for use by JavaScript code that runs in the web page, but it is restricted to the same origin as the website this JavaScript is part of (or is included from). Web developers got more creative, and invented JSONP as a work-around, to effectively do HTTP requests to other origins. JSONP was a dirty hack and had its limitations, but since it was recognized that its use cases were in themselves valid (sometimes depending on which resource is being fetched you want to have a HTTP client running inside JavaScript on a web page, without the same-origin restriction), and that's why CORS was invented. Instead of removing the overly simplistic and restrictive same-origin policy for XHR, and making it more flexible, CORS headers are added by the cross-origin resource, to overwrite the strict same-origin policies which are still the default behavior of HTTP clients that run inside browsers. It's a case of Deny-Then-Allow (where Deny is the default blanket same origin policy, and Allow are the explicit exceptions defined through CORS). HTTP clients that run outside browsers (in native apps, or on the command line, for instance), never had same-origin policies in the first place! In fact they don't even have a well-defined origin. So that's why they just ignore the CORS headers on API responses. CORS headers remove a limitation which these other HTTP clients never had. HTH! Cheers, Michiel. On Tue, Nov 10, 2015 at 1:11 PM, Linhui Sun wrote: > > > 2015-11-10 19:55 GMT+08:00 Michiel de Jong : > >> No, for web apps CORS headers are necessary, but for native apps it >> doesn't make any difference if they are present or not. >> > I think I must miss something about the CORS, could you explain it a > little more in detail why the CORS does not make any difference in the > native apps. IMO, the native apps are still using HTTP connection and may > also encounter a cross-domain access problem. > > Thanks, > Linhui > >> >> >> Cheers, >> Michiel. >> >> On Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun >> wrote: >> >>> >>> 2015-11-09 21:02 GMT+08:00 Michiel de Jong : >>> >>>> >>>> >>>> On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun >>>> wrote: >>>> >>>>> 2015-11-09 19:06 GMT+08:00 Michiel de Jong : >>>>> >>>>>> Hi! >>>>>> >>>>>> I wanted to draw your attention to the situation where a web app, >>>>>> rather than an OS-native app, wants to sync data with a user's storage. >>>>>> >>>>>> In this case, it's necessary that the API of the storage server be >>>>>> served with CORS headers. [1] The following storage sync APIs already do >>>>>> this: >>>>>> >>>>>> * Dropbox >>>>>> * Google Drive (including YouTube) >>>>>> * Kinto (a Mozilla project) [2] >>>>>> * remoteStorage (an IETF I-D of which I'm a contributor) [3] >>>>>> * Hoodie http://hood.ie/ >>>>>> >>>>>> I work on data sync for Firefox OS [4] - a mobile OS where every >>>>>> application is a client-side web app, so CORS headers are important there. >>>>>> >>>>> I think we should also consider the sync among a web app, a native app >>>>> and user's storage since we cannot force users to use a web app or a native >>>>> app. >>>>> >>>> >>>> ok, so then CORS headers are a must (otherwise you can only use >>>> OS-native apps). >>>> >>> Web sync is important when we have no access to our own laptops or >>> computers. It may also play an important role in the mobile devices. But it >>> is a frequently happened scenario that other devices or subscribers uses a >>> native app. How would this (CORS header) work for native apps or a hybrid >>> combination of native and web apps? IMO, the native apps also need the CORS >>> header. Or not? >>> >>> Regards, >>> Linhui >>> >> >> > --001a1140153097271605242edb6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK! "In the beginning" ;) th= ere was HTTP. Then XMLHttpRequest was invented (also known as XHR or AJAX, = later superseded by XHR2, and by the fetch API in the latest browser versio= ns). Since XHR allows any website to make any HTTP request from the JavaScr= ipt that runs in your browser, the same-origin policy was applied to it (a = similar policy already existed for Cookies and other things, and the same t= hing was also done for the HTTP client that was added to Flash at the time)= .

This created a situation where a HTTP client is present in t= he browser's sandbox, for use by JavaScript code that runs in the web p= age, but it is restricted to the same origin as the website this JavaScript= is part of (or is included from).

Web developers got more cre= ative, and invented JSONP as a work-around, to effectively do HTTP requests= to other origins.

JSONP was a dirty hack and had its limitati= ons, but since it was recognized that its use cases were in themselves vali= d (sometimes depending on which resource is being fetched you want to have = a HTTP client running inside JavaScript on a web page, without the same-ori= gin restriction), and that's why CORS was invented.

I= nstead of removing the overly simplistic and restrictive same-origin policy= for XHR, and making it more flexible, CORS headers are added by the cross-= origin resource, to overwrite the strict same-origin policies which are sti= ll the default behavior of HTTP clients that run inside browsers. It's = a case of Deny-Then-Allow (where Deny is the default blanket same origin po= licy, and Allow are the explicit exceptions defined through CORS).

<= /div>
HTTP clients that run outside browsers (in native apps, or on the= command line, for instance), never had same-origin policies in the first p= lace! In fact they don't even have a well-defined origin. So that's= why they just ignore the CORS headers on API responses. CORS headers remov= e a limitation which these other HTTP clients never had.

= HTH!


Cheers,
Michiel.

On Tue, = Nov 10, 2015 at 1:11 PM, Linhui Sun <lh.sunlinh@gmail.com> wrote:


2015-11-10= 19:55 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>:<= br>
No, for web ap= ps CORS headers are necessary, but for native apps it doesn't make any = difference if they are present or not.
I think I must miss something about the CORS, could you explain i= t a little more in detail why the CORS does not make any difference in the = native apps. IMO, the native apps are still using HTTP connection and may a= lso encounter a cross-domain access problem.

Thank= s,
Linhui=C2=A0


Cheers,
Michiel.
<= /div>

On= Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun <lh.sunlinh@gmail.com>= ; wrote:

2015-11-09 21:02 GM= T+08:00 Michiel de Jong <mbdejong@mozilla.com>:


On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun <lh.s= unlinh@gmail.com> wrote:
2015-11-09 19:= 06 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
Hi!

I wanted to= draw your attention to the situation where a web app, rather than an OS-na= tive app, wants to sync data with a user's storage.

In thi= s case, it's necessary that the API of the storage server be served wit= h CORS headers. [1] The following storage sync APIs already do this:
* Dropbox
* Google Drive (including YouTube)
* Kin= to (a Mozilla project) [2]
* remoteStorage (an IETF I-D of which I= 'm a contributor) [3]
* Hoodie http://hood.ie/

I work on data sync fo= r Firefox OS [4] - a mobile OS where every application is a client-side web= app, so CORS headers are important there.=C2=A0
I think we should also consider the sync among = a web app, a native app and user's storage since we cannot force users = to use a web app or a native app.
=
ok, so then CORS headers are a must (otherwise you ca= n only use OS-native apps).
Web sync is important when we have no access to our own laptops or compute= rs. It may also play an important role in the mobile devices. But it is a f= requently happened scenario that other devices or subscribers uses a native= app. How would this (CORS header) work for native apps or a hybrid combina= tion of native and web apps? IMO, the native apps also need the CORS header= . Or not?

Regards,
Linhui



--001a1140153097271605242edb6c-- From nobody Tue Nov 10 05:30: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 DB5281ACEE6 for ; Tue, 10 Nov 2015 05:30:20 -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 NsV2a9coIKSv for ; Tue, 10 Nov 2015 05:30:17 -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 AE67A1ACEE5 for ; Tue, 10 Nov 2015 05:30:16 -0800 (PST) Received: by wmww144 with SMTP id w144so722264wmw.0 for ; Tue, 10 Nov 2015 05:30:15 -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=KVl7byOoCN1HEsBK6zO+Fx2StZnq9NQH73yF1hQmKcM=; b=hWnckZvMuWsBuzeXshD7tGmwwWcO72z6ProcKqk6EosxQgSMpjxA69iSo5LE0Xx9+l aDSyFr8M4htDIeurJg8woUJjqUFg6Uozbs4b60tbREYkV6+YyvUiaxynBDsUSnel9SGy o6FOAHHH14KgbVJ/7YisVmHbjnG4qhcrrtwkvwXsUMdafkfGE2TjMfwFFI/uktWBSx05 tYv/o5pp6eOM1P/KhcZtJnLoVU0Z5MSO5aR4bxtZHtFdqcRSj9OI+xncM2RPu1m/B/fj TaOCzNjh20iqaW4M4oiS8PdSinSIXdKr46ZH5EP1F/sqfa4nedTwkOxbNOzVVChtzpT6 V5Zg== X-Received: by 10.194.142.45 with SMTP id rt13mr4481063wjb.45.1447162213615; Tue, 10 Nov 2015 05:30:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.173.15 with HTTP; Tue, 10 Nov 2015 05:29:54 -0800 (PST) In-Reply-To: References: From: Linhui Sun Date: Tue, 10 Nov 2015 21:29:54 +0800 Message-ID: To: Michiel de Jong Content-Type: multipart/alternative; boundary=089e0122927eacce9605242fb503 Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 10 Nov 2015 13:30:21 -0000 --089e0122927eacce9605242fb503 Content-Type: text/plain; charset=UTF-8 Cool and got it! Many thanks for the detailed explanation! Thus we will have no problem when users use a combination of web apps and native apps (with the help of CORS). In addition, I had a look at the wiki of Firefox OS Data Sync and got few comments. In the "The product" section, you mentioned that you want to achieve a "user choice". Does that mean you want to implement a general third-party app that can connect to various storage services? If so, this is only part of the so called "user choice". IMO, the "user choice" should also include the concept of "interoperability" (sync among different storage services). Since a further result of "user choice" is to synchronize files among different services. Do you think this is also needed? And in section 2.2.4 (i.e. "File sharing"), have you ever considered the scenario that Alice could also modify and update the file shared by Bob? Thanks, Linhui 2015-11-10 20:29 GMT+08:00 Michiel de Jong : > OK! "In the beginning" ;) there was HTTP. Then XMLHttpRequest was invented > (also known as XHR or AJAX, later superseded by XHR2, and by the fetch API > in the latest browser versions). Since XHR allows any website to make any > HTTP request from the JavaScript that runs in your browser, the same-origin > policy was applied to it (a similar policy already existed for Cookies and > other things, and the same thing was also done for the HTTP client that was > added to Flash at the time). > > This created a situation where a HTTP client is present in the browser's > sandbox, for use by JavaScript code that runs in the web page, but it is > restricted to the same origin as the website this JavaScript is part of (or > is included from). > > Web developers got more creative, and invented JSONP as a work-around, to > effectively do HTTP requests to other origins. > > JSONP was a dirty hack and had its limitations, but since it was > recognized that its use cases were in themselves valid (sometimes depending > on which resource is being fetched you want to have a HTTP client running > inside JavaScript on a web page, without the same-origin restriction), and > that's why CORS was invented. > > Instead of removing the overly simplistic and restrictive same-origin > policy for XHR, and making it more flexible, CORS headers are added by the > cross-origin resource, to overwrite the strict same-origin policies which > are still the default behavior of HTTP clients that run inside browsers. > It's a case of Deny-Then-Allow (where Deny is the default blanket same > origin policy, and Allow are the explicit exceptions defined through CORS). > > HTTP clients that run outside browsers (in native apps, or on the command > line, for instance), never had same-origin policies in the first place! In > fact they don't even have a well-defined origin. So that's why they just > ignore the CORS headers on API responses. CORS headers remove a limitation > which these other HTTP clients never had. > > HTH! > > > Cheers, > Michiel. > > On Tue, Nov 10, 2015 at 1:11 PM, Linhui Sun wrote: > >> >> >> 2015-11-10 19:55 GMT+08:00 Michiel de Jong : >> >>> No, for web apps CORS headers are necessary, but for native apps it >>> doesn't make any difference if they are present or not. >>> >> I think I must miss something about the CORS, could you explain it a >> little more in detail why the CORS does not make any difference in the >> native apps. IMO, the native apps are still using HTTP connection and may >> also encounter a cross-domain access problem. >> >> Thanks, >> Linhui >> >>> >>> >>> Cheers, >>> Michiel. >>> >>> On Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun >>> wrote: >>> >>>> >>>> 2015-11-09 21:02 GMT+08:00 Michiel de Jong : >>>> >>>>> >>>>> >>>>> On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun >>>>> wrote: >>>>> >>>>>> 2015-11-09 19:06 GMT+08:00 Michiel de Jong : >>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> I wanted to draw your attention to the situation where a web app, >>>>>>> rather than an OS-native app, wants to sync data with a user's storage. >>>>>>> >>>>>>> In this case, it's necessary that the API of the storage server be >>>>>>> served with CORS headers. [1] The following storage sync APIs already do >>>>>>> this: >>>>>>> >>>>>>> * Dropbox >>>>>>> * Google Drive (including YouTube) >>>>>>> * Kinto (a Mozilla project) [2] >>>>>>> * remoteStorage (an IETF I-D of which I'm a contributor) [3] >>>>>>> * Hoodie http://hood.ie/ >>>>>>> >>>>>>> I work on data sync for Firefox OS [4] - a mobile OS where every >>>>>>> application is a client-side web app, so CORS headers are important there. >>>>>>> >>>>>> I think we should also consider the sync among a web app, a native >>>>>> app and user's storage since we cannot force users to use a web app or a >>>>>> native app. >>>>>> >>>>> >>>>> ok, so then CORS headers are a must (otherwise you can only use >>>>> OS-native apps). >>>>> >>>> Web sync is important when we have no access to our own laptops or >>>> computers. It may also play an important role in the mobile devices. But it >>>> is a frequently happened scenario that other devices or subscribers uses a >>>> native app. How would this (CORS header) work for native apps or a hybrid >>>> combination of native and web apps? IMO, the native apps also need the CORS >>>> header. Or not? >>>> >>>> Regards, >>>> Linhui >>>> >>> >>> >> > --089e0122927eacce9605242fb503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cool and got it! Many thanks for the detailed explanation!= Thus we will have no problem when users use a combination of web apps and = native apps (with the help of CORS).=C2=A0

In addition, = I had a look at the wiki of Firefox OS Data Sync and got few comments. In t= he "The product" section, you mentioned that you want to achieve = a "user choice". Does that mean you want to implement a general t= hird-party app that can connect to various storage services? If so, this is= only part of the so called "user choice". IMO, the "user ch= oice" should also include the concept of "interoperability" = (sync among different storage services). Since a further result of "us= er choice" is to synchronize files among different services. Do you th= ink this is also needed?

And in section 2.2.4 (i.e= . "File sharing"), have you ever considered the scenario that Ali= ce could also modify and update the file shared by Bob?

Thanks,
Linhui

2015-11-10 20:29 GMT+08:00 Michiel de Jong <mb= dejong@mozilla.com>:
OK! "In the beginning" ;) there wa= s HTTP. Then XMLHttpRequest was invented (also known as XHR or AJAX, later = superseded by XHR2, and by the fetch API in the latest browser versions). S= ince XHR allows any website to make any HTTP request from the JavaScript th= at runs in your browser, the same-origin policy was applied to it (a simila= r policy already existed for Cookies and other things, and the same thing w= as also done for the HTTP client that was added to Flash at the time).
<= br>
This created a situation where a HTTP client is present in the bro= wser's sandbox, for use by JavaScript code that runs in the web page, b= ut it is restricted to the same origin as the website this JavaScript is pa= rt of (or is included from).

Web developers got more creative,= and invented JSONP as a work-around, to effectively do HTTP requests to ot= her origins.

JSONP was a dirty hack and had its limitations, b= ut since it was recognized that its use cases were in themselves valid (som= etimes depending on which resource is being fetched you want to have a HTTP= client running inside JavaScript on a web page, without the same-origin re= striction), and that's why CORS was invented.

Instead= of removing the overly simplistic and restrictive same-origin policy for X= HR, and making it more flexible, CORS headers are added by the cross-origin= resource, to overwrite the strict same-origin policies which are still the= default behavior of HTTP clients that run inside browsers. It's a case= of Deny-Then-Allow (where Deny is the default blanket same origin policy, = and Allow are the explicit exceptions defined through CORS).

<= div>HTTP clients that run outside browsers (in native apps, or on the comma= nd line, for instance), never had same-origin policies in the first place! = In fact they don't even have a well-defined origin. So that's why t= hey just ignore the CORS headers on API responses. CORS headers remove a li= mitation which these other HTTP clients never had.

HTH!

Cheers,
Michiel.

<= div class=3D"gmail_quote">On Tue, Nov 10, 2015 at 1:11 PM, Linhui Sun <= lh.sunlinh@gmail.com> wrote:


2015-11-10 19:55 GMT+08:00 Michiel de Jong &l= t;mbdejong@mozill= a.com>:
No, for web apps CORS headers are necessary, but for native apps it= doesn't make any difference if they are present or not.
I think I must miss something about the COR= S, could you explain it a little more in detail why the CORS does not make = any difference in the native apps. IMO, the native apps are still using HTT= P connection and may also encounter a cross-domain access problem.

Thanks,
Linhui=C2=A0


Cheers,
Mi= chiel.

On Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun <= ;lh.sunlinh@gmail= .com> wrote:

2015-11-= 09 21:02 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>= :


<= div class=3D"gmail_quote">On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun = <lh.sunlinh@gmail.com> wrote:
2015-= 11-09 19:06 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>:
Hi!

I = wanted to draw your attention to the situation where a web app, rather than= an OS-native app, wants to sync data with a user's storage.

In this case, it's necessary that the API of the storage server be s= erved with CORS headers. [1] The following storage sync APIs already do thi= s:

* Dropbox
* Google Drive (including YouTube)
* Kinto (a Mozilla project) [2]
* remoteStorage (an IETF I-D o= f which I'm a contributor) [3]
* Hoodie http://hood.ie/

I work on dat= a sync for Firefox OS [4] - a mobile OS where every application is a client= -side web app, so CORS headers are important there.=C2=A0
=
I think we should also consider the sy= nc among a web app, a native app and user's storage since we cannot for= ce users to use a web app or a native app.

ok, so then CORS headers are a must (otherwi= se you can only use OS-native apps).
Web sync is important when we have no access to our own laptops o= r computers. It may also play an important role in the mobile devices. But = it is a frequently happened scenario that other devices or subscribers uses= a native app. How would this (CORS header) work for native apps or a hybri= d combination of native and web apps? IMO, the native apps also need the CO= RS header. Or not?

Regards,
Linhui
=




--089e0122927eacce9605242fb503-- From nobody Tue Nov 10 09:22: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 016681A00BD for ; Tue, 10 Nov 2015 09:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 3YDxXMGqhWIk for ; Tue, 10 Nov 2015 09:22:41 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 34F431A00B1 for ; Tue, 10 Nov 2015 09:22:41 -0800 (PST) Received: by wmdw130 with SMTP id w130so80696203wmd.0 for ; Tue, 10 Nov 2015 09:22:39 -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=u9lAnvE9wPfruJ+FX9KbOrHSbHrx6cY2c0+SAGdcn1A=; b=q8hdGIXcjqRGmc+VVU08x3zk9c0atSMYq1Wflq9mMBjGbmf+w7L/Bv/lGy1dg7rWdu Kb/ZAa5sjopfYKmm4kstrmmtyTF9KsMwGannOfNV2QXEF3nBZ4J3Ms1MNcPT3w+v+M84 AH/Kg0l73CIWvKpc4ZN7irq30hpsHztUECZmfLOUKE3karDscpsllKrKpztFt+u+kips zEo/0QsejBpXq1H07oyfUQk3PK3IaQELhMYdtUpXstWOolwffV86CC5VaSiwsAAKi5aK WHQTldxye2L60opJ73lMKcR0nL+rhw9nY3F4pfqC2JasHaSQGakdsDchmTCO6BTpwRRt aZ4g== 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=u9lAnvE9wPfruJ+FX9KbOrHSbHrx6cY2c0+SAGdcn1A=; b=CktFMP1QKnHqlSWTWv/R8wOb+hByYb0mv69+4V2LUhOheW1p4Fr0XJg61ECV/xantx R60KBRkJSGQeX0qoC6VtQveYN5vmyiEqX/7I4kSed97hjqxfxFtantw5xQVbq+rnTmAe 3da7Yu4F1Pwj1hLwpYNq4IwOVzwASPOyQ+xuPaJiGxT8K7OpNrxFezMNwSpN6FTFeICI H+s4tklZ0mdDn6lDNQH1f1MPmJdZAhS1AwOhTOg9QGPsfteIN7OnvZFFfGpvgrcW0CK4 RHjGQtbkKP5mlHGXLipHmvn8OeAJ9/i8c1BzKdoHGHFL4fg/KVO1SVyhQsrEgsYIOlQF zXlQ== X-Gm-Message-State: ALoCoQn8/cD7yhI9TKX9RZASTm5+MGqE8uciHBvCOe2ZqSsTyJfhGiPYda0gJ4RAq1XZyHP2PiBG MIME-Version: 1.0 X-Received: by 10.28.23.141 with SMTP id 135mr6334435wmx.84.1447176159592; Tue, 10 Nov 2015 09:22:39 -0800 (PST) Received: by 10.194.151.230 with HTTP; Tue, 10 Nov 2015 09:22:39 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Nov 2015 18:22:39 +0100 Message-ID: From: Michiel de Jong To: Linhui Sun Content-Type: multipart/alternative; boundary=001a1147180eeb9cb9052432f462 Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 10 Nov 2015 17:22:45 -0000 --001a1147180eeb9cb9052432f462 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 10, 2015 at 2:29 PM, Linhui Sun wrote: > Cool and got it! Many thanks for the detailed explanation! Thus we will > have no problem when users use a combination of web apps and native apps > (with the help of CORS). > > In addition, I had a look at the wiki of Firefox OS Data Sync and got few > comments. In the "The product" section, you mentioned that you want to > achieve a "user choice". Does that mean you want to implement a general > third-party app that can connect to various storage services? If so, this > is only part of the so called "user choice". IMO, the "user choice" should > also include the concept of "interoperability" (sync among different > storage services). Since a further result of "user choice" is to > synchronize files among different services. Do you think this is also > needed? > Do you mean server-to-server? I think client-to-(any)-server would already be a big win. :) The current landscape for many internet users is that they're not really aware where their data is synced to, but it mainly depends on the device they buy: a Windows Phone will sync to Microsoft, an Android phone will sync to Google, and an iPhone will sync to Apple. The user can choose their storage provider only by buying a new device. That's like buying a new car just so you can drive on a different road. :) > > And in section 2.2.4 (i.e. "File sharing"), have you ever considered the > scenario that Alice could also modify and update the file shared by Bob? > Yes, but I must say it's a pretty complicated thing to get working if Alice does not have her own account at Bob's storage provider. So if Bob uses Dropbox and Alice has a Dropbox account, or Bob uses Google Drive and Alice has a Google account, then this will work. I agree with you that this is a point where the way the internet currently works for Bob and Alice can be improved. I'm not aware of anybody within Mozilla working on that currently, if that was your question. But there's been some work on this between Cozy cloud and myself earlier this year, see https://tools.ietf.org/html/draft-dejong-decentralized-sharing. > > Thanks, > Linhui > > 2015-11-10 20:29 GMT+08:00 Michiel de Jong : > >> OK! "In the beginning" ;) there was HTTP. Then XMLHttpRequest was >> invented (also known as XHR or AJAX, later superseded by XHR2, and by the >> fetch API in the latest browser versions). Since XHR allows any website to >> make any HTTP request from the JavaScript that runs in your browser, the >> same-origin policy was applied to it (a similar policy already existed for >> Cookies and other things, and the same thing was also done for the HTTP >> client that was added to Flash at the time). >> >> This created a situation where a HTTP client is present in the browser's >> sandbox, for use by JavaScript code that runs in the web page, but it is >> restricted to the same origin as the website this JavaScript is part of (or >> is included from). >> >> Web developers got more creative, and invented JSONP as a work-around, to >> effectively do HTTP requests to other origins. >> >> JSONP was a dirty hack and had its limitations, but since it was >> recognized that its use cases were in themselves valid (sometimes depending >> on which resource is being fetched you want to have a HTTP client running >> inside JavaScript on a web page, without the same-origin restriction), and >> that's why CORS was invented. >> >> Instead of removing the overly simplistic and restrictive same-origin >> policy for XHR, and making it more flexible, CORS headers are added by the >> cross-origin resource, to overwrite the strict same-origin policies which >> are still the default behavior of HTTP clients that run inside browsers. >> It's a case of Deny-Then-Allow (where Deny is the default blanket same >> origin policy, and Allow are the explicit exceptions defined through CORS). >> >> HTTP clients that run outside browsers (in native apps, or on the command >> line, for instance), never had same-origin policies in the first place! In >> fact they don't even have a well-defined origin. So that's why they just >> ignore the CORS headers on API responses. CORS headers remove a limitation >> which these other HTTP clients never had. >> >> HTH! >> >> >> Cheers, >> Michiel. >> >> On Tue, Nov 10, 2015 at 1:11 PM, Linhui Sun wrote: >> >>> >>> >>> 2015-11-10 19:55 GMT+08:00 Michiel de Jong : >>> >>>> No, for web apps CORS headers are necessary, but for native apps it >>>> doesn't make any difference if they are present or not. >>>> >>> I think I must miss something about the CORS, could you explain it a >>> little more in detail why the CORS does not make any difference in the >>> native apps. IMO, the native apps are still using HTTP connection and may >>> also encounter a cross-domain access problem. >>> >>> Thanks, >>> Linhui >>> >>>> >>>> >>>> Cheers, >>>> Michiel. >>>> >>>> On Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun >>>> wrote: >>>> >>>>> >>>>> 2015-11-09 21:02 GMT+08:00 Michiel de Jong : >>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun >>>>>> wrote: >>>>>> >>>>>>> 2015-11-09 19:06 GMT+08:00 Michiel de Jong : >>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> I wanted to draw your attention to the situation where a web app, >>>>>>>> rather than an OS-native app, wants to sync data with a user's storage. >>>>>>>> >>>>>>>> In this case, it's necessary that the API of the storage server be >>>>>>>> served with CORS headers. [1] The following storage sync APIs already do >>>>>>>> this: >>>>>>>> >>>>>>>> * Dropbox >>>>>>>> * Google Drive (including YouTube) >>>>>>>> * Kinto (a Mozilla project) [2] >>>>>>>> * remoteStorage (an IETF I-D of which I'm a contributor) [3] >>>>>>>> * Hoodie http://hood.ie/ >>>>>>>> >>>>>>>> I work on data sync for Firefox OS [4] - a mobile OS where every >>>>>>>> application is a client-side web app, so CORS headers are important there. >>>>>>>> >>>>>>> I think we should also consider the sync among a web app, a native >>>>>>> app and user's storage since we cannot force users to use a web app or a >>>>>>> native app. >>>>>>> >>>>>> >>>>>> ok, so then CORS headers are a must (otherwise you can only use >>>>>> OS-native apps). >>>>>> >>>>> Web sync is important when we have no access to our own laptops or >>>>> computers. It may also play an important role in the mobile devices. But it >>>>> is a frequently happened scenario that other devices or subscribers uses a >>>>> native app. How would this (CORS header) work for native apps or a hybrid >>>>> combination of native and web apps? IMO, the native apps also need the CORS >>>>> header. Or not? >>>>> >>>>> Regards, >>>>> Linhui >>>>> >>>> >>>> >>> >> > --001a1147180eeb9cb9052432f462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 10, 2015 at 2:29 PM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
<= div dir=3D"ltr">Cool and got it! Many thanks for the detailed explanation! = Thus we will have no problem when users use a combination of web apps and n= ative apps (with the help of CORS).=C2=A0

In addition, I= had a look at the wiki of Firefox OS Data Sync and got few comments. In th= e "The product" section, you mentioned that you want to achieve a= "user choice". Does that mean you want to implement a general th= ird-party app that can connect to various storage services? If so, this is = only part of the so called "user choice". IMO, the "user cho= ice" should also include the concept of "interoperability" (= sync among different storage services). Since a further result of "use= r choice" is to synchronize files among different services. Do you thi= nk this is also needed?


=C2=A0

Thanks,
Linhui

2015-11-10 20:= 29 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
OK! "In the beginning" ;) there was HTTP. Then XMLHttp= Request was invented (also known as XHR or AJAX, later superseded by XHR2, = and by the fetch API in the latest browser versions). Since XHR allows any = website to make any HTTP request from the JavaScript that runs in your brow= ser, the same-origin policy was applied to it (a similar policy already exi= sted for Cookies and other things, and the same thing was also done for the= HTTP client that was added to Flash at the time).

This create= d a situation where a HTTP client is present in the browser's sandbox, = for use by JavaScript code that runs in the web page, but it is restricted = to the same origin as the website this JavaScript is part of (or is include= d from).

Web developers got more creative, and invented JSONP = as a work-around, to effectively do HTTP requests to other origins.

=
JSONP was a dirty hack and had its limitations, but since it was reco= gnized that its use cases were in themselves valid (sometimes depending on = which resource is being fetched you want to have a HTTP client running insi= de JavaScript on a web page, without the same-origin restriction), and that= 's why CORS was invented.

Instead of removing the ove= rly simplistic and restrictive same-origin policy for XHR, and making it mo= re flexible, CORS headers are added by the cross-origin resource, to overwr= ite the strict same-origin policies which are still the default behavior of= HTTP clients that run inside browsers. It's a case of Deny-Then-Allow = (where Deny is the default blanket same origin policy, and Allow are the ex= plicit exceptions defined through CORS).

HTTP clients tha= t run outside browsers (in native apps, or on the command line, for instanc= e), never had same-origin policies in the first place! In fact they don'= ;t even have a well-defined origin. So that's why they just ignore the = CORS headers on API responses. CORS headers remove a limitation which these= other HTTP clients never had.

HTH!

Cheers,
Michiel.

On Tue, Nov 10, 2015 at = 1:11 PM, Linhui Sun <lh.sunlinh@gmail.com> wrote:


2015-11-10 19:55 GM= T+08:00 Michiel de Jong <mbdejong@mozilla.com>:
No, = for web apps CORS headers are necessary, but for native apps it doesn't= make any difference if they are present or not.
I think I must miss something about the CORS, could you= explain it a little more in detail why the CORS does not make any differen= ce in the native apps. IMO, the native apps are still using HTTP connection= and may also encounter a cross-domain access problem.

=
Thanks,
Linhui=C2=A0


Cheers,
<= /div>Michiel.

On Tue, Nov 10, 2015 at 11:54 AM, Linhui Sun <lh.sunli= nh@gmail.com> wrote:

2015-11-09 21:02 GMT+08:00 Michiel de Jong <mbdejong= @mozilla.com>:


On Mon, Nov 9, 2015 at 1:37 PM, Linhui Sun <lh.sunlinh= @gmail.com> wrote:
2015-11-09 19:06 GMT+08:00 Michiel de Jong &= lt;mbdejong@mozil= la.com>:
Hi!
<= div>

I wanted to draw your atte= ntion to the situation where a web app, rather than an OS-native app, wants= to sync data with a user's storage.

In this case, it'= s necessary that the API of the storage server be served with CORS headers.= [1] The following storage sync APIs already do this:

* Dropbo= x
* Google Drive (including YouTube)
* Kinto (a Mozilla p= roject) [2]
* remoteStorage (an IETF I-D of which I'm a contri= butor) [3]
* Hoodie = http://hood.ie/

I work on data sync for Firefox OS [4= ] - a mobile OS where every application is a client-side web app, so CORS h= eaders are important there.=C2=A0
I think we should also consider the sync among a web app, a na= tive app and user's storage since we cannot force users to use a web ap= p or a native app.

ok, so then CORS headers are a must (otherwise you can only use OS-n= ative apps).
Web sync is im= portant when we have no access to our own laptops or computers. It may also= play an important role in the mobile devices. But it is a frequently happe= ned scenario that other devices or subscribers uses a native app. How would= this (CORS header) work for native apps or a hybrid combination of native = and web apps? IMO, the native apps also need the CORS header. Or not?
=

Regards,
Linhui





--001a1147180eeb9cb9052432f462-- From nobody Tue Nov 10 19: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 C7A871B479A for ; Tue, 10 Nov 2015 19:04:09 -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 0rW-VEs5ZTO4 for ; Tue, 10 Nov 2015 19:04:07 -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 0CD711B479E for ; Tue, 10 Nov 2015 19:04:02 -0800 (PST) Received: by wmvv187 with SMTP id v187so37168712wmv.1 for ; Tue, 10 Nov 2015 19:04:00 -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=Ma2nfhFqjv4vIOxo4TMkIx/AZVO4BAiZQ5lJhB/QxVk=; b=0o48ZP/uMszMaQ0qq+MiCW/pEZal8PTVj5UiJsXyDXgHOblk/r/1chJVlKaxpOY+Sz 40u3TROGncKH2iwm5ZngYXMQoK75a43SxOT3YrhpLYoKeMeJZ5sMC7Ov57G5cXUl8zqX wcfmPpPXOWYysecH1O2uzPHTsyWcBNjzUoLzygy9aa1bA+y+VNNtx1TmXdKz52TduPa1 9CnuFmNChFihdy4lUU0fcvmLS7uRaJCe5vM/EHph+Ardg0tqKt4AkO972ueHue8/14iW iLA9zh/dJIX5A2RtAI8RlzC8YetS76ZwJfIRgg3RCuY6DbhNPsOHdXShyOqrNukKFiQH TZOg== X-Received: by 10.194.78.15 with SMTP id x15mr8294645wjw.144.1447211040529; Tue, 10 Nov 2015 19:04:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.173.15 with HTTP; Tue, 10 Nov 2015 19:03:41 -0800 (PST) In-Reply-To: References: From: Linhui Sun Date: Wed, 11 Nov 2015 11:03:41 +0800 Message-ID: To: Michiel de Jong Content-Type: multipart/alternative; boundary=047d7bfcfd7afc62ee05243b1344 Archived-At: Cc: storagesync Subject: Re: [Storagesync] CORS headers on storage sync APIs - a requirement? 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, 11 Nov 2015 03:04:10 -0000 --047d7bfcfd7afc62ee05243b1344 Content-Type: text/plain; charset=UTF-8 2015-11-11 1:22 GMT+08:00 Michiel de Jong : > > > On Tue, Nov 10, 2015 at 2:29 PM, Linhui Sun wrote: > >> Cool and got it! Many thanks for the detailed explanation! Thus we will >> have no problem when users use a combination of web apps and native apps >> (with the help of CORS). >> >> In addition, I had a look at the wiki of Firefox OS Data Sync and got few >> comments. In the "The product" section, you mentioned that you want to >> achieve a "user choice". Does that mean you want to implement a general >> third-party app that can connect to various storage services? If so, this >> is only part of the so called "user choice". IMO, the "user choice" should >> also include the concept of "interoperability" (sync among different >> storage services). Since a further result of "user choice" is to >> synchronize files among different services. Do you think this is also >> needed? >> > > Do you mean server-to-server? I think client-to-(any)-server would already > be a big win. :) The current landscape for many internet users is that > they're not really aware where their data is synced to, but it mainly > depends on the device they buy: a Windows Phone will sync to Microsoft, an > Android phone will sync to Google, and an iPhone will sync to Apple. The > user can choose their storage provider only by buying a new device. That's > like buying a new car just so you can drive on a different road. :) > I'm not saying the server-to-server sync, since it may be involved in some authentication and security issues among different services. What we are trying to do in this ISS work is to achieve the interoperability through standardizing the sync protocol. And currently, if I got a iPhone, I could still use the GoogleDrive through installing a GoogleDrive app. I think a more appropriate analogy is that we can drive our cars on different roads but we have to pay for them. If we have the "interoperability", our cars could drive on different roads without any restriction. And I think that is what the client-to-any-server should be : ) > > >> >> And in section 2.2.4 (i.e. "File sharing"), have you ever considered the >> scenario that Alice could also modify and update the file shared by Bob? >> > > Yes, but I must say it's a pretty complicated thing to get working if > Alice does not have her own account at Bob's storage provider. So if Bob > uses Dropbox and Alice has a Dropbox account, or Bob uses Google Drive and > Alice has a Google account, then this will work. I agree with you that this > is a point where the way the internet currently works for Bob and Alice can > be improved. I'm not aware of anybody within Mozilla working on that > currently, if that was your question. But there's been some work on this > between Cozy cloud and myself earlier this year, see > https://tools.ietf.org/html/draft-dejong-decentralized-sharing. > The current situation is caused by various proprietary sync protocols and that is what "interoperability" should also resolve (though it is hard). IMO, the Internet-based storage services should not be blocked by different vendors. We have discussed this in the BOF, we got some positive feedbacks but it is also upset that some vendors express that they have no interest. Anyway, we think this is still worth doing. I think the draft you mentioned here is a good start, the use case described in the Introduction is what we desire. I will read this draft and maybe you could post it to this ML to request for more reviews : ) Regards, Linhui --047d7bfcfd7afc62ee05243b1344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-11-11 1:22 GMT+08:00 Michiel de Jong <mbdejong@mozilla.com= >:


On Tue, Nov 10, 20= 15 at 2:29 PM, Linhui Sun <lh.sunlinh@gmail.com> wrote:
Cool a= nd got it! Many thanks for the detailed explanation! Thus we will have no p= roblem when users use a combination of web apps and native apps (with the h= elp of CORS).=C2=A0

In addition, I had a look at the wik= i of Firefox OS Data Sync and got few comments. In the "The product&qu= ot; section, you mentioned that you want to achieve a "user choice&quo= t;. Does that mean you want to implement a general third-party app that can= connect to various storage services? If so, this is only part of the so ca= lled "user choice". IMO, the "user choice" should also = include the concept of "interoperability" (sync among different s= torage services). Since a further result of "user choice" is to s= ynchronize files among different services. Do you think this is also needed= ?

Do you mean server-to-= server? I think client-to-(any)-server would already be a big win. :) The c= urrent landscape for many internet users is that they're not really awa= re where their data is synced to, but it mainly depends on the device they = buy: a Windows Phone will sync to Microsoft, an Android phone will sync to = Google, and an iPhone will sync to Apple. The user can choose their storage= provider only by buying a new device. That's like buying a new car jus= t so you can drive on a different road. :)
I'm not saying the server-to-server sync, since it may be = involved in some authentication and security issues among different service= s. What we are trying to do in this ISS work is to achieve the interoperabi= lity through standardizing the sync protocol. And currently, if I got a iPh= one, I could still use the GoogleDrive through installing a GoogleDrive app= . I think a more appropriate analogy is that we can drive our cars on diffe= rent roads but we have to pay for them. If we have the "interoperabili= ty", our cars could drive on different roads without any restriction. = And I think that is what the client-to-any-server should be : )
=C2=A0

And in s= ection 2.2.4 (i.e. "File sharing"), have you ever considered the = scenario that Alice could also modify and update the file shared by Bob?

Yes, but I must say it'= ;s a pretty complicated thing to get working if Alice does not have her own= account at Bob's storage provider. So if Bob uses Dropbox and Alice ha= s a Dropbox account, or Bob uses Google Drive and Alice has a Google accoun= t, then this will work. I agree with you that this is a point where the way= the internet currently works for Bob and Alice can be improved. I'm no= t aware of anybody within Mozilla working on that currently, if that was yo= ur question. But there's been some work on this between Cozy cloud and = myself earlier this year, see https://tools.ietf.org/html= /draft-dejong-decentralized-sharing.=C2=A0
=C2=A0The current situation is caused by various proprietary s= ync protocols and that is what "interoperability" should also res= olve (though it is hard). IMO, the Internet-based storage services should n= ot be blocked by different vendors. We have discussed this in the BOF, we g= ot some positive feedbacks but it is also upset that some vendors express t= hat they have no interest. Anyway, we think this is still worth doing. I th= ink the draft you mentioned here is a good start, the use case described in= the Introduction is what we desire. I will read this draft and maybe you c= ould post it to this ML to request for more reviews : )=C2=A0
Regards,
Linhui
--047d7bfcfd7afc62ee05243b1344-- From nobody Thu Nov 12 01:42: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 C5B671B2D53 for ; Thu, 12 Nov 2015 01:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 0TiGJaXtJUyk for ; Thu, 12 Nov 2015 01:42:10 -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 064F71B2D55 for ; Thu, 12 Nov 2015 01:42:09 -0800 (PST) Received: by wmvv187 with SMTP id v187so23627819wmv.1 for ; Thu, 12 Nov 2015 01:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla_com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=FClboan+Adr9KnX4gpr2Lw7FNnl7Xbzxze3jWZ7O5/0=; b=DYEXnrY4ZNY2rOQPMxZ2vrzlKHEHxtupShQYWAPAhfqv5qD5t+CvqdG3CRHLEPSAwR euVSa2U99l2uOym0yq+ZqXg1JbEwqbhPheouE5GJJTSDcfVBbfjkmVndqrIfsCx24ppp F/gDoeMO3j5XBVEP1L7U5HugRaypNPOzxSOy4E/ZXpno9SbYMHzSn1yuP9caC6w+DO3Q QJx7GQlIQohd3TbwbIPWY4/XBN3hEOxhfVFrwsSeSEDbRGQHkCuZmQDPwLcY4oG6OJjc rdnH6I14I3jnb4pv8tBioZ00htSes4J3qkUUiaVyxvi3tgCVYYW0cyuZz0vygsPKJ1kB xMLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=FClboan+Adr9KnX4gpr2Lw7FNnl7Xbzxze3jWZ7O5/0=; b=d5DUIXbu9yfyPGi+i8dY8c0UtiSM/y4kWR9jCRqgO2sDR3MT2WkYURopNQagCg6inJ sGigLr9cO9VsMXegnNb9YTmsB4mGIl0usv16mfKIKCacqs8Y1FvAWhFk6UX/dp/e8v9b i5f6C0+MC7fO+1Twc8JpXBaIA3nDdnByDhQZuEDQcP/mgRBLvdh1NS/v8c2Lu4pAAhin +sCtNvrHT/vc/H9DSwFnVq3RBS7l6ecJw2aYNZidiEHuSHU3TbN9iANEZsUh3WJiJTs/ UjT3qh1+Y/gNL0xhynN3ih1Q6b5ZAkgYP8ztzKrvnQZ42G5UcX0RCGBEcklo9fwMzNw3 btkg== X-Gm-Message-State: ALoCoQlOwwLnGe8W99wPdo4jvvZa3aonn9SGKDbgs7Eft1VbreZVujrIUBqe7MhtWNFlguyeJu2m MIME-Version: 1.0 X-Received: by 10.194.175.164 with SMTP id cb4mr15208887wjc.72.1447321328448; Thu, 12 Nov 2015 01:42:08 -0800 (PST) Received: by 10.194.151.230 with HTTP; Thu, 12 Nov 2015 01:42:08 -0800 (PST) Date: Thu, 12 Nov 2015 10:42:08 +0100 Message-ID: From: Michiel de Jong To: storagesync Content-Type: multipart/alternative; boundary=089e013d1f90a89bdd052454c13b Archived-At: Subject: [Storagesync] Blogpost about Sync/Backup workshop at Redecentralize Conference 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, 12 Nov 2015 09:42:12 -0000 --089e013d1f90a89bdd052454c13b Content-Type: text/plain; charset=UTF-8 Thought some people on this list might find this blogpost from Francis Irving interesting: http://www.flourish.org/2015/11/syncbackup-workshop-at-redecentralize-conference/ Cheers, Michiel. --089e013d1f90a89bdd052454c13b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thought some people on this list might find this= blogpost from Francis Irving interesting:

http:/= /www.flourish.org/2015/11/syncbackup-workshop-at-redecentralize-conference/=


Cheers,
Michiel.
--089e013d1f90a89bdd052454c13b-- From nobody Tue Nov 17 05:11: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 A05641B2EF4 for ; Tue, 17 Nov 2015 05:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.914 X-Spam-Level: X-Spam-Status: No, score=0.914 tagged_above=-999 required=5 tests=[BAYES_60=1.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-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 c_6i5WDJFNcD for ; Tue, 17 Nov 2015 05:11:49 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 155831B2EF3 for ; Tue, 17 Nov 2015 05:11:44 -0800 (PST) Received: by ajax-webmail-Jdweb2 (Coremail) ; Tue, 17 Nov 2015 21:13:35 +0800 (GMT+08:00) Date: Tue, 17 Nov 2015 21:13:35 +0800 (GMT+08:00) From: fsong@bjtu.edu.cn To: storagesync@ietf.org Message-ID: <208d822f.1c53b.15115943f39.Coremail.fsong@bjtu.edu.cn> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_426061_268825284.1447766015799" X-Originating-IP: [59.100.6.101] 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: M55wygDn7sL_J0tWcerSAA--.54726W X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/1tbiAQAQB1R9XjPWNQAGs3 X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Subject: [Storagesync] recent issues and next step? 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, 17 Nov 2015 13:11:50 -0000 ------=_Part_426061_268825284.1447766015799 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksCgogCgpVbnRpbCBub3csIGFmdGVyIHJlYWRpbmcgcHJldmlvdXMgZW1haWwsIHNldmVyYWwg aXNzdWVzIGFyZSBzdGlsbCBpbiBteSBtaW5kOgoKIAoKMS4gICAgICAgIFRoZSBkZXNpZ24gdGFy Z2V0cyBvZiBXZWJEQVYsIHJzeW5jIGFuZCBvdGhlciBleGlzdGluZyBhcHByb2FjaGVzIChhcmUg dGhlcmUgYW55IG92ZXJsYXBzIHdpdGggSVNTPykKCjIuICAgICAgICBUaGUgcG90ZW50aWFsIHVz ZSBjYXNlcyBvZiBJU1MsIHN1Y2ggYXMgY2xpZW50L3NlcnZlciwgZ2l0LWxpa2UgcGF0dGVybiwg c3ZuLCBldGMuIChpcyB0aGF0IGVub3VnaCBmb3IgSVNTPykKCjMuICAgICAgICBUaGUgZWZmaWNp ZW5jeSBpbXByb3ZlbWVudHMgbWlnaHQgYmUgdGhlIHNlY29uZCBnb2FsIGZvciBzdGFuZGFyZGl6 aW5nIElTUyBwcm90b2NvbCAoSSBhZ3JlZSB3aXRoIHRoYXQsIGJ1dCB3aGF0IGlzIHRoZSBmaXJz dOKApj8pCgo0LiAgICAgICAgQ09SUyBoZWFkZXJzIG9uIHN0b3JhZ2Ugc3luYyBBUElzIChzb3Vu ZCBpbnRlcmVzdGluZyBmb3IgbWUpCgo1LiAgICAgICAgUGxlYXNlIGNvcnJlY3QgbWUgaWYgdGhl cmUgYXJlIHN0aWxsIG1vcmUuCgogCgpHZXR0aW5nIG1vcmUgcGVvcGxlIGFyb3VuZCwgSSB0aGlu aywgd2lsbCBiZSBiZW5lZml0IGZvciBJU1MuIFRoZXJlZm9yZSwgb25lIG9yIG1vcmUgc3BlY2lm aWMgdG9waWNzIG1pZ2h0IGJlIGhlbHBmdWwuIEZvciBpbnN0YW50LCBleGFjdCB1c2UgY2FzZSBh bmQgcHJvYmxlbSBmb3IgSVNTPwoKIAoKRmVpIFNvbmcKCiA= ------=_Part_426061_268825284.1447766015799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdp bmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BB TiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXpl OiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPkhpLDxvOnA+PC9vOnA+ PC9GT05UPjwvU1BBTj48L1A+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBj bSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQ7 IG1zby1iaWRpLWZvbnQtc2l6ZTogNi4wcHQiIGxhbmc9IkVOLVVTIj48bzpwPjxGT05UIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1B TElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9y cGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjog YmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDYuMHB0IiBsYW5nPSJF Ti1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+VW50aWwgbm93LCBhZnRlciByZWFkaW5nIHByZXZp b3VzIGVtYWlsLCBzZXZlcmFsIGlzc3VlcyBhcmUgc3RpbGwgaW4gbXkgbWluZDo8bzpwPjwvbzpw PjwvRk9OVD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0 OyBtc28tYmlkaS1mb250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+PG86cD48Rk9OVCBmYWNl PSJDYWxpYnJpIj4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4KPFAgc3R5bGU9IlRFWFQt QUxJR046IGxlZnQ7IFRFWFQtSU5ERU5UOiAtMThwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCAxOHB0 OyBtc28tY2hhci1pbmRlbnQtY291bnQ6IDA7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIGFsaWdu PSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWJpZGktdGhlbWUtZm9u dDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtc2l6ZTogNi4wcHQiIGxhbmc9IkVOLVVTIj48 U1BBTiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+MS48L0ZP TlQ+PFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFO IHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6 IDYuMHB0IiBsYW5nPSJFTi1VUyI+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+VGhlIGRlc2lnbiB0YXJn ZXRzIG9mIFdlYkRBViwgcnN5bmMgYW5kIG90aGVyIGV4aXN0aW5nIGFwcHJvYWNoZXMgKGFyZSB0 aGVyZSBhbnkgb3ZlcmxhcHMgd2l0aCBJU1M/KTxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+ CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBURVhULUlOREVOVDogLTE4cHQ7IE1BUkdJTjog MGNtIDBjbSAwcHQgMThwdDsgbXNvLWNoYXItaW5kZW50LWNvdW50OiAwOyBtc28tbGlzdDogbDAg bGV2ZWwxIGxmbzE7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1T SVpFOiA5cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZmFyZWFzdC10 aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6IENhbGlicmk7IG1z by1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LXNpemU6IDYuMHB0 IiBsYW5nPSJFTi1VUyI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPjxGT05UIGZhY2U9 IkNhbGlicmkiPjIuPC9GT05UPjxTUEFOIHN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21h biciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9T UEFOPjwvU1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDlwdDsgbXNv LWJpZGktZm9udC1zaXplOiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxGT05UIGZhY2U9IkNhbGlicmki PlRoZSBwb3RlbnRpYWwgdXNlIGNhc2VzIG9mIElTUywgc3VjaCBhcyBjbGllbnQvc2VydmVyLCBn aXQtbGlrZSBwYXR0ZXJuLCBzdm4sIGV0Yy4gKGlzIHRoYXQgZW5vdWdoIGZvciBJU1M/KTxvOnA+ PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBURVhU LUlOREVOVDogLTE4cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQgMThwdDsgbXNvLWNoYXItaW5kZW50 LWNvdW50OiAwOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IG1zby1wYWdpbmF0aW9uOiB3aWRv dy1vcnBoYW4iIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5 bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiBDYWxpYnJpOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBt c28tYmlkaS1mb250LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+PFNQQU4gc3R5bGU9Im1zby1s aXN0OiBJZ25vcmUiPjxGT05UIGZhY2U9IkNhbGlicmkiPjMuPC9GT05UPjxTUEFOIHN0eWxlPSJG T05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6IGJs YWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIgbGFuZz0iRU4t VVMiPjxGT05UIGZhY2U9IkNhbGlicmkiPlRoZSBlZmZpY2llbmN5IGltcHJvdmVtZW50cyBtaWdo dCBiZSB0aGUgc2Vjb25kIGdvYWwgZm9yIHN0YW5kYXJkaXppbmcgSVNTIHByb3RvY29sIChJIGFn cmVlIHdpdGggdGhhdCwgYnV0IHdoYXQgaXMgdGhlIGZpcnN04oCmPyk8bzpwPjwvbzpwPjwvRk9O VD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgVEVYVC1JTkRFTlQ6IC0x OHB0OyBNQVJHSU46IDBjbSAwY20gMHB0IDE4cHQ7IG1zby1jaGFyLWluZGVudC1jb3VudDogMDsg bXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjog YmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQ2FsaWJyaTsg bXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiBDYWxpYnJpOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9u dC1zaXplOiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxTUEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3Jl Ij48Rk9OVCBmYWNlPSJDYWxpYnJpIj40LjwvRk9OVD48U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdU aW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1T SVpFOiA5cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogNi4wcHQiIGxhbmc9IkVOLVVTIj48Rk9OVCBm YWNlPSJDYWxpYnJpIj5DT1JTIGhlYWRlcnMgb24gc3RvcmFnZSBzeW5jIEFQSXMgKHNvdW5kIGlu dGVyZXN0aW5nIGZvciBtZSk8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPgo8UCBzdHlsZT0i VEVYVC1BTElHTjogbGVmdDsgVEVYVC1JTkRFTlQ6IC0xOHB0OyBNQVJHSU46IDBjbSAwY20gMHB0 IDE4cHQ7IG1zby1jaGFyLWluZGVudC1jb3VudDogMDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8x OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg YWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0OyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDog bWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tYmlkaS10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIgbGFuZz0iRU4t VVMiPjxTUEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj48Rk9OVCBmYWNlPSJDYWxpYnJpIj41 LjwvRk9OVD48U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+ PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQ7IG1zby1iaWRpLWZvbnQt c2l6ZTogNi4wcHQiIGxhbmc9IkVOLVVTIj48Rk9OVCBmYWNlPSJDYWxpYnJpIj5QbGVhc2UgY29y cmVjdCBtZSBpZiB0aGVyZSBhcmUgc3RpbGwgbW9yZS48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+ PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi PjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250 LXNpemU6IDYuMHB0IiBsYW5nPSJFTi1VUyI+PG86cD48Rk9OVCBmYWNlPSJDYWxpYnJpIj4mbmJz cDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJ WkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIgbGFuZz0iRU4tVVMiPjxGT05UIGZh Y2U9IkNhbGlicmkiPkdldHRpbmcgbW9yZSBwZW9wbGUgYXJvdW5kLCBJIHRoaW5rLCB3aWxsIGJl IGJlbmVmaXQgZm9yIElTUy4gVGhlcmVmb3JlLCBvbmUgb3IgbW9yZSBzcGVjaWZpYyB0b3BpY3Mg bWlnaHQgYmUgaGVscGZ1bC4gRm9yIGluc3RhbnQsIGV4YWN0IHVzZSBjYXNlIGFuZCBwcm9ibGVt IGZvciBJU1M/PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4KPFAgc3R5bGU9IlRFWFQtQUxJ R046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBo YW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJs YWNrOyBGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiA2LjBwdCIgbGFuZz0iRU4t VVMiPjxvOnA+PEZPTlQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48 L1A+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBtc28t cGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+ PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA5cHQ7IG1zby1iaWRpLWZvbnQt c2l6ZTogNi4wcHQiIGxhbmc9IkVOLVVTIj48Rk9OVCBmYWNlPSJDYWxpYnJpIj5GZWkgU29uZzxv OnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+CjxQPiZuYnNwOzwvUD4= ------=_Part_426061_268825284.1447766015799-- From nobody Tue Nov 17 22:42: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 73AEA1AD071 for ; Tue, 17 Nov 2015 22:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 pGyOc7P3okXr for ; Tue, 17 Nov 2015 22:42:12 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 CE1B41AD06F for ; Tue, 17 Nov 2015 22:42:11 -0800 (PST) Received: by wmww144 with SMTP id w144so57730731wmw.0 for ; Tue, 17 Nov 2015 22:42:10 -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=5rTcP0J9ENXkuolS9z4u1R+ddMaPLdOEx0+1BIVl/T0=; b=cLTtyecyx7BoMGYmx4cSFYdID2GYR9oJmyG2//YghhAmi8x1PgTUHu8hpI9h9f2eRQ IDY+wYgAYIao34MVOwNuJtQzVMXDpq2j0xyXb987EHZp02nuNJ7RQrSkh16qdljsfUHY MtFkp6LyI3BGeqJMi8p40kiLs+mva+igjPOI/PjMHWwBFF7fGrqLpunW3wtbtWEdgoUf nIfUMAPGOpvl5ZFNtP3Kcx4ElMXSVK6X5X4L6nzTz956r+1Yv2w9yeBbZXs9GauKeEM6 bMM2lYlr/xl7I43hC4A2F0d+gHhF6UBYlG8QslPQhhUnkS9TJ0rVm+fxg+7bs7dIn5Lg MjKQ== X-Received: by 10.194.133.1 with SMTP id oy1mr26992675wjb.137.1447828930439; Tue, 17 Nov 2015 22:42:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.173.15 with HTTP; Tue, 17 Nov 2015 22:41:51 -0800 (PST) In-Reply-To: <208d822f.1c53b.15115943f39.Coremail.fsong@bjtu.edu.cn> References: <208d822f.1c53b.15115943f39.Coremail.fsong@bjtu.edu.cn> From: Linhui Sun Date: Wed, 18 Nov 2015 14:41:51 +0800 Message-ID: To: fsong@bjtu.edu.cn Content-Type: multipart/alternative; boundary=089e011836b6182fa20524caf1ad Archived-At: Cc: storagesync Subject: Re: [Storagesync] recent issues and next step? 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, 18 Nov 2015 06:42:14 -0000 --089e011836b6182fa20524caf1ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fei, 2015-11-17 21:13 GMT+08:00 : > Hi, > > > > Until now, after reading previous email, several issues are still in my > mind: > > > > 1. The design targets of WebDAV, rsync and other existing > approaches (are there any overlaps with ISS?) > For me, WebDAV and ISS are different in applicability. While a fact is that many open source storage services are using WebDav to do the sync (e.g. ownCloud) now. Need investigation here to find how they do that. > 2. The potential use cases of ISS, such as client/server, git-like > pattern, svn, etc. (is that enough for ISS?) > IMO, the use case is not something like C/S or git way. These things sound like mode/pattern which could be discussed later. Use cases might be something more related to the requirements, please correct me if I am wrong : ) Possible use cases of a generalized API or protocol in my mind: 1) User A is using Dropbox, User B is using GoogleDrive. If A shares a file with B, they could work together on that file since then. Both A and B could make changes to the shared file and also retrieve or delete the file at any time. 2) User A has different services accounts, he could easily access all different services through one client app and also easily transfer files between different clouds. 3) Since network-based storage services could become the "data entrance", many apps want to work together with such services. Developers of those apps only need to interoperate with one generalized API to support all the similar services. 4) Enterprises may desire to have a private storage service due to the consideration of security and privacy. They could develop their own sync storage services based on a standard API or protocol. 3. The efficiency improvements might be the second goal for > standardizing ISS protocol (I agree with that, but what is the first=E2= =80=A6?) > Maybe the interoperability? A generalized API or protocol to access all services and allow sync cross the services. > 4. CORS headers on storage sync APIs (sound interesting for me) > > 5. Please correct me if there are still more. > > > > Getting more people around, I think, will be benefit for ISS. Therefore, > one or more specific topics might be helpful. For instant, exact use case > and problem for ISS? > > > > Fei Song > > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > Regards, Linhui --089e011836b6182fa20524caf1ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fei,

2015-11-17 21:13 GMT+08:00 <fsong@bjtu.edu.cn>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Hi,<= /p>

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

Until now, after reading previous email, several issues are = still in my mind:

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

1.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The design targ= ets of WebDAV, rsync and other existing approaches (are there any overlaps = with ISS?)

For me, WebDAV and ISS are di= fferent in applicability. While a fact is that many open source storage ser= vices are using WebDav to do the sync (e.g. ownCloud) now. Need investigati= on here to find how they do that.

2.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The potential u= se cases of ISS, such as client/server, git-like pattern, svn, etc. (is tha= t enough for ISS?)

IMO, the use case is = not something like C/S or git way. These things sound like mode/pattern whi= ch could be discussed later. Use cases might be something more related to t= he requirements, please correct me if I am wrong : )

Possible use cases of a generalized API or protocol in my mind:
1) User A is using Dropbox, User B is using GoogleDrive. If A shares a fi= le with B, they could work together on that file since then. Both A and B c= ould make changes to the shared file and also retrieve or delete the file a= t any time.
2) User A has different services accounts, he could e= asily access all different services through one client app and also easily = transfer files between different clouds.
3) Since network-based s= torage services could become the "data entrance", many apps want = to work together with such services. Developers of those apps only need to = interoperate with one generalized API to support all the similar services.<= /div>
4) Enterprises may desire to have a private storage service due t= o the consideration of security and privacy. They could develop their own s= ync storage services based on a standard API or protocol.

3.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The efficiency = improvements might be the second goal for standardizing ISS protocol (I agr= ee with that, but what is the first=E2=80=A6?)

Maybe the interoperability? A generalized API or protocol to access = all services and allow sync cross the services.=C2=A0

4.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CORS headers on= storage sync APIs (sound interesting for me)

5.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please correct = me if there are still more.

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

Getting more people around, I think, will be benefit for ISS= . Therefore, one or more specific topics might be helpful. For instant, exa= ct use case and problem for ISS?

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

Fei Song

=C2=A0


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

Regards,
Linhui
--089e011836b6182fa20524caf1ad-- From nobody Sun Nov 22 01:57: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 E1CF11B2C8B for ; Sun, 22 Nov 2015 01:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.214 X-Spam-Level: X-Spam-Status: No, score=0.214 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 5z10OfSLVq7c for ; Sun, 22 Nov 2015 01:57:26 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id B751D1B2C8A for ; Sun, 22 Nov 2015 01:57:19 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygBHT6T9kVFWbWpdAA--.21013S2; Sun, 22 Nov 2015 17:59:25 +0800 (CST) Date: Sun, 22 Nov 2015 17:57:17 +0800 From: "Fei Song" To: "Linhui Sun" References: <208d822f.1c53b.15115943f39.Coremail.fsong@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201511221757169480356@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygBHT6T9kVFWbWpdAA--.21013S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCF1kZF48Kw15Xr4xJr17GFg_yoW5XF1kpF 13GF47KFZ5Jay8Aw1jvF4xWF4FvryFyrW5Zrn8Kr18Jr90yFySqr12qrWFkFyUGrWrJw1j qryq9asxuas0vrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkEb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8uwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07j7hL nUUUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync Subject: Re: [Storagesync] recent issues and next step? 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, 22 Nov 2015 09:57:29 -0000 SGkgTGluaHVpIGFuZCBhbGwsDQoNCkFjdHVhbGx5IEkgc2VudCBsYXN0IGVtYWlsIGp1c3QgdG8g c3VtbWFyaXplIHdoYXQgd2UgaGF2ZSBkaXNjdXNzZWQgaW4gdGhpcyBtYWlsaW5nIGxpc3QuDQpE aWQgd2UgbWlzcyBhbnl0aGluZyBpbiBzeW5jPw0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcN Cj5IaSBGZWksDQo+DQo+MjAxNS0xMS0xNyAyMToxMyBHTVQrMDg6MDAgPGZzb25nQGJqdHUuZWR1 LmNuPjoNCj4NCj4+IEhpLA0KPj4NCj4+DQo+Pg0KPj4gVW50aWwgbm93LCBhZnRlciByZWFkaW5n IHByZXZpb3VzIGVtYWlsLCBzZXZlcmFsIGlzc3VlcyBhcmUgc3RpbGwgaW4gbXkNCj4+IG1pbmQ6 DQo+Pg0KPj4NCj4+DQo+PiAxLiAgICAgICAgVGhlIGRlc2lnbiB0YXJnZXRzIG9mIFdlYkRBViwg cnN5bmMgYW5kIG90aGVyIGV4aXN0aW5nDQo+PiBhcHByb2FjaGVzIChhcmUgdGhlcmUgYW55IG92 ZXJsYXBzIHdpdGggSVNTPykNCj4+DQo+Rm9yIG1lLCBXZWJEQVYgYW5kIElTUyBhcmUgZGlmZmVy ZW50IGluIGFwcGxpY2FiaWxpdHkuIFdoaWxlIGEgZmFjdCBpcyB0aGF0DQo+bWFueSBvcGVuIHNv dXJjZSBzdG9yYWdlIHNlcnZpY2VzIGFyZSB1c2luZyBXZWJEYXYgdG8gZG8gdGhlIHN5bmMgKGUu Zy4NCj5vd25DbG91ZCkgbm93LiBOZWVkIGludmVzdGlnYXRpb24gaGVyZSB0byBmaW5kIGhvdyB0 aGV5IGRvIHRoYXQuDQo+DQo+PiAyLiAgICAgICAgVGhlIHBvdGVudGlhbCB1c2UgY2FzZXMgb2Yg SVNTLCBzdWNoIGFzIGNsaWVudC9zZXJ2ZXIsIGdpdC1saWtlDQo+PiBwYXR0ZXJuLCBzdm4sIGV0 Yy4gKGlzIHRoYXQgZW5vdWdoIGZvciBJU1M/KQ0KPj4NCj5JTU8sIHRoZSB1c2UgY2FzZSBpcyBu b3Qgc29tZXRoaW5nIGxpa2UgQy9TIG9yIGdpdCB3YXkuIFRoZXNlIHRoaW5ncyBzb3VuZA0KPmxp a2UgbW9kZS9wYXR0ZXJuIHdoaWNoIGNvdWxkIGJlIGRpc2N1c3NlZCBsYXRlci4gVXNlIGNhc2Vz IG1pZ2h0IGJlDQo+c29tZXRoaW5nIG1vcmUgcmVsYXRlZCB0byB0aGUgcmVxdWlyZW1lbnRzLCBw bGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nDQo+OiApDQo+DQo+UG9zc2libGUgdXNlIGNh c2VzIG9mIGEgZ2VuZXJhbGl6ZWQgQVBJIG9yIHByb3RvY29sIGluIG15IG1pbmQ6DQo+MSkgVXNl ciBBIGlzIHVzaW5nIERyb3Bib3gsIFVzZXIgQiBpcyB1c2luZyBHb29nbGVEcml2ZS4gSWYgQSBz aGFyZXMgYSBmaWxlDQo+d2l0aCBCLCB0aGV5IGNvdWxkIHdvcmsgdG9nZXRoZXIgb24gdGhhdCBm aWxlIHNpbmNlIHRoZW4uIEJvdGggQSBhbmQgQg0KPmNvdWxkIG1ha2UgY2hhbmdlcyB0byB0aGUg c2hhcmVkIGZpbGUgYW5kIGFsc28gcmV0cmlldmUgb3IgZGVsZXRlIHRoZSBmaWxlDQo+YXQgYW55 IHRpbWUuDQo+MikgVXNlciBBIGhhcyBkaWZmZXJlbnQgc2VydmljZXMgYWNjb3VudHMsIGhlIGNv dWxkIGVhc2lseSBhY2Nlc3MgYWxsDQo+ZGlmZmVyZW50IHNlcnZpY2VzIHRocm91Z2ggb25lIGNs aWVudCBhcHAgYW5kIGFsc28gZWFzaWx5IHRyYW5zZmVyIGZpbGVzDQo+YmV0d2VlbiBkaWZmZXJl bnQgY2xvdWRzLg0KPjMpIFNpbmNlIG5ldHdvcmstYmFzZWQgc3RvcmFnZSBzZXJ2aWNlcyBjb3Vs ZCBiZWNvbWUgdGhlICJkYXRhIGVudHJhbmNlIiwNCj5tYW55IGFwcHMgd2FudCB0byB3b3JrIHRv Z2V0aGVyIHdpdGggc3VjaCBzZXJ2aWNlcy4gRGV2ZWxvcGVycyBvZiB0aG9zZQ0KPmFwcHMgb25s eSBuZWVkIHRvIGludGVyb3BlcmF0ZSB3aXRoIG9uZSBnZW5lcmFsaXplZCBBUEkgdG8gc3VwcG9y dCBhbGwgdGhlDQo+c2ltaWxhciBzZXJ2aWNlcy4NCj40KSBFbnRlcnByaXNlcyBtYXkgZGVzaXJl IHRvIGhhdmUgYSBwcml2YXRlIHN0b3JhZ2Ugc2VydmljZSBkdWUgdG8gdGhlDQo+Y29uc2lkZXJh dGlvbiBvZiBzZWN1cml0eSBhbmQgcHJpdmFjeS4gVGhleSBjb3VsZCBkZXZlbG9wIHRoZWlyIG93 biBzeW5jDQo+c3RvcmFnZSBzZXJ2aWNlcyBiYXNlZCBvbiBhIHN0YW5kYXJkIEFQSSBvciBwcm90 b2NvbC4NCj4NCj4zLiAgICAgICAgVGhlIGVmZmljaWVuY3kgaW1wcm92ZW1lbnRzIG1pZ2h0IGJl IHRoZSBzZWNvbmQgZ29hbCBmb3INCj4+IHN0YW5kYXJkaXppbmcgSVNTIHByb3RvY29sIChJIGFn cmVlIHdpdGggdGhhdCwgYnV0IHdoYXQgaXMgdGhlIGZpcnN0oa0/KQ0KPj4NCj5NYXliZSB0aGUg aW50ZXJvcGVyYWJpbGl0eT8gQSBnZW5lcmFsaXplZCBBUEkgb3IgcHJvdG9jb2wgdG8gYWNjZXNz IGFsbA0KPnNlcnZpY2VzIGFuZCBhbGxvdyBzeW5jIGNyb3NzIHRoZSBzZXJ2aWNlcy4NCj4NCj4+ IDQuICAgICAgICBDT1JTIGhlYWRlcnMgb24gc3RvcmFnZSBzeW5jIEFQSXMgKHNvdW5kIGludGVy ZXN0aW5nIGZvciBtZSkNCj4+DQo+PiA1LiAgICAgICAgUGxlYXNlIGNvcnJlY3QgbWUgaWYgdGhl cmUgYXJlIHN0aWxsIG1vcmUuDQo+Pg0KPj4NCj4+DQo+PiBHZXR0aW5nIG1vcmUgcGVvcGxlIGFy b3VuZCwgSSB0aGluaywgd2lsbCBiZSBiZW5lZml0IGZvciBJU1MuIFRoZXJlZm9yZSwNCj4+IG9u ZSBvciBtb3JlIHNwZWNpZmljIHRvcGljcyBtaWdodCBiZSBoZWxwZnVsLiBGb3IgaW5zdGFudCwg ZXhhY3QgdXNlIGNhc2UNCj4+IGFuZCBwcm9ibGVtIGZvciBJU1M/DQo+Pg0KPj4NCj4+DQo+PiBG ZWkgU29uZw0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPj4gU3RvcmFnZXN5 bmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rv cmFnZXN5bmMNCj4+DQo+PiBSZWdhcmRzLA0KPkxpbmh1aQ0KPg== From nobody Sun Nov 22 02:10: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 5A5B71B2D19 for ; Sun, 22 Nov 2015 02:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 VKUuVB-MOXaG for ; Sun, 22 Nov 2015 02:10:43 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7B01B2D18 for ; Sun, 22 Nov 2015 02:10:43 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygC3v6QjlVFWKm5dAA--.21184S2; Sun, 22 Nov 2015 18:12:51 +0800 (CST) Date: Sun, 22 Nov 2015 18:10:43 +0800 From: "Fei Song" To: "Linhui Sun" References: <208d822f.1c53b.15115943f39.Coremail.fsong@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201511221810434337497@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygC3v6QjlVFWKm5dAA--.21184S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWF4UJr48JF1fur4rCF43Awb_yoW5Ww1kpr 13GF43KFZ5Xay8Aw1jva1xWFWFvryFyrW3Xrn0gr18Ar98ZFySqr42qrWFkFWDWrWrJw1j qrWq9asxuas0vrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gw1l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 ya0PUUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync Subject: [Storagesync] The potential use cases of ISS 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, 22 Nov 2015 10:10:45 -0000 SGkgTGluaHVpLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgb24gobBUaGUgcG90ZW50aWFs IHVzZSBjYXNlcyBvZiBJU1OhsQ0KDQpCYXNlZCBvbiB5b3VyIGxhc3QgZW1haWwsIGl0IHdhcyBj b25zaWRlcmVkIGZyb20gdGhyZWUgcGVyc3BlY3RpdmVzLg0KMS4JRW5kIHVzZXJzDQoyLglEZXZl bG9wZXJzDQozLglFbnRlcnByaXNlcw0KDQpJIGFtIHRoaW5raW5nIHRoYXQgd2hldGhlciBJU1As IElDUCwgQ1NQKGNsb3VkIHNlcnZpY2UgcHJvdmlkZXIpIG9yIG90aGVyIHByb3ZpZGVycyBjb3Vs ZCBhbHNvIGdldCBiZW5lZml0cyBmcm9tIElTUz8NCg0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNv bmcNCj5IaSBGZWksDQo+DQo+MjAxNS0xMS0xNyAyMToxMyBHTVQrMDg6MDAgPGZzb25nQGJqdHUu ZWR1LmNuPjoNCj4NCj4+IEhpLA0KPj4NCj4+DQo+Pg0KPj4gVW50aWwgbm93LCBhZnRlciByZWFk aW5nIHByZXZpb3VzIGVtYWlsLCBzZXZlcmFsIGlzc3VlcyBhcmUgc3RpbGwgaW4gbXkNCj4+IG1p bmQ6DQo+Pg0KPj4NCj4+DQo+PiAxLiAgICAgICAgVGhlIGRlc2lnbiB0YXJnZXRzIG9mIFdlYkRB ViwgcnN5bmMgYW5kIG90aGVyIGV4aXN0aW5nDQo+PiBhcHByb2FjaGVzIChhcmUgdGhlcmUgYW55 IG92ZXJsYXBzIHdpdGggSVNTPykNCj4+DQo+Rm9yIG1lLCBXZWJEQVYgYW5kIElTUyBhcmUgZGlm ZmVyZW50IGluIGFwcGxpY2FiaWxpdHkuIFdoaWxlIGEgZmFjdCBpcyB0aGF0DQo+bWFueSBvcGVu IHNvdXJjZSBzdG9yYWdlIHNlcnZpY2VzIGFyZSB1c2luZyBXZWJEYXYgdG8gZG8gdGhlIHN5bmMg KGUuZy4NCj5vd25DbG91ZCkgbm93LiBOZWVkIGludmVzdGlnYXRpb24gaGVyZSB0byBmaW5kIGhv dyB0aGV5IGRvIHRoYXQuDQo+DQo+PiAyLiAgICAgICAgVGhlIHBvdGVudGlhbCB1c2UgY2FzZXMg b2YgSVNTLCBzdWNoIGFzIGNsaWVudC9zZXJ2ZXIsIGdpdC1saWtlDQo+PiBwYXR0ZXJuLCBzdm4s IGV0Yy4gKGlzIHRoYXQgZW5vdWdoIGZvciBJU1M/KQ0KPj4NCj5JTU8sIHRoZSB1c2UgY2FzZSBp cyBub3Qgc29tZXRoaW5nIGxpa2UgQy9TIG9yIGdpdCB3YXkuIFRoZXNlIHRoaW5ncyBzb3VuZA0K Pmxpa2UgbW9kZS9wYXR0ZXJuIHdoaWNoIGNvdWxkIGJlIGRpc2N1c3NlZCBsYXRlci4gVXNlIGNh c2VzIG1pZ2h0IGJlDQo+c29tZXRoaW5nIG1vcmUgcmVsYXRlZCB0byB0aGUgcmVxdWlyZW1lbnRz LCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nDQo+OiApDQo+DQo+UG9zc2libGUgdXNl IGNhc2VzIG9mIGEgZ2VuZXJhbGl6ZWQgQVBJIG9yIHByb3RvY29sIGluIG15IG1pbmQ6DQo+MSkg VXNlciBBIGlzIHVzaW5nIERyb3Bib3gsIFVzZXIgQiBpcyB1c2luZyBHb29nbGVEcml2ZS4gSWYg QSBzaGFyZXMgYSBmaWxlDQo+d2l0aCBCLCB0aGV5IGNvdWxkIHdvcmsgdG9nZXRoZXIgb24gdGhh dCBmaWxlIHNpbmNlIHRoZW4uIEJvdGggQSBhbmQgQg0KPmNvdWxkIG1ha2UgY2hhbmdlcyB0byB0 aGUgc2hhcmVkIGZpbGUgYW5kIGFsc28gcmV0cmlldmUgb3IgZGVsZXRlIHRoZSBmaWxlDQo+YXQg YW55IHRpbWUuDQo+MikgVXNlciBBIGhhcyBkaWZmZXJlbnQgc2VydmljZXMgYWNjb3VudHMsIGhl IGNvdWxkIGVhc2lseSBhY2Nlc3MgYWxsDQo+ZGlmZmVyZW50IHNlcnZpY2VzIHRocm91Z2ggb25l IGNsaWVudCBhcHAgYW5kIGFsc28gZWFzaWx5IHRyYW5zZmVyIGZpbGVzDQo+YmV0d2VlbiBkaWZm ZXJlbnQgY2xvdWRzLg0KPjMpIFNpbmNlIG5ldHdvcmstYmFzZWQgc3RvcmFnZSBzZXJ2aWNlcyBj b3VsZCBiZWNvbWUgdGhlICJkYXRhIGVudHJhbmNlIiwNCj5tYW55IGFwcHMgd2FudCB0byB3b3Jr IHRvZ2V0aGVyIHdpdGggc3VjaCBzZXJ2aWNlcy4gRGV2ZWxvcGVycyBvZiB0aG9zZQ0KPmFwcHMg b25seSBuZWVkIHRvIGludGVyb3BlcmF0ZSB3aXRoIG9uZSBnZW5lcmFsaXplZCBBUEkgdG8gc3Vw cG9ydCBhbGwgdGhlDQo+c2ltaWxhciBzZXJ2aWNlcy4NCj40KSBFbnRlcnByaXNlcyBtYXkgZGVz aXJlIHRvIGhhdmUgYSBwcml2YXRlIHN0b3JhZ2Ugc2VydmljZSBkdWUgdG8gdGhlDQo+Y29uc2lk ZXJhdGlvbiBvZiBzZWN1cml0eSBhbmQgcHJpdmFjeS4gVGhleSBjb3VsZCBkZXZlbG9wIHRoZWly IG93biBzeW5jDQo+c3RvcmFnZSBzZXJ2aWNlcyBiYXNlZCBvbiBhIHN0YW5kYXJkIEFQSSBvciBw cm90b2NvbC4NCj4NCj4zLiAgICAgICAgVGhlIGVmZmljaWVuY3kgaW1wcm92ZW1lbnRzIG1pZ2h0 IGJlIHRoZSBzZWNvbmQgZ29hbCBmb3INCj4+IHN0YW5kYXJkaXppbmcgSVNTIHByb3RvY29sIChJ IGFncmVlIHdpdGggdGhhdCwgYnV0IHdoYXQgaXMgdGhlIGZpcnN0oa0/KQ0KPj4NCj5NYXliZSB0 aGUgaW50ZXJvcGVyYWJpbGl0eT8gQSBnZW5lcmFsaXplZCBBUEkgb3IgcHJvdG9jb2wgdG8gYWNj ZXNzIGFsbA0KPnNlcnZpY2VzIGFuZCBhbGxvdyBzeW5jIGNyb3NzIHRoZSBzZXJ2aWNlcy4NCj4N Cj4+IDQuICAgICAgICBDT1JTIGhlYWRlcnMgb24gc3RvcmFnZSBzeW5jIEFQSXMgKHNvdW5kIGlu dGVyZXN0aW5nIGZvciBtZSkNCj4+DQo+PiA1LiAgICAgICAgUGxlYXNlIGNvcnJlY3QgbWUgaWYg dGhlcmUgYXJlIHN0aWxsIG1vcmUuDQo+Pg0KPj4NCj4+DQo+PiBHZXR0aW5nIG1vcmUgcGVvcGxl IGFyb3VuZCwgSSB0aGluaywgd2lsbCBiZSBiZW5lZml0IGZvciBJU1MuIFRoZXJlZm9yZSwNCj4+ IG9uZSBvciBtb3JlIHNwZWNpZmljIHRvcGljcyBtaWdodCBiZSBoZWxwZnVsLiBGb3IgaW5zdGFu dCwgZXhhY3QgdXNlIGNhc2UNCj4+IGFuZCBwcm9ibGVtIGZvciBJU1M/DQo+Pg0KPj4NCj4+DQo+ PiBGZWkgU29uZw0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPj4gU3RvcmFn ZXN5bmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3RvcmFnZXN5bmMNCj4+DQo+PiBSZWdhcmRzLA0KPkxpbmh1aQ0KPg== From nobody Sun Nov 22 20:42: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 2F1D91B35CB for ; Sun, 22 Nov 2015 20:42:32 -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_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 Q7ulaRLfBALz for ; Sun, 22 Nov 2015 20:42:30 -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 86E811B35C9 for ; Sun, 22 Nov 2015 20:42:29 -0800 (PST) Received: by wmuu63 with SMTP id u63so38737472wmu.0 for ; Sun, 22 Nov 2015 20:42: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=ZfQlK7iWIi3nPBD8l8ry7Mzsoi5dWudwJS8SEIfozMA=; b=QzoJta8q0CPRWq7xVckeG6W0c7K9H/SyG6cu/mJuf272RWIePpjC19Rz5sCKdqLJ7C 4Oy4rsLE9kY9rxKatIJ06BdczLl5M+6vI4LBRrBOqKtLg1toPTVdJU7fC4A6to42ubXf N1XxLEgi6xSxCJWxv132XIL9++V2tH4oXykB5G6Rtmsbww0J4vzeH/OW8cdoQHD4/577 uN7tgfj0aCIIsreylxqSh1TPQ9HtEa3Z6630FdpWhqvmWlnBMV/q99sFWRA7+FMDr1ox 1AIb93WFVj4l6/GRyQ1R8HpIeGUq5DjwyaDzmCjveHOVy02zfOLR4zNX9EWU8W1891qw mLhA== X-Received: by 10.194.84.4 with SMTP id u4mr33464106wjy.149.1448253748055; Sun, 22 Nov 2015 20:42:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Sun, 22 Nov 2015 20:42:08 -0800 (PST) In-Reply-To: <201511221810434337497@bjtu.edu.cn> References: <208d822f.1c53b.15115943f39.Coremail.fsong@bjtu.edu.cn> <201511221810434337497@bjtu.edu.cn> From: Linhui Sun Date: Mon, 23 Nov 2015 12:42:08 +0800 Message-ID: To: fsong Content-Type: multipart/alternative; boundary=047d7bb04d3632940505252ddadf Archived-At: Cc: storagesync Subject: Re: [Storagesync] The potential use cases of ISS 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, 23 Nov 2015 04:42:32 -0000 --047d7bb04d3632940505252ddadf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fei, 2015-11-22 18:10 GMT+08:00 Fei Song : > Hi Linhui, > > Thanks for your comments on =E2=80=9CThe potential use cases of ISS=E2=80= =9D > > Based on your last email, it was considered from three perspectives. > 1. End users > 2. Developers > 3. Enterprises > > I am thinking that whether ISP, ICP, CSP(cloud service provider) or other > providers could also get benefits from ISS? > I think the ISS might have little impact on ISP since it is more an application layer problem, the ICP might potentially benefit since the data exchange is promoted (not sure just a guess). For the CSPs, as discussed in the BOF, the "interoperability" will let their data out but also let the data in. IMO, the big players might not like this currently since they may lose users. But it might be good for the remaining players or even the whole industry if the end users are happy with this (in this way, the total number of users are still increasing). Comments are welcome : ) Regards, Linhui > > > -------------- > Fei Song > >Hi Fei, > > > >2015-11-17 21:13 GMT+08:00 : > > > >> Hi, > >> > >> > >> > >> Until now, after reading previous email, several issues are still in m= y > >> mind: > >> > >> > >> > >> 1. The design targets of WebDAV, rsync and other existing > >> approaches (are there any overlaps with ISS?) > >> > >For me, WebDAV and ISS are different in applicability. While a fact is > that > >many open source storage services are using WebDav to do the sync (e.g. > >ownCloud) now. Need investigation here to find how they do that. > > > >> 2. The potential use cases of ISS, such as client/server, > git-like > >> pattern, svn, etc. (is that enough for ISS?) > >> > >IMO, the use case is not something like C/S or git way. These things sou= nd > >like mode/pattern which could be discussed later. Use cases might be > >something more related to the requirements, please correct me if I am > wrong > >: ) > > > >Possible use cases of a generalized API or protocol in my mind: > >1) User A is using Dropbox, User B is using GoogleDrive. If A shares a > file > >with B, they could work together on that file since then. Both A and B > >could make changes to the shared file and also retrieve or delete the fi= le > >at any time. > >2) User A has different services accounts, he could easily access all > >different services through one client app and also easily transfer files > >between different clouds. > >3) Since network-based storage services could become the "data entrance"= , > >many apps want to work together with such services. Developers of those > >apps only need to interoperate with one generalized API to support all t= he > >similar services. > >4) Enterprises may desire to have a private storage service due to the > >consideration of security and privacy. They could develop their own sync > >storage services based on a standard API or protocol. > > > >3. The efficiency improvements might be the second goal for > >> standardizing ISS protocol (I agree with that, but what is the first= =E2=80=A6?) > >> > >Maybe the interoperability? A generalized API or protocol to access all > >services and allow sync cross the services. > > > >> 4. CORS headers on storage sync APIs (sound interesting for me) > >> > >> 5. Please correct me if there are still more. > >> > >> > >> > >> Getting more people around, I think, will be benefit for ISS. Therefor= e, > >> one or more specific topics might be helpful. For instant, exact use > case > >> and problem for ISS? > >> > >> > >> > >> Fei Song > >> > >> > >> > >> _______________________________________________ > >> Storagesync mailing list > >> Storagesync@ietf.org > >> https://www.ietf.org/mailman/listinfo/storagesync > >> > >> Regards, > >Linhui > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > --047d7bb04d3632940505252ddadf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fei,

2015-11-22 18:10 GMT+08:00 Fei Song <fsong@bjtu.edu.cn><= /span>:
Hi Linhui,

Thanks for your comments on =E2=80=9CThe potential use cases of ISS=E2=80= =9D

Based on your last email, it was considered from three perspectives.
1.=C2=A0 =C2=A0 =C2=A0 End users
2.=C2=A0 =C2=A0 =C2=A0 Developers
3.=C2=A0 =C2=A0 =C2=A0 Enterprises

I am thinking that whether ISP, ICP, CSP(cloud service provider) or other p= roviders could also get benefits from ISS?
I think the= ISS might have little impact on ISP since it is more an application layer = problem, the ICP might potentially benefit since the data exchange is promo= ted (not sure just a guess). For the CSPs, as discussed in the BOF, the &qu= ot;interoperability" will let their data out but also let the data in.= IMO, the big players might not like this currently since they may lose use= rs. But it might be good for the remaining players or even the whole indust= ry if the end users are happy with this (in this way, the total number of u= sers are still increasing).

Comments are welcome := )

Regards,
Linhui


--------------
Fei Song
>Hi Fei,
>
>2015-11-17 21:13 GMT+08:00 <fso= ng@bjtu.edu.cn>:
>
>> Hi,
>>
>>
>>
>> Until now, after reading previous email, several issues are still = in my
>> mind:
>>
>>
>>
>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0 The design targets of WebDAV, rsync = and other existing
>> approaches (are there any overlaps with ISS?)
>>
>For me, WebDAV and ISS are different in applicability. While a fact is = that
>many open source storage services are using WebDav to do the sync (e.g.=
>ownCloud) now. Need investigation here to find how they do that.
>
>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 The potential use cases of ISS, such= as client/server, git-like
>> pattern, svn, etc. (is that enough for ISS?)
>>
>IMO, the use case is not something like C/S or git way. These things so= und
>like mode/pattern which could be discussed later. Use cases might be >something more related to the requirements, please correct me if I am w= rong
>: )
>
>Possible use cases of a generalized API or protocol in my mind:
>1) User A is using Dropbox, User B is using GoogleDrive. If A shares a = file
>with B, they could work together on that file since then. Both A and B<= br> >could make changes to the shared file and also retrieve or delete the f= ile
>at any time.
>2) User A has different services accounts, he could easily access all >different services through one client app and also easily transfer file= s
>between different clouds.
>3) Since network-based storage services could become the "data ent= rance",
>many apps want to work together with such services. Developers of those=
>apps only need to interoperate with one generalized API to support all = the
>similar services.
>4) Enterprises may desire to have a private storage service due to the<= br> >consideration of security and privacy. They could develop their own syn= c
>storage services based on a standard API or protocol.
>
>3.=C2=A0 =C2=A0 =C2=A0 =C2=A0 The efficiency improvements might be the = second goal for
>> standardizing ISS protocol (I agree with that, but what is the fir= st=E2=80=A6?)
>>
>Maybe the interoperability? A generalized API or protocol to access all=
>services and allow sync cross the services.
>
>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0 CORS headers on storage sync APIs (s= ound interesting for me)
>>
>> 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0 Please correct me if there are still= more.
>>
>>
>>
>> Getting more people around, I think, will be benefit for ISS. Ther= efore,
>> one or more specific topics might be helpful. For instant, exact u= se case
>> and problem for ISS?
>>
>>
>>
>> Fei Song
>>
>>
>>
>> _______________________________________________
>> Storagesync mailing list
>> Storagesync@ietf.org >> https://www.ietf.org/mailman/listinfo/sto= ragesync
>>
>> Regards,
>Linhui
>
_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync

--047d7bb04d3632940505252ddadf-- From nobody Mon Nov 23 21:15: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 3483A1B2D52 for ; Mon, 23 Nov 2015 21:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.814 X-Spam-Level: X-Spam-Status: No, score=0.814 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_35=0.6, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 60cbxk_bK7ez for ; Mon, 23 Nov 2015 21:15:08 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 611271B2D50 for ; Mon, 23 Nov 2015 21:15:08 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygD3_zPe8lNW5TTgAA--.17700S2; Tue, 24 Nov 2015 13:17:19 +0800 (CST) Date: Tue, 24 Nov 2015 13:15:06 +0800 From: "Fei Song" To: "Linhui Sun" References: <208d822f.1c53b.15115943f39.Coremail.fsong@bjtu.edu.cn> <201511221810434337497@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015112413150652682230@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygD3_zPe8lNW5TTgAA--.17700S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAw4DCFy7Jr13JF4fZrWDArb_yoWrCFW3pr 13JFnrKa1kJayrAw4jyw1xWF4FvryFyry5Xrn8Kr18Ar90yFyxtr47tr4FkFyDWrWrJr1U tryq9asxurn0vFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8WwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU4a 0mUUUUU X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: storagesync Subject: Re: [Storagesync] The potential use cases of ISS 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, 24 Nov 2015 05:15:11 -0000 SGkgTGluaHVpIGFuZCBhbGwsDQoNClBsZWFzZSBzZWUgbXkgcmVwbHkgaW5saW5lLg0KDQotLS0t LS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5IaSBGZWksDQo+DQo+MjAxNS0xMS0yMiAxODoxMCBHTVQr MDg6MDAgRmVpIFNvbmcgPGZzb25nQGJqdHUuZWR1LmNuPjoNCj4NCj4+IEhpIExpbmh1aSwNCj4+ DQo+PiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgb24gobBUaGUgcG90ZW50aWFsIHVzZSBjYXNl cyBvZiBJU1OhsQ0KPj4NCj4+IEJhc2VkIG9uIHlvdXIgbGFzdCBlbWFpbCwgaXQgd2FzIGNvbnNp ZGVyZWQgZnJvbSB0aHJlZSBwZXJzcGVjdGl2ZXMuDQo+PiAxLiAgICAgIEVuZCB1c2Vycw0KPj4g Mi4gICAgICBEZXZlbG9wZXJzDQo+PiAzLiAgICAgIEVudGVycHJpc2VzDQo+Pg0KPj4gSSBhbSB0 aGlua2luZyB0aGF0IHdoZXRoZXIgSVNQLCBJQ1AsIENTUChjbG91ZCBzZXJ2aWNlIHByb3ZpZGVy KSBvciBvdGhlcg0KPj4gcHJvdmlkZXJzIGNvdWxkIGFsc28gZ2V0IGJlbmVmaXRzIGZyb20gSVNT Pw0KPj4NCj5JIHRoaW5rIHRoZSBJU1MgbWlnaHQgaGF2ZSBsaXR0bGUgaW1wYWN0IG9uIElTUCBz aW5jZSBpdCBpcyBtb3JlIGFuDQo+YXBwbGljYXRpb24gbGF5ZXIgcHJvYmxlbSwgdGhlIElDUCBt aWdodCBwb3RlbnRpYWxseSBiZW5lZml0IHNpbmNlIHRoZSBkYXRhDQo+ZXhjaGFuZ2UgaXMgcHJv bW90ZWQgKG5vdCBzdXJlIGp1c3QgYSBndWVzcykuIEZvciB0aGUgQ1NQcywgYXMgZGlzY3Vzc2Vk IGluDQo+dGhlIEJPRiwgdGhlICJpbnRlcm9wZXJhYmlsaXR5IiB3aWxsIGxldCB0aGVpciBkYXRh IG91dCBidXQgYWxzbyBsZXQgdGhlDQo+ZGF0YSBpbi4gSU1PLCB0aGUgYmlnIHBsYXllcnMgbWln aHQgbm90IGxpa2UgdGhpcyBjdXJyZW50bHkgc2luY2UgdGhleSBtYXkNCj5sb3NlIHVzZXJzLiBC dXQgaXQgbWlnaHQgYmUgZ29vZCBmb3IgdGhlIHJlbWFpbmluZyBwbGF5ZXJzIG9yIGV2ZW4gdGhl DQo+d2hvbGUgaW5kdXN0cnkgaWYgdGhlIGVuZCB1c2VycyBhcmUgaGFwcHkgd2l0aCB0aGlzIChp biB0aGlzIHdheSwgdGhlIHRvdGFsDQo+bnVtYmVyIG9mIHVzZXJzIGFyZSBzdGlsbCBpbmNyZWFz aW5nKS4NCg0KKzENCg0KSW4gSVNTIGNhc2UsIHRoZSB0cmFmZmljIG9mIElTUCBhbmQgSUNQIHNo b3VsZCBub3QgYmUgY2hhbmdlZCBkcmFzdGljYWxseS4gDQpIb3dldmVyLCB3aXRoIHRoZSBjbG91 ZCBzZXJ2aWNlcyBzdGVwcGluZyBmb3J3YXJkIHRvIHRoZSBuZXh0IGxldmVsLCANCnRoZSBwYXR0 ZXJuIG9mIG9ubGluZSBzdG9yYWdlIG1pZ2h0IGJlIGNoYW5nZWQsIHdoaWNoIG1heSBmdXJ0aGVy IGluZmx1ZW5jZSB0aGUgSVNQIGFuZCBJQ1AuDQoNCkZvciBDU1AsIGl0IHdpbGwgYmUgdG91Y2hl ZCBmb3Igc3VyZS4NCg0KDQo+DQo+Q29tbWVudHMgYXJlIHdlbGNvbWUgOiApDQo+DQo+UmVnYXJk cywNCj5MaW5odWkNCj4NCj4+DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0NCj4+IEZlaSBTb25nDQo+ PiA+SGkgRmVpLA0KPj4gPg0KPj4gPjIwMTUtMTEtMTcgMjE6MTMgR01UKzA4OjAwIDxmc29uZ0Bi anR1LmVkdS5jbj46DQo+PiA+DQo+PiA+PiBIaSwNCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+ IFVudGlsIG5vdywgYWZ0ZXIgcmVhZGluZyBwcmV2aW91cyBlbWFpbCwgc2V2ZXJhbCBpc3N1ZXMg YXJlIHN0aWxsIGluIG15DQo+PiA+PiBtaW5kOg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4g MS4gICAgICAgIFRoZSBkZXNpZ24gdGFyZ2V0cyBvZiBXZWJEQVYsIHJzeW5jIGFuZCBvdGhlciBl eGlzdGluZw0KPj4gPj4gYXBwcm9hY2hlcyAoYXJlIHRoZXJlIGFueSBvdmVybGFwcyB3aXRoIElT Uz8pDQo+PiA+Pg0KPj4gPkZvciBtZSwgV2ViREFWIGFuZCBJU1MgYXJlIGRpZmZlcmVudCBpbiBh cHBsaWNhYmlsaXR5LiBXaGlsZSBhIGZhY3QgaXMNCj4+IHRoYXQNCj4+ID5tYW55IG9wZW4gc291 cmNlIHN0b3JhZ2Ugc2VydmljZXMgYXJlIHVzaW5nIFdlYkRhdiB0byBkbyB0aGUgc3luYyAoZS5n Lg0KPj4gPm93bkNsb3VkKSBub3cuIE5lZWQgaW52ZXN0aWdhdGlvbiBoZXJlIHRvIGZpbmQgaG93 IHRoZXkgZG8gdGhhdC4NCj4+ID4NCj4+ID4+IDIuICAgICAgICBUaGUgcG90ZW50aWFsIHVzZSBj YXNlcyBvZiBJU1MsIHN1Y2ggYXMgY2xpZW50L3NlcnZlciwNCj4+IGdpdC1saWtlDQo+PiA+PiBw YXR0ZXJuLCBzdm4sIGV0Yy4gKGlzIHRoYXQgZW5vdWdoIGZvciBJU1M/KQ0KPj4gPj4NCj4+ID5J TU8sIHRoZSB1c2UgY2FzZSBpcyBub3Qgc29tZXRoaW5nIGxpa2UgQy9TIG9yIGdpdCB3YXkuIFRo ZXNlIHRoaW5ncyBzb3VuZA0KPj4gPmxpa2UgbW9kZS9wYXR0ZXJuIHdoaWNoIGNvdWxkIGJlIGRp c2N1c3NlZCBsYXRlci4gVXNlIGNhc2VzIG1pZ2h0IGJlDQo+PiA+c29tZXRoaW5nIG1vcmUgcmVs YXRlZCB0byB0aGUgcmVxdWlyZW1lbnRzLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtDQo+PiB3 cm9uZw0KPj4gPjogKQ0KPj4gPg0KPj4gPlBvc3NpYmxlIHVzZSBjYXNlcyBvZiBhIGdlbmVyYWxp emVkIEFQSSBvciBwcm90b2NvbCBpbiBteSBtaW5kOg0KPj4gPjEpIFVzZXIgQSBpcyB1c2luZyBE cm9wYm94LCBVc2VyIEIgaXMgdXNpbmcgR29vZ2xlRHJpdmUuIElmIEEgc2hhcmVzIGENCj4+IGZp bGUNCj4+ID53aXRoIEIsIHRoZXkgY291bGQgd29yayB0b2dldGhlciBvbiB0aGF0IGZpbGUgc2lu Y2UgdGhlbi4gQm90aCBBIGFuZCBCDQo+PiA+Y291bGQgbWFrZSBjaGFuZ2VzIHRvIHRoZSBzaGFy ZWQgZmlsZSBhbmQgYWxzbyByZXRyaWV2ZSBvciBkZWxldGUgdGhlIGZpbGUNCj4+ID5hdCBhbnkg dGltZS4NCj4+ID4yKSBVc2VyIEEgaGFzIGRpZmZlcmVudCBzZXJ2aWNlcyBhY2NvdW50cywgaGUg Y291bGQgZWFzaWx5IGFjY2VzcyBhbGwNCj4+ID5kaWZmZXJlbnQgc2VydmljZXMgdGhyb3VnaCBv bmUgY2xpZW50IGFwcCBhbmQgYWxzbyBlYXNpbHkgdHJhbnNmZXIgZmlsZXMNCj4+ID5iZXR3ZWVu IGRpZmZlcmVudCBjbG91ZHMuDQo+PiA+MykgU2luY2UgbmV0d29yay1iYXNlZCBzdG9yYWdlIHNl cnZpY2VzIGNvdWxkIGJlY29tZSB0aGUgImRhdGEgZW50cmFuY2UiLA0KPj4gPm1hbnkgYXBwcyB3 YW50IHRvIHdvcmsgdG9nZXRoZXIgd2l0aCBzdWNoIHNlcnZpY2VzLiBEZXZlbG9wZXJzIG9mIHRo b3NlDQo+PiA+YXBwcyBvbmx5IG5lZWQgdG8gaW50ZXJvcGVyYXRlIHdpdGggb25lIGdlbmVyYWxp emVkIEFQSSB0byBzdXBwb3J0IGFsbCB0aGUNCj4+ID5zaW1pbGFyIHNlcnZpY2VzLg0KPj4gPjQp IEVudGVycHJpc2VzIG1heSBkZXNpcmUgdG8gaGF2ZSBhIHByaXZhdGUgc3RvcmFnZSBzZXJ2aWNl IGR1ZSB0byB0aGUNCj4+ID5jb25zaWRlcmF0aW9uIG9mIHNlY3VyaXR5IGFuZCBwcml2YWN5LiBU aGV5IGNvdWxkIGRldmVsb3AgdGhlaXIgb3duIHN5bmMNCj4+ID5zdG9yYWdlIHNlcnZpY2VzIGJh c2VkIG9uIGEgc3RhbmRhcmQgQVBJIG9yIHByb3RvY29sLg0KPj4gPg0KPj4gPjMuICAgICAgICBU aGUgZWZmaWNpZW5jeSBpbXByb3ZlbWVudHMgbWlnaHQgYmUgdGhlIHNlY29uZCBnb2FsIGZvcg0K Pj4gPj4gc3RhbmRhcmRpemluZyBJU1MgcHJvdG9jb2wgKEkgYWdyZWUgd2l0aCB0aGF0LCBidXQg d2hhdCBpcyB0aGUgZmlyc3ShrT8pDQo+PiA+Pg0KPj4gPk1heWJlIHRoZSBpbnRlcm9wZXJhYmls aXR5PyBBIGdlbmVyYWxpemVkIEFQSSBvciBwcm90b2NvbCB0byBhY2Nlc3MgYWxsDQo+PiA+c2Vy dmljZXMgYW5kIGFsbG93IHN5bmMgY3Jvc3MgdGhlIHNlcnZpY2VzLg0KPj4gPg0KPj4gPj4gNC4g ICAgICAgIENPUlMgaGVhZGVycyBvbiBzdG9yYWdlIHN5bmMgQVBJcyAoc291bmQgaW50ZXJlc3Rp bmcgZm9yIG1lKQ0KPj4gPj4NCj4+ID4+IDUuICAgICAgICBQbGVhc2UgY29ycmVjdCBtZSBpZiB0 aGVyZSBhcmUgc3RpbGwgbW9yZS4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEdldHRpbmcg bW9yZSBwZW9wbGUgYXJvdW5kLCBJIHRoaW5rLCB3aWxsIGJlIGJlbmVmaXQgZm9yIElTUy4gVGhl cmVmb3JlLA0KPj4gPj4gb25lIG9yIG1vcmUgc3BlY2lmaWMgdG9waWNzIG1pZ2h0IGJlIGhlbHBm dWwuIEZvciBpbnN0YW50LCBleGFjdCB1c2UNCj4+IGNhc2UNCj4+ID4+IGFuZCBwcm9ibGVtIGZv ciBJU1M/DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBGZWkgU29uZw0KPj4gPj4NCj4+ID4+ DQo+PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ID4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPj4gPj4gU3RvcmFnZXN5bmNA aWV0Zi5vcmcNCj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rv cmFnZXN5bmMNCj4+ID4+DQo+PiA+PiBSZWdhcmRzLA0KPj4gPkxpbmh1aQ0KPj4gPg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFN0b3JhZ2Vz eW5jIG1haWxpbmcgbGlzdA0KPj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+DQo+ From nobody Mon Nov 23 21:18: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 38E251B2D59 for ; Mon, 23 Nov 2015 21:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 ZT3lEO-6mh9I for ; Mon, 23 Nov 2015 21:18:43 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF6F1B2D57 for ; Mon, 23 Nov 2015 21:18:42 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygAH7iyz81NWQzXgAA--.18221S2; Tue, 24 Nov 2015 13:20:51 +0800 (CST) Date: Tue, 24 Nov 2015 13:18:44 +0800 From: "Fei Song" To: storagesync References: <208d822f.1c53b.15115943f39.Coremail.fsong@bjtu.edu.cn> <201511221810434337497@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015112413184387006231@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygAH7iyz81NWQzXgAA--.18221S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGr4UCF13WF17CFWfWryUKFg_yoWrWw1kpr 13GFnrKa1kJay8Aw40yw17WF4FvryFyrW3Xrn8Gr18Ar90yFyftr47tr1FkF9rWrWrGr1j qr1qgasxurn0vrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkKb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8WwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv 6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8HEEU UUUUU== X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Linhui Sun Subject: Re: [Storagesync] The potential use cases of ISS 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, 24 Nov 2015 05:18:45 -0000 U28sIGNhbiB3ZSBwZW5jaWwgdGhpcyB3aXRoOg0KDQoxLiAgRW5kIHVzZXJzDQoyLiAgRGV2ZWxv cGVycw0KMy4gIEVudGVycHJpc2VzDQo0LiAgQ1NQcw0KDQpBbnkgc3VwcGxlbWVudHM/IA0KDQoN Ci0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KPkhpIEZlaSwNCj4NCj4yMDE1LTExLTIyIDE4OjEw IEdNVCswODowMCBGZWkgU29uZyA8ZnNvbmdAYmp0dS5lZHUuY24+Og0KPg0KPj4gSGkgTGluaHVp LA0KPj4NCj4+IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cyBvbiChsFRoZSBwb3RlbnRpYWwgdXNl IGNhc2VzIG9mIElTU6GxDQo+Pg0KPj4gQmFzZWQgb24geW91ciBsYXN0IGVtYWlsLCBpdCB3YXMg Y29uc2lkZXJlZCBmcm9tIHRocmVlIHBlcnNwZWN0aXZlcy4NCj4+IDEuICAgICAgRW5kIHVzZXJz DQo+PiAyLiAgICAgIERldmVsb3BlcnMNCj4+IDMuICAgICAgRW50ZXJwcmlzZXMNCj4+DQo+PiBJ IGFtIHRoaW5raW5nIHRoYXQgd2hldGhlciBJU1AsIElDUCwgQ1NQKGNsb3VkIHNlcnZpY2UgcHJv dmlkZXIpIG9yIG90aGVyDQo+PiBwcm92aWRlcnMgY291bGQgYWxzbyBnZXQgYmVuZWZpdHMgZnJv bSBJU1M/DQo+Pg0KPkkgdGhpbmsgdGhlIElTUyBtaWdodCBoYXZlIGxpdHRsZSBpbXBhY3Qgb24g SVNQIHNpbmNlIGl0IGlzIG1vcmUgYW4NCj5hcHBsaWNhdGlvbiBsYXllciBwcm9ibGVtLCB0aGUg SUNQIG1pZ2h0IHBvdGVudGlhbGx5IGJlbmVmaXQgc2luY2UgdGhlIGRhdGENCj5leGNoYW5nZSBp cyBwcm9tb3RlZCAobm90IHN1cmUganVzdCBhIGd1ZXNzKS4gRm9yIHRoZSBDU1BzLCBhcyBkaXNj dXNzZWQgaW4NCj50aGUgQk9GLCB0aGUgImludGVyb3BlcmFiaWxpdHkiIHdpbGwgbGV0IHRoZWly IGRhdGEgb3V0IGJ1dCBhbHNvIGxldCB0aGUNCj5kYXRhIGluLiBJTU8sIHRoZSBiaWcgcGxheWVy cyBtaWdodCBub3QgbGlrZSB0aGlzIGN1cnJlbnRseSBzaW5jZSB0aGV5IG1heQ0KPmxvc2UgdXNl cnMuIEJ1dCBpdCBtaWdodCBiZSBnb29kIGZvciB0aGUgcmVtYWluaW5nIHBsYXllcnMgb3IgZXZl biB0aGUNCj53aG9sZSBpbmR1c3RyeSBpZiB0aGUgZW5kIHVzZXJzIGFyZSBoYXBweSB3aXRoIHRo aXMgKGluIHRoaXMgd2F5LCB0aGUgdG90YWwNCj5udW1iZXIgb2YgdXNlcnMgYXJlIHN0aWxsIGlu Y3JlYXNpbmcpLg0KPg0KPkNvbW1lbnRzIGFyZSB3ZWxjb21lIDogKQ0KPg0KPlJlZ2FyZHMsDQo+ TGluaHVpDQo+DQo+Pg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tDQo+PiBGZWkgU29uZw0KPj4gPkhp IEZlaSwNCj4+ID4NCj4+ID4yMDE1LTExLTE3IDIxOjEzIEdNVCswODowMCA8ZnNvbmdAYmp0dS5l ZHUuY24+Og0KPj4gPg0KPj4gPj4gSGksDQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBVbnRp bCBub3csIGFmdGVyIHJlYWRpbmcgcHJldmlvdXMgZW1haWwsIHNldmVyYWwgaXNzdWVzIGFyZSBz dGlsbCBpbiBteQ0KPj4gPj4gbWluZDoNCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+IDEuICAg ICAgICBUaGUgZGVzaWduIHRhcmdldHMgb2YgV2ViREFWLCByc3luYyBhbmQgb3RoZXIgZXhpc3Rp bmcNCj4+ID4+IGFwcHJvYWNoZXMgKGFyZSB0aGVyZSBhbnkgb3ZlcmxhcHMgd2l0aCBJU1M/KQ0K Pj4gPj4NCj4+ID5Gb3IgbWUsIFdlYkRBViBhbmQgSVNTIGFyZSBkaWZmZXJlbnQgaW4gYXBwbGlj YWJpbGl0eS4gV2hpbGUgYSBmYWN0IGlzDQo+PiB0aGF0DQo+PiA+bWFueSBvcGVuIHNvdXJjZSBz dG9yYWdlIHNlcnZpY2VzIGFyZSB1c2luZyBXZWJEYXYgdG8gZG8gdGhlIHN5bmMgKGUuZy4NCj4+ ID5vd25DbG91ZCkgbm93LiBOZWVkIGludmVzdGlnYXRpb24gaGVyZSB0byBmaW5kIGhvdyB0aGV5 IGRvIHRoYXQuDQo+PiA+DQo+PiA+PiAyLiAgICAgICAgVGhlIHBvdGVudGlhbCB1c2UgY2FzZXMg b2YgSVNTLCBzdWNoIGFzIGNsaWVudC9zZXJ2ZXIsDQo+PiBnaXQtbGlrZQ0KPj4gPj4gcGF0dGVy biwgc3ZuLCBldGMuIChpcyB0aGF0IGVub3VnaCBmb3IgSVNTPykNCj4+ID4+DQo+PiA+SU1PLCB0 aGUgdXNlIGNhc2UgaXMgbm90IHNvbWV0aGluZyBsaWtlIEMvUyBvciBnaXQgd2F5LiBUaGVzZSB0 aGluZ3Mgc291bmQNCj4+ID5saWtlIG1vZGUvcGF0dGVybiB3aGljaCBjb3VsZCBiZSBkaXNjdXNz ZWQgbGF0ZXIuIFVzZSBjYXNlcyBtaWdodCBiZQ0KPj4gPnNvbWV0aGluZyBtb3JlIHJlbGF0ZWQg dG8gdGhlIHJlcXVpcmVtZW50cywgcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbQ0KPj4gd3JvbmcN Cj4+ID46ICkNCj4+ID4NCj4+ID5Qb3NzaWJsZSB1c2UgY2FzZXMgb2YgYSBnZW5lcmFsaXplZCBB UEkgb3IgcHJvdG9jb2wgaW4gbXkgbWluZDoNCj4+ID4xKSBVc2VyIEEgaXMgdXNpbmcgRHJvcGJv eCwgVXNlciBCIGlzIHVzaW5nIEdvb2dsZURyaXZlLiBJZiBBIHNoYXJlcyBhDQo+PiBmaWxlDQo+ PiA+d2l0aCBCLCB0aGV5IGNvdWxkIHdvcmsgdG9nZXRoZXIgb24gdGhhdCBmaWxlIHNpbmNlIHRo ZW4uIEJvdGggQSBhbmQgQg0KPj4gPmNvdWxkIG1ha2UgY2hhbmdlcyB0byB0aGUgc2hhcmVkIGZp bGUgYW5kIGFsc28gcmV0cmlldmUgb3IgZGVsZXRlIHRoZSBmaWxlDQo+PiA+YXQgYW55IHRpbWUu DQo+PiA+MikgVXNlciBBIGhhcyBkaWZmZXJlbnQgc2VydmljZXMgYWNjb3VudHMsIGhlIGNvdWxk IGVhc2lseSBhY2Nlc3MgYWxsDQo+PiA+ZGlmZmVyZW50IHNlcnZpY2VzIHRocm91Z2ggb25lIGNs aWVudCBhcHAgYW5kIGFsc28gZWFzaWx5IHRyYW5zZmVyIGZpbGVzDQo+PiA+YmV0d2VlbiBkaWZm ZXJlbnQgY2xvdWRzLg0KPj4gPjMpIFNpbmNlIG5ldHdvcmstYmFzZWQgc3RvcmFnZSBzZXJ2aWNl cyBjb3VsZCBiZWNvbWUgdGhlICJkYXRhIGVudHJhbmNlIiwNCj4+ID5tYW55IGFwcHMgd2FudCB0 byB3b3JrIHRvZ2V0aGVyIHdpdGggc3VjaCBzZXJ2aWNlcy4gRGV2ZWxvcGVycyBvZiB0aG9zZQ0K Pj4gPmFwcHMgb25seSBuZWVkIHRvIGludGVyb3BlcmF0ZSB3aXRoIG9uZSBnZW5lcmFsaXplZCBB UEkgdG8gc3VwcG9ydCBhbGwgdGhlDQo+PiA+c2ltaWxhciBzZXJ2aWNlcy4NCj4+ID40KSBFbnRl cnByaXNlcyBtYXkgZGVzaXJlIHRvIGhhdmUgYSBwcml2YXRlIHN0b3JhZ2Ugc2VydmljZSBkdWUg dG8gdGhlDQo+PiA+Y29uc2lkZXJhdGlvbiBvZiBzZWN1cml0eSBhbmQgcHJpdmFjeS4gVGhleSBj b3VsZCBkZXZlbG9wIHRoZWlyIG93biBzeW5jDQo+PiA+c3RvcmFnZSBzZXJ2aWNlcyBiYXNlZCBv biBhIHN0YW5kYXJkIEFQSSBvciBwcm90b2NvbC4NCj4+ID4NCj4+ID4zLiAgICAgICAgVGhlIGVm ZmljaWVuY3kgaW1wcm92ZW1lbnRzIG1pZ2h0IGJlIHRoZSBzZWNvbmQgZ29hbCBmb3INCj4+ID4+ IHN0YW5kYXJkaXppbmcgSVNTIHByb3RvY29sIChJIGFncmVlIHdpdGggdGhhdCwgYnV0IHdoYXQg aXMgdGhlIGZpcnN0oa0/KQ0KPj4gPj4NCj4+ID5NYXliZSB0aGUgaW50ZXJvcGVyYWJpbGl0eT8g QSBnZW5lcmFsaXplZCBBUEkgb3IgcHJvdG9jb2wgdG8gYWNjZXNzIGFsbA0KPj4gPnNlcnZpY2Vz IGFuZCBhbGxvdyBzeW5jIGNyb3NzIHRoZSBzZXJ2aWNlcy4NCj4+ID4NCj4+ID4+IDQuICAgICAg ICBDT1JTIGhlYWRlcnMgb24gc3RvcmFnZSBzeW5jIEFQSXMgKHNvdW5kIGludGVyZXN0aW5nIGZv ciBtZSkNCj4+ID4+DQo+PiA+PiA1LiAgICAgICAgUGxlYXNlIGNvcnJlY3QgbWUgaWYgdGhlcmUg YXJlIHN0aWxsIG1vcmUuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBHZXR0aW5nIG1vcmUg cGVvcGxlIGFyb3VuZCwgSSB0aGluaywgd2lsbCBiZSBiZW5lZml0IGZvciBJU1MuIFRoZXJlZm9y ZSwNCj4+ID4+IG9uZSBvciBtb3JlIHNwZWNpZmljIHRvcGljcyBtaWdodCBiZSBoZWxwZnVsLiBG b3IgaW5zdGFudCwgZXhhY3QgdXNlDQo+PiBjYXNlDQo+PiA+PiBhbmQgcHJvYmxlbSBmb3IgSVNT Pw0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gRmVpIFNvbmcNCj4+ID4+DQo+PiA+Pg0KPj4g Pj4NCj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiA+PiBTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNCj4+ID4+IFN0b3JhZ2VzeW5jQGlldGYu b3JnDQo+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2Vz eW5jDQo+PiA+Pg0KPj4gPj4gUmVnYXJkcywNCj4+ID5MaW5odWkNCj4+ID4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBTdG9yYWdlc3luYyBt YWlsaW5nIGxpc3QNCj4+IFN0b3JhZ2VzeW5jQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+Pg0KPg== From nobody Wed Nov 25 06:45: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 6C0301B2D91 for ; Wed, 25 Nov 2015 06:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 fD4qy2nKWwAu for ; Wed, 25 Nov 2015 06:45:53 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 D2BF51B2C35 for ; Wed, 25 Nov 2015 06:45:52 -0800 (PST) Received: by wmec201 with SMTP id c201so73155947wme.1 for ; Wed, 25 Nov 2015 06:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=h0QAEFYthkGCkpUU93y5d3vbCCpuAzECoj0bHUOolTo=; b=atsAmJBe7BaYnc8Mc2fCZ0yJQVnOuXb0yAhw1ZcQ8DfLGzpV0ogJaS6AiNAeKD5nCC avWekUw2vnRQP7pDWLsLW/9h14a19DOGBtMdhPjQQrvLPm8qGU6baw0rd9YABDLvtKay IXOv6YdhiYWpTBsV2JUmrqahpMNf1IKEEj+qlL+McQD4qFh0nDnfIiqZfI4GXb0wzwh2 QhmKe/ya9rFOWBIVg94EhJg9zc/puI4o+Vli5UJe9VO4Q3J7lyYN7eYkMbTnNAjTrXvM cYfpxp78snBPhMrMU9qiI/Zz9ZLIFAxsL/uLlr+juh2x1FugN6i6El8tLFwz+kqXiFKP KdGw== X-Received: by 10.28.141.140 with SMTP id p134mr5163107wmd.6.1448462751395; Wed, 25 Nov 2015 06:45:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 25 Nov 2015 06:45:32 -0800 (PST) From: Linhui Sun Date: Wed, 25 Nov 2015 22:45:32 +0800 Message-ID: To: storagesync Content-Type: multipart/alternative; boundary=001a1146a0b0c47a0c05255e83d9 Archived-At: Subject: [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: Wed, 25 Nov 2015 14:45:55 -0000 --001a1146a0b0c47a0c05255e83d9 Content-Type: text/plain; charset=UTF-8 Hi all, As I mentioned before, I think the developers could benefit from the IETF standards. The ownCloud (https://owncloud.org/) is just an example. It is developed for those who do not trust commercial storage services and want to build their own network-based storage services. The ownCloud is using WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed for distributed work but not for the sync. Thus, I made some preliminary investigations on how the ownCloud uses WebDAV for sync purposes. A brief summary of what I've found is in the following, please correct me if I am wrong. I installed the ownCloud server (v8.2.1) on the CentOS7, and the client is a desktop client on Windows. 1. To find whether there is a change to the synced directory, the client continuously sends PROPFIND to the server at regular intervals (around 34 seconds under my observation). The server will respond a 207 Multi-Status Response to tell whether the main directory has been changed. To perform this regular check, the client will open a new TCP connection to send the PROPFIND, the server will close the existing TCP connection after responding the 207 Multi-Status Response. For the next check, the client will open another new TCP connection. 2. Every time adding (or creating) a new file to the local folder, the client will open a new TCP connection (if there is no connection existing) to send the file asap. The client will first send several PROPFINDs to find out which sub-directory has been changed. And then it sends the file using PUT. The server will respond a 201 Created Response and then terminate the connection. Currently, I haven't found any application layer chunking, all the segmentation are performed by TCP. 3. Every time I delete (or rename) a file locally, the client will also open a new TCP connection to send several PROPFINDs to find out which file has been removed (or renamed). Then it will send DELETE (or MOVE). The server will respond a 204 No Content Response (or 201 Created Response) and then terminate the connection. 4. I open a file and frequently edit and save it (actually this is what I usually do with the Dropbox). The client will send the whole file to the server every time I save the file. To summarize, it seems that the ownCloud makes heavily use of PROPFIND to achieve the sync process. Each sync operation (e.g. upload, modify and etc.) will start with sending one or more PROPFINDs. And currently, if I add a file to the server (directly from the server side via web interface), the client cannot find the change. I need to interrupt the sync and recover it to make the client be aware of the change and download the newly added file. I'm not sure whether this is caused by the sync mechanism or an improper server configuration. I need to investigate this further and also how the ownCloud works for multiple clients (or devices). For ISS, I think ownCloud has demonstrated to some extent that similar IETF protocols could be deployed and employed. The intention of this message is to investigate the current state of using WebDAV for sync purposes to see what needs to be improved here and whether we need new protocols. Comments are welcome : ) Regards, Linhui --001a1146a0b0c47a0c05255e83d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

As I mentioned before, I think = the developers could benefit from the IETF standards. The ownCloud (https://owncloud.org/) is just an example. I= t is developed for those who do not trust commercial storage services and w= ant to build their own network-based storage services. The ownCloud is usin= g WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed fo= r distributed work but not for the sync. Thus, I made some preliminary inve= stigations on how the ownCloud uses WebDAV for sync purposes. A brief summa= ry of what I've found is in the following, please correct me if I am wr= ong.

I installed the ownCloud server (v8.2.1) on t= he CentOS7, and the client is a desktop client on Windows.

1. To find whether there is a change to the synced directory, the = client continuously sends PROPFIND to the server at regular intervals (arou= nd 34 seconds under my observation). The server will respond a 207 Multi-St= atus Response to tell whether the main directory has been changed. To perfo= rm this regular check, the client will open a new TCP connection to send th= e PROPFIND, the server will close the existing TCP connection after respond= ing the 207 Multi-Status Response. For the next check, the client will open= another new TCP connection.

2. Every time adding = (or creating) a new file to the local folder, the client will open a new TC= P connection (if there is no connection existing) to send the file asap. Th= e client will first send several PROPFINDs to find out which sub-directory = has been changed. And then it sends the file using PUT. The server will res= pond a 201 Created Response and then terminate the connection. Currently, I= haven't found any application layer chunking, all the segmentation are= performed by TCP.

3. Every time I delete (or rena= me) a file locally, the client will also open a new TCP connection to send = several PROPFINDs to find out which file has been removed (or renamed). The= n it will send DELETE (or MOVE). The server will respond a 204 No Content R= esponse (or 201 Created Response) and then terminate the connection.
<= div>
4. I open a file and frequently edit and save it (actual= ly this is what I usually do with the Dropbox). The client will send the wh= ole file to the server every time I save the file.

To summarize, it seems that the ownCloud makes heavily use of PROPFIND to = achieve the sync process. Each sync operation (e.g. upload, modify and etc.= ) will start with sending one or more PROPFINDs. And currently, if I add a = file to the server (directly from the server side via web interface), the c= lient cannot find the change. I need to interrupt the sync and recover it t= o make the client be aware of the change and download the newly added file.= I'm not sure whether this is caused by the sync mechanism or an improp= er server configuration. I need to investigate this further and also how th= e ownCloud works for multiple clients (or devices).

For ISS, I think ownCloud has demonstrated to some extent that similar IE= TF protocols could be deployed and employed. The intention of this message = is to investigate the current state of using WebDAV for sync purposes to se= e what needs to be improved here and whether we need new protocols.

Comments are welcome : )

Regards= ,
Linhui


--001a1146a0b0c47a0c05255e83d9-- From nobody Wed Nov 25 09:50: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 4CA7E1A86F2 for ; Wed, 25 Nov 2015 09:50:55 -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, 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 Gx8awigFyOjX for ; Wed, 25 Nov 2015 09:50:49 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0684.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::684]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A481A86FD for ; Wed, 25 Nov 2015 09:50:48 -0800 (PST) Received: from DB4PR06CA0025.eurprd06.prod.outlook.com (10.160.40.153) by DBXPR06MB414.eurprd06.prod.outlook.com (10.141.14.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 17:50:28 +0000 Received: from DB3FFO11FD034.protection.gbl (2a01:111:f400:7e04::110) by DB4PR06CA0025.outlook.office365.com (2a01:111:e400:9851::25) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Wed, 25 Nov 2015 17:50:28 +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 DB3FFO11FD034.mail.protection.outlook.com (10.47.217.65) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Wed, 25 Nov 2015 17:50:28 +0000 Received: from cernfe03.cern.ch (188.184.36.39) by cernmxgwlb4.cern.ch (188.184.36.50) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Nov 2015 18:50:20 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE03.cern.ch ([fe80::fce6:ee57:884e:2488%13]) with mapi id 14.03.0174.001; Wed, 25 Nov 2015 18:50:20 +0100 From: Jakub Moscicki To: Linhui Sun Thread-Topic: [Storagesync] Some preliminary investigations on ownCloud Thread-Index: AQHRJ5AKSwIzN6/UrkiVkC+IcfyVd56s85oA Date: Wed, 25 Nov 2015 17:50:20 +0000 Message-ID: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [177.21.120.55] Content-Type: multipart/alternative; boundary="_000_71E522FCC6224DDEB4445CE902980823cernch_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD034; 1:c149K0c2V+CHkZSk4NRYrpuRK6ukOPuPTW5p9cg4KEeegYw9cZNqafCXPT+3wY6XfsZcnBwsTYXPh5gYswLbLzwpBsuJk2skUpOYjyXZYS8bWhlIzlK55448ekh6BTx2xGF6B1CfYtOxAcgL7nTHcJkBXQrwx2fszzpYFDVHjBRWnvkUSmt9hGe2DiJEkhgIjHvTHsnSyGPF4cnKn2uVOj6DsM0bISrFgwB4BZLB7TwbsIpkCc1K5PjSJBIBa+AE65HlP//hy892V2rcX6DKYKeTyKyXwG2F7LfDLQsuacUhk6PhWMBGbJ/abCQToF2KiMhsgbKHPQXNdHfqhXH7P+mGH6nguwA0C7wbjkw7GWfyfefQuaeEo4xJyUOO3SxPCx8deMebLGJpX0pgS2Vf9NrxkyDXNv/QlQz/HZ+uCLk= X-Forefront-Antispam-Report: CIP:188.184.36.50; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(3000300001)(438002)(199003)(24454002)(189002)(53754006)(512874002)(586003)(189998001)(3846002)(84326002)(6116002)(5004730100002)(87936001)(76176999)(11100500001)(53416004)(5007970100001)(54356999)(102836003)(19580405001)(5001970100001)(2950100001)(2900100001)(66066001)(110136002)(83716003)(74482002)(36756003)(5001920100001)(19580395003)(50986999)(300700001)(92566002)(86362001)(5250100002)(16796002)(26826002)(82746002)(16236675004)(5003600100002)(15975445007)(106116001)(106466001)(19617315012)(6806005)(5008740100001)(33656002)(1220700001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR06MB414; H:CERNMX11.cern.ch; FPR:; SPF:Pass; PTR:cernmx11.cern.ch; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB414; 2:UEJaeysgZpGOxkQI1ZedFO3vJ3h1xnwX2Dq/IANA+ehEQ17oPgze6fhbBcMQATiaM5MICjUS6xc9q02kIQvyqTbIOO939Mh9x/Smfn7hrAj87kyKpMlqcqwoTo6olm5H0Q7w33cpFs+eGirhRE9QZw==; 3:WGaZFrRw745lHbTjKqf69TKv9m2a5kYkcvorcCvzlW1umLpbYSPXUVFSF+82LI2XXiYA/LMfYL1Qx8t9ZuO59T6JOK71g+NLlR2xwPE1I6TS8FVnkLFlrJvfIW8tT1fQy6ZWRj5WW+w5qhWMXbta1YNK/FzourW9ZdOVWLxm+lM028Jd4gYnIWQNzAMy1CWD3O/yT97L0aQL1zHfqS8u4HGm4yw72ha+A8V3ZiHcvi8s4jZuPncByiDUpQUq2hARyZm29VMLzomHiryNugpUuw==; 25:6Md4g3zw9ByV2m5vzV6nDHOlZaRsA5Ued/m4frdDceUffzQdS6+iV3uJqQ++plKV88+YHC+ZzqIt/LAp+gFitgF90ZECAdEkm1SK6EI8xaV4sFKpkDsVyQxRnlLakjQQ4/GP5n6UcgGNgu/3wy4HLRM/oWOVgGVg/KICYUO2Jdpuolh6tmLFeK+O/pWzeDIxTO1AY5SOQMWuTgEGZFzRAfKGlgT+tsLDPMLnU8zFwhN+nHq55dF5j45RQgtd9m3/O2V17hmEFQzZQ1P23h4V+A== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DBXPR06MB414; X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB414; 20:no5gmrG59pDr3vtBVfwNDd0IFP657SglNcfMZ4LFjuVeoYauKxU3BMdtewjjx7YbOeS2ZhPLTj/uIMZIw4em6E/dygbg1s/aZHU4R1L5jiDcpx2wLz3bECLXv3L5P1T1EvjVsAhZ3dydrBNstgMMAJDtvsOvuLrK5JwmS2SVb5DQ6DB0Ifbte8Nt/NVmJQdMOjhtxukmBs4HviKpyIEvRyc5/6g6qEBxpxh/iMeACielfKpOTevYt+HkyufGuP++eT26AMF5Lnq54PO4TvfNY3CMbPeLlNcJ0tY0uGces06/iOvHngYz/TG2m9gGTzOyoNyM3B5XRwAZQbkhJ6BK+cQZLPXJP8VtuGX0nA30ST69aqnuPR+NuUTRW+rjHKSFH5+NaawqMSyIcHj+0aiaVy2cyfRLhEeZjbCWJAoJCShuqmmiXAXOPHIcRGusvgcwOj/H+XbRME4glBK5bqqIKbomcMqgj2VL3eq4HsXUZ5mD55XLmwqF9JYbWF9I4sbO; 4:aeKz4apXgkUqR3lHOgLaqYzquDqEPfg78Q4PuQVOPseZhoFhQSd4TqoBYWZ3bK6nuG/79Uiy1+BZMx8WlrOVLAFynWPccYQGbcOuppbIp6vaFGdzZEnHglQsdzyq47wuggVirM2+/0DTzJscspMkpUgjMwlrl3LV7VWAVhfBSfn+zrlGHLU9hb9e0o5DV08HRHIs9BYsU/8d7NTD5zjfbJqMCIYqvMsliAbgRuToXKcKY3I1rFmN8jDn8RbH2rboJIUTOTwWSxTZzIsiQDRODkKkC/3AVokORWdRqW1UNDKZ+yQvzqu9mKwlFa03Kbm7WTvej8YGBgi4RvRySDOrzK416QGzaHc1CBYGEVJAIAumzIGQT6D8Ye2aL27ildKNdAsvf6JfTMO3ccQPeJ6lH9i288NfMBuRxVXE4rwQj6TidxPd+SyKHlC8kiRVywkD 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)(5005006)(8121501046)(10201501046)(3002001); SRVR:DBXPR06MB414; BCL:0; PCL:0; RULEID:; SRVR:DBXPR06MB414; X-Forefront-PRVS: 0771670921 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DBXPR06MB414; 23:q4CUd5gA/5HQHjIbhaufOGwBGkO+fb+nJ1f2iPjSXX?= =?us-ascii?Q?hAPa/TtDODNkwWA3k2jGWpB6nCCQvbFODb1Sac490rhrHt+ltxQwl+7hJhil?= =?us-ascii?Q?XuietZAKwMB7zgnWl5GOrkEH33ONNKGGFHoYZ659wnL0Li4o1P1QWeCcdC3R?= =?us-ascii?Q?PP118sOG20DtWJSZYmwA7YocJnrAs2KDotNSELo+9ywomyyu7fZH15uAflP0?= =?us-ascii?Q?KJcof7b2jQj1YSw1ZN6iGf4L3PIW5L1FEMBqUsCh65TtSzWHhNMYxowkSjLr?= =?us-ascii?Q?7OryMf6CxK8hQNN4VEe/yAMaDWVM+Je8JcE7cN9XNTImKiikHlX3ks5AAUN6?= =?us-ascii?Q?w9wrBZ3cyi596eVqWEj37RYXiG+28p0VBNcx6VIbrn3sjV5nqlrHcHTAcOFN?= =?us-ascii?Q?xX0eM/4xIhM13sj+DC8UyynSLoVolZi4aMKdqPTyBqUxTOHt0lT6pkRA0Aiz?= =?us-ascii?Q?rs8c+lp1YSHKnzIhggEX2AJAGJtWoFSHFUf5AgMrsXQUnrbPXU5YfljDafsb?= =?us-ascii?Q?aPgLhY3XO4W7jVMcGEZfDBzS51OWD69FubuZXvHVZEoWpSrxxfNTPS1/p9pK?= =?us-ascii?Q?Pb5XJxGAx0WvEYlh0mdeyZ8TOTIdVwK0zTpdCpg7u00qIRolKYiJRp+06mmB?= =?us-ascii?Q?NpmMHZmwY67zqvB8QfbHUuyUEeWsuauChF6D3oQ1BAPVDN0/k0qMfAcSrfWd?= =?us-ascii?Q?oX0AI+3UXxJ7X2ds4Yc1Tv661vd6vgnj3osFFAqUfwfH2DBgZzuVggT//Slq?= =?us-ascii?Q?4yP4mLCWzy6dY8ExTQ6bTgiOcTN0HqkTzLxZXAM6tjM/Es809S3g7lQ5jwgv?= =?us-ascii?Q?kpFRnkJ7duuzxareAeH4yqEOp0a9Ufpstpq7O+YPPv4xZTIvQsMQbgpzG+lt?= =?us-ascii?Q?juwVfSPLe3rARB32Uc/mudfy+pUfMZvjT0aYY7KEuRdLQICS0BPMinhv+ms2?= =?us-ascii?Q?OfOs56w8wsTZirgah55GtqTmlUDiPwArI9iraEMymKsMbFL28o6Lwd9vMkdW?= =?us-ascii?Q?76FAfTMF6DuLW/lzMOLbfYzmPft7aJJFbCC9hB6CbAGaJh4aTgXWnFjHxCoy?= =?us-ascii?Q?aBB2pWtbexnSBS5JLhAXXa8XPD8fA9CEtUt9DuWm3oS8It782EToByq9+UDl?= =?us-ascii?Q?u8zgKyiDWhjaCWo5+QNM1wrhKkCvPGV1mtnaywe6/Cx4M1Y7ftwMH06ZDcOH?= =?us-ascii?Q?7djenlVS28kPMa4YHeL9InRWCOTHGvbbWIKHmDtImfaK5YfpdGk9VnyWXDHl?= =?us-ascii?Q?vg9hFCLHbDOuEt0ZI3lucRvqITozZZIAw5CjG6iOCXJlEmHQQ0sFw9AkLPmM?= =?us-ascii?Q?c7Sn1L3EV3F70vWFKpieYDthGf8RwrUVP7E7j1dxj4?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB414; 5:bzrrK/MxiECY5/jbbmdYmKutDNMlciNGrMoLMlv49rkIQNZ6/OEMy8Q9DDMsQpw7s8fQFRdFqrTDjkb6Jez1n3e3WRSu7QsqgM8O9Nm7b9jIj3HmM2Aq4262EJXAiXVl/x2ThscjtAyqDji8miPAgQ==; 24:98wornWE4JNM6UAypDacPNK6Xln3r/zjEwj6qwhr5Aqylmv2H3aRJ4GKdVDRrHlG/dOzO+LFLPeibX+V1uEG/UGYvO+d3dfxGlrbVQRhdsc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2015 17:50:28.1705 (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: DBXPR06MB414 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: Wed, 25 Nov 2015 17:50:55 -0000 --_000_71E522FCC6224DDEB4445CE902980823cernch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCldoYXQga2luZCBvZiBvdXRjb21lIGFyZSB5b3UgbG9va2luZyBmb3Igd2l0aCB0 aGlzIGFuYWx5c2lzPyBTb21lIHJlc2VhcmNoIGluIHRoaXMgYXJlYSBoYXMgYWxyZWFkeSBiZWVu IGRvbmUgb3IgaXMgYmVpbmcgZG9uZSBhcyB3ZSBzcGVhaw0KDQplLmcuICJBIHN0dWR5IG9mIGRl bHRhLXN5bmMgYW5kIG90aGVyIG9wdGltaXNhdGlvbiBpbiBIVFRQL1dlYmRhdiBzeW5jaG9uaXNh dGlvbiBwcm90b2NvbHMiDQoNCnNlZSAiVGVjaG5vbG9neSBhbmQgUmVzZWFyY2giOg0KDQpodHRw Oi8vY3MzLmV0aHouY2gvcHJvZ3JhbS5odG1sDQoNCkl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRv IHNlZSBpZiB0aGVyZSBpcyBhIHBvdGVudGlhbCBmb3IgY29sbGFib3JhdGlvbi4gT3IgbWF5YmUg d2UgYWxyZWFkeSBoYXZlIHNvbWUgaW5mb3JtYXRpb24geW91IGFyZSBsb29raW5nIGZvci4NCg0K QmVzdCByZWdhcmRzLA0KDQpKYWt1YiBNb3NjaWNraQ0KDQrigJQNCg0KDQpPbiAyNSBOb3YgMjAx NSwgYXQgMTE6NDUsIExpbmh1aSBTdW4gPGxoLnN1bmxpbmhAZ21haWwuY29tPG1haWx0bzpsaC5z dW5saW5oQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNCkFzIEkgbWVudGlvbmVkIGJl Zm9yZSwgSSB0aGluayB0aGUgZGV2ZWxvcGVycyBjb3VsZCBiZW5lZml0IGZyb20gdGhlIElFVEYg c3RhbmRhcmRzLiBUaGUgb3duQ2xvdWQgKGh0dHBzOi8vb3duY2xvdWQub3JnLykgaXMganVzdCBh biBleGFtcGxlLiBJdCBpcyBkZXZlbG9wZWQgZm9yIHRob3NlIHdobyBkbyBub3QgdHJ1c3QgY29t bWVyY2lhbCBzdG9yYWdlIHNlcnZpY2VzIGFuZCB3YW50IHRvIGJ1aWxkIHRoZWlyIG93biBuZXR3 b3JrLWJhc2VkIHN0b3JhZ2Ugc2VydmljZXMuIFRoZSBvd25DbG91ZCBpcyB1c2luZyBXZWJEQVYg KFJGQzQ5MTgpIHRvIGFjaGlldmUgdGhlIGRhdGEgc3luYy4gSU1PLCB0aGUgV2ViREFWIGlzIGRl c2lnbmVkIGZvciBkaXN0cmlidXRlZCB3b3JrIGJ1dCBub3QgZm9yIHRoZSBzeW5jLiBUaHVzLCBJ IG1hZGUgc29tZSBwcmVsaW1pbmFyeSBpbnZlc3RpZ2F0aW9ucyBvbiBob3cgdGhlIG93bkNsb3Vk IHVzZXMgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzLiBBIGJyaWVmIHN1bW1hcnkgb2Ygd2hhdCBJ J3ZlIGZvdW5kIGlzIGluIHRoZSBmb2xsb3dpbmcsIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0g d3JvbmcuDQoNCkkgaW5zdGFsbGVkIHRoZSBvd25DbG91ZCBzZXJ2ZXIgKHY4LjIuMSkgb24gdGhl IENlbnRPUzcsIGFuZCB0aGUgY2xpZW50IGlzIGEgZGVza3RvcCBjbGllbnQgb24gV2luZG93cy4N Cg0KMS4gVG8gZmluZCB3aGV0aGVyIHRoZXJlIGlzIGEgY2hhbmdlIHRvIHRoZSBzeW5jZWQgZGly ZWN0b3J5LCB0aGUgY2xpZW50IGNvbnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2Vy dmVyIGF0IHJlZ3VsYXIgaW50ZXJ2YWxzIChhcm91bmQgMzQgc2Vjb25kcyB1bmRlciBteSBvYnNl cnZhdGlvbikuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA3IE11bHRpLVN0YXR1cyBSZXNw b25zZSB0byB0ZWxsIHdoZXRoZXIgdGhlIG1haW4gZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQu IFRvIHBlcmZvcm0gdGhpcyByZWd1bGFyIGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5l dyBUQ1AgY29ubmVjdGlvbiB0byBzZW5kIHRoZSBQUk9QRklORCwgdGhlIHNlcnZlciB3aWxsIGNs b3NlIHRoZSBleGlzdGluZyBUQ1AgY29ubmVjdGlvbiBhZnRlciByZXNwb25kaW5nIHRoZSAyMDcg TXVsdGktU3RhdHVzIFJlc3BvbnNlLiBGb3IgdGhlIG5leHQgY2hlY2ssIHRoZSBjbGllbnQgd2ls bCBvcGVuIGFub3RoZXIgbmV3IFRDUCBjb25uZWN0aW9uLg0KDQoyLiBFdmVyeSB0aW1lIGFkZGlu ZyAob3IgY3JlYXRpbmcpIGEgbmV3IGZpbGUgdG8gdGhlIGxvY2FsIGZvbGRlciwgdGhlIGNsaWVu dCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gKGlmIHRoZXJlIGlzIG5vIGNvbm5lY3Rp b24gZXhpc3RpbmcpIHRvIHNlbmQgdGhlIGZpbGUgYXNhcC4gVGhlIGNsaWVudCB3aWxsIGZpcnN0 IHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZCBvdXQgd2hpY2ggc3ViLWRpcmVjdG9yeSBo YXMgYmVlbiBjaGFuZ2VkLiBBbmQgdGhlbiBpdCBzZW5kcyB0aGUgZmlsZSB1c2luZyBQVVQuIFRo ZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjAxIENyZWF0ZWQgUmVzcG9uc2UgYW5kIHRoZW4gdGVy bWluYXRlIHRoZSBjb25uZWN0aW9uLiBDdXJyZW50bHksIEkgaGF2ZW4ndCBmb3VuZCBhbnkgYXBw bGljYXRpb24gbGF5ZXIgY2h1bmtpbmcsIGFsbCB0aGUgc2VnbWVudGF0aW9uIGFyZSBwZXJmb3Jt ZWQgYnkgVENQLg0KDQozLiBFdmVyeSB0aW1lIEkgZGVsZXRlIChvciByZW5hbWUpIGEgZmlsZSBs b2NhbGx5LCB0aGUgY2xpZW50IHdpbGwgYWxzbyBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIHRv IHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZCBvdXQgd2hpY2ggZmlsZSBoYXMgYmVlbiBy ZW1vdmVkIChvciByZW5hbWVkKS4gVGhlbiBpdCB3aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4g VGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDQgTm8gQ29udGVudCBSZXNwb25zZSAob3IgMjAx IENyZWF0ZWQgUmVzcG9uc2UpIGFuZCB0aGVuIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4NCg0K NC4gSSBvcGVuIGEgZmlsZSBhbmQgZnJlcXVlbnRseSBlZGl0IGFuZCBzYXZlIGl0IChhY3R1YWxs eSB0aGlzIGlzIHdoYXQgSSB1c3VhbGx5IGRvIHdpdGggdGhlIERyb3Bib3gpLiBUaGUgY2xpZW50 IHdpbGwgc2VuZCB0aGUgd2hvbGUgZmlsZSB0byB0aGUgc2VydmVyIGV2ZXJ5IHRpbWUgSSBzYXZl IHRoZSBmaWxlLg0KDQpUbyBzdW1tYXJpemUsIGl0IHNlZW1zIHRoYXQgdGhlIG93bkNsb3VkIG1h a2VzIGhlYXZpbHkgdXNlIG9mIFBST1BGSU5EIHRvIGFjaGlldmUgdGhlIHN5bmMgcHJvY2Vzcy4g RWFjaCBzeW5jIG9wZXJhdGlvbiAoZS5nLiB1cGxvYWQsIG1vZGlmeSBhbmQgZXRjLikgd2lsbCBz dGFydCB3aXRoIHNlbmRpbmcgb25lIG9yIG1vcmUgUFJPUEZJTkRzLiBBbmQgY3VycmVudGx5LCBp ZiBJIGFkZCBhIGZpbGUgdG8gdGhlIHNlcnZlciAoZGlyZWN0bHkgZnJvbSB0aGUgc2VydmVyIHNp ZGUgdmlhIHdlYiBpbnRlcmZhY2UpLCB0aGUgY2xpZW50IGNhbm5vdCBmaW5kIHRoZSBjaGFuZ2Uu IEkgbmVlZCB0byBpbnRlcnJ1cHQgdGhlIHN5bmMgYW5kIHJlY292ZXIgaXQgdG8gbWFrZSB0aGUg Y2xpZW50IGJlIGF3YXJlIG9mIHRoZSBjaGFuZ2UgYW5kIGRvd25sb2FkIHRoZSBuZXdseSBhZGRl ZCBmaWxlLiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGlzIGlzIGNhdXNlZCBieSB0aGUgc3luYyBt ZWNoYW5pc20gb3IgYW4gaW1wcm9wZXIgc2VydmVyIGNvbmZpZ3VyYXRpb24uIEkgbmVlZCB0byBp bnZlc3RpZ2F0ZSB0aGlzIGZ1cnRoZXIgYW5kIGFsc28gaG93IHRoZSBvd25DbG91ZCB3b3JrcyBm b3IgbXVsdGlwbGUgY2xpZW50cyAob3IgZGV2aWNlcykuDQoNCkZvciBJU1MsIEkgdGhpbmsgb3du Q2xvdWQgaGFzIGRlbW9uc3RyYXRlZCB0byBzb21lIGV4dGVudCB0aGF0IHNpbWlsYXIgSUVURiBw cm90b2NvbHMgY291bGQgYmUgZGVwbG95ZWQgYW5kIGVtcGxveWVkLiBUaGUgaW50ZW50aW9uIG9m IHRoaXMgbWVzc2FnZSBpcyB0byBpbnZlc3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB1c2lu ZyBXZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgaW1wcm92 ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldyBwcm90b2NvbHMuDQoNCkNvbW1lbnRzIGFy ZSB3ZWxjb21lIDogKQ0KDQpSZWdhcmRzLA0KTGluaHVpDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0K U3RvcmFnZXN5bmNAaWV0Zi5vcmc8bWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KDQo= --_000_71E522FCC6224DDEB4445CE902980823cernch_ Content-Type: text/html; charset="utf-8" Content-ID: <389A5D5380A22E428E4552865023C8F9@cern.ch> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaGF0IGtpbmQgb2Ygb3V0Y29t ZSBhcmUgeW91IGxvb2tpbmcgZm9yIHdpdGggdGhpcyBhbmFseXNpcz8gU29tZSByZXNlYXJjaCBp biB0aGlzIGFyZWEgaGFzIGFscmVhZHkgYmVlbiBkb25lIG9yIGlzIGJlaW5nIGRvbmUgYXMgd2Ug c3BlYWsmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPmUuZy4gJnF1b3Q7QSBzdHVkeSBvZiBkZWx0YS1zeW5jIGFuZCBvdGhlciBv cHRpbWlzYXRpb24gaW4gSFRUUC9XZWJkYXYgc3luY2hvbmlzYXRpb24gcHJvdG9jb2xzJnF1b3Q7 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+c2VlICZxdW90O1RlY2hub2xvZ3kgYW5kIFJlc2VhcmNoJnF1b3Q7 OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGEgaHJlZj0iaHR0cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbCIgY2xhc3M9IiI+aHR0 cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbDwvYT48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXQgd291bGQgYmUgaW50 ZXJlc3RpbmcgdG8gc2VlIGlmIHRoZXJlIGlzIGEgcG90ZW50aWFsIGZvciBjb2xsYWJvcmF0aW9u LiBPciBtYXliZSB3ZSBhbHJlYWR5IGhhdmUgc29tZSBpbmZvcm1hdGlvbiB5b3UgYXJlIGxvb2tp bmcgZm9yLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SmFrdWIgTW9zY2lja2k8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5PbiAyNSBOb3YgMjAxNSwgYXQgMTE6NDUsIExpbmh1aSBTdW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpsaC5zdW5saW5oQGdtYWlsLmNvbSIgY2xhc3M9IiI+bGguc3VubGluaEBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkgYWxsLA0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgSSBtZW50aW9u ZWQgYmVmb3JlLCBJIHRoaW5rIHRoZSBkZXZlbG9wZXJzIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUg SUVURiBzdGFuZGFyZHMuIFRoZSBvd25DbG91ZCAoPGEgaHJlZj0iaHR0cHM6Ly9vd25jbG91ZC5v cmcvIiBjbGFzcz0iIj5odHRwczovL293bmNsb3VkLm9yZy88L2E+KSBpcyBqdXN0IGFuIGV4YW1w bGUuIEl0IGlzIGRldmVsb3BlZCBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB0cnVzdCBjb21tZXJjaWFs IHN0b3JhZ2UNCiBzZXJ2aWNlcyBhbmQgd2FudCB0byBidWlsZCB0aGVpciBvd24gbmV0d29yay1i YXNlZCBzdG9yYWdlIHNlcnZpY2VzLiBUaGUgb3duQ2xvdWQgaXMgdXNpbmcgV2ViREFWIChSRkM0 OTE4KSB0byBhY2hpZXZlIHRoZSBkYXRhIHN5bmMuIElNTywgdGhlIFdlYkRBViBpcyBkZXNpZ25l ZCBmb3IgZGlzdHJpYnV0ZWQgd29yayBidXQgbm90IGZvciB0aGUgc3luYy4gVGh1cywgSSBtYWRl IHNvbWUgcHJlbGltaW5hcnkgaW52ZXN0aWdhdGlvbnMgb24gaG93DQogdGhlIG93bkNsb3VkIHVz ZXMgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzLiBBIGJyaWVmIHN1bW1hcnkgb2Ygd2hhdCBJJ3Zl IGZvdW5kIGlzIGluIHRoZSBmb2xsb3dpbmcsIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jv bmcuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5JIGluc3RhbGxlZCB0aGUgb3duQ2xvdWQgc2VydmVyICh2OC4yLjEpIG9uIHRoZSBDZW50 T1M3LCBhbmQgdGhlIGNsaWVudCBpcyBhIGRlc2t0b3AgY2xpZW50IG9uIFdpbmRvd3MuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4xLiBU byBmaW5kIHdoZXRoZXIgdGhlcmUgaXMgYSBjaGFuZ2UgdG8gdGhlIHN5bmNlZCBkaXJlY3Rvcnks IHRoZSBjbGllbnQgY29udGludW91c2x5IHNlbmRzIFBST1BGSU5EIHRvIHRoZSBzZXJ2ZXIgYXQg cmVndWxhciBpbnRlcnZhbHMgKGFyb3VuZCAzNCBzZWNvbmRzIHVuZGVyIG15IG9ic2VydmF0aW9u KS4gVGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDcgTXVsdGktU3RhdHVzIFJlc3BvbnNlIHRv IHRlbGwgd2hldGhlcg0KIHRoZSBtYWluIGRpcmVjdG9yeSBoYXMgYmVlbiBjaGFuZ2VkLiBUbyBw ZXJmb3JtIHRoaXMgcmVndWxhciBjaGVjaywgdGhlIGNsaWVudCB3aWxsIG9wZW4gYSBuZXcgVENQ IGNvbm5lY3Rpb24gdG8gc2VuZCB0aGUgUFJPUEZJTkQsIHRoZSBzZXJ2ZXIgd2lsbCBjbG9zZSB0 aGUgZXhpc3RpbmcgVENQIGNvbm5lY3Rpb24gYWZ0ZXIgcmVzcG9uZGluZyB0aGUgMjA3IE11bHRp LVN0YXR1cyBSZXNwb25zZS4gRm9yIHRoZSBuZXh0IGNoZWNrLCB0aGUgY2xpZW50DQogd2lsbCBv cGVuIGFub3RoZXIgbmV3IFRDUCBjb25uZWN0aW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Mi4gRXZlcnkgdGltZSBhZGRpbmcgKG9y IGNyZWF0aW5nKSBhIG5ldyBmaWxlIHRvIHRoZSBsb2NhbCBmb2xkZXIsIHRoZSBjbGllbnQgd2ls bCBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIChpZiB0aGVyZSBpcyBubyBjb25uZWN0aW9uIGV4 aXN0aW5nKSB0byBzZW5kIHRoZSBmaWxlIGFzYXAuIFRoZSBjbGllbnQgd2lsbCBmaXJzdCBzZW5k IHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIHN1Yi1kaXJlY3RvcnkNCiBoYXMg YmVlbiBjaGFuZ2VkLiBBbmQgdGhlbiBpdCBzZW5kcyB0aGUgZmlsZSB1c2luZyBQVVQuIFRoZSBz ZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjAxIENyZWF0ZWQgUmVzcG9uc2UgYW5kIHRoZW4gdGVybWlu YXRlIHRoZSBjb25uZWN0aW9uLiBDdXJyZW50bHksIEkgaGF2ZW4ndCBmb3VuZCBhbnkgYXBwbGlj YXRpb24gbGF5ZXIgY2h1bmtpbmcsIGFsbCB0aGUgc2VnbWVudGF0aW9uIGFyZSBwZXJmb3JtZWQg YnkgVENQLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+My4gRXZlcnkgdGltZSBJIGRlbGV0ZSAob3IgcmVuYW1lKSBhIGZpbGUgbG9jYWxs eSwgdGhlIGNsaWVudCB3aWxsIGFsc28gb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiB0byBzZW5k IHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIGZpbGUgaGFzIGJlZW4gcmVtb3Zl ZCAob3IgcmVuYW1lZCkuIFRoZW4gaXQgd2lsbCBzZW5kIERFTEVURSAob3IgTU9WRSkuIFRoZSBz ZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA0DQogTm8gQ29udGVudCBSZXNwb25zZSAob3IgMjAxIENy ZWF0ZWQgUmVzcG9uc2UpIGFuZCB0aGVuIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjQuIEkg b3BlbiBhIGZpbGUgYW5kIGZyZXF1ZW50bHkgZWRpdCBhbmQgc2F2ZSBpdCAoYWN0dWFsbHkgdGhp cyBpcyB3aGF0IEkgdXN1YWxseSBkbyB3aXRoIHRoZSBEcm9wYm94KS4gVGhlIGNsaWVudCB3aWxs IHNlbmQgdGhlIHdob2xlIGZpbGUgdG8gdGhlIHNlcnZlciBldmVyeSB0aW1lIEkgc2F2ZSB0aGUg ZmlsZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlRvIHN1bW1hcml6ZSwgaXQgc2VlbXMgdGhhdCB0aGUgb3duQ2xvdWQgbWFrZXMgaGVh dmlseSB1c2Ugb2YgUFJPUEZJTkQgdG8gYWNoaWV2ZSB0aGUgc3luYyBwcm9jZXNzLiBFYWNoIHN5 bmMgb3BlcmF0aW9uIChlLmcuIHVwbG9hZCwgbW9kaWZ5IGFuZCBldGMuKSB3aWxsIHN0YXJ0IHdp dGggc2VuZGluZyBvbmUgb3IgbW9yZSBQUk9QRklORHMuIEFuZCBjdXJyZW50bHksIGlmIEkgYWRk IGEgZmlsZSB0byB0aGUgc2VydmVyDQogKGRpcmVjdGx5IGZyb20gdGhlIHNlcnZlciBzaWRlIHZp YSB3ZWIgaW50ZXJmYWNlKSwgdGhlIGNsaWVudCBjYW5ub3QgZmluZCB0aGUgY2hhbmdlLiBJIG5l ZWQgdG8gaW50ZXJydXB0IHRoZSBzeW5jIGFuZCByZWNvdmVyIGl0IHRvIG1ha2UgdGhlIGNsaWVu dCBiZSBhd2FyZSBvZiB0aGUgY2hhbmdlIGFuZCBkb3dubG9hZCB0aGUgbmV3bHkgYWRkZWQgZmls ZS4gSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBpcyBjYXVzZWQgYnkgdGhlIHN5bmMgbWVjaGFu aXNtDQogb3IgYW4gaW1wcm9wZXIgc2VydmVyIGNvbmZpZ3VyYXRpb24uIEkgbmVlZCB0byBpbnZl c3RpZ2F0ZSB0aGlzIGZ1cnRoZXIgYW5kIGFsc28gaG93IHRoZSBvd25DbG91ZCB3b3JrcyBmb3Ig bXVsdGlwbGUgY2xpZW50cyAob3IgZGV2aWNlcykuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Gb3IgSVNTLCBJIHRoaW5rIG93bkNsb3Vk IGhhcyBkZW1vbnN0cmF0ZWQgdG8gc29tZSBleHRlbnQgdGhhdCBzaW1pbGFyIElFVEYgcHJvdG9j b2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3llZC4gVGhlIGludGVudGlvbiBvZiB0aGlz IG1lc3NhZ2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdXNpbmcgV2Vi REFWIGZvciBzeW5jIHB1cnBvc2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkDQog aGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldyBwcm90b2NvbHMuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db21tZW50cyBhcmUgd2Vs Y29tZSA6ICk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkxpbmh1aTwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0PGJyIGNs YXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYub3JnIiBjbGFzcz0iIj5T dG9yYWdlc3luY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_71E522FCC6224DDEB4445CE902980823cernch_-- From nobody Wed Nov 25 19:11: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 0C4E61A90DC for ; Wed, 25 Nov 2015 19:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 RfLJyYvF-9Jw for ; Wed, 25 Nov 2015 19:11:50 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id A53EE1A90DE for ; Wed, 25 Nov 2015 19:11:48 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygCXncH7eFZWqGfjAA--.36995S2; Thu, 26 Nov 2015 11:14:03 +0800 (CST) Date: Thu, 26 Nov 2015 11:11:48 +0800 From: "Fei Song" To: "Linhui Sun" , storagesync References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201511261111483122529@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygCXncH7eFZWqGfjAA--.36995S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGr4fCw17XF4Utw4xXr18Xwb_yoW5KF4Dpr Z09ws3tF1kJF4xGwn7XFWUur1F9Fs3JrW3JF1kXw40yrZ8ur9aqFySyr1v9a4UGrZ3Wr1Y qF4YqrZxA3Z8A3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 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: 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: Thu, 26 Nov 2015 03:11:53 -0000 SGkgYWxsDQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+SGkgYWxsLA0KPg0KPkFzIEkg bWVudGlvbmVkIGJlZm9yZSwgSSB0aGluayB0aGUgZGV2ZWxvcGVycyBjb3VsZCBiZW5lZml0IGZy b20gdGhlIElFVEYNCj5zdGFuZGFyZHMuIFRoZSBvd25DbG91ZCAoaHR0cHM6Ly9vd25jbG91ZC5v cmcvKSBpcyBqdXN0IGFuIGV4YW1wbGUuIEl0IGlzDQo+ZGV2ZWxvcGVkIGZvciB0aG9zZSB3aG8g ZG8gbm90IHRydXN0IGNvbW1lcmNpYWwgc3RvcmFnZSBzZXJ2aWNlcyBhbmQgd2FudA0KPnRvIGJ1 aWxkIHRoZWlyIG93biBuZXR3b3JrLWJhc2VkIHN0b3JhZ2Ugc2VydmljZXMuIFRoZSBvd25DbG91 ZCBpcyB1c2luZw0KPldlYkRBViAoUkZDNDkxOCkgdG8gYWNoaWV2ZSB0aGUgZGF0YSBzeW5jLiBJ TU8sIHRoZSBXZWJEQVYgaXMgZGVzaWduZWQgZm9yDQo+ZGlzdHJpYnV0ZWQgd29yayBidXQgbm90 IGZvciB0aGUgc3luYy4gVGh1cywgSSBtYWRlIHNvbWUgcHJlbGltaW5hcnkNCj5pbnZlc3RpZ2F0 aW9ucyBvbiBob3cgdGhlIG93bkNsb3VkIHVzZXMgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzLiBB IGJyaWVmDQo+c3VtbWFyeSBvZiB3aGF0IEkndmUgZm91bmQgaXMgaW4gdGhlIGZvbGxvd2luZywg cGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbQ0KPndyb25nLg0KPg0KPkkgaW5zdGFsbGVkIHRoZSBv d25DbG91ZCBzZXJ2ZXIgKHY4LjIuMSkgb24gdGhlIENlbnRPUzcsIGFuZCB0aGUgY2xpZW50IGlz DQo+YSBkZXNrdG9wIGNsaWVudCBvbiBXaW5kb3dzLg0KPg0KPjEuIFRvIGZpbmQgd2hldGhlciB0 aGVyZSBpcyBhIGNoYW5nZSB0byB0aGUgc3luY2VkIGRpcmVjdG9yeSwgdGhlIGNsaWVudA0KPmNv bnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2VydmVyIGF0IHJlZ3VsYXIgaW50ZXJ2 YWxzIChhcm91bmQgMzQNCj5zZWNvbmRzIHVuZGVyIG15IG9ic2VydmF0aW9uKS4gVGhlIHNlcnZl ciB3aWxsIHJlc3BvbmQgYSAyMDcgTXVsdGktU3RhdHVzDQo+UmVzcG9uc2UgdG8gdGVsbCB3aGV0 aGVyIHRoZSBtYWluIGRpcmVjdG9yeSBoYXMgYmVlbiBjaGFuZ2VkLiBUbyBwZXJmb3JtDQo+dGhp cyByZWd1bGFyIGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlv biB0byBzZW5kIHRoZQ0KPlBST1BGSU5ELCB0aGUgc2VydmVyIHdpbGwgY2xvc2UgdGhlIGV4aXN0 aW5nIFRDUCBjb25uZWN0aW9uIGFmdGVyDQo+cmVzcG9uZGluZyB0aGUgMjA3IE11bHRpLVN0YXR1 cyBSZXNwb25zZS4gRm9yIHRoZSBuZXh0IGNoZWNrLCB0aGUgY2xpZW50DQo+d2lsbCBvcGVuIGFu b3RoZXIgbmV3IFRDUCBjb25uZWN0aW9uLg0KDQpJIHdvbmRlciB3aGV0aGVyIHRoZXNlIG1lc3Nh Z2UgeW91IGdvdCBoYWQgYmVlbiBlbmNyeXB0IG9yIG5vdC4NCg0KPg0KPjIuIEV2ZXJ5IHRpbWUg YWRkaW5nIChvciBjcmVhdGluZykgYSBuZXcgZmlsZSB0byB0aGUgbG9jYWwgZm9sZGVyLCB0aGUN Cj5jbGllbnQgd2lsbCBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIChpZiB0aGVyZSBpcyBubyBj b25uZWN0aW9uIGV4aXN0aW5nKQ0KPnRvIHNlbmQgdGhlIGZpbGUgYXNhcC4gVGhlIGNsaWVudCB3 aWxsIGZpcnN0IHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZA0KPm91dCB3aGljaCBzdWIt ZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQuIEFuZCB0aGVuIGl0IHNlbmRzIHRoZSBmaWxlIHVz aW5nDQo+UFVULiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwMSBDcmVhdGVkIFJlc3BvbnNl IGFuZCB0aGVuIHRlcm1pbmF0ZSB0aGUNCj5jb25uZWN0aW9uLiBDdXJyZW50bHksIEkgaGF2ZW4n dCBmb3VuZCBhbnkgYXBwbGljYXRpb24gbGF5ZXIgY2h1bmtpbmcsIGFsbA0KPnRoZSBzZWdtZW50 YXRpb24gYXJlIHBlcmZvcm1lZCBieSBUQ1AuDQo+DQo+My4gRXZlcnkgdGltZSBJIGRlbGV0ZSAo b3IgcmVuYW1lKSBhIGZpbGUgbG9jYWxseSwgdGhlIGNsaWVudCB3aWxsIGFsc28NCj5vcGVuIGEg bmV3IFRDUCBjb25uZWN0aW9uIHRvIHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZCBvdXQg d2hpY2ggZmlsZQ0KPmhhcyBiZWVuIHJlbW92ZWQgKG9yIHJlbmFtZWQpLiBUaGVuIGl0IHdpbGwg c2VuZCBERUxFVEUgKG9yIE1PVkUpLiBUaGUNCj5zZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA0IE5v IENvbnRlbnQgUmVzcG9uc2UgKG9yIDIwMSBDcmVhdGVkIFJlc3BvbnNlKSBhbmQNCj50aGVuIHRl cm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4NCj4NCj40LiBJIG9wZW4gYSBmaWxlIGFuZCBmcmVxdWVu dGx5IGVkaXQgYW5kIHNhdmUgaXQgKGFjdHVhbGx5IHRoaXMgaXMgd2hhdCBJDQo+dXN1YWxseSBk byB3aXRoIHRoZSBEcm9wYm94KS4gVGhlIGNsaWVudCB3aWxsIHNlbmQgdGhlIHdob2xlIGZpbGUg dG8gdGhlDQo+c2VydmVyIGV2ZXJ5IHRpbWUgSSBzYXZlIHRoZSBmaWxlLg0KPg0KPlRvIHN1bW1h cml6ZSwgaXQgc2VlbXMgdGhhdCB0aGUgb3duQ2xvdWQgbWFrZXMgaGVhdmlseSB1c2Ugb2YgUFJP UEZJTkQgdG8NCj5hY2hpZXZlIHRoZSBzeW5jIHByb2Nlc3MuIEVhY2ggc3luYyBvcGVyYXRpb24g KGUuZy4gdXBsb2FkLCBtb2RpZnkgYW5kDQo+ZXRjLikgd2lsbCBzdGFydCB3aXRoIHNlbmRpbmcg b25lIG9yIG1vcmUgUFJPUEZJTkRzLiBBbmQgY3VycmVudGx5LCBpZiBJDQo+YWRkIGEgZmlsZSB0 byB0aGUgc2VydmVyIChkaXJlY3RseSBmcm9tIHRoZSBzZXJ2ZXIgc2lkZSB2aWEgd2ViIGludGVy ZmFjZSksDQo+dGhlIGNsaWVudCBjYW5ub3QgZmluZCB0aGUgY2hhbmdlLiBJIG5lZWQgdG8gaW50 ZXJydXB0IHRoZSBzeW5jIGFuZCByZWNvdmVyDQo+aXQgdG8gbWFrZSB0aGUgY2xpZW50IGJlIGF3 YXJlIG9mIHRoZSBjaGFuZ2UgYW5kIGRvd25sb2FkIHRoZSBuZXdseSBhZGRlZA0KPmZpbGUuIEkn bSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgY2F1c2VkIGJ5IHRoZSBzeW5jIG1lY2hhbmlzbSBv ciBhbg0KPmltcHJvcGVyIHNlcnZlciBjb25maWd1cmF0aW9uLiBJIG5lZWQgdG8gaW52ZXN0aWdh dGUgdGhpcyBmdXJ0aGVyIGFuZCBhbHNvDQo+aG93IHRoZSBvd25DbG91ZCB3b3JrcyBmb3IgbXVs dGlwbGUgY2xpZW50cyAob3IgZGV2aWNlcykuDQoNCldoYXQgZG8geW91IG1lYW4gYnkgImRpcmVj dGx5IGZyb20gdGhlIHNlcnZlciBzaWRlIHZpYSB3ZWIgaW50ZXJmYWNlIi4NCklmIGFsbCB0aGUg Y29uZmlndXJhdGlvbiB3ZXJlIGNvcnJlY3QsIGRvIHlvdSB3YW50IHRvIGlkZW50aWZ5IHRoYXQg dGhlIHN5bmMgaW4gDQpvd25DbG91ZCBpcyBvbmx5IHVuaWRpcmVjdGlvbmFsPw0KDQo+DQo+Rm9y IElTUywgSSB0aGluayBvd25DbG91ZCBoYXMgZGVtb25zdHJhdGVkIHRvIHNvbWUgZXh0ZW50IHRo YXQgc2ltaWxhciBJRVRGDQo+cHJvdG9jb2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3ll ZC4gVGhlIGludGVudGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMNCj50byBpbnZlc3RpZ2F0ZSB0aGUg Y3VycmVudCBzdGF0ZSBvZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMgdG8gc2VlDQo+ d2hhdCBuZWVkcyB0byBiZSBpbXByb3ZlZCBoZXJlIGFuZCB3aGV0aGVyIHdlIG5lZWQgbmV3IHBy b3RvY29scy4NCg0KDQo+DQo+Q29tbWVudHMgYXJlIHdlbGNvbWUgOiApDQo+DQo+UmVnYXJkcywN Cj5MaW5odWkNCj4= From nobody Wed Nov 25 19:20: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 CA8A41A9127 for ; Wed, 25 Nov 2015 19:20:17 -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 0mwwi6qmN_O3 for ; Wed, 25 Nov 2015 19:20:15 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 9846B1A9123 for ; Wed, 25 Nov 2015 19:20:14 -0800 (PST) Received: by wmvv187 with SMTP id v187so12321272wmv.1 for ; Wed, 25 Nov 2015 19:20:13 -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=Reor16vtJATUE+CPBa8ajwQ7svs42DAgIjBB1llnZik=; b=WgUcJW/jTwi85FNfFdlxPSOodjuG/sZ5LEZHQw8ZQtjeipwQ13e0MHx68Xg+hsfETH CsS68F2JIMEjM9fGlYlIPJfTtqqmZ3MK4x6ZP0ZyW9WD+DF4Pjzy6F1xbamL575yPNO7 Y8xxg/VP05B4kfMV68je4Kuu4p1FWdQcklL8sssBVeAGaSasNmqHTK/fCt176+CPPKOL 86q8W232rRRAoaikX++oTwyl1QK0Mfy8S0Kk0oSA+erufnyOAIg1cfC9olEYeljZr6fy 6h2aS/sbSRmt2lnVJDDeF+rzl/hx5LgjXtS9VnRWI/Pm159h3v3LvY1mOLKGdiZ9t6oY wwKQ== X-Received: by 10.194.79.72 with SMTP id h8mr51457879wjx.136.1448508013080; Wed, 25 Nov 2015 19:20:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 25 Nov 2015 19:19:53 -0800 (PST) In-Reply-To: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> From: Linhui Sun Date: Thu, 26 Nov 2015 11:19:53 +0800 Message-ID: To: Jakub Moscicki Content-Type: multipart/alternative; boundary=047d7bb0499e92f6b00525690d1f 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: Thu, 26 Nov 2015 03:20:18 -0000 --047d7bb0499e92f6b00525690d1f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jakub, 2015-11-26 1:50 GMT+08:00 Jakub Moscicki : > Hello, > > What kind of outcome are you looking for with this analysis? Some researc= h > in this area has already been done or is being done as we speak > I think this is for the previous confusion that "why do we need the ISS over the existing WebDAV". As we could find that many open source projects are using WebDAV now (ownCloud is a popular example), we need to find out whether WebDAV is sufficient for this kind of applications. IMO, the developers for those applications might be the active users of the ISS work, thus finding out what do they lack, what do they want is important. > > e.g. "A study of delta-sync and other optimisation in HTTP/Webdav > synchonisation protocols" > > see "Technology and Research": > > http://cs3.ethz.ch/program.html > Actually I'm not talking about the efficiency or optimization here. What I really want to say is the applicability. If we find the WebDAV is enough and appropriate, then for ISS, a generalized API to access all services and for collaboration would be better than a sync protocol. > > It would be interesting to see if there is a potential for collaboration. > Or maybe we already have some information you are looking for. > The collaboration is really important but is based on the fact that many providers are willing to use it. At the current stage, I think we need to find someone who are willing to deploy and use the possible ISS work, maybe ownCloud is a potential user : ) Regards, Linhui > > Best regards, > > Jakub Moscicki > > =E2=80=94 > > > On 25 Nov 2015, at 11:45, Linhui Sun wrote: > > Hi all, > > As I mentioned before, I think the developers could benefit from the IETF > standards. The ownCloud (https://owncloud.org/) is just an example. It is > developed for those who do not trust commercial storage services and want > to build their own network-based storage services. The ownCloud is using > WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed fo= r > distributed work but not for the sync. Thus, I made some preliminary > investigations on how the ownCloud uses WebDAV for sync purposes. A brief > summary of what I've found is in the following, please correct me if I am > wrong. > > I installed the ownCloud server (v8.2.1) on the CentOS7, and the client i= s > a desktop client on Windows. > > 1. To find whether there is a change to the synced directory, the client > continuously sends PROPFIND to the server at regular intervals (around 34 > seconds under my observation). The server will respond a 207 Multi-Status > Response to tell whether the main directory has been changed. To perform > this regular check, the client will open a new TCP connection to send the > PROPFIND, the server will close the existing TCP connection after > responding the 207 Multi-Status Response. For the next check, the client > will open another new TCP connection. > > 2. Every time adding (or creating) a new file to the local folder, the > client will open a new TCP connection (if there is no connection existing= ) > to send the file asap. The client will first send several PROPFINDs to fi= nd > out which sub-directory has been changed. And then it sends the file usin= g > PUT. The server will respond a 201 Created Response and then terminate th= e > connection. Currently, I haven't found any application layer chunking, al= l > the segmentation are performed by TCP. > > 3. Every time I delete (or rename) a file locally, the client will also > open a new TCP connection to send several PROPFINDs to find out which fil= e > has been removed (or renamed). Then it will send DELETE (or MOVE). The > server will respond a 204 No Content Response (or 201 Created Response) a= nd > then terminate the connection. > > 4. I open a file and frequently edit and save it (actually this is what I > usually do with the Dropbox). The client will send the whole file to the > server every time I save the file. > > To summarize, it seems that the ownCloud makes heavily use of PROPFIND to > achieve the sync process. Each sync operation (e.g. upload, modify and > etc.) will start with sending one or more PROPFINDs. And currently, if I > add a file to the server (directly from the server side via web interface= ), > the client cannot find the change. I need to interrupt the sync and recov= er > it to make the client be aware of the change and download the newly added > file. I'm not sure whether this is caused by the sync mechanism or an > improper server configuration. I need to investigate this further and als= o > how the ownCloud works for multiple clients (or devices). > > For ISS, I think ownCloud has demonstrated to some extent that similar > IETF protocols could be deployed and employed. The intention of this > message is to investigate the current state of using WebDAV for sync > purposes to see what needs to be improved here and whether we need new > protocols. > > Comments are welcome : ) > > Regards, > Linhui > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > > > --047d7bb0499e92f6b00525690d1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jakub,

2015-11-26 1:50 GMT+08:00 Jakub Moscicki <Jakub.Moscicki@cer= n.ch>:
Hello,

What kind of outcome are you looking for with this analysis? Some rese= arch in this area has already been done or is being done as we speak=C2=A0<= /div>
I think this is for the previous confusion tha= t "why do we need the ISS over the existing WebDAV". As we could = find that many open source projects are using WebDAV now (ownCloud is a pop= ular example), we need to find out whether WebDAV is sufficient for this ki= nd of applications. IMO, the developers for those applications might be the= active users of the ISS work, thus finding out what do they lack, what do = they want is important.

e.g. "A study of delta-sync and other optimisation in HTTP/Webdav= synchonisation protocols"

see "Technology and Research":

Actually I&#= 39;m not talking about the efficiency or optimization here. What I really w= ant to say is the applicability. If we find the WebDAV is enough and approp= riate, then for ISS, a generalized API to access all services and for colla= boration would be better than a sync protocol.

It would be interesting to see if there is a potential for collaborati= on. Or maybe we already have some information you are looking for.
The collaboration is really important but is based on = the fact that many providers are willing to use it. At the current stage, I= think we need to find someone who are willing to deploy and use the possib= le ISS work, maybe ownCloud is a potential user : )

Regards,
Linhui

Best regards,

Jakub Moscicki

=E2=80=94


On 25 Nov 2015, at 11:45, Linhui Sun <lh.sunlinh@gmail.com> wrote:

Hi all,

As I mentioned before, I think the developers could benefit from the I= ETF standards. The ownCloud (https://owncloud.org/) is just an example. It is developed for th= ose who do not trust commercial storage services and want to build their own network-based storage services. The o= wnCloud is using WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV= is designed for distributed work but not for the sync. Thus, I made some p= reliminary investigations on how the ownCloud uses WebDAV for sync purposes. A brief summary of what I'= ve found is in the following, please correct me if I am wrong.

I installed the ownCloud server (v8.2.1) on the CentOS7, and the clien= t is a desktop client on Windows.

1. To find whether there is a change to the synced directory, the clie= nt continuously sends PROPFIND to the server at regular intervals (around 3= 4 seconds under my observation). The server will respond a 207 Multi-Status= Response to tell whether the main directory has been changed. To perform this regular check, the cl= ient will open a new TCP connection to send the PROPFIND, the server will c= lose the existing TCP connection after responding the 207 Multi-Status Resp= onse. For the next check, the client will open another new TCP connection.

2. Every time adding (or creating) a new file to the local folder, the= client will open a new TCP connection (if there is no connection existing)= to send the file asap. The client will first send several PROPFINDs to fin= d out which sub-directory has been changed. And then it sends the file using PUT. The server will re= spond a 201 Created Response and then terminate the connection. Currently, = I haven't found any application layer chunking, all the segmentation ar= e performed by TCP.

3. Every time I delete (or rename) a file locally, the client will als= o open a new TCP connection to send several PROPFINDs to find out which fil= e has been removed (or renamed). Then it will send DELETE (or MOVE). The se= rver will respond a 204 No Content Response (or 201 Created Response) and then terminate the conne= ction.

4. I open a file and frequently edit and save it (actually this is wha= t I usually do with the Dropbox). The client will send the whole file to th= e server every time I save the file.

To summarize, it seems that the ownCloud makes heavily use of PROPFIND= to achieve the sync process. Each sync operation (e.g. upload, modify and = etc.) will start with sending one or more PROPFINDs. And currently, if I ad= d a file to the server (directly from the server side via web interface), the client cannot find = the change. I need to interrupt the sync and recover it to make the client = be aware of the change and download the newly added file. I'm not sure = whether this is caused by the sync mechanism or an improper server configuration. I need to investigate this further an= d also how the ownCloud works for multiple clients (or devices).

For ISS, I think ownCloud has demonstrated to some extent that similar= IETF protocols could be deployed and employed. The intention of this messa= ge is to investigate the current state of using WebDAV for sync purposes to= see what needs to be improved here and whether we need new protocols.

Comments are welcome : )

Regards,
Linhui


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


--047d7bb0499e92f6b00525690d1f-- From nobody Wed Nov 25 19:20: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 7416D1A9123 for ; Wed, 25 Nov 2015 19:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 0ohy-fp3h9wK for ; Wed, 25 Nov 2015 19:20:34 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAB31A9127 for ; Wed, 25 Nov 2015 19:20:33 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygC3vsIAe1ZWhWrjAA--.9419S2; Thu, 26 Nov 2015 11:22:40 +0800 (CST) Date: Thu, 26 Nov 2015 11:20:25 +0800 From: "Fei Song" To: "Jakub Moscicki" , "Linhui Sun" References: , <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015112611202500034610@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygC3vsIAe1ZWhWrjAA--.9419S2 X-Coremail-Antispam: 1UD129KBjvJXoWxuF17ZrWUArWxGF13JF4UCFg_yoWrCryrpr Z093WkKa4kJr4xGwn7X34j9r10vFZ7JrW7JFn5J3y0yrZ8WF9aqFyIyrs09a4UGrZ3Gr4Y qF4FgFZxC3Z8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 EJm5UUUUU== 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: Thu, 26 Nov 2015 03:20:39 -0000 SGkgSmFrdWIgYW5kIGFsbCwNCg0KSSBjYW4ndCBkb3dubG9hZCB0aGUgcGFwZXIgeW91IG1lbnRp b25lZC4gQ291bGQgeW91IHBsZWFzZSBzaG93IG1lIGEgbGluayB0byBpdD8NCkZvciB0aGUgVVJM IGh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwgLHRoZXJlIGlzIG5vIGxpbmtzLi4uIA0K DQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KPkhlbGxvLA0KPg0KPldoYXQga2luZCBvZiBv dXRjb21lIGFyZSB5b3UgbG9va2luZyBmb3Igd2l0aCB0aGlzIGFuYWx5c2lzPyBTb21lIHJlc2Vh cmNoIGluIHRoaXMgYXJlYSBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgb3IgaXMgYmVpbmcgZG9uZSBh cyB3ZSBzcGVhaw0KPg0KPmUuZy4gIkEgc3R1ZHkgb2YgZGVsdGEtc3luYyBhbmQgb3RoZXIgb3B0 aW1pc2F0aW9uIGluIEhUVFAvV2ViZGF2IHN5bmNob25pc2F0aW9uIHByb3RvY29scyINCj4NCj5z ZWUgIlRlY2hub2xvZ3kgYW5kIFJlc2VhcmNoIjoNCj4NCj5odHRwOi8vY3MzLmV0aHouY2gvcHJv Z3JhbS5odG1sDQo+DQo+SXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gc2VlIGlmIHRoZXJlIGlz IGEgcG90ZW50aWFsIGZvciBjb2xsYWJvcmF0aW9uLiBPciBtYXliZSB3ZSBhbHJlYWR5IGhhdmUg c29tZSBpbmZvcm1hdGlvbiB5b3UgYXJlIGxvb2tpbmcgZm9yLg0KPg0KPkJlc3QgcmVnYXJkcywN Cj4NCj5KYWt1YiBNb3NjaWNraQ0KPg0KPqGqDQo+DQo+DQo+T24gMjUgTm92IDIwMTUsIGF0IDEx OjQ1LCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbTxtYWlsdG86bGguc3VubGluaEBn bWFpbC5jb20+PiB3cm90ZToNCj4NCj5IaSBhbGwsDQo+DQo+QXMgSSBtZW50aW9uZWQgYmVmb3Jl LCBJIHRoaW5rIHRoZSBkZXZlbG9wZXJzIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgSUVURiBzdGFu ZGFyZHMuIFRoZSBvd25DbG91ZCAoaHR0cHM6Ly9vd25jbG91ZC5vcmcvKSBpcyBqdXN0IGFuIGV4 YW1wbGUuIEl0IGlzIGRldmVsb3BlZCBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB0cnVzdCBjb21tZXJj aWFsIHN0b3JhZ2Ugc2VydmljZXMgYW5kIHdhbnQgdG8gYnVpbGQgdGhlaXIgb3duIG5ldHdvcmst YmFzZWQgc3RvcmFnZSBzZXJ2aWNlcy4gVGhlIG93bkNsb3VkIGlzIHVzaW5nIFdlYkRBViAoUkZD NDkxOCkgdG8gYWNoaWV2ZSB0aGUgZGF0YSBzeW5jLiBJTU8sIHRoZSBXZWJEQVYgaXMgZGVzaWdu ZWQgZm9yIGRpc3RyaWJ1dGVkIHdvcmsgYnV0IG5vdCBmb3IgdGhlIHN5bmMuIFRodXMsIEkgbWFk ZSBzb21lIHByZWxpbWluYXJ5IGludmVzdGlnYXRpb25zIG9uIGhvdyB0aGUgb3duQ2xvdWQgdXNl cyBXZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMuIEEgYnJpZWYgc3VtbWFyeSBvZiB3aGF0IEkndmUg Zm91bmQgaXMgaW4gdGhlIGZvbGxvd2luZywgcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9u Zy4NCj4NCj5JIGluc3RhbGxlZCB0aGUgb3duQ2xvdWQgc2VydmVyICh2OC4yLjEpIG9uIHRoZSBD ZW50T1M3LCBhbmQgdGhlIGNsaWVudCBpcyBhIGRlc2t0b3AgY2xpZW50IG9uIFdpbmRvd3MuDQo+ DQo+MS4gVG8gZmluZCB3aGV0aGVyIHRoZXJlIGlzIGEgY2hhbmdlIHRvIHRoZSBzeW5jZWQgZGly ZWN0b3J5LCB0aGUgY2xpZW50IGNvbnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2Vy dmVyIGF0IHJlZ3VsYXIgaW50ZXJ2YWxzIChhcm91bmQgMzQgc2Vjb25kcyB1bmRlciBteSBvYnNl cnZhdGlvbikuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA3IE11bHRpLVN0YXR1cyBSZXNw b25zZSB0byB0ZWxsIHdoZXRoZXIgdGhlIG1haW4gZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQu IFRvIHBlcmZvcm0gdGhpcyByZWd1bGFyIGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5l dyBUQ1AgY29ubmVjdGlvbiB0byBzZW5kIHRoZSBQUk9QRklORCwgdGhlIHNlcnZlciB3aWxsIGNs b3NlIHRoZSBleGlzdGluZyBUQ1AgY29ubmVjdGlvbiBhZnRlciByZXNwb25kaW5nIHRoZSAyMDcg TXVsdGktU3RhdHVzIFJlc3BvbnNlLiBGb3IgdGhlIG5leHQgY2hlY2ssIHRoZSBjbGllbnQgd2ls bCBvcGVuIGFub3RoZXIgbmV3IFRDUCBjb25uZWN0aW9uLg0KPg0KPjIuIEV2ZXJ5IHRpbWUgYWRk aW5nIChvciBjcmVhdGluZykgYSBuZXcgZmlsZSB0byB0aGUgbG9jYWwgZm9sZGVyLCB0aGUgY2xp ZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiAoaWYgdGhlcmUgaXMgbm8gY29ubmVj dGlvbiBleGlzdGluZykgdG8gc2VuZCB0aGUgZmlsZSBhc2FwLiBUaGUgY2xpZW50IHdpbGwgZmly c3Qgc2VuZCBzZXZlcmFsIFBST1BGSU5EcyB0byBmaW5kIG91dCB3aGljaCBzdWItZGlyZWN0b3J5 IGhhcyBiZWVuIGNoYW5nZWQuIEFuZCB0aGVuIGl0IHNlbmRzIHRoZSBmaWxlIHVzaW5nIFBVVC4g VGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDEgQ3JlYXRlZCBSZXNwb25zZSBhbmQgdGhlbiB0 ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24uIEN1cnJlbnRseSwgSSBoYXZlbid0IGZvdW5kIGFueSBh cHBsaWNhdGlvbiBsYXllciBjaHVua2luZywgYWxsIHRoZSBzZWdtZW50YXRpb24gYXJlIHBlcmZv cm1lZCBieSBUQ1AuDQo+DQo+My4gRXZlcnkgdGltZSBJIGRlbGV0ZSAob3IgcmVuYW1lKSBhIGZp bGUgbG9jYWxseSwgdGhlIGNsaWVudCB3aWxsIGFsc28gb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlv biB0byBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIGZpbGUgaGFzIGJl ZW4gcmVtb3ZlZCAob3IgcmVuYW1lZCkuIFRoZW4gaXQgd2lsbCBzZW5kIERFTEVURSAob3IgTU9W RSkuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA0IE5vIENvbnRlbnQgUmVzcG9uc2UgKG9y IDIwMSBDcmVhdGVkIFJlc3BvbnNlKSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24u DQo+DQo+NC4gSSBvcGVuIGEgZmlsZSBhbmQgZnJlcXVlbnRseSBlZGl0IGFuZCBzYXZlIGl0IChh Y3R1YWxseSB0aGlzIGlzIHdoYXQgSSB1c3VhbGx5IGRvIHdpdGggdGhlIERyb3Bib3gpLiBUaGUg Y2xpZW50IHdpbGwgc2VuZCB0aGUgd2hvbGUgZmlsZSB0byB0aGUgc2VydmVyIGV2ZXJ5IHRpbWUg SSBzYXZlIHRoZSBmaWxlLg0KPg0KPlRvIHN1bW1hcml6ZSwgaXQgc2VlbXMgdGhhdCB0aGUgb3du Q2xvdWQgbWFrZXMgaGVhdmlseSB1c2Ugb2YgUFJPUEZJTkQgdG8gYWNoaWV2ZSB0aGUgc3luYyBw cm9jZXNzLiBFYWNoIHN5bmMgb3BlcmF0aW9uIChlLmcuIHVwbG9hZCwgbW9kaWZ5IGFuZCBldGMu KSB3aWxsIHN0YXJ0IHdpdGggc2VuZGluZyBvbmUgb3IgbW9yZSBQUk9QRklORHMuIEFuZCBjdXJy ZW50bHksIGlmIEkgYWRkIGEgZmlsZSB0byB0aGUgc2VydmVyIChkaXJlY3RseSBmcm9tIHRoZSBz ZXJ2ZXIgc2lkZSB2aWEgd2ViIGludGVyZmFjZSksIHRoZSBjbGllbnQgY2Fubm90IGZpbmQgdGhl IGNoYW5nZS4gSSBuZWVkIHRvIGludGVycnVwdCB0aGUgc3luYyBhbmQgcmVjb3ZlciBpdCB0byBt YWtlIHRoZSBjbGllbnQgYmUgYXdhcmUgb2YgdGhlIGNoYW5nZSBhbmQgZG93bmxvYWQgdGhlIG5l d2x5IGFkZGVkIGZpbGUuIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgY2F1c2VkIGJ5IHRo ZSBzeW5jIG1lY2hhbmlzbSBvciBhbiBpbXByb3BlciBzZXJ2ZXIgY29uZmlndXJhdGlvbi4gSSBu ZWVkIHRvIGludmVzdGlnYXRlIHRoaXMgZnVydGhlciBhbmQgYWxzbyBob3cgdGhlIG93bkNsb3Vk IHdvcmtzIGZvciBtdWx0aXBsZSBjbGllbnRzIChvciBkZXZpY2VzKS4NCj4NCj5Gb3IgSVNTLCBJ IHRoaW5rIG93bkNsb3VkIGhhcyBkZW1vbnN0cmF0ZWQgdG8gc29tZSBleHRlbnQgdGhhdCBzaW1p bGFyIElFVEYgcHJvdG9jb2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3llZC4gVGhlIGlu dGVudGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJlbnQgc3Rh dGUgb2YgdXNpbmcgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRv IGJlIGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIgd2UgbmVlZCBuZXcgcHJvdG9jb2xzLg0KPg0K PkNvbW1lbnRzIGFyZSB3ZWxjb21lIDogKQ0KPg0KPlJlZ2FyZHMsDQo+TGluaHVpDQo+DQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5TdG9yYWdl c3luYyBtYWlsaW5nIGxpc3QNCj5TdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5 bmNAaWV0Zi5vcmc+DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9y YWdlc3luYw0KPg== From nobody Wed Nov 25 19:28: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 AF8FC1A9166 for ; Wed, 25 Nov 2015 19:28:02 -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 i6QPOoVjXvk5 for ; Wed, 25 Nov 2015 19:28:00 -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 A99A91A9170 for ; Wed, 25 Nov 2015 19:27:59 -0800 (PST) Received: by wmww144 with SMTP id w144so5711259wmw.0 for ; Wed, 25 Nov 2015 19:27:58 -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=lt2YdEzAZ0zbjIKKl2NuEy4vPC2RlodvD3PFDzNq7lE=; b=OQ8NFi71veULQ5EMqaW0dgmFkRJCQQC5yOzAlD+8fhP+4D/4P1XfOIPPXhLb+jcvOR 0QI0olLE9afK+y7VicdNLlevdAZMiUATfVKFwU2NM8ThF2ZuRHgI6LgstcWbbnIDjdMe 9gRcM4ohVOGLQFmMzDCLQ2m3MVEV4wVfc5p526W3Scx3Aoe/OuWeesEWAK8eaU968b6E oNZa2HEuEEjI9tUlde8TVFqp9i21ImeNkiGaE2Fmfb+OIiCNS2H3pt7aUZ3jbLsWRJ7S MZgg5yA2HjS/MjnGQCehPlHfvPeOlqRpb1bLfoq037c5klFoLidDAOp/T+HLiTu/R+iU CX7Q== X-Received: by 10.28.103.84 with SMTP id b81mr952260wmc.39.1448508478286; Wed, 25 Nov 2015 19:27:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 25 Nov 2015 19:27:38 -0800 (PST) In-Reply-To: <201511261111483122529@bjtu.edu.cn> References: <201511261111483122529@bjtu.edu.cn> From: Linhui Sun Date: Thu, 26 Nov 2015 11:27:38 +0800 Message-ID: To: fsong Content-Type: multipart/alternative; boundary=001a114b679c4d708805256929de 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: Thu, 26 Nov 2015 03:28:02 -0000 --001a114b679c4d708805256929de Content-Type: text/plain; charset=UTF-8 Hi Fei, 2015-11-26 11:11 GMT+08:00 Fei Song : > Hi all > > > -------------- > Fei Song > >Hi all, > > > >As I mentioned before, I think the developers could benefit from the IETF > >standards. The ownCloud (https://owncloud.org/) is just an example. It is > >developed for those who do not trust commercial storage services and want > >to build their own network-based storage services. The ownCloud is using > >WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed for > >distributed work but not for the sync. Thus, I made some preliminary > >investigations on how the ownCloud uses WebDAV for sync purposes. A brief > >summary of what I've found is in the following, please correct me if I am > >wrong. > > > >I installed the ownCloud server (v8.2.1) on the CentOS7, and the client is > >a desktop client on Windows. > > > >1. To find whether there is a change to the synced directory, the client > >continuously sends PROPFIND to the server at regular intervals (around 34 > >seconds under my observation). The server will respond a 207 Multi-Status > >Response to tell whether the main directory has been changed. To perform > >this regular check, the client will open a new TCP connection to send the > >PROPFIND, the server will close the existing TCP connection after > >responding the 207 Multi-Status Response. For the next check, the client > >will open another new TCP connection. > > I wonder whether these message you got had been encrypt or not. > The ownCloud suggests people use HTTPS, but you could also use the HTTP. And that is what I did. > > > > >2. Every time adding (or creating) a new file to the local folder, the > >client will open a new TCP connection (if there is no connection existing) > >to send the file asap. The client will first send several PROPFINDs to > find > >out which sub-directory has been changed. And then it sends the file using > >PUT. The server will respond a 201 Created Response and then terminate the > >connection. Currently, I haven't found any application layer chunking, all > >the segmentation are performed by TCP. > > > >3. Every time I delete (or rename) a file locally, the client will also > >open a new TCP connection to send several PROPFINDs to find out which file > >has been removed (or renamed). Then it will send DELETE (or MOVE). The > >server will respond a 204 No Content Response (or 201 Created Response) > and > >then terminate the connection. > > > >4. I open a file and frequently edit and save it (actually this is what I > >usually do with the Dropbox). The client will send the whole file to the > >server every time I save the file. > > > >To summarize, it seems that the ownCloud makes heavily use of PROPFIND to > >achieve the sync process. Each sync operation (e.g. upload, modify and > >etc.) will start with sending one or more PROPFINDs. And currently, if I > >add a file to the server (directly from the server side via web > interface), > >the client cannot find the change. I need to interrupt the sync and > recover > >it to make the client be aware of the change and download the newly added > >file. I'm not sure whether this is caused by the sync mechanism or an > >improper server configuration. I need to investigate this further and also > >how the ownCloud works for multiple clients (or devices). > > What do you mean by "directly from the server side via web interface". > If all the configuration were correct, do you want to identify that the > sync in > ownCloud is only unidirectional? > People could access to the ownCloud service via desktop, mobile client or web interface (i.e. browser), the point I want to say here is an operation on the server side cannot be detected automatically. I'm not sure whether I've configured the server correctly. But the sync is not unidirectional since after I recovering the sync, the client could download the asap. > > > > >For ISS, I think ownCloud has demonstrated to some extent that similar > IETF > >protocols could be deployed and employed. The intention of this message is > >to investigate the current state of using WebDAV for sync purposes to see > >what needs to be improved here and whether we need new protocols. > > > > > >Comments are welcome : ) > > > >Regards, > >Linhui > > > _______________________________________________ > Storagesync mailing list > Storagesync@ietf.org > https://www.ietf.org/mailman/listinfo/storagesync > --001a114b679c4d708805256929de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fei,

2015-11-26 11:11 GMT+08:00 Fei Song <fsong@bjtu.edu.cn><= /span>:
Hi all


--------------
Fei Song
>Hi all,
>
>As I mentioned before, I think the developers could benefit from the IE= TF
>standards. The ownCloud (https://owncloud.org/) is just an example. It = is
>developed for those who do not trust commercial storage services and wa= nt
>to build their own network-based storage services. The ownCloud is usin= g
>WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed = for
>distributed work but not for the sync. Thus, I made some preliminary >investigations on how the ownCloud uses WebDAV for sync purposes. A bri= ef
>summary of what I've found is in the following, please correct me i= f I am
>wrong.
>
>I installed the ownCloud server (v8.2.1) on the CentOS7, and the client= is
>a desktop client on Windows.
>
>1. To find whether there is a change to the synced directory, the clien= t
>continuously sends PROPFIND to the server at regular intervals (around = 34
>seconds under my observation). The server will respond a 207 Multi-Stat= us
>Response to tell whether the main directory has been changed. To perfor= m
>this regular check, the client will open a new TCP connection to send t= he
>PROPFIND, the server will close the existing TCP connection after
>responding the 207 Multi-Status Response. For the next check, the clien= t
>will open another new TCP connection.

I wonder whether these message you got had been encrypt or not.
<= /blockquote>
The ownCloud suggests people use HTTPS, but you could also= use the HTTP. And that is what I did.=C2=A0

>
>2. Every time adding (or creating) a new file to the local folder, the<= br> >client will open a new TCP connection (if there is no connection existi= ng)
>to send the file asap. The client will first send several PROPFINDs to = find
>out which sub-directory has been changed. And then it sends the file us= ing
>PUT. The server will respond a 201 Created Response and then terminate = the
>connection. Currently, I haven't found any application layer chunki= ng, all
>the segmentation are performed by TCP.
>
>3. Every time I delete (or rename) a file locally, the client will also=
>open a new TCP connection to send several PROPFINDs to find out which f= ile
>has been removed (or renamed). Then it will send DELETE (or MOVE). The<= br> >server will respond a 204 No Content Response (or 201 Created Response)= and
>then terminate the connection.
>
>4. I open a file and frequently edit and save it (actually this is what= I
>usually do with the Dropbox). The client will send the whole file to th= e
>server every time I save the file.
>
>To summarize, it seems that the ownCloud makes heavily use of PROPFIND = to
>achieve the sync process. Each sync operation (e.g. upload, modify and<= br> >etc.) will start with sending one or more PROPFINDs. And currently, if = I
>add a file to the server (directly from the server side via web interfa= ce),
>the client cannot find the change. I need to interrupt the sync and rec= over
>it to make the client be aware of the change and download the newly add= ed
>file. I'm not sure whether this is caused by the sync mechanism or = an
>improper server configuration. I need to investigate this further and a= lso
>how the ownCloud works for multiple clients (or devices).

What do you mean by "directly from the server side via web inte= rface".
If all the configuration were correct, do you want to identify that the syn= c in
ownCloud is only unidirectional?
People could access t= o the ownCloud service via desktop, mobile client or web interface (i.e. br= owser), the point I want to say here is an operation on the server side can= not be detected automatically. I'm not sure whether I've configured= the server correctly. But the sync is not unidirectional since after I rec= overing the sync, the client could download the asap.=C2=A0

>
>For ISS, I think ownCloud has demonstrated to some extent that similar = IETF
>protocols could be deployed and employed. The intention of this message= is
>to investigate the current state of using WebDAV for sync purposes to s= ee
>what needs to be improved here and whether we need new protocols.


>
>Comments are welcome : )
>
>Regards,
>Linhui
>
____________________________= ___________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync

--001a114b679c4d708805256929de-- From nobody Wed Nov 25 19:28: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 310971A9166 for ; Wed, 25 Nov 2015 19:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 LaPRZytd7YVH for ; Wed, 25 Nov 2015 19:28:05 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4C22D1A9172 for ; Wed, 25 Nov 2015 19:28:05 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygC3vsLKfFZWzm3jAA--.9442S2; Thu, 26 Nov 2015 11:30:18 +0800 (CST) Date: Thu, 26 Nov 2015 11:28:03 +0800 From: "Fei Song" To: "Jakub Moscicki" , "Linhui Sun" References: , <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015112611280303192311@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygC3vsLKfFZWzm3jAA--.9442S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZr4kXFy5uFW3GrW5WF47CFg_yoWrZF1xpF Z8Ka1kKFykJw4xGwn7Xryj9r1vvFZ7JrW7JFn5Jw48trZ8WF9aqFyIyr4Y9a4UGrZ3Kr4Y qr4FgFW3C3Z8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 EJm5UUUUU== 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: Thu, 26 Nov 2015 03:28:10 -0000 QlRXLCBCYXNlZCBvbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiBsYXN0IGVtYWlsOiJUaGUgaW50ZW50 aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyB0byBpbnZlc3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBv ZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUg aW1wcm92ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldyBwcm90b2NvbHMiDQoNClRoZSBv dXRjb21lIGhlL3NoZSB3YW50ZWQgbWlnaHQgYmUganVzdCB0aGUgbGlua3MgbGlrZSBodHRwOi8v Y3MzLmV0aHouY2gvcHJvZ3JhbS5odG1sIDopDQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25n DQo+SGVsbG8sDQo+DQo+V2hhdCBraW5kIG9mIG91dGNvbWUgYXJlIHlvdSBsb29raW5nIGZvciB3 aXRoIHRoaXMgYW5hbHlzaXM/IFNvbWUgcmVzZWFyY2ggaW4gdGhpcyBhcmVhIGhhcyBhbHJlYWR5 IGJlZW4gZG9uZSBvciBpcyBiZWluZyBkb25lIGFzIHdlIHNwZWFrDQo+DQo+ZS5nLiAiQSBzdHVk eSBvZiBkZWx0YS1zeW5jIGFuZCBvdGhlciBvcHRpbWlzYXRpb24gaW4gSFRUUC9XZWJkYXYgc3lu Y2hvbmlzYXRpb24gcHJvdG9jb2xzIg0KPg0KPnNlZSAiVGVjaG5vbG9neSBhbmQgUmVzZWFyY2gi Og0KPg0KPmh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwNCj4NCj5JdCB3b3VsZCBiZSBp bnRlcmVzdGluZyB0byBzZWUgaWYgdGhlcmUgaXMgYSBwb3RlbnRpYWwgZm9yIGNvbGxhYm9yYXRp b24uIE9yIG1heWJlIHdlIGFscmVhZHkgaGF2ZSBzb21lIGluZm9ybWF0aW9uIHlvdSBhcmUgbG9v a2luZyBmb3IuDQo+DQo+QmVzdCByZWdhcmRzLA0KPg0KPkpha3ViIE1vc2NpY2tpDQo+DQo+oaoN Cj4NCj4NCj5PbiAyNSBOb3YgMjAxNSwgYXQgMTE6NDUsIExpbmh1aSBTdW4gPGxoLnN1bmxpbmhA Z21haWwuY29tPG1haWx0bzpsaC5zdW5saW5oQGdtYWlsLmNvbT4+IHdyb3RlOg0KPg0KPkhpIGFs bCwNCj4NCj5BcyBJIG1lbnRpb25lZCBiZWZvcmUsIEkgdGhpbmsgdGhlIGRldmVsb3BlcnMgY291 bGQgYmVuZWZpdCBmcm9tIHRoZSBJRVRGIHN0YW5kYXJkcy4gVGhlIG93bkNsb3VkIChodHRwczov L293bmNsb3VkLm9yZy8pIGlzIGp1c3QgYW4gZXhhbXBsZS4gSXQgaXMgZGV2ZWxvcGVkIGZvciB0 aG9zZSB3aG8gZG8gbm90IHRydXN0IGNvbW1lcmNpYWwgc3RvcmFnZSBzZXJ2aWNlcyBhbmQgd2Fu dCB0byBidWlsZCB0aGVpciBvd24gbmV0d29yay1iYXNlZCBzdG9yYWdlIHNlcnZpY2VzLiBUaGUg b3duQ2xvdWQgaXMgdXNpbmcgV2ViREFWIChSRkM0OTE4KSB0byBhY2hpZXZlIHRoZSBkYXRhIHN5 bmMuIElNTywgdGhlIFdlYkRBViBpcyBkZXNpZ25lZCBmb3IgZGlzdHJpYnV0ZWQgd29yayBidXQg bm90IGZvciB0aGUgc3luYy4gVGh1cywgSSBtYWRlIHNvbWUgcHJlbGltaW5hcnkgaW52ZXN0aWdh dGlvbnMgb24gaG93IHRoZSBvd25DbG91ZCB1c2VzIFdlYkRBViBmb3Igc3luYyBwdXJwb3Nlcy4g QSBicmllZiBzdW1tYXJ5IG9mIHdoYXQgSSd2ZSBmb3VuZCBpcyBpbiB0aGUgZm9sbG93aW5nLCBw bGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLg0KPg0KPkkgaW5zdGFsbGVkIHRoZSBvd25D bG91ZCBzZXJ2ZXIgKHY4LjIuMSkgb24gdGhlIENlbnRPUzcsIGFuZCB0aGUgY2xpZW50IGlzIGEg ZGVza3RvcCBjbGllbnQgb24gV2luZG93cy4NCj4NCj4xLiBUbyBmaW5kIHdoZXRoZXIgdGhlcmUg aXMgYSBjaGFuZ2UgdG8gdGhlIHN5bmNlZCBkaXJlY3RvcnksIHRoZSBjbGllbnQgY29udGludW91 c2x5IHNlbmRzIFBST1BGSU5EIHRvIHRoZSBzZXJ2ZXIgYXQgcmVndWxhciBpbnRlcnZhbHMgKGFy b3VuZCAzNCBzZWNvbmRzIHVuZGVyIG15IG9ic2VydmF0aW9uKS4gVGhlIHNlcnZlciB3aWxsIHJl c3BvbmQgYSAyMDcgTXVsdGktU3RhdHVzIFJlc3BvbnNlIHRvIHRlbGwgd2hldGhlciB0aGUgbWFp biBkaXJlY3RvcnkgaGFzIGJlZW4gY2hhbmdlZC4gVG8gcGVyZm9ybSB0aGlzIHJlZ3VsYXIgY2hl Y2ssIHRoZSBjbGllbnQgd2lsbCBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIHRvIHNlbmQgdGhl IFBST1BGSU5ELCB0aGUgc2VydmVyIHdpbGwgY2xvc2UgdGhlIGV4aXN0aW5nIFRDUCBjb25uZWN0 aW9uIGFmdGVyIHJlc3BvbmRpbmcgdGhlIDIwNyBNdWx0aS1TdGF0dXMgUmVzcG9uc2UuIEZvciB0 aGUgbmV4dCBjaGVjaywgdGhlIGNsaWVudCB3aWxsIG9wZW4gYW5vdGhlciBuZXcgVENQIGNvbm5l Y3Rpb24uDQo+DQo+Mi4gRXZlcnkgdGltZSBhZGRpbmcgKG9yIGNyZWF0aW5nKSBhIG5ldyBmaWxl IHRvIHRoZSBsb2NhbCBmb2xkZXIsIHRoZSBjbGllbnQgd2lsbCBvcGVuIGEgbmV3IFRDUCBjb25u ZWN0aW9uIChpZiB0aGVyZSBpcyBubyBjb25uZWN0aW9uIGV4aXN0aW5nKSB0byBzZW5kIHRoZSBm aWxlIGFzYXAuIFRoZSBjbGllbnQgd2lsbCBmaXJzdCBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRv IGZpbmQgb3V0IHdoaWNoIHN1Yi1kaXJlY3RvcnkgaGFzIGJlZW4gY2hhbmdlZC4gQW5kIHRoZW4g aXQgc2VuZHMgdGhlIGZpbGUgdXNpbmcgUFVULiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIw MSBDcmVhdGVkIFJlc3BvbnNlIGFuZCB0aGVuIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4gQ3Vy cmVudGx5LCBJIGhhdmVuJ3QgZm91bmQgYW55IGFwcGxpY2F0aW9uIGxheWVyIGNodW5raW5nLCBh bGwgdGhlIHNlZ21lbnRhdGlvbiBhcmUgcGVyZm9ybWVkIGJ5IFRDUC4NCj4NCj4zLiBFdmVyeSB0 aW1lIEkgZGVsZXRlIChvciByZW5hbWUpIGEgZmlsZSBsb2NhbGx5LCB0aGUgY2xpZW50IHdpbGwg YWxzbyBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIHRvIHNlbmQgc2V2ZXJhbCBQUk9QRklORHMg dG8gZmluZCBvdXQgd2hpY2ggZmlsZSBoYXMgYmVlbiByZW1vdmVkIChvciByZW5hbWVkKS4gVGhl biBpdCB3aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4gVGhlIHNlcnZlciB3aWxsIHJlc3BvbmQg YSAyMDQgTm8gQ29udGVudCBSZXNwb25zZSAob3IgMjAxIENyZWF0ZWQgUmVzcG9uc2UpIGFuZCB0 aGVuIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4NCj4NCj40LiBJIG9wZW4gYSBmaWxlIGFuZCBm cmVxdWVudGx5IGVkaXQgYW5kIHNhdmUgaXQgKGFjdHVhbGx5IHRoaXMgaXMgd2hhdCBJIHVzdWFs bHkgZG8gd2l0aCB0aGUgRHJvcGJveCkuIFRoZSBjbGllbnQgd2lsbCBzZW5kIHRoZSB3aG9sZSBm aWxlIHRvIHRoZSBzZXJ2ZXIgZXZlcnkgdGltZSBJIHNhdmUgdGhlIGZpbGUuDQo+DQo+VG8gc3Vt bWFyaXplLCBpdCBzZWVtcyB0aGF0IHRoZSBvd25DbG91ZCBtYWtlcyBoZWF2aWx5IHVzZSBvZiBQ Uk9QRklORCB0byBhY2hpZXZlIHRoZSBzeW5jIHByb2Nlc3MuIEVhY2ggc3luYyBvcGVyYXRpb24g KGUuZy4gdXBsb2FkLCBtb2RpZnkgYW5kIGV0Yy4pIHdpbGwgc3RhcnQgd2l0aCBzZW5kaW5nIG9u ZSBvciBtb3JlIFBST1BGSU5Ecy4gQW5kIGN1cnJlbnRseSwgaWYgSSBhZGQgYSBmaWxlIHRvIHRo ZSBzZXJ2ZXIgKGRpcmVjdGx5IGZyb20gdGhlIHNlcnZlciBzaWRlIHZpYSB3ZWIgaW50ZXJmYWNl KSwgdGhlIGNsaWVudCBjYW5ub3QgZmluZCB0aGUgY2hhbmdlLiBJIG5lZWQgdG8gaW50ZXJydXB0 IHRoZSBzeW5jIGFuZCByZWNvdmVyIGl0IHRvIG1ha2UgdGhlIGNsaWVudCBiZSBhd2FyZSBvZiB0 aGUgY2hhbmdlIGFuZCBkb3dubG9hZCB0aGUgbmV3bHkgYWRkZWQgZmlsZS4gSSdtIG5vdCBzdXJl IHdoZXRoZXIgdGhpcyBpcyBjYXVzZWQgYnkgdGhlIHN5bmMgbWVjaGFuaXNtIG9yIGFuIGltcHJv cGVyIHNlcnZlciBjb25maWd1cmF0aW9uLiBJIG5lZWQgdG8gaW52ZXN0aWdhdGUgdGhpcyBmdXJ0 aGVyIGFuZCBhbHNvIGhvdyB0aGUgb3duQ2xvdWQgd29ya3MgZm9yIG11bHRpcGxlIGNsaWVudHMg KG9yIGRldmljZXMpLg0KPg0KPkZvciBJU1MsIEkgdGhpbmsgb3duQ2xvdWQgaGFzIGRlbW9uc3Ry YXRlZCB0byBzb21lIGV4dGVudCB0aGF0IHNpbWlsYXIgSUVURiBwcm90b2NvbHMgY291bGQgYmUg ZGVwbG95ZWQgYW5kIGVtcGxveWVkLiBUaGUgaW50ZW50aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyB0 byBpbnZlc3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMg cHVycG9zZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQgaGVyZSBhbmQgd2hldGhl ciB3ZSBuZWVkIG5ldyBwcm90b2NvbHMuDQo+DQo+Q29tbWVudHMgYXJlIHdlbGNvbWUgOiApDQo+ DQo+UmVnYXJkcywNCj5MaW5odWkNCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPlN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPlN0b3JhZ2Vz eW5jQGlldGYub3JnPG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZz4NCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+ From nobody Wed Nov 25 19:29: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 3E1DA1A9174 for ; Wed, 25 Nov 2015 19:29:09 -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 tiKvGvf844oi for ; Wed, 25 Nov 2015 19:29:06 -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 B6E021A9173 for ; Wed, 25 Nov 2015 19:29:05 -0800 (PST) Received: by wmec201 with SMTP id c201so5708142wme.1 for ; Wed, 25 Nov 2015 19:29:04 -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=o3AIzRfL0B9Uq6aWHxEebd6WJo6nMP28ZrR+Slgb2Mg=; b=I/vtkb5LbkrQ/IngpbeO0SMfQIPPa7G2clqIknDqkRx4kSJmK2zeidSFqHM0vONZn1 bL8mRZ04Zzd6hduaa6uQawQYmOSHKhuzDD/MUWx2wb2ttfUfsGOr/GcJpJWL1ER2nUCe hd1sxYLsZEw4M8y+eRAggEOtLcVaMgOFGfrT/+FerkRK+uPbft7m+rWM+GqLliMcv4Qc +14DpHfWHsCxVRXfdkazxSz636QvwMhhSNydF1pIzCP45lSzBVc0Klnm80JpfDole/R/ MQmp6Bkl8L14DhhEpaxmiVAY3iFWPFVnd3j760gW8YtfgeCJUEWqUMWZnGEfpZxzG1kb CAAw== X-Received: by 10.28.15.194 with SMTP id 185mr1075656wmp.9.1448508544342; Wed, 25 Nov 2015 19:29:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 25 Nov 2015 19:28:44 -0800 (PST) In-Reply-To: <2015112611202500034610@bjtu.edu.cn> References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611202500034610@bjtu.edu.cn> From: Linhui Sun Date: Thu, 26 Nov 2015 11:28:44 +0800 Message-ID: To: fsong Content-Type: multipart/alternative; boundary=001a11469edc3d623b0525692d47 Archived-At: Cc: Jakub Moscicki , 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: Thu, 26 Nov 2015 03:29:09 -0000 --001a11469edc3d623b0525692d47 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-11-26 11:20 GMT+08:00 Fei Song : > Hi Jakub and all, > > I can't download the paper you mentioned. Could you please show me a link > to it? > For the URL http://cs3.ethz.ch/program.html ,there is no links... > +1 Regards, Linhui > > > -------------- > Fei Song > >Hello, > > > >What kind of outcome are you looking for with this analysis? Some > research in this area has already been done or is being done as we speak > > > >e.g. "A study of delta-sync and other optimisation in HTTP/Webdav > synchonisation protocols" > > > >see "Technology and Research": > > > >http://cs3.ethz.ch/program.html > > > >It would be interesting to see if there is a potential for collaboration= . > Or maybe we already have some information you are looking for. > > > >Best regards, > > > >Jakub Moscicki > > > >=E2=80=94 > > > > > >On 25 Nov 2015, at 11:45, Linhui Sun lh.sunlinh@gmail.com>> wrote: > > > >Hi all, > > > >As I mentioned before, I think the developers could benefit from the IET= F > standards. The ownCloud (https://owncloud.org/) is just an example. It is > developed for those who do not trust commercial storage services and want > to build their own network-based storage services. The ownCloud is using > WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed fo= r > distributed work but not for the sync. Thus, I made some preliminary > investigations on how the ownCloud uses WebDAV for sync purposes. A brief > summary of what I've found is in the following, please correct me if I am > wrong. > > > >I installed the ownCloud server (v8.2.1) on the CentOS7, and the client > is a desktop client on Windows. > > > >1. To find whether there is a change to the synced directory, the client > continuously sends PROPFIND to the server at regular intervals (around 34 > seconds under my observation). The server will respond a 207 Multi-Status > Response to tell whether the main directory has been changed. To perform > this regular check, the client will open a new TCP connection to send the > PROPFIND, the server will close the existing TCP connection after > responding the 207 Multi-Status Response. For the next check, the client > will open another new TCP connection. > > > >2. Every time adding (or creating) a new file to the local folder, the > client will open a new TCP connection (if there is no connection existing= ) > to send the file asap. The client will first send several PROPFINDs to fi= nd > out which sub-directory has been changed. And then it sends the file usin= g > PUT. The server will respond a 201 Created Response and then terminate th= e > connection. Currently, I haven't found any application layer chunking, al= l > the segmentation are performed by TCP. > > > >3. Every time I delete (or rename) a file locally, the client will also > open a new TCP connection to send several PROPFINDs to find out which fil= e > has been removed (or renamed). Then it will send DELETE (or MOVE). The > server will respond a 204 No Content Response (or 201 Created Response) a= nd > then terminate the connection. > > > >4. I open a file and frequently edit and save it (actually this is what = I > usually do with the Dropbox). The client will send the whole file to the > server every time I save the file. > > > >To summarize, it seems that the ownCloud makes heavily use of PROPFIND t= o > achieve the sync process. Each sync operation (e.g. upload, modify and > etc.) will start with sending one or more PROPFINDs. And currently, if I > add a file to the server (directly from the server side via web interface= ), > the client cannot find the change. I need to interrupt the sync and recov= er > it to make the client be aware of the change and download the newly added > file. I'm not sure whether this is caused by the sync mechanism or an > improper server configuration. I need to investigate this further and als= o > how the ownCloud works for multiple clients (or devices). > > > >For ISS, I think ownCloud has demonstrated to some extent that similar > IETF protocols could be deployed and employed. The intention of this > message is to investigate the current state of using WebDAV for sync > purposes to see what needs to be improved here and whether we need new > protocols. > > > >Comments are welcome : ) > > > >Regards, > >Linhui > > > > > >_______________________________________________ > >Storagesync mailing list > >Storagesync@ietf.org > >https://www.ietf.org/mailman/listinfo/storagesync > > --001a11469edc3d623b0525692d47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-11-26 11:20 GMT+08:00 Fei Song <fsong@bjtu.edu.cn>:=
Hi Jakub and all,

I can't download the paper you mentioned. Could you please show me a li= nk to it?
For the URL http://cs3.ethz.ch/program.html ,there is no links...=
+1=C2=A0

Regards,
= Linhui


--------------
Fei Song
>Hello,
>
>What kind of outcome are you looking for with this analysis? Some resea= rch in this area has already been done or is being done as we speak
>
>e.g. "A study of delta-sync and other optimisation in HTTP/Webdav = synchonisation protocols"
>
>see "Technology and Research":
>
>http://cs3.ethz.ch/program.html
>
>It would be interesting to see if there is a potential for collaboratio= n. Or maybe we already have some information you are looking for.
>
>Best regards,
>
>Jakub Moscicki
>
>=E2=80=94
>
>
>On 25 Nov 2015, at 11:45, Linhui Sun <lh.sunlinh@gmail.com<mailto:lh.sunlinh@gmail.com>> wrote: >
>Hi all,
>
>As I mentioned before, I think the developers could benefit from the IE= TF standards. The ownCloud (https://owncloud.org/) is just an example. It i= s developed for those who do not trust commercial storage services and want= to build their own network-based storage services. The ownCloud is using W= ebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed for d= istributed work but not for the sync. Thus, I made some preliminary investi= gations on how the ownCloud uses WebDAV for sync purposes. A brief summary = of what I've found is in the following, please correct me if I am wrong= .
>
>I installed the ownCloud server (v8.2.1) on the CentOS7, and the client= is a desktop client on Windows.
>
>1. To find whether there is a change to the synced directory, the clien= t continuously sends PROPFIND to the server at regular intervals (around 34= seconds under my observation). The server will respond a 207 Multi-Status = Response to tell whether the main directory has been changed. To perform th= is regular check, the client will open a new TCP connection to send the PRO= PFIND, the server will close the existing TCP connection after responding t= he 207 Multi-Status Response. For the next check, the client will open anot= her new TCP connection.
>
>2. Every time adding (or creating) a new file to the local folder, the = client will open a new TCP connection (if there is no connection existing) = to send the file asap. The client will first send several PROPFINDs to find= out which sub-directory has been changed. And then it sends the file using= PUT. The server will respond a 201 Created Response and then terminate the= connection. Currently, I haven't found any application layer chunking,= all the segmentation are performed by TCP.
>
>3. Every time I delete (or rename) a file locally, the client will also= open a new TCP connection to send several PROPFINDs to find out which file= has been removed (or renamed). Then it will send DELETE (or MOVE). The ser= ver will respond a 204 No Content Response (or 201 Created Response) and th= en terminate the connection.
>
>4. I open a file and frequently edit and save it (actually this is what= I usually do with the Dropbox). The client will send the whole file to the= server every time I save the file.
>
>To summarize, it seems that the ownCloud makes heavily use of PROPFIND = to achieve the sync process. Each sync operation (e.g. upload, modify and e= tc.) will start with sending one or more PROPFINDs. And currently, if I add= a file to the server (directly from the server side via web interface), th= e client cannot find the change. I need to interrupt the sync and recover i= t to make the client be aware of the change and download the newly added fi= le. I'm not sure whether this is caused by the sync mechanism or an imp= roper server configuration. I need to investigate this further and also how= the ownCloud works for multiple clients (or devices).
>
>For ISS, I think ownCloud has demonstrated to some extent that similar = IETF protocols could be deployed and employed. The intention of this messag= e is to investigate the current state of using WebDAV for sync purposes to = see what needs to be improved here and whether we need new protocols.
>
>Comments are welcome : )
>
>Regards,
>Linhui
>
>
>_______________________________________________
>Storagesync mailing list
>Storagesync@ietf.org= <mailto:Storagesync@ietf.org= >
>https://www.ietf.org/mailman/listinfo/storagesy= nc
>

--001a11469edc3d623b0525692d47-- From nobody Wed Nov 25 19:37: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 B76C31A9250 for ; Wed, 25 Nov 2015 19:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 imrc1liXVr_w for ; Wed, 25 Nov 2015 19:36:56 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6B71A924B for ; Wed, 25 Nov 2015 19:36:55 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygBnSQbbflZWdHHjAA--.16194S2; Thu, 26 Nov 2015 11:39:07 +0800 (CST) Date: Thu, 26 Nov 2015 11:36:57 +0800 From: "Fei Song" To: "Linhui Sun" References: <201511261111483122529@bjtu.edu.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015112611365765643513@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygBnSQbbflZWdHHjAA--.16194S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAw4fAw4xArWfKFWkWrWxZwb_yoWrtF47pr ZIkas7KF1kJrWxCwn2qFyjkr1F9rZ3JrW7Xrn8Jw4xArZ09ryftF4Iyr1ruasrCrZ3Gr1j qr4YgrW3Xwn8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8 EJm5UUUUU== 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: Thu, 26 Nov 2015 03:36:59 -0000 SGkgTGluaHVpLA0KDQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KPkhpIEZlaSwNCj4NCj4y MDE1LTExLTI2IDExOjExIEdNVCswODowMCBGZWkgU29uZyA8ZnNvbmdAYmp0dS5lZHUuY24+Og0K Pg0KPj4gSGkgYWxsDQo+Pg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tDQo+PiBGZWkgU29uZw0KPj4g PkhpIGFsbCwNCj4+ID4NCj4+ID5BcyBJIG1lbnRpb25lZCBiZWZvcmUsIEkgdGhpbmsgdGhlIGRl dmVsb3BlcnMgY291bGQgYmVuZWZpdCBmcm9tIHRoZSBJRVRGDQo+PiA+c3RhbmRhcmRzLiBUaGUg b3duQ2xvdWQgKGh0dHBzOi8vb3duY2xvdWQub3JnLykgaXMganVzdCBhbiBleGFtcGxlLiBJdCBp cw0KPj4gPmRldmVsb3BlZCBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB0cnVzdCBjb21tZXJjaWFsIHN0 b3JhZ2Ugc2VydmljZXMgYW5kIHdhbnQNCj4+ID50byBidWlsZCB0aGVpciBvd24gbmV0d29yay1i YXNlZCBzdG9yYWdlIHNlcnZpY2VzLiBUaGUgb3duQ2xvdWQgaXMgdXNpbmcNCj4+ID5XZWJEQVYg KFJGQzQ5MTgpIHRvIGFjaGlldmUgdGhlIGRhdGEgc3luYy4gSU1PLCB0aGUgV2ViREFWIGlzIGRl c2lnbmVkIGZvcg0KPj4gPmRpc3RyaWJ1dGVkIHdvcmsgYnV0IG5vdCBmb3IgdGhlIHN5bmMuIFRo dXMsIEkgbWFkZSBzb21lIHByZWxpbWluYXJ5DQo+PiA+aW52ZXN0aWdhdGlvbnMgb24gaG93IHRo ZSBvd25DbG91ZCB1c2VzIFdlYkRBViBmb3Igc3luYyBwdXJwb3Nlcy4gQSBicmllZg0KPj4gPnN1 bW1hcnkgb2Ygd2hhdCBJJ3ZlIGZvdW5kIGlzIGluIHRoZSBmb2xsb3dpbmcsIHBsZWFzZSBjb3Jy ZWN0IG1lIGlmIEkgYW0NCj4+ID53cm9uZy4NCj4+ID4NCj4+ID5JIGluc3RhbGxlZCB0aGUgb3du Q2xvdWQgc2VydmVyICh2OC4yLjEpIG9uIHRoZSBDZW50T1M3LCBhbmQgdGhlIGNsaWVudCBpcw0K Pj4gPmEgZGVza3RvcCBjbGllbnQgb24gV2luZG93cy4NCj4+ID4NCj4+ID4xLiBUbyBmaW5kIHdo ZXRoZXIgdGhlcmUgaXMgYSBjaGFuZ2UgdG8gdGhlIHN5bmNlZCBkaXJlY3RvcnksIHRoZSBjbGll bnQNCj4+ID5jb250aW51b3VzbHkgc2VuZHMgUFJPUEZJTkQgdG8gdGhlIHNlcnZlciBhdCByZWd1 bGFyIGludGVydmFscyAoYXJvdW5kIDM0DQo+PiA+c2Vjb25kcyB1bmRlciBteSBvYnNlcnZhdGlv bikuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA3IE11bHRpLVN0YXR1cw0KPj4gPlJlc3Bv bnNlIHRvIHRlbGwgd2hldGhlciB0aGUgbWFpbiBkaXJlY3RvcnkgaGFzIGJlZW4gY2hhbmdlZC4g VG8gcGVyZm9ybQ0KPj4gPnRoaXMgcmVndWxhciBjaGVjaywgdGhlIGNsaWVudCB3aWxsIG9wZW4g YSBuZXcgVENQIGNvbm5lY3Rpb24gdG8gc2VuZCB0aGUNCj4+ID5QUk9QRklORCwgdGhlIHNlcnZl ciB3aWxsIGNsb3NlIHRoZSBleGlzdGluZyBUQ1AgY29ubmVjdGlvbiBhZnRlcg0KPj4gPnJlc3Bv bmRpbmcgdGhlIDIwNyBNdWx0aS1TdGF0dXMgUmVzcG9uc2UuIEZvciB0aGUgbmV4dCBjaGVjaywg dGhlIGNsaWVudA0KPj4gPndpbGwgb3BlbiBhbm90aGVyIG5ldyBUQ1AgY29ubmVjdGlvbi4NCj4+ DQo+PiBJIHdvbmRlciB3aGV0aGVyIHRoZXNlIG1lc3NhZ2UgeW91IGdvdCBoYWQgYmVlbiBlbmNy eXB0IG9yIG5vdC4NCj4+DQo+VGhlIG93bkNsb3VkIHN1Z2dlc3RzIHBlb3BsZSB1c2UgSFRUUFMs IGJ1dCB5b3UgY291bGQgYWxzbyB1c2UgdGhlIEhUVFAuDQo+QW5kIHRoYXQgaXMgd2hhdCBJIGRp ZC4NCg0KVGhhbmtzIQ0KDQo+DQo+Pg0KPj4gPg0KPj4gPjIuIEV2ZXJ5IHRpbWUgYWRkaW5nIChv ciBjcmVhdGluZykgYSBuZXcgZmlsZSB0byB0aGUgbG9jYWwgZm9sZGVyLCB0aGUNCj4+ID5jbGll bnQgd2lsbCBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIChpZiB0aGVyZSBpcyBubyBjb25uZWN0 aW9uIGV4aXN0aW5nKQ0KPj4gPnRvIHNlbmQgdGhlIGZpbGUgYXNhcC4gVGhlIGNsaWVudCB3aWxs IGZpcnN0IHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8NCj4+IGZpbmQNCj4+ID5vdXQgd2hpY2gg c3ViLWRpcmVjdG9yeSBoYXMgYmVlbiBjaGFuZ2VkLiBBbmQgdGhlbiBpdCBzZW5kcyB0aGUgZmls ZSB1c2luZw0KPj4gPlBVVC4gVGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDEgQ3JlYXRlZCBS ZXNwb25zZSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhlDQo+PiA+Y29ubmVjdGlvbi4gQ3VycmVudGx5 LCBJIGhhdmVuJ3QgZm91bmQgYW55IGFwcGxpY2F0aW9uIGxheWVyIGNodW5raW5nLCBhbGwNCj4+ ID50aGUgc2VnbWVudGF0aW9uIGFyZSBwZXJmb3JtZWQgYnkgVENQLg0KPj4gPg0KPj4gPjMuIEV2 ZXJ5IHRpbWUgSSBkZWxldGUgKG9yIHJlbmFtZSkgYSBmaWxlIGxvY2FsbHksIHRoZSBjbGllbnQg d2lsbCBhbHNvDQo+PiA+b3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiB0byBzZW5kIHNldmVyYWwg UFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIGZpbGUNCj4+ID5oYXMgYmVlbiByZW1vdmVkIChv ciByZW5hbWVkKS4gVGhlbiBpdCB3aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4gVGhlDQo+PiA+ c2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwNCBObyBDb250ZW50IFJlc3BvbnNlIChvciAyMDEgQ3Jl YXRlZCBSZXNwb25zZSkNCj4+IGFuZA0KPj4gPnRoZW4gdGVybWluYXRlIHRoZSBjb25uZWN0aW9u Lg0KPj4gPg0KPj4gPjQuIEkgb3BlbiBhIGZpbGUgYW5kIGZyZXF1ZW50bHkgZWRpdCBhbmQgc2F2 ZSBpdCAoYWN0dWFsbHkgdGhpcyBpcyB3aGF0IEkNCj4+ID51c3VhbGx5IGRvIHdpdGggdGhlIERy b3Bib3gpLiBUaGUgY2xpZW50IHdpbGwgc2VuZCB0aGUgd2hvbGUgZmlsZSB0byB0aGUNCj4+ID5z ZXJ2ZXIgZXZlcnkgdGltZSBJIHNhdmUgdGhlIGZpbGUuDQo+PiA+DQo+PiA+VG8gc3VtbWFyaXpl LCBpdCBzZWVtcyB0aGF0IHRoZSBvd25DbG91ZCBtYWtlcyBoZWF2aWx5IHVzZSBvZiBQUk9QRklO RCB0bw0KPj4gPmFjaGlldmUgdGhlIHN5bmMgcHJvY2Vzcy4gRWFjaCBzeW5jIG9wZXJhdGlvbiAo ZS5nLiB1cGxvYWQsIG1vZGlmeSBhbmQNCj4+ID5ldGMuKSB3aWxsIHN0YXJ0IHdpdGggc2VuZGlu ZyBvbmUgb3IgbW9yZSBQUk9QRklORHMuIEFuZCBjdXJyZW50bHksIGlmIEkNCj4+ID5hZGQgYSBm aWxlIHRvIHRoZSBzZXJ2ZXIgKGRpcmVjdGx5IGZyb20gdGhlIHNlcnZlciBzaWRlIHZpYSB3ZWIN Cj4+IGludGVyZmFjZSksDQo+PiA+dGhlIGNsaWVudCBjYW5ub3QgZmluZCB0aGUgY2hhbmdlLiBJ IG5lZWQgdG8gaW50ZXJydXB0IHRoZSBzeW5jIGFuZA0KPj4gcmVjb3Zlcg0KPj4gPml0IHRvIG1h a2UgdGhlIGNsaWVudCBiZSBhd2FyZSBvZiB0aGUgY2hhbmdlIGFuZCBkb3dubG9hZCB0aGUgbmV3 bHkgYWRkZWQNCj4+ID5maWxlLiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGlzIGlzIGNhdXNlZCBi eSB0aGUgc3luYyBtZWNoYW5pc20gb3IgYW4NCj4+ID5pbXByb3BlciBzZXJ2ZXIgY29uZmlndXJh dGlvbi4gSSBuZWVkIHRvIGludmVzdGlnYXRlIHRoaXMgZnVydGhlciBhbmQgYWxzbw0KPj4gPmhv dyB0aGUgb3duQ2xvdWQgd29ya3MgZm9yIG11bHRpcGxlIGNsaWVudHMgKG9yIGRldmljZXMpLg0K Pj4NCj4+IFdoYXQgZG8geW91IG1lYW4gYnkgImRpcmVjdGx5IGZyb20gdGhlIHNlcnZlciBzaWRl IHZpYSB3ZWIgaW50ZXJmYWNlIi4NCj4+IElmIGFsbCB0aGUgY29uZmlndXJhdGlvbiB3ZXJlIGNv cnJlY3QsIGRvIHlvdSB3YW50IHRvIGlkZW50aWZ5IHRoYXQgdGhlDQo+PiBzeW5jIGluDQo+PiBv d25DbG91ZCBpcyBvbmx5IHVuaWRpcmVjdGlvbmFsPw0KPj4NCj5QZW9wbGUgY291bGQgYWNjZXNz IHRvIHRoZSBvd25DbG91ZCBzZXJ2aWNlIHZpYSBkZXNrdG9wLCBtb2JpbGUgY2xpZW50IG9yDQo+ d2ViIGludGVyZmFjZSAoaS5lLiBicm93c2VyKSwgdGhlIHBvaW50IEkgd2FudCB0byBzYXkgaGVy ZSBpcyBhbiBvcGVyYXRpb24NCj5vbiB0aGUgc2VydmVyIHNpZGUgY2Fubm90IGJlIGRldGVjdGVk IGF1dG9tYXRpY2FsbHkuIEknbSBub3Qgc3VyZSB3aGV0aGVyDQo+SSd2ZSBjb25maWd1cmVkIHRo ZSBzZXJ2ZXIgY29ycmVjdGx5LiBCdXQgdGhlIHN5bmMgaXMgbm90IHVuaWRpcmVjdGlvbmFsDQo+ c2luY2UgYWZ0ZXIgSSByZWNvdmVyaW5nIHRoZSBzeW5jLCB0aGUgY2xpZW50IGNvdWxkIGRvd25s b2FkIHRoZSBhc2FwLg0KDQpJIHNlZSwgdGhlbiB0aGVyZSBtaWdodCBiZSBhbiBvcHRpb24gYXQg dGhlIHNlcnZlciBzaWRlIA0KY2FuIHN5bmMgdGhlIGNoYW5nZXMgdG8gdGhlIGNsaWVudCBhdXRv bWF0aWNhbGx5Lg0KDQoNCj4NCj4+DQo+PiA+DQo+PiA+Rm9yIElTUywgSSB0aGluayBvd25DbG91 ZCBoYXMgZGVtb25zdHJhdGVkIHRvIHNvbWUgZXh0ZW50IHRoYXQgc2ltaWxhcg0KPj4gSUVURg0K Pj4gPnByb3RvY29scyBjb3VsZCBiZSBkZXBsb3llZCBhbmQgZW1wbG95ZWQuIFRoZSBpbnRlbnRp b24gb2YgdGhpcyBtZXNzYWdlIGlzDQo+PiA+dG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJlbnQgc3Rh dGUgb2YgdXNpbmcgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzIHRvIHNlZQ0KPj4gPndoYXQgbmVl ZHMgdG8gYmUgaW1wcm92ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldyBwcm90b2NvbHMu DQo+Pg0KPj4NCj4+ID4NCj4+ID5Db21tZW50cyBhcmUgd2VsY29tZSA6ICkNCj4+ID4NCj4+ID5S ZWdhcmRzLA0KPj4gPkxpbmh1aQ0KPj4gPg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IFN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0KPj4gU3Rv cmFnZXN5bmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3RvcmFnZXN5bmMNCj4+DQo+ From nobody Wed Nov 25 19:37: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 930801A924B for ; Wed, 25 Nov 2015 19:37:37 -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 T9mPBfloyL2g for ; Wed, 25 Nov 2015 19:37:34 -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 54ED11A9251 for ; Wed, 25 Nov 2015 19:37:34 -0800 (PST) Received: by wmec201 with SMTP id c201so12593432wme.0 for ; Wed, 25 Nov 2015 19:37:33 -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=7UqjobXUF6aZN+IgCULTW2LCoVp/8uRHDJ/JNbqJx94=; b=MJd/o8v54P8prK/8/B9f7rpNAeXoCBU3xZjc+9V3w87Usc3nycwiR6jLuvSdivTYXy pQW/xQtreS1iYmGFjGtaRNbYUoDQ8i3ZWvgbGVi91+7T7+4UDBdxQJL3aQfgHwm9f8q8 XBtgqB1g3nz3XR90pg3i/BNlLeHBoW0AZJnFu21uTTeL07zRIhswviIHziNWfZfYziNJ PJtZPWmhzQom9Jn8tm/rc6rMRI7PTlmdweBn0wmd+o+c0JoNfT4Hur3gsonVv4DPuHVZ XfFogg1HuzpoOi9w5tsXHJiuDNgS2cE1RzizbSAtdCYKZ8TR0krJbgXuPSmH7BrGSb2j pcPg== X-Received: by 10.28.141.140 with SMTP id p134mr1105833wmd.6.1448509052973; Wed, 25 Nov 2015 19:37:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Wed, 25 Nov 2015 19:37:13 -0800 (PST) In-Reply-To: <2015112611280303192311@bjtu.edu.cn> References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> From: Linhui Sun Date: Thu, 26 Nov 2015 11:37:13 +0800 Message-ID: To: fsong Content-Type: multipart/alternative; boundary=001a1146a0b08e79300525694b23 Archived-At: Cc: Jakub Moscicki , 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: Thu, 26 Nov 2015 03:37:37 -0000 --001a1146a0b08e79300525694b23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-11-26 11:28 GMT+08:00 Fei Song : > BTW, Based on the last sentence of last email:"The intention of this > message is to investigate the current state of using WebDAV for sync > purposes to see what needs to be improved here and whether we need new > protocols" > > The outcome he/she wanted might be just the links like > http://cs3.ethz.ch/program.html :) > In another word, I think what I want finally might be a discussion about "What is needed for the ISS: a sync protocol or a generalized API". Sorry for the poor expression : ) Regards, Linhui > > > -------------- > Fei Song > >Hello, > > > >What kind of outcome are you looking for with this analysis? Some > research in this area has already been done or is being done as we speak > > > >e.g. "A study of delta-sync and other optimisation in HTTP/Webdav > synchonisation protocols" > > > >see "Technology and Research": > > > >http://cs3.ethz.ch/program.html > > > >It would be interesting to see if there is a potential for collaboration= . > Or maybe we already have some information you are looking for. > > > >Best regards, > > > >Jakub Moscicki > > > >=E2=80=94 > > > > > >On 25 Nov 2015, at 11:45, Linhui Sun lh.sunlinh@gmail.com>> wrote: > > > >Hi all, > > > >As I mentioned before, I think the developers could benefit from the IET= F > standards. The ownCloud (https://owncloud.org/) is just an example. It is > developed for those who do not trust commercial storage services and want > to build their own network-based storage services. The ownCloud is using > WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed fo= r > distributed work but not for the sync. Thus, I made some preliminary > investigations on how the ownCloud uses WebDAV for sync purposes. A brief > summary of what I've found is in the following, please correct me if I am > wrong. > > > >I installed the ownCloud server (v8.2.1) on the CentOS7, and the client > is a desktop client on Windows. > > > >1. To find whether there is a change to the synced directory, the client > continuously sends PROPFIND to the server at regular intervals (around 34 > seconds under my observation). The server will respond a 207 Multi-Status > Response to tell whether the main directory has been changed. To perform > this regular check, the client will open a new TCP connection to send the > PROPFIND, the server will close the existing TCP connection after > responding the 207 Multi-Status Response. For the next check, the client > will open another new TCP connection. > > > >2. Every time adding (or creating) a new file to the local folder, the > client will open a new TCP connection (if there is no connection existing= ) > to send the file asap. The client will first send several PROPFINDs to fi= nd > out which sub-directory has been changed. And then it sends the file usin= g > PUT. The server will respond a 201 Created Response and then terminate th= e > connection. Currently, I haven't found any application layer chunking, al= l > the segmentation are performed by TCP. > > > >3. Every time I delete (or rename) a file locally, the client will also > open a new TCP connection to send several PROPFINDs to find out which fil= e > has been removed (or renamed). Then it will send DELETE (or MOVE). The > server will respond a 204 No Content Response (or 201 Created Response) a= nd > then terminate the connection. > > > >4. I open a file and frequently edit and save it (actually this is what = I > usually do with the Dropbox). The client will send the whole file to the > server every time I save the file. > > > >To summarize, it seems that the ownCloud makes heavily use of PROPFIND t= o > achieve the sync process. Each sync operation (e.g. upload, modify and > etc.) will start with sending one or more PROPFINDs. And currently, if I > add a file to the server (directly from the server side via web interface= ), > the client cannot find the change. I need to interrupt the sync and recov= er > it to make the client be aware of the change and download the newly added > file. I'm not sure whether this is caused by the sync mechanism or an > improper server configuration. I need to investigate this further and als= o > how the ownCloud works for multiple clients (or devices). > > > >For ISS, I think ownCloud has demonstrated to some extent that similar > IETF protocols could be deployed and employed. The intention of this > message is to investigate the current state of using WebDAV for sync > purposes to see what needs to be improved here and whether we need new > protocols. > > > >Comments are welcome : ) > > > >Regards, > >Linhui > > > > > >_______________________________________________ > >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 > --001a1146a0b08e79300525694b23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-11-26 11:28 GMT+08:00 Fei Song <fsong@bjtu.edu.cn>:=
BTW, Based on the last sentence of last email:"Th= e intention of this message is to investigate the current state of using We= bDAV for sync purposes to see what needs to be improved here and whether we= need new protocols"

The outcome he/she wanted might be just the links like http://cs3.eth= z.ch/program.html :)
In another word, I think what= I want finally might be a discussion about "What is needed for the IS= S: a sync protocol or a generalized API". Sorry for the poor expressio= n : )

Regards,
Linhui=C2=A0


--------------
Fei Song
>Hello,
>
>What kind of outcome are you looking for with this analysis? Some resea= rch in this area has already been done or is being done as we speak
>
>e.g. "A study of delta-sync and other optimisation in HTTP/Webdav = synchonisation protocols"
>
>see "Technology and Research":
>
>http://cs3.ethz.ch/program.html
>
>It would be interesting to see if there is a potential for collaboratio= n. Or maybe we already have some information you are looking for.
>
>Best regards,
>
>Jakub Moscicki
>
>=E2=80=94
>
>
>On 25 Nov 2015, at 11:45, Linhui Sun <lh.sunlinh@gmail.com<mailto:lh.sunlinh@gmail.com>> wrote: >
>Hi all,
>
>As I mentioned before, I think the developers could benefit from the IE= TF standards. The ownCloud (https://owncloud.org/) is just an example. It i= s developed for those who do not trust commercial storage services and want= to build their own network-based storage services. The ownCloud is using W= ebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed for d= istributed work but not for the sync. Thus, I made some preliminary investi= gations on how the ownCloud uses WebDAV for sync purposes. A brief summary = of what I've found is in the following, please correct me if I am wrong= .
>
>I installed the ownCloud server (v8.2.1) on the CentOS7, and the client= is a desktop client on Windows.
>
>1. To find whether there is a change to the synced directory, the clien= t continuously sends PROPFIND to the server at regular intervals (around 34= seconds under my observation). The server will respond a 207 Multi-Status = Response to tell whether the main directory has been changed. To perform th= is regular check, the client will open a new TCP connection to send the PRO= PFIND, the server will close the existing TCP connection after responding t= he 207 Multi-Status Response. For the next check, the client will open anot= her new TCP connection.
>
>2. Every time adding (or creating) a new file to the local folder, the = client will open a new TCP connection (if there is no connection existing) = to send the file asap. The client will first send several PROPFINDs to find= out which sub-directory has been changed. And then it sends the file using= PUT. The server will respond a 201 Created Response and then terminate the= connection. Currently, I haven't found any application layer chunking,= all the segmentation are performed by TCP.
>
>3. Every time I delete (or rename) a file locally, the client will also= open a new TCP connection to send several PROPFINDs to find out which file= has been removed (or renamed). Then it will send DELETE (or MOVE). The ser= ver will respond a 204 No Content Response (or 201 Created Response) and th= en terminate the connection.
>
>4. I open a file and frequently edit and save it (actually this is what= I usually do with the Dropbox). The client will send the whole file to the= server every time I save the file.
>
>To summarize, it seems that the ownCloud makes heavily use of PROPFIND = to achieve the sync process. Each sync operation (e.g. upload, modify and e= tc.) will start with sending one or more PROPFINDs. And currently, if I add= a file to the server (directly from the server side via web interface), th= e client cannot find the change. I need to interrupt the sync and recover i= t to make the client be aware of the change and download the newly added fi= le. I'm not sure whether this is caused by the sync mechanism or an imp= roper server configuration. I need to investigate this further and also how= the ownCloud works for multiple clients (or devices).
>
>For ISS, I think ownCloud has demonstrated to some extent that similar = IETF protocols could be deployed and employed. The intention of this messag= e is to investigate the current state of using WebDAV for sync purposes to = see what needs to be improved here and whether we need new protocols.
>
>Comments are welcome : )
>
>Regards,
>Linhui
>
>
>_______________________________________________
>Storagesync mailing list
>Storagesync@ietf.org= <mailto:Storagesync@ietf.org= >
>https://www.ietf.org/mailman/listinfo/storagesy= nc
>
_______________________________________________
Storagesync mailing list
Storagesync@ietf.org
https://www.ietf.org/mailman/listinfo/storagesync

--001a1146a0b08e79300525694b23-- From nobody Wed Nov 25 20:56: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 5C7C01A01EC for ; Wed, 25 Nov 2015 20:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 xqS--W25AvoP for ; Wed, 25 Nov 2015 20:56:45 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 547381A899A for ; Wed, 25 Nov 2015 20:56:44 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb3 (Coremail) with SMTP id d55wygDHlKaHkVZWo2FmAA--.31092S2; Thu, 26 Nov 2015 12:58:47 +0800 (CST) Date: Thu, 26 Nov 2015 12:56:32 +0800 From: "Fei Song" To: "Linhui Sun" 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: <2015112612563203148818@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: d55wygDHlKaHkVZWo2FmAA--.31092S2 X-Coremail-Antispam: 1UD129KBjvJXoWxtr4ftr1DZF1DKryDZF4fKrg_yoW7KryrpF W3t3WkKFykJw4xCwn2qr129F10vr95JrW7Xrn8Jw1xJrZ0gFy3tF1xtr15uFyUGrWfGr1j qF4F9FW3C3Z8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_Gryl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07 bzoGdUUUUU= X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/ Archived-At: Cc: Jakub Moscicki , 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: Thu, 26 Nov 2015 04:56:48 -0000 SSB0aGluayB3aGF0IElTUyBuZWVkIGlzIGEgbmV3IHByb3RvY29sLCBoZXJlIGFyZSBzb21lIHRo b3VnaHRzOg0KDQoxLglUaGUgbGF0ZXN0IHZlcnNpb24gb2YgV2ViREFWIChSRkMgNDkxOCkgd2Fz IHN0YW5kYXJkaXplZCBpbiAyMDA3LiBXZSBoYXZlIHdpdG5lc3NlZCB0aGF0IGNsb3VkIHN0b3Jh Z2Ugb3Igb25saW5lIHN0b3JhZ2UgaGFkIGJlZW4gd2lkZWx5IHVzZWQuIE1vcmUgYW5kIG1vcmUg YXBwbGljYXRpb25zIGhhZCBiZWVuIGVtZXJnaW5nIHJlY2VudGx5LiBJdCBpcyBub3QgcXVpdGUg ZmxleGlibGUgZm9yIHRoZSBkZXZlbG9wZXIgb3Igc2VydmljZSBwcm92aWRlcnMgdG8gdXNlIFdl YkRBViBvciBvdGhlciBjb21wZXRlbnQgc2NoZW1lcyB0byBtZWV0IHRoZXNlIG5ldyBhbmQgY2hh bGxlbmdpbmcgcmVxdWlyZW1lbnRzIHF1aWNrbHkuDQoyLglFdmVuIGlmIHRoZSBtb2RpZmljYXRp b25zIG9mIFdlYkRBViBvciBvdGhlciBjb21wZXRlbnQgc2NoZW1lcyBhcmUgYWNjb21wbGlzaGVk IHRvIGFjaGlldmUgZGlmZmVyZW50IHB1cnBvc2UsIGl0IGlzIG5vdCBiZW5lZmljaWFsIGZvciB0 aGUgdW5pZmljYXRpb24gYW5kIHN0YW5kYXJkaXphdGlvbi4NCjMuCUEgZ2VuZXJhbGl6ZWQgQVBJ IGlzIGhhcmQgdG8gaGF2ZS4gU29tZXRpbWVzIGl0IGlzIGV2ZW4gaGFyZGVyIHRoYW4gdG8gZGVz aWduIGEgcHJvdG9jb2wgc2luY2UgdGhlcmUgYXJlIGRpdmVyc2UgcHJvdG9jb2xzIGFuZCBldmVy LWNoYW5naW5nIGltcGxlbWVudGF0aW9uIHZlcnNpb24uIEl0IG1pZ2h0IGJlIG91dCBvZiB0aGUg c2NvcGUgb2YgSUVURiBhcyB3ZWxsoa0NCg0KDQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0K PjIwMTUtMTEtMjYgMTE6MjggR01UKzA4OjAwIEZlaSBTb25nIDxmc29uZ0BianR1LmVkdS5jbj46 DQo+DQo+PiBCVFcsIEJhc2VkIG9uIHRoZSBsYXN0IHNlbnRlbmNlIG9mIGxhc3QgZW1haWw6IlRo ZSBpbnRlbnRpb24gb2YgdGhpcw0KPj4gbWVzc2FnZSBpcyB0byBpbnZlc3RpZ2F0ZSB0aGUgY3Vy cmVudCBzdGF0ZSBvZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMNCj4+IHB1cnBvc2VzIHRvIHNlZSB3 aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIgd2UgbmVlZCBuZXcNCj4+ IHByb3RvY29scyINCj4+DQo+PiBUaGUgb3V0Y29tZSBoZS9zaGUgd2FudGVkIG1pZ2h0IGJlIGp1 c3QgdGhlIGxpbmtzIGxpa2UNCj4+IGh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwgOikN Cj4+DQo+SW4gYW5vdGhlciB3b3JkLCBJIHRoaW5rIHdoYXQgSSB3YW50IGZpbmFsbHkgbWlnaHQg YmUgYSBkaXNjdXNzaW9uIGFib3V0DQo+IldoYXQgaXMgbmVlZGVkIGZvciB0aGUgSVNTOiBhIHN5 bmMgcHJvdG9jb2wgb3IgYSBnZW5lcmFsaXplZCBBUEkiLiBTb3JyeQ0KPmZvciB0aGUgcG9vciBl eHByZXNzaW9uIDogKQ0KPg0KPlJlZ2FyZHMsDQo+TGluaHVpDQo+DQo+Pg0KPj4NCj4+IC0tLS0t LS0tLS0tLS0tDQo+PiBGZWkgU29uZw0KPj4gPkhlbGxvLA0KPj4gPg0KPj4gPldoYXQga2luZCBv ZiBvdXRjb21lIGFyZSB5b3UgbG9va2luZyBmb3Igd2l0aCB0aGlzIGFuYWx5c2lzPyBTb21lDQo+ PiByZXNlYXJjaCBpbiB0aGlzIGFyZWEgaGFzIGFscmVhZHkgYmVlbiBkb25lIG9yIGlzIGJlaW5n IGRvbmUgYXMgd2Ugc3BlYWsNCj4+ID4NCj4+ID5lLmcuICJBIHN0dWR5IG9mIGRlbHRhLXN5bmMg YW5kIG90aGVyIG9wdGltaXNhdGlvbiBpbiBIVFRQL1dlYmRhdg0KPj4gc3luY2hvbmlzYXRpb24g cHJvdG9jb2xzIg0KPj4gPg0KPj4gPnNlZSAiVGVjaG5vbG9neSBhbmQgUmVzZWFyY2giOg0KPj4g Pg0KPj4gPmh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwNCj4+ID4NCj4+ID5JdCB3b3Vs ZCBiZSBpbnRlcmVzdGluZyB0byBzZWUgaWYgdGhlcmUgaXMgYSBwb3RlbnRpYWwgZm9yIGNvbGxh Ym9yYXRpb24uDQo+PiBPciBtYXliZSB3ZSBhbHJlYWR5IGhhdmUgc29tZSBpbmZvcm1hdGlvbiB5 b3UgYXJlIGxvb2tpbmcgZm9yLg0KPj4gPg0KPj4gPkJlc3QgcmVnYXJkcywNCj4+ID4NCj4+ID5K YWt1YiBNb3NjaWNraQ0KPj4gPg0KPj4gPqGqDQo+PiA+DQo+PiA+DQo+PiA+T24gMjUgTm92IDIw MTUsIGF0IDExOjQ1LCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbTxtYWlsdG86DQo+ PiBsaC5zdW5saW5oQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4gPg0KPj4gPkhpIGFsbCwNCj4+ID4N Cj4+ID5BcyBJIG1lbnRpb25lZCBiZWZvcmUsIEkgdGhpbmsgdGhlIGRldmVsb3BlcnMgY291bGQg YmVuZWZpdCBmcm9tIHRoZSBJRVRGDQo+PiBzdGFuZGFyZHMuIFRoZSBvd25DbG91ZCAoaHR0cHM6 Ly9vd25jbG91ZC5vcmcvKSBpcyBqdXN0IGFuIGV4YW1wbGUuIEl0IGlzDQo+PiBkZXZlbG9wZWQg Zm9yIHRob3NlIHdobyBkbyBub3QgdHJ1c3QgY29tbWVyY2lhbCBzdG9yYWdlIHNlcnZpY2VzIGFu ZCB3YW50DQo+PiB0byBidWlsZCB0aGVpciBvd24gbmV0d29yay1iYXNlZCBzdG9yYWdlIHNlcnZp Y2VzLiBUaGUgb3duQ2xvdWQgaXMgdXNpbmcNCj4+IFdlYkRBViAoUkZDNDkxOCkgdG8gYWNoaWV2 ZSB0aGUgZGF0YSBzeW5jLiBJTU8sIHRoZSBXZWJEQVYgaXMgZGVzaWduZWQgZm9yDQo+PiBkaXN0 cmlidXRlZCB3b3JrIGJ1dCBub3QgZm9yIHRoZSBzeW5jLiBUaHVzLCBJIG1hZGUgc29tZSBwcmVs aW1pbmFyeQ0KPj4gaW52ZXN0aWdhdGlvbnMgb24gaG93IHRoZSBvd25DbG91ZCB1c2VzIFdlYkRB ViBmb3Igc3luYyBwdXJwb3Nlcy4gQSBicmllZg0KPj4gc3VtbWFyeSBvZiB3aGF0IEkndmUgZm91 bmQgaXMgaW4gdGhlIGZvbGxvd2luZywgcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbQ0KPj4gd3Jv bmcuDQo+PiA+DQo+PiA+SSBpbnN0YWxsZWQgdGhlIG93bkNsb3VkIHNlcnZlciAodjguMi4xKSBv biB0aGUgQ2VudE9TNywgYW5kIHRoZSBjbGllbnQNCj4+IGlzIGEgZGVza3RvcCBjbGllbnQgb24g V2luZG93cy4NCj4+ID4NCj4+ID4xLiBUbyBmaW5kIHdoZXRoZXIgdGhlcmUgaXMgYSBjaGFuZ2Ug dG8gdGhlIHN5bmNlZCBkaXJlY3RvcnksIHRoZSBjbGllbnQNCj4+IGNvbnRpbnVvdXNseSBzZW5k cyBQUk9QRklORCB0byB0aGUgc2VydmVyIGF0IHJlZ3VsYXIgaW50ZXJ2YWxzIChhcm91bmQgMzQN Cj4+IHNlY29uZHMgdW5kZXIgbXkgb2JzZXJ2YXRpb24pLiBUaGUgc2VydmVyIHdpbGwgcmVzcG9u ZCBhIDIwNyBNdWx0aS1TdGF0dXMNCj4+IFJlc3BvbnNlIHRvIHRlbGwgd2hldGhlciB0aGUgbWFp biBkaXJlY3RvcnkgaGFzIGJlZW4gY2hhbmdlZC4gVG8gcGVyZm9ybQ0KPj4gdGhpcyByZWd1bGFy IGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiB0byBzZW5k IHRoZQ0KPj4gUFJPUEZJTkQsIHRoZSBzZXJ2ZXIgd2lsbCBjbG9zZSB0aGUgZXhpc3RpbmcgVENQ IGNvbm5lY3Rpb24gYWZ0ZXINCj4+IHJlc3BvbmRpbmcgdGhlIDIwNyBNdWx0aS1TdGF0dXMgUmVz cG9uc2UuIEZvciB0aGUgbmV4dCBjaGVjaywgdGhlIGNsaWVudA0KPj4gd2lsbCBvcGVuIGFub3Ro ZXIgbmV3IFRDUCBjb25uZWN0aW9uLg0KPj4gPg0KPj4gPjIuIEV2ZXJ5IHRpbWUgYWRkaW5nIChv ciBjcmVhdGluZykgYSBuZXcgZmlsZSB0byB0aGUgbG9jYWwgZm9sZGVyLCB0aGUNCj4+IGNsaWVu dCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gKGlmIHRoZXJlIGlzIG5vIGNvbm5lY3Rp b24gZXhpc3RpbmcpDQo+PiB0byBzZW5kIHRoZSBmaWxlIGFzYXAuIFRoZSBjbGllbnQgd2lsbCBm aXJzdCBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQNCj4+IG91dCB3aGljaCBzdWItZGly ZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQuIEFuZCB0aGVuIGl0IHNlbmRzIHRoZSBmaWxlIHVzaW5n DQo+PiBQVVQuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjAxIENyZWF0ZWQgUmVzcG9uc2Ug YW5kIHRoZW4gdGVybWluYXRlIHRoZQ0KPj4gY29ubmVjdGlvbi4gQ3VycmVudGx5LCBJIGhhdmVu J3QgZm91bmQgYW55IGFwcGxpY2F0aW9uIGxheWVyIGNodW5raW5nLCBhbGwNCj4+IHRoZSBzZWdt ZW50YXRpb24gYXJlIHBlcmZvcm1lZCBieSBUQ1AuDQo+PiA+DQo+PiA+My4gRXZlcnkgdGltZSBJ IGRlbGV0ZSAob3IgcmVuYW1lKSBhIGZpbGUgbG9jYWxseSwgdGhlIGNsaWVudCB3aWxsIGFsc28N Cj4+IG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gdG8gc2VuZCBzZXZlcmFsIFBST1BGSU5EcyB0 byBmaW5kIG91dCB3aGljaCBmaWxlDQo+PiBoYXMgYmVlbiByZW1vdmVkIChvciByZW5hbWVkKS4g VGhlbiBpdCB3aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4gVGhlDQo+PiBzZXJ2ZXIgd2lsbCBy ZXNwb25kIGEgMjA0IE5vIENvbnRlbnQgUmVzcG9uc2UgKG9yIDIwMSBDcmVhdGVkIFJlc3BvbnNl KSBhbmQNCj4+IHRoZW4gdGVybWluYXRlIHRoZSBjb25uZWN0aW9uLg0KPj4gPg0KPj4gPjQuIEkg b3BlbiBhIGZpbGUgYW5kIGZyZXF1ZW50bHkgZWRpdCBhbmQgc2F2ZSBpdCAoYWN0dWFsbHkgdGhp cyBpcyB3aGF0IEkNCj4+IHVzdWFsbHkgZG8gd2l0aCB0aGUgRHJvcGJveCkuIFRoZSBjbGllbnQg d2lsbCBzZW5kIHRoZSB3aG9sZSBmaWxlIHRvIHRoZQ0KPj4gc2VydmVyIGV2ZXJ5IHRpbWUgSSBz YXZlIHRoZSBmaWxlLg0KPj4gPg0KPj4gPlRvIHN1bW1hcml6ZSwgaXQgc2VlbXMgdGhhdCB0aGUg b3duQ2xvdWQgbWFrZXMgaGVhdmlseSB1c2Ugb2YgUFJPUEZJTkQgdG8NCj4+IGFjaGlldmUgdGhl IHN5bmMgcHJvY2Vzcy4gRWFjaCBzeW5jIG9wZXJhdGlvbiAoZS5nLiB1cGxvYWQsIG1vZGlmeSBh bmQNCj4+IGV0Yy4pIHdpbGwgc3RhcnQgd2l0aCBzZW5kaW5nIG9uZSBvciBtb3JlIFBST1BGSU5E cy4gQW5kIGN1cnJlbnRseSwgaWYgSQ0KPj4gYWRkIGEgZmlsZSB0byB0aGUgc2VydmVyIChkaXJl Y3RseSBmcm9tIHRoZSBzZXJ2ZXIgc2lkZSB2aWEgd2ViIGludGVyZmFjZSksDQo+PiB0aGUgY2xp ZW50IGNhbm5vdCBmaW5kIHRoZSBjaGFuZ2UuIEkgbmVlZCB0byBpbnRlcnJ1cHQgdGhlIHN5bmMg YW5kIHJlY292ZXINCj4+IGl0IHRvIG1ha2UgdGhlIGNsaWVudCBiZSBhd2FyZSBvZiB0aGUgY2hh bmdlIGFuZCBkb3dubG9hZCB0aGUgbmV3bHkgYWRkZWQNCj4+IGZpbGUuIEknbSBub3Qgc3VyZSB3 aGV0aGVyIHRoaXMgaXMgY2F1c2VkIGJ5IHRoZSBzeW5jIG1lY2hhbmlzbSBvciBhbg0KPj4gaW1w cm9wZXIgc2VydmVyIGNvbmZpZ3VyYXRpb24uIEkgbmVlZCB0byBpbnZlc3RpZ2F0ZSB0aGlzIGZ1 cnRoZXIgYW5kIGFsc28NCj4+IGhvdyB0aGUgb3duQ2xvdWQgd29ya3MgZm9yIG11bHRpcGxlIGNs aWVudHMgKG9yIGRldmljZXMpLg0KPj4gPg0KPj4gPkZvciBJU1MsIEkgdGhpbmsgb3duQ2xvdWQg aGFzIGRlbW9uc3RyYXRlZCB0byBzb21lIGV4dGVudCB0aGF0IHNpbWlsYXINCj4+IElFVEYgcHJv dG9jb2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3llZC4gVGhlIGludGVudGlvbiBvZiB0 aGlzDQo+PiBtZXNzYWdlIGlzIHRvIGludmVzdGlnYXRlIHRoZSBjdXJyZW50IHN0YXRlIG9mIHVz aW5nIFdlYkRBViBmb3Igc3luYw0KPj4gcHVycG9zZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUg aW1wcm92ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBuZWVkIG5ldw0KPj4gcHJvdG9jb2xzLg0KPj4g Pg0KPj4gPkNvbW1lbnRzIGFyZSB3ZWxjb21lIDogKQ0KPj4gPg0KPj4gPlJlZ2FyZHMsDQo+PiA+ TGluaHVpDQo+PiA+DQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+ID5TdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNCj4+ID5TdG9yYWdl c3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+DQo+PiA+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPj4gPg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFN0b3JhZ2VzeW5j IG1haWxpbmcgbGlzdA0KPj4gU3RvcmFnZXN5bmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+DQo+ From nobody Wed Nov 25 21:03: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 97F941ACDD4 for ; Wed, 25 Nov 2015 21:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 ePJabmiBmFGl for ; Wed, 25 Nov 2015 21:03:26 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6E61ACDD3 for ; Wed, 25 Nov 2015 21:03:25 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygBnSQYjk1ZWOI7jAA--.16347S2; Thu, 26 Nov 2015 13:05:39 +0800 (CST) Date: Thu, 26 Nov 2015 13:03:29 +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: <2015112613032953136920@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: Mp5wygBnSQYjk1ZWOI7jAA--.16347S2 X-Coremail-Antispam: 1UD129KBjvJXoWxKr4fGrWfuF18uw17trW7CFg_yoW7Cw4DpF Zxt3WkKFWkJr4xCwn7tryj9r10vrykJrW7Xrn8Jr4xArZ0gFy3tF1Iyr4ruFyDGrWfGr1j qr1Ygay3Awn8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iq xwCY02Avz4vE14v_GrWl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07 jYzuZUUUUU= 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: Thu, 26 Nov 2015 05:03:28 -0000 SSB3aWxsIGFsc28gYWRkIHRoaXMgaW50byAicmVjZW50IGlzc3VlcyBkaXNjdXNzZWQiLiBIZXJl IGlzIHRoZSBsYXRlc3QgdmVyc2lvbjoNCg0KMS4gVGhlIGRlc2lnbiB0YXJnZXRzIG9mIFdlYkRB ViwgcnN5bmMgYW5kIG90aGVyIGV4aXN0aW5nIGFwcHJvYWNoZXM/DQoyLiBUaGUgcG90ZW50aWFs IHVzZSBjYXNlcyBvZiBJU1MsIHN1Y2ggYXMgY2xpZW50L3NlcnZlciwgZ2l0LWxpa2UgcGF0dGVy biwgc3ZuLCBldGMuDQozLiBUaGUgZWZmaWNpZW5jeSBpbXByb3ZlbWVudHMgbWlnaHQgYmUgdGhl IHNlY29uZCBnb2FsIGZvciBzdGFuZGFyZGl6aW5nIElTUyBwcm90b2NvbA0KNC4gQ09SUyBoZWFk ZXJzIG9uIHN0b3JhZ2Ugc3luYyBBUElzDQo1LiBXaGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzog YSBzeW5jIHByb3RvY29sIG9yIGEgZ2VuZXJhbGl6ZWQgQVBJDQoNCg0KLS0tLS0tLS0tLS0tLS0N CkZlaSBTb25nDQo+MjAxNS0xMS0yNiAxMToyOCBHTVQrMDg6MDAgRmVpIFNvbmcgPGZzb25nQGJq dHUuZWR1LmNuPjoNCj4NCj4+IEJUVywgQmFzZWQgb24gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgbGFz dCBlbWFpbDoiVGhlIGludGVudGlvbiBvZiB0aGlzDQo+PiBtZXNzYWdlIGlzIHRvIGludmVzdGln YXRlIHRoZSBjdXJyZW50IHN0YXRlIG9mIHVzaW5nIFdlYkRBViBmb3Igc3luYw0KPj4gcHVycG9z ZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBu ZWVkIG5ldw0KPj4gcHJvdG9jb2xzIg0KPj4NCj4+IFRoZSBvdXRjb21lIGhlL3NoZSB3YW50ZWQg bWlnaHQgYmUganVzdCB0aGUgbGlua3MgbGlrZQ0KPj4gaHR0cDovL2NzMy5ldGh6LmNoL3Byb2dy YW0uaHRtbCA6KQ0KPj4NCj5JbiBhbm90aGVyIHdvcmQsIEkgdGhpbmsgd2hhdCBJIHdhbnQgZmlu YWxseSBtaWdodCBiZSBhIGRpc2N1c3Npb24gYWJvdXQNCj4iV2hhdCBpcyBuZWVkZWQgZm9yIHRo ZSBJU1M6IGEgc3luYyBwcm90b2NvbCBvciBhIGdlbmVyYWxpemVkIEFQSSIuIFNvcnJ5DQo+Zm9y IHRoZSBwb29yIGV4cHJlc3Npb24gOiApDQo+DQo+UmVnYXJkcywNCj5MaW5odWkNCj4NCj4+DQo+ Pg0KPj4gLS0tLS0tLS0tLS0tLS0NCj4+IEZlaSBTb25nDQo+PiA+SGVsbG8sDQo+PiA+DQo+PiA+ V2hhdCBraW5kIG9mIG91dGNvbWUgYXJlIHlvdSBsb29raW5nIGZvciB3aXRoIHRoaXMgYW5hbHlz aXM/IFNvbWUNCj4+IHJlc2VhcmNoIGluIHRoaXMgYXJlYSBoYXMgYWxyZWFkeSBiZWVuIGRvbmUg b3IgaXMgYmVpbmcgZG9uZSBhcyB3ZSBzcGVhaw0KPj4gPg0KPj4gPmUuZy4gIkEgc3R1ZHkgb2Yg ZGVsdGEtc3luYyBhbmQgb3RoZXIgb3B0aW1pc2F0aW9uIGluIEhUVFAvV2ViZGF2DQo+PiBzeW5j aG9uaXNhdGlvbiBwcm90b2NvbHMiDQo+PiA+DQo+PiA+c2VlICJUZWNobm9sb2d5IGFuZCBSZXNl YXJjaCI6DQo+PiA+DQo+PiA+aHR0cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbA0KPj4gPg0K Pj4gPkl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIHNlZSBpZiB0aGVyZSBpcyBhIHBvdGVudGlh bCBmb3IgY29sbGFib3JhdGlvbi4NCj4+IE9yIG1heWJlIHdlIGFscmVhZHkgaGF2ZSBzb21lIGlu Zm9ybWF0aW9uIHlvdSBhcmUgbG9va2luZyBmb3IuDQo+PiA+DQo+PiA+QmVzdCByZWdhcmRzLA0K Pj4gPg0KPj4gPkpha3ViIE1vc2NpY2tpDQo+PiA+DQo+PiA+oaoNCj4+ID4NCj4+ID4NCj4+ID5P biAyNSBOb3YgMjAxNSwgYXQgMTE6NDUsIExpbmh1aSBTdW4gPGxoLnN1bmxpbmhAZ21haWwuY29t PG1haWx0bzoNCj4+IGxoLnN1bmxpbmhAZ21haWwuY29tPj4gd3JvdGU6DQo+PiA+DQo+PiA+SGkg YWxsLA0KPj4gPg0KPj4gPkFzIEkgbWVudGlvbmVkIGJlZm9yZSwgSSB0aGluayB0aGUgZGV2ZWxv cGVycyBjb3VsZCBiZW5lZml0IGZyb20gdGhlIElFVEYNCj4+IHN0YW5kYXJkcy4gVGhlIG93bkNs b3VkIChodHRwczovL293bmNsb3VkLm9yZy8pIGlzIGp1c3QgYW4gZXhhbXBsZS4gSXQgaXMNCj4+ IGRldmVsb3BlZCBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB0cnVzdCBjb21tZXJjaWFsIHN0b3JhZ2Ug c2VydmljZXMgYW5kIHdhbnQNCj4+IHRvIGJ1aWxkIHRoZWlyIG93biBuZXR3b3JrLWJhc2VkIHN0 b3JhZ2Ugc2VydmljZXMuIFRoZSBvd25DbG91ZCBpcyB1c2luZw0KPj4gV2ViREFWIChSRkM0OTE4 KSB0byBhY2hpZXZlIHRoZSBkYXRhIHN5bmMuIElNTywgdGhlIFdlYkRBViBpcyBkZXNpZ25lZCBm b3INCj4+IGRpc3RyaWJ1dGVkIHdvcmsgYnV0IG5vdCBmb3IgdGhlIHN5bmMuIFRodXMsIEkgbWFk ZSBzb21lIHByZWxpbWluYXJ5DQo+PiBpbnZlc3RpZ2F0aW9ucyBvbiBob3cgdGhlIG93bkNsb3Vk IHVzZXMgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzLiBBIGJyaWVmDQo+PiBzdW1tYXJ5IG9mIHdo YXQgSSd2ZSBmb3VuZCBpcyBpbiB0aGUgZm9sbG93aW5nLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJ IGFtDQo+PiB3cm9uZy4NCj4+ID4NCj4+ID5JIGluc3RhbGxlZCB0aGUgb3duQ2xvdWQgc2VydmVy ICh2OC4yLjEpIG9uIHRoZSBDZW50T1M3LCBhbmQgdGhlIGNsaWVudA0KPj4gaXMgYSBkZXNrdG9w IGNsaWVudCBvbiBXaW5kb3dzLg0KPj4gPg0KPj4gPjEuIFRvIGZpbmQgd2hldGhlciB0aGVyZSBp cyBhIGNoYW5nZSB0byB0aGUgc3luY2VkIGRpcmVjdG9yeSwgdGhlIGNsaWVudA0KPj4gY29udGlu dW91c2x5IHNlbmRzIFBST1BGSU5EIHRvIHRoZSBzZXJ2ZXIgYXQgcmVndWxhciBpbnRlcnZhbHMg KGFyb3VuZCAzNA0KPj4gc2Vjb25kcyB1bmRlciBteSBvYnNlcnZhdGlvbikuIFRoZSBzZXJ2ZXIg d2lsbCByZXNwb25kIGEgMjA3IE11bHRpLVN0YXR1cw0KPj4gUmVzcG9uc2UgdG8gdGVsbCB3aGV0 aGVyIHRoZSBtYWluIGRpcmVjdG9yeSBoYXMgYmVlbiBjaGFuZ2VkLiBUbyBwZXJmb3JtDQo+PiB0 aGlzIHJlZ3VsYXIgY2hlY2ssIHRoZSBjbGllbnQgd2lsbCBvcGVuIGEgbmV3IFRDUCBjb25uZWN0 aW9uIHRvIHNlbmQgdGhlDQo+PiBQUk9QRklORCwgdGhlIHNlcnZlciB3aWxsIGNsb3NlIHRoZSBl eGlzdGluZyBUQ1AgY29ubmVjdGlvbiBhZnRlcg0KPj4gcmVzcG9uZGluZyB0aGUgMjA3IE11bHRp LVN0YXR1cyBSZXNwb25zZS4gRm9yIHRoZSBuZXh0IGNoZWNrLCB0aGUgY2xpZW50DQo+PiB3aWxs IG9wZW4gYW5vdGhlciBuZXcgVENQIGNvbm5lY3Rpb24uDQo+PiA+DQo+PiA+Mi4gRXZlcnkgdGlt ZSBhZGRpbmcgKG9yIGNyZWF0aW5nKSBhIG5ldyBmaWxlIHRvIHRoZSBsb2NhbCBmb2xkZXIsIHRo ZQ0KPj4gY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiAoaWYgdGhlcmUgaXMg bm8gY29ubmVjdGlvbiBleGlzdGluZykNCj4+IHRvIHNlbmQgdGhlIGZpbGUgYXNhcC4gVGhlIGNs aWVudCB3aWxsIGZpcnN0IHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZA0KPj4gb3V0IHdo aWNoIHN1Yi1kaXJlY3RvcnkgaGFzIGJlZW4gY2hhbmdlZC4gQW5kIHRoZW4gaXQgc2VuZHMgdGhl IGZpbGUgdXNpbmcNCj4+IFBVVC4gVGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDEgQ3JlYXRl ZCBSZXNwb25zZSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhlDQo+PiBjb25uZWN0aW9uLiBDdXJyZW50 bHksIEkgaGF2ZW4ndCBmb3VuZCBhbnkgYXBwbGljYXRpb24gbGF5ZXIgY2h1bmtpbmcsIGFsbA0K Pj4gdGhlIHNlZ21lbnRhdGlvbiBhcmUgcGVyZm9ybWVkIGJ5IFRDUC4NCj4+ID4NCj4+ID4zLiBF dmVyeSB0aW1lIEkgZGVsZXRlIChvciByZW5hbWUpIGEgZmlsZSBsb2NhbGx5LCB0aGUgY2xpZW50 IHdpbGwgYWxzbw0KPj4gb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiB0byBzZW5kIHNldmVyYWwg UFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIGZpbGUNCj4+IGhhcyBiZWVuIHJlbW92ZWQgKG9y IHJlbmFtZWQpLiBUaGVuIGl0IHdpbGwgc2VuZCBERUxFVEUgKG9yIE1PVkUpLiBUaGUNCj4+IHNl cnZlciB3aWxsIHJlc3BvbmQgYSAyMDQgTm8gQ29udGVudCBSZXNwb25zZSAob3IgMjAxIENyZWF0 ZWQgUmVzcG9uc2UpIGFuZA0KPj4gdGhlbiB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24uDQo+PiA+ DQo+PiA+NC4gSSBvcGVuIGEgZmlsZSBhbmQgZnJlcXVlbnRseSBlZGl0IGFuZCBzYXZlIGl0IChh Y3R1YWxseSB0aGlzIGlzIHdoYXQgSQ0KPj4gdXN1YWxseSBkbyB3aXRoIHRoZSBEcm9wYm94KS4g VGhlIGNsaWVudCB3aWxsIHNlbmQgdGhlIHdob2xlIGZpbGUgdG8gdGhlDQo+PiBzZXJ2ZXIgZXZl cnkgdGltZSBJIHNhdmUgdGhlIGZpbGUuDQo+PiA+DQo+PiA+VG8gc3VtbWFyaXplLCBpdCBzZWVt cyB0aGF0IHRoZSBvd25DbG91ZCBtYWtlcyBoZWF2aWx5IHVzZSBvZiBQUk9QRklORCB0bw0KPj4g YWNoaWV2ZSB0aGUgc3luYyBwcm9jZXNzLiBFYWNoIHN5bmMgb3BlcmF0aW9uIChlLmcuIHVwbG9h ZCwgbW9kaWZ5IGFuZA0KPj4gZXRjLikgd2lsbCBzdGFydCB3aXRoIHNlbmRpbmcgb25lIG9yIG1v cmUgUFJPUEZJTkRzLiBBbmQgY3VycmVudGx5LCBpZiBJDQo+PiBhZGQgYSBmaWxlIHRvIHRoZSBz ZXJ2ZXIgKGRpcmVjdGx5IGZyb20gdGhlIHNlcnZlciBzaWRlIHZpYSB3ZWIgaW50ZXJmYWNlKSwN Cj4+IHRoZSBjbGllbnQgY2Fubm90IGZpbmQgdGhlIGNoYW5nZS4gSSBuZWVkIHRvIGludGVycnVw dCB0aGUgc3luYyBhbmQgcmVjb3Zlcg0KPj4gaXQgdG8gbWFrZSB0aGUgY2xpZW50IGJlIGF3YXJl IG9mIHRoZSBjaGFuZ2UgYW5kIGRvd25sb2FkIHRoZSBuZXdseSBhZGRlZA0KPj4gZmlsZS4gSSdt IG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBpcyBjYXVzZWQgYnkgdGhlIHN5bmMgbWVjaGFuaXNtIG9y IGFuDQo+PiBpbXByb3BlciBzZXJ2ZXIgY29uZmlndXJhdGlvbi4gSSBuZWVkIHRvIGludmVzdGln YXRlIHRoaXMgZnVydGhlciBhbmQgYWxzbw0KPj4gaG93IHRoZSBvd25DbG91ZCB3b3JrcyBmb3Ig bXVsdGlwbGUgY2xpZW50cyAob3IgZGV2aWNlcykuDQo+PiA+DQo+PiA+Rm9yIElTUywgSSB0aGlu ayBvd25DbG91ZCBoYXMgZGVtb25zdHJhdGVkIHRvIHNvbWUgZXh0ZW50IHRoYXQgc2ltaWxhcg0K Pj4gSUVURiBwcm90b2NvbHMgY291bGQgYmUgZGVwbG95ZWQgYW5kIGVtcGxveWVkLiBUaGUgaW50 ZW50aW9uIG9mIHRoaXMNCj4+IG1lc3NhZ2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJlbnQg c3RhdGUgb2YgdXNpbmcgV2ViREFWIGZvciBzeW5jDQo+PiBwdXJwb3NlcyB0byBzZWUgd2hhdCBu ZWVkcyB0byBiZSBpbXByb3ZlZCBoZXJlIGFuZCB3aGV0aGVyIHdlIG5lZWQgbmV3DQo+PiBwcm90 b2NvbHMuDQo+PiA+DQo+PiA+Q29tbWVudHMgYXJlIHdlbGNvbWUgOiApDQo+PiA+DQo+PiA+UmVn YXJkcywNCj4+ID5MaW5odWkNCj4+ID4NCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPlN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0K Pj4gPlN0b3JhZ2VzeW5jQGlldGYub3JnPG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZz4NCj4+ ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+PiA+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+PiBTdG9yYWdlc3luY0BpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPj4NCj4= From nobody Wed Nov 25 23:29: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 23EBB1A1BF8 for ; Wed, 25 Nov 2015 23:29:48 -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 wLEgufBNUWr2 for ; Wed, 25 Nov 2015 23:29:42 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0669.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::669]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E70F1B2A7D for ; Wed, 25 Nov 2015 23:29:41 -0800 (PST) Received: from AM3PR06CA051.eurprd06.prod.outlook.com (10.141.192.169) by DB5PR06MB1416.eurprd06.prod.outlook.com (10.163.103.22) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 26 Nov 2015 07:29:20 +0000 Received: from DB3FFO11FD056.protection.gbl (2a01:111:f400:7e04::195) by AM3PR06CA051.outlook.office365.com (2a01:111:e400:882b::41) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 26 Nov 2015 07:29:20 +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 DB3FFO11FD056.mail.protection.outlook.com (10.47.217.128) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Thu, 26 Nov 2015 07:29:20 +0000 Received: from cernfe01.cern.ch (188.184.36.42) by cernmxgwlb4.cern.ch (188.184.36.50) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Nov 2015 08:29:18 +0100 Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE01.cern.ch ([fe80::885b:f831:a970:75e1%13]) with mapi id 14.03.0174.001; Thu, 26 Nov 2015 08:29:18 +0100 From: Jakub Moscicki To: Linhui Sun Thread-Topic: [Storagesync] Some preliminary investigations on ownCloud Thread-Index: AQHRJ/vKifQcOZIR00eK6XsP2b71eZ6t148A Date: Thu, 26 Nov 2015 07:29:17 +0000 Message-ID: <03A07C3E-9B3B-4886-9131-2CAF0A7B3F85@cern.ch> References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [191.242.168.97] Content-Type: multipart/alternative; boundary="_000_03A07C3E9B3B488691312CAF0A7B3F85cernch_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD056; 1:RogARR9MqF4a2JuwMGhtx6Cno17HyFVwP5SQ52Ge4ZEQodGVGN1UC0HqtBeIsKUgLoZ8yDHzCQSuxJLNoMgtSrooVB9WLkLrZ7QtcscqjqFqEchaNN2yWEpjWaedHMCXttUh8f8jkQey5WGh7Q1P0RDM1tmLMM30F8rpuZTZwnlPnh7jtJj7aBUChe8ATxpo8QFV/3CdXuzfT/WkcV0POfNfdFvHQ30xxiwLDg2v1bNgrLe6/86lODZ2ETxw/Yko7HQiOlWW6+GbsUENMrHxHv++GbeP1aLkE5LGYUiSU51kH352SIcmBUMT2RiLjbIZaRWcpH9OaqXNQodc+DEbN51WkpXzAVIVg+mTF+lFDRs7KYC738oatArqRIZZbu7x0txuEWUiTFJ10EsQh1VoAJ9TcAUG7QCGdmB2xdqKvlY= X-Forefront-Antispam-Report: CIP:188.184.36.50; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(3000300001)(438002)(189002)(199003)(377424004)(24454002)(53754006)(1220700001)(16236675004)(19580405001)(11100500001)(53416004)(189998001)(84326002)(33656002)(106466001)(5001970100001)(93886004)(74482002)(4001150100001)(50986999)(5004730100002)(512874002)(1096002)(76176999)(66066001)(106116001)(92566002)(19580395003)(3846002)(16297215004)(6806005)(87936001)(5003600100002)(19617315012)(110136002)(102836003)(6116002)(586003)(83716003)(16796002)(2900100001)(2950100001)(86362001)(54356999)(36756003)(15975445007)(26826002)(82746002)(5250100002)(300700001)(5008740100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB1416; H:CERNMX11.cern.ch; FPR:; SPF:Pass; PTR:cernmx11.cern.ch; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1416; 2:kZBxkuEOTqYkaf4qMrRUV/UzTxMNESUh+flY5+DsFqckmRdk1rHnZpoY+zz6A0qgT3T4ezI92LBeHLvDQV9OlDnnIoZnzcP9HEkT3m3//2V7ShvhJN9P18VeYkRmeK0LuX2iZKahwzYkDKG1iiGTHw==; 3:+5EqIz92jeg/6VTsS3BJndOjt5yZizQWy5NrXXoRSVczlhMKXKLxrJEDSQqAPbm9Xj04+UmQ/CVNFPUayC7ef0xpIL3DTIjvKl5GcEHS6pXVD9KaUQ5d8Vu8gfAT+nad7wSvC+2wBySqU0685y8OdFopTQGlK9l6CV0ngOrW5/5368Ho6Cd58sew4xS9TSShvZy43T2Vq83r18BjgolDdkdqNmsI1P9OHB9iAWibKJGXWf88sf44htNq0kX7hmTRHg4rjtZGK5cPlvFSoheTrg==; 25:TdJtWCTHwJSWdMDCzV2d/+HDfbc/k6YyOmFr8H47TuR1VnO3V3Tf0TifPqC9+LvSd0+WdR9xkMGsl97UMUDmMbm3YecFpdQTBpFvbsVBD/7PubkaK9qZy/qYGJ+85hKZnhJTidK6t4Ycl3tyKNSQ9SD9lBcA69N7ah8wD8BGE90bWJYeQ5psF234uGIq+iO+oODTUo1LV7q4LykUyzv0TjDHBQIbesVOK85peYd48WpfRVdUWRYZGkh4JKZw5f5/54g9/3KCYZct8fZVk/MOnw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DB5PR06MB1416; X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1416; 20:FCddSNzrzZdrzdrFgg6jgvWO82t5ajSCjMFBrB5HvO9tZWH9fICYi/WvdjgwHlpCIx+R6Mmi/qRhgbjueOe6riCxf5Bj7MkLHc/arR1To6EJQY2ZXyp8I7DK1O4k2Ec5SJx3Hw8XceLEPBSTdSOm9KeXGKkmb6esZEi5CVfYmUQ1Hup1gh7WsTr2vVS+wxH5wEol807pQpEddH7SXHYgQef3A7vPnsYa+l+giHGvBSjFUYbR0bAy64zx2Xi5v+xNoRnEJHQJFQ4+hE+6hroK5uAjAluZjZlRlgnM6FpT72UK/olgqYKFJag6qvhvw9PWbmvRb6i2NYWizsEQWFbo42e3aMJqHL8nvliacrrENy6wJIwGogvr1yz7mBbRFX+GNmBA7OZiFnLpvhctePXtZHRO0u/waDFfNsYtW/JhLu+ATgUIu0sRAnAxqAWEONVpHPl12fMzrAUzrF7f879lS2K/lyaZfrNU6ju+allY186zpR9pk11rqgO98/sUN0tR; 4:gpsIXT44M407zWe/Oc+69GNVexIwS8Zu3lQD0jJ4HVuKCBOtuy4wMkPa7lCbKUCQ6h+eZnzRlQjTkzgyq+bL+ICet7p0mjONUtrESkZUGS40jgJfHWWKKevEK+UTnRpr17u7pqgaKweII1PDa9cqvcnSL5zGbZPNTwgasJ/oVnxolC+uLqFNXtsd4N8q2qZovS1P6Yc4diUogn2AYvO2o3smBrFWkgNPqKZctCrM68elT/D38HT6Js/j9lBAA2slF5Ev3bh66TSvSU/W1RSK4oZ+VZGCy4AbOMCSs+8T60FoFveWcUjP4/5hebRTf/uAa6lP2+I3cHXTV9nhyMWrXckkxXFkqAzGYr+fg5GJpj3ncPyNx4HxIDmRWdnQWRysidOM9vrCk0pZ+52qruoAfSDFNna1ANt+/glJi2Z0Is6D4/i7Jr2dGXbJZZ7DcE3S 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)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR06MB1416; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB1416; X-Forefront-PRVS: 0772E5DAD5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5PR06MB1416; 23:/tZLRsQ/KtfMBuqSyUv/KhY2nH5jj1OrsmaiJouqJ?= =?us-ascii?Q?01oFCtEj4E7cfnnpGO19E2njila/Zbj8d5FW0WQjYgtbzoPBTmw0zsDCf/OS?= =?us-ascii?Q?l4xXYWcE/62/jt0b2oUzfGHYJ8iXlXMTwXYyAJ3HCYsXZ7goCz6T5TlWOwiI?= =?us-ascii?Q?odRvuQYobsWJsHBVciJ7XHpcsgqSiHP60iz5UDm7XXHCM7rf8ypQhRCQcGp/?= =?us-ascii?Q?qDPJbuyTyPuFCeGTvQWhZDcZ4QEA6iQdVhqenSABkKfUR+dPhReK/Z8BCLWJ?= =?us-ascii?Q?bjdRuNykya3fqe3/BeXCU6G3SIKmfOeAJ5AWzKtMAQ8rIyvnY9W1+rdP54ro?= =?us-ascii?Q?tNWSY0FRsGRtqwfxPBVzDYG++Yx6qlXkA1TZbSPTlT2CycYhQyrL/QcfDJXF?= =?us-ascii?Q?6ZG4ww958izNm9QzmpROV/voDVUCoa4i0fGr5x2bNAmcvU75DMXjBtK9f6EZ?= =?us-ascii?Q?ZvD5+c7/OaW2Ok70SKtOi/MYbIAjH3b2wwNp1RAw9WdXVrH1+vXLqQblyUgJ?= =?us-ascii?Q?lff5tiizS3UXr7t3JE3nEJwOdiyw3DywasvdXnrVJshUw4nmxqWLsSmTWhPM?= =?us-ascii?Q?buAAUse4Izvl6u7fJLfIysnI7E3N85oUPDAZt+u5BOBWSTS+WNHV48BFBWDL?= =?us-ascii?Q?Vgr3BFaDlVdb15fd5glzSHTBbhW6NU0bgJqBtoJig4qL/C5CVEQVCDatTaVW?= =?us-ascii?Q?+Fd4/BmHimNM/sgXs4bgczXdN4iXlWhe6z3KXtWkszRyO4tTS9YOr4/qKie0?= =?us-ascii?Q?9S7qdAAhI9sYqSDZt3UwT8lXVnqJCA5YsicDBavHQ4fBjL8AP21nXs3o1IlE?= =?us-ascii?Q?fWTYmoPyvyGrY0ThSmg566fsLZMxwk3PxJJJkrN6e9RGjMaf+G5TPrtnAgDS?= =?us-ascii?Q?aJyp6vcIDim1DG3d4pnZQ75TY17lFlMZYLsoXfvo/LfHAC9/4xztN8Ziu3u7?= =?us-ascii?Q?Jm/oUetww16YDqdljLBvtm0PkM+mfPK0UUCMkVvwcE61ZtlltO2C7Y4IrKFC?= =?us-ascii?Q?5E4hEpF2M6Q8cN8hL+3ogeg2Zae9E4djy40GHIa1+ZrVsDmDDkx7HxarPC67?= =?us-ascii?Q?4e+pQ1MIolXkJ7prch3qPFqgS0cxqgMTZ9Cr9l4ZP9V93RGA1WQBCJjo6Oig?= =?us-ascii?Q?L40EYUOTUikeROWcxUurxL5GlxpSJ176YtNeI4EATwKSQLrGNoha7Xai5Jzc?= =?us-ascii?Q?GJu4xuss0ai3piaIp/QlfRYA26epnxX+cOwYQYK/4gu+V5dAUhiHLo0V0Kn3?= =?us-ascii?Q?lhAOw+LuTIfYZVmDs73dR4kO6CqMFzSgTDK2k/FI4kD43MM9cqSrc+ghOqfv?= =?us-ascii?Q?axBq0CzVYzpOpEmXDV3B1PdaoIixcReDaFZlPPN3P0ShqjvE5MLAgIbUnKlm?= =?us-ascii?Q?lYlMVeNjBLwhwL9zuvyPwsZSalbn8vcegOgvhJVZuNRthyu?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1416; 5:kG9XRfgUKRcvocnoSAyrpLpJbIEcsP/SF+QSrn6xvavDOMrEAEjNVwodZirqW1+u5OKfkkIc8+5OfXNgAFCgTgPtsqP+wH7O7ftBgDFDaHuG87m5Fb3YVCJBou6iZeLhtFMFQDDZ7rav1YoSPKbr1A==; 24:cds0gQ4U5dBRBvpvWQF0nqWp5zRpEuIJhbWGNR3RlStn6tS0XBz8/HdDMBvWQhQJIKQv0M7WW7aKc69vbrf+7QPoa/rKz5LdtgGvT9x72Pk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Nov 2015 07:29:20.3051 (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: DB5PR06MB1416 Archived-At: Cc: fsong , 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: Thu, 26 Nov 2015 07:29:48 -0000 --_000_03A07C3E9B3B488691312CAF0A7B3F85cernch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MjAxNS0xMS0yNiAxMToyOCBHTVQrMDg6MDAgRmVpIFNvbmcgPGZzb25nQGJqdHUuZWR1LmNuPG1h aWx0bzpmc29uZ0BianR1LmVkdS5jbj4+Og0KQlRXLCBCYXNlZCBvbiB0aGUgbGFzdCBzZW50ZW5j ZSBvZiBsYXN0IGVtYWlsOiJUaGUgaW50ZW50aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyB0byBpbnZl c3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMgcHVycG9z ZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQgaGVyZSBhbmQgd2hldGhlciB3ZSBu ZWVkIG5ldyBwcm90b2NvbHMiDQoNClRoZSBvdXRjb21lIGhlL3NoZSB3YW50ZWQgbWlnaHQgYmUg anVzdCB0aGUgbGlua3MgbGlrZSBodHRwOi8vY3MzLmV0aHouY2gvcHJvZ3JhbS5odG1sIDopDQpJ biBhbm90aGVyIHdvcmQsIEkgdGhpbmsgd2hhdCBJIHdhbnQgZmluYWxseSBtaWdodCBiZSBhIGRp c2N1c3Npb24gYWJvdXQgIldoYXQgaXMgbmVlZGVkIGZvciB0aGUgSVNTOiBhIHN5bmMgcHJvdG9j b2wgb3IgYSBnZW5lcmFsaXplZCBBUEkiLiBTb3JyeSBmb3IgdGhlIHBvb3IgZXhwcmVzc2lvbiA6 ICkNCg0KSSB0aGluayB0aGlzIGlzIGEgcmVsZXZhbnQgcXVlc3Rpb24gaW5kZWVkICh3ZWxsLCBh Y3R1YWxseSBhbHNvIGlmIHRoZXJlIGlzIGFueSBzdGFuZGFyZCBuZWVkZWQgYXQgYWxsIGluIHRo ZSBmaXJzdCBwbGFjZSkuIEJ5IHRoZSBnZW5lcmFsaXplZCBBUEkgZG8geW91IG1lYW4gYSBIVFRQ LXN0eWxlIEFQSSAobGlrZSBSRVNUKT8gSW4gdGhhdCBjYXNlIHlvdSBtYXkgY29uc2lkZXIgV2Vi REFWIHF1aXRlIGNsb3NlIGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBwcm90b2NvbCBh bmQgdGhlIEFQSSBibHVycyBmb3IgcHJhY3RpY2FsIHB1cnBvc2VzLg0KDQpXaGlsZSBJIGFncmVl IHRoYXQgV2ViREFWIG1heSBoYXZlIGRpc2FkdmFudGFnZXMgdGhlcmUgaXMgYSBnb29kIG51bWJl ciBvZiBpbnN0YWxsYXRpb25zIHVzaW5nIHRoaXMgYWxyZWFkeSBpbiBvdXIgY29tbXVuaXR5IChy ZXNlYXJjaCBsYWJzIG1haW5seSBpbiwgYnV0IG5vdCBsaW1pdGVkIHRvLCBFdXJvcGUpLiBJIHRo aW5rIHRoZSBpbnRlcmVzdGluZyBwb2ludCBhYm91dCBXZWJEQVYvSFRUUCBpcyBleHRlbnNpYmls aXR5IGFuZCBtYXliZSBpdCBpcyB3b3J0aCBpcyB0aGF0IHRoZXNlIGV4dGVuc2lvbnMgZ28gYnkg YSDigJxzdGFuZGFyZOKAnS4gSG93ZXZlciwgeW91IHNob3VsZCBjb25zaWRlciB0aGF0IGZvciBy ZWFzb25hYmx5IGVmZmljaWVudCBzeW5jIHNjZW5hcmlvIHRoZSBzZXJ2ZXIgc2hvdWxkIGFsc28g ZXhoaWJpdCBjZXJ0YWluIGJlaGF2aW91ci4gVGhhdCBpcywgaW4gY2FzZSBvZiBvd25jbG91ZCBm b3IgZXhhbXBsZSwgYSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gZWZmaWNpZW50bHkgcHJvcGFn YXRlIHRoZSBFVEFHIGNoYW5nZXMgdXAgdGhlIGRpcmVjdG9yeSB0cmVlIChsaWtlIHRoZSBNZXJr bGUgVHJlZSkgc28gdGhhdCB0aGUgY2xpZW50IG1heSB1c2UgcHJvcGZpbmQgZWZmaWNpZW50bHku IFRoaXMgaXMgbm90IGEgaGFyZCBzcGVjIHJlcXVpcmVtZW50IGJ1dCBvdGhlcndpc2UgcHJvcGZp bmRpbmcgdGhlIGVudGlyZSByZW1vdGUgdHJlZSBlYWNoIHRpbWUgd291bGQgYmUgaW1wcmFjdGlj YWxseSBpbmVmZmljaWVudC4gU28gdGhpcyByZWFsbHkgZ29lcyBhIGxpdHRsZSBiaXQgYmV5b25k IGp1c3QgYW4gQVBJLg0KDQpZb3Ugc2hvdWxkIGFsc28gY29uc2lkZXIgdGhhdCB0aGUgT3BlbkNs b3VkTWVzaCAodW5kZXIgR0VBTlQgdW1icmVsbGEpIGlzIGFuIGluaXRpYXRpdmUgd2l0aCB0aGUg aW50ZW50IGlzIHRvIG1ha2UgY3Jvc3Mtc2VydmljZSBzaGFyaW5nIHZlcnkgZWFzeS4gVGhlc2Ug c2hhcmVzIG1heSBhbHNvIGJlIHN5bmNocm9uaXplZCBhdXRvbWF0aWNhbGx5LiBJIGN1cnJlbnRs eSBoYXZlIG5vIGV2aWRlbmNlLCBob3dldmVyLCB0aGF0IG90aGVyIHNvZnR3YXJlIHByb3ZpZGVy cyB3aXRoIHRoZSBleGNlcHRpb24gb2Ygb3duY2xvdWQgYXJlIGludGVyZXN0ZWQgaW4gZGV2ZWxv cGluZyBzdWNoIHN0YW5kYXJkLiBJZiB0aGVyZSBpcyBubyBib3R0b20gdXAgaW50ZXJlc3QgZnJv bSB0aGUgdXNlcnMgdGhlbiBpdCB3b27igJl0IGhhcHBlbiAoaW4gbXkgb3BpbmlvbikuDQoNCldp dGggdGhlIGxpbmsgSSB3YW50ZWQgdG8gcG9pbnQgeW91IHRvIHRoZSBmYWN0IHRoYXQgd2hhdCB5 b3UgZGlzY3VzcyBpbiB0aGlzIG1haWxpbmcgbGlzdCB3aWxsIGJlIGFsc28gZGlzY3Vzc2VkIGF0 IHRoZSB1cGNvbWluZyBDUzMgZXZlbnQgSSBsaW5rZWQgaW4uIFRoZSBpbnRlbnQgaXMgdG8gZG8g dGhpcyBkaXNjdXNzaW5nIHRvZ2V0aGVyIGJldHdlZW4gc2VydmljZSBwcm92aWRlcnMsIGRldmVs b3BlcnMgYW5kIHJlc2VhcmNoZXJzIHRvZ2V0aGVyIOKAlCBzbyB0aGF0IGl0IGRvZXMgbm90IG9u bHkgZW5kIHVwIGFzIGFuIGFjYWRlbWljIGV4ZXJjaXNlIGJ1dCBiYWNrZWQgdXAgYnkgYSBjcml0 aWNhbCBtYXNzIGlmIHRoZXJlIGlzIHNvbWUgcG90ZW50aWFsIGluIHN0YW5kYXJkaXNhdGlvbiwg YXQgbGVhc3QgaW4gb3VyIGNvbW11bml0eS4gSSBob3BlIHRoaXMgY291bGQgYmUgb2YgaW50ZXJl c3QgdG8gSUVURiBjb21tdW5pdHksIGFzIG1lbnRpb25lZCBvbiB0aGUgcHJvZ3JhbSBwYWdlLg0K DQpTZWxlY3RlZCBwYXBlcnMgd2lsbCBiZSBwdWJsaXNoZWQgaW4gRkdDUyBhZnRlciB0aGUgZXZl bnQsIHNvIHBsZWFzZSBzdGFuZCBieSwgb3IgYXR0ZW5kIHRoZSBldmVudCBpZiB5b3Ugd2FudCB0 byBiZSBwYXJ0IG9mIHRoaXMgZGlzY3Vzc2lvbiBoZXJlLiBCVFcuIHRoZSBhYnN0cmFjdCBzdWJt aXNzaW9uIGRlYWRsaW5lIGlzIHBhc3QgYnV0IG9uZSBleGNlcHRpb25hbGx5IGdvb2QgY29udHJp YnV0aW9uIGNvdWxkIHN0aWxsIHBvc3NpYmx5IGJlIGFjY29tbW9kYXRlZCBpZiBzdWJtaXR0ZWQg cmFwaWRseS4NCg0KSSB3b3VsZCBiZSBub25ldGhlbGVzcyBoYXBweSB0byBjb250aW51ZSBjb250 cmlidXRpbmcgdG8gdGhlIGRpc2N1c3Npb24gaW4gdGhpcyBtYWlsaW5nIGxpc3QuDQoNCkJlc3Qg cmVnYXJkcywNCg0KSmFrdWIgTW9zY2lja2kNCg0KLS0NCg0KDQpSZWdhcmRzLA0KTGluaHVpDQoN Cg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+SGVsbG8sDQo+DQo+V2hhdCBraW5kIG9mIG91 dGNvbWUgYXJlIHlvdSBsb29raW5nIGZvciB3aXRoIHRoaXMgYW5hbHlzaXM/IFNvbWUgcmVzZWFy Y2ggaW4gdGhpcyBhcmVhIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBvciBpcyBiZWluZyBkb25lIGFz IHdlIHNwZWFrDQo+DQo+ZS5nLiAiQSBzdHVkeSBvZiBkZWx0YS1zeW5jIGFuZCBvdGhlciBvcHRp bWlzYXRpb24gaW4gSFRUUC9XZWJkYXYgc3luY2hvbmlzYXRpb24gcHJvdG9jb2xzIg0KPg0KPnNl ZSAiVGVjaG5vbG9neSBhbmQgUmVzZWFyY2giOg0KPg0KPmh0dHA6Ly9jczMuZXRoei5jaC9wcm9n cmFtLmh0bWwNCj4NCj5JdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBzZWUgaWYgdGhlcmUgaXMg YSBwb3RlbnRpYWwgZm9yIGNvbGxhYm9yYXRpb24uIE9yIG1heWJlIHdlIGFscmVhZHkgaGF2ZSBz b21lIGluZm9ybWF0aW9uIHlvdSBhcmUgbG9va2luZyBmb3IuDQo+DQo+QmVzdCByZWdhcmRzLA0K Pg0KPkpha3ViIE1vc2NpY2tpDQo+DQo+4oCUDQo+DQo+DQo+T24gMjUgTm92IDIwMTUsIGF0IDEx OjQ1LCBMaW5odWkgU3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbTxtYWlsdG86bGguc3VubGluaEBn bWFpbC5jb20+PG1haWx0bzpsaC5zdW5saW5oQGdtYWlsLmNvbTxtYWlsdG86bGguc3VubGluaEBn bWFpbC5jb20+Pj4gd3JvdGU6DQo+DQo+SGkgYWxsLA0KPg0KPkFzIEkgbWVudGlvbmVkIGJlZm9y ZSwgSSB0aGluayB0aGUgZGV2ZWxvcGVycyBjb3VsZCBiZW5lZml0IGZyb20gdGhlIElFVEYgc3Rh bmRhcmRzLiBUaGUgb3duQ2xvdWQgKGh0dHBzOi8vb3duY2xvdWQub3JnLykgaXMganVzdCBhbiBl eGFtcGxlLiBJdCBpcyBkZXZlbG9wZWQgZm9yIHRob3NlIHdobyBkbyBub3QgdHJ1c3QgY29tbWVy Y2lhbCBzdG9yYWdlIHNlcnZpY2VzIGFuZCB3YW50IHRvIGJ1aWxkIHRoZWlyIG93biBuZXR3b3Jr LWJhc2VkIHN0b3JhZ2Ugc2VydmljZXMuIFRoZSBvd25DbG91ZCBpcyB1c2luZyBXZWJEQVYgKFJG QzQ5MTgpIHRvIGFjaGlldmUgdGhlIGRhdGEgc3luYy4gSU1PLCB0aGUgV2ViREFWIGlzIGRlc2ln bmVkIGZvciBkaXN0cmlidXRlZCB3b3JrIGJ1dCBub3QgZm9yIHRoZSBzeW5jLiBUaHVzLCBJIG1h ZGUgc29tZSBwcmVsaW1pbmFyeSBpbnZlc3RpZ2F0aW9ucyBvbiBob3cgdGhlIG93bkNsb3VkIHVz ZXMgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzLiBBIGJyaWVmIHN1bW1hcnkgb2Ygd2hhdCBJJ3Zl IGZvdW5kIGlzIGluIHRoZSBmb2xsb3dpbmcsIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jv bmcuDQo+DQo+SSBpbnN0YWxsZWQgdGhlIG93bkNsb3VkIHNlcnZlciAodjguMi4xKSBvbiB0aGUg Q2VudE9TNywgYW5kIHRoZSBjbGllbnQgaXMgYSBkZXNrdG9wIGNsaWVudCBvbiBXaW5kb3dzLg0K Pg0KPjEuIFRvIGZpbmQgd2hldGhlciB0aGVyZSBpcyBhIGNoYW5nZSB0byB0aGUgc3luY2VkIGRp cmVjdG9yeSwgdGhlIGNsaWVudCBjb250aW51b3VzbHkgc2VuZHMgUFJPUEZJTkQgdG8gdGhlIHNl cnZlciBhdCByZWd1bGFyIGludGVydmFscyAoYXJvdW5kIDM0IHNlY29uZHMgdW5kZXIgbXkgb2Jz ZXJ2YXRpb24pLiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwNyBNdWx0aS1TdGF0dXMgUmVz cG9uc2UgdG8gdGVsbCB3aGV0aGVyIHRoZSBtYWluIGRpcmVjdG9yeSBoYXMgYmVlbiBjaGFuZ2Vk LiBUbyBwZXJmb3JtIHRoaXMgcmVndWxhciBjaGVjaywgdGhlIGNsaWVudCB3aWxsIG9wZW4gYSBu ZXcgVENQIGNvbm5lY3Rpb24gdG8gc2VuZCB0aGUgUFJPUEZJTkQsIHRoZSBzZXJ2ZXIgd2lsbCBj bG9zZSB0aGUgZXhpc3RpbmcgVENQIGNvbm5lY3Rpb24gYWZ0ZXIgcmVzcG9uZGluZyB0aGUgMjA3 IE11bHRpLVN0YXR1cyBSZXNwb25zZS4gRm9yIHRoZSBuZXh0IGNoZWNrLCB0aGUgY2xpZW50IHdp bGwgb3BlbiBhbm90aGVyIG5ldyBUQ1AgY29ubmVjdGlvbi4NCj4NCj4yLiBFdmVyeSB0aW1lIGFk ZGluZyAob3IgY3JlYXRpbmcpIGEgbmV3IGZpbGUgdG8gdGhlIGxvY2FsIGZvbGRlciwgdGhlIGNs aWVudCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gKGlmIHRoZXJlIGlzIG5vIGNvbm5l Y3Rpb24gZXhpc3RpbmcpIHRvIHNlbmQgdGhlIGZpbGUgYXNhcC4gVGhlIGNsaWVudCB3aWxsIGZp cnN0IHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZCBvdXQgd2hpY2ggc3ViLWRpcmVjdG9y eSBoYXMgYmVlbiBjaGFuZ2VkLiBBbmQgdGhlbiBpdCBzZW5kcyB0aGUgZmlsZSB1c2luZyBQVVQu IFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjAxIENyZWF0ZWQgUmVzcG9uc2UgYW5kIHRoZW4g dGVybWluYXRlIHRoZSBjb25uZWN0aW9uLiBDdXJyZW50bHksIEkgaGF2ZW4ndCBmb3VuZCBhbnkg YXBwbGljYXRpb24gbGF5ZXIgY2h1bmtpbmcsIGFsbCB0aGUgc2VnbWVudGF0aW9uIGFyZSBwZXJm b3JtZWQgYnkgVENQLg0KPg0KPjMuIEV2ZXJ5IHRpbWUgSSBkZWxldGUgKG9yIHJlbmFtZSkgYSBm aWxlIGxvY2FsbHksIHRoZSBjbGllbnQgd2lsbCBhbHNvIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rp b24gdG8gc2VuZCBzZXZlcmFsIFBST1BGSU5EcyB0byBmaW5kIG91dCB3aGljaCBmaWxlIGhhcyBi ZWVuIHJlbW92ZWQgKG9yIHJlbmFtZWQpLiBUaGVuIGl0IHdpbGwgc2VuZCBERUxFVEUgKG9yIE1P VkUpLiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwNCBObyBDb250ZW50IFJlc3BvbnNlIChv ciAyMDEgQ3JlYXRlZCBSZXNwb25zZSkgYW5kIHRoZW4gdGVybWluYXRlIHRoZSBjb25uZWN0aW9u Lg0KPg0KPjQuIEkgb3BlbiBhIGZpbGUgYW5kIGZyZXF1ZW50bHkgZWRpdCBhbmQgc2F2ZSBpdCAo YWN0dWFsbHkgdGhpcyBpcyB3aGF0IEkgdXN1YWxseSBkbyB3aXRoIHRoZSBEcm9wYm94KS4gVGhl IGNsaWVudCB3aWxsIHNlbmQgdGhlIHdob2xlIGZpbGUgdG8gdGhlIHNlcnZlciBldmVyeSB0aW1l IEkgc2F2ZSB0aGUgZmlsZS4NCj4NCj5UbyBzdW1tYXJpemUsIGl0IHNlZW1zIHRoYXQgdGhlIG93 bkNsb3VkIG1ha2VzIGhlYXZpbHkgdXNlIG9mIFBST1BGSU5EIHRvIGFjaGlldmUgdGhlIHN5bmMg cHJvY2Vzcy4gRWFjaCBzeW5jIG9wZXJhdGlvbiAoZS5nLiB1cGxvYWQsIG1vZGlmeSBhbmQgZXRj Likgd2lsbCBzdGFydCB3aXRoIHNlbmRpbmcgb25lIG9yIG1vcmUgUFJPUEZJTkRzLiBBbmQgY3Vy cmVudGx5LCBpZiBJIGFkZCBhIGZpbGUgdG8gdGhlIHNlcnZlciAoZGlyZWN0bHkgZnJvbSB0aGUg c2VydmVyIHNpZGUgdmlhIHdlYiBpbnRlcmZhY2UpLCB0aGUgY2xpZW50IGNhbm5vdCBmaW5kIHRo ZSBjaGFuZ2UuIEkgbmVlZCB0byBpbnRlcnJ1cHQgdGhlIHN5bmMgYW5kIHJlY292ZXIgaXQgdG8g bWFrZSB0aGUgY2xpZW50IGJlIGF3YXJlIG9mIHRoZSBjaGFuZ2UgYW5kIGRvd25sb2FkIHRoZSBu ZXdseSBhZGRlZCBmaWxlLiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGlzIGlzIGNhdXNlZCBieSB0 aGUgc3luYyBtZWNoYW5pc20gb3IgYW4gaW1wcm9wZXIgc2VydmVyIGNvbmZpZ3VyYXRpb24uIEkg bmVlZCB0byBpbnZlc3RpZ2F0ZSB0aGlzIGZ1cnRoZXIgYW5kIGFsc28gaG93IHRoZSBvd25DbG91 ZCB3b3JrcyBmb3IgbXVsdGlwbGUgY2xpZW50cyAob3IgZGV2aWNlcykuDQo+DQo+Rm9yIElTUywg SSB0aGluayBvd25DbG91ZCBoYXMgZGVtb25zdHJhdGVkIHRvIHNvbWUgZXh0ZW50IHRoYXQgc2lt aWxhciBJRVRGIHByb3RvY29scyBjb3VsZCBiZSBkZXBsb3llZCBhbmQgZW1wbG95ZWQuIFRoZSBp bnRlbnRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHRvIGludmVzdGlnYXRlIHRoZSBjdXJyZW50IHN0 YXRlIG9mIHVzaW5nIFdlYkRBViBmb3Igc3luYyBwdXJwb3NlcyB0byBzZWUgd2hhdCBuZWVkcyB0 byBiZSBpbXByb3ZlZCBoZXJlIGFuZCB3aGV0aGVyIHdlIG5lZWQgbmV3IHByb3RvY29scy4NCj4N Cj5Db21tZW50cyBhcmUgd2VsY29tZSA6ICkNCj4NCj5SZWdhcmRzLA0KPkxpbmh1aQ0KPg0KPg0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFn ZXN5bmMgbWFpbGluZyBsaXN0DQo+U3RvcmFnZXN5bmNAaWV0Zi5vcmc8bWFpbHRvOlN0b3JhZ2Vz eW5jQGlldGYub3JnPjxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc8bWFpbHRvOlN0b3JhZ2Vz eW5jQGlldGYub3JnPj4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 b3JhZ2VzeW5jDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQpTdG9yYWdlc3luY0BpZXRmLm9yZzxtYWls dG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3N0b3JhZ2VzeW5jDQoNCg0K --_000_03A07C3E9B3B488691312CAF0A7B3F85cernch_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi PjIwMTUtMTEtMjYgMTE6MjggR01UJiM0MzswODowMCBGZWkgU29uZyA8c3BhbiBkaXI9Imx0ciIg Y2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmZzb25nQGJqdHUuZWR1LmNuIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+ZnNvbmdAYmp0dS5lZHUuY248L2E+Jmd0Ozwvc3Bhbj46PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpy Z2IoMjA0LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgi Pg0KQlRXLCBCYXNlZCBvbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiBsYXN0IGVtYWlsOiZxdW90O1Ro ZSBpbnRlbnRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHRvIGludmVzdGlnYXRlIHRoZSBjdXJyZW50 IHN0YXRlIG9mIHVzaW5nIFdlYkRBViBmb3Igc3luYyBwdXJwb3NlcyB0byBzZWUgd2hhdCBuZWVk cyB0byBiZSBpbXByb3ZlZCBoZXJlIGFuZCB3aGV0aGVyIHdlIG5lZWQgbmV3IHByb3RvY29scyZx dW90OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBvdXRjb21lIGhlL3NoZSB3YW50 ZWQgbWlnaHQgYmUganVzdCB0aGUgbGlua3MgbGlrZSA8YSBocmVmPSJodHRwOi8vY3MzLmV0aHou Y2gvcHJvZ3JhbS5odG1sIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij4NCmh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWw8L2E+IDopPGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj5JbiBhbm90aGVyIHdvcmQsIEkgdGhpbmsgd2hh dCBJIHdhbnQgZmluYWxseSBtaWdodCBiZSBhIGRpc2N1c3Npb24gYWJvdXQgJnF1b3Q7V2hhdCBp cyBuZWVkZWQgZm9yIHRoZSBJU1M6IGEgc3luYyBwcm90b2NvbCBvciBhIGdlbmVyYWxpemVkIEFQ SSZxdW90Oy4gU29ycnkgZm9yIHRoZSBwb29yIGV4cHJlc3Npb24gOiApPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQpJIHRoaW5rIHRoaXMgaXMgYSByZWxldmFudCBxdWVzdGlvbiBpbmRlZWQgKHdl bGwsIGFjdHVhbGx5IGFsc28gaWYgdGhlcmUgaXMgYW55IHN0YW5kYXJkIG5lZWRlZCBhdCBhbGwg aW4gdGhlIGZpcnN0IHBsYWNlKS4gQnkgdGhlIGdlbmVyYWxpemVkIEFQSSBkbyB5b3UgbWVhbiBh IEhUVFAtc3R5bGUgQVBJIChsaWtlIFJFU1QpPyBJbiB0aGF0IGNhc2UgeW91IG1heSBjb25zaWRl ciBXZWJEQVYgcXVpdGUgY2xvc2UgYW5kIHRoZSBkaWZmZXJlbmNlDQogYmV0d2VlbiB0aGUgcHJv dG9jb2wgYW5kIHRoZSBBUEkgYmx1cnMgZm9yIHByYWN0aWNhbCBwdXJwb3Nlcy4mbmJzcDs8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PldoaWxlIEkgYWdyZWUgdGhhdCBX ZWJEQVYgbWF5IGhhdmUgZGlzYWR2YW50YWdlcyB0aGVyZSBpcyBhIGdvb2QgbnVtYmVyIG9mIGlu c3RhbGxhdGlvbnMgdXNpbmcgdGhpcyBhbHJlYWR5IGluIG91ciBjb21tdW5pdHkgKHJlc2VhcmNo IGxhYnMgbWFpbmx5IGluLCBidXQgbm90IGxpbWl0ZWQgdG8sIEV1cm9wZSkuIEkgdGhpbmsgdGhl IGludGVyZXN0aW5nIHBvaW50IGFib3V0IFdlYkRBVi9IVFRQIGlzIGV4dGVuc2liaWxpdHkgYW5k IG1heWJlDQogaXQgaXMgd29ydGggaXMgdGhhdCB0aGVzZSBleHRlbnNpb25zIGdvIGJ5IGEg4oCc c3RhbmRhcmTigJ0uIEhvd2V2ZXIsIHlvdSBzaG91bGQgY29uc2lkZXIgdGhhdCBmb3IgcmVhc29u YWJseSBlZmZpY2llbnQgc3luYyBzY2VuYXJpbyB0aGUgc2VydmVyIHNob3VsZCBhbHNvIGV4aGli aXQgY2VydGFpbiBiZWhhdmlvdXIuIFRoYXQgaXMsIGluIGNhc2Ugb2Ygb3duY2xvdWQgZm9yIGV4 YW1wbGUsIGEgc2VydmVyIHNob3VsZCBiZSBhYmxlIHRvIGVmZmljaWVudGx5DQogcHJvcGFnYXRl IHRoZSBFVEFHIGNoYW5nZXMgdXAgdGhlIGRpcmVjdG9yeSB0cmVlIChsaWtlIHRoZSBNZXJrbGUg VHJlZSkgc28gdGhhdCB0aGUgY2xpZW50IG1heSB1c2UgcHJvcGZpbmQgZWZmaWNpZW50bHkuIFRo aXMgaXMgbm90IGEgaGFyZCBzcGVjIHJlcXVpcmVtZW50IGJ1dCBvdGhlcndpc2UgcHJvcGZpbmRp bmcgdGhlIGVudGlyZSByZW1vdGUgdHJlZSBlYWNoIHRpbWUgd291bGQgYmUgaW1wcmFjdGljYWxs eSBpbmVmZmljaWVudC4gU28gdGhpcw0KIHJlYWxseSBnb2VzIGEgbGl0dGxlIGJpdCBiZXlvbmQg anVzdCBhbiBBUEkuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+WW91IHNob3VsZCBhbHNvIGNvbnNpZGVyIHRoYXQgdGhlIE9wZW5DbG91ZE1lc2ggKHVuZGVy IEdFQU5UIHVtYnJlbGxhKSBpcyBhbiBpbml0aWF0aXZlIHdpdGggdGhlIGludGVudCBpcyB0byBt YWtlIGNyb3NzLXNlcnZpY2Ugc2hhcmluZyB2ZXJ5IGVhc3kuIFRoZXNlIHNoYXJlcyBtYXkgYWxz byBiZSBzeW5jaHJvbml6ZWQgYXV0b21hdGljYWxseS4gSSBjdXJyZW50bHkgaGF2ZSBubyBldmlk ZW5jZSwgaG93ZXZlciwgdGhhdCBvdGhlciBzb2Z0d2FyZQ0KIHByb3ZpZGVycyB3aXRoIHRoZSBl eGNlcHRpb24gb2Ygb3duY2xvdWQgYXJlIGludGVyZXN0ZWQgaW4gZGV2ZWxvcGluZyBzdWNoIHN0 YW5kYXJkLiBJZiB0aGVyZSBpcyBubyBib3R0b20gdXAgaW50ZXJlc3QgZnJvbSB0aGUgdXNlcnMg dGhlbiBpdCB3b27igJl0IGhhcHBlbiAoaW4gbXkgb3BpbmlvbikuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PldpdGggdGhlIGxpbmsgSSB3 YW50ZWQgdG8gcG9pbnQgeW91IHRvIHRoZSBmYWN0IHRoYXQgd2hhdCB5b3UgZGlzY3VzcyBpbiB0 aGlzIG1haWxpbmcgbGlzdCB3aWxsIGJlIGFsc28gZGlzY3Vzc2VkIGF0IHRoZSB1cGNvbWluZyBD UzMgZXZlbnQgSSBsaW5rZWQgaW4uIFRoZSBpbnRlbnQgaXMgdG8gZG8gdGhpcyBkaXNjdXNzaW5n IHRvZ2V0aGVyIGJldHdlZW4gc2VydmljZSBwcm92aWRlcnMsIGRldmVsb3BlcnMgYW5kIHJlc2Vh cmNoZXJzDQogdG9nZXRoZXIg4oCUIHNvIHRoYXQgaXQgZG9lcyBub3Qgb25seSBlbmQgdXAgYXMg YW4gYWNhZGVtaWMgZXhlcmNpc2UgYnV0IGJhY2tlZCB1cCBieSBhIGNyaXRpY2FsIG1hc3MgaWYg dGhlcmUgaXMgc29tZSBwb3RlbnRpYWwgaW4gc3RhbmRhcmRpc2F0aW9uLCBhdCBsZWFzdCBpbiBv dXIgY29tbXVuaXR5LiBJIGhvcGUgdGhpcyBjb3VsZCBiZSBvZiBpbnRlcmVzdCB0byBJRVRGIGNv bW11bml0eSwgYXMgbWVudGlvbmVkIG9uIHRoZSBwcm9ncmFtIHBhZ2UuPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5TZWxlY3RlZCBwYXBlcnMgd2lsbCBiZSBwdWJsaXNo ZWQgaW4gRkdDUyBhZnRlciB0aGUgZXZlbnQsIHNvIHBsZWFzZSBzdGFuZCBieSwgb3IgYXR0ZW5k IHRoZSBldmVudCBpZiB5b3Ugd2FudCB0byBiZSBwYXJ0IG9mIHRoaXMgZGlzY3Vzc2lvbiBoZXJl LiBCVFcuIHRoZSBhYnN0cmFjdCBzdWJtaXNzaW9uIGRlYWRsaW5lIGlzIHBhc3QgYnV0IG9uZSBl eGNlcHRpb25hbGx5IGdvb2QgY29udHJpYnV0aW9uIGNvdWxkIHN0aWxsIHBvc3NpYmx5DQogYmUg YWNjb21tb2RhdGVkIGlmIHN1Ym1pdHRlZCByYXBpZGx5LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+SSB3b3VsZCBiZSBub25ldGhlbGVzcyBoYXBweSB0byBjb250aW51 ZSBjb250cmlidXRpbmcgdG8gdGhlIGRpc2N1c3Npb24gaW4gdGhpcyBtYWlsaW5nIGxpc3QuPC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5KYWt1YiBNb3NjaWNraTwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+LS08YnIgY2xhc3M9IiI+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2 IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkxpbmh1aSZuYnNwOzwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0 LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpG ZWkgU29uZzxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPiZndDtIZWxsbyw8YnIgY2xhc3M9 IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0O1doYXQga2luZCBvZiBvdXRjb21lIGFyZSB5b3Ug bG9va2luZyBmb3Igd2l0aCB0aGlzIGFuYWx5c2lzPyBTb21lIHJlc2VhcmNoIGluIHRoaXMgYXJl YSBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgb3IgaXMgYmVpbmcgZG9uZSBhcyB3ZSBzcGVhazxiciBj bGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ZS5nLiAmcXVvdDtBIHN0dWR5IG9mIGRl bHRhLXN5bmMgYW5kIG90aGVyIG9wdGltaXNhdGlvbiBpbiBIVFRQL1dlYmRhdiBzeW5jaG9uaXNh dGlvbiBwcm90b2NvbHMmcXVvdDs8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 O3NlZSAmcXVvdDtUZWNobm9sb2d5IGFuZCBSZXNlYXJjaCZxdW90Ozo8YnIgY2xhc3M9IiI+DQom Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxhIGhyZWY9Imh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFt Lmh0bWwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHA6Ly9j czMuZXRoei5jaC9wcm9ncmFtLmh0bWw8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0i Ij4NCiZndDtJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBzZWUgaWYgdGhlcmUgaXMgYSBwb3Rl bnRpYWwgZm9yIGNvbGxhYm9yYXRpb24uIE9yIG1heWJlIHdlIGFscmVhZHkgaGF2ZSBzb21lIGlu Zm9ybWF0aW9uIHlvdSBhcmUgbG9va2luZyBmb3IuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFz cz0iIj4NCiZndDtCZXN0IHJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4N CiZndDtKYWt1YiBNb3NjaWNraTxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 4oCUPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQo8 L3NwYW4+PHNwYW4gY2xhc3M9IiI+Jmd0O09uIDI1IE5vdiAyMDE1LCBhdCAxMTo0NSwgTGluaHVp IFN1biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tIiBjbGFzcz0iIj5s aC5zdW5saW5oQGdtYWlsLmNvbTwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsaC5zdW5s aW5oQGdtYWlsLmNvbSIgY2xhc3M9IiI+bGguc3VubGluaEBnbWFpbC5jb208L2E+Jmd0OyZndDsg d3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDtIaSBhbGwsPGJyIGNs YXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDtBcyBJIG1lbnRpb25lZCBiZWZvcmUsIEkg dGhpbmsgdGhlIGRldmVsb3BlcnMgY291bGQgYmVuZWZpdCBmcm9tIHRoZSBJRVRGIHN0YW5kYXJk cy4gVGhlIG93bkNsb3VkICg8YSBocmVmPSJodHRwczovL293bmNsb3VkLm9yZy8iIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vb3duY2xvdWQub3JnLzwv YT4pIGlzIGp1c3QgYW4gZXhhbXBsZS4gSXQgaXMgZGV2ZWxvcGVkIGZvciB0aG9zZSB3aG8gZG8g bm90DQogdHJ1c3QgY29tbWVyY2lhbCBzdG9yYWdlIHNlcnZpY2VzIGFuZCB3YW50IHRvIGJ1aWxk IHRoZWlyIG93biBuZXR3b3JrLWJhc2VkIHN0b3JhZ2Ugc2VydmljZXMuIFRoZSBvd25DbG91ZCBp cyB1c2luZyBXZWJEQVYgKFJGQzQ5MTgpIHRvIGFjaGlldmUgdGhlIGRhdGEgc3luYy4gSU1PLCB0 aGUgV2ViREFWIGlzIGRlc2lnbmVkIGZvciBkaXN0cmlidXRlZCB3b3JrIGJ1dCBub3QgZm9yIHRo ZSBzeW5jLiBUaHVzLCBJIG1hZGUgc29tZSBwcmVsaW1pbmFyeQ0KIGludmVzdGlnYXRpb25zIG9u IGhvdyB0aGUgb3duQ2xvdWQgdXNlcyBXZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMuIEEgYnJpZWYg c3VtbWFyeSBvZiB3aGF0IEkndmUgZm91bmQgaXMgaW4gdGhlIGZvbGxvd2luZywgcGxlYXNlIGNv cnJlY3QgbWUgaWYgSSBhbSB3cm9uZy48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0O0kgaW5zdGFsbGVkIHRoZSBvd25DbG91ZCBzZXJ2ZXIgKHY4LjIuMSkgb24gdGhlIENlbnRP UzcsIGFuZCB0aGUgY2xpZW50IGlzIGEgZGVza3RvcCBjbGllbnQgb24gV2luZG93cy48YnIgY2xh c3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzEuIFRvIGZpbmQgd2hldGhlciB0aGVyZSBp cyBhIGNoYW5nZSB0byB0aGUgc3luY2VkIGRpcmVjdG9yeSwgdGhlIGNsaWVudCBjb250aW51b3Vz bHkgc2VuZHMgUFJPUEZJTkQgdG8gdGhlIHNlcnZlciBhdCByZWd1bGFyIGludGVydmFscyAoYXJv dW5kIDM0IHNlY29uZHMgdW5kZXIgbXkgb2JzZXJ2YXRpb24pLiBUaGUgc2VydmVyIHdpbGwgcmVz cG9uZCBhIDIwNyBNdWx0aS1TdGF0dXMgUmVzcG9uc2UgdG8gdGVsbCB3aGV0aGVyIHRoZSBtYWlu IGRpcmVjdG9yeQ0KIGhhcyBiZWVuIGNoYW5nZWQuIFRvIHBlcmZvcm0gdGhpcyByZWd1bGFyIGNo ZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiB0byBzZW5kIHRo ZSBQUk9QRklORCwgdGhlIHNlcnZlciB3aWxsIGNsb3NlIHRoZSBleGlzdGluZyBUQ1AgY29ubmVj dGlvbiBhZnRlciByZXNwb25kaW5nIHRoZSAyMDcgTXVsdGktU3RhdHVzIFJlc3BvbnNlLiBGb3Ig dGhlIG5leHQgY2hlY2ssIHRoZSBjbGllbnQgd2lsbCBvcGVuIGFub3RoZXINCiBuZXcgVENQIGNv bm5lY3Rpb24uPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsyLiBFdmVyeSB0 aW1lIGFkZGluZyAob3IgY3JlYXRpbmcpIGEgbmV3IGZpbGUgdG8gdGhlIGxvY2FsIGZvbGRlciwg dGhlIGNsaWVudCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gKGlmIHRoZXJlIGlzIG5v IGNvbm5lY3Rpb24gZXhpc3RpbmcpIHRvIHNlbmQgdGhlIGZpbGUgYXNhcC4gVGhlIGNsaWVudCB3 aWxsIGZpcnN0IHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmluZCBvdXQgd2hpY2ggc3ViLWRp cmVjdG9yeSBoYXMgYmVlbiBjaGFuZ2VkLg0KIEFuZCB0aGVuIGl0IHNlbmRzIHRoZSBmaWxlIHVz aW5nIFBVVC4gVGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDEgQ3JlYXRlZCBSZXNwb25zZSBh bmQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24uIEN1cnJlbnRseSwgSSBoYXZlbid0IGZv dW5kIGFueSBhcHBsaWNhdGlvbiBsYXllciBjaHVua2luZywgYWxsIHRoZSBzZWdtZW50YXRpb24g YXJlIHBlcmZvcm1lZCBieSBUQ1AuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZn dDszLiBFdmVyeSB0aW1lIEkgZGVsZXRlIChvciByZW5hbWUpIGEgZmlsZSBsb2NhbGx5LCB0aGUg Y2xpZW50IHdpbGwgYWxzbyBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIHRvIHNlbmQgc2V2ZXJh bCBQUk9QRklORHMgdG8gZmluZCBvdXQgd2hpY2ggZmlsZSBoYXMgYmVlbiByZW1vdmVkIChvciBy ZW5hbWVkKS4gVGhlbiBpdCB3aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4gVGhlIHNlcnZlciB3 aWxsIHJlc3BvbmQgYSAyMDQgTm8gQ29udGVudCBSZXNwb25zZQ0KIChvciAyMDEgQ3JlYXRlZCBS ZXNwb25zZSkgYW5kIHRoZW4gdGVybWluYXRlIHRoZSBjb25uZWN0aW9uLjxiciBjbGFzcz0iIj4N CiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7NC4gSSBvcGVuIGEgZmlsZSBhbmQgZnJlcXVlbnRseSBl ZGl0IGFuZCBzYXZlIGl0IChhY3R1YWxseSB0aGlzIGlzIHdoYXQgSSB1c3VhbGx5IGRvIHdpdGgg dGhlIERyb3Bib3gpLiBUaGUgY2xpZW50IHdpbGwgc2VuZCB0aGUgd2hvbGUgZmlsZSB0byB0aGUg c2VydmVyIGV2ZXJ5IHRpbWUgSSBzYXZlIHRoZSBmaWxlLjxiciBjbGFzcz0iIj4NCiZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7VG8gc3VtbWFyaXplLCBpdCBzZWVtcyB0aGF0IHRoZSBvd25DbG91ZCBt YWtlcyBoZWF2aWx5IHVzZSBvZiBQUk9QRklORCB0byBhY2hpZXZlIHRoZSBzeW5jIHByb2Nlc3Mu IEVhY2ggc3luYyBvcGVyYXRpb24gKGUuZy4gdXBsb2FkLCBtb2RpZnkgYW5kIGV0Yy4pIHdpbGwg c3RhcnQgd2l0aCBzZW5kaW5nIG9uZSBvciBtb3JlIFBST1BGSU5Ecy4gQW5kIGN1cnJlbnRseSwg aWYgSSBhZGQgYSBmaWxlIHRvIHRoZSBzZXJ2ZXIgKGRpcmVjdGx5IGZyb20NCiB0aGUgc2VydmVy IHNpZGUgdmlhIHdlYiBpbnRlcmZhY2UpLCB0aGUgY2xpZW50IGNhbm5vdCBmaW5kIHRoZSBjaGFu Z2UuIEkgbmVlZCB0byBpbnRlcnJ1cHQgdGhlIHN5bmMgYW5kIHJlY292ZXIgaXQgdG8gbWFrZSB0 aGUgY2xpZW50IGJlIGF3YXJlIG9mIHRoZSBjaGFuZ2UgYW5kIGRvd25sb2FkIHRoZSBuZXdseSBh ZGRlZCBmaWxlLiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGlzIGlzIGNhdXNlZCBieSB0aGUgc3lu YyBtZWNoYW5pc20gb3IgYW4NCiBpbXByb3BlciBzZXJ2ZXIgY29uZmlndXJhdGlvbi4gSSBuZWVk IHRvIGludmVzdGlnYXRlIHRoaXMgZnVydGhlciBhbmQgYWxzbyBob3cgdGhlIG93bkNsb3VkIHdv cmtzIGZvciBtdWx0aXBsZSBjbGllbnRzIChvciBkZXZpY2VzKS48YnIgY2xhc3M9IiI+DQomZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0O0ZvciBJU1MsIEkgdGhpbmsgb3duQ2xvdWQgaGFzIGRlbW9uc3Ry YXRlZCB0byBzb21lIGV4dGVudCB0aGF0IHNpbWlsYXIgSUVURiBwcm90b2NvbHMgY291bGQgYmUg ZGVwbG95ZWQgYW5kIGVtcGxveWVkLiBUaGUgaW50ZW50aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyB0 byBpbnZlc3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMg cHVycG9zZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQgaGVyZQ0KIGFuZCB3aGV0 aGVyIHdlIG5lZWQgbmV3IHByb3RvY29scy48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0O0NvbW1lbnRzIGFyZSB3ZWxjb21lIDogKTxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7UmVnYXJkcyw8YnIgY2xhc3M9IiI+DQomZ3Q7TGluaHVpPGJyIGNsYXNzPSIi Pg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQomZ3Q7U3Rv cmFnZXN5bmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPC9zcGFuPiZndDs8YSBocmVmPSJt YWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmciIGNsYXNzPSIiPlN0b3JhZ2VzeW5jQGlldGYub3Jn PC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYub3JnIiBjbGFz cz0iIj5TdG9yYWdlc3luY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMiIHJl bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmM8L2E+PGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9Img1Ij4mZ3Q7PGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpTdG9yYWdl c3luYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86U3RvcmFnZXN5 bmNAaWV0Zi5vcmciIGNsYXNzPSIiPlN0b3JhZ2VzeW5jQGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFn ZXN5bmMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmM8L2E+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_03A07C3E9B3B488691312CAF0A7B3F85cernch_-- From nobody Wed Nov 25 23:39: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 E53091B337B for ; Wed, 25 Nov 2015 23:39:52 -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 0TZ9JY5CZYMn for ; Wed, 25 Nov 2015 23:39:46 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A526A1B3321 for ; Wed, 25 Nov 2015 23:39:43 -0800 (PST) Received: from HE1PR06CA0063.eurprd06.prod.outlook.com (10.164.28.159) by AM3PR06MB402.eurprd06.prod.outlook.com (10.242.110.146) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 26 Nov 2015 07:39:26 +0000 Received: from AM1FFO11FD044.protection.gbl (2a01:111:f400:7e00::181) by HE1PR06CA0063.outlook.office365.com (2a01:111:e400:c45f::31) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 26 Nov 2015 07:39:26 +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 AM1FFO11FD044.mail.protection.outlook.com (10.174.64.233) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Thu, 26 Nov 2015 07:39:25 +0000 Received: from CERNFE25.cern.ch (137.138.203.208) by cernmxgwlb4.cern.ch (188.184.36.50) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Nov 2015 08:39:25 +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; Thu, 26 Nov 2015 08:39:24 +0100 From: Jakub Moscicki To: Linhui Sun Thread-Topic: [Storagesync] Some preliminary investigations on ownCloud Thread-Index: AQHRJ/vKifQcOZIR00eK6XsP2b71eZ6t148AgAAC1wA= Date: Thu, 26 Nov 2015 07:39:23 +0000 Message-ID: <9A7E1A04-8C4A-40BE-933D-6814ACDB135C@cern.ch> References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <03A07C3E-9B3B-4886-9131-2CAF0A7B3F85@cern.ch> In-Reply-To: <03A07C3E-9B3B-4886-9131-2CAF0A7B3F85@cern.ch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [191.242.168.97] Content-Type: multipart/alternative; boundary="_000_9A7E1A048C4A40BE933D6814ACDB135Ccernch_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD044; 1:x711Jwby0fq8hQH6TwvQjfCnXemv5MI9Uiw5cUX2CM0PM6EJ98ox3+zqQj3Jld0GM9POh0YUPgbZ5qcMinhGEqW9DkdO0MIvdpaCpaDfg3ICQTuaRrvtXcY87t6iGVBj3sNDbauEFuX6Sa8u9kwXTlwSNeBJsCpFJXD4HC3fatkELb9SsXJAo0gNLaPmpfBnKWs9Wg4yRNQAeKa5WvlKJvzwD1zhMpPscW2qG2x2wRGpZbI40hyHPqVlZOqQyfVQ+vuJZQUBkEzjapDEZhgN5qIRyatmT1uzDxhVtWZtxgHE01jY+oSmoLyHckh/V/rSzUNBP/DAq8cQoy4O4uIAEvEAg7AngeO/EJJzUKXgvWRGGrh92G7apB9+9+twgSbAv1TlLwBH2Vpq/pCLzUUsyrj5h6HnwmwhTbcANJgxhsA= X-Forefront-Antispam-Report: CIP:188.184.36.50; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(3000300001)(438002)(189002)(377424004)(24454002)(53754006)(199003)(83716003)(87936001)(93886004)(102836003)(6116002)(586003)(512874002)(84326002)(3846002)(106466001)(76176999)(74482002)(106116001)(19617315012)(92566002)(66066001)(16796002)(54356999)(53416004)(86362001)(82746002)(5250100002)(33656002)(300700001)(5003600100002)(16236675004)(4001150100001)(26826002)(189998001)(5001970100001)(110136002)(5008740100001)(15975445007)(50986999)(19580405001)(5004730100002)(11100500001)(6806005)(2900100001)(16297215004)(19580395003)(36756003)(2950100001)(1220700001)(1096002)(15188555004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR06MB402; H:CERNMX11.cern.ch; FPR:; SPF:Pass; PTR:cernmx11.cern.ch; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB402; 2:GYgs0DkwzwfEHjb8C7bFyTexktkrPmL3IH9Yp+Fk9rvhvqY1B70rWTDaozq/Oi61ORdogqPjFWDn6EPq8oHUamUPk+Hk+AWKUkVYbWby3yjxBcbggPZvRVfK/YMf1IOlUgn/FONSLXSvgdASKgdHJw==; 3:qyxU3YpIbcdv95K/Ry+mGkm8JVIHpbvyYmRmVqmqj5SThHXDV434qK1S1q59y9eLj4afJwHki2u3TThQeAWb/mKJ+OqhNHHwlObJLEgOYFHhMDqtfK4RzMo+sRAjObx3UEVWc7hgi6j3VMB8ntTNHVKk4HMFARNMwER5XTcStB6zVpQGbSXdNUKX4U6dIGBtZav/NqX+o0Jc6TVyJTzepsRBcOknlahKKeTIDmEWCWxR+ehq/aBTzNX/h4wcbV0YqiswaYq7TPodiqLoGnwOLg==; 25:gC3OHtAiZcA6ubIROnTmkBpScQtrFBs3vrO594ANFnrBg0HyhTcPAkeKBM5PJDzrB4N1qB9Cm9bg0be/jgQpZfa9iSLnJiAWfmqztJZDo2bOEfdcKX5tcZTu2fI9a0weS9+jRqiwpAPLixvRQMpt3FFYJeBmFLqzQygelbJEICq4Inyxo2poX3vACOWIZKJFDBHb/h6RTrKoKp/Ne1ik5p1J/bduXX333ex+BdfxAIGxUniBYG4jE/2YKFngBMTe+POhT5C5sNNu2v9VQfHcGw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AM3PR06MB402; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB402; 20:CELRedcLOP2F3nm38fuWgzntL6myDG2OFEzNxhgtpjvgKzL2tfGk1KmU7MgcJqLf6o8PPJrPOqug3DNZEfyWKRIG5lxXNQAxBI6Cxv0Lgx/lAGpSpezq9y5WYhB1JhlVfLqes7uT4sffHr7nbuBX9+1MRMzXxkWJI1g7Lr9dFvLJOEshSvBVY2543POe2wd9glA/g+sPiZNVtJd5n9dmzkOr4MVJxHpA8kDxZs1++R0ZxJ9hMteCTzQPnEmEm36FX+1xSa6CUBvgralLUexk12HgtTzQaYK4QcDWn4ks7XcByeUMlxZwM0iWfZX7cC2iv05MJRbmY0XBEVWxn2Qlvw0I0A24ue3d9kmOJav0IBwTVyIEf5qCQQQY6gGT0WrQAf9AfZMoOD77f0F9q8WofCrKCSqQmm0j0k996wh+m7hjBAXFyKAyKlN1yADZ7FtT0XMae9p6yZAmmEOsii/LgT1BoZHqVvHyimgkeLMFSn2kAClJZgWtGpZXXIgW09nQ; 4:9gFDLKLG07aIgn84bG56/l8wtq4Dmn+EEhPrhrS6L90U3Mh8TMa1/OK68fRwz2F+K6yIuUK3ZxH7ZJI4Q4aF+gpvCIH+aB15xTr8b7O6jRMDz0EFcl7V9eqZKiLcXtG3LBpeJ6mtZKiMa+RYfEH9hjGexC8jlOlThmOChfzWsMianeZnZp0i0QbiMgGbQQgTU18kURyFczFqfl0MzebQQNslvQjnFEGcldTNjVpUHo1qxzus6e2kdOvK92vvve6UNfIfWs1NAMD0vjt43d28HL2kTp2vRdS1Q7M1YTLqGPvB+0kVUhpzf+Q7t+1GYEs5ZG4eQWGFJPxNUox9xWZzKNNU2ac82w4rv0N5QmArg/97/ke09+rtwnQuPdQW4/Ud83wm+GcdStilxoMja4zoR3xyiWxwMpzglYWblTXngGTxJK9BOlBoc1PgAZnQEyIn 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:AM3PR06MB402; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB402; X-Forefront-PRVS: 0772E5DAD5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3PR06MB402; 23:Rv8cBtt3E5liybTmi1HuqyB4+k1GTvDTphqcHYFUPU?= =?us-ascii?Q?bxHOgH11Ziw8envCrBLudiMJKMFmAgidlpgL/CKC94ESa6Ti26jn4Sl3uD+3?= =?us-ascii?Q?RVrKqVMybJo6QlpEGlhLDQHoYGQv8cw5r2/iNsvaLzclQd0CNo80Tgd3GZkB?= =?us-ascii?Q?PnoSX+8xjwZcYrrzFyF7/giF9Mf4tooYeKR5V5eQs3itlPOXDsPO0wRl4dbn?= =?us-ascii?Q?oWPYCzuVYF3x5noi84HeWLYBKjfyu6R7wOwyMEp3KUknricvkVT5Oknyi567?= =?us-ascii?Q?P7LG90e1S512Nzc/b7S9Jc5JYoSX/ZLA1JVbarde8KRmeiJmilR89VxyyHBN?= =?us-ascii?Q?yA6Y2iBi0C3pNshFRu6pPmvvLDR3hgVD7mH9QDSkLsjdeFjBPF1aV8E/42LE?= =?us-ascii?Q?L7myYyCZq3ARIZKyL8rTAUaSiD1siEoRNESqj+1WLeoyZQKgUheCQxSGfOV7?= =?us-ascii?Q?ACkKjYazwHIo7MfJWHhF4pwMgBvt46udBF3CN731YWpuVHd9+f57/JXP7SGs?= =?us-ascii?Q?AAc9AowCYo2wWKM7WW30UERehPfmaEHXcNnSitjanuft5gAweYYKt0URdZP3?= =?us-ascii?Q?wK2u0n3XmG5TB1xzYs1S0i/0+upVHp16lSd3BRHxU8Wm0E8H6yKeZTc5MDBC?= =?us-ascii?Q?xpxmamRk6mjFTYCTH8fFlSvR0GoMwVTwpPnEc6Pr/uXmrMT7x3bnnEOCIfjd?= =?us-ascii?Q?FJyztjfNl3URpm9djFo9b6GKqesYfqs0OnpEIUjEbb7xhGcEezQzrD++o7Wl?= =?us-ascii?Q?p06FK8SW7bXQxLJlmmXL2S3k+/USj0Bj+m7B/GEQI4Q8mRSCluaoSv00RzKd?= =?us-ascii?Q?FSY4L2OJuhbNv/tlwffw1hmZg13Fs0sJ0HW3NruD81WERbeUhDwVZF1PhZY5?= =?us-ascii?Q?pEZ3KizaIEC9yj+LnjMhrO/CXdko/SMrwq4SGVAyWWPCJa3ltNF+ppbJC5zr?= =?us-ascii?Q?b9P9F7WEtjZDsZolozs/1lSnVNHMvz4WP11jcG5x1O2veJtLdZDe8uoLaHCJ?= =?us-ascii?Q?Besip9Cwei+XF0yam8Y11MmbhgNfm3jB/bngrHM6orPOk85mUYn7jbQC1S/O?= =?us-ascii?Q?L3TwtGBrukvYJbOZjh4oxCsyWh4NPECEug28MOC6W0UJkFhdZWHa2riFldBm?= =?us-ascii?Q?cymWCXwCPsGsJI7bSGiIk84WRgZKRRLHLPN/LG6Ftmmq3aNYOWOfuR8a9wnO?= =?us-ascii?Q?P+HJqmbmCNULTF7C3nb8wZkZtqzAJA+Oc5sX+1UTPo+GfPdRVVSP20bXNhJj?= =?us-ascii?Q?TCIV8k7O4pqnaMInlwHaW3NU8R3iMDhmPsaAB+8XBrn5CLq2oQlHD9EdL25J?= =?us-ascii?Q?ZqcARtHPCcPhcUfm5Kv/DT81k9D7QCvkEAP9L9uosJt4wBmcoMHaBkrRUkaz?= =?us-ascii?Q?+WyV3xZAHQLoaEo7fhT0us7uziEFxOt5XC+Q0neqFAN9xe5flS+alpTufZyS?= =?us-ascii?Q?Z7hv/h4w=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB402; 5:PL/LggWDTjDdFsMfPOsOD9cAs/b0vQsV+4Tgp5yOqUzCIXZfNilG0396D87dpHKByJuHKDDzP07mCdMZrxE4W7J6h8IjdT+tuKub8g4tDs2Q/wba1VnuwgnGYEc/MSKabnqN0hmKF7ycnS6779VuDA==; 24:Ak1/cloAXWDBoUpQkJLb70VSIHCd1yx2yU6LcjoodeZOgipHVTEFFgspaWz7hgTI9FkhdE1r7FZpWV6QZA46MSRmvVI4kLBbVAFmdN7UlDQ= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cern.ch X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Nov 2015 07:39:25.4312 (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: AM3PR06MB402 Archived-At: Cc: fsong , 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: Thu, 26 Nov 2015 07:39:53 -0000 --_000_9A7E1A048C4A40BE933D6814ACDB135Ccernch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QlRXLCBoZXJlIGlzIHRoZSBwdWJsaWMgQ0ZQIGZvciBGR0NTOiBodHRwOi8vY3MzLmV0aHouY2gv cHVibGljYXRpb25zLmh0bWwNCg0KQmVzdCByZWdhcmRzLA0KDQpKYWt1YiBNb3NjaWNraQ0KDQri gJQNCg0KT24gMjYgTm92IDIwMTUsIGF0IDA0OjI5LCBKYWt1YiBNb3NjaWNraSA8SmFrdWIuTW9z Y2lja2lAY2Vybi5jaDxtYWlsdG86SmFrdWIuTW9zY2lja2lAY2Vybi5jaD4+IHdyb3RlOg0KDQoy MDE1LTExLTI2IDExOjI4IEdNVCswODowMCBGZWkgU29uZyA8ZnNvbmdAYmp0dS5lZHUuY248bWFp bHRvOmZzb25nQGJqdHUuZWR1LmNuPj46DQpCVFcsIEJhc2VkIG9uIHRoZSBsYXN0IHNlbnRlbmNl IG9mIGxhc3QgZW1haWw6IlRoZSBpbnRlbnRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHRvIGludmVz dGlnYXRlIHRoZSBjdXJyZW50IHN0YXRlIG9mIHVzaW5nIFdlYkRBViBmb3Igc3luYyBwdXJwb3Nl cyB0byBzZWUgd2hhdCBuZWVkcyB0byBiZSBpbXByb3ZlZCBoZXJlIGFuZCB3aGV0aGVyIHdlIG5l ZWQgbmV3IHByb3RvY29scyINCg0KVGhlIG91dGNvbWUgaGUvc2hlIHdhbnRlZCBtaWdodCBiZSBq dXN0IHRoZSBsaW5rcyBsaWtlIGh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwgOikNCklu IGFub3RoZXIgd29yZCwgSSB0aGluayB3aGF0IEkgd2FudCBmaW5hbGx5IG1pZ2h0IGJlIGEgZGlz Y3Vzc2lvbiBhYm91dCAiV2hhdCBpcyBuZWVkZWQgZm9yIHRoZSBJU1M6IGEgc3luYyBwcm90b2Nv bCBvciBhIGdlbmVyYWxpemVkIEFQSSIuIFNvcnJ5IGZvciB0aGUgcG9vciBleHByZXNzaW9uIDog KQ0KDQpJIHRoaW5rIHRoaXMgaXMgYSByZWxldmFudCBxdWVzdGlvbiBpbmRlZWQgKHdlbGwsIGFj dHVhbGx5IGFsc28gaWYgdGhlcmUgaXMgYW55IHN0YW5kYXJkIG5lZWRlZCBhdCBhbGwgaW4gdGhl IGZpcnN0IHBsYWNlKS4gQnkgdGhlIGdlbmVyYWxpemVkIEFQSSBkbyB5b3UgbWVhbiBhIEhUVFAt c3R5bGUgQVBJIChsaWtlIFJFU1QpPyBJbiB0aGF0IGNhc2UgeW91IG1heSBjb25zaWRlciBXZWJE QVYgcXVpdGUgY2xvc2UgYW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHByb3RvY29sIGFu ZCB0aGUgQVBJIGJsdXJzIGZvciBwcmFjdGljYWwgcHVycG9zZXMuDQoNCldoaWxlIEkgYWdyZWUg dGhhdCBXZWJEQVYgbWF5IGhhdmUgZGlzYWR2YW50YWdlcyB0aGVyZSBpcyBhIGdvb2QgbnVtYmVy IG9mIGluc3RhbGxhdGlvbnMgdXNpbmcgdGhpcyBhbHJlYWR5IGluIG91ciBjb21tdW5pdHkgKHJl c2VhcmNoIGxhYnMgbWFpbmx5IGluLCBidXQgbm90IGxpbWl0ZWQgdG8sIEV1cm9wZSkuIEkgdGhp bmsgdGhlIGludGVyZXN0aW5nIHBvaW50IGFib3V0IFdlYkRBVi9IVFRQIGlzIGV4dGVuc2liaWxp dHkgYW5kIG1heWJlIGl0IGlzIHdvcnRoIGlzIHRoYXQgdGhlc2UgZXh0ZW5zaW9ucyBnbyBieSBh IOKAnHN0YW5kYXJk4oCdLiBIb3dldmVyLCB5b3Ugc2hvdWxkIGNvbnNpZGVyIHRoYXQgZm9yIHJl YXNvbmFibHkgZWZmaWNpZW50IHN5bmMgc2NlbmFyaW8gdGhlIHNlcnZlciBzaG91bGQgYWxzbyBl eGhpYml0IGNlcnRhaW4gYmVoYXZpb3VyLiBUaGF0IGlzLCBpbiBjYXNlIG9mIG93bmNsb3VkIGZv ciBleGFtcGxlLCBhIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBlZmZpY2llbnRseSBwcm9wYWdh dGUgdGhlIEVUQUcgY2hhbmdlcyB1cCB0aGUgZGlyZWN0b3J5IHRyZWUgKGxpa2UgdGhlIE1lcmts ZSBUcmVlKSBzbyB0aGF0IHRoZSBjbGllbnQgbWF5IHVzZSBwcm9wZmluZCBlZmZpY2llbnRseS4g VGhpcyBpcyBub3QgYSBoYXJkIHNwZWMgcmVxdWlyZW1lbnQgYnV0IG90aGVyd2lzZSBwcm9wZmlu ZGluZyB0aGUgZW50aXJlIHJlbW90ZSB0cmVlIGVhY2ggdGltZSB3b3VsZCBiZSBpbXByYWN0aWNh bGx5IGluZWZmaWNpZW50LiBTbyB0aGlzIHJlYWxseSBnb2VzIGEgbGl0dGxlIGJpdCBiZXlvbmQg anVzdCBhbiBBUEkuDQoNCllvdSBzaG91bGQgYWxzbyBjb25zaWRlciB0aGF0IHRoZSBPcGVuQ2xv dWRNZXNoICh1bmRlciBHRUFOVCB1bWJyZWxsYSkgaXMgYW4gaW5pdGlhdGl2ZSB3aXRoIHRoZSBp bnRlbnQgaXMgdG8gbWFrZSBjcm9zcy1zZXJ2aWNlIHNoYXJpbmcgdmVyeSBlYXN5LiBUaGVzZSBz aGFyZXMgbWF5IGFsc28gYmUgc3luY2hyb25pemVkIGF1dG9tYXRpY2FsbHkuIEkgY3VycmVudGx5 IGhhdmUgbm8gZXZpZGVuY2UsIGhvd2V2ZXIsIHRoYXQgb3RoZXIgc29mdHdhcmUgcHJvdmlkZXJz IHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBvd25jbG91ZCBhcmUgaW50ZXJlc3RlZCBpbiBkZXZlbG9w aW5nIHN1Y2ggc3RhbmRhcmQuIElmIHRoZXJlIGlzIG5vIGJvdHRvbSB1cCBpbnRlcmVzdCBmcm9t IHRoZSB1c2VycyB0aGVuIGl0IHdvbuKAmXQgaGFwcGVuIChpbiBteSBvcGluaW9uKS4NCg0KV2l0 aCB0aGUgbGluayBJIHdhbnRlZCB0byBwb2ludCB5b3UgdG8gdGhlIGZhY3QgdGhhdCB3aGF0IHlv dSBkaXNjdXNzIGluIHRoaXMgbWFpbGluZyBsaXN0IHdpbGwgYmUgYWxzbyBkaXNjdXNzZWQgYXQg dGhlIHVwY29taW5nIENTMyBldmVudCBJIGxpbmtlZCBpbi4gVGhlIGludGVudCBpcyB0byBkbyB0 aGlzIGRpc2N1c3NpbmcgdG9nZXRoZXIgYmV0d2VlbiBzZXJ2aWNlIHByb3ZpZGVycywgZGV2ZWxv cGVycyBhbmQgcmVzZWFyY2hlcnMgdG9nZXRoZXIg4oCUIHNvIHRoYXQgaXQgZG9lcyBub3Qgb25s eSBlbmQgdXAgYXMgYW4gYWNhZGVtaWMgZXhlcmNpc2UgYnV0IGJhY2tlZCB1cCBieSBhIGNyaXRp Y2FsIG1hc3MgaWYgdGhlcmUgaXMgc29tZSBwb3RlbnRpYWwgaW4gc3RhbmRhcmRpc2F0aW9uLCBh dCBsZWFzdCBpbiBvdXIgY29tbXVuaXR5LiBJIGhvcGUgdGhpcyBjb3VsZCBiZSBvZiBpbnRlcmVz dCB0byBJRVRGIGNvbW11bml0eSwgYXMgbWVudGlvbmVkIG9uIHRoZSBwcm9ncmFtIHBhZ2UuDQoN ClNlbGVjdGVkIHBhcGVycyB3aWxsIGJlIHB1Ymxpc2hlZCBpbiBGR0NTIGFmdGVyIHRoZSBldmVu dCwgc28gcGxlYXNlIHN0YW5kIGJ5LCBvciBhdHRlbmQgdGhlIGV2ZW50IGlmIHlvdSB3YW50IHRv IGJlIHBhcnQgb2YgdGhpcyBkaXNjdXNzaW9uIGhlcmUuIEJUVy4gdGhlIGFic3RyYWN0IHN1Ym1p c3Npb24gZGVhZGxpbmUgaXMgcGFzdCBidXQgb25lIGV4Y2VwdGlvbmFsbHkgZ29vZCBjb250cmli dXRpb24gY291bGQgc3RpbGwgcG9zc2libHkgYmUgYWNjb21tb2RhdGVkIGlmIHN1Ym1pdHRlZCBy YXBpZGx5Lg0KDQpJIHdvdWxkIGJlIG5vbmV0aGVsZXNzIGhhcHB5IHRvIGNvbnRpbnVlIGNvbnRy aWJ1dGluZyB0byB0aGUgZGlzY3Vzc2lvbiBpbiB0aGlzIG1haWxpbmcgbGlzdC4NCg0KQmVzdCBy ZWdhcmRzLA0KDQpKYWt1YiBNb3NjaWNraQ0KDQotLQ0KDQoNClJlZ2FyZHMsDQpMaW5odWkNCg0K DQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNvbmcNCj5IZWxsbywNCj4NCj5XaGF0IGtpbmQgb2Ygb3V0 Y29tZSBhcmUgeW91IGxvb2tpbmcgZm9yIHdpdGggdGhpcyBhbmFseXNpcz8gU29tZSByZXNlYXJj aCBpbiB0aGlzIGFyZWEgaGFzIGFscmVhZHkgYmVlbiBkb25lIG9yIGlzIGJlaW5nIGRvbmUgYXMg d2Ugc3BlYWsNCj4NCj5lLmcuICJBIHN0dWR5IG9mIGRlbHRhLXN5bmMgYW5kIG90aGVyIG9wdGlt aXNhdGlvbiBpbiBIVFRQL1dlYmRhdiBzeW5jaG9uaXNhdGlvbiBwcm90b2NvbHMiDQo+DQo+c2Vl ICJUZWNobm9sb2d5IGFuZCBSZXNlYXJjaCI6DQo+DQo+aHR0cDovL2NzMy5ldGh6LmNoL3Byb2dy YW0uaHRtbA0KPg0KPkl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIHNlZSBpZiB0aGVyZSBpcyBh IHBvdGVudGlhbCBmb3IgY29sbGFib3JhdGlvbi4gT3IgbWF5YmUgd2UgYWxyZWFkeSBoYXZlIHNv bWUgaW5mb3JtYXRpb24geW91IGFyZSBsb29raW5nIGZvci4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+ DQo+SmFrdWIgTW9zY2lja2kNCj4NCj7igJQNCj4NCj4NCj5PbiAyNSBOb3YgMjAxNSwgYXQgMTE6 NDUsIExpbmh1aSBTdW4gPGxoLnN1bmxpbmhAZ21haWwuY29tPG1haWx0bzpsaC5zdW5saW5oQGdt YWlsLmNvbT48bWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tPG1haWx0bzpsaC5zdW5saW5oQGdt YWlsLmNvbT4+PiB3cm90ZToNCj4NCj5IaSBhbGwsDQo+DQo+QXMgSSBtZW50aW9uZWQgYmVmb3Jl LCBJIHRoaW5rIHRoZSBkZXZlbG9wZXJzIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgSUVURiBzdGFu ZGFyZHMuIFRoZSBvd25DbG91ZCAoaHR0cHM6Ly9vd25jbG91ZC5vcmcvKSBpcyBqdXN0IGFuIGV4 YW1wbGUuIEl0IGlzIGRldmVsb3BlZCBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB0cnVzdCBjb21tZXJj aWFsIHN0b3JhZ2Ugc2VydmljZXMgYW5kIHdhbnQgdG8gYnVpbGQgdGhlaXIgb3duIG5ldHdvcmst YmFzZWQgc3RvcmFnZSBzZXJ2aWNlcy4gVGhlIG93bkNsb3VkIGlzIHVzaW5nIFdlYkRBViAoUkZD NDkxOCkgdG8gYWNoaWV2ZSB0aGUgZGF0YSBzeW5jLiBJTU8sIHRoZSBXZWJEQVYgaXMgZGVzaWdu ZWQgZm9yIGRpc3RyaWJ1dGVkIHdvcmsgYnV0IG5vdCBmb3IgdGhlIHN5bmMuIFRodXMsIEkgbWFk ZSBzb21lIHByZWxpbWluYXJ5IGludmVzdGlnYXRpb25zIG9uIGhvdyB0aGUgb3duQ2xvdWQgdXNl cyBXZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMuIEEgYnJpZWYgc3VtbWFyeSBvZiB3aGF0IEkndmUg Zm91bmQgaXMgaW4gdGhlIGZvbGxvd2luZywgcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9u Zy4NCj4NCj5JIGluc3RhbGxlZCB0aGUgb3duQ2xvdWQgc2VydmVyICh2OC4yLjEpIG9uIHRoZSBD ZW50T1M3LCBhbmQgdGhlIGNsaWVudCBpcyBhIGRlc2t0b3AgY2xpZW50IG9uIFdpbmRvd3MuDQo+ DQo+MS4gVG8gZmluZCB3aGV0aGVyIHRoZXJlIGlzIGEgY2hhbmdlIHRvIHRoZSBzeW5jZWQgZGly ZWN0b3J5LCB0aGUgY2xpZW50IGNvbnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2Vy dmVyIGF0IHJlZ3VsYXIgaW50ZXJ2YWxzIChhcm91bmQgMzQgc2Vjb25kcyB1bmRlciBteSBvYnNl cnZhdGlvbikuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA3IE11bHRpLVN0YXR1cyBSZXNw b25zZSB0byB0ZWxsIHdoZXRoZXIgdGhlIG1haW4gZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQu IFRvIHBlcmZvcm0gdGhpcyByZWd1bGFyIGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5l dyBUQ1AgY29ubmVjdGlvbiB0byBzZW5kIHRoZSBQUk9QRklORCwgdGhlIHNlcnZlciB3aWxsIGNs b3NlIHRoZSBleGlzdGluZyBUQ1AgY29ubmVjdGlvbiBhZnRlciByZXNwb25kaW5nIHRoZSAyMDcg TXVsdGktU3RhdHVzIFJlc3BvbnNlLiBGb3IgdGhlIG5leHQgY2hlY2ssIHRoZSBjbGllbnQgd2ls bCBvcGVuIGFub3RoZXIgbmV3IFRDUCBjb25uZWN0aW9uLg0KPg0KPjIuIEV2ZXJ5IHRpbWUgYWRk aW5nIChvciBjcmVhdGluZykgYSBuZXcgZmlsZSB0byB0aGUgbG9jYWwgZm9sZGVyLCB0aGUgY2xp ZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiAoaWYgdGhlcmUgaXMgbm8gY29ubmVj dGlvbiBleGlzdGluZykgdG8gc2VuZCB0aGUgZmlsZSBhc2FwLiBUaGUgY2xpZW50IHdpbGwgZmly c3Qgc2VuZCBzZXZlcmFsIFBST1BGSU5EcyB0byBmaW5kIG91dCB3aGljaCBzdWItZGlyZWN0b3J5 IGhhcyBiZWVuIGNoYW5nZWQuIEFuZCB0aGVuIGl0IHNlbmRzIHRoZSBmaWxlIHVzaW5nIFBVVC4g VGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDEgQ3JlYXRlZCBSZXNwb25zZSBhbmQgdGhlbiB0 ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24uIEN1cnJlbnRseSwgSSBoYXZlbid0IGZvdW5kIGFueSBh cHBsaWNhdGlvbiBsYXllciBjaHVua2luZywgYWxsIHRoZSBzZWdtZW50YXRpb24gYXJlIHBlcmZv cm1lZCBieSBUQ1AuDQo+DQo+My4gRXZlcnkgdGltZSBJIGRlbGV0ZSAob3IgcmVuYW1lKSBhIGZp bGUgbG9jYWxseSwgdGhlIGNsaWVudCB3aWxsIGFsc28gb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlv biB0byBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIGZpbGUgaGFzIGJl ZW4gcmVtb3ZlZCAob3IgcmVuYW1lZCkuIFRoZW4gaXQgd2lsbCBzZW5kIERFTEVURSAob3IgTU9W RSkuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA0IE5vIENvbnRlbnQgUmVzcG9uc2UgKG9y IDIwMSBDcmVhdGVkIFJlc3BvbnNlKSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24u DQo+DQo+NC4gSSBvcGVuIGEgZmlsZSBhbmQgZnJlcXVlbnRseSBlZGl0IGFuZCBzYXZlIGl0IChh Y3R1YWxseSB0aGlzIGlzIHdoYXQgSSB1c3VhbGx5IGRvIHdpdGggdGhlIERyb3Bib3gpLiBUaGUg Y2xpZW50IHdpbGwgc2VuZCB0aGUgd2hvbGUgZmlsZSB0byB0aGUgc2VydmVyIGV2ZXJ5IHRpbWUg SSBzYXZlIHRoZSBmaWxlLg0KPg0KPlRvIHN1bW1hcml6ZSwgaXQgc2VlbXMgdGhhdCB0aGUgb3du Q2xvdWQgbWFrZXMgaGVhdmlseSB1c2Ugb2YgUFJPUEZJTkQgdG8gYWNoaWV2ZSB0aGUgc3luYyBw cm9jZXNzLiBFYWNoIHN5bmMgb3BlcmF0aW9uIChlLmcuIHVwbG9hZCwgbW9kaWZ5IGFuZCBldGMu KSB3aWxsIHN0YXJ0IHdpdGggc2VuZGluZyBvbmUgb3IgbW9yZSBQUk9QRklORHMuIEFuZCBjdXJy ZW50bHksIGlmIEkgYWRkIGEgZmlsZSB0byB0aGUgc2VydmVyIChkaXJlY3RseSBmcm9tIHRoZSBz ZXJ2ZXIgc2lkZSB2aWEgd2ViIGludGVyZmFjZSksIHRoZSBjbGllbnQgY2Fubm90IGZpbmQgdGhl IGNoYW5nZS4gSSBuZWVkIHRvIGludGVycnVwdCB0aGUgc3luYyBhbmQgcmVjb3ZlciBpdCB0byBt YWtlIHRoZSBjbGllbnQgYmUgYXdhcmUgb2YgdGhlIGNoYW5nZSBhbmQgZG93bmxvYWQgdGhlIG5l d2x5IGFkZGVkIGZpbGUuIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgY2F1c2VkIGJ5IHRo ZSBzeW5jIG1lY2hhbmlzbSBvciBhbiBpbXByb3BlciBzZXJ2ZXIgY29uZmlndXJhdGlvbi4gSSBu ZWVkIHRvIGludmVzdGlnYXRlIHRoaXMgZnVydGhlciBhbmQgYWxzbyBob3cgdGhlIG93bkNsb3Vk IHdvcmtzIGZvciBtdWx0aXBsZSBjbGllbnRzIChvciBkZXZpY2VzKS4NCj4NCj5Gb3IgSVNTLCBJ IHRoaW5rIG93bkNsb3VkIGhhcyBkZW1vbnN0cmF0ZWQgdG8gc29tZSBleHRlbnQgdGhhdCBzaW1p bGFyIElFVEYgcHJvdG9jb2xzIGNvdWxkIGJlIGRlcGxveWVkIGFuZCBlbXBsb3llZC4gVGhlIGlu dGVudGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJlbnQgc3Rh dGUgb2YgdXNpbmcgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRv IGJlIGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIgd2UgbmVlZCBuZXcgcHJvdG9jb2xzLg0KPg0K PkNvbW1lbnRzIGFyZSB3ZWxjb21lIDogKQ0KPg0KPlJlZ2FyZHMsDQo+TGluaHVpDQo+DQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5TdG9yYWdl c3luYyBtYWlsaW5nIGxpc3QNCj5TdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5 bmNAaWV0Zi5vcmc+PG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5 bmNAaWV0Zi5vcmc+Pg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rv cmFnZXN5bmMNCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNClN0b3JhZ2VzeW5jQGlldGYub3JnPG1haWx0 bzpTdG9yYWdlc3luY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3RvcmFnZXN5bmMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KU3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQpTdG9yYWdlc3luY0BpZXRm Lm9yZzxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQoNCg== --_000_9A7E1A048C4A40BE933D6814ACDB135Ccernch_ Content-Type: text/html; charset="utf-8" Content-ID: <691FB9145226E740B75FDCC87D10664E@cern.ch> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQlRXLCBoZXJlIGlzIHRoZSBwdWJs aWMgQ0ZQIGZvciBGR0NTOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9jczMuZXRoei5jaC9wdWJsaWNh dGlvbnMuaHRtbCIgY2xhc3M9IiI+aHR0cDovL2NzMy5ldGh6LmNoL3B1YmxpY2F0aW9ucy5odG1s PC9hPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+SmFrdWIgTW9zY2lja2k8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI2IE5vdiAyMDE1LCBhdCAw NDoyOSwgSmFrdWIgTW9zY2lja2kgJmx0OzxhIGhyZWY9Im1haWx0bzpKYWt1Yi5Nb3NjaWNraUBj ZXJuLmNoIiBjbGFzcz0iIj5KYWt1Yi5Nb3NjaWNraUBjZXJuLmNoPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+MjAxNS0xMS0yNiAxMToyOCBHTVQmIzQz OzA4OjAwIEZlaSBTb25nIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJt YWlsdG86ZnNvbmdAYmp0dS5lZHUuY24iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5mc29uZ0Bi anR1LmVkdS5jbjwvYT4mZ3Q7PC9zcGFuPjo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxl ZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxl ZnQtc3R5bGU6c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpCVFcsIEJhc2VkIG9uIHRoZSBsYXN0 IHNlbnRlbmNlIG9mIGxhc3QgZW1haWw6JnF1b3Q7VGhlIGludGVudGlvbiBvZiB0aGlzIG1lc3Nh Z2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdXNpbmcgV2ViREFWIGZv ciBzeW5jIHB1cnBvc2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkIGhlcmUgYW5k IHdoZXRoZXIgd2UgbmVlZCBuZXcgcHJvdG9jb2xzJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KVGhlIG91dGNvbWUgaGUvc2hlIHdhbnRlZCBtaWdodCBiZSBqdXN0IHRoZSBsaW5r cyBsaWtlIDxhIGhyZWY9Imh0dHA6Ly9jczMuZXRoei5jaC9wcm9ncmFtLmh0bWwiIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cDovL2NzMy5ldGh6LmNoL3By b2dyYW0uaHRtbDwvYT4gOik8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNz PSIiPkluIGFub3RoZXIgd29yZCwgSSB0aGluayB3aGF0IEkgd2FudCBmaW5hbGx5IG1pZ2h0IGJl IGEgZGlzY3Vzc2lvbiBhYm91dCAmcXVvdDtXaGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzogYSBz eW5jIHByb3RvY29sIG9yIGEgZ2VuZXJhbGl6ZWQgQVBJJnF1b3Q7LiBTb3JyeSBmb3IgdGhlIHBv b3IgZXhwcmVzc2lvbiA6ICk8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkkgdGhp bmsgdGhpcyBpcyBhIHJlbGV2YW50IHF1ZXN0aW9uIGluZGVlZCAod2VsbCwgYWN0dWFsbHkgYWxz byBpZiB0aGVyZSBpcyBhbnkgc3RhbmRhcmQgbmVlZGVkIGF0IGFsbCBpbiB0aGUgZmlyc3QgcGxh Y2UpLiBCeSB0aGUgZ2VuZXJhbGl6ZWQgQVBJIGRvIHlvdSBtZWFuIGEgSFRUUC1zdHlsZSBBUEkg KGxpa2UgUkVTVCk/IEluIHRoYXQgY2FzZSB5b3UgbWF5IGNvbnNpZGVyIFdlYkRBViBxdWl0ZSBj bG9zZSBhbmQgdGhlIGRpZmZlcmVuY2UNCiBiZXR3ZWVuIHRoZSBwcm90b2NvbCBhbmQgdGhlIEFQ SSBibHVycyBmb3IgcHJhY3RpY2FsIHB1cnBvc2VzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2hpbGUgSSBhZ3JlZSB0aGF0 IFdlYkRBViBtYXkgaGF2ZSBkaXNhZHZhbnRhZ2VzIHRoZXJlIGlzIGEgZ29vZCBudW1iZXIgb2Yg aW5zdGFsbGF0aW9ucyB1c2luZyB0aGlzIGFscmVhZHkgaW4gb3VyIGNvbW11bml0eSAocmVzZWFy Y2ggbGFicyBtYWlubHkgaW4sIGJ1dCBub3QgbGltaXRlZCB0bywgRXVyb3BlKS4gSSB0aGluayB0 aGUgaW50ZXJlc3RpbmcgcG9pbnQgYWJvdXQgV2ViREFWL0hUVFAgaXMgZXh0ZW5zaWJpbGl0eQ0K IGFuZCBtYXliZSBpdCBpcyB3b3J0aCBpcyB0aGF0IHRoZXNlIGV4dGVuc2lvbnMgZ28gYnkgYSDi gJxzdGFuZGFyZOKAnS4gSG93ZXZlciwgeW91IHNob3VsZCBjb25zaWRlciB0aGF0IGZvciByZWFz b25hYmx5IGVmZmljaWVudCBzeW5jIHNjZW5hcmlvIHRoZSBzZXJ2ZXIgc2hvdWxkIGFsc28gZXho aWJpdCBjZXJ0YWluIGJlaGF2aW91ci4gVGhhdCBpcywgaW4gY2FzZSBvZiBvd25jbG91ZCBmb3Ig ZXhhbXBsZSwgYSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUNCiB0byBlZmZpY2llbnRseSBwcm9wYWdh dGUgdGhlIEVUQUcgY2hhbmdlcyB1cCB0aGUgZGlyZWN0b3J5IHRyZWUgKGxpa2UgdGhlIE1lcmts ZSBUcmVlKSBzbyB0aGF0IHRoZSBjbGllbnQgbWF5IHVzZSBwcm9wZmluZCBlZmZpY2llbnRseS4g VGhpcyBpcyBub3QgYSBoYXJkIHNwZWMgcmVxdWlyZW1lbnQgYnV0IG90aGVyd2lzZSBwcm9wZmlu ZGluZyB0aGUgZW50aXJlIHJlbW90ZSB0cmVlIGVhY2ggdGltZSB3b3VsZCBiZSBpbXByYWN0aWNh bGx5IGluZWZmaWNpZW50Lg0KIFNvIHRoaXMgcmVhbGx5IGdvZXMgYSBsaXR0bGUgYml0IGJleW9u ZCBqdXN0IGFuIEFQSS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Zb3Ugc2hvdWxkIGFsc28gY29uc2lkZXIg dGhhdCB0aGUgT3BlbkNsb3VkTWVzaCAodW5kZXIgR0VBTlQgdW1icmVsbGEpIGlzIGFuIGluaXRp YXRpdmUgd2l0aCB0aGUgaW50ZW50IGlzIHRvIG1ha2UgY3Jvc3Mtc2VydmljZSBzaGFyaW5nIHZl cnkgZWFzeS4gVGhlc2Ugc2hhcmVzIG1heSBhbHNvIGJlIHN5bmNocm9uaXplZCBhdXRvbWF0aWNh bGx5LiBJIGN1cnJlbnRseSBoYXZlIG5vIGV2aWRlbmNlLCBob3dldmVyLCB0aGF0DQogb3RoZXIg c29mdHdhcmUgcHJvdmlkZXJzIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBvd25jbG91ZCBhcmUgaW50 ZXJlc3RlZCBpbiBkZXZlbG9waW5nIHN1Y2ggc3RhbmRhcmQuIElmIHRoZXJlIGlzIG5vIGJvdHRv bSB1cCBpbnRlcmVzdCBmcm9tIHRoZSB1c2VycyB0aGVuIGl0IHdvbuKAmXQgaGFwcGVuIChpbiBt eSBvcGluaW9uKS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2l0aCB0aGUgbGluayBJIHdhbnRlZCB0byBwb2ludCB5b3Ug dG8gdGhlIGZhY3QgdGhhdCB3aGF0IHlvdSBkaXNjdXNzIGluIHRoaXMgbWFpbGluZyBsaXN0IHdp bGwgYmUgYWxzbyBkaXNjdXNzZWQgYXQgdGhlIHVwY29taW5nIENTMyBldmVudCBJIGxpbmtlZCBp bi4gVGhlIGludGVudCBpcyB0byBkbyB0aGlzIGRpc2N1c3NpbmcgdG9nZXRoZXIgYmV0d2VlbiBz ZXJ2aWNlIHByb3ZpZGVycywgZGV2ZWxvcGVycyBhbmQgcmVzZWFyY2hlcnMNCiB0b2dldGhlciDi gJQgc28gdGhhdCBpdCBkb2VzIG5vdCBvbmx5IGVuZCB1cCBhcyBhbiBhY2FkZW1pYyBleGVyY2lz ZSBidXQgYmFja2VkIHVwIGJ5IGEgY3JpdGljYWwgbWFzcyBpZiB0aGVyZSBpcyBzb21lIHBvdGVu dGlhbCBpbiBzdGFuZGFyZGlzYXRpb24sIGF0IGxlYXN0IGluIG91ciBjb21tdW5pdHkuIEkgaG9w ZSB0aGlzIGNvdWxkIGJlIG9mIGludGVyZXN0IHRvIElFVEYgY29tbXVuaXR5LCBhcyBtZW50aW9u ZWQgb24gdGhlIHByb2dyYW0gcGFnZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNlbGVjdGVkIHBhcGVycyB3aWxsIGJlIHB1Ymxpc2hl ZCBpbiBGR0NTIGFmdGVyIHRoZSBldmVudCwgc28gcGxlYXNlIHN0YW5kIGJ5LCBvciBhdHRlbmQg dGhlIGV2ZW50IGlmIHlvdSB3YW50IHRvIGJlIHBhcnQgb2YgdGhpcyBkaXNjdXNzaW9uIGhlcmUu IEJUVy4gdGhlIGFic3RyYWN0IHN1Ym1pc3Npb24gZGVhZGxpbmUgaXMgcGFzdCBidXQgb25lIGV4 Y2VwdGlvbmFsbHkgZ29vZCBjb250cmlidXRpb24gY291bGQgc3RpbGwNCiBwb3NzaWJseSBiZSBh Y2NvbW1vZGF0ZWQgaWYgc3VibWl0dGVkIHJhcGlkbHkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHdvdWxkIGJlIG5vbmV0aGVsZXNz IGhhcHB5IHRvIGNvbnRpbnVlIGNvbnRyaWJ1dGluZyB0byB0aGUgZGlzY3Vzc2lvbiBpbiB0aGlz IG1haWxpbmcgbGlzdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkpha3ViIE1vc2NpY2tpPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tLTxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+TGluaHVpJm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2Jv cmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLS0t LS0tLS0tLTxiciBjbGFzcz0iIj4NCkZlaSBTb25nPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9 IiI+Jmd0O0hlbGxvLDxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7V2hhdCBr aW5kIG9mIG91dGNvbWUgYXJlIHlvdSBsb29raW5nIGZvciB3aXRoIHRoaXMgYW5hbHlzaXM/IFNv bWUgcmVzZWFyY2ggaW4gdGhpcyBhcmVhIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBvciBpcyBiZWlu ZyBkb25lIGFzIHdlIHNwZWFrPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDtl LmcuICZxdW90O0Egc3R1ZHkgb2YgZGVsdGEtc3luYyBhbmQgb3RoZXIgb3B0aW1pc2F0aW9uIGlu IEhUVFAvV2ViZGF2IHN5bmNob25pc2F0aW9uIHByb3RvY29scyZxdW90OzxiciBjbGFzcz0iIj4N CiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7c2VlICZxdW90O1RlY2hub2xvZ3kgYW5kIFJlc2VhcmNo JnF1b3Q7OjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7PGEgaHJlZj0iaHR0 cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+aHR0cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbDwvYT48YnIgY2xh c3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0O0l0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRv IHNlZSBpZiB0aGVyZSBpcyBhIHBvdGVudGlhbCBmb3IgY29sbGFib3JhdGlvbi4gT3IgbWF5YmUg d2UgYWxyZWFkeSBoYXZlIHNvbWUgaW5mb3JtYXRpb24geW91IGFyZSBsb29raW5nIGZvci48YnIg Y2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0O0Jlc3QgcmVnYXJkcyw8YnIgY2xhc3M9 IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0O0pha3ViIE1vc2NpY2tpPGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDvigJQ8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OzxiciBjbGFzcz0iIj4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iIj4mZ3Q7T24gMjUgTm92 IDIwMTUsIGF0IDExOjQ1LCBMaW5odWkgU3VuICZsdDs8YSBocmVmPSJtYWlsdG86bGguc3VubGlu aEBnbWFpbC5jb20iIGNsYXNzPSIiPmxoLnN1bmxpbmhAZ21haWwuY29tPC9hPiZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmxoLnN1bmxpbmhAZ21haWwuY29tIiBjbGFzcz0iIj5saC5zdW5saW5o QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0O0hpIGFsbCw8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0O0Fz IEkgbWVudGlvbmVkIGJlZm9yZSwgSSB0aGluayB0aGUgZGV2ZWxvcGVycyBjb3VsZCBiZW5lZml0 IGZyb20gdGhlIElFVEYgc3RhbmRhcmRzLiBUaGUgb3duQ2xvdWQgKDxhIGhyZWY9Imh0dHBzOi8v b3duY2xvdWQub3JnLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ aHR0cHM6Ly9vd25jbG91ZC5vcmcvPC9hPikgaXMganVzdCBhbiBleGFtcGxlLiBJdCBpcyBkZXZl bG9wZWQgZm9yIHRob3NlIHdobyBkbyBub3QNCiB0cnVzdCBjb21tZXJjaWFsIHN0b3JhZ2Ugc2Vy dmljZXMgYW5kIHdhbnQgdG8gYnVpbGQgdGhlaXIgb3duIG5ldHdvcmstYmFzZWQgc3RvcmFnZSBz ZXJ2aWNlcy4gVGhlIG93bkNsb3VkIGlzIHVzaW5nIFdlYkRBViAoUkZDNDkxOCkgdG8gYWNoaWV2 ZSB0aGUgZGF0YSBzeW5jLiBJTU8sIHRoZSBXZWJEQVYgaXMgZGVzaWduZWQgZm9yIGRpc3RyaWJ1 dGVkIHdvcmsgYnV0IG5vdCBmb3IgdGhlIHN5bmMuIFRodXMsIEkgbWFkZSBzb21lIHByZWxpbWlu YXJ5DQogaW52ZXN0aWdhdGlvbnMgb24gaG93IHRoZSBvd25DbG91ZCB1c2VzIFdlYkRBViBmb3Ig c3luYyBwdXJwb3Nlcy4gQSBicmllZiBzdW1tYXJ5IG9mIHdoYXQgSSd2ZSBmb3VuZCBpcyBpbiB0 aGUgZm9sbG93aW5nLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLjxiciBjbGFzcz0i Ij4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7SSBpbnN0YWxsZWQgdGhlIG93bkNsb3VkIHNlcnZl ciAodjguMi4xKSBvbiB0aGUgQ2VudE9TNywgYW5kIHRoZSBjbGllbnQgaXMgYSBkZXNrdG9wIGNs aWVudCBvbiBXaW5kb3dzLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7MS4g VG8gZmluZCB3aGV0aGVyIHRoZXJlIGlzIGEgY2hhbmdlIHRvIHRoZSBzeW5jZWQgZGlyZWN0b3J5 LCB0aGUgY2xpZW50IGNvbnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2VydmVyIGF0 IHJlZ3VsYXIgaW50ZXJ2YWxzIChhcm91bmQgMzQgc2Vjb25kcyB1bmRlciBteSBvYnNlcnZhdGlv bikuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA3IE11bHRpLVN0YXR1cyBSZXNwb25zZSB0 byB0ZWxsIHdoZXRoZXIgdGhlIG1haW4gZGlyZWN0b3J5DQogaGFzIGJlZW4gY2hhbmdlZC4gVG8g cGVyZm9ybSB0aGlzIHJlZ3VsYXIgY2hlY2ssIHRoZSBjbGllbnQgd2lsbCBvcGVuIGEgbmV3IFRD UCBjb25uZWN0aW9uIHRvIHNlbmQgdGhlIFBST1BGSU5ELCB0aGUgc2VydmVyIHdpbGwgY2xvc2Ug dGhlIGV4aXN0aW5nIFRDUCBjb25uZWN0aW9uIGFmdGVyIHJlc3BvbmRpbmcgdGhlIDIwNyBNdWx0 aS1TdGF0dXMgUmVzcG9uc2UuIEZvciB0aGUgbmV4dCBjaGVjaywgdGhlIGNsaWVudCB3aWxsIG9w ZW4gYW5vdGhlcg0KIG5ldyBUQ1AgY29ubmVjdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OzIuIEV2ZXJ5IHRpbWUgYWRkaW5nIChvciBjcmVhdGluZykgYSBuZXcgZmls ZSB0byB0aGUgbG9jYWwgZm9sZGVyLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29u bmVjdGlvbiAoaWYgdGhlcmUgaXMgbm8gY29ubmVjdGlvbiBleGlzdGluZykgdG8gc2VuZCB0aGUg ZmlsZSBhc2FwLiBUaGUgY2xpZW50IHdpbGwgZmlyc3Qgc2VuZCBzZXZlcmFsIFBST1BGSU5EcyB0 byBmaW5kIG91dCB3aGljaCBzdWItZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQuDQogQW5kIHRo ZW4gaXQgc2VuZHMgdGhlIGZpbGUgdXNpbmcgUFVULiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBh IDIwMSBDcmVhdGVkIFJlc3BvbnNlIGFuZCB0aGVuIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4g Q3VycmVudGx5LCBJIGhhdmVuJ3QgZm91bmQgYW55IGFwcGxpY2F0aW9uIGxheWVyIGNodW5raW5n LCBhbGwgdGhlIHNlZ21lbnRhdGlvbiBhcmUgcGVyZm9ybWVkIGJ5IFRDUC48YnIgY2xhc3M9IiI+ DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzMuIEV2ZXJ5IHRpbWUgSSBkZWxldGUgKG9yIHJlbmFt ZSkgYSBmaWxlIGxvY2FsbHksIHRoZSBjbGllbnQgd2lsbCBhbHNvIG9wZW4gYSBuZXcgVENQIGNv bm5lY3Rpb24gdG8gc2VuZCBzZXZlcmFsIFBST1BGSU5EcyB0byBmaW5kIG91dCB3aGljaCBmaWxl IGhhcyBiZWVuIHJlbW92ZWQgKG9yIHJlbmFtZWQpLiBUaGVuIGl0IHdpbGwgc2VuZCBERUxFVEUg KG9yIE1PVkUpLiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwNCBObyBDb250ZW50IFJlc3Bv bnNlDQogKG9yIDIwMSBDcmVhdGVkIFJlc3BvbnNlKSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNv bm5lY3Rpb24uPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDs0LiBJIG9wZW4g YSBmaWxlIGFuZCBmcmVxdWVudGx5IGVkaXQgYW5kIHNhdmUgaXQgKGFjdHVhbGx5IHRoaXMgaXMg d2hhdCBJIHVzdWFsbHkgZG8gd2l0aCB0aGUgRHJvcGJveCkuIFRoZSBjbGllbnQgd2lsbCBzZW5k IHRoZSB3aG9sZSBmaWxlIHRvIHRoZSBzZXJ2ZXIgZXZlcnkgdGltZSBJIHNhdmUgdGhlIGZpbGUu PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDtUbyBzdW1tYXJpemUsIGl0IHNl ZW1zIHRoYXQgdGhlIG93bkNsb3VkIG1ha2VzIGhlYXZpbHkgdXNlIG9mIFBST1BGSU5EIHRvIGFj aGlldmUgdGhlIHN5bmMgcHJvY2Vzcy4gRWFjaCBzeW5jIG9wZXJhdGlvbiAoZS5nLiB1cGxvYWQs IG1vZGlmeSBhbmQgZXRjLikgd2lsbCBzdGFydCB3aXRoIHNlbmRpbmcgb25lIG9yIG1vcmUgUFJP UEZJTkRzLiBBbmQgY3VycmVudGx5LCBpZiBJIGFkZCBhIGZpbGUgdG8gdGhlIHNlcnZlciAoZGly ZWN0bHkgZnJvbQ0KIHRoZSBzZXJ2ZXIgc2lkZSB2aWEgd2ViIGludGVyZmFjZSksIHRoZSBjbGll bnQgY2Fubm90IGZpbmQgdGhlIGNoYW5nZS4gSSBuZWVkIHRvIGludGVycnVwdCB0aGUgc3luYyBh bmQgcmVjb3ZlciBpdCB0byBtYWtlIHRoZSBjbGllbnQgYmUgYXdhcmUgb2YgdGhlIGNoYW5nZSBh bmQgZG93bmxvYWQgdGhlIG5ld2x5IGFkZGVkIGZpbGUuIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRo aXMgaXMgY2F1c2VkIGJ5IHRoZSBzeW5jIG1lY2hhbmlzbSBvciBhbg0KIGltcHJvcGVyIHNlcnZl ciBjb25maWd1cmF0aW9uLiBJIG5lZWQgdG8gaW52ZXN0aWdhdGUgdGhpcyBmdXJ0aGVyIGFuZCBh bHNvIGhvdyB0aGUgb3duQ2xvdWQgd29ya3MgZm9yIG11bHRpcGxlIGNsaWVudHMgKG9yIGRldmlj ZXMpLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Rm9yIElTUywgSSB0aGlu ayBvd25DbG91ZCBoYXMgZGVtb25zdHJhdGVkIHRvIHNvbWUgZXh0ZW50IHRoYXQgc2ltaWxhciBJ RVRGIHByb3RvY29scyBjb3VsZCBiZSBkZXBsb3llZCBhbmQgZW1wbG95ZWQuIFRoZSBpbnRlbnRp b24gb2YgdGhpcyBtZXNzYWdlIGlzIHRvIGludmVzdGlnYXRlIHRoZSBjdXJyZW50IHN0YXRlIG9m IHVzaW5nIFdlYkRBViBmb3Igc3luYyBwdXJwb3NlcyB0byBzZWUgd2hhdCBuZWVkcyB0byBiZSBp bXByb3ZlZCBoZXJlDQogYW5kIHdoZXRoZXIgd2UgbmVlZCBuZXcgcHJvdG9jb2xzLjxiciBjbGFz cz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Q29tbWVudHMgYXJlIHdlbGNvbWUgOiApPGJy IGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDtSZWdhcmRzLDxiciBjbGFzcz0iIj4N CiZndDtMaW5odWk8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFz cz0iIj4NCiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxiciBjbGFzcz0iIj4NCiZndDtTdG9yYWdlc3luYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQo8L3NwYW4+Jmd0OzxhIGhyZWY9Im1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZyIgY2xhc3M9 IiI+U3RvcmFnZXN5bmNAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86U3Rv cmFnZXN5bmNAaWV0Zi5vcmciIGNsYXNzPSIiPlN0b3JhZ2VzeW5jQGlldGYub3JnPC9hPiZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdG9yYWdlc3luYyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYzwv YT48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iaDUiPiZndDs8YnIg Y2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxiciBjbGFzcz0iIj4NClN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZyIgY2xhc3M9IiI+U3RvcmFnZXN5bmNA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9y YWdlc3luYzwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpTdG9yYWdlc3luYyBtYWls aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5v cmciIGNsYXNzPSIiPlN0b3JhZ2VzeW5jQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmM8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_9A7E1A048C4A40BE933D6814ACDB135Ccernch_-- From nobody Thu Nov 26 00:02: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 5FC181A0141 for ; Thu, 26 Nov 2015 00:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 ahvSsAL9CKV6 for ; Thu, 26 Nov 2015 00:02:10 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id A76201A0137 for ; Thu, 26 Nov 2015 00:02:09 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb4 (Coremail) with SMTP id eJ5wygDHzgYAvVZWTq5RAQ--.37162S2; Thu, 26 Nov 2015 16:04:16 +0800 (CST) Date: Thu, 26 Nov 2015 16:02:02 +0800 From: "Fei Song" To: "Jakub Moscicki" , "Linhui Sun" 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: <2015112616020129658321@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: eJ5wygDHzgYAvVZWTq5RAQ--.37162S2 X-Coremail-Antispam: 1UD129KBjvJXoW3JF48ArW3urykCrWfCr4DJwb_yoW3urW3pF 43K3W8KFykJr4xCwn7Jr1I9r10vFWkJrW3Jrn8Jr1xArZ8WFyIqFyxtr4ruFyUGrZ3Gr1j qr4F9FZxC3Z8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkEb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07bwv3 nUUUUU= 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: Thu, 26 Nov 2015 08:02:13 -0000 VGhhbmtzIGZvciB0aGF0fg0KDQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KPkJUVywgaGVy ZSBpcyB0aGUgcHVibGljIENGUCBmb3IgRkdDUzogaHR0cDovL2NzMy5ldGh6LmNoL3B1YmxpY2F0 aW9ucy5odG1sDQo+DQo+QmVzdCByZWdhcmRzLA0KPg0KPkpha3ViIE1vc2NpY2tpDQo+DQo+oaoN Cj4NCj5PbiAyNiBOb3YgMjAxNSwgYXQgMDQ6MjksIEpha3ViIE1vc2NpY2tpIDxKYWt1Yi5Nb3Nj aWNraUBjZXJuLmNoPG1haWx0bzpKYWt1Yi5Nb3NjaWNraUBjZXJuLmNoPj4gd3JvdGU6DQo+DQo+ MjAxNS0xMS0yNiAxMToyOCBHTVQrMDg6MDAgRmVpIFNvbmcgPGZzb25nQGJqdHUuZWR1LmNuPG1h aWx0bzpmc29uZ0BianR1LmVkdS5jbj4+Og0KPkJUVywgQmFzZWQgb24gdGhlIGxhc3Qgc2VudGVu Y2Ugb2YgbGFzdCBlbWFpbDoiVGhlIGludGVudGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgdG8gaW52 ZXN0aWdhdGUgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdXNpbmcgV2ViREFWIGZvciBzeW5jIHB1cnBv c2VzIHRvIHNlZSB3aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIgd2Ug bmVlZCBuZXcgcHJvdG9jb2xzIg0KPg0KPlRoZSBvdXRjb21lIGhlL3NoZSB3YW50ZWQgbWlnaHQg YmUganVzdCB0aGUgbGlua3MgbGlrZSBodHRwOi8vY3MzLmV0aHouY2gvcHJvZ3JhbS5odG1sIDop DQo+SW4gYW5vdGhlciB3b3JkLCBJIHRoaW5rIHdoYXQgSSB3YW50IGZpbmFsbHkgbWlnaHQgYmUg YSBkaXNjdXNzaW9uIGFib3V0ICJXaGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzogYSBzeW5jIHBy b3RvY29sIG9yIGEgZ2VuZXJhbGl6ZWQgQVBJIi4gU29ycnkgZm9yIHRoZSBwb29yIGV4cHJlc3Np b24gOiApDQo+DQo+SSB0aGluayB0aGlzIGlzIGEgcmVsZXZhbnQgcXVlc3Rpb24gaW5kZWVkICh3 ZWxsLCBhY3R1YWxseSBhbHNvIGlmIHRoZXJlIGlzIGFueSBzdGFuZGFyZCBuZWVkZWQgYXQgYWxs IGluIHRoZSBmaXJzdCBwbGFjZSkuIEJ5IHRoZSBnZW5lcmFsaXplZCBBUEkgZG8geW91IG1lYW4g YSBIVFRQLXN0eWxlIEFQSSAobGlrZSBSRVNUKT8gSW4gdGhhdCBjYXNlIHlvdSBtYXkgY29uc2lk ZXIgV2ViREFWIHF1aXRlIGNsb3NlIGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBwcm90 b2NvbCBhbmQgdGhlIEFQSSBibHVycyBmb3IgcHJhY3RpY2FsIHB1cnBvc2VzLg0KPg0KPldoaWxl IEkgYWdyZWUgdGhhdCBXZWJEQVYgbWF5IGhhdmUgZGlzYWR2YW50YWdlcyB0aGVyZSBpcyBhIGdv b2QgbnVtYmVyIG9mIGluc3RhbGxhdGlvbnMgdXNpbmcgdGhpcyBhbHJlYWR5IGluIG91ciBjb21t dW5pdHkgKHJlc2VhcmNoIGxhYnMgbWFpbmx5IGluLCBidXQgbm90IGxpbWl0ZWQgdG8sIEV1cm9w ZSkuIEkgdGhpbmsgdGhlIGludGVyZXN0aW5nIHBvaW50IGFib3V0IFdlYkRBVi9IVFRQIGlzIGV4 dGVuc2liaWxpdHkgYW5kIG1heWJlIGl0IGlzIHdvcnRoIGlzIHRoYXQgdGhlc2UgZXh0ZW5zaW9u cyBnbyBieSBhIKGwc3RhbmRhcmShsS4gSG93ZXZlciwgeW91IHNob3VsZCBjb25zaWRlciB0aGF0 IGZvciByZWFzb25hYmx5IGVmZmljaWVudCBzeW5jIHNjZW5hcmlvIHRoZSBzZXJ2ZXIgc2hvdWxk IGFsc28gZXhoaWJpdCBjZXJ0YWluIGJlaGF2aW91ci4gVGhhdCBpcywgaW4gY2FzZSBvZiBvd25j bG91ZCBmb3IgZXhhbXBsZSwgYSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gZWZmaWNpZW50bHkg cHJvcGFnYXRlIHRoZSBFVEFHIGNoYW5nZXMgdXAgdGhlIGRpcmVjdG9yeSB0cmVlIChsaWtlIHRo ZSBNZXJrbGUgVHJlZSkgc28gdGhhdCB0aGUgY2xpZW50IG1heSB1c2UgcHJvcGZpbmQgZWZmaWNp ZW50bHkuIFRoaXMgaXMgbm90IGEgaGFyZCBzcGVjIHJlcXVpcmVtZW50IGJ1dCBvdGhlcndpc2Ug cHJvcGZpbmRpbmcgdGhlIGVudGlyZSByZW1vdGUgdHJlZSBlYWNoIHRpbWUgd291bGQgYmUgaW1w cmFjdGljYWxseSBpbmVmZmljaWVudC4gU28gdGhpcyByZWFsbHkgZ29lcyBhIGxpdHRsZSBiaXQg YmV5b25kIGp1c3QgYW4gQVBJLg0KPg0KPllvdSBzaG91bGQgYWxzbyBjb25zaWRlciB0aGF0IHRo ZSBPcGVuQ2xvdWRNZXNoICh1bmRlciBHRUFOVCB1bWJyZWxsYSkgaXMgYW4gaW5pdGlhdGl2ZSB3 aXRoIHRoZSBpbnRlbnQgaXMgdG8gbWFrZSBjcm9zcy1zZXJ2aWNlIHNoYXJpbmcgdmVyeSBlYXN5 LiBUaGVzZSBzaGFyZXMgbWF5IGFsc28gYmUgc3luY2hyb25pemVkIGF1dG9tYXRpY2FsbHkuIEkg Y3VycmVudGx5IGhhdmUgbm8gZXZpZGVuY2UsIGhvd2V2ZXIsIHRoYXQgb3RoZXIgc29mdHdhcmUg cHJvdmlkZXJzIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBvd25jbG91ZCBhcmUgaW50ZXJlc3RlZCBp biBkZXZlbG9waW5nIHN1Y2ggc3RhbmRhcmQuIElmIHRoZXJlIGlzIG5vIGJvdHRvbSB1cCBpbnRl cmVzdCBmcm9tIHRoZSB1c2VycyB0aGVuIGl0IHdvbqGvdCBoYXBwZW4gKGluIG15IG9waW5pb24p Lg0KPg0KPldpdGggdGhlIGxpbmsgSSB3YW50ZWQgdG8gcG9pbnQgeW91IHRvIHRoZSBmYWN0IHRo YXQgd2hhdCB5b3UgZGlzY3VzcyBpbiB0aGlzIG1haWxpbmcgbGlzdCB3aWxsIGJlIGFsc28gZGlz Y3Vzc2VkIGF0IHRoZSB1cGNvbWluZyBDUzMgZXZlbnQgSSBsaW5rZWQgaW4uIFRoZSBpbnRlbnQg aXMgdG8gZG8gdGhpcyBkaXNjdXNzaW5nIHRvZ2V0aGVyIGJldHdlZW4gc2VydmljZSBwcm92aWRl cnMsIGRldmVsb3BlcnMgYW5kIHJlc2VhcmNoZXJzIHRvZ2V0aGVyIKGqIHNvIHRoYXQgaXQgZG9l cyBub3Qgb25seSBlbmQgdXAgYXMgYW4gYWNhZGVtaWMgZXhlcmNpc2UgYnV0IGJhY2tlZCB1cCBi eSBhIGNyaXRpY2FsIG1hc3MgaWYgdGhlcmUgaXMgc29tZSBwb3RlbnRpYWwgaW4gc3RhbmRhcmRp c2F0aW9uLCBhdCBsZWFzdCBpbiBvdXIgY29tbXVuaXR5LiBJIGhvcGUgdGhpcyBjb3VsZCBiZSBv ZiBpbnRlcmVzdCB0byBJRVRGIGNvbW11bml0eSwgYXMgbWVudGlvbmVkIG9uIHRoZSBwcm9ncmFt IHBhZ2UuDQo+DQo+U2VsZWN0ZWQgcGFwZXJzIHdpbGwgYmUgcHVibGlzaGVkIGluIEZHQ1MgYWZ0 ZXIgdGhlIGV2ZW50LCBzbyBwbGVhc2Ugc3RhbmQgYnksIG9yIGF0dGVuZCB0aGUgZXZlbnQgaWYg eW91IHdhbnQgdG8gYmUgcGFydCBvZiB0aGlzIGRpc2N1c3Npb24gaGVyZS4gQlRXLiB0aGUgYWJz dHJhY3Qgc3VibWlzc2lvbiBkZWFkbGluZSBpcyBwYXN0IGJ1dCBvbmUgZXhjZXB0aW9uYWxseSBn b29kIGNvbnRyaWJ1dGlvbiBjb3VsZCBzdGlsbCBwb3NzaWJseSBiZSBhY2NvbW1vZGF0ZWQgaWYg c3VibWl0dGVkIHJhcGlkbHkuDQo+DQo+SSB3b3VsZCBiZSBub25ldGhlbGVzcyBoYXBweSB0byBj b250aW51ZSBjb250cmlidXRpbmcgdG8gdGhlIGRpc2N1c3Npb24gaW4gdGhpcyBtYWlsaW5nIGxp c3QuDQo+DQo+QmVzdCByZWdhcmRzLA0KPg0KPkpha3ViIE1vc2NpY2tpDQo+DQo+LS0NCj4NCj4N Cj5SZWdhcmRzLA0KPkxpbmh1aQ0KPg0KPg0KPi0tLS0tLS0tLS0tLS0tDQo+RmVpIFNvbmcNCj4+ SGVsbG8sDQo+Pg0KPj5XaGF0IGtpbmQgb2Ygb3V0Y29tZSBhcmUgeW91IGxvb2tpbmcgZm9yIHdp dGggdGhpcyBhbmFseXNpcz8gU29tZSByZXNlYXJjaCBpbiB0aGlzIGFyZWEgaGFzIGFscmVhZHkg YmVlbiBkb25lIG9yIGlzIGJlaW5nIGRvbmUgYXMgd2Ugc3BlYWsNCj4+DQo+PmUuZy4gIkEgc3R1 ZHkgb2YgZGVsdGEtc3luYyBhbmQgb3RoZXIgb3B0aW1pc2F0aW9uIGluIEhUVFAvV2ViZGF2IHN5 bmNob25pc2F0aW9uIHByb3RvY29scyINCj4+DQo+PnNlZSAiVGVjaG5vbG9neSBhbmQgUmVzZWFy Y2giOg0KPj4NCj4+aHR0cDovL2NzMy5ldGh6LmNoL3Byb2dyYW0uaHRtbA0KPj4NCj4+SXQgd291 bGQgYmUgaW50ZXJlc3RpbmcgdG8gc2VlIGlmIHRoZXJlIGlzIGEgcG90ZW50aWFsIGZvciBjb2xs YWJvcmF0aW9uLiBPciBtYXliZSB3ZSBhbHJlYWR5IGhhdmUgc29tZSBpbmZvcm1hdGlvbiB5b3Ug YXJlIGxvb2tpbmcgZm9yLg0KPj4NCj4+QmVzdCByZWdhcmRzLA0KPj4NCj4+SmFrdWIgTW9zY2lj a2kNCj4+DQo+PqGqDQo+Pg0KPj4NCj4+T24gMjUgTm92IDIwMTUsIGF0IDExOjQ1LCBMaW5odWkg U3VuIDxsaC5zdW5saW5oQGdtYWlsLmNvbTxtYWlsdG86bGguc3VubGluaEBnbWFpbC5jb20+PG1h aWx0bzpsaC5zdW5saW5oQGdtYWlsLmNvbTxtYWlsdG86bGguc3VubGluaEBnbWFpbC5jb20+Pj4g d3JvdGU6DQo+Pg0KPj5IaSBhbGwsDQo+Pg0KPj5BcyBJIG1lbnRpb25lZCBiZWZvcmUsIEkgdGhp bmsgdGhlIGRldmVsb3BlcnMgY291bGQgYmVuZWZpdCBmcm9tIHRoZSBJRVRGIHN0YW5kYXJkcy4g VGhlIG93bkNsb3VkIChodHRwczovL293bmNsb3VkLm9yZy8pIGlzIGp1c3QgYW4gZXhhbXBsZS4g SXQgaXMgZGV2ZWxvcGVkIGZvciB0aG9zZSB3aG8gZG8gbm90IHRydXN0IGNvbW1lcmNpYWwgc3Rv cmFnZSBzZXJ2aWNlcyBhbmQgd2FudCB0byBidWlsZCB0aGVpciBvd24gbmV0d29yay1iYXNlZCBz dG9yYWdlIHNlcnZpY2VzLiBUaGUgb3duQ2xvdWQgaXMgdXNpbmcgV2ViREFWIChSRkM0OTE4KSB0 byBhY2hpZXZlIHRoZSBkYXRhIHN5bmMuIElNTywgdGhlIFdlYkRBViBpcyBkZXNpZ25lZCBmb3Ig ZGlzdHJpYnV0ZWQgd29yayBidXQgbm90IGZvciB0aGUgc3luYy4gVGh1cywgSSBtYWRlIHNvbWUg cHJlbGltaW5hcnkgaW52ZXN0aWdhdGlvbnMgb24gaG93IHRoZSBvd25DbG91ZCB1c2VzIFdlYkRB ViBmb3Igc3luYyBwdXJwb3Nlcy4gQSBicmllZiBzdW1tYXJ5IG9mIHdoYXQgSSd2ZSBmb3VuZCBp cyBpbiB0aGUgZm9sbG93aW5nLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLg0KPj4N Cj4+SSBpbnN0YWxsZWQgdGhlIG93bkNsb3VkIHNlcnZlciAodjguMi4xKSBvbiB0aGUgQ2VudE9T NywgYW5kIHRoZSBjbGllbnQgaXMgYSBkZXNrdG9wIGNsaWVudCBvbiBXaW5kb3dzLg0KPj4NCj4+ MS4gVG8gZmluZCB3aGV0aGVyIHRoZXJlIGlzIGEgY2hhbmdlIHRvIHRoZSBzeW5jZWQgZGlyZWN0 b3J5LCB0aGUgY2xpZW50IGNvbnRpbnVvdXNseSBzZW5kcyBQUk9QRklORCB0byB0aGUgc2VydmVy IGF0IHJlZ3VsYXIgaW50ZXJ2YWxzIChhcm91bmQgMzQgc2Vjb25kcyB1bmRlciBteSBvYnNlcnZh dGlvbikuIFRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIGEgMjA3IE11bHRpLVN0YXR1cyBSZXNwb25z ZSB0byB0ZWxsIHdoZXRoZXIgdGhlIG1haW4gZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQuIFRv IHBlcmZvcm0gdGhpcyByZWd1bGFyIGNoZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBU Q1AgY29ubmVjdGlvbiB0byBzZW5kIHRoZSBQUk9QRklORCwgdGhlIHNlcnZlciB3aWxsIGNsb3Nl IHRoZSBleGlzdGluZyBUQ1AgY29ubmVjdGlvbiBhZnRlciByZXNwb25kaW5nIHRoZSAyMDcgTXVs dGktU3RhdHVzIFJlc3BvbnNlLiBGb3IgdGhlIG5leHQgY2hlY2ssIHRoZSBjbGllbnQgd2lsbCBv cGVuIGFub3RoZXIgbmV3IFRDUCBjb25uZWN0aW9uLg0KPj4NCj4+Mi4gRXZlcnkgdGltZSBhZGRp bmcgKG9yIGNyZWF0aW5nKSBhIG5ldyBmaWxlIHRvIHRoZSBsb2NhbCBmb2xkZXIsIHRoZSBjbGll bnQgd2lsbCBvcGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIChpZiB0aGVyZSBpcyBubyBjb25uZWN0 aW9uIGV4aXN0aW5nKSB0byBzZW5kIHRoZSBmaWxlIGFzYXAuIFRoZSBjbGllbnQgd2lsbCBmaXJz dCBzZW5kIHNldmVyYWwgUFJPUEZJTkRzIHRvIGZpbmQgb3V0IHdoaWNoIHN1Yi1kaXJlY3Rvcnkg aGFzIGJlZW4gY2hhbmdlZC4gQW5kIHRoZW4gaXQgc2VuZHMgdGhlIGZpbGUgdXNpbmcgUFVULiBU aGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwMSBDcmVhdGVkIFJlc3BvbnNlIGFuZCB0aGVuIHRl cm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4gQ3VycmVudGx5LCBJIGhhdmVuJ3QgZm91bmQgYW55IGFw cGxpY2F0aW9uIGxheWVyIGNodW5raW5nLCBhbGwgdGhlIHNlZ21lbnRhdGlvbiBhcmUgcGVyZm9y bWVkIGJ5IFRDUC4NCj4+DQo+PjMuIEV2ZXJ5IHRpbWUgSSBkZWxldGUgKG9yIHJlbmFtZSkgYSBm aWxlIGxvY2FsbHksIHRoZSBjbGllbnQgd2lsbCBhbHNvIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rp b24gdG8gc2VuZCBzZXZlcmFsIFBST1BGSU5EcyB0byBmaW5kIG91dCB3aGljaCBmaWxlIGhhcyBi ZWVuIHJlbW92ZWQgKG9yIHJlbmFtZWQpLiBUaGVuIGl0IHdpbGwgc2VuZCBERUxFVEUgKG9yIE1P VkUpLiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIwNCBObyBDb250ZW50IFJlc3BvbnNlIChv ciAyMDEgQ3JlYXRlZCBSZXNwb25zZSkgYW5kIHRoZW4gdGVybWluYXRlIHRoZSBjb25uZWN0aW9u Lg0KPj4NCj4+NC4gSSBvcGVuIGEgZmlsZSBhbmQgZnJlcXVlbnRseSBlZGl0IGFuZCBzYXZlIGl0 IChhY3R1YWxseSB0aGlzIGlzIHdoYXQgSSB1c3VhbGx5IGRvIHdpdGggdGhlIERyb3Bib3gpLiBU aGUgY2xpZW50IHdpbGwgc2VuZCB0aGUgd2hvbGUgZmlsZSB0byB0aGUgc2VydmVyIGV2ZXJ5IHRp bWUgSSBzYXZlIHRoZSBmaWxlLg0KPj4NCj4+VG8gc3VtbWFyaXplLCBpdCBzZWVtcyB0aGF0IHRo ZSBvd25DbG91ZCBtYWtlcyBoZWF2aWx5IHVzZSBvZiBQUk9QRklORCB0byBhY2hpZXZlIHRoZSBz eW5jIHByb2Nlc3MuIEVhY2ggc3luYyBvcGVyYXRpb24gKGUuZy4gdXBsb2FkLCBtb2RpZnkgYW5k IGV0Yy4pIHdpbGwgc3RhcnQgd2l0aCBzZW5kaW5nIG9uZSBvciBtb3JlIFBST1BGSU5Ecy4gQW5k IGN1cnJlbnRseSwgaWYgSSBhZGQgYSBmaWxlIHRvIHRoZSBzZXJ2ZXIgKGRpcmVjdGx5IGZyb20g dGhlIHNlcnZlciBzaWRlIHZpYSB3ZWIgaW50ZXJmYWNlKSwgdGhlIGNsaWVudCBjYW5ub3QgZmlu ZCB0aGUgY2hhbmdlLiBJIG5lZWQgdG8gaW50ZXJydXB0IHRoZSBzeW5jIGFuZCByZWNvdmVyIGl0 IHRvIG1ha2UgdGhlIGNsaWVudCBiZSBhd2FyZSBvZiB0aGUgY2hhbmdlIGFuZCBkb3dubG9hZCB0 aGUgbmV3bHkgYWRkZWQgZmlsZS4gSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBpcyBjYXVzZWQg YnkgdGhlIHN5bmMgbWVjaGFuaXNtIG9yIGFuIGltcHJvcGVyIHNlcnZlciBjb25maWd1cmF0aW9u LiBJIG5lZWQgdG8gaW52ZXN0aWdhdGUgdGhpcyBmdXJ0aGVyIGFuZCBhbHNvIGhvdyB0aGUgb3du Q2xvdWQgd29ya3MgZm9yIG11bHRpcGxlIGNsaWVudHMgKG9yIGRldmljZXMpLg0KPj4NCj4+Rm9y IElTUywgSSB0aGluayBvd25DbG91ZCBoYXMgZGVtb25zdHJhdGVkIHRvIHNvbWUgZXh0ZW50IHRo YXQgc2ltaWxhciBJRVRGIHByb3RvY29scyBjb3VsZCBiZSBkZXBsb3llZCBhbmQgZW1wbG95ZWQu IFRoZSBpbnRlbnRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHRvIGludmVzdGlnYXRlIHRoZSBjdXJy ZW50IHN0YXRlIG9mIHVzaW5nIFdlYkRBViBmb3Igc3luYyBwdXJwb3NlcyB0byBzZWUgd2hhdCBu ZWVkcyB0byBiZSBpbXByb3ZlZCBoZXJlIGFuZCB3aGV0aGVyIHdlIG5lZWQgbmV3IHByb3RvY29s cy4NCj4+DQo+PkNvbW1lbnRzIGFyZSB3ZWxjb21lIDogKQ0KPj4NCj4+UmVnYXJkcywNCj4+TGlu aHVpDQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+U3RvcmFnZXN5bmMgbWFpbGluZyBsaXN0DQo+PlN0b3JhZ2VzeW5jQGlldGYub3Jn PG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZz48bWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYub3Jn PG1haWx0bzpTdG9yYWdlc3luY0BpZXRmLm9yZz4+DQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMNCj4+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5TdG9yYWdlc3luYyBtYWlsaW5nIGxpc3QNCj5TdG9y YWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+DQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdG9yYWdlc3luYw0KPg0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5bmMgbWFp bGluZyBsaXN0DQo+U3RvcmFnZXN5bmNAaWV0Zi5vcmc8bWFpbHRvOlN0b3JhZ2VzeW5jQGlldGYu b3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFnZXN5bmMN Cj4= From nobody Thu Nov 26 00:21: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 45B061B2AF1 for ; Thu, 26 Nov 2015 00:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, 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 iPLSXDcrVROy for ; Thu, 26 Nov 2015 00:21:33 -0800 (PST) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id A8C7E1B36F3 for ; Thu, 26 Nov 2015 00:21:31 -0800 (PST) Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb2 (Coremail) with SMTP id M55wygCnfMiNwVZWSNPjAA--.23348S2; Thu, 26 Nov 2015 16:23:41 +0800 (CST) Date: Thu, 26 Nov 2015 16:21:26 +0800 From: "Fei Song" To: "Jakub Moscicki" , "Linhui Sun" References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> , <03A07C3E-9B3B-4886-9131-2CAF0A7B3F85@cern.ch> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2015112616212587598524@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: M55wygCnfMiNwVZWSNPjAA--.23348S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Ar47ur47Ar1kCF45ZF1UJrb_yoW3ZFy7pF W3Ka4xKF1kJr4xCwn7Jr1I9F10vrZ5JrW3Jrn8Jry8ArZ8WFyIqFyxtr4F9a4UGrZ3Gr1j qr40gFZxC3Z8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUym sjDUUUU 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: Thu, 26 Nov 2015 08:21:35 -0000 SGkgSmFrdWIsDQoNCg0KLS0tLS0tLS0tLS0tLS0NCkZlaSBTb25nDQo+MjAxNS0xMS0yNiAxMToy OCBHTVQrMDg6MDAgRmVpIFNvbmcgPGZzb25nQGJqdHUuZWR1LmNuPG1haWx0bzpmc29uZ0BianR1 LmVkdS5jbj4+Og0KPkJUVywgQmFzZWQgb24gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgbGFzdCBlbWFp bDoiVGhlIGludGVudGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgdG8gaW52ZXN0aWdhdGUgdGhlIGN1 cnJlbnQgc3RhdGUgb2YgdXNpbmcgV2ViREFWIGZvciBzeW5jIHB1cnBvc2VzIHRvIHNlZSB3aGF0 IG5lZWRzIHRvIGJlIGltcHJvdmVkIGhlcmUgYW5kIHdoZXRoZXIgd2UgbmVlZCBuZXcgcHJvdG9j b2xzIg0KPg0KPlRoZSBvdXRjb21lIGhlL3NoZSB3YW50ZWQgbWlnaHQgYmUganVzdCB0aGUgbGlu a3MgbGlrZSBodHRwOi8vY3MzLmV0aHouY2gvcHJvZ3JhbS5odG1sIDopDQo+SW4gYW5vdGhlciB3 b3JkLCBJIHRoaW5rIHdoYXQgSSB3YW50IGZpbmFsbHkgbWlnaHQgYmUgYSBkaXNjdXNzaW9uIGFi b3V0ICJXaGF0IGlzIG5lZWRlZCBmb3IgdGhlIElTUzogYSBzeW5jIHByb3RvY29sIG9yIGEgZ2Vu ZXJhbGl6ZWQgQVBJIi4gU29ycnkgZm9yIHRoZSBwb29yIGV4cHJlc3Npb24gOiApDQo+DQo+SSB0 aGluayB0aGlzIGlzIGEgcmVsZXZhbnQgcXVlc3Rpb24gaW5kZWVkICh3ZWxsLCBhY3R1YWxseSBh bHNvIGlmIHRoZXJlIGlzIGFueSBzdGFuZGFyZCBuZWVkZWQgYXQgYWxsIGluIHRoZSBmaXJzdCBw bGFjZSkuIEJ5IHRoZSBnZW5lcmFsaXplZCBBUEkgZG8geW91IG1lYW4gYSBIVFRQLXN0eWxlIEFQ SSAobGlrZSBSRVNUKT8gSW4gdGhhdCBjYXNlIHlvdSBtYXkgY29uc2lkZXIgV2ViREFWIHF1aXRl IGNsb3NlIGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBwcm90b2NvbCBhbmQgdGhlIEFQ SSBibHVycyBmb3IgcHJhY3RpY2FsIHB1cnBvc2VzLg0KPg0KPldoaWxlIEkgYWdyZWUgdGhhdCBX ZWJEQVYgbWF5IGhhdmUgZGlzYWR2YW50YWdlcyB0aGVyZSBpcyBhIGdvb2QgbnVtYmVyIG9mIGlu c3RhbGxhdGlvbnMgdXNpbmcgdGhpcyBhbHJlYWR5IGluIG91ciBjb21tdW5pdHkgKHJlc2VhcmNo IGxhYnMgbWFpbmx5IGluLCBidXQgbm90IGxpbWl0ZWQgdG8sIEV1cm9wZSkuIEkgdGhpbmsgdGhl IGludGVyZXN0aW5nIHBvaW50IGFib3V0IFdlYkRBVi9IVFRQIGlzIGV4dGVuc2liaWxpdHkgYW5k IG1heWJlIGl0IGlzIHdvcnRoIGlzIHRoYXQgdGhlc2UgZXh0ZW5zaW9ucyBnbyBieSBhIKGwc3Rh bmRhcmShsS4gSG93ZXZlciwgeW91IHNob3VsZCBjb25zaWRlciB0aGF0IGZvciByZWFzb25hYmx5 IGVmZmljaWVudCBzeW5jIHNjZW5hcmlvIHRoZSBzZXJ2ZXIgc2hvdWxkIGFsc28gZXhoaWJpdCBj ZXJ0YWluIGJlaGF2aW91ci4gVGhhdCBpcywgaW4gY2FzZSBvZiBvd25jbG91ZCBmb3IgZXhhbXBs ZSwgYSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gZWZmaWNpZW50bHkgcHJvcGFnYXRlIHRoZSBF VEFHIGNoYW5nZXMgdXAgdGhlIGRpcmVjdG9yeSB0cmVlIChsaWtlIHRoZSBNZXJrbGUgVHJlZSkg c28gdGhhdCB0aGUgY2xpZW50IG1heSB1c2UgcHJvcGZpbmQgZWZmaWNpZW50bHkuIFRoaXMgaXMg bm90IGEgaGFyZCBzcGVjIHJlcXVpcmVtZW50IGJ1dCBvdGhlcndpc2UgcHJvcGZpbmRpbmcgdGhl IGVudGlyZSByZW1vdGUgdHJlZSBlYWNoIHRpbWUgd291bGQgYmUgaW1wcmFjdGljYWxseSBpbmVm ZmljaWVudC4gU28gdGhpcyByZWFsbHkgZ29lcyBhIGxpdHRsZSBiaXQgYmV5b25kIGp1c3QgYW4g QVBJLg0KDQorMSwgSnVzdCBsaWtlIEkgc2VudCB0byB0aGUgbWFpbGluZyBsaXN0IGJlZm9yZSwg V2ViREFWIGlzIGEgZ3JlYXQgc29sdXRpb24uIEhvd2V2ZXIsIGEgYmV0dGVyIG9uZSBtaWdodCBi ZSBtb3JlIGJlbmVmaWNpYWwgZm9yIHRoZSBjb21tdW5pdHkuDQoNCj4NCj5Zb3Ugc2hvdWxkIGFs c28gY29uc2lkZXIgdGhhdCB0aGUgT3BlbkNsb3VkTWVzaCAodW5kZXIgR0VBTlQgdW1icmVsbGEp IGlzIGFuIGluaXRpYXRpdmUgd2l0aCB0aGUgaW50ZW50IGlzIHRvIG1ha2UgY3Jvc3Mtc2Vydmlj ZSBzaGFyaW5nIHZlcnkgZWFzeS4gVGhlc2Ugc2hhcmVzIG1heSBhbHNvIGJlIHN5bmNocm9uaXpl ZCBhdXRvbWF0aWNhbGx5LiBJIGN1cnJlbnRseSBoYXZlIG5vIGV2aWRlbmNlLCBob3dldmVyLCB0 aGF0IG90aGVyIHNvZnR3YXJlIHByb3ZpZGVycyB3aXRoIHRoZSBleGNlcHRpb24gb2Ygb3duY2xv dWQgYXJlIGludGVyZXN0ZWQgaW4gZGV2ZWxvcGluZyBzdWNoIHN0YW5kYXJkLiBJZiB0aGVyZSBp cyBubyBib3R0b20gdXAgaW50ZXJlc3QgZnJvbSB0aGUgdXNlcnMgdGhlbiBpdCB3b26hr3QgaGFw cGVuIChpbiBteSBvcGluaW9uKS4NCg0KVGhlIHRlcm0gInN0YW5kYXJkIiB5b3UgbWVudGlvbmVk IGluICJzb2Z0d2FyZSBwcm92aWRlcnMgYXJlIGludGVyZXN0ZWQgaW4gZGV2ZWxvcGluZyBzdWNo IHN0YW5kYXJkIiBtZWFucyBhIHByb3RvY29sIG9yIG90aGVyIHRoaW5ncz8NCg0KPg0KPldpdGgg dGhlIGxpbmsgSSB3YW50ZWQgdG8gcG9pbnQgeW91IHRvIHRoZSBmYWN0IHRoYXQgd2hhdCB5b3Ug ZGlzY3VzcyBpbiB0aGlzIG1haWxpbmcgbGlzdCB3aWxsIGJlIGFsc28gZGlzY3Vzc2VkIGF0IHRo ZSB1cGNvbWluZyBDUzMgZXZlbnQgSSBsaW5rZWQgaW4uIFRoZSBpbnRlbnQgaXMgdG8gZG8gdGhp cyBkaXNjdXNzaW5nIHRvZ2V0aGVyIGJldHdlZW4gc2VydmljZSBwcm92aWRlcnMsIGRldmVsb3Bl cnMgYW5kIHJlc2VhcmNoZXJzIHRvZ2V0aGVyIKGqIHNvIHRoYXQgaXQgZG9lcyBub3Qgb25seSBl bmQgdXAgYXMgYW4gYWNhZGVtaWMgZXhlcmNpc2UgYnV0IGJhY2tlZCB1cCBieSBhIGNyaXRpY2Fs IG1hc3MgaWYgdGhlcmUgaXMgc29tZSBwb3RlbnRpYWwgaW4gc3RhbmRhcmRpc2F0aW9uLCBhdCBs ZWFzdCBpbiBvdXIgY29tbXVuaXR5LiBJIGhvcGUgdGhpcyBjb3VsZCBiZSBvZiBpbnRlcmVzdCB0 byBJRVRGIGNvbW11bml0eSwgYXMgbWVudGlvbmVkIG9uIHRoZSBwcm9ncmFtIHBhZ2UuDQoNCk1h bnkgdGhhbmtzIGZvciB5b3VyIGluZm9ybWF0aW9uLiBJdCBpcyBncmVhdCB0byBzZWUgdGhlIHBh cmFsbGVsIGRpc2N1c3Npb25zIGluIENTMy4NCg0KPg0KPlNlbGVjdGVkIHBhcGVycyB3aWxsIGJl IHB1Ymxpc2hlZCBpbiBGR0NTIGFmdGVyIHRoZSBldmVudCwgc28gcGxlYXNlIHN0YW5kIGJ5LCBv ciBhdHRlbmQgdGhlIGV2ZW50IGlmIHlvdSB3YW50IHRvIGJlIHBhcnQgb2YgdGhpcyBkaXNjdXNz aW9uIGhlcmUuIEJUVy4gdGhlIGFic3RyYWN0IHN1Ym1pc3Npb24gZGVhZGxpbmUgaXMgcGFzdCBi dXQgb25lIGV4Y2VwdGlvbmFsbHkgZ29vZCBjb250cmlidXRpb24gY291bGQgc3RpbGwgcG9zc2li bHkgYmUgYWNjb21tb2RhdGVkIGlmIHN1Ym1pdHRlZCByYXBpZGx5Lg0KPg0KPkkgd291bGQgYmUg bm9uZXRoZWxlc3MgaGFwcHkgdG8gY29udGludWUgY29udHJpYnV0aW5nIHRvIHRoZSBkaXNjdXNz aW9uIGluIHRoaXMgbWFpbGluZyBsaXN0Lg0KPg0KPkJlc3QgcmVnYXJkcywNCj4NCj5KYWt1YiBN b3NjaWNraQ0KPg0KPi0tDQo+DQo+DQo+UmVnYXJkcywNCj5MaW5odWkNCj4NCj4NCj4tLS0tLS0t LS0tLS0tLQ0KPkZlaSBTb25nDQo+PkhlbGxvLA0KPj4NCj4+V2hhdCBraW5kIG9mIG91dGNvbWUg YXJlIHlvdSBsb29raW5nIGZvciB3aXRoIHRoaXMgYW5hbHlzaXM/IFNvbWUgcmVzZWFyY2ggaW4g dGhpcyBhcmVhIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBvciBpcyBiZWluZyBkb25lIGFzIHdlIHNw ZWFrDQo+Pg0KPj5lLmcuICJBIHN0dWR5IG9mIGRlbHRhLXN5bmMgYW5kIG90aGVyIG9wdGltaXNh dGlvbiBpbiBIVFRQL1dlYmRhdiBzeW5jaG9uaXNhdGlvbiBwcm90b2NvbHMiDQo+Pg0KPj5zZWUg IlRlY2hub2xvZ3kgYW5kIFJlc2VhcmNoIjoNCj4+DQo+Pmh0dHA6Ly9jczMuZXRoei5jaC9wcm9n cmFtLmh0bWwNCj4+DQo+Pkl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIHNlZSBpZiB0aGVyZSBp cyBhIHBvdGVudGlhbCBmb3IgY29sbGFib3JhdGlvbi4gT3IgbWF5YmUgd2UgYWxyZWFkeSBoYXZl IHNvbWUgaW5mb3JtYXRpb24geW91IGFyZSBsb29raW5nIGZvci4NCj4+DQo+PkJlc3QgcmVnYXJk cywNCj4+DQo+Pkpha3ViIE1vc2NpY2tpDQo+Pg0KPj6hqg0KPj4NCj4+DQo+Pk9uIDI1IE5vdiAy MDE1LCBhdCAxMTo0NSwgTGluaHVpIFN1biA8bGguc3VubGluaEBnbWFpbC5jb208bWFpbHRvOmxo LnN1bmxpbmhAZ21haWwuY29tPjxtYWlsdG86bGguc3VubGluaEBnbWFpbC5jb208bWFpbHRvOmxo LnN1bmxpbmhAZ21haWwuY29tPj4+IHdyb3RlOg0KPj4NCj4+SGkgYWxsLA0KPj4NCj4+QXMgSSBt ZW50aW9uZWQgYmVmb3JlLCBJIHRoaW5rIHRoZSBkZXZlbG9wZXJzIGNvdWxkIGJlbmVmaXQgZnJv bSB0aGUgSUVURiBzdGFuZGFyZHMuIFRoZSBvd25DbG91ZCAoaHR0cHM6Ly9vd25jbG91ZC5vcmcv KSBpcyBqdXN0IGFuIGV4YW1wbGUuIEl0IGlzIGRldmVsb3BlZCBmb3IgdGhvc2Ugd2hvIGRvIG5v dCB0cnVzdCBjb21tZXJjaWFsIHN0b3JhZ2Ugc2VydmljZXMgYW5kIHdhbnQgdG8gYnVpbGQgdGhl aXIgb3duIG5ldHdvcmstYmFzZWQgc3RvcmFnZSBzZXJ2aWNlcy4gVGhlIG93bkNsb3VkIGlzIHVz aW5nIFdlYkRBViAoUkZDNDkxOCkgdG8gYWNoaWV2ZSB0aGUgZGF0YSBzeW5jLiBJTU8sIHRoZSBX ZWJEQVYgaXMgZGVzaWduZWQgZm9yIGRpc3RyaWJ1dGVkIHdvcmsgYnV0IG5vdCBmb3IgdGhlIHN5 bmMuIFRodXMsIEkgbWFkZSBzb21lIHByZWxpbWluYXJ5IGludmVzdGlnYXRpb25zIG9uIGhvdyB0 aGUgb3duQ2xvdWQgdXNlcyBXZWJEQVYgZm9yIHN5bmMgcHVycG9zZXMuIEEgYnJpZWYgc3VtbWFy eSBvZiB3aGF0IEkndmUgZm91bmQgaXMgaW4gdGhlIGZvbGxvd2luZywgcGxlYXNlIGNvcnJlY3Qg bWUgaWYgSSBhbSB3cm9uZy4NCj4+DQo+PkkgaW5zdGFsbGVkIHRoZSBvd25DbG91ZCBzZXJ2ZXIg KHY4LjIuMSkgb24gdGhlIENlbnRPUzcsIGFuZCB0aGUgY2xpZW50IGlzIGEgZGVza3RvcCBjbGll bnQgb24gV2luZG93cy4NCj4+DQo+PjEuIFRvIGZpbmQgd2hldGhlciB0aGVyZSBpcyBhIGNoYW5n ZSB0byB0aGUgc3luY2VkIGRpcmVjdG9yeSwgdGhlIGNsaWVudCBjb250aW51b3VzbHkgc2VuZHMg UFJPUEZJTkQgdG8gdGhlIHNlcnZlciBhdCByZWd1bGFyIGludGVydmFscyAoYXJvdW5kIDM0IHNl Y29uZHMgdW5kZXIgbXkgb2JzZXJ2YXRpb24pLiBUaGUgc2VydmVyIHdpbGwgcmVzcG9uZCBhIDIw NyBNdWx0aS1TdGF0dXMgUmVzcG9uc2UgdG8gdGVsbCB3aGV0aGVyIHRoZSBtYWluIGRpcmVjdG9y eSBoYXMgYmVlbiBjaGFuZ2VkLiBUbyBwZXJmb3JtIHRoaXMgcmVndWxhciBjaGVjaywgdGhlIGNs aWVudCB3aWxsIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gdG8gc2VuZCB0aGUgUFJPUEZJTkQs IHRoZSBzZXJ2ZXIgd2lsbCBjbG9zZSB0aGUgZXhpc3RpbmcgVENQIGNvbm5lY3Rpb24gYWZ0ZXIg cmVzcG9uZGluZyB0aGUgMjA3IE11bHRpLVN0YXR1cyBSZXNwb25zZS4gRm9yIHRoZSBuZXh0IGNo ZWNrLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhbm90aGVyIG5ldyBUQ1AgY29ubmVjdGlvbi4NCj4+ DQo+PjIuIEV2ZXJ5IHRpbWUgYWRkaW5nIChvciBjcmVhdGluZykgYSBuZXcgZmlsZSB0byB0aGUg bG9jYWwgZm9sZGVyLCB0aGUgY2xpZW50IHdpbGwgb3BlbiBhIG5ldyBUQ1AgY29ubmVjdGlvbiAo aWYgdGhlcmUgaXMgbm8gY29ubmVjdGlvbiBleGlzdGluZykgdG8gc2VuZCB0aGUgZmlsZSBhc2Fw LiBUaGUgY2xpZW50IHdpbGwgZmlyc3Qgc2VuZCBzZXZlcmFsIFBST1BGSU5EcyB0byBmaW5kIG91 dCB3aGljaCBzdWItZGlyZWN0b3J5IGhhcyBiZWVuIGNoYW5nZWQuIEFuZCB0aGVuIGl0IHNlbmRz IHRoZSBmaWxlIHVzaW5nIFBVVC4gVGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDEgQ3JlYXRl ZCBSZXNwb25zZSBhbmQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24uIEN1cnJlbnRseSwg SSBoYXZlbid0IGZvdW5kIGFueSBhcHBsaWNhdGlvbiBsYXllciBjaHVua2luZywgYWxsIHRoZSBz ZWdtZW50YXRpb24gYXJlIHBlcmZvcm1lZCBieSBUQ1AuDQo+Pg0KPj4zLiBFdmVyeSB0aW1lIEkg ZGVsZXRlIChvciByZW5hbWUpIGEgZmlsZSBsb2NhbGx5LCB0aGUgY2xpZW50IHdpbGwgYWxzbyBv cGVuIGEgbmV3IFRDUCBjb25uZWN0aW9uIHRvIHNlbmQgc2V2ZXJhbCBQUk9QRklORHMgdG8gZmlu ZCBvdXQgd2hpY2ggZmlsZSBoYXMgYmVlbiByZW1vdmVkIChvciByZW5hbWVkKS4gVGhlbiBpdCB3 aWxsIHNlbmQgREVMRVRFIChvciBNT1ZFKS4gVGhlIHNlcnZlciB3aWxsIHJlc3BvbmQgYSAyMDQg Tm8gQ29udGVudCBSZXNwb25zZSAob3IgMjAxIENyZWF0ZWQgUmVzcG9uc2UpIGFuZCB0aGVuIHRl cm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4NCj4+DQo+PjQuIEkgb3BlbiBhIGZpbGUgYW5kIGZyZXF1 ZW50bHkgZWRpdCBhbmQgc2F2ZSBpdCAoYWN0dWFsbHkgdGhpcyBpcyB3aGF0IEkgdXN1YWxseSBk byB3aXRoIHRoZSBEcm9wYm94KS4gVGhlIGNsaWVudCB3aWxsIHNlbmQgdGhlIHdob2xlIGZpbGUg dG8gdGhlIHNlcnZlciBldmVyeSB0aW1lIEkgc2F2ZSB0aGUgZmlsZS4NCj4+DQo+PlRvIHN1bW1h cml6ZSwgaXQgc2VlbXMgdGhhdCB0aGUgb3duQ2xvdWQgbWFrZXMgaGVhdmlseSB1c2Ugb2YgUFJP UEZJTkQgdG8gYWNoaWV2ZSB0aGUgc3luYyBwcm9jZXNzLiBFYWNoIHN5bmMgb3BlcmF0aW9uIChl LmcuIHVwbG9hZCwgbW9kaWZ5IGFuZCBldGMuKSB3aWxsIHN0YXJ0IHdpdGggc2VuZGluZyBvbmUg b3IgbW9yZSBQUk9QRklORHMuIEFuZCBjdXJyZW50bHksIGlmIEkgYWRkIGEgZmlsZSB0byB0aGUg c2VydmVyIChkaXJlY3RseSBmcm9tIHRoZSBzZXJ2ZXIgc2lkZSB2aWEgd2ViIGludGVyZmFjZSks IHRoZSBjbGllbnQgY2Fubm90IGZpbmQgdGhlIGNoYW5nZS4gSSBuZWVkIHRvIGludGVycnVwdCB0 aGUgc3luYyBhbmQgcmVjb3ZlciBpdCB0byBtYWtlIHRoZSBjbGllbnQgYmUgYXdhcmUgb2YgdGhl IGNoYW5nZSBhbmQgZG93bmxvYWQgdGhlIG5ld2x5IGFkZGVkIGZpbGUuIEknbSBub3Qgc3VyZSB3 aGV0aGVyIHRoaXMgaXMgY2F1c2VkIGJ5IHRoZSBzeW5jIG1lY2hhbmlzbSBvciBhbiBpbXByb3Bl ciBzZXJ2ZXIgY29uZmlndXJhdGlvbi4gSSBuZWVkIHRvIGludmVzdGlnYXRlIHRoaXMgZnVydGhl ciBhbmQgYWxzbyBob3cgdGhlIG93bkNsb3VkIHdvcmtzIGZvciBtdWx0aXBsZSBjbGllbnRzIChv ciBkZXZpY2VzKS4NCj4+DQo+PkZvciBJU1MsIEkgdGhpbmsgb3duQ2xvdWQgaGFzIGRlbW9uc3Ry YXRlZCB0byBzb21lIGV4dGVudCB0aGF0IHNpbWlsYXIgSUVURiBwcm90b2NvbHMgY291bGQgYmUg ZGVwbG95ZWQgYW5kIGVtcGxveWVkLiBUaGUgaW50ZW50aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyB0 byBpbnZlc3RpZ2F0ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB1c2luZyBXZWJEQVYgZm9yIHN5bmMg cHVycG9zZXMgdG8gc2VlIHdoYXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQgaGVyZSBhbmQgd2hldGhl ciB3ZSBuZWVkIG5ldyBwcm90b2NvbHMuDQo+Pg0KPj5Db21tZW50cyBhcmUgd2VsY29tZSA6ICkN Cj4+DQo+PlJlZ2FyZHMsDQo+Pkxpbmh1aQ0KPj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PlN0b3JhZ2VzeW5jIG1haWxpbmcgbGlzdA0K Pj5TdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+PG1haWx0 bzpTdG9yYWdlc3luY0BpZXRmLm9yZzxtYWlsdG86U3RvcmFnZXN5bmNAaWV0Zi5vcmc+Pg0KPj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0b3JhZ2VzeW5jDQo+Pg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U3RvcmFnZXN5 bmMgbWFpbGluZyBsaXN0DQo+U3RvcmFnZXN5bmNAaWV0Zi5vcmc8bWFpbHRvOlN0b3JhZ2VzeW5j QGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RvcmFn ZXN5bmMNCj4NCj4= From nobody Thu Nov 26 01:38: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 910D41B381F for ; Thu, 26 Nov 2015 01:38:29 -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 qlZk0Kre9I11 for ; Thu, 26 Nov 2015 01:38:26 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 78D161B381E for ; Thu, 26 Nov 2015 01:38:25 -0800 (PST) Received: by wmww144 with SMTP id w144so14666662wmw.0 for ; Thu, 26 Nov 2015 01:38:24 -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=YCdVlguhUmdUyNsAR+P8Xk5Vvhd4KpMjpk5/3ZzseB4=; b=brfYSDmGysUQ64XVBl6dqKPMjrRsLChQw8VjjBU68HYl/OMEU69lx186Ave1vBREUO kgd9ZrBmkQvG/s20XNh/kl1FtmGpcB8sMmKdc5KF972AQMCA1rniRZTUtGkt4Qn8bViM 0VOfWF+KKbN+sHItXlVdRLISoHcSOaH/uzJAk6+xllChS9go7y46RqNxqYcKXOKRb66w Jyibg7BxOTWSshiQk51/+4IuYqgywc2lzQ1JrX0HW6sjUm/GVMOUDKafTZk8pJagLbNY pXMnDKohzLDSLlje2uQ/+uH6kOXjT6i6HgRoD/5xU8gDT+pDW3QFU2w1BhxNJlPDFQ5C INDQ== X-Received: by 10.28.48.10 with SMTP id w10mr2398952wmw.39.1448530704006; Thu, 26 Nov 2015 01:38:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.147 with HTTP; Thu, 26 Nov 2015 01:38:04 -0800 (PST) In-Reply-To: <03A07C3E-9B3B-4886-9131-2CAF0A7B3F85@cern.ch> References: <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <03A07C3E-9B3B-4886-9131-2CAF0A7B3F85@cern.ch> From: Linhui Sun Date: Thu, 26 Nov 2015 17:38:04 +0800 Message-ID: To: Jakub Moscicki Content-Type: multipart/alternative; boundary=001a11422fa80f064005256e56b6 Archived-At: Cc: fsong , 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: Thu, 26 Nov 2015 09:38:29 -0000 --001a11422fa80f064005256e56b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-11-26 15:29 GMT+08:00 Jakub Moscicki : > 2015-11-26 11:28 GMT+08:00 Fei Song : > >> BTW, Based on the last sentence of last email:"The intention of this >> message is to investigate the current state of using WebDAV for sync >> purposes to see what needs to be improved here and whether we need new >> protocols" >> >> The outcome he/she wanted might be just the links like >> http://cs3.ethz.ch/program.html :) >> > In another word, I think what I want finally might be a discussion about > "What is needed for the ISS: a sync protocol or a generalized API". Sorry > for the poor expression : ) > > > I think this is a relevant question indeed (well, actually also if there > is any standard needed at all in the first place). By the generalized API > do you mean a HTTP-style API (like REST)? In that case you may consider > WebDAV quite close and the difference between the protocol and the API > blurs for practical purposes. > Yes. And maybe for the application layer applications, an API is more realistic and practical at the first stage? I'm not saying we should not standardize a sync protocol... > > While I agree that WebDAV may have disadvantages there is a good number o= f > installations using this already in our community (research labs mainly i= n, > but not limited to, Europe). I think the interesting point about > WebDAV/HTTP is extensibility and maybe it is worth is that these extensio= ns > go by a =E2=80=9Cstandard=E2=80=9D. However, you should consider that for > Actually I don't know what the "extensibility" means here, are you saying that we could extend the WebDAV? > reasonably efficient sync scenario the server should also exhibit certain > behaviour. That is, in case of owncloud for example, a server should be > able to efficiently propagate the ETAG changes up the directory tree (lik= e > the Merkle Tree) so that the client may use propfind efficiently. This is > not a hard spec requirement but otherwise propfinding the entire remote > tree each time would be impractically inefficient. So this really goes a > little bit beyond just an API. > And that is what I mean the "applicability", IMO, the WebDAV seems not suitable for sync purposes. As a result, the developers compromise to propfind the entire file tree at intervals. > > You should also consider that the OpenCloudMesh (under GEANT umbrella) is > an initiative with the intent is to make cross-service sharing very easy. > These shares may also be synchronized automatically. I currently have no > evidence, however, that other software providers with the exception of > owncloud are interested in developing such standard. If there is no botto= m > up interest from the users then it won=E2=80=99t happen (in my opinion). > That's cool. I'm just wondering whether the ISS could get some input from that... > > With the link I wanted to point you to the fact that what you discuss in > this mailing list will be also discussed at the upcoming CS3 event I link= ed > in. The intent is to do this discussing together between service provider= s, > developers and researchers together =E2=80=94 so that it does not only en= d up as an > academic exercise but backed up by a critical mass if there is some > potential in standardisation, at least in our community. I hope this coul= d > be of interest to IETF community, as mentioned on the program page. > > Selected papers will be published in FGCS after the event, so please stan= d > by, or attend the event if you want to be part of this discussion here. > BTW. the abstract submission deadline is past but one exceptionally good > contribution could still possibly be accommodated if submitted rapidly. > > I would be nonetheless happy to continue contributing to the discussion i= n > this mailing list. > Thanks for that! > > Best regards, > > Jakub Moscicki > > -- > > > > Regards, > Linhui > >> >> >> -------------- >> Fei Song >> >Hello, >> > >> >What kind of outcome are you looking for with this analysis? Some >> research in this area has already been done or is being done as we speak >> > >> >e.g. "A study of delta-sync and other optimisation in HTTP/Webdav >> synchonisation protocols" >> > >> >see "Technology and Research": >> > >> >http://cs3.ethz.ch/program.html >> > >> >It would be interesting to see if there is a potential for >> collaboration. Or maybe we already have some information you are looking >> for. >> > >> >Best regards, >> > >> >Jakub Moscicki >> > >> >=E2=80=94 >> > >> > >> >On 25 Nov 2015, at 11:45, Linhui Sun > lh.sunlinh@gmail.com>> wrote: >> > >> >Hi all, >> > >> >As I mentioned before, I think the developers could benefit from the >> IETF standards. The ownCloud (https://owncloud.org/) is just an example. >> It is developed for those who do not trust commercial storage services a= nd >> want to build their own network-based storage services. The ownCloud is >> using WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is >> designed for distributed work but not for the sync. Thus, I made some >> preliminary investigations on how the ownCloud uses WebDAV for sync >> purposes. A brief summary of what I've found is in the following, please >> correct me if I am wrong. >> > >> >I installed the ownCloud server (v8.2.1) on the CentOS7, and the client >> is a desktop client on Windows. >> > >> >1. To find whether there is a change to the synced directory, the clien= t >> continuously sends PROPFIND to the server at regular intervals (around 3= 4 >> seconds under my observation). The server will respond a 207 Multi-Statu= s >> Response to tell whether the main directory has been changed. To perform >> this regular check, the client will open a new TCP connection to send th= e >> PROPFIND, the server will close the existing TCP connection after >> responding the 207 Multi-Status Response. For the next check, the client >> will open another new TCP connection. >> > >> >2. Every time adding (or creating) a new file to the local folder, the >> client will open a new TCP connection (if there is no connection existin= g) >> to send the file asap. The client will first send several PROPFINDs to f= ind >> out which sub-directory has been changed. And then it sends the file usi= ng >> PUT. The server will respond a 201 Created Response and then terminate t= he >> connection. Currently, I haven't found any application layer chunking, a= ll >> the segmentation are performed by TCP. >> > >> >3. Every time I delete (or rename) a file locally, the client will also >> open a new TCP connection to send several PROPFINDs to find out which fi= le >> has been removed (or renamed). Then it will send DELETE (or MOVE). The >> server will respond a 204 No Content Response (or 201 Created Response) = and >> then terminate the connection. >> > >> >4. I open a file and frequently edit and save it (actually this is what >> I usually do with the Dropbox). The client will send the whole file to t= he >> server every time I save the file. >> > >> >To summarize, it seems that the ownCloud makes heavily use of PROPFIND >> to achieve the sync process. Each sync operation (e.g. upload, modify an= d >> etc.) will start with sending one or more PROPFINDs. And currently, if I >> add a file to the server (directly from the server side via web interfac= e), >> the client cannot find the change. I need to interrupt the sync and reco= ver >> it to make the client be aware of the change and download the newly adde= d >> file. I'm not sure whether this is caused by the sync mechanism or an >> improper server configuration. I need to investigate this further and al= so >> how the ownCloud works for multiple clients (or devices). >> > >> >For ISS, I think ownCloud has demonstrated to some extent that similar >> IETF protocols could be deployed and employed. The intention of this >> message is to investigate the current state of using WebDAV for sync >> purposes to see what needs to be improved here and whether we need new >> protocols. >> > >> >Comments are welcome : ) >> > >> >Regards, >> >Linhui >> > >> > >> >_______________________________________________ >> >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 >> > > > --001a11422fa80f064005256e56b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-11-26 15:29 GMT+08:00 Jakub Moscicki <Jakub.Moscicki@cern.ch= >:
2015-11-26 11:28 GMT+08:00 Fei Song <fsong@bjtu.edu.c= n>:
BTW, Based on the last sentence of last email:"The intention of this m= essage is to investigate the current state of using WebDAV for sync purpose= s to see what needs to be improved here and whether we need new protocols&q= uot;

The outcome he/she wanted might be just the links like http://cs3.ethz.ch/program.html :)
In another word, I think what I want finally might be a discussion abo= ut "What is needed for the ISS: a sync protocol or a generalized API&q= uot;. Sorry for the poor expression : )

 I think this is a relevant question indeed (well, actually also if there is= any standard needed at all in the first place). By the generalized API do = you mean a HTTP-style API (like REST)? In that case you may consider WebDAV= quite close and the difference between the protocol and the API blurs for practical purposes.=C2=A0
=
Yes. And maybe for the application layer applicatio= ns, an API is more realistic and practical at the first stage? I'm not = saying we should not standardize a sync protocol...

While I agree that WebDAV may have disadvantages there is a good numbe= r of installations using this already in our community (research labs mainl= y in, but not limited to, Europe). I think the interesting point about WebD= AV/HTTP is extensibility and maybe it is worth is that these extensions go by a =E2=80=9Cstandard=E2=80=9D. H= owever, you should consider that for
Actually = I don't know what the "extensibility" means here, are you say= ing that we could extend the WebDAV?=C2=A0
reasonably efficient sync sce= nario the server should also exhibit certain behaviour. That is, in case of= owncloud for example, a server should be able to efficiently propagate the ETAG changes up the directory tree (like the Merkle Tree) so= that the client may use propfind efficiently. This is not a hard spec requ= irement but otherwise propfinding the entire remote tree each time would be= impractically inefficient. So this really goes a little bit beyond just an API.
= And that is what I mean the "applicability", IMO, the WebDAV seem= s not suitable for sync purposes. As a result, the developers compromise to= propfind the entire file tree at intervals.

You should also consider that the OpenCloudMesh (under GEANT umbrella)= is an initiative with the intent is to make cross-service sharing very eas= y. These shares may also be synchronized automatically. I currently have no= evidence, however, that other software providers with the exception of owncloud are interested in developing such= standard. If there is no bottom up interest from the users then it won=E2= =80=99t happen (in my opinion).
That'= ;s cool. I'm just wondering whether the ISS could get some input from t= hat...=C2=A0

With the link I wanted to point you to the fact that what you discuss = in this mailing list will be also discussed at the upcoming CS3 event I lin= ked in. The intent is to do this discussing together between service provid= ers, developers and researchers together =E2=80=94 so that it does not only end up as an academic exercise= but backed up by a critical mass if there is some potential in standardisa= tion, at least in our community. I hope this could be of interest to IETF c= ommunity, as mentioned on the program page.

Selected papers will be published in FGCS after the event, so please s= tand by, or attend the event if you want to be part of this discussion here= . BTW. the abstract submission deadline is past but one exceptionally good = contribution could still possibly be accommodated if submitted rapidly.

I would be nonetheless happy to continue contributing to the discussio= n in this mailing list.
Thanks for that!=C2=A0=

Best regards,

Jakub Moscicki

--



Regards,
Linhui=C2=A0


--------------
Fei Song
>Hello,
>
>What kind of outcome are you looking for with this analysis? Some resea= rch in this area has already been done or is being done as we speak
>
>e.g. "A study of delta-sync and other optimisation in HTTP/Webdav = synchonisation protocols"
>
>see "Technology and Research":
>
>http://cs3.ethz.ch/program.html
>
>It would be interesting to see if there is a potential for collaboratio= n. Or maybe we already have some information you are looking for.
>
>Best regards,
>
>Jakub Moscicki
>
>=E2=80=94
>
>
>On 25 Nov 2015, at 11:45, Linhui Sun <lh.sunlinh@gmail.com<mailto= :lh.sunlinh@gmail= .com>> wrote:
>
>Hi all,
>
>As I mentioned before, I think the developers could benefit from the IE= TF standards. The ownCloud (https://owncloud.org/) is just an example. It i= s developed for those who do not trust commercial storage services and want to build their own network-base= d storage services. The ownCloud is using WebDAV (RFC4918) to achieve the d= ata sync. IMO, the WebDAV is designed for distributed work but not for the = sync. Thus, I made some preliminary investigations on how the ownCloud uses WebDAV for sync purposes. A brief = summary of what I've found is in the following, please correct me if I = am wrong.
>
>I installed the ownCloud server (v8.2.1) on the CentOS7, and the client= is a desktop client on Windows.
>
>1. To find whether there is a change to the synced directory, the clien= t continuously sends PROPFIND to the server at regular intervals (around 34= seconds under my observation). The server will respond a 207 Multi-Status = Response to tell whether the main directory has been changed. To perform this regular check, the client will open a ne= w TCP connection to send the PROPFIND, the server will close the existing T= CP connection after responding the 207 Multi-Status Response. For the next = check, the client will open another new TCP connection.
>
>2. Every time adding (or creating) a new file to the local folder, the = client will open a new TCP connection (if there is no connection existing) = to send the file asap. The client will first send several PROPFINDs to find= out which sub-directory has been changed. And then it sends the file using PUT. The server will respond a 201 Create= d Response and then terminate the connection. Currently, I haven't foun= d any application layer chunking, all the segmentation are performed by TCP= .
>
>3. Every time I delete (or rename) a file locally, the client will also= open a new TCP connection to send several PROPFINDs to find out which file= has been removed (or renamed). Then it will send DELETE (or MOVE). The ser= ver will respond a 204 No Content Response (or 201 Created Response) and then terminate the connection.
>
>4. I open a file and frequently edit and save it (actually this is what= I usually do with the Dropbox). The client will send the whole file to the= server every time I save the file.
>
>To summarize, it seems that the ownCloud makes heavily use of PROPFIND = to achieve the sync process. Each sync operation (e.g. upload, modify and e= tc.) will start with sending one or more PROPFINDs. And currently, if I add= a file to the server (directly from the server side via web interface), the client cannot find the change. I n= eed to interrupt the sync and recover it to make the client be aware of the= change and download the newly added file. I'm not sure whether this is= caused by the sync mechanism or an improper server configuration. I need to investigate this further and also= how the ownCloud works for multiple clients (or devices).
>
>For ISS, I think ownCloud has demonstrated to some extent that similar = IETF protocols could be deployed and employed. The intention of this messag= e is to investigate the current state of using WebDAV for sync purposes to = see what needs to be improved here and whether we need new protocols.
>
>Comments are welcome : )
>
>Regards,
>Linhui
>
>
>_______________________________________________
>Storagesync mailing list
>Storag= esync@ietf.org<mailto:Storagesync@ietf.org>
>https://www.ietf.org/mailman/listinfo/storagesy= nc
>
_______________________________________________
Storagesync mailing list
Storagesync@ietf.= org
https://www.ietf.org/mailman/listinfo/storagesync



--001a11422fa80f064005256e56b6-- From nobody Mon Nov 30 13:24: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 2A7431B35A1 for ; Mon, 30 Nov 2015 13:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 Wa5Kt6f86HCc for ; Mon, 30 Nov 2015 13:24:36 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 E46A21B352C for ; Mon, 30 Nov 2015 13:24:35 -0800 (PST) Received: by iofh3 with SMTP id h3so189539112iof.3 for ; Mon, 30 Nov 2015 13:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=InbWI4P17fa6dYO4Uyrkx2S1yvUrSLeD2PBFCbuJNTU=; b=0EDujx1iujfaF3aenKyiYzAuiSrZxfiV2kX8kVl/H3dkTIltCnehYOTQ8O5ZLIoJ3R 5fjERxF5J2TiSjRfi4RqoRnIQFrEs0DmXP6ZterIHhMAyt3AQxkrmAejkK1cOUdoGWhF E126KhrUIXk+NeExXxwAgkj/mpAMwyOWg5v9dQ6tXwrFTfidyIJeKDpHfimIQywNgvH9 nJ7qaFKLZbb244y2v3RYsFA6B6GnQq5mpdENANlsXns1rI5XbPkafC25ZyiI+0DmHNjL Lt+vHIOhn84NgVmJabKsPxGpv5VqOveeezRmLffY5B7soJ0q2GmQdKrPd4Taa6SdBe5l dqRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=InbWI4P17fa6dYO4Uyrkx2S1yvUrSLeD2PBFCbuJNTU=; b=Oce/v1vIPRY6QEEt8bR3XxfV0Ehko5KBnC8VU6zB2IafggXkoJ//loPWqThXQynLth 3PlJFylJNmH/HgATCJt62hShX6+Jpz/hACFavOe57fsYLoPbOE96I4fxBdrmyRn6eAdg 9Q71JzLrSMNIxWnsdXCYrThhTiKiZ/kcuQR6h+g5JGKDc8V+6YsXeYpQCsOcjW7k1jYh kVFJOGk123ZZxxJPPlyy8cnjGjVj45ko6/vDHrNS0xxD7Iv8z2uTetV7KuXp7N8wn3E8 iyAbas+chyxFZfmhwSCrvwvXttrteD9mInaMp5pnLX5IxA2RZon0hdsPzxAhP4YV5HKi U7sA== X-Gm-Message-State: ALoCoQm6QufcBSSPHDsoFFttJSJxMjLe6tt8aKXJh6ukTdPBQxhqxyKCp/HoXUSJ7wAv9KI1N+E9 MIME-Version: 1.0 X-Received: by 10.107.129.82 with SMTP id c79mr25991913iod.95.1448918675085; Mon, 30 Nov 2015 13:24:35 -0800 (PST) Received: by 10.107.137.68 with HTTP; Mon, 30 Nov 2015 13:24:35 -0800 (PST) Date: Mon, 30 Nov 2015 22:24:35 +0100 Message-ID: From: Michiel de Jong To: storagesync Content-Type: multipart/alternative; boundary=001a113f9b76f008890525c8aa51 Archived-At: Subject: [Storagesync] New version of draft-dejong-remotestorage Internet-Draft available 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, 30 Nov 2015 21:24:39 -0000 --001a113f9b76f008890525c8aa51 Content-Type: text/plain; charset=UTF-8 FYI: https://www.ietf.org/internet-drafts/draft-dejong-remotestorage-06.txt Reactions welcome! :) See https://remotestorage.io/ for more info about the remoteStorage project, and https://github.com/remotestorage/spec/issues for discussions around the contents of this internet-draft. Cheers, Michiel. --001a113f9b76f008890525c8aa51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See https://remotestorage.io/ for more info = about the remoteStorage project, and https://github.com/remotestorage/spec/= issues for discussions around the contents of this internet-draft.

Cheers,
Michiel.
--001a113f9b76f008890525c8aa51-- From nobody Mon Nov 30 18:02:28 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 B03CD1B36AD for ; Mon, 30 Nov 2015 18:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lMg3sUQW8YBq for ; Mon, 30 Nov 2015 18:02:24 -0800 (PST) Received: from smtp.mrt.ac.lk (smtp.mrt.ac.lk [192.248.8.101]) by ietfa.amsl.com (Postfix) with ESMTP id AA70F1B36A9 for ; Mon, 30 Nov 2015 18:02:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.mrt.ac.lk (Postfix) with ESMTP id 020BF242317 for ; Tue, 1 Dec 2015 07:32:22 +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 b18f_vQKD17K for ; Tue, 1 Dec 2015 07:32:20 +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 62F1224230C for ; Tue, 1 Dec 2015 07:32:19 +0530 (IST) Received: from [192.168.1.3] (unknown [112.135.58.216]) (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 C01DC5FD6D for ; Tue, 1 Dec 2015 07:32:19 +0530 (IST) To: storagesync@ietf.org References: From: Gihan Dias Organization: University of Morauwa Message-ID: <565CFFAB.3000005@cse.mrt.ac.lk> Date: Tue, 1 Dec 2015 07:32:19 +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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 02:02:26 -0000 On 2015-12-01 පෙ.ව. 2:54, Michiel de Jong wrote: > FYI: > https://www.ietf.org/internet-drafts/draft-dejong-remotestorage-06.txt > > Reactions welcome! :) Michiel, Sorry for the newbie question, but I found it difficult to figure out why this cannot be handled by WebDAV. Could you point me at a document explaining the differences? Thanks, Gihan