From GordonS@spt-inc.com Wed Jun 1 09:37:52 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB60313000A; Wed, 1 Jun 2011 09:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.805 X-Spam-Level: X-Spam-Status: No, score=-4.805 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMQ3W8mB8e8j; Wed, 1 Jun 2011 09:37:52 -0700 (PDT) Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 084AE130018; Wed, 1 Jun 2011 09:37:49 -0700 (PDT) Received: from mail177-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 1 Jun 2011 16:37:48 +0000 Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2-R.bigfish.com (Postfix) with ESMTP id A7D9814E02DF; Wed, 1 Jun 2011 16:37:48 +0000 (UTC) X-SpamScore: -37 X-BigFish: VPS-37(zz936eK9371M1454K14ffOzz1202hzz1033IL8275dhz32i2a8h668h839h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:VA3DIAHUB026.RED001.local; RD:smtp801.microsoftonline.com; EFVD:NLI Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2 (MessageSwitch) id 1306946246818693_24572; Wed, 1 Jun 2011 16:37:26 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.252]) by mail177-tx2.bigfish.com (Postfix) with ESMTP id 648E81A680A7; Wed, 1 Jun 2011 16:35:27 +0000 (UTC) Received: from VA3DIAHUB026.RED001.local (65.55.171.153) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 1 Jun 2011 16:35:25 +0000 Received: from VA3DIAXVS2C1.RED001.local ([10.16.20.90]) by VA3DIAHUB026.RED001.local ([10.32.21.26]) with mapi; Wed, 1 Jun 2011 09:35:16 -0700 From: Gordon Spoelhof To: Mykyta Yevstifeyev , "ftpext@ietf.org" , "uri-review@ietf.org" Date: Wed, 1 Jun 2011 09:35:16 -0700 Thread-Topic: [Uri-review] draft-yevstifeyev-ftp-uri-scheme-01 posted Thread-Index: AcwcSHbffb95mmQNRj2gZVm+gK8jrAEMLPd3 Message-ID: <7F001908BF95A24A9136F8BC9131E4F10CC27DFF@VA3DIAXVS2C1.RED001.local> References: <4DDF617E.9050503@gmail.com> In-Reply-To: <4DDF617E.9050503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: spt-inc.com X-Mailman-Approved-At: Wed, 01 Jun 2011 09:44:27 -0700 Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-01 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:37:52 -0000 R3JhbnRlZCBJIGFtIGJlaGluZCBvbiBteSBSRkNzLCBidXQgSSBzZWN0aW9uIDQuMS4xIG9mIFJG QyA5NTkgc3BlY2lmaWVzIGFuIGF1dGhvcml6YXRpb24gbWV0aG9kIGNvbnNpc3Rpbmcgb2YgVVNF UiwgUEFTUywgYW5kIEFDQ1Qgd2hlcmUgQUNDVCBpcyB0aGUgYWNjb3VudCB1bmRlciB3aGljaA0K YSB1c2VyIGFjY2Vzc2VzIHRoZSBzeXN0ZW0uICBTT01FIHN5c3RlbXMgcmVxdWlyZWQgdGhpcyAi YmFjayBpbiB0aGUgZGF5IiwgYW5kIHVzZSBvZiBBQ0NUIHdhcyBvcHRpb25hbC4NCg0KUXVlc3Rp b24gMTogZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIHdoZXJlIGRvZXMgQUNDVCBmaXQgaW50 byB0aGUgc2NoZW1lPw0KUXVlc3Rpb24gMjogKG5vdCByZWFsbHkgdGhhdCBhcHBsaWNhYmxlKSwg YnV0IGFzICJleHBlcmltZW50YWwiIHdoYXQgZWZmb3J0cyBmb3Igc2VjdXJlIGZ0cCBhbmQgc2Z0 cCB1cmlzIGFyZSBpbiB0aGUgd29ya3MsIGFuZCBpZiBzbywgY2FuIHRoZSBzY2hlbWVzIHNoYXJl IHNvbWUgc3ludGFjdGljIHNpbWlsYXJpdHk/DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb206IHVyaS1yZXZpZXctYm91bmNlc0BpZXRmLm9yZyBbdXJpLXJl dmlldy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXlreXRhIFlldnN0aWZleWV2IFtl dm5pa2l0YTJAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBNYXkgMjcsIDIwMTEgNDozMSBBTQ0K VG86IGZ0cGV4dEBpZXRmLm9yZzsgdXJpLXJldmlld0BpZXRmLm9yZw0KQ2M6IEFudGhvbnkgQnJ5 YW47IFRvbnkgSGFuc2VuDQpTdWJqZWN0OiBbVXJpLXJldmlld10gZHJhZnQteWV2c3RpZmV5ZXYt ZnRwLXVyaS1zY2hlbWUtMDEgcG9zdGVkDQoNCkhpIGFsbCwNCg0KSSd2ZSBqdXN0IHBvc3RlZCBk cmFmdC15ZXZzdGlmZXlldi1mdHAtdXJpLXNjaGVtZS0wMTsgcGxlYXNlIGZpbmQgaXQgaGVyZToN Cg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWV2c3RpZmV5ZXYtZnRwLXVyaS1z Y2hlbWUtMDENCg0KVGhlIG5ldyByZXZpc2lvbiB0cmllcyB0byBhZGRyZXNzIGNvbW1lbnRzIGZy b20gRGFuaWVsIGFzIHdlbGwgYXMgZnJvbSBKb2huLiAgSXQgYWxzbyBpbmNvcnBvcmF0ZXMgdmFy aW91cyBlZGl0b3JpYWwgaW1wcm92ZW1lbnRzLiAgVGhlIGRpZmZzIGNhbiBiZSBmb3VuZCBoZXJl OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXlldnN0aWZleWV2LWZ0 cC11cmktc2NoZW1lLTAxLiAgUGxlYXNlLCBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMgYW5kIHN1 Z2dlc3Rpb25zLCBmZWVsIGZyZWUgdG8gZXhwcmVzcyB0aGVtLg0KDQpDb25zaWRlcmluZyB0aGUg bmVjZXNzaXR5IG9mIHdpZGUgY29tbXVuaXR5IGludm9sdmVtZW50LCBJJ2QgbGlrZSB0byBhc2sg dG8gYWRvcHQgdGhpcyBkcmFmdCBhcyB0aGUgZnRwZXh0MiBXRyBpdGVtLiAgSSBhbSBjb3B5aW5n IHRoaXMgbWVzc2FnZSB0byBXRyBjaGFpcnMgdG8gbGV0IHRoZW0ga25vdyBhbmQgZGVjaWRlIGlm IGl0IGlzIE9LLg0KDQpBbGwgdGhlIGJlc3QsDQpNeWt5dGEgWWV2c3RpZmV5ZXYNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteWV2c3RpZmV5ZXYtZnRwLXVyaS1zY2hlbWUtMDEudHh0 IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTXlreXRhIFlldnN0aWZleWV2IGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFm dC15ZXZzdGlmZXlldi1mdHAtdXJpLXNjaGVtZQ0KUmV2aXNpb246ICAgICAgICAwMQ0KVGl0bGU6 ICAgICAgICAgICBUaGUgJiMzOTtmdHAmIzM5OyBVUkkgU2NoZW1lDQpDcmVhdGlvbiBkYXRlOiAg IDIwMTEtMDUtMjcNCldHIElEOiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1i ZXIgb2YgcGFnZXM6IDEyDQoNCg0KClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2hlZCBmaWxlcyBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBpbnRlbmRlZCByZWNp cGllbnQocykuIElmIHlvdSBhcmUgbm90IHRoZSBuYW1lZCByZWNpcGllbnQgeW91IHNob3VsZCBu b3QgcmVhZCwgZGlzdHJpYnV0ZSwgY29weSBvciBhbHRlciB0aGlzIGVtYWlsLiBBbnkgdmlld3Mg b3Igb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgZW1haWwgYXJlIHRob3NlIG9mIHRoZSBhdXRo b3IgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhvc2Ugb2YgdGhlIGNvbXBhbnkuIFdhcm5pbmc6IEFs dGhvdWdoIHByZWNhdXRpb25zIGhhdmUgYmVlbiB0YWtlbiB0byBtYWtlIHN1cmUgbm8gdmlydXNl cyBhcmUgcHJlc2VudCBpbiB0aGlzIGVtYWlsLCB0aGUgY29tcGFueSBjYW5ub3QgYWNjZXB0IHJl c3BvbnNpYmlsaXR5IGZvciBhbnkgbG9zcyBvciBkYW1hZ2UgdGhhdCBhcmlzZSBmcm9tIHRoZSB1 c2Ugb2YgdGhpcyBlbWFpbCBvciBhdHRhY2htZW50cy4KCg== From daniel@haxx.se Wed Jun 1 10:33:18 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076F4E084A; Wed, 1 Jun 2011 10:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae9xDQfkW1BP; Wed, 1 Jun 2011 10:33:17 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69527E07E0; Wed, 1 Jun 2011 10:33:15 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id p51HX6PG001108; Wed, 1 Jun 2011 19:33:06 +0200 Date: Wed, 1 Jun 2011 19:33:06 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Gordon Spoelhof In-Reply-To: <7F001908BF95A24A9136F8BC9131E4F10CC27DFF@VA3DIAXVS2C1.RED001.local> Message-ID: References: <4DDF617E.9050503@gmail.com> <7F001908BF95A24A9136F8BC9131E4F10CC27DFF@VA3DIAXVS2C1.RED001.local> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.8 (giant.haxx.se [80.67.6.50]); Wed, 01 Jun 2011 19:33:06 +0200 (CEST) Cc: "ftpext@ietf.org" , "uri-review@ietf.org" Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-01 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:33:18 -0000 On Wed, 1 Jun 2011, Gordon Spoelhof wrote: > Granted I am behind on my RFCs, but I section 4.1.1 of RFC 959 specifies an > authorization method consisting of USER, PASS, and ACCT where ACCT is the > account under which a user accesses the system. SOME systems required this > "back in the day", and use of ACCT was optional. > > Question 1: for backward compatibility, where does ACCT fit into the scheme? For backward compatibility with RFC1738 there is no particular attention to ACCT and yes that is a sort of an oversight methinks. > Question 2: (not really that applicable), but as "experimental" what efforts > for secure ftp and sftp uris are in the works, and if so, can the schemes > share some syntactic similarity? As it seems the work is to "refresh" RFC1738 there's of course no room for these... But I'll offer my 2 cents on them anyway: "secure ftp" is RFC4217 (Securing FTP with TLS) I presume. I think it could have pretty much identical spec as plain FTP. With some TLS-specific bits added somewhere perhaps. SFTP is not even a properly specified protocol as it never got passed a series of Internet-Drafts, and lots of implementations are stuck on implementing some of the older drafts. The URI spec work for SCP, SFTP and SSH only reached http://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-04. It differs a bit from the FTP one. There are implementations supporting FTP, FTP-SSL and SFTP based on this. -- / daniel.haxx.se From evnikita2@gmail.com Wed Jun 1 23:51:54 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DF1E075D; Wed, 1 Jun 2011 23:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMblU6v0IyVI; Wed, 1 Jun 2011 23:51:54 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1AC4E0771; Wed, 1 Jun 2011 23:51:53 -0700 (PDT) Received: by fxm15 with SMTP id 15so582865fxm.31 for ; Wed, 01 Jun 2011 23:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2XJfGAEZTrR2AJ15FlZ2zWlDlu2Te2gM/TQbBmtZyEk=; b=T+R2jyzs+sYLAXiq/HAbrnk450Gl1FnhsttmQIhjRyFFJ4rAInwEhW9Upm8cGZU9Zv jE9SdFgHS7vgJqygvCQOZdy1gGw3Vw/3v4JzHUVWyAXwZjRv14TczBPYEHfR7JEjU9zG rxbaQzk9bvct2g56tCgPURscasIsvToFCc7Vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fwhb1YoYwVvg2KUboxYrVcD+mr84iaLMY1bgfm3fQ6NvnJGf9m6nMpxLepSqUH/2vZ XwjBDUyWwHU2A2xy2krkmG60MmmUe0B/R9Mg3njTzLDD7azPX83/qNm+ymLeemtRqPD4 RsK74h41+F+VGUIg3dUWoSThD4Elw8JeFqekc= Received: by 10.223.25.201 with SMTP id a9mr349192fac.141.1306997512706; Wed, 01 Jun 2011 23:51:52 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id a18sm83583fak.29.2011.06.01.23.51.50 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 23:51:51 -0700 (PDT) Message-ID: <4DE73333.2070608@gmail.com> Date: Thu, 02 Jun 2011 09:52:35 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Daniel Stenberg References: <4DDF617E.9050503@gmail.com> <7F001908BF95A24A9136F8BC9131E4F10CC27DFF@VA3DIAXVS2C1.RED001.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ftpext@ietf.org" , Gordon Spoelhof , "uri-review@ietf.org" Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-01 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 06:51:54 -0000 01.06.2011 20:33, Daniel Stenberg wrote: > On Wed, 1 Jun 2011, Gordon Spoelhof wrote: > >> Granted I am behind on my RFCs, but I section 4.1.1 of RFC 959 >> specifies an authorization method consisting of USER, PASS, and ACCT >> where ACCT is the account under which a user accesses the system. >> SOME systems required this "back in the day", and use of ACCT was >> optional. >> >> Question 1: for backward compatibility, where does ACCT fit into the >> scheme? > > For backward compatibility with RFC1738 there is no particular > attention to ACCT and yes that is a sort of an oversight methinks. I agree with Daniel, the ACCT command isn't going to be used with 'ftp' URI scheme; so I'll add the following text in Section 2.2.1: > The 'ftp' URI scheme does not provide the way to denote account > information used with ACCT (account) FTP command; thus, if the server > requests account information upon sending pasword via returning 332 > reply or it is required for other action (which is indicated by > receiving either 332 or 532 reply), account information SHALL be > requested from the user and sent to the server. Is it OK? > >> Question 2: (not really that applicable), but as "experimental" what >> efforts for secure ftp and sftp uris are in the works, and if so, can >> the schemes share some syntactic similarity? > > As it seems the work is to "refresh" RFC1738 there's of course no room > for these... Concur. > But I'll offer my 2 cents on them anyway: > > "secure ftp" is RFC4217 (Securing FTP with TLS) I presume. I think it > could have pretty much identical spec as plain FTP. With some > TLS-specific bits added somewhere perhaps. I agree with this as well. The 'ftps' scheme will certainly have the same syntax, but specifying it in the current document isn't appropriate, as Daniel explained above. > > SFTP is not even a properly specified protocol as it never got passed > a series of Internet-Drafts, and lots of implementations are stuck on > implementing some of the older drafts. The URI spec work for SCP, SFTP > and SSH only reached > http://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-04. It > differs a bit from the FTP one. Yes, Secure Shell WG was working on SFTP, but was concluded before the work was completed. I see the draft (http://tools.ietf.org/html/draft-ietf-secsh-filexfer-12) intended to become SFTP specification, but it wasn't even brought to IESG attention (as far as I see at https://datatracker.ietf.org/doc/draft-ietf-secsh-filexfer/history/). Rather the same situation is with draft-ietf-secsh-scp-sftp-ssh-uri; so let's first wait for SFTP specification before defining the URI scheme for it. Mykyta Yevstifeyev > > There are implementations supporting FTP, FTP-SSL and SFTP based on this. > From anthonybryan@gmail.com Tue Jun 7 16:21:39 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D511E80CF for ; Tue, 7 Jun 2011 16:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpsEj8IlFuzE for ; Tue, 7 Jun 2011 16:21:37 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 106EE11E8071 for ; Tue, 7 Jun 2011 16:21:36 -0700 (PDT) Received: by gwb20 with SMTP id 20so2724021gwb.31 for ; Tue, 07 Jun 2011 16:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=TdrnejVrM3jIpnWKpL6N6IR5SQwz+1ki3vccdxeHa3k=; b=F2pbjcKNEQ9L/Xli71attJ1Rflqx8JXBcxwd1Mo4odfnvzjtp3mgcURzsATPXpZ2Jw 1KbQ/jWtlvEp0pisQaD5qE42uLJkOEOG0sjFycjFZFOozzjikJGwzF7PNS4bClGl3Jeu e7kY1IfKphquVjsOU2ZSHdsXYj1foTDMWA2SU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=o1nQtHFNiomHeAQkurnvRCN1ZHH5Sh8GFVtxdbXCvfLkS3NjRYYb8SwALCzFC11KjK HeOA4x/UzJeiADIcJq9e2TqoUT2GpJkh+5QmnlnrKurn5feGoDg4M9aOgegCLXsvK17a 6hvFm4pz+D836Rb1Ys+Finlq9mhyyXiRCk2So= MIME-Version: 1.0 Received: by 10.91.64.15 with SMTP id r15mr6138227agk.62.1307488896336; Tue, 07 Jun 2011 16:21:36 -0700 (PDT) Received: by 10.90.97.19 with HTTP; Tue, 7 Jun 2011 16:21:36 -0700 (PDT) Date: Tue, 7 Jun 2011 19:21:36 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org, Daniel Stenberg , Tatsuhiro Tsujikawa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [ftpext] Single Port FTP X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 23:21:39 -0000 fyi, some thoughts on single port FTP (i.e. avoiding opening a separate data connection by doing data transfers over the control connection). heresy? :) ---------- Forwarded message ---------- From: Date: Tue, Jun 7, 2011 at 7:14 PM Subject: New Version Notification for draft-bryan-ftp-lock-00.txt To: anthonybryan@gmail.com Cc: anthonybryan@gmail.com, daniel@haxx.se, tatsuhiro.t@gmail.com A new version of I-D, draft-bryan-ftp-lock-00.txt has been successfully submitted by Anthony Bryan and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-bryan-ftp-lock Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 File Transfer Protocol LOCK Command for Using a = Single Port Creation date: =A0 2011-06-07 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 10 Abstract: =A0 One of the biggest hurdles for FTP in real life usage is its use of =A0 two connections. =A0First, it uses a primary connection to send control =A0 commands on, and when it sends or receives data, it opens a second =A0 TCP stream for that purpose. =A0This document specifies a new FTP LOCK =A0 command to be used by clients to request the server to use the =A0 control connection for data transfers, using a single port instead of =A0 two. The IETF Secretariat --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From iljitsch@muada.com Tue Jun 7 16:25:43 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9234511E8071 for ; Tue, 7 Jun 2011 16:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KswpAxXtLCqL for ; Tue, 7 Jun 2011 16:25:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id A42D211E80A7 for ; Tue, 7 Jun 2011 16:25:42 -0700 (PDT) Received: from [IPv6:2001:610:158:1020:223:32ff:fec4:ba94] ([IPv6:2001:610:158:1020:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p57NQTZx013992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2011 01:26:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 8 Jun 2011 01:25:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Anthony Bryan X-Mailer: Apple Mail (2.1084) Cc: ftpext@ietf.org, Daniel Stenberg Subject: Re: [ftpext] Single Port FTP X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 23:25:43 -0000 On 8 jun 2011, at 1:21, Anthony Bryan wrote: > fyi, some thoughts on single port FTP (i.e. avoiding opening a > separate data connection by doing data transfers over the control > connection). Isn't that called HTTP? Seems to me that if you can open one connection you can open two. There = is very little chance that many people are going to pay attention to new = FTP specs. It's not like there aren't tons of old specs they haven't = implemented (properly) yet.= From john-ietf@jck.com Tue Jun 7 18:15:25 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C970B11E8145 for ; Tue, 7 Jun 2011 18:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD5Fr43Tadnv for ; Tue, 7 Jun 2011 18:15:25 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 31DF411E8136 for ; Tue, 7 Jun 2011 18:15:25 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QU7Mh-0002sX-TD; Tue, 07 Jun 2011 21:15:24 -0400 Date: Tue, 07 Jun 2011 21:15:22 -0400 From: John C Klensin To: Anthony Bryan , ftpext@ietf.org, Daniel Stenberg , Tatsuhiro Tsujikawa Message-ID: <7FB1920BB81E826691F2ADD9@PST.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ftpext] Single Port FTP X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 01:15:26 -0000 --On Tuesday, June 07, 2011 19:21 -0400 Anthony Bryan wrote: > fyi, some thoughts on single port FTP (i.e. avoiding opening a > separate data connection by doing data transfers over the > control connection). > > heresy? :) No, just not FTP. TFTP and its various more secure variations were designed for this, HTTP is often used to retrieve files and provides similar single-port services, etc. I see absolutely no reason to clutter up FTP with the functional equivalent of an architecturally completely different protocol. john From keisial@gmail.com Wed Jun 8 08:04:36 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8305721F8527 for ; Wed, 8 Jun 2011 08:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SM8hOoDVLHD for ; Wed, 8 Jun 2011 08:04:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB76721F84EF for ; Wed, 8 Jun 2011 08:04:35 -0700 (PDT) Received: by wyb29 with SMTP id 29so494787wyb.31 for ; Wed, 08 Jun 2011 08:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t/FGNLCJ5knlerDhxwT1ZbL/a8hnJoqUDX2Zy4rsfRw=; b=ecCpFJdDQuT3Ko2fxV9FaOTSa7q6Awxk8kqPnRDTGAMX6XPPSaI8CauxiHHGnQhsz6 lZE4OWZbYO6mhUcqlugra4C/j5YngdkJYxnqzdLoJnz8pEopXPxqmcsLfk6UQsrDsahJ zFebe1k2CeBDAkV+w5sXae03Gc1JAsOQOF8Ow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dyA2f6EN3Jbof9RWwz4cDZ8vRnith5SZmeS3/m5G6mHT+XqKCGwdiQHkE9khXsfAzi 5JyWrDIhA3ng+RVQqAy3I/oKybKw7UmuL/15YxEJK6GcjwHaA9MA6fhzDH1VoliCE0m2 e1El7WnIqqLES6QD5YTu40JM0B5QweFQ4cHYQ= Received: by 10.216.145.131 with SMTP id p3mr878779wej.82.1307545474894; Wed, 08 Jun 2011 08:04:34 -0700 (PDT) Received: from [192.168.1.26] (176.Red-83-49-112.dynamicIP.rima-tde.net [83.49.112.176]) by mx.google.com with ESMTPS id w62sm332977wec.18.2011.06.08.08.04.32 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 08:04:33 -0700 (PDT) Message-ID: <4DEF90A6.8030602@gmail.com> Date: Wed, 08 Jun 2011 17:09:26 +0200 From: "=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=" User-Agent: Thunderbird MIME-Version: 1.0 To: Anthony Bryan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ftpext@ietf.org, Daniel Stenberg Subject: Re: [ftpext] Single Port FTP X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 15:04:36 -0000 Anthony Bryan wrote: > fyi, some thoughts on single port FTP (i.e. avoiding opening a > separate data connection by doing data transfers over the control > connection). > > heresy? :) I don't think LOCK is an appropiate name. You are doing two different things there. - Using just one connection. - Defining a new transfer mode. A one-connection tranfer should be able to use a different transfer mode, such as block mode. Also, another mode like a count of bytes to be sent seems even easier. The way some paragraphs are written seem too familiar for an standard, but that's minor. There seems to be a hidden assumption that the control connection is binary safe. What about 'headers' below the boundary? There's no explanation about where is boundary-announce expected to be provided. I think it would better fit within the protocol if the boundary was passed as an argument to a command/response code. It could also be auto-guessed from the boundary-start. References should list rfc2046 (MIME multipart type). How should errors be handled? I think that the server should send an error message, then close the control connection. The client SHOULD in that case read the sent message for errors. Another option would be that the server ignored anything after an error, the client COULD stop its tranfer (by prematurely sending the boundary) on receving a server error, but that may waste bandwidth for dumb clients. From rto@globalscape.com Wed Jun 8 09:14:54 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322F71F0C3E for ; Wed, 8 Jun 2011 09:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpEUgFRgBV6X for ; Wed, 8 Jun 2011 09:14:50 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4761F0657 for ; Wed, 8 Jun 2011 09:14:50 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Wed, 8 Jun 2011 11:14:49 -0500 From: Robert Oslin To: "ftpext@ietf.org" Date: Wed, 8 Jun 2011 11:14:47 -0500 Thread-Topic: COMB command IETF draft proposal Thread-Index: Acwl9uaCXZ71zT57ShSQbo8MMP/pVw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_006_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_" MIME-Version: 1.0 Subject: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 16:14:54 -0000 --_006_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_ Content-Type: multipart/related; boundary="_005_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_"; type="multipart/alternative" --_005_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_ Content-Type: multipart/alternative; boundary="_000_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_" --_000_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Any submission to the IETF intended by the Contributor for publication as = all or part of an IETF Internet-Draft or RFC and any statement made within = the context of an IETF activity is considered an "IETF Contribution". It only took me 10+ years, but here's my contribution the FTP ext community= (attached). Essentially an early draft to ratify the commonly used COMB command for sup= port of multi-part (a.k.a accelerated) uploads. I welcome comments/question= s from the community. Ideally redlining the document (or via comments in th= e doc). I will resubmit using formal IETF draft (in ASCII) once I've addres= sed all comments/questions in the MS Word version (hope that's ok and doesn= 't break and IETF rules). Thanks, Robert Oslin Director of Product Management Tel: 1 (210) 293-7902 Fax: 1 (210) 690-8824 Send me large files securely www.globalscape.com [cid:image001.gif@01CC25CD.46CF5CE0] (NYSE Amex:GSB) *This communication, including attachments, is for the exclusive use of the= addressee and may contain proprietary, confidential or privileged informat= ion. If you are not the intended recipient, any use, copying, disclosure, d= issemination or distribution is strictly prohibited. If you are not the int= ended recipient, please notify the sender immediately by return email and d= elete this communication and destroy all copies. --_000_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“Any submi= ssion to the IETF intended by the Contributor for publication as all or par= t of an IETF Internet-Draft or RFC and any statement made within the contex= t of an IETF activity is considered an "IETF Contribution".<= /o:p>

 

It = only took me 10+ years, but here’s my contribution the FTP ext commun= ity (attached).

 

Essentially an early draft to ratify the commonly used CO= MB command for support of multi-part (a.k.a accelerated) uploads. I welcome= comments/questions from the community. Ideally redlining the document (or = via comments in the doc). I will resubmit using formal IETF draft (in ASCII= ) once I’ve addressed all comments/questions in the MS Word version (= hope that’s ok and doesn’t break and IETF rules).

 

Thanks,

 

= Robert Oslin
Director of Product Management
Tel: 1 (210) = 293-7902
Fax: 1 (210) 690-8824

Send me large files = securely

www.globalscape.com

3D"Description:

   (NYSE Amex:GSB)<= /span>

*This comm= unication, including attachments, is for the exclusive use of the addressee= and may contain proprietary, confidential or privileged information. If yo= u are not the intended recipient, any use, copying, disclosure, disseminati= on or distribution is strictly prohibited. If you are not the intended reci= pient, please notify the sender immediately by return email and delete this= communication and destroy all copies.

 

= --_000_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_-- --_005_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1415; creation-date="Wed, 08 Jun 2011 11:14:48 GMT"; modification-date="Wed, 08 Jun 2011 11:14:48 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhlgAfANUAAL+/v0BAQMvY6mSKvxAQEGBgYJ+fn5ex1M/Pz3BwcCAgIK+vr+/v79/f34+P j1BQUNji7zAwMPL1+j1tr0p3tX6eyuXr9FeAurHE36S62nGUxb7O5Iuoz8LFyjY8RX9/fzBjqgAA AP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACWAB8AAAb/QJFw SCwaj8ikcslsOp/QqDQpqEKm2Kx2y3VKKhOQGETBdM/otLooCIMGmOqmcpGs7/i8CAHo+xFCEGIT G0YQFR1+AF0Mig16kEMCV08FIZeYIQEiEhQgE5RGEh6ZXQCZH5GQGZ6FRw2Ke5mZmwdiGUoNBJim qKp6BxoaB0UIBbuzCpcFH7QinhRMzZd7H9YOgEWw1twL2SKnmKm/eBAXAxZEBrPsCgwitBa3TA2Y AewB2QbK7JcKBuB8iRBAZ4yYARxCicBQcMwEhOmISHAjhhiRAQYNnuOQDmPGj0YQZCJgAMCCe+Lg 2RMgRkATfgQSfLCEiQCDaZcCfDCQANkl/z6+KjgcQNQgBxEQPI0hqlSMmSEeDSqMSoHoAIogMkT9 OMYIzhAAhTDwuYkWSxAumaBcMOSrAwPcHAxB8CBTH18GD1CScODAJAsU6wyxNYZShjFNL1wcY1GI 0KWMnXwNK8RnBJU5z6ZdEoHakHA5RTRw8KBzvxB3U17gSlSvCA4GXQnhe2CDgHQQ3GgAHFlI1ApV BBygWFRMVatEFX7OpGBRg7qYCmDWJMEpEwa8lttzMPLBTpqXUl9KJQGDBqwGB2gwuBnJ6k/pDhf2 zdVgBQlbP7YnAv60gkfOrFYBE+uE11Ym/bkzBErhgRZCKlVkYAcEAjCkkUG4DCGBBlYJV//fGIL9 FlxwUPXmRH8jffDOdJtgIEZESDDATwgEMNNfBA6GkAAADjDYICrvkeFXhY/BVyQIFcRxQGJnkYHc VkdF1ZgRUQ3Q15VXhgTTAjx+AMA3QjgjAkYDKJHAeGeyU8A7BviEiQJpXlISKnw19ZEGlGwQZEYU HGCBUhPAKARhLUmZRH5cGQFdCAomoUg2EyFpxxF8LCIaXNYssKJYAMQFSCN+NABqH48IYYEAGVxZ xRESVKhqRK1accSIEFBYhaBF2DrirvtNd0kEAQSr0weaJoEfGU/NRs6yqix62iUkKWHeJwNU4Cez 2ObBgI/PopatFACUyiwDYGYRJ7ABuCn/EBoIBFsuFAlQJoID0ULRQAMLsGVmsPoW8cEDXHD36xEO joNGAMz0K0UACluzMDbvFhGBAwBsSoTDW+BEEpgIfGUpGgVE8MgCD8hlzAcIJNBAPg8UkLLLQzSX QAE7EuDOzIsEkECPOxeg6cwPtBlBAnzQ3EjLH+uIcj4BjPbASQg3YEwCTSMMkAEtf9DAzOIKsUC3 s0i3xgcEnNITvQ7sHAAAAexDcgSlDRECdh8osMDELbcpkgH7JKBAAQg/HcLXBkSwzgIFeBfBB5uE 2YcIdRWwT6c6L66ANWUTwN3kiwfwgOdG0Au23WsAkICMzcx0CgM37aRTAiJ4ngDsooUApI8IZYfQ gN3YnSTCTMBTbUA9tw8+twE6WwPwHpeJwEBnC8wkGgHtft0A8sgDcLl0JdcoORJdMh6sNQZEzEhn EWxrcwPHMHzJAjKJ0Ga9AOCoQPHyExBTj79zI9MC+kMNAW5XAAUQ4CSYEkI4PMcw6hmQOyJoDtk0 8YEdNU0BBuyUzRT2rQ56UAgOcAB2uvbBEnoQAcqgnQlXyMIWuvCFMIyhKoIAADs= --_005_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_-- --_006_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="COMB (Multi-part) - IETF Draft.docx" Content-Description: COMB (Multi-part) - IETF Draft.docx Content-Disposition: attachment; filename="COMB (Multi-part) - IETF Draft.docx"; size=67471; creation-date="Wed, 08 Jun 2011 10:36:24 GMT"; modification-date="Wed, 08 Jun 2011 11:09:19 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDcBSGo5QEAAJ8JAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 ljFv2zAQhfcC+Q8C10Cik6EoCssZ0nRMAtRFu9LkySIikgJ5TuJ/35NkC2mimkoVLQZs6t77+ET6 bnn1bKrkEXzQzubsIluwBKx0Stttzn6uv6dfWBJQWCUqZyFnewjsanX2abne1xASqrYhZyVi/ZXz IEswImSuBksrhfNGIH31W14L+SC2wC8Xi89cOotgMcVGg62W36AQuwqTm2f6uSPxUAWWXHcPNl45 E3VdaSmQSPmjVa9c0oNDRpXtM6HUdTgnDMYHHZqVfxsc6u4oGq8VJPfC460whMGfnFdcObkztIfs tMwApysKLaGvb9Rq7ySEQJmbKutXjND2yD/EIXcBnfltKq4RzL13dbiYjNOLNnrgUUOf4RBDm4Xd mQ14op/s/iaMXvpUEC1EwH0F4eMJOt2R9r80ljdFAZJOffxgmJA26Fln8aI27gaIlPcYk7/vYho7 feGgHEV4gs2P2SheiEdBCufQOpzj3ffSUQiwaiaGo3IUoQShwE//B3hzBzvhqH8T1iz+nXDUv8O8 HHHv3nkl3rX/GfxH7r+gXrkWmwo+PoFeOvoSkAYA4O3n9JPYypyypFbZtj0aKPx/bPs4MTTVKfXg Ef2ud6RhZHLO0Iw7CtSAN2/Hq9UfAAAA//8DAFBLAwQUAAYACAAAACEAHpEat/MAAABOAgAACwAI Al9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIyS20oDQQyG7wXfYch9N9sKItLZ3kihdyLrA4SZ7AF3Dsyk2r69 oyC6UNte5vTny0/Wm4Ob1DunPAavYVnVoNibYEffa3htt4sHUFnIW5qCZw1HzrBpbm/WLzyRlKE8 jDGrouKzhkEkPiJmM7CjXIXIvlS6kBxJCVOPkcwb9Yyrur7H9FcDmpmm2lkNaWfvQLXHWDZf1g5d Nxp+Cmbv2MuJFcgHYW/ZLmIqbEnGco1qKfUsGmwwzyWdkWKsCjbgaaLV9UT/X4uOhSwJoQmJz/N8 dZwDWl4PdNmiecevOx8hWSwWfXv7Q4OzL2g+AQAA//8DAFBLAwQUAAYACAAAACEAyMpXtZcBAADZ BwAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACslclOwzAQhu9IvEPkO3FToCxq2gsg9QpFcHWdySJiO7KnQN8et6GpS1NX Qr5EmrEy8/n3LOPpt6ijT9CmUjIlSTwgEUiuskoWKXmdP13cksggkxmrlYSUrMCQ6eT8bPwMNUP7 kymrxkQ2ijQpKRGbe0oNL0EwE6sGpD3JlRYMrakL2jD+wQqgw8FgRLUbg0z2YkazLCV6ltn881Vj M5+OrfK84vCg+FKAxJ4UFGQmFdorRHOmC8CUbD2x5SS0HyG5DMmQK4lztqhhB9G5fBRBIQyualeG 1valvwmrgcI/D5GrX5cPIhmGpgDtPoOtDT30AQTNL5diAdp22g6hc/kgkpAi8KVBJd5t9Xc9Ece0 89IKQSQ+mlFImi9YvACi1cTpUcfpA0mC6lICy9ziaG1vcVyHVMIcyLD1eDWw8zvcuFz3pKtBa3ur 4epIflFxrYzKMeZK0HZSryf0zf4SoO0gequwfMxz4OiUwcGRT4i7Ixw9K+n02uivBa8OyTEh/gWA dp86+2Jj0s23g6B7C3nyAwAA//8DAFBLAwQUAAYACAAAACEAX7k6MCdJAACH0AEAEQAAAHdvcmQv ZG9jdW1lbnQueG1s7H3rcttKkub/jdh3QPBHj71rybzq4m6jl5KoY3ecY2tlnZmY6O7YgEhIRJsk OAAoWf1rXmNfYB9snmS/zKoCq4BCAdTNN05Ej3UIoCorKzMr7/WnP3+Zz7ybMEmjePG21dltt7xw MY4n0eL6bev3i9Odg5aXZsFiEsziRfi2dRemrT/7//2//en2zSQer+bhIvMwxCJ9c7scv21Ns2z5 5vXrdDwN50G6O4/GSZzGV9nuOJ6/jq+uonH4+jZOJq+77U6b/1om8ThMU8x3HCxugrQlh5uXR4uX 4QJzXcXJPMjS3Ti5fj0Pks+r5Q5GXwZZdBnNouwOY7f31DDx29YqWbyRAO3kANEnbwRA8h/1RVJa hWVe8eWJxADP+DoJZ4AhXqTTaLlexn1HwxKnCqQb1yJu5jP13u2y0y/Nly+5yR6cJMEttmI9YGk4 CzIm4qP5TOCB9ne9q8URO23XYuSO0BA5DE1AMOdUkMyDaJEPcz/U6MgFRzyEvn9J4tUyB2cZPWy0 94vP+VjEmBtA1t5jztOXlm40QIl1P02DZdjy5uM3768XcRJczgDRbafvEUW2fAiLy3hyR/8uvds3 EDaT87etdvv4uN/eO2ypn07Cq2A1y+jJcNQe9DvqyRn9NDrpgbF5sOVZwmN9yu5mIb6+CWZvW+en xxdRNgtbr/0/vcZE4h1+MRF/T6Pr6Qz/y9Qnd+FsFt/KD+RLl4n4XnyoQCMATo/ao9EBA8Ay7026 DMZY5zIJ0zC5CVv+aQRwLpJgkV6FiXeWxFk8jmcegZMxUOVBO+3B3mDoGvT4429HHqTVHELYOVQ9 fJCc3m/AcLSzDJLMOdjxqDPcOxZw+b8vZ3EwSV3rkFvJW00YpBVDLlxlDT5SSD6D6DXR7O+4Ptdx 58fpLFq43i4Q24Mmu8qWzzUVdv7yCefS9i3z2+3d7Iu5Y8RJJb5tH+wf9EeKO881vjWfMN/Kn3gQ wYcRCPn2zSy8IlYvsKtJC+2T7lFPcoc/vEyzJBhvDp/Y6pNh56jf3Rxo5tkKhr+Yhl4F0784vTh7 6c2Dz2HqLWIPB+JNREqWR0yYLqGoZDhovdXSq+NrnRVJOSrLnRXzJw1XpBRmRPtHgXdF4ipIvew2 9gDUPE5CjwRDyiClq8s0/I8VFLzZnZeERIfRgubIoNsBbiwFv4bRMtstTVu9i3ZYLqZR6uX6ZLoM x9FVBMRttJxFeJvLyWwaQMrHq9nEC0jGY0UeNsQbzyLSWLMY6/6sfizOsin0LP0TGlShCWgV2BVw AMfFORwbg/PkJopXKdBe/GpTyARhhBPv8o62rTSeAwrC1kOnl9guDsOz+kHleSL4Ved9O9V4czrL liBiptpd6zwVnxrvWoXc3uneaWetnAigDva7J0cDmxAxX2fJp8nWKo3lXWdnEV98PF7Ei9XcKQrl zAJ3n7IgW6VefIVdBef8Fs7j+gUdnAzax7DvpAJWt6Djdq8zOlWv84LkCARDYh3GQU/M4u8XWZgs wmwHVsFV5gF0SJk5RCFINIJoXM1mYOEFW3iLMVS7KJsy4ebikxd9dHzm7R+wlOI/D6slEGkUroUL fJryZx7cQWRn3mUImTghSTR5xZNNwiS6gY13A8ji5DPDEmUQ8vn74yQMsJhXXvhlHC5Z0CxXl7Mo nXp4EXIAcgiKKo8GeYHzbJHCagzpabTAL7Ngcb0KriH7YjAshMoUX4wW1zSESeBWonUtVe2Ydlyb r2+wx765k1gXzg7CCR0QSpBLAg099TItJFqEwCLeuiAJfBon2OYX70cXpy9fAQk8UJAKdNN/qjGv yXhKdz3vQwxssVgVCBIPeA+CWRp7kwhaQnS5wlvq2zU82AAFiyDB9BvCqV1SFeBlRLNiraEZ9k80 YcUiACK+RPPVnGRDGn0BAS+yKZHdhFEEkl4tJ4JEk3A5gwEDYsXhb4gPjb2Jf4ZH7f6hMOMq9KB5 MCkfLoreDEHjkBDxZRrPQuwbDiuxt9rGgXkWOMOieQgaeM+iI1oES8iFZRIRA4F3Vuma1OT2Essl IawxOLXAzXgRb89owXh/HNF3pM1ovIYPWkQ4JI8KSMFk8dUoIdGX3S1h+V0nwRyiOMlIcmtIK6/Y x7fXsBOLZ551yNFiUj/gbsuA7omkweFR+7DTYzPQIfH9C+gWkFAZUd14lQDbWZHRvDEEGcgvGJO7 D/I+MBV5DX1Ec3LiTWmouGUuoKXH5Pb2djcKsyv2J9IfrzvRZCeQxkbazCIyBem5QQBqDW65ew9M m6LBgxNmAk33JIIWmsUJ6c/fBc5Thnt3ms1nz0HScqtqGNYujG1KzG0EpSX8sgTaPdhExhIKRH28 NzjsHrUUQRhUQvBczSbH04BoVv51wWLmMsSpKZVDtkarqTpa4PS7CL9UyGnv/SkDmL/mE7jmmMR9 Xx/QT8N/HZ0ML0ae97f/5bV+a3l/+x/eb6PzX0anH89/G1485SrSEOYETgorxgk7vaP2EIo0U5Dw aCziMzobpOdQeTnkVvh7hOQnQnkozorSLpZoK5/fTtneW6/j/WUlbc785W+WPr4/QrbT8ZasrSLv Ecm66w1X1yvoJk/IhT+1hLYT9hNi+2cV0D3vE3wK4fwSfoEnRO+WmLfaRoUm+ohiue99hJWyJeVH V/FzzXkrl1lFf3pSHsApebMVy0GypeXv3gjc804Q1N2qGD8XLe/1B0e9ar+UTI1yeznaT6iSPqLe se/9JVisgkQE17eOjkdzLX7LesdPRN8H3ml4mWwJfCvAtYyRH0mAH3q/Bcl4uvWAIAD9iK6arfi+ f9zrEdWTTtsbIqNBJI1vtZOtdoLwbJMY43eifXc6kN5b1ZuSh7ayu3EA/Xsh7i4i6IvQa50GEWry vqXQ7mMYQLSq78HG3+KdC+xKGSBP7Qjf4n2L962cEel3j5s3VZ/wsMX7Fu8/k3wXGZiVibSNTCYV 6NrqNCLtWERv62XNz4b7b0qR/9mQ/y0plVvcP1UW+1boFDqJ/CAyJ/P1Q7aqB8o9q00ae92rimHo 4H9kmB7Rqbeufpm8aj1ltKsp89W46zL/4NUTYPQH3+UfpY7lCZXoR6LPdTDtu6jH+sMs+6O3/5R8 /4iyygge/zv+79vyfgvFrUZ+rekDvQk7T0jPjSVaDlFFyd4TwviItLGVcKJnDJFfhYumVsLtn3Q6 3f4DEzQPn5BeHo2m/3ANsbf3nYi9t98JnN+2eH4U4u6iZcT3QN//E2XW35BPY3/QOzl9aOb394J7 e1z+m9qOx5Dz38t2fENs0KyjQ+YrzfCRvQaNT8/Mb9CvqjvqnA7yxm3nRh6AiphovWjM17kHmPyJ NJZHbVw3C9LsHItFO6bJGZqcHaFb2mfZLPY4Xt4l3JwXHb7QJpyEeY5m/F3uQmoC/sB1VrdUqfAe reF9MX7JekAObaHrS68mOOsmK2P7aEcq4PGohxqaD1OnA+r2Re0el+jrjn7kXjRBQybuY8ftPvFE ddbyglU2jRM0Vhuiiw3jnxpmcUfLSQNa63X2hsfrpqoGsBZaM19nWpM/sXGmvjCGcazZbNsnugn+ A82PqLmX1iOQULHGzn/95/9NvV/Da7QBQ9MW0ZQ19c65eTt1N43Fuyeyt3vqvZCNojLCbRium0XN QKaLNNyJ0LDwJfULC6+uaHZ0AaIpqc0aNcTiBoBjbg2fd2xU+N/1zmZhgL5l1PMT/UvxHf5DPaUG Tuhehq6Id+iIh0at0/DOm4TpGA3uQu8uXiVqy2jHsW3ofDfmFvSicyJ+QStVRkemd1gttEu0cpfZ z1Jyl9neV2/8a77OO/uo7S+1LsKZf0ENxgmXx+huB9I2u6pZl9Pp7/f3i80vq5cjX6+UgGjZ2ZH9 gVhCWuccot8memibVF09p3SD186ZZwQnp1g+WiS+CdJxFF2gkR3SSucRGrC/Gy7SiCYGbWXDNAr0 hyP5Gz2f0ov6w/zLcQpqywc8iiaR6EmX/hOfccP1blf9ckxAaL8BGxyBJ6yI5OWCeNV2s8IkrnZA UAemwUGn3y72ZtUGrfOcYPu8v8Xe36be3/7p/W1Va8YJgaRNUAG1zZCfoodXgt7kn4GjYDGGtH3b +j8X8bh70N3f6w0GrH2DO9Gy7Q43cIi2Ung375LvIiMWmxLFRjf8d2pW1cVKvJT5nV3qzJfEkxVL CuOYLRxcDSe+DS/fRRMcMUb7qyy4lP/NMKoFlTDJhHL7xj5IBZrdxPEgsOso52z4y+h8dOoZO0iE VGd8brJw4p/Hx5qNOHO+JK56EOKgxVTR0iZLr/SRGToyEJSzFafalbVD12IUMWpasGYBWFVeJfCl ZMM/34/wzVFVIYHYsfh8Eqi7S+f2DamkpJyiays3fzY0lCpSejiZ2sUSjWsNQ2sy/weQVP0mkuqB uCgJrweOVykRnlqe9VxE+BTEshVxMG/vp1/WiThu2f98Iq63q9+zQzf4oO2594L+eOmiKtehpal6 dmWpQuN6Kvb7xpSwwVa0NT2rMr/vIsIfU7RJY1Ue4j+Q9oarDqENP5v92NuFBXk6QgtmdScZeZmg yIV8AYF+W5mLyLaSji28+5ibe1tJ11zSca5XlWd+K+m+KSdhnRK3/9ySDpbq7wiF7Jy9h5WKeBW7 nKHDbQVbrTJ6H8G2vxVsW8FWFXOGA+6HVeFwx/bzqnCwT1lRO5bXyuJSIwSBt2LtScTawVasNRdr +y4i/DH1NQ4k/4hxBQ7QPp9l2kdkc/hhSMEFXDAe4gofii+46GlrhN7bCD3cCrWtUHPoaj+qUNvj HKLnE2oDCLU5rjieI1wqUsjOcSk37pqjH7bCTWTLiNwWe1TkHoboXnsr3JoLtwPXCbvV2L4nD9te 53kN0b1d3GiF+2Kj7G6rtU3ON8uTuo9gQ+1RfabaAwPGP0z+x1aw/TApbntcovB8Wtv+LgoK5K3j WyXtaZS07laWNVfSuDZ2GwalBNhvvlaiJgy698wFA/uU8PEhTuYwP2/CrVwj9agp491HR+tt5VpT 9Gb+Vq79ODraM5ch7O8iveM9Sje3kk3rW96U9e4j2bbVB40Pjp9Ssv2wMYNnrj44QDX/+PMivp2F k+ttnGD/oD96GhN0W3OwgUDrtLeBgu+mXr/OBn3mooPhconiuOiLN9z1Lo5OXIS0zem4b07H3raw YBNxxi1Cv2WX2t7h3qDLOfOs32vF7mZUVrZ8GpwMB3xMOuvfEd25b0uPYnlruWbfbCKj4mEn3aPe kAKTxWUcjPb22yP1RCyjtz84dCzjXRhMosW10bvl9s1lHH+eB8nnT1mQZJgomsDJQ+MuAuqAYvR6 ED1PEgWOjNkJGCl9NPMd7TXURCO061HTiC4ZZWQcDftHXZazxXVj+wadE2Pd8ifOXzVB6x/1u0d7 vLEVnaNOL868F7fTEP1eEm85C6LFThZ+QRujxAsX4+RumYWTl14WfA5TejwOS92uxLrjmzCpkswC TfWwlIZWiyGvW6c92BsMxVJ8QItuV8EinUdpikQ/7gWUxNzUKYvH+ONFc2D8i+OzqrdLMwMXNO8y Bq3Mgjsg7a+ub+U+ChxN0F3KW4ToeBCgX5OMEFHPqRoANLM88//896r5mqK50AAKrKXjedjZ3x/u u0jmfeah29Z1uECWJZpTecF4HBKZoENVkJX2UCx93hxoP/gSzVdzDDuNwhtu9gT8UDsz9tYsQIKY fhGj05l3tVpwIxuqzQlucEUhv36JhlhV89GG6kv0b6NJNvUuw+w2DBfeeBYhtcr18UFvcHrQlnTo Du/VYpJ7tXG7tUreIXibT2lQyiuPO4BFtEmuFenoqGg2DQEB3KBeYLWIRDOz1IvHSN7w4lVG+ba8 Ad6v8RiN1YZo7Od9AELj5LP34tfhh5cQJTdREi/IHDX7ymnE15R8SxSmU6/Bb8dVq246VbxYoIMa Nyoh+QaGT1AHdh3G10mwnAITM2+C2ls0doJ0rJqsSHF2FIdfptFllHnXQF6GqRqMptZdXo2fxCvq AphESy+L5gDuxblzwGHnZNCVNH3hfFPQtGNq5+eGEG/CPI6J3L0U6nkP0sQLIWS8ZTD+HKJP3jQg Gl9vOXr6jWcxSpuNDV8mMeQTJS1BcPP3MZ2dbqG6N+zt78tz2D+rQrBlI2MAqcOUrgAwNwMkwPCE OnlB9DJ5pqCc2SxC40HqOFY1C9GjIScq96EMj5120ahwQQ0IVzOcDAsn6er8aR9M7oYL+nqBhW1z M6ROiHY4qKmiC4j6laSryxTpupB5zoH01fisHYCwgE1ozJI0H7xBbuI0jpcLaFaikyUk/JU3daHA oGp0b616tzEdzUDAizE0ijLuwXbxFSrVIBAydLd720Jzy9mMdXarUq5rmz6RQ/EItA8I3bx2ODu9 GGxahQniPZ1wfHAwpPTlKjNb3j7psZjFVeA13qiqAWh9OlXYUUXq3G20mMS3Xhr9M/SCyT/QXJV9 1UKHnOOW+LU8SaPrBfrXQshk0DbTWXzrOB/LSyAcy2O8Kdh++iQKYT1mHl0hbDAln3u3pLqbGrRQ jG/j1Yw0+zBOQnRmFgr/DHtQhcvyBtiJoCCTyLVApsJSnfhESqatK10CkrPVe5pnQ0pS+US0oRXW Mo2c0P9zNaEmUziNr7JbtN310KFuUlMVqx+i9jWSdjimo1kZRyGG9aCagYCBUpzgq8VVcBMnZLZU IbQOEWxgVcxPCkLECuwr5xl0eLC31+u7jD62emGyJnCgOIdy7ZkD1DmUhwilLs6x68G8imbQdmuU kHuCuAzI3g1nThDriQIUBiJ4gt0WEhOkhuUrMyK4xl/X1Iu6aEODKtOVW0nS0e1LVQbWpPCAgBag IWAUmOGVCkoj2vVBUtj4ZmJax2+TfvjytLVIC7k6XVpoRzNLiyqf2Sohld+5h/sH7aM9J0fBV2FT dAxnjAZQBSwwF2c7sLQhpF0kpet4dlmRoYF4HW/XLwpa1Q0o0AWKviY48ujcyYk0m8JyvZ4uV04X TOeksy/d1RVY4W5UoEtBWSQUmkJkRw6Ik45B9F13jaMj2Te1lgi+VGr1PnF9r2OmAg52xLjG0HEj sEur925hM6ZL2IYQDjAv4JshD+8ch7oHEwU8DeGWpegzD81bGsVwcLLQh61LFiaEihKArvl1HNjX 8EdvCg2OBAegcQ1Vjw5aVTBLY7TFh88Ezc/VObumKN1teA3vNpqV4ziG+3CxAyM5DHAQAx0wehar +SVgopb9TeS8jmf7OgmjpfU5TkB1wrplcj1SQlSMxnfAxI5H6kaG3YXajAjHdbTARtMOY70L4AzO zgWxfC22UnKNAtfF3XKtxkBp8UMljul8qF/RU25IFSTgHTDshHSJBpzbPe71jnvSgQa/K6l5zKoB le965JCW6jRRrHJUPwwrBQVaMxkJqzp9+hfYDByv49mKgyXENix4QQcPg8GLl/AvgqqehHvKBFe5 W5OQcgRcizEQ8mA5jJDTPFjceVfBGK37IThdUxvUAXqarSgM6cHq5zDGjNyJJLniNaE4L9Ot5xh4 qtmT8krbmGm8BO2B+6dBMmEbJyfE3JW5iCdOitCluy9OC/Z+Kjy4sKBD7SOTA6EEunHFkBM5pyvu IyetojFdlCMCpCIPNAKsrCXHIIw+4maowWphjk56ndH6bkXNmBwd7HX7eQSWjcn9Tq/fEW5yl3p4 gQMF8VK4NW7gspCd4xgwJUvoMHWhSldy7YfLWmQXx2GZ7Gu4Kr6g85BcvkOOCzHmGsNgrJOP//bh 14/Dk/cffnF902BeYcldJfEcrqB5DAtmGqekopCZLsJ0JWsdby5XyRKucT7jyIfEQX3VrPTF+ejT xctXQD+MYlS0gP5yu5MepdAbybeBzy/vvPPRxTkiJ/B7JAhEhs54g84Y9h2DAJ5DZEzSXW/0MNRQ zIKgVSM6SakeMOHhgTuOIntuBVffNj+Ad8O1EH1mH3cjJeQIv7zDFPHVVYqAC/E2My/yLDzWUhNy l+OaJUY/PdKX6ZpLB8yOfvdpeXja7felteY7t0dflX0m2p405NRb587oc9pHYqUdxwvwcRshSB3A XRQBQ14GHQ9OowTnD5R7ylNhwb4OOEDha4ouPwlBmZfQhV1f6MD6znO2fiucoOkT2bECziTSsImB FVoRg+nHYbREBgtSAnCtGb27pivXGnXIfdLe0yYHiHFM6JdiSUqR4tZ+gPi/UwlKtlqA89xBeh04 O15opbBsiGgWJQ+/U8LD2w7dw4UaQ8b/fkYSvvi6awYkapARCu0TErf4oX4e1e9+CmUJYXiwwHjK zIATQQVFlfS3zFKK9iCCP7dFj0h31qHgVKOAM1ALgFuHLMePigNWbN6L4dnZ6KUS6a/gahgHuByl ktQLwLj0EQROKFsGBgBufhIMIXJOdoiHsAxkL+BUKo5YtS8+9Js0nqEalHUafA/ndWV+Dy1/eNTu HyrpWtJsXYTjgkl3Rvm/zOLLYPbpeHg2eoW6rvEuKafFr+87k1QF+XNfjxIUJ9BRpod1K/bc9bkx pwhGuF43kFFCsQ6XPnAFXGTw0iEcEHEsofxAibpTpOnRcTPxWtRCtOUCSbtUKfMfClLjidxnkxDW YiPDBBXNE481TDok4ETFsgoTlZi8MuxMhK7j1icElU9V+4B2sWEMV4TM8BMbuEbf6sIqjHd1brQT AItpZm6ps7rNW11c2geMrpzSRbcM7QOkqyVlXGK7XCuT+FLULiKRbS071z64VCgajOwQICQWGoxQ DRsCLAlHU4R/Dr5reO4odIcTPUHKaeYaXceg73Zu3BNJbhIw6K8seNWqG56FrpXqPGHfzgfvhH1Y aXI+DDYRRmgwhsJYUxoWvv0GAwvZFzR4c1MQnOSvhxLt+JWxmgcB5qclxVetgklPi3L7q2Qsrc5S RIR0fxccugT1ERB1vVu/cNaNnRHUJ2HZeqmtAhLQ8yjZkC0iPQykIidCcLkFxD2XQO7Kh2GXTUIY CKTj4i5lFdISVQPSROSVPQn8qE6Aud50Bf6TsKV+KY+5ZVAUcoP5Rjlj9ddfsfkhDybhJ2q8Fpjh rEa6PrgnVTBUDcZ1HNdsj7qG0PnWh4agvCSEJnIrgHRIafwaosJJT/r56GtXv8PjTPDqu+tafu3O NMm9OB11D4+txVvm8BW+keEMggfZABZ3RpVUtx8tFWFYnzL3JwiGIAfRaTbotGCfgYKjoAgXRo0g 0F9WNe427aSqmLHb7pSKEB0E7xZv+olmn4+Ip7g8oUvoJIXYEqVOUrR4grCNG6260mqf1D6j/V3w aBE+nUrqJwu0WFlxJAdi69RNnXign5jphSKBSgiSNKOQfDAJH+R1NHmOOUv+RGuQ1Ztw9gM3s/Aq g1pE+c5aYafY1M5uibh0bOpSxr4dpc0Q446+cETcwK81MGeuQ/ermk+KKxSOMF/OQ0wp6JPrupQj +M0Tz+/IMrVj6/gP19kfBaQGaFpQX1gC2l5mvtMlIEvhBdpfF0cVP9MpuDsJKpVd25wlF4npXBgg afdYJkJUzLqsJC3LfCYzyCzezM/my+KSFH1aBmk9AtDd3eefs/cV5uzTnCZlbcigR+3946EZOZc/ EdVJEZSizod0KfRkRD5sUiWHLnDsOG0jnSHsvCXcKjOUJiLFUSS3VZEOGYkG3zymeqcPbIeULUEX bPWL5Tig0lWxXBwtc9hsCO8oXpdvZKsEuXCBdxbD0UStHY9jSlVihxPiKAgg4hs6mITfw2RDK0GY 265LbPMJS+xNCcI6o3kSyPKA0377ZGRVOs3X7wWGkj/2/fvEUrxqA6VcEuAJ+dsdtNFSU8W82SZB PhH5/OLPwd0rcrnTnhTUKCsuTBx/BexrqTNmF5YnQPRHmTggWDsJ/4EqXab1ktahDgXi7HruYVWh uH+8VfYNl+5x56wapVckK1u84445ufBdJqkggaIIbdWCKY6J6DCVtiAJdnWFeiqqdKeyetlDAaku k5CoDXTHljtCaBz3dCa+6MtzR3nq0e9cjDGRyhyJ2YtH/0WV2UgpoTAzBahgjiUwzrMpZBwv+SaY RSiTRTYZIeI2gkML6bDsFooQv2wg30zxoXOY+aSokdbp3FZ2Pu7sj3p8M6DWntHkKx2CvU77oM1t zul1hqD7aM1Q+F6IcjOUviyUdNDqSTxeUVmfc2NdS3WMfRwvKLuZi/MLTFButJK3fKEBjRKzzsFe hY/CfMI4lT/xIOLamVo1RvGjkP7aABln5X4O7zjwmHqt337/dNF6Jf71Pnzkv89H//v39+ejE/r9 07vhr7/mf6g3Pr37+Puv8jn9pX4/H0GY/Tb6cCI+/m347/iU3Kmtj2cX7z9+GP7aIl+ukS/JrIJj /5J4A0rZEqlvFAZOYZimY5Sp4j/wzV/PT4+7nc7h3xswjYlEeUQXftRODvPJvXBuZSdz3OcAo2S5 SRAcFH2BKwq8iWIZrmtABgi3OhGBwEl4xSUOcg/ahwPsgYd0B3ZDRuMVEmOEy5aqIVgEyhMK5MVK HZEPxkzoX5KV9C85MNRr6jkuPaY/hedXTxPRfhWvzJExTD9SUTb9++ni4zn9S8mT+Jcpbvjp+D2N R5KYfKeAAFnIfBwRaYlF8fmE1VxA5yTwvRaJbxI7INRUfMOUmOMAt8ewrtTd7ZKdT2TZ22OUGPLg GyGIJmA8LifcgwRBStgHLxReGvZpEnlMEOSKr9EAitsSkEwACRqi4xW1nGB7A/VclyFKTZAhYlOH S/kPVYlYFoHZ4todY3MhzYuNAWjAcj5FeTi7SofUTZxXXNdImFBJU/hX1pCvE0aIkeh2cGkoSWY5 ey+ovowPYR6IRWwwTT6umkjOKzif+GmMwjKkwRG82KGr6As2IkWRFbywl1gJ5TurmgN6J17Apob5 jQfTAJaf9NdOsK0qJVdmUTMBFPaZOJoYWTRgWlKRk4yFwJEUgHTG6KNyjbHMlkosCcRSvttj4xnZ 0/90h9KBL+ywxH1/YLi1pBRplLSTwxWnGePx0YfTXJKC90gWDrq9/vd7RG+K61qXtp3du7sdp3Iq FWvHqX0UpNG4NAZ/gEzJz2HhEtqvcgxIaAz9IqIUcmk1j6kOlA9i0SzAu4ZHaEFCPu+9eqSOWEFW fE4XPrqNIIsukVTBzadIlFwyboZEnLAsRYOPWYTSmOGvZ++Gr7yT97+8v3jlfTpDyVw2psOffE5B JmSZqMXguDTpA+CAYKKEFGRg6QzaXK5sSmS12r6DTkwS+XpkYOeDi+N3w3Pvrfev/O9rbIn32oS4 4qTVc6gFmb27GB55f9zslHbh7SZKyUJH98kVinen1N6KTy9jBis+Tau4xl7W9PNGLmrrjAU740no yxFcYpNSbOELzmvNz4GXfP6KXU5W1CODWFwyKE7sBH5HVD+TFo8iKCq6ukHOL/Eeikp2UK0jVQGw Linz3voTVckjORKfRTE2SlkUPC/URiSaQEn52iz61TYt8z9QCRtX3ZJYhUhE3QIKy4Bh6tiGziLC U0W6HCQbtFDhl2eLCDo1FFDp7iBByIo40kVtijgpaBDuCHjKKl/dwOPtgNIGswqTyhfYLmPRyqmw GB9ZzmNuucQGFmuJcKChNkusgPq9QdDDpNQNAqqHJfAVyBF0UpEmTiCTvpJiWnIntEAdl63NiUEo 8SfDDtraQo8u9QQ22e/x3AfW1sTVfYhkyrEE8JG9cbzwsjducM+2Zb9R350dVuMNgWoR95Wp72Jb jI5r5Em/f/J7eUD7qeW9oHmK/umy+6+rchzonDHcf2Yikn5EmE94E7UVuupthujxe6sEoMYBQnuR 1qLGlLAF0WrDXYCl66HolwPJgb6PxFOFTXPBhXkow1x35xSPeCOWr89px78FaKED5BFIRBjZJ89H SoRTBHIMfWYy7opIVOcM7nZG+wcHpzKboIG4MPds093k0zMVdpcyhDkiJM8ySLEGiSO9Qe9oP+9L rsPQOe4cnea15naKCi5FNg7vo9W1UVa4SJjuSBgL5GAdYe0ccaldb520cdht94YHcmfMbAEVI+UC mAI8Bn01GMNOdqSd/mGWFXVMY/CT08Ep2qQLctSjQ8qrWIRMvMkuq43GZtFZP2hxOnV6UWDyYDAY 9GTSTMWKi58LaP/rP//fZoggYItDVUHilxqbi0k/NB6gslM5LVrfoIpFb4hVu3JnMN2m7OgPYXJw 6TVMW01kS2+b1G6UfOAKMqg6UocTPUngThQOQYRgSGmSqpVQ3VhlyrVv/g6hFnL4NJB27U5vdMQ3 FRTvCLBImoPu3vBA3I3AsqUiFn0BLc2QeQhQ8bIoOiWM+3WDhLzBFttj3gthGvS6L402Ck3JxU4E +RyuYeppySYBnAJO50kfwWWOY7pgkLsheKTB7skNUdxnqDzqR81+NDebD48NttS6fLUqz7q3mTdD wzI4d+Etdq27q7U+sm/hi5TD9C+dw2iLqSBNQ9CWxmK82+dX6yyXONNHiQjkjoNlKo9e8UPmD13L rod3IjpvBrNNYOVFPmxeJTU3mVahyN1xqX7NJONc0NcTC1mvIqbtHEgHxYdUhaJzg2qH4tyCG53J /fpIdvp55a3QRl9kw83l5RT2iRQakWdSfEGxNJ/3a1lcQeu5ayBcXKPxh2uw49N2d6Q0MUSDqHuN 6/369VLvG7bWhbmwdHZ52esPhgfy6gA7+pzQ10PzV/iRXesx1k99pN25vvqEsuS28eglPbdqU/0/ ex8TZW6dXJz9uUkcRkKmxtRkv/nELvvZeHGLeWIt2ldTkCqadWHBONtepEWD26VQ5IdL4NxFfQY7 GSUhepqRz7KGHrqn/a5S/O0jwXnVdLEVA1yi/8XK0itJiJtcABPCcx+ZsoTpKdqy8fU1E2h61D/u jlPVNlcaNqQR+2pI5bMSjgtJ9Wwvhfj6niPhCSDPFagQHs1JDHeiyGakTot3CB3jLhUR1ckhyjGE jihol1cESSCcTp3qeYKZNjz3hiYmkCvOxy+OrNiQ5LW+WJ+i6cxG6L+E/ABy17LCDL0fLnDOlgKB icxJL8Fmk1udrhYJZFol+tnB3UuOVdec9SflKwqGoNcUJr6d4s4E1e02V7dMPsdreReFgiZkNZxM oaMbThIdEkN2cWQntRH1xnKtWpfO9iHMRSnhVRqUCcM+wqbaRU5ZRcAdc2A3im/rBNU+7h71nXds yUZfxUEcU5Kbbc1ciOiKoMsEnvcYXn/BXRRuYH9cceDNoJMcUBxEcGMjlqrHgGYoS31kLVelOWYK TOV3su+6uR9WipcwKVRowtV8whSvLUAcfw0PYDv9Ws5UBUZDhVHZcLg/he4s4sDQf6wQcyqr9GKb 6HBSLokQUHHHH2AacoRyg9YRPhPLVsydDtqj40NbRMZ8wpg77u+1Bx32zDHm6uKZfB0hMlFRsCKW paKJSic3/BUSDw0ctSZouoAzn1iBzu7tqFXQF5iniaeW56RLJt9SdOFyJ/6MID2uZIiTHeuoj79X 9192XLyPqvGCsQqmE8FmBt61nwRaKjV04V6RGysY4H7FN0rK+LutvxauYrSiuzPYP8XNGoqbNaFi PmEqKwWYREiC7bACvRjObk0YZb4e3yl+5Dg/TAGJZSqQSQAZE4gDdJOhRV1J8xnEtWrcYWGTaUi2 QsGbUFnAVQRhIQ+O4hiVKyNJUnzZhTLl+EVrbVJqc62y9ogdHXTaEJiCEMljzAU3TZy+UnqqJWxI T/azUVzouXZyFFGgJitSgn00Tk8lXzk4nLqulLbdgVGoKnkrf+48DG37SrjPkc9aFyTVqdQOm71N ktgGrF+YKA9bPswD8hVpFywwWRYHdSCB/E2zONAvYkDORN78dTPiokzmDeZe90MmlaD2thuDjtc5 0qWgrnO11GCZr/IVzmbY93wvRRFqnQqP0fxiMJL8I9iebcorXAELvqcNoCHRdLg4ihOS4sv6lPpS 7cT1OQzhJ0Qm1WfKlcxv0Sh33nDAIBoGkSgxtBoXYPW9O7jCusSG+uJ0a9PHthfnc0DM7qTi+5Vj b0IZjSG2bwdnLRUBcyyE0+DXnaLqWihrEtw+v2DicFLefx079TKLcimoMaBoVElkLQq2wSdUvBks qGCBtUBEJYvr1afSKdinpvox7gPBMjF4dCVcvlT2dZ3Q5aYyp5+FjUg4fzf89M77K6zh3b+TD041 4p2jEW+wiNJ5aWv1uY/6g4ORyuQQAj3ALQjgeNyqG1/z4UnHNlwq8thoYHaYGpSq/65sOiRRLcGq ULiKZ2E5Z8aFYgmRg8rqzjAdUXa6QmbgCmgSPjQqucg3jQrGF1dC/0G5a4YKcrLy5DUPEf2CYsPF v1CFDlkQwDRqf9d6UvglHK8440/uviGDZBNt5GZDusoG5BHIR6dD/KeoxuYN5c/lZ5RqiplQ2u7C n96lx6/vequLPn+n6cB2tGIdzgE0Aq4YgBQf1xAbQKtN5k9kgdwynlHNNqUewKHDd66LbE6pZuWH hsC4CxIdzfbFUAq+OyOtntTXSWAEWinxy00IGgbsEMIHRV6tvJAdghAX0ku2yF3LEwi3FK3VnZPp G2OfLMD9Bci3c+JUg1j1coVVzqFv7BkHX7BvDxZ6hyfto9NiZbhZga77MqTQ14Wedg7ITPflp+wO Gfa3b5Dk+7b1Dt54OArzpEkRD1dZlZx/hlejydtWj+zaci7qnjUXVa//909Hw/X9Fcp5weVnuswp 4FuBgAS2HADZvIokbiGxky0svFdMjmmEkdpKDzWwdCyIQ4flvv9vdLsWl9uSu5WkJcjfWDBXUPcO Dv8OulBhQt1iYtkuvfUic1rHigipiZo+pFN7V+jWTScCVRziMOB7PHhmirLkUkHZqmYcgGuO1aNC /lKegy6oF87Cwn4I94udYzjViTQT5lPcPxZ9YSBxsqCXMxiVD366yZdCKKhEXN8JJx30OKO4FhMD iC/oRT23nJaWk07+UQPPn0kBG3OLmzasXqAfbEblBKvYeo/+T1T/EtkbVPP86GkCrCjNRVODndEX XJxFt6Rp4bKvTVKNVmBg2ZK9X6yzFrKK81293V1T2674XCYOf6Nb+BAEkHht8v2Pi4EfggSYmsHF HvqeGNv5/CT7/DMqKcExg3A2i5bUPCS/12s5o6jeNJ5NqO4Ll1NCY4hxhMKxIPSHFDca3tGxLTUL OC7YesR7lKVBVgUnJqNKFwcv0kJ3RKAQM+CcFx1KhN1ooB5gKV2J/Mf1pkdJyxaSStdysCyCFs17 OXkmV6dMKfb8W7DhjNKLKdEj4oxrx2ajKlQNu0IT1TyjjsCq/eCmfZXXHEh1Cm2IvADX/85xn1Yg fMPWWjFji/XO8r7wglVRRAnmqnxI9EhjFRj7TsSYZ7JQNSERMYwXWX2+iHFhBncv1MukpJZN2jiZ paIGiQsyhcqM5NH8FuQGVGTunPQ8FX7UQjPmk3ttdBPSkrZIZQNECxiPZwtyjLNsC+7bbUG9C+Lv 8JtQH5VVKu/KtJzGZdOvX1nTZy5TuQU3wYocgQRPTtkGcoVIIn7haBeAZ8e9xVYDwTnokO/dYxtt mYQ3VDgNV4VyHItMHY5uNCDJ3sngtMcGudYxrroZpvk6k6T8iVctFvieMt2qeJekue458e3Z13ZR o1oMNR28YpTLEPnOpbulGPiKL8ihTS2Pc3khQ69kp0KQ8H7+S+olMaRMnskkfO993hBE4ujGcdFP ltNsKj/bfNc0mWHZIM03LA8H5GOkvNrgEqcIe2/GKNtIWvgvXIP6ttXvsRsH2RHrN6jvd/5Cb081 AFdj3cO8fTjHfQtLczJ7BTlppi6fTy561taI3t2l5thKS7IIGkW0zUeverM8eMXCqgZgHU53dVYv hF49ONg/OVD9wK+qBi1D5e9Wdwkvg9B83KdbrWUNV7vLbhVo39Miej/CIvr3XIRV8SoIPE1sm0/u perdWw5JL9bjNZU2z6BaTcp8/V5rt2K7f9Dp9o/pyGqk2li2QI7Aqo11GKnviEt99GoIGBxQ4WAV s/3M5z1dfC3vs3bRlDZnlVWDDlewxkW3K33SPNMZtwKjLwwpGCIOreyXtd64LicWaTBN9BLoOliT 7MxAKjsa/ym1qPB9SbojZhxfjZIEWKRmQW9blV1BSMLpOPBXaTE8ah9s3Z9AbVVpqJamm+E28WrN zVTBNM6iIXXtteJgOEWYQnbDbOAFNimvll/M1+/FL9qKygdQxZqKOkvLRcWaUZD5RZ3Fvn96hwp9 B6UxIljtYcTghIposywoeFo7RhTxt0quJzUSUYsxZ4kv8knpVUPrIb6swnB5z+oUHxOK5uPaV/5t LNipJDkWbD0s5Ptq59xHszb4/dxtOk1XoJjZ7amPZm2ZJgKKln2jZW6IWClHJcqLcswVJT4i+91J hPoJYkcwTmgub+KLpWC/U+g7Lxalk7Q4fklqFUNjinZKxw6dlYUedu5QmSaei4PZF0PNvLnhLgW7 i9wtJGfJ3VEFbsUMpE1IZYP9++hsIlQHqmcsHP/jFcrIEMRHZsBnwmvuEWlwGMqdU9AZok79qJGt +ToTkbb3X83foe2gsQLHccIML+PfVqeA2MfKY7c8j69OKDtFbDBSBU08eFwBYdlm33ipTwxg6aj5 1gAs2drfGoAlO9oGoPUAMTlcT7sxnzDva3HCRkfWvfn00U9mCblFxJlP7rVMK2KlummZ0XzCM2q6 qetkHuY17Hm5OszGm3h2g6Ay9QSCYcRlGvLsoDxjrchYs2YLxebaRtGRqNtg/mbWlrm4WmvLfL2I ix/xgLmMrneRXP9kx0MWT4K7tDzFoxLpd8b97YP9g761/aP5pIL+7hF8MelaF6uWGeVPJLOfFrEF jaJW5xanSCkH3/qdKwvLXPMjY6MJYRva28YieSuGQJlV7tICTYnjy29pYshr3YUpGltv5VIxH75a SphPnkMuWWaUrlCSAnJbP4RfkDxOda+oUUKWhWi1I/LW8Bvqm8bcaJ4SMFSOEvvq14VNHt9Ik5dH iXS2G5SIBpeiGAr14Xj7MlqQbUvf0fWHMsqPzHJqjY0HMjMgCecxIux6ZRygo8trhft5gfwVuqdA U30IflXa7Z2HKEclB36KKiuusaM8JFRriWZAaLtPKhVq+65FLh16PKMnxzUqfkwn9k8qhDbOZmtq hoO8pvMgnVJWyNOpSgEuZdr9MktxFXUaz8Nd1NqVb6UunXal4Io4JomuqZ5ud3JZkIn2EdYRFfG9 ucwmBKU5aizcK3+iwZ9Wq3h0Y81cjK4umE9YLEohhZIjrFMd7WTEFNKs6lQAi7lbln/DWTaNV9dT 0Y4Hkkbm4S7CkC7BUbdrqQ5YVBY4xWWS4QLVuEj0pZ5nUswVSMSIVBjmFxJ+UfVAjRY4r6r4naCd Bp6/wj2lAh2dk87+cNBSaNMIynydMS1/0ghKZSfhXwzxlJlOOIFExdsM95ipua6SnaORzDjkx8Q0 4rUcn8a2M7IqnFksmYrYVYgxsEWjNIEGOpN/zNnv7HDkux1ZnuEWxY76o6v+6Kk/+vyHAYlVGJg7 JC3t6g21xDW/4w2V69xgKxpvuxXZJvZ0kWRuw1dnlEoWeEKMgeuKCQjF6A1znh8V2xFYvyscjBUb hz7YkVDdSKqSnF1sLgW/XYGn9tFKjSbN1bK++XoFidqdHM0knQJW2QkVW/aMIlZJ2NZSCNjWUsjX 1vKJxKsFx1oY2qmAbYZjK0FYdZ3qs8B8nQniawNrgqQLWPNJBbD3LZZn3adcIHFQXyBhqYdwue69 43hOxVEe0rTipCgHy5UUg8pKChMfzTElTfiLPG+NyjtkSREXxstLNbw+chXFDyjwocC0THOD3Xy5 StG/JNy9Nq1fULDSlErhg1Jk3KWEGVpPYdSjo26vfdRyfI47jChuLlpvkJMgwH/kFRy4Mw+GPN2T zOoYPAu0H+XuPI4J7nAnFOItcAdgcMKMLMyC/4D6Zd0pr8TVisrqURZvrKcJ52oHkrnPRbpvvJuD tgGEA6l+p/imAxUmhRQ/1KlB3zfr9UOuWeQumYh0rMF+8kg6VoOBkIsAMwz+akF1aNeL6J/UFSfx 0PCX3E90R6q7f7++RjsIqu2h4CXr9PYPC5G6JyAi+7ymnCgCXLnBGzakMATPBqTaLQLkIiIxSfGL qiXY0SFJqDp1xP6ZIrmmk0NFBmflNFj0JBlitnvQ3z+VDav9VWU6I0nkBvRJFZwatXsvHiblN8Mu cpjYTzt5+Z3zie08HRTP08bEsKmOoagNRAQP/KQk5ao2xSfFRM8fEB2SpNN9EnN5L98E4AL9sLfX 6bpvHSmFEg2CbkClTef36XSWTn9ON8TtqEThqBmQ2XTFkRwC5NsQwXbS6smDuLgcfavrN0aXbkUi ItoANuHpdM2h+yztopB8pa4RdCjpNs1V3kVsmUQ3KIW4RpILNK1bhGk400Ve54CftM2mpDzXLNJO c+w2HfyyNzKNK1lBZtTkkSU9oDSFh5YbVcqwUnF+oVyYKrP1HJcoUHunKYPmE1YGNXw1VwYHe6bi pqvCFBhjsUGXeqz5RerTECeTFXgq9rjnHfUUDFLqyPPAg8K1E1kcU0cJuomFmkijMRX2Q9yCLBQ0 2qB1TFDfE+48EH4ZwzGvei0iDIhj5rOTCOvJQ/TXsG6xne5BTsW31QazsTRoH+8575m0Au1AG90w EOwWbnaz0pv1CuXqtnUWIuz29geH4gZD6eOwWuIdZc1Wt63bawErZUv80G6J663d3g8/DGFe62Hb AsLL5jV3w7PixFykbl6bT4o86HTx0Ez2wIS+EO77pl9TDIY07iduUT+6Y2G44hF5E/LOWGb4sGAi 1ZN1JY3KAIoOZ4IAOALhiNOLDumks/Gl9vuH+00u1TIR+cgo/iqbKiS83BnvAyoS3rCXwaDD54fs +WcE3REuHHkB/kmYjpOIOx2/Qf4F1A3keoRGj3O6MEBUQ1LhCOR26VR//pU9/4wSl5noy/kpS4CL n5usEE+VXtQLlLm+8T7hEo4IcfW8R/LPym+EmAVSlaAsAR3noisYua3SN95H2VT858UNJ3nhDiZQ DB+xUoUcl+97szK5VUs6Otw7OrLermS+rqsJ5RwV810ZyKse2jw4eejHU8D2rQqY6ESjqRNCH5Aw inPvvXKSihw5nfwMort9U1bEuBVVE7S7jaH9Tq/fEb6H3KVQhtSuoA8RNEDWH7EP+fWlTz/3hfGi 0vzKTNxJzBmFhZXls5JOr3vm7HOiJ59rgAIJNF0J36TCwYmqwZuO5L4qrxY8v6arjEE+UelmC90+ qp+LmsWRE6B4uwsryNT8UF5kwojJbwAhS5bte77IqYFxXgBEo0fzCbOlTo8OU61AeirQZvBTmfTI QawSZGFdCj8Ih6TyBhJ8L4Xu0WMLuokjy1xMrUgyXy+uXRk90vY5jXEiYXPHaIJ1EaFs1/sQ3nrn MY4taSAm9CaJA/mFA3efhCNg7M1DJOVNRKrumgNIZURRFDpp4n86xrDp81doVohbL+G3EaXJMOrR kV76OwmluLKZjgeIA7a+hdFPBhcEhay/RVM4ckXRO0x/uDfjJtLakIC6KDOF2szDbXEZ3sXCkeal Y1RviYxlGHjNOdWfxGO+8b4BsW54sJiv8y52Rr3RvrgNS27GfS177otfsuz32CfgPlg+qaTsDa17 Dt9bD5WDw/b+SY9OumIH+r1OfwiY5BNGQW+wPzput4gGhYfNLsuHxcT3qi1ld8//J+3adtMIYuiv 8AhSHqgg0L6sVNLQD+gX0CRtkFKQuJT273uO7WHN7Ix3q0g8LnPxeI49vk7vFw/aaPHUPO3Pb2Sp 1PRjSGw8yrQnSbXJJwpuizq927RB9Pz4xVB6uDfJ4uB/xLVXmTFfeZkQFxSy7Y4hi5JU5Dzq4UZm fnaEKQ9/50x9Fv4vBgjUBedt6oqsgBz2rswJmPiC+/0wW67X6aTOlkiQ/yGYIrkfOm9Xx/Ocx1gy GgkliaSFfHKOpayHfDV++f301LrAgMjtzy2aDiVLtwDnEElhBEqTOoF4e8v+5y7RwGVScPMMdYx2 JtYTRsoGMlktEQNW6NcAOXNmbQ60+sJGtd8Bs2HORl1ZorbYvq1oLbWBzRly5CC+f+avhNw6m84f lwoNtcQoSov8gIJDPqLH0wuzTLAySZ95RUZCZ4BEbNmjsxw3WrUqXLNn6PINe9+p3/KDCpH2DkUI +m3/43ShlNTuQhLvTmT0XZVyUnpK+CuE1jxMGIo+H3B40d8flsvF40cRC5Wz59E/7y87aRg4phaQ WeMzCOhfEJuKoZqttECI1uYpUT5jktmaT9XAuvxHQO77Zqa2HY2wnC/W9+Y/btTtFn3ev9VwttWX 2Wxq8F7esF6pfJD0hPUtd8QOYBrO1/0KzQbVa5G+RUQz2JXNeXJ3Ri4AGvg6oX/Sy+bC2CIy9POO Al00hicllBIJjIu+758zQ5KM3/0NQmV8YDl+uxc2Jt3AraAau/Q7ajs2arlf0cbHRxjYqbxf79hV r5nIow+hfkfYwGD/AuALHhBV26dfmyDoXYa5G3eAmm2ES1gUi0BHZQXDpqM5ikJYo7y+3d0oFfTJ OdYme9oe8HwAwp5G6Dog7TD15VibT2TMajr/NI+wrjxb+UYBCo94wVgx7Ql4/OrYhw7XvsYprPVh JjKacKo2u788x0pJC33uuyIY5rkXfQZBq9ItbPu7r+9Yv+2GT0AoyzuV1Tn1AhHPDdJKMVjDsnsy jL3cpZITD3ww5dMZIoUt5kJewuL8G421MjoOsy6igGW39SnL6SEQTRk1i38clh/Syjh7K6SrLuU9 yXpdnFWkNAB8N4Ql64AZmtL8sEvcsdUHuOEwgtFg80YFAUmCf6DsIpxCSTyh6YKIxJhjjPAdwcZC 8CH9qOuwZMhtHFXWzCuwlPK5uRqHJdjGFiulsnotREYryT8AAAD//+xbbW/jNhL+K4Q/9QBvYsmW X4LGOMexu9vui2GnuAMORaFItC1EFlWJjuP9dH/j/t79kntISo4o05adze4Wd1eg7a40IofPPDMc DscpT9wg4im535I0pl4w3wbRgrhk+OnDDfHYauVGPtkEfIln3E0WlJN5ENLIXVHCly6HTJQGKUZg c4jELiRD5rmc+oSteRr4VLzhS/rj5eaK98V/k/6P+A/Bv3g9va41GsNh2+6Oa+I57wdJWVQ+J0+r 8CqNXY9e1+KEpjR5pLU+WTJo4gcJ9ThLthdE+xaTxeLjuDhZs9EadRq1/NEtnbvrkAs19DcT+cjp jIYNqZlUm5vVmLE537gJJY808lmSEs+NyCrgwQJIYPVBSpIgfRAwxwmLaRJuyaMbBr7LBd4CNgFp Kt4+AjOfBJEATV9OCbXbsTO2bjPUCsbZDadhkeF+YAEEtl2vaMQvtI+MAA5unIHdMQE47HTao27+ xgxgf7YGq5LtFRmEfMnWi6VcqCScQAaIsAi0Woc+uQd2CZVkclMCSIPIpzEghqIEsqsgTSFdJ3OW kJR66yTgW3yV4m3iejzwAKmAUZmFQMqnjzQU85DZ20+/vr8lK/dBWIjqlH+eBsq4sZizjm9Dymmd bDANJT+s45C5/l/qUMwnUNMnP/hsE8mHwn4s8TENZ2IZ9AnaSadQdpX0TU4A2x5ZMHMO6XSSCFaO R3ZvONg9LFBYF5cWsEbNUacnaRJPJInjGd+GFA4ACl7X3kJzkNCqXUrvzGTuGXuAmR5mIBaHaOBf 1yzpNYKo17Xf75hnd+1Ou+m0bfFpgZyaksqpp3ROExrBHhq/Nlf5PCMRZ/JZMk32XLfEPG0egz/r 4hKM7JEcWYEhQorwwc2VO+dUwFsEwugAOshf0SYSWKGCUjXHSrOJJWiwb5NmtU0+smQFb3uk5Bzr 7HiyZx0jLDeDVrv3zN/jVM2EC9bRqTodD59VLZrpmUcaNnYBG3zYbVsgay+jqxHNZvmLZrNpNTIw EZzZfJQkAJxvYzgBtswwlDMa0S4sh/dvEtePaHlvMw8JZ6gesE5mF3VS+4VuyQahJpVBcJ1SEXoA FAIfI+8iPxCbMSz8xxqbpIjw5L0IgWmtTm6GE2K16kKa2JbVq5MPbuItidXrdfTQ9IxvwU9LOBbe SLxOd51Rz3LGI4G8zAiOc6TRa942u4fD2R5HMKpyn2TMRKqzufLS69pdILbbj3RDpgxJTkYmKVnh cK0yRUAqZA5mg912Ws2h2qLNmcMwYd4DTerk9kLuI6XwaObHEcoVJux/ekTMDcOThjxIueKAdTKp GmyRuKsT1bv44ZTBTlHMDO3ID5ATptiga4P1QlAfedXNx7F0lNk24u4TmcmkV/gI8ogUOQnewzOE R5SUE16/S1gL2wjvO4ck1f50U0TQbsLf3kGTJEIq/cENQjLExCzhwXolCXBLV0g5diLvuQ8v/8ge 6eoe2QRcszybiJa8f4rDSo6e4pbHPTBz19Oi9E2WR2QOlu1kMg3h/X8AZxF4fjOuyb1XeYDKWc6M vQUlXyf2agN+y9j75QYrsDXD/3jSA6IrUkn7gLIn2GfnHor0VtdqtgbfMPAVJ3yVwKcN+MWBTxvt ywKfNlQhxpV9yBCv8kfKRgVaHDoVnjCmYsq5AXZ2d0vaXRVoHRkUf3ajNY6FxG40uuVp1Rx6SmJ0 i2xJ+ToLcUx/83pnAX3c6evOqDlio+e8TqBUaE5Yyum5uYH6tE5+VskK/jel24iFfopNdozCELlL 3CjFWY9MEsaZx8JaXbPm1zAbd+9TqZl7D8vLQ60XUjcRiVrMkOy1mlmuCslcIqRzvhNwWvLUh430 gAAyvGwHyyczh1AcYeVBVoyOeZ38K33fE+xHti2yDGHVOvmE6pXa3rvO/y7NzWmc3ISa3d5vpJyS VSbHewLl7FTx+S3lSyRdGk/BHGPG8ZyOym/NKmO7UA4yLRUkD41azJiVTqPw80v06Qs/RMVsjVpk RBeMB6qetqLe0o2CdCWTX1HuOuSt6jQIvOsEQX2NUhpyzq5OSsMyBLIZNl/Dxc3eJmYSZ7tvP2Me mc32F5RtthGu/4yUBUUmonAweuIUtXucPkSlYHw3yc49QvG8EoDNeO9gsecX/zd94UJCmF4kNDB9 +WiPmHCSS+8Hg5cd5FUgOXL61bT5fj7UP3AIP54j6hHpy7UvnO+yzfpI7dF0qjWqYKyJHs4ZdfFz yvenlIodke/sl4rNpatMSUGi0E35lOLWJaH+xF3QG1x2PMiSP++/i3D38oIyspMXBMQE2v1cCR3t rAL9yyVCXfxFiT0GzQfWZpMOZI7whBDp6Z1e5wVB/sh0/V9wu5oG5yYj5+q/S+EHLwhKhyfrv2U0 2rvj2dsxZN38OZM6Mp5IZ+4mqJGpm2hx07bbt84OX5px80lf/cSWD6zNdpxKYFP+z5QucJ2ebLPN 2AHBnjdjq3F+1NPUyHU7d9H5oadwPKo+YekS3XYWZw6OYdm9togK2ilMH8Tq2N0KEdtq75/l9FFs J78DOqhLs2FXqdtsOVXqNrvdKnVxNK1St9Vx9o+v+oocq1ulrtO2qtRtN1pV6rZb3Sp12z2rSt0O +gQqzNi1G1W6gFFVuvQanSpdek5+d3OQDL1ec19drX7QM2CrCVjdqhKE3TGAr43RbBtcSJNoOQbr aBJOy+BjmkS7ZTCfJtG1W/tk0yQAx75lNAkLB4sKTK1Gz+Cm+ihWz8ASXQRNChXaWs2OgUj6KK22 cnYkeaCJrDYZjqQIr2EQ4WLYxoDZX6brEA/cNWeK8cX6UAZS+X6SIt8apIFrvKXcXKWfMbSscuWh I/2M617tGfTU7jKNyWnWGYIvZVKldorDvSW6+DnJ6a5n4EgfQ9ucnMo8cS9By5SUe0V/4D1EbBNS X97xndBgIolnRGTQshyrJzQpIFJ6WNw7NXGVe6pHQrNSlqfpfCdawnzmyZ4rskF3E3raYnSQ+WSN 7G9B7Dd/w6X+m0f7onHB6SoOcYt/4bNT+rM6uI9WrTrlXHncsJs9vT+rY9u2o26oDx17BnEsqCsA yy7SxeqOHQq07kHXZzHuO3W7GNHX1SvW0vU3EujskVBlL780l/kGlUl1oZIB80l2HUj/tdyzYGrR nTWEauiCk5/3YVPU4Mp19qNjh0gARdOkSHy9MMC9teh989HghpZH9BbKvsuli76dALyQPR2gzV4L GzilOi+JJ3roRFcd2g2zdkzBvgQNT1faQl7VKmX6K+4pVJacx1eXl5vN5mJD7/0ETUgX6Da9hCX9 tcfTSx5wN5rz+FJ0/D1dLPlKh/B7aJqiH45DJ6lpNW7DkTVoD3expBA29DeSzdkjgc6JuGkK5Gzt L0J274ap58YKUFxDaIJG3HR9in6nv/mqmmpq7qFQwIf3dyyBMX7PPOTCTeMnbQzjUvUCy7Rqy9PF 5fqzR8JShwLmW+tNxO4+DSMWrVel0KlvLdqeMFijHzZJ//3Pf5GB76PFOS2dpF9jRfr2fuqKxsEC NwoqgSlnKyd3U5WJrZpYVUCYiusvTj6lyJ9e3Yp/0jX/JH11NhxMRqInyDvhbK/zMaPvcNBq3RoD zastPHRlh6xMOmn6ZjDNWK3lmPtOqxSTQU1lDkfHEW1MMzR5DyLOooDVyd3fq6mgL/G/EJFfZ4Nq FM7khS7+BUHgqD1FuMoSRj3qZYQ9gxeFVrDTg+Bhv3i19Ve1lIo0+dt4jjlPHa3QYXhVvnbaBWLD bwnUjni+hfoJZ38tZR/fh7fZ/nQS8N+MTC9RCj9o4RPNVjpvjcFuho+kWZ32TduSh5AlfuBBk13j PHxRda/76pdPNZLI310k7/ye2uHnjOHAdsoHOGbKgu2hKeZBkqLLZjeBJSsBm6tDM+zJ59U7tNtD b9Xagy7uIFqzdarmjhczURDZ4PcpdlZ3WeLPTlfVYDzmo/6SzRsv0OEuAGAxnrWURBIslsDMslBm xbt7xjlb4e+4/BZ/F4Wg61oHtRb8RS30+Vu1kGfhxZoDuuxHJOg0Z6EozIhSEZQQY6j6dsBDOlnI P6MI8FMSiB+/iNLRJOAetG+q+hnoqUggT9/3zN/KP+R1g/5/AAAA//8DAFBLAwQUAAYACAAAACEA 5fZdFJYEAACjNgAAEAAAAHdvcmQvaGVhZGVyMi54bWzsW1uP2jgUfl9p/4OVhz7sdiCZUtpmG7qU yyyVpoMGdlcr9cUkBqJx7Mh2YPj3a+cGKRAxGRSYIUgQCPa5fT6XnDifvzx6GCwQ4y4llmbUdA0g YlPHJTNL+3vcv/qoAS4gcSCmBFnaCnHtS+vXXz4vzbnDgJxNuLn0bUubC+Gb9Tq358iDvOa5NqOc TkXNpl6dTqeujepLypz6tW7o4TefURtxLll1IFlArsXkvG1q1EdE8ppS5kHBa5TN6h5kD4F/Jan7 ULgTF7tiJWnrzYQMtbSAETMW6CoVSE0xI4HiQzKDbWmxg280s0vtwENEhBzrDGEpAyV87vprNYpS kyrOE5EWeUosPJyMW/pGY4tfqvIhGHQZXEoo1gS3yO0whhNN8nBkB4XvGtWfKRp6njIxIopEKsMh ImR5JpJ40CUpmWKm2TSudIbnrO8bRgM/Fcd3n0dtQB5SWsonnyCZ3gw9b1M1/iQCW647mkMfacCz zcGMUAYnWEq0NBpArUitJeOED5amjC/OvaXp+ruversjg0x8qoumMMBi+5+hOtVvGHonJjJkIa2R WGEkZy8gtrS/EHQQ0+rqHxYNmLuzOZZvkYxZIYzpUo2px4Pk0VeD1bGSL7JfYhNpImUS0fqOhHSs B/Cv/JBRAYQrWJlMRIYMTR4OhZPYtuGpBNihjKUZAEV2XMTlvgbuOHZJhnCZuGzpPSACMYIEkMFr KjJyJbbJKvI0hW8wnUA86rSHvbdgQOxahsPJNScOclS6FwE3wShM+8zhYMyg/ZCR9Bi2+AZJANkK GNdvgawJjAyDU5pClSEm96EtI5nPEEdsgbRW79F35Q8TZOSMDTHFTmcOmVwM8bfxypezJ2gm09Cm f6h17xIu2Bg9it2MwKAf8kiH/eRxR+U1av/T67bHPQB+/Am0Ww38+A3c9u5vev27+9v2uIggHPmQ QYG29I5DNKFDRul0IyJvmKTVVObdp3oOhT1WQcTZkiOlvsf+FjDAtwCviij/ghDfDXiFP7DANWgH s4CLi1wBeQ64x8tegcu/AyPkC+RNEKtQPyzjvALUG+DOFrTCXBYjF4P5e/CdLipHDyvQiwG9CbrI rkAvDXQ9r4ooq4z/AJJrzDxp9tQ0L76SL6Dz8zL6WWD+EfTRhIWNhQIGqECPGoBhFzDHTdNL6NZZ gP4J3EJmz6vCvYx8fhaIGzpo+8zFFeSXA7khvfwym3IFMtkrSOXGtWzDEgS0PnTlje5TdyaVFAWA KNKBrlQt7UKlQjW8b6s+9lwIVQs4925d5aul+WrSwrmQKFyyuidPsCXre2rHrdQ99KbDy8lAorWJ 6oH3VHapt29viAp9B5KtellP7WWdwd6TN1j8AT6U19VI9/+o3SD/ydfpr7OSvWDrHqNa9FFHMqxV o52eu7YRHbGCLVBjVA53GEprYD/lWTmn/XxEnN/MpMM1y3M4qzxWZ+nb+hlg/rvc4Hfq6k89BZO3 +o+4xHf3zy7JAqcBW7SSVHZgxZYpBE+5A3pji/vzxWh8fd/oG5pK3eFzF/Kw5ykOxWv9ZIb8JR8x a/0PAAD//wMAUEsDBBQABgAIAAAAIQCYc1CjkAQAAEU2AAAQAAAAd29yZC9mb290ZXIxLnhtbOxb W3PaOBR+78z+B40e+tA2wU4ITdnglgbIpDNpmITdmZ3tPggjwFNb0kgCwr+v5BsJviyYQEhxZpLY 4HP9dI6OpOOLzw+eC6aYC4eSBjSPDQgwsenAIaMG/KvXOTqHQEhEBsilBDfgHAv42frjzcWsPpQc KGoi6jNmN+BYSlavVIQ9xh4Sx55jcyroUB7b1KvQ4dCxcWVG+aByYpiGf8U4tbEQStQlIlMkYMjO S3KjDBMla0i5h6Q4pnxU8RD/OWFHijtD0uk7riPnirdRi9jQBpxwUg8VOooV0iT1QKHwX0TBE1ak yA0oW9SeeJhIX2KFY1fpQIkYO2xhRlFuysRxpNI0z4ip50bPzZhZTciLTV4FgxZHMwXFgmGCXYoz BgGR5wZ+0PguUF3maBp5xoSIaBaxDquo8FRmpImHHBKzKeaax85VwbDJ+L7idMJidZizGbdr8jPm pWNyDc2Mmh95j00TazFIhO79GDEMgWfXr0eEctR3lUYzswr0iISWyhMMzOoqvwzuGtAwTr8azUuV ZMKPWniIJq5MftPVH3WqpnEZMulyn9e9nLtYUU+R24AdSiXmsGJdVJSY4An/MR5cj53R2FW/MiKY Y9els5AgfKjPA/qAUAt5FmreoUQKJdhWDu45HhbgO56BO+oh8lQBad0K1yHaBulbktBkDV6ov2yN 1Fm1LhiyFTCMY4H5FEOr/cAcdQPSxA7dweUYcaV8eNWbM0XcxyMVVMv8HSIk7+GHDDnguuPLiB9b MvFZZd03/263mr02AD++AHgDwY934KZ9d9Xu3N7dNHtFFBGYIY4kTtgdjhJCu5zSYeiVYNwtbK1p 9y5u9V0C3TQOGV7BZJDQI+aejjNoABN8m7jzIsa/IsTTAS/xV/ifgOZkNBHyIEdAXgBmRNlvEPKn 4B4zib0+5iXqq804vwHqVXBrS1piroqRg8H8DHyn0zLQ/Qr0YECvgRa2S9B3BrqRV0XkLAQyCoxi ZfxH8A2RCeKHWcnnIZDh5s1m9L3A/Bx0cJ+XoOv9hV1k970A/RO4Qdwel4X7wSBuGqDJuOOWkB8O 5KaK8nIqP5ysbp6obViCAewgRx3bvfTOpNaiQE1VpHQtTd3ZQqVE1T/A038yFgXlAM49rStjddNY Vaem8Wn319bpqWHCR4fKaYd98QmeFe3qvO7E/Io8sK1p+BW5YEsRX3qg9MD6HpBPUuCKi4O0KT2r G0Vn1hXZFmt+WLSfDD7AIuv5IruW0jr/kGbZ5lvTEYRd1RtpGMbZSat65s9nL+bgF+knSu8uKTBN F0F3UR/sQTvRW1f+CT4WGdjF4ilu6dIQ/KN+Xn7prBqYzTzoN486XTDGqGf0deVpkLH2KYbAIQfc pzwv7wbntyMVcLXdBVxjd6L2MraNPcD8verZ3FJdvvJaVL+mkTf6M3JMWjH2f6ksfUv0kDywJbCj 6k3XbqvtRUgrmt1WrJLT8A4T4zba1v/tohH2M9SK+hWb87rNq3aRPJha3hVBIagwlm18nhlHWv/p wI6Zq2um08J6L2oEHe/qJTDrFwAAAP//AwBQSwMEFAAGAAgAAAAhAPyV8WibAgAAuwcAABAAAAB3 b3JkL2hlYWRlcjEueG1spJVLb5tAEMfvlfodVnusZAOtG1UokLp+pEnl1nJIT7msYTAo7EO7axN/ +w4P4zROLCfhACuY+c1/HrucXzzwgmxAm1yKgHp9lxIQsUxysQrobTTtfaPEWCYSVkgBAd2CoRfh xw/npZ8lmqC3MH6p4oBm1irfcUycAWemz/NYSyNT248ld2Sa5jE4pdSJ89n13HqltIzBGAw1YmLD DG1x/JAmFQiMlUrNmTV9qVcOZ/p+rXpIV8zmy7zI7RbZ7tkOIwO61sJvBfU6QZWL3whqHzsPfZDF M3Ebz7GM1xyErSM6GgrUIIXJcrVP4600TDHbSdocS2LDi51dqbzBQbwu5VN6MNasxFbsgQe4Z4qR NE68aOpQ9Xff1adEzz2WTNuRCtFpOEXC/zF3SjjLRYd5W2keFxc3w3vm+1LLterkqPx9tCtx37Gq PfkKZe5ZvfMep2ZeBTjYujcZU0AJj/2rlZCaLQtUVHoDUk0kDfGcUKT08XxJFgF13S8/3OEID5n2 1RhSti7s4Zd59Wo68NxRC5nrmnVjtwWg94YVAf0JLAFNnfDcwTCNRW2mm3XBxAptgRk7NDkL6L3s /Vq09q2NDa+EBS3A9nBeU1uhbA1sSFXU1lRPpbAGgTHWLMo5GPIbSrKQnIkKWvonBWTLRvCeb8Np NCczLETeU0xbcqsKyRJzRMsbI6VFMsqYxhzaVbRV2K8lrHC7PJWVC2N1BA+2Opd9o1iMpkqDAb0B GpKb4d/JeBhNyN13Qmd4kS1elNx9IrPJ4nIy/bOYDSNSZdGhnlT2BT0GsAzMwoGkthNCzrWUaSu4 abYNr9cCCP5dvCN1e87zBREgkn38asDeN8zDift14NEa0o7qqVO6m+5GBN7x1xv+AwAA//8DAFBL AwQUAAYACAAAACEAckNo4MEBAACUBQAAEQAAAHdvcmQvZW5kbm90ZXMueG1spJTNbsMgDMfvk/YO EfcWMlXbFDXdYdWmXffxAIyQBjXYCEizvv1ImqTdUlVbeyEE8M9/Y+z5w5cuo420TiGkJJ4yEkkQ mClYpeTj/WlyTyLnOWS8RJAp2UpHHhbXV/M6kZABeumigACX1EakpPDeJJQ6UUjN3VQrYdFh7qcC NcU8V0LSGm1Gb1jM2pmxKKRzwd8jhw13pMPpMQ2NhOArR6u5d1O0K6q5XVdmEuiGe/WpSuW3gc1u ewympLKQdIImg6DGJNkJ6j69hR1FccTvznKJotISfOuRWlkGDQiuUGYfxrm0EGLRS9qcCmKjy/5c beLZyN8Q8l9ysLS8DqnYA0e4I5eR7Yx0ubuHJr/7rP4mxuxUMF1GGsSg4S8SfvrslWiuYMCcdzWH lxsq4pL3/WyxMoMcoy6jvcB6YDWF+Q9l7LatvMPQ3L8Ao9J9K7iRJNIieVkBWv5ZBkV1PIuaF0kW +2YR1YnfmrDppOGWe7QkLKksJZO4PWfCb2hG2WtKGItvZvHsrjnRLi1lzqvSH+w0ZNsMA44u5rRd C6Np512bOiZCIHgFVVu1b78FsUv0HCWf0BbU9u108Q0AAP//AwBQSwMEFAAGAAgAAAAhAF6kzLrB AQAAmgUAABIAAAB3b3JkL2Zvb3Rub3Rlcy54bWyklN1OwjAUgO9NfIel99DOEDQLwwuJhlvRByhd xxrXc5q2Y/L2doMNdISo3Oyna7/znZ6dzh4/dRltpXUKISXxmJFIgsBMwSYl72/PowcSOc8h4yWC TMlOOvI4v72Z1UmO6AG9dFFggEtqI1JSeG8SSp0opOZurJWw6DD3Y4GaYp4rIWmNNqN3LGbtk7Eo pHMh4BOHLXfkgNNDGhoJIVaOVnPvxmg3VHP7UZlRoBvu1VqVyu8Cm007DKakspAchEa9ULMk2Qsd bt0KO8jiTNz9ygWKSkvwbURqZRkcEFyhzDGN/9JCikWntL2UxFaX3bzaxJNBvD7l39RgYXkdSnEE DnBnNiPbL9Llfh+a+h6r+pMYs0vJHCrSIHqH3yh8j9mZaK6gx/xva043N7TENf/3i8XK9DpGXUdb wkfPajrzD2Zs2nbeaWruT4BB664KbiSJtEiWG0DL12UwquNJ1PyRZH5yWkR14ncmfHXScMs9WhKG VJaSUdxONOE1HEfZa0oYi+8m8eS+mdEOLWTOq9KffGnQtrn0ODqf0XYsXE373B1UZzUEgldQtY27 +qnErjE6S75kF4Q7VTf/AgAA//8DAFBLAwQUAAYACAAAACEATqvb62YEAACsNgAAEAAAAHdvcmQv Zm9vdGVyMi54bWzsW+9v2jgY/n7S/Q+WP+zD3dokHWUbt2THFag6qVfUciedbvfBBAPREtuyHSj/ /dkhCV1JImYmoEsq0STEfn/48eP3jXnz4eNjFIIF5iKgxIXOuQ0BJj6dBGTmwr9Gg7N3EAiJyASF lGAXrrCAH72ff/qw7EwlB6o3EZ0l8104l5J1LEv4cxwhcR4FPqeCTuW5TyOLTqeBj60l5RPrwnbs 5Ixx6mMhlKorRBZIwFRctC2NMkyUrinlEZLinPKZFSH+JWZnSjpDMhgHYSBXSrbdzsRQF8acdFKD znKDdJfO2qD0kPXgW14U6F337FE/jjCRiUaL41DZQImYB2zjhqk05eI8M2lR5cQiCrN2S+a0tvTl Lu+CQY+jpYJiI3BLXMFgTNadonA9DhrfDarPJTp2lTMpIlpEbsMuJnytM7MkQgHJxZgNzdPBVWTY Z35fcxqz3BwW7CfthnzJZWlOfoNldjth3lPXxDcJ2KLuwxwxDEHkd25mhHI0DpVFS6cF9IyEnlon GFh21PoyuXehbb/5w+5eqUUm/aqHpygO5fadof5q0HLsq1TIkCeyHuQqxKr3AoUuHFAqMYeWvsPX DebBbB6qj8zarHAY0qVuY6WN1JHpxvrY2Pcyxi/DTEGoIZPenQgDoiGUa2CTKZDcQuNkPkgdTDqC IV/NR8axwHyBodd/ZIG6AEVdp+Hkao64mjnp2WjFVOcxnqm1JJ1AuZ6ACMlH+LFED7gZJDryZs/M /K66Hrp/93vdUR+Az78DeAvB51/Abf/+uj+4u7/tjkwMEZghjiTe8jvlGaFDTun0Ca2WnY2vbT28 m0t9leC2/rdmapGEklHBZLJlRy69GGfgAgd8isOVifMvCPFiwBv8Ff4XoBvPYiFrOQOqCFjCsh+A 8m/AA2YSR2PMG9R3izg/AOotcOdL2mCukpHaYH4J/qSLhuhJBlob0Nugh/0G9IOBbldlERUPAiUJ hlka/xZ8QiRGvJ6ZfBUCJcO8X0Q/CczfgQEe8wZ0vb9wiNX9JEB/D24R9+dN4l4bxB0bdBkPwgby +kDuKJY3obw+q7pzobZhCQZwgAL1a+Wxdya1FQY5lUnq2rh6sAeVBtX8d6mSh4JmAlf+Wtdw9WBc zbZwarIKH9jdowfYA/t7bOI27u66Q/FyIpD0nqK6Y6pe5F5ZbYhe+nYUa1aK8HVByOQ1NHnCNtlH lF77dZF3+28WZxVjQ1Wkadv25UWvdQmTgp+SApAiM0qSI7NBPkqFT3G9h0EsNUE3r7nxTqDA51Uo fwNvTSa2Gdw5pzQE/6i/4z/Mqkpqpwr6/VmnCZajXkG0vM1uG1lmCNSZcO+Pj/OrmSJc+3CEcw+n 6iS5bZ8A5r+qKspjp9j6fZGq2V8S1IsSsnyZKlnKijcp6zQCxwFbelko2zEtLgJXVld+/ztEM5ws KTvqMAtSw+5132ThMsnHpJeE/+f+fJ+wL73/NOty4er8YK9LaF2bVzTUlXrXzPsfAAD//wMAUEsD BBQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P 2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd 0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwE mPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5 VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bk vvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16 Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEb kMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuz GPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq +fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ 0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpL Bf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZi UsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwr TTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hK yMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQq Yz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20M XFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2U z2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklxYkojeMzquoMLBTZrkODq I6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85 oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W73 3twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kE z7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSo wzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aUR bTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0 z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+ gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExE lcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT 0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H 6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9 YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0w wTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQBzD2suVg4AAEw6AAARAAAAd29y ZC9zZXR0aW5ncy54bWzEW11v5LixfQ9w/4Ph5+s1vyk1MhuIX8kEmd3FevfmWe6W7cZ2txpqebyT X5+j/hjHM0eLILlB/OKWSiySVYdVxSLr93/4dbu5+tgNh3W/e3ctvxHXV91u2a/Wu8d31z//VG6q 66vD2O5W7abfde+uP3WH6z98+z+/+/3L4tCNIz47XIHF7rDYLt9dP43jfnF7e1g+ddv28E2/73Yg PvTDth3xODzebtvhl+f9zbLf7ttxfb/erMdPt0oId31m07+7fh52izOLm+16OfSH/mGcmiz6h4f1 sjv/u7QY/pl+Ty1Tv3zedrvx2OPt0G0whn53eFrvDxdu23+VG6b4dGHy8bcm8XG7uXz3IsVvfXme 7ks/rD63+GeGNzXYD/2yOxygoO3mNN1tu959ZiPNV4w+i/obiPr21PftxArNpTj+eh35YfNVe6Lt kxb/sr4f2uGkZgBgGsV2uXj/uOuH9n4DUL1Ic/0tEPW3vt9evSz23bCEkgBHJa5vJ0K7HNcfu78O 6wlwd+OnTYfP2v3+u3aL5h/u/nqU0Mti006w7XY3P99d44uP3W7VD+/Tu2tnpufVZvN/n6GupfAA 98tit4lP3fIXdDc9AbrLX45dTC/+ld4PN82P/7XeH4abkP8feweM+oe7sR0niR/23WZztAzLTddC jS+Lx6HdYk2/uz69OclrHFuIcfVTt91jhXVXw2K9enc9vF+dBXqYNPhDu+vK0TKU9WbsBjD72AJV uoijItrN5qiGw0Uxz4ex315ewU5N6h6BkzevjqwP73c/HwCM40dPXTtZszdf7Z63993w5dtxQuOb 71broVuOp1FO0Pt+9+Pz7jKgr4k/tEMLgeyf5j/57tLzeVZfM/lpGsWFwSTV4bX/c6Ox3+s/vZ3W UWQf14f1l1NoJ9nuIKjjxKYFA97nZbXqHtrnzYge78DyogB/WXWr/rt+/NOn/VM3tY/t/nBU7/IJ 01yC692+XUIosd+NQ7+5ND+2irDvA8zPaQE99P2468fuh2FazJcnNJhgcXMGxRevj0O8ff361BYL +pXR+eELPm/fXti8aXjyPtNYTr/uTp4MjHZHg3J6e/ZOH/pVN4HteVh/ZfJmTebU4IhmWLaT0I4O 78uOenjeYb3qjjo/KqhAmHfrv3XNbvVnAH4Nf3f0Uf/GCH5rANAsAPM9/PRPn/Zd6drxGWr7D3V2 REbZrPcf1sMAu7xbYfX+u50BIq/qRBizOkx6nX78CNRd1CBEsFaE+iSLifpKEUL6mClF6ujtDCWH 8yr6gpu0si68jQ+5ohQjS8W5GdXEyNsYAUt/BNcXIzC20ZpSrEqGz8faWs20ca7wNk5mm2g/XmV9 XtZfjM3roANv46zjM618ZfhMa500l2gjQuQSDbKakUFUwXg6tqSCbmYo2fERZBU9l2hRqaJIlIBp ov1IoUygWpBCGznTRltP5SaFdXamjbOG6lRKo4NiMpDKSC43qW0xVKdS+1Ik5WZsbqgWpHHZOd7G G0+1jYHVCCfIKpHWhsz7AQ49xai0vuizQX+La+lEinxsldSGy7pydeSUWjWBc6uN9Xw+talnRt1o P4O3xlSZ2ioZZSh8ptG6xGWdpG84RpNuKo6qZPIMDpJrAp9pVvijOs065Zk2Onu+5rKpaq6F7KuK Syf7UPjKKro2HDvFiszXQnHwTWw+SknP7ZtSTgeKXqWN4foBpeLoVdrbmmoOFFfzfoyoJcWosqYk TvE2Gooq5TECKh0Fay2prEHxhY+tlmpmbLX0gSJRNV7w9aOCrD3vJ7jKUySqKIuZoWgdqV9QSRVJ 0auyLJYiUWVVG84tG8kjFAWvzdepKtpJil6F2UgqNy2U5prTwmRulbWwQVK8aWkC14KWzkg6U1Ca SGWttWgcxY7WpuYrGJTIJQo/Wwq1FBpRGo8CtLFGUM1NFE/XgrZY2nzU8Oc8qtHOKMUl6owNXG4e MuBtvMVCZRZJ1y6mSCmN1IpaWB1EMzNqoMBxVAWdJOcWjeL2eorVebSuky08ItbFz6wFo1zj6Ko3 2taFysAYoJdGg8bqKvA2oHAfDIC4RFejgU4z9RimQjTG+6nUDBJNMIpHG6A0gssgwMhTW2WiU9xj mKwst9emCFWoxzDFa+5LLHKSha4sK3xJVAtWSoTLDL1WmobvS6zyiGJpGydnfLB1pmmoRbLe+4bq x1YSbob2U0n4WkqpwYxaCthXIyhCbLA+Uc3ZKPSMRKNL3G/bLHXhEi0yaTpqJ2SOMxSruO11UlSC StRJU/HIG5TG0Zk6xDuKagFmFMEYkzWWXFPxERiveGbBwR7V1I4650RF5eYcEELR6ypdAkWiqx1g SkfdyLrm3LAr8HTNucabyLkF5RVvExyMLx1BRM6B2ngXtbV8bMmmzLWQpeRexmXZ8LjKZe1mpJON T7wf7NH57t0VI2bkVlzhPsvDKDfUkntsDiVFlccex1KMesQulmrBG6RqODcrIt87e6sTX8HeOpyR MJ1C1a6mK8t74XgMC0rhNhEwtNxr+koEnNyQ3buvgCo+gkZIninxjTORrh8fZZqZTwLe+AgQrRuu hWSVpVbZJye57fVZI0yiMy2+mpEBKBUfAaIaLoNKaCQxWD+gGJ6DBKXJFFWVMEVRLSAMUYnaN1CK olpAosTy2L9CLFbRdYoNLYJ8Oh947Zn5WDEToVTWWk3XXOVF01Arhg3gnKwrnyrOrRZ+RjrYU4uG zgc5IZ7nq2qDbTpt00AN1O5UjY7c18OZKp7VraKH46T9JARJXNsJhofrJ9vAfXCVnRd0/VRAjuHY KUjhU7nVQlUcO1CC51F0LW0SVNuTejhGa4VlQr1ZjdStoFqosd3mmSxQGm6va7jtQlcjKJlnqZEi qHlEjHTizB69Noi8eT/OZ+5laizuhuKgrpzjuae6tkhuM1TVjcjc7tQBuSfeT7TT8THxGHUSvqbW EpRQuOaA3sA1l0XlqEWqswuZtynC84i4BsVTXNdFYVNJ51Ns5L6kEaLmOYcGef9IpdMIh90Z6wcm JPGZNtJmTUfdSMSw1FKAUme6shrlm0x12mgTak5B7MSjgMZMx3B0PnAYPGfXYMPN8yGN8ZGfcDRT XBVpPxapWy4dnL3wGKnBVnNG1h6bTc6tQhRNLV9Ty8hR1dTWc7/dNBLRC50PMmmCrpImCMN3OU2w UCvlFrXO1MY3GfDlM83CzmgbI+N7DEBKcxvfFB0MnU8Q0vGTB1ASzxoGYZOhfi4IF/iOJQgfG8ek E6TEPodSFLY/dP0EJQPPHwTlsP2g3LQQPNMYNPLk1B4EbU1NV1YwcPV0nQZjZ3JcASkZQe3b/Hl9 wHT4nnbahHIchFpWPH6DaYk111ztAt/Xh8Y4jlFQ/AxCGgNFUC0EpXl8EILKFccoVhY/0wsBRoRr IQrB84kBJ9V87xwSwmuOxOQEzzCF5A2PogPOMWbmkxXS+FQ62eqGI6QgEUylg4naivpgUDKPr6OQ 8GdsBAC1KBQhoEieu41ITlZ0zUWpHI82osQJIZV1lIjs+EyNE5a3QS6A5ymiNVpQnxWdhlOnMkBW jJ//RGcrftIFSs13H9Ebk6m2I5IB/I5MrIyZkQFW8Aw37IxmJFrbyD1grJ1O1L7F2oua+saISJWj NzY4jeWyblxdUd8YoxGOjwB7Mx5TxAzwcLwhL8YjlIis+4ysiwj8lkHECSGPE2PBxpVjB3szftKV pMI1EIa3hCwFP3MFZSbfmxRInBvyMY5qLiHdy/clSXscU9KxaZ8U9cFISSmeR0pGK0X1gwtZ+XJJ 8O2dkmS94Sd3ML1wtnRsHmEVtRSpwtkQtRSpFolby1TjCIr6klS7mSggNRLnSXRsCJ/4eXAK0mlq D1JwmkcbKYq64RKNVvHde4oWp2B0bBk7V84NJ+/c8qXiay5RBKqJ3wLBcYmJVD9wgDO5NGzMDD/l OR6ocW5auUQxmrXx/LQvGxV5DjJXUvATmwzbz5EIiubRba5wGks9ba4Q2lEcgKL5eWNGlo3fq8lI 4/BYLNeu4XcWcPWs4XjLQQuezcvB4ECLoSoHX/gNrxztTI4rw7bwE4GcEG1Q9IKCEho6AtxC5KdW GTc0+a4aFNwd4dxc4uf1cCWax+RF6MRzAUXBWNL5gNLwU7iifOAxRcGOhd+dLNpmftMPRzmJZw2L AeL52KZrXNQ7F+sCP28ssLyOeqZS4SIk1Vyp505JcYySeZ6i4OSOZ2hLQC6NWoqCUJXHiQWZDY4D XO+CuBlCCu4jccSDkngOEpTCb3gV5JckjZFKETW3FAWnMicbj5vhk0PFffDtYirOmioITr+mS/ZX 29MF/dhu74d1e/VhKt9C3nC7uB9+CevdhX7foXyt+0fK3fP9hXhzcyIctqhWKaiKuBCOKt0uVuvD PnUPR7abD+3w+Mr3/MVA36Iw48+feU21UN3wx6F/3p96e0GJyeny/KU7aU5GeLtY78a/rLeX94fn +7tLqx1KsP6B9Lxbff9xmBjevornZTGicg9lOeCCUqrLHflTQdUxqbrcDHdTdV/3AeVXKP7AJ/eP 8t31Zv34NB6LUEY8rVDld3y4f1RnmpqKCkY8TbTjQ7ucZoavzz+mD04/8dX5x+s7fXmnX9+Zy7tj ddepib28s6/fucs7VBm+LJ5Q6TCgjAkVX59/Tu8f+s2mf+lWqHi50L96NckLdWRTYcz73XLzvOqA hlW/RMXRVCR1KpA5PLX7DmqfamuAvn5xfHEutjlcfVx0v46oUlutR9RW7terbfsrCnvEKTtw/nrT fuqfxzffTpymj/dv3l6t2rGd6oImTb5pjGeUbL0dy3nsGeVPqzvUbaH25/E06FW3XAPFd5+296+1 PN+c5rtZH8a7bo+yn7EfIKljZcv/Hnt8LQP99u8AAAD//wMAUEsDBBQABgAIAAAAIQCy2LdL4gAA AFgBAAAcAAAAd29yZC9fcmVscy9zZXR0aW5ncy54bWwucmVsc4SQPWvDMBCG90L/gzjoWMvJUEqw nCFpIEOX4G5eDulki1ofSJeQ/PtqaKGBQsfj3nveh+u2V7+IC+XiYlCwaloQFHQ0LkwKPobD8yuI whgMLjGQghsV2PaPD92JFuR6VGaXiqiUUBTMzGkjZdEzeSxNTBTqxsbskeuYJ5lQf+JEct22LzL/ ZkB/xxRHoyAfzQrEcEu1+X92tNZp2kd99hT4jwqJzFjdzEA+VX2qbMwTsQLrFqrmcr8Zd9HQmK0e T4fd07rl72xjIv/k32tEwduVKQdcQPadvPtH/wUAAP//AwBQSwMEFAAGAAgAAAAhAOtuLGWjLQAA d4YCAA8AAAB3b3JkL3N0eWxlcy54bWzsfV1z2zqS9v1Wvf9Bpat3L84cS/5OrWfL9jnepDYnk40z M9eURMecUKKWpI6T/PptNAASID4IUFQkypit2hyLAEg0uhtPf6DxH//5bZmO/ozzIslWN+PJX07G o3g1zxbJ6svN+O+fH365Go+KMlotojRbxTfj73Ex/s+//r9/+4+XN0X5PY2LEQywKt4s5zfj57Jc v/n112L+HC+j4i/ZOl7Bw6csX0Yl/Jl/+XUZ5V8361/m2XIdlcksSZPy+6/Tk5OLMRsmdxkle3pK 5vFv2XyzjFcl9v81j1MYMVsVz8m64KO9uIz2kuWLdZ7N46KASS9TOt4ySlbVMJMzZaBlMs+zInsq /wKT+ZV+0a9kKOg+OcH/Wqbj0XL+5t2XVZZHsxSI9zI5G/8VKLfI5r/FT9EmLQvyZ/4xZ3+yv/Cf h2xVFqOXN1ExT5Kb8edkCcT+EL+MPmXLCL7t5U0cFeVtkUTah8+3q0LfbV6oHX4lr0yj1RcY9s8o vRnHq1/+/ii/pPpplixg5Cj/5fF2DB1/xRnwf4WZrKt50VaNacOCwfI9Ui4CosRP77P513jxWMKD mzFwIv7493cf8yTLgVPq3x7jZfI2WSxi4Nmq3eo5WcT/fI5Xfy/iRf37/zwgA7If5tlmVd6MpxeX uBJpsfj92zxeE9aB162iJbz5A+kAi/fy5n953wmZKFBI1/w5joi4jCbePabePU69e5x59zj37gHi 60mrS+8eoIc833Ht3KPM5nT1NknNa6fXljUnPXD1vHrg6nn1wNXz6oGr59UDV8+rB66eVw9cPa8e uHrOPeYRirDzin9OyjR2bv24mZVeHd5+X8d5mqy+kleIk7i2MdVjmWerL85f9fty/RwVCex2joLx 9vMf70cf85juyGW88Pq6j2k0j5+zdBHno8/xt5J0LgQ9jOrPea4fstHjOpqD3mx+hLsafZ98eS5H j8+ofpvDXJxYxJf2fJ8UOAvxoy9smp52+688USh3MbW87Y94kWyW/ENVTXNx6t5ZUToXZ+2dyUQ1 rz137Km+86K9J6GS5p2Xjj3Vd1459lSU7IVN5n4DRDrSMcKljX/uszTLnzYpX9Mm813auKjqrH2t jZGqnjoWvLRxkSQqo9v5HJCXZnVsc65lxtzfNu1aeMz9bZNvSpF5FBshGqNMzaM4y5V5CJuAfYr/ TIjRtZ0aRcn+GOXRlzxaPzfZ8PSM/OIEYv9nk5W4IYrKcOoOod6tAMwX8Ug7zilidKfvYOuD87Is jrMCMi+OsyYyD+GsksxDOOkmY3cvJWUexSa2lc7BJTFpjkub5FZD4J5gHMImtlr9pe4RfvpL7W8j hKq/1P42KjQ0z4QvhzqKjRCNUSoRUUfx1l/qEDb9pRVUdQhvQVWH8BZUdQhvQVWH8BJUpXsnQVVH sfFnJWWioKpD2Fi0GkIUVHUIG39qBVWFZH6Cqva3EUIVVLW/jQoNEasEVR3FRojGKJWgqqN4C6o6 hLegqkN4C6o6hLegqkN4C6o6hJegKt07Cao6io0/KykTBVUdwsai1RCioKpD2PhTK6iIF0UE6GhF 871M7W8jhCqoan8bFRoiVgmqOoqNEI1RKkFVR/EWVHUIb0FVh/AWVHUIb0FVh/AWVHUIL0FVuncS VHUUG39WUiYKqjqEjUWrIURBVYew8adWUBUvr6egqv1thFAFVe1vo0JDxCpBVUexEaIxSiWo6ije gqoO4S2o6hDegqoO4S2o6hDegqoO4SWoSvdOgqqOYuPPSspEQVWHsLFoNYQoqOoQNv7UCqoSXPEU VLW/jRCqoKr9bVRoiFglqOooNkI0RqkEVR3FW1DVIbwFVR3CW1DVIbwFVR3CW1DVIbwEVeneSVDV UWz8WUmZKKjqEDYWrYYQBVUdwsafJJyXxiMxfiZi3om/19M01NQ9mMU+6lP8FOeQgRMrvlz3obgv 1jwW2vRO/ti7LPs6qqKlIplO0d5wGySZpUmGLurvrf7uUxpdbmRz2Ljq89/uR29pEkb76DSurIyu +Mkhq0VMUCHZH5jwBA1LiO7ejNei1x2SV0g6D2RQ4ReQnJZ3kIPCMklIZ5JaAn0xuYb9jCkljID4 35CFteBtTk4m5+d3vzPFAqk0ZJAymmHGEPzL26XxU0neuc4grefslImOqcEVDxeaGkym10wdGltc TpmqMrWYTvgmZ2xxft3yoacnU7Y5mMY4PTtv+dLTq6uWLwV6MU+U6S1nl+ctX3o+uWr50vOLScuX XpyctXzpxdlVy5deXE9avvTy9KzlSy8vL1u+9Gp60vKlwGItX3p9wsMFJqpfn5+0fOn19Sl+KYgp DIJCUdB8ApCF6KmMIZNwCh8Cf0EeBoir8MenDUnGi79F85LGlJMVETsiSZUIwbhM5iA7j4he3sjH u882eQKpEJCRR15S5+LdRZAuiVkNLAWv0ZKk34k/oeQXP2AM1A2c7Ysf9yT7T/hNyLNDTdSikrAN UUJMNU4w4U1UQ3XiGn7DLIK8ub+RNDhFSa0g30P3u1l5ndyBWDBsxgj5NY7XH2AgfNlqs6R0hf94 Vyk97ADzrJ5mm5Is3/s/U/565C2+OvBvF1JMjaRgErQfUiRpPU223/lSB7tx6rC8TIF3Ce/d5gkk N9IVvy/w34T9K/EcijkMhfzfkdCnRkIzfLZ/QrMV9yU0dvMmtERgrr+2ITDNJ9YJNdOf+ycwW2lf AmM3hcCzXXHquZFTmRLbPyHZivoSErsZCakV/T4488JIUIYw9k9QtrK+BOWblIwPtJzJtcQ2Ik4T 1XUizmyD/ROSragvITmbISE77jBXRjZjMHX/1GHL5Esd7KbILZVX+Hkblro2Eo15kPZPNLZ6vkTj oEWWzQq7N/CPtB07yur8Gez+OdgXBPUbzH52BqbKyyOmg0Jy1mhUtRphMwRktZ+Fw16GB+uEa9pO 8mPAT2YpAiuJZrwbvvkzeW71V4ywCUWO6gfyzPa2LwR7bZYyb8YsfYeWF5zTQkuNOlYW3yL6Emh4 H6fpH1GOvo9sDcQwNCW2G306AfsU/qsx1Cwry2xp7p9jKjkOrxsAyCp+DP2TTMJMb+DcWZyz/HYD zT9kxA+qcAbkxuPvBlZwpbTjt1V24gT/p3zN36gJhp8EZ17woxT9UH9vY/1ll5bGKgQ6aQxBbsew pzCVlk1CInc9pSixz4eJ1c7nw5WL83wk72I1H2LKg+Yh4tAEBPCzfmnwLBs+ktdiAh62OwaBmLrk nhT4F0QFvQDzNI5Q1Rn9i3ILnYNRbqH1MDaa6FyMchOtj7HRROdklJtovYyNJjo3Y6OJzs8oN9E6 GhtNdJ5GuYnW1dhoovM1yk20zsZGE523sdFE526Um2j9jY0mOoej3ETrcWw00bkc5SZan2Ojic7p 2GjCvI7odKxEBM5SUDiAMgKjqP5P3F/IvoRNJifM70w2EpP3kg0i+ia38n09ZJDhr+qOJ/qzTncw baPRHQ9nk5N7Zo8iECXBEjw8XPtBv2a//PcnopNgkp3AKoR1VJ8lPaqp+1oxqGLyV0abMvsUw24M PkUcQ8Ux/NinrCw1GxdfuKAs6/1BG5ORRUgblJGbBGVZqRZp99VGZ2TSHbyyrBQhzAygzM14kdXh y8nJCY1ytepFDgiZagE4lH3Ms+xpO3WjxgXoOe+gbmoRnwRspoXGAZvplZY2HCwrrR1is57Uzcsb EYYxG2c3OkgNmREd1D1cFiCPyZidBvtQq8mCfajXZNqklIYm09mHO9FB3ItiUULb2WR6h9ptXiYw 5cd4TiomKY4oyVdo0ll9+wp5pHhL3xqYm2o0neje7pH0oHuD7hW8p9o8QFmBBN07BN3LTCCue+Ff ryw00DRqugnRNN1TTTprmt9Pzn87u6OhgxAFMPrygmNLL5fapGNZpb2SKMBOUB6Pcm2hadQ8LKJp uudgddY0wYV+Mw7xRoMaCfFGrSnOTzlI8cbdaBrmDNlC06iJikTTdE9SDJomWE/BetIkE8j4amje c74HbqFp1KRfomm6J/wGTRM0TdA0x6dpWOreFppGzZQnmqZ7lnzQNEHTBE1zfJqGZQB31TR3Kdx8 gkX1m6nd+ITW22/LQvLNvFfOy094MQQx2WFyBqsFVjtanVDfgvxJs6xaMvL1Gex32eK7fqLw4OfO 03Ox5psCjpA8ktIezTIfnx7u305+WWXg2F9lEIZU4qLQYPR2MvpltMpG0Ij8Q5rpVpSPVT035bK2 JqiqZ+dx3/KcdnX2gOQPryCFWLt6JIuYPByV5GYI3bzE9FxnTmW5xUJ1BJYVLZ3c4gzZkmUsndyq pvX7akE+vK6V05TAmDYYwb0ZrDKPbnrsNFd1mKs+y+U7WbiMq7xNky9VIQZyOIUUQWBi1zJLvdjd s/tRmpPj96bopiSumIkJvQpAsAA9lneoaz5MG/H7lzf/mldeQppaD1/HubZK+NSet92KEziDm1mh 4vK98UKxgYtlinmerFHKgCo+7GBXYdW8C1L0iVzVptVjdbNR1U7HPqDI6qZUJcgq6+769P6ayTML Peo5hK9q9VTan64up2R/eobzB3DarvMO5UqbFpq06j6ZBpqgCCmT8h7EnZbmqOYM/1HLDK0nBKtf Pe7vNAKMSgfjIgf/uoS37QTE/RG+Vks+vjWS5zpWctFEzmqWsZpUjUZkKMaR6u7J2ZANwPam6mxx ffKleVUfnRJWrgBa9iewtCxbU6UTrEGftJGylRUVhFiFaZxUtBtpeiXJu1VR5htMTiu0rCY1aCOQ adez8trp+eXv94yJGI/M4EW9TpOk0H3AA8ZwiZeOAUiDUdWibZ4yI1w+XF5dsQCxICytOomfvQcp ZkejsXcv6uN2vdbOk/yum11HFH05nU7P7+mIbOrr6Et8l8fR1ztybxo9NcZm2AAyUBCRrvOOCPBW PQ1HZB1IALZFn1S4PTm5PnmQqFDNuK1GFTUhYc2rHqoi5Ye7e2WPt+rhnYo6ePr65U3jlHdHHnGl Dnsp0KHet12og/2AgD7UqawZbl6rxCBP0L42nuGvD4pb9ZsGsij7BPEkACYjVgtU1IMzXewPWnmP OEGZqGw1SfWoRD1JlEVlyUUg0cskqcAzVcG0fW2t8rKPorVaQTcfHKCs70OSF+W7FVyAq5aPqImA rUasmU5Ncnahsu5LEYqansinkM0BaixOJIzkqPmVybXOyzKjXaywfPrnlBY33VZChRW0Cau4hAbJ 5YsoUuWwltI2QfrVhqn1vprtSmkni00nadNXjAw/T21Z51l5WXapy+7TjNy4ruA6/rtOYW3DEIlc 5XUrVfVbBLclNoE3/tj21Z1sinrP9dWpv/8CN9mnj+BOjMpNrn4zfT6qG7R9v6NmMX+nwQ3LLzNu ErUqra77MLPX1c0xyXbsBMferrTa76s/4zRbx7eLRR4XqvEZs+ejiDXQzWcb9n7KocL4xxw0HNTI urymCOwZ/GHXFH89i2WPodXzI9RLJqEM+vgFLhC9GSM0Iw9vV/PnDI7nE/OHoLdv6JK+GZOLY2mx k+/sF1paiyIIUcSmV9VZfhkfVW6BqJgnCS9IS19aiH9L1dqAoTohJr4un2Lgf/XEWrUsOX3e26ow 1uo2WfC41QWhmS9BBJGVHdFCEr2sPWRpmr3Ei/qW8qbQqS10dDFLn6OSqLaZOblPGTgAS05dnfAy EHB3Ov+R7BRQvw4+o50R9LMmt5/fzuGG9e+qExJvRucPdzJVsz7UB2zwaw2qhH5t32qkky40k/o+ 0eyQ+OX4ZCdErvjJT6FbJpEt1C2TToI82e0kmqpDLBpfa8vGr23V5XtXJoQaoAiSVaI9EYzEEp7v lmR9rft/x99nWZSrvlWcTvV0t5M5tPU3K6qPOfGNLqOy1LijkWRSCx3ZROQDbqOvXO+T3mLneyi/ SuVOLd1lKIwpe7drKF1pi13uteT7H6PlGvau5iaLhGHPdCTpb3vti5O22Xo/w6U5LzlsCrmeEMLz YRBjtxiNMMc/IriqgVTt1XJO9XS35OpFpcLa50Sq1ZlUT/xmYRb+VmmXsCZAzZMHFuroEWsSd+gH jM8pMwYyxCT5C4oD7wY/+CJNLMfR5LC6RkcjaCLqaWeUz+w/0TokXlQCYnjWxpZeVfK9qpcRo6As DrOjeVwyO7vHeahuQpxH/65BcT2g6nXvC6KWU8GJtNdT2YaxeL5qn5x1rkgxTqS9XMNWEwE7uG8R udukaaxGjHA27JlOD4tCr5xg8J1jFRiWIqOYbwCqiz2F/+oUGiQzoRMxaAP60CHcsKN58lsdepun QVuwebYrjR3Nc7tkkCokWK+nQZmwebbrlB3Nk6dU97aeBl3D5tmucnY0zyqy28NE7+E6jGS1UXEt 6qHqaZsm8lU82iwFfIm4EfYARPgMDCqIP3ZQQruZIsEsMO9tdCyfg0H78McOdSt3M0WEMz3N0aB5 qjm2654dzXHLozhE2vgkDFqHP3aoTLWjORIQtOU6ftAbYqhs2DPUAj1aCExJNhIEJzzxrQcdSj/c oGHowx3oF8O8eMpab/MyqBU2r3ZQ48uMhnnhi/oBpfTTDaqEzat/RWKYF76oz3kZ1AebVzto6Wm9 8EXbz+sPiN9D2Ntw2Q57ijeOG3w4or3kO7X13SIn3pgSr7vCgCiLfYK7pPhxM8a77gmW4ccQ0aHF QveoyNhlWJ36VhdldeqNh0S5697vswkaYVMvnqsLgdfzkjpYxEnCC56SNBWnLCI4xZXRBAOV47/p F6dX4xK31O2q/0wEyhX/jGeKN4E+Gf1/ePbvWqdgJ4YyZCA0T6fU09U8IeHE5s90O27JPNAHi+g8 3unzVhkV2NO+t2SRQ7YEwB/gvChRDrrkNfIMVQN52DaHneWC6SPaH0GpUZWscCBJ8zkor/RjlG7K SBtSFh7tjcB69q6z6Jr+9PpJ2yf77hciX/OLc4gutd9OqGeQxxLSY9SETPaz7svNMUqvBLwZHbvL EbnKVfS4mZVJqYmWVQ90ExA1q9sns2CG4k2gaeH608svb1pOwex8S4IjnUAa0PUVvT6TX05hAZ+g mHuhni3C56PT30asxUh/xgibiVT0ZWD4sgIBT10ZhgAY8q3GOwelBrorB6UGvFa+VEVRbqG71EZq wSuxmsfQXichjcErn5nH0JYZlsfQ3TUoteBKwPyWM91Ng9IY2sts5Ba6ewalFtpS5nKL6jgp8AAs N0JOuYXukkGphba6sNxCd8Wg1EJ7aZbcQnfBoNRCW4VPbqG7XlBuwW6PAPXNhULRMlNeO6eh90Un CXQ/oit2YTZzekOsYBcUWZosiIpgdsH9Cfk/8gO1DB7wf4wovD9Q5ZGUb8EkaXpBMB5e+pS9ICBi gFncjNgLOHPWqamwRqw50hq3luo987ssh8vNUK25GlT48Ww2VxCMpcnTMPl0Osv5+6G6DFXiYAdi B2YHip1JAIBMHLrm01napSthwHoO+BeDEzUJ8QUqQdOoKDk9WyjjZOGKM6sXdXBkQT67z1ITnzmz k6OFLZJt4NzEqdbCTUSTcl43ex5EugyYnVYxuRgdmcmDLH7aQ1Zcfn0HprRWL67k3IYokugeNT0L Z/YU9gA/ioji7tdzYLxZ1LzJAAeCBK7qSAJjdc7KDZF0pvlRMjDsvGgSEzyD/wGUpdgQMLjVZFaD b59JD9Fk1uceYrNgMkO9AN0NjJJJFEzmsUSPi2AyS/TgF2QQG4X5kXowmdFKBCvmLlotHpMfMVe2 zAMGkAuCFPAjHLRFQEn1xeJbxOyuWUrwxB9RjkYSBvIMTdk2Bk8hSEXM18ZQFd4w9Ocq2TAAIYvw MfRPakxzY3UPRjV8huNONSzbVzLyWnB550244gj0lvlBH84tLbFd0Uh6HcZjB8IM2HqcgVqbvM3y Hy4GpMCobma1yDEys7r1HzBhVawu+hKPQO3BFDqCZTWjSwHL+rSuAJZZHCyA5QYUPjljN/4A8uMI TQKHASzLFNsXWEY4DW7co4bTaiikLbZ0BPsBmhe4vM2YmqPXXkAXflBWRhZ+fTugPRHUDMyBSCJy jqvRgTADRmsIg/8Bty2IQTnJucpDqTZJ3c5+hpHBUGQSZAipku+c9vmdkFR7Ltp4DsFz1+8MZgVJ yxaJK/BQ15h6MCuaaWv3oNSKZG5KWmOPQ8Ya80ca8HGwKGR8HDLWZHpcH2jGmpBdJeBH2bs0wUth NOlRJGBKzxRCdfCshCu9uO3oPQDdFMWvEXztsLEPxvFfXSiM6KeuAiqfsiHTZZl4NWapQhY6a0dX OwgBz8e834Q5cVEHCM95wpwuwC/gB8egicvBMRGhDJh4PhGXDsbNgCkjZIgxthFd0VD8m2s9VhAS ih9Lv4CwO7LbsGJ0AUsbsLQpm4Vj6ZDKQresgKXhSOh5OP0hRRqGe/pDRK8m4BCwtEcSza6wtOSY rL2uzvu0zdYRSwocLjKEjasuDFA0DgCxkzmAYYwHgKi5Zve17vL4yoDRpISzNXjSmQv3b5xZuagn T7gdfA+IWERk0OR3kR33UxQHzgU96RLV1JB0OFEHvpn7B2trAX8U5GilcxY9MytMaUHc6gg5QcHq IGnRWAkgWB0N//zJJbPKTRlQP9ODz2CBm45joe62NPrerBOWZ69JfP4Zxg340pIvz4bjqQ4fQHdf kRgDDTQ0UbsD3sJ4gTbFqOE1b/g3UW/SK90ah/iD8dRcBgZF+jSevLSBORi0XXzvwHEmY8Rtyd5m nDXYvzZDQa0M3cffFXeqhThpOjrHnfpSnCEXPeSig7Rq6hSFXHTZH37smSNmPOniS7X5Yh3goBVO tr//aNDkrlztAUmS61jr8rqEYepyUJIDtZlKfLhI0iZz7TIDFNi7762V8PS+oK3iH21Y8gggo9ag FHzXww5voKy6FmsLHuo1ZOuD80xX5+WeKMGnTWpMMmfPQ5b5OPiog4/akBd1WJkxOq+U0R34c3zU 5GQhFSCzTWGxCeruNoDjNEA3H3X9AQncmbCI33IDWU6nN0MsQn9CgKMxS1TvKtLI5ubTYhLEYs5O 7gEhMwnIqtQiNgTRpzsFspABLUQIjol4oE62JZ6AhtvKGB2WVbQjZlJxcsNFwHXe8SbTg4R4Jngw eGzMK+fwOSSWB/gc4PMg4DNuBv6wuCMyRRxwTMCweZkZQb4tUKcHYNgI/5KXVoDbLfy75fodnO+0 iRJIvmfLOlDjxJ473uY7HSzkJJN3zgL2KDdzYC71Jls4JCe5sEUAj8S07wYejenBHDyG/OAAHgN4 PGbwaM4AxHrZLRU+LD5Vl+5W5OMygM2n6tK/k0+VbVzHBp3PiaDPieaHClvgNW9xdLVD5xbflm3x ze5sbrUcPOp1IKELvJFQbwtFzdJ46kJQizC5dD9wuNnTegi+W00mw/bG4MFT0deW6wJON8uV8cbU +ywlj0NaQEgLqC+xDUfXBnB0TQzqgFYQnWPM6YkOIBDw7pWsxUNcW9XbMO+llmB/DU5s4MZpAMtm 7NCfIguRGIM40VaV6gUkarlAthEOnHWtrSUv0iLb8EQ1uP51GIiHrLOX67CZ79AXKfcPW7xIIaFq juNeKS1Ej/IrJ0XvJctJSEq2q33hs9bM3kXJcuk7SQyrh5DN6yzUYo9INJAP9S/zuq/iMZDDVakw Be94A7HZLLkqaNKFVJUQbQjRhkFEGzhQQIYFAE6d4Tsx6QZw16eb3YK+dQ4yyQ7rmSey/w2hNbO4 JWZAMHpFK9HmF643EksEci7jRGP5n50Nvv1TcOdWSsMDTeAmADlVPOlOMyzcIXIPsAT1EATzpSLF LsyXU03BUnjhVocHdm6+nJwE80U8U+6ldYL5wsybd4ubMZakYSEnS7YUmi8hWYpuKgYAG65DkmM0 4TokmR57KKZ4KBEpW7Ch/fiqS2851OF6dpRX0O1cEYd/PM2z+gfH8b7vp3bDkYazglm4d7PQFCl2 kaxXYFPC+oienWA6MteF7Zq1gbFF76Zj0bhAoqfTHrswHSc7MHGPPvIFOqFTDMhYGZSl9YXKoMGI CjEggwl9WNV+xOPK22fuhTBPnBcILF5FzQ9dmAc1nzaYeNSQ8xVMu3d4qRZGbT2w5GJlHiC87Aq0 zsdEmayiZcy9LqwEOwNa5/T8wCwq4sXfVlKbD1m+jFL6vIiXydtksYhXyKY51CDjbSGweDe5OmMD rUlVTAjKRTOqxQxb2Nlpy50qVxcMAsJI/E0kGbsCBZPp9QX9NmOLy+mVvcV0csFiyaYxgrda9s4G b7VMj5/pre4XaIluVJPjy3jEgGhZ7tTtcERC7G5zSTu9v8sRCfEDOjmlB3/4t8q/AeVqOWMhgJKO hVVs62tyrIrLMzAPWm+A1iSTR0gz7TEMgfNek+P5FUy7dyvgYJzMDduiA2ZflfFyneVR/t2I24Um lFkCdNcaCAG6y1A1QHeZHnuF7nAA8y5aLR6TH5VdPmG26iz1uK/TWrlmYqp9U2edA6jDeuKGnAyH EajOE62JYzpjLGzHjZTqaFNmZMUGBE6kvP1mmUzMEN++qDVu7m+z/AfuXyxfQMptOQLC7eos57HT bbpdiN0bT/2exl+iVWmAUvxpQFHUYRtQ1DgUkGlgpIO6+1x0gHpgJKG2oX9xD9G76d9bdn7595d8 m/7drejQ5EhiQAC1ohUctg8wUGzIjsMVz1WMa1d3YM6jNTkzO3xoSVZaV4HGe8v+rzxZGPZrfBQ2 67BZs+uxw2Z93Ju1fDzkjET+NXWIuTn58kbcqn37yhu1b29pm/btbN2k22dt3aLbug9xg+60pZiu FyV7Sqgh2pIlc37dkqxzejJtydY5PTtvydY5vbpqydaBnKGWbJ2zy/OWLz2HTCX7bMOu8pp2lXYb xravuPS27Swu/S17i0t36+7iPoAhPtA+wBB3GG7LSP7yPkxATXLIQO/HJMuqs/fgZzWzSFOb5cim 3QmTmOrgISYJRfDQ0g95uVlxE9zSN0eIScLO/PLm5WY8OcEsBZqDuvgWsZg6bCPVUTCKIdjBgp/n nJ1RX6OuqiHVTexTymGUazVuzc1i4J2m7ZuuKkYZBpbiG9JVq0IQRyYinWCcqR4YwrhQDCzAuOrI WnAtHSGME7ILZM9/u2/E5loyHn0SN84d+pac3m+NPbTPn+K6waWO/gQEipkuZpC57brvH3BJrjVI RZXqy5L05B6undB4244Mrxgh/X2Wivm3RzbtTjDNVHEIYVooNxRgWoBphkoLh1tuyCMJ1Jwc4oR0 LFE4p/7B2Xfgzr7tjqgEQEaxPNb/Yo5afRzQ4mzcOgt22D7InwWJLdhw6xXYe80ywoa6uHQnyGiq nYSQMRROCpAxQMZjhoxGz54T4tsScNoQhdP7A2I1RZdf3lTEhfgzHkmVos/1NQeHGZ7ewjnoxDn7 9w6adnGjv8uCKmGsV1O1Hnfk466cunohaSHo3GyRA4mN/UMzZT6dpfxI9CpbxXj+BK6ER4VhOYiC zFsFNUysDL/7FU4noPPCcjJuxPLrQyXPGV81sgVXEC2UA5KDr6EckEyPfZUD8vBhBkC6iMNBhD4O ImAKWx+gqULSf0bpzbjDLnuwHiNXrLmd49go0u3ZE/CBwyLea82bfNWQ9dIGWS/H1GIJFSwDZA2H XA76kAvzoVgyifDaB6/ilcbNz8lNFRystsqd7fiBeCZmaeWowL+qIzfwF0ZTDQ5SRnuDf3ToDlbO 61wps6oD4FiTfgECunkWbSDZidUHBvR0iZcS5YBButLSqDPaGf44AHNvhByW8aA5Q175+baVz4GJ 16u2J65s9gQrIBNc4JVoBBe4pVxecIEfjwvctv2331Tl0tuG4lz6WxIyXLp3ziDms+98WIsOEMyF jzlgL9e7siS3cH3fgrPNsH9MIuWjFo173MkpROALIMhTkoLnX5qhNgMT7UuWH1zRUWcpCEkMx5uP aqRGyM4tv6fkThQqaFD/J6WZF+Tnd4ub8Wfyy/ukKE0lHcmzUNKRetZD+aRQPgkjs5IdcLgHunB/ gLh0L3cjGV1FFp+by7WmZrRW97aBRafXd0KL/P0DxWrqiaG2PAX5TtIGXLjCUglEETqjLtuymZed vIfp27071ayojd1a2ydqa0vCHPaZLCJIuuNEWvh2/FdfNa2AnviJEG56bHdfebFOUWc18+CTYAY5 q6/9G42mWcPvfunOBMWbCqQiwg8FUpFDAsIPCP8YED6v2++VQGKDa0aUXV8uT5TVADMgusDkbd2R NkoPEBhDxalL+RJPNJ0qYEycmxTTmzY0LQIU3ZkBGFdOvOMHxuplur1UMAvAOABjBpwl17ep5CwC 41ByNgBjEphbB2A8JGD8084B2qCcETSjK5U5OTtnItSIaoCo+ydUfdW4fhoubbIMVTpGSD42XTbE TzZ2xeBOYnC4zjatbaIiKfEOpu357HDJ0cn3aCoXixArlIsNECtArFD7CxPg0LUGZWHwfzQM/MqP pg3Ur3oQCE9KpHw1CM+atcAc9pVzViKRNjzfacc3VfvEHT9U+ww7ftjxX+WO7xLeMm/4Lr1tHhmX /p1yBQlcoWgl+HPeoKNwMIWVjtE98QqKA3VCJaaSj4hKQsnHgEoCKhkcKvk5pxxckMOAccvROBkg d+Rc40iymbtaB3/bWQkg2KvxJxDmcM7b7w16WHD4MUI2Oa2rLdZ2WCdjSMKWnACI9pBN6KjCYSeY 8UyRf0a7qRoiorlQDTGguYDmApp7oe4IuZiyZQPhqcq266TNYLDubXNDOb3esv+5vP91+qH8s/l3 DeRqjth/Toc1MNTT8UMxa1+TguVM7m7nzbkXdv+03g9oHti8dXUIEbYc97U7MtZnUiIdKoo2ZeZ1 1n7/Cy8pF/UIh69FoLXK5SMcwzaSSOAd1NWujSRTiUc0kkKJx2AkBSMpGElaI8lsZdTR7gG7vKHa zass+e5vIsl1gZwRvM0CduGtA4M0zXIt/vu3FtLs3F4aBqmDuSRyB7v9g7nHASLS+o3BXIL608dq LokBlJ50y8DNJSmQS4ylHZtLH/PsKS6KJFtF9E7cVbQkxVMxnw0rpY6kJtRTEa7b4iQiYLCyJsIN sXI5+FAeX6bHkG+IdYFUR2AZveWCLQfPXGb/Ok2rgzjzNHTXcdPOItv+jjf+x2S5TmNTCXT6NBRB Z0V5Dd6ysN/L+1vY72V6DHm/d8rXsLm7HAYgDpBQyEV3I0xLmM9GdzNUOaS0DC/fl+gvbKGMMYVi 2GQBcvnlitIN3FT/mG3voQJyCIVWzovziwk7DWaqCB2292Fs7wO4g9k/IAcaMBw+aStXpkk+bNTl 8reUX9H9G+EcT3WZuzc+u89o/EDDgs6iu53/cP+xcy+irWKip/Ey4r5otspW9Kq7H1BNimzsxTqa x+y/MdfyZswVAJheez9Q5UUvtfzgrFPabK3PjoVcQMYuxoGpBjQzDkIV6GAcBOPA4Pk93AsQf1oV aPNmbfH8YViDqu2sLLOlPtrmNIDlrJhDf7L1BNejzvWoASMNG4Jk6jw8DPmoxj7ibZtZaYm34dMQ bwvxtjqbKDjkGu62k0t+x5dpVz4/YYW1TS7M6+tTdHIS9R/NCpJzSmykZPUFdqLoqYzzm/H0rCpr t4BfyT53Mz47xXdDv/XHnKWqVv+BOatbXTo8fJdd/3GZHrHCwEzdPuJdDhjoEFwAIH/PRMow37RZ U4UELOGyCnj8lKTpzVgCHh3L87Tw6Xao8hAoSlSbc+UiMbu+hTJb4v2BiaB8XLmFNN3C8bV+2z9t WsQQMwe2FcOeHJ77J5aXhPXltjxYZy1Qw9P7iLaOMTWBWkIhNSF4H4P30WTnHKwl5OF9NOMJc6pW vWVacFp7d6LAB+j8a0ma2AKkDMRY8Np4X5ER5UUXKcmhhWcsUjYQlrECW3ZJ97bA9jUZUVZ6knt2 /I6toCJG99nHHJaBHvkOhgL1LHbLbzgeQ+Hzc7yMMUFGPZRMn9FIYjiNDKKj3lQcTifJ8YOQvizT Y8ink86IbWjNbjObF+19bf689t4W0NTe2VrC1rX7P7g+kA8xt3UfolkE3+znffpnPDMdeoVHIQIf IvBl8DsNzu9E4uePVSD/BYL4GDak9sTiW8S4epZ6OKiEo4TZpixi5IsCUqtNDqY6tVrcfHz7ypuP b29p8/Ht3Nh8unWvNh+/7kPcfMBgZdly4EdxYUEySd7j5xXOwMx/Dgk4k8Kn8C+ZpR9zGm1g31TO q3Mg8MHHY1DCBm8KO5G9P8ScQswp7P1h74ekQGHvh02x69bv2VXe+T07Sxu/Z19oniziqvRVp97V tu/VO+z6411dGhx2/ZsxFrCErd101I3s+uGcW9j1w64fdn1515eN12mb61S+Oc27s7zze3eX9n7v 3o3dX+7f7uug3avt36972P/D/l+VJCDMUHse8C8SCKc8wpIEbNemrqM8+pJH62cMDpXf0/jdAjBA Aufu1Cgy/qqLH3/I8iXUwsZH//tA/ijxv3PAyNyJAlkOd5Ors3Paip0Iqg8SzeKnLIe6C+QkEXRh 54ou2LGif835MPN4BSeO6CAgN2myit//mfKn2Bwmz4Zn3pr8IVuVBRm1mCfJzfg2T+Br4e/nW0Dx wt/zgv9BZ0n//32B/36N8xV/z5TdiFT84L/Qs04QWflxT96EoeXq/BN+B3yWIewiLcJ8U8AhX1y6 m/FEWpZPD/cPyZdNri4NPBmxR/Sb5fi+uD6ta/I1jtcf4m90Bckf74HGlAT1crH1kejdywTJfVN3 mzQF+5EcGROzGMgk8Toq9txvppcPl1dXrFoXYw95cqvNkuaQwH+8q9h2ghcEw9TYY85cvUz2dr1+ q+JsMk94MoJHuinC47eTX6AQx2ZJn69gsTjLmVf69uTk+gRPIFfiUc04SWsRYi+ViACRAfiSmggv b1TRw369U+dMywVIHXZscSaz+o6pw17qTR3s1zt1zs3UYXr251KHvdSbOtivV+rcZUka5+s0KvXK UnyuEzJRjkzyVcTL5G2yWMQrHEFWrLdnk+nZhImNi97HNmTzvYvSNMtWn0GqleVlz0b4sO27YW/8 yvWCMOj9c8T2T/mLL65OH+5kBaHR9zAg2XOrjZr88WmTwg9ClMS+/X6OnrNlJOy/9Q9kA2Z/4ezq /ZUXWhT3V/ob8E3L/jqHGUdzAhvg6y37a5NIzQ1IpP6oJmNDxn6Ln6JNWn7kyIqAD6qoDQtCH5oX w4BiaqrFUVHeFklEeKeMVl8OkLRvP//x/mNOMB5gwzJeIPWa9CWNRmKrbYncfCul9Cb5mCdZnpTf uXRcX9Mndom+O7+dIhqowoBNYHmfbfIkzkcf4heyBpZ1abQkfC/+BMzvydaV+rjPlkvAyJ/ipziP V3NV/UWrVVZGJVxfM4IFYY10usTMyDKvTh/OppPfGBdTCNWP3Eq4uDlBrX4U5lYS/amblqjaRYlk hCPj1rJtninTcbWK9FWLNY0ovJJthwpy9aTbmrNryh57jjvLtmInvItxhWQHavhlv4Jk5bPHzexf 8VzdigVWK1gTHbcptBDRhPJQw4/s/S4syTaKGf0ONFs9tYhlc2TfKn6OiYdYGzMbCfOu52We+wEw 0csbO1WBzqigir/+nwAAAAD//wMAUEsDBBQABgAIAAAAIQDNnjZDlBUAAI3iAAASAAAAd29yZC9u dW1iZXJpbmcueG1s7F3rbuM4lv6/wL5DYMBA74+uSPJFdjDpgXzrqUXNdKO7FgvsYn8otpIIkSVD kpNK/5yX2UfYx5pX2ENSkimJ4kWmMuqGAlTZFnU7Fx6e851D8k9//nYMbl69OPGj8H5kfjJGN164 jw5++HQ/+o+vu+8Xo5skdcODG0Shdz9695LRn3/413/509tdeD4+eDGceAP3CJO7t9P+fvScpqe7 29tk/+wd3eTT0d/HURI9pp/20fE2enz0997tWxQfbi3DNPC3UxztvSSB+6zd8NVNRtntjvW7RScv hGc9RvHRTZNPUfx0e3Tjl/Ppe7j7yU39Bz/w03e4tzHPbxPdj85xeJe90PfFC6FL7sgLZR/5FXGN CsZzyZWbaH8+emGKn3gbewG8QxQmz/7pQkbbuwGJz/krvfKIeD0G+XlvJ3Nae15BsowMNrH7BqK4 3LB2OwYzDuSiY0D4gOR7kWr1jqbBIyaTCLpF8Q4yr1B+Zv4mR9cPi9u0Yw3NXOgS1+j3j3F0PhWv c/Kvu9vn8KW4F+qZCm9mzHHPo0lLlG5Q67q/Prsnb3Rz3N99fgqj2H0I4I3ezOkN0sjRD2At3Ick jd19+rfz8ab06/PhfmTgU8LEP0Dbqxvcj3b4z16PbtHFx3OQ+l+8Vy/4+n7y8nOQzQg8fJiclh5P Qd7oLGeOvXQs0hK8ogYfPvKHgVGL0/xkk5wFFm13LA4evL1/dAPSdPo1fQ+KJ3/xE0QImL9Zcf+v 3rfi0rH5qTj+7/v8KYH3mGZ3+zlGZKXAlOwzPwdeYQTfTxEIxFwYBjr/9nKmHyIOoRtlzfDr2Q2f gBP3o8k8P/2E7g+XAb34k2K+UBZmkyw25N1byMJemXPbmE0LnsBbdyCLy/07kMV0mjM3l1pJFqhZ vyysJlls28tit3XWln3hVTeymBSy7kAWxoIrC9SsXxaTJlnsWsti50wNy1pjYnBn7UYWFxuoXxa2 xRMFatUvCTKg1EcLohWtRgvT2C628K/QWmVJPJyDwEvJ9fXBYoVb2YPFP/7+f8Vj/2mDxdtdTMak eBeFaQLku8neBxfl1/fjQwQOJowzDrCcPrCHMYpq9kMYlA7eowuDNSIIxh98z5bj0Kyhvy2ywbrF OGQZS2dibecFuzuR8sW00t1Nk5SvG4b6J+V5k5Qzo9VCyrPddj3bmh33ZfYAp0nK1w1w/ZOy3STl jIstpLxdOPPVvGuLzR469Uj5qqGzfzJeNMk464gtZOwsjLW9nF/Rk6ViuGI4oO21nhDuEpKxogbU igZWvQHcskkQS0JoC0EY5trZWdMsGm8TTMu4R0w56OlrV8mhf33NrAMmhmVvZyuHK2Ms+QDBKITV NF6yM53tdLPQ1ddAR+je9N9j838K8V7h5FpL7Lw1ISKome5Qizl2xuB0jIjUBfksclrLYRnBRsTQ URC9efEXL029uKCaZsfY0oMP2Xh8auLGApppblw6QQkfKpNIIAdJEn+Jjm7IpnDCojD2n57zGEkK ArNmSx6JuJkmESAz9Dq5wOETQ2BlEkkkLyaxNHhUFHo8ZdGnivBNJiaPPNxMkyclQRIei8kTKulM B4lTY8IjETcrk0hiQ0kSOUo6Z1GorKRTe8YlETXTJEopKQmMxCRyldRm0aeqpLMp18zgZpo8KSUl EYGYPKGSLnSQODe5ZgY3K5NIHGJJEjlKumRRqKyk8yXX1OBmmsQGJQWLqpRMqGcTjIm5sM1V5kuy ndHn94fYP/wVZX0a3BXL3k0ho5Dh4GWPFMhITwGkj9eOs7XMqWxXavZRf9mtUcqHoHjM8S4qjrb3 bi7eCitYQK20gKaFXW3wbTIAbx2dY9+Lb/7mveHrCYpXParqBxU8NqbG0jCMCbp3CqlwyIC/Qu5P 1lOieV4ZYnWw1OwIL6uyj8lUhI9WT1TjMx43iC5nfJ7p5/M//v6/GpTXMovsI0t7cTOtvpVRou6a Z+r7n5DaRNUoUFBRQNDlY2osJYqKzUPGUrMLluqA9K1F4c0yWYqa27CUwuyrkL5iPIQtUkk/e2oH QNvywIDFStzchpXV7t2RHSC9nlba3toBGJZ4nMbNbThd7vOEz+VjanYAAwUl1e2tHZiBocqiWpby 4uY2LNVnB2xsQmn97KkdmNncUQo3t2HlB9kBKMbMfdu++wPzKXfwws1tOF3u823sgGoIUy/CMZzF xjDnWTqfHcLwsNaJMZ3b601HWOvOfzrH3s04y5ODV90+JOHZHRSAgAQf/ThJv/ioBDE/mx+QfPWP XoLCkRsS9CItIHJktCAfunoYlwQ+wGW4UhA/9O3uYY2KFugjfvV37Yy9e6pelEDFX7BmHE9j/6Wo /8ueeYCSxvrRMPo5jqLHytOT0D19jX6EsLbS8OqGfvJcObiPgigujkF8RdyXt7vk5O7BGy6aiOf+ Vvn94sVh5RBUFPqoOLlyOPmtxpVzfkoIFd/k/lAgnjqB/1Rc/eAmXgAyJ80eKunErC8uMad3ybN7 iODN4OtDcI5/cXGhJ/59gGAaqUv2Ayqus+/Jt8vX9+Lry+Xoy+WoGzxByTp+IhQ1ogfGTw/rANgG 34kiFIy7xe34hci5KVRr/nROEQ34/LfiYaAU96M4hPJjdM3+eILXTlBFNPpJnrlPY5Rjg99htPOD ACkk/DhBR9i4SJbwA79AEgX+AfMIjjygxAsGp+EH9fx6pUwZrpYNpYVQmZ6kw3URNRuR71nSQTGU bYDKylLsT9LhyrCSLcF+JR2uDPfYJPYs6aAYZ0kpqSxS+gFJh+tiHrYE+5V0uDIWYZPYs6SDYhDQ oKRAqlLSoV6qbWyhNGC7ykoz2R67OOngmIaxm9r8pMMMKmUWW2eLq3DE2Z/z6cQtFXCgPTz43yT9 eXpSgqD6ug65KqJ/BDChon5zCV5SmyyAJteFJh4j//A2ouKq8ihdA9zN1TUkcbJ6kvURNEk1DL2h u5RJqgPeu5Ykca2+XD1EiRwBfs02cDXIuTulk6t/oEkS4chskmrobmdKJ1nvQJNUA2yllK6Ornai dHL1DTQ5IrCULaEavtmd0snVM5RIQpimsqWrQYmdKZ1k/QJNUg0dbFA6VcegPnPIXFjT6XbHrUbg QXnOEvq8M7+iMpZnVfsO5UnB3jWvAsC6HC/KgLQqVMcC5lhQGxuAU0PUGFhZ8lv+flbmMdIwWX6M D4oBxjMAYKMBAGualV120gYArJg7z7OHeqpuBwCsrZ8KOPedOKTF0Rwn9JH0QvNcN3zm5pheHUG1 0KDBhSj3wwEAw3kLYTwu56UKJDgAYF35ufW509YEJsVa8wy6YgNgXD93tXGm28kVU6c7BLrAnPEC oDrQldUWVhPLKIhSykSjC6plR3XvdkhNoxV9Mlef4W4PqeksVPjDpqZLPl15dQworQeI+y9ZsUpy fiwKJ8Iohc71REoMKrXhMDsX5tDdFG2cChcaV8BmQr5gpda3AW8oLWlRdh5knXgxN/B0InC1lLgx nvSNIa1y3kz1mBBJKzMEAoaeKYlsolysJDk0oaokwJPxrG9skU2ui9kya68qwJbxvG+ckQ1JRFGX /W8Ma6k8jcxUnIENsTZ6LBjOhqJARRvbrxS+aVs5eXmsQw83tRwkKpnUyY1+ZfvN2QLbJBA2kxuo GXnM+XIXwJ4ruaGK/5O+RK8cZs1h9tpyuSF9Qz0u2q2X8/XumpUxanERawAkr0cPf6gQNCu/rPhG VMUAa+ZobfovrbHdOkgfXMlIE1briihm1NkVZZ0/kZnuoC6gHv8qGt1WflxFKyWhW1pmGKelDYZu mcn6YkI4TH+lwNUyk3WoRPooCdbSchOVDFxNm6xLVHIWq/qov3bgaro+2LmhZaY+80nRhnywq0LT JkJZW8hN1fEgki05HvbKma7JshNNS5byANnldOZsto5DPANQbjCUV6ypXOkdf4jCA9bcoQGxLebE dDGZCNiLE0h5jQSrbmKYXzTMLyKL3+faQqd1saNOHHNmECm50Ho7ZFbkDEk65/mLwyeLRNWlMqQy 1x/oo4vIu27ZChhaYTBClQb0oPbBrrqARFw/0aykuBmNNDnSUQlc2CR+sMcuIHEoryhhVVIS/GD/ XSDBobxC5Pjn/VDVmyexTMmbX0J5xHzC3QpCPL9oYzjW3JkxfXowJ/lqJdZ8sTVbxcA1aPGykY13 KCKJ0kqlWnay0byymWLo2bt5SoKO25ELRGkQWrKts3r/XjtJFSYYnUxLkZsLJdCCjqpUKwzobiKL HCYqYEJHjlaVCV1N8pMETwVM6MgVqzChm64gh7IKGHDlAlj5MF+OKHo3p0vEhOuWrmIzoXezwARM wB5dc+DVlcNX31LBcuzNZL7LCrXYeWOxwzeDUNnZLphVtUX3dBbz+WZiywLotXxyBdq9Jj08zCgH qahF9cOMcoIIZwWeAPU1bbFZ0dMOEsZsGzjMKOdISISISno4dDpOlB5mS2mYUY4W1YahD2+8TfUh YXGC3FwdWkKiZDBbQr3zJWiSOvIMrPpGPNZqsbU2ZMXWNondrQ3B+Tb3LGgMnDxLPP+uVPZQhnz+ 4rloMe1Mkeh6MkG1vXIVNfTyEoCKfhPHTU8hqGwtmZgZrYrte8cP2fozMT/a1tr3jiWtUmLM/oLr VFvMx2gz/aDrjiObSRMrynWV9r1TF9n8m5gxWTynYF5hMhNM3yEzM9pMQehaaTRkG7KhxyY+THve jG31GRpds0c28SdWnWxN6KvYM170j0Oy6IWYQ9kOh9dyaLzsA5PAk1ZZ2dAiXg+deZxupqYx3VyZ eeTt/lgAURuYQb6ZGBpsAUz6/MV79GIv3HsJM+/4h9kwsuAeWbAf8i0Ki2j8XreQrBK9UiGas3KI ptRiN5tKVoiGfIqcpEsmrx0IJkDNO9pmskKwPtXWkjrsaOPJKtG6VFsSSBNIuqOtKCtE61FtPanB bjanrBCsT7XlwDiBlDvarrJKtC7VllwAUkT0P2UDS4vgKrTHNTPnc9hrOwvy2Kk/3swN4ghYOcyS vgcebJ/yAtzHpfNOnPr7wPvV26PtOgrnCJrVpnfgPGDzWJo9BpaVlpokKhAOlCgbGbyXn0mjr9xp pWw0WRHf+y8vzvaL9JMvT3hHDlQ/TJeyZRxFFI8zzA/O4KwcklMCn7lwSpXq2mkmuiYGeEWQ/3fj CWuyf23mr4BAlO1tzrVXc8EVgJctVVlITpB2+m48ZRGovJqBWl1iZb46m8JW8FpFU8czFnWq4oPF 6rmLE6Bm0OsinS0lQFmQTKSi47kWEk3uztsmalYmUTa+FejouBcLbrCVVBavEkpRizujWu8qpaiy gJNIinqclyuXxsilCJ9KcBExtyXnxVpY9tLMEoBtnRczWy8jqTovpuu391i4gbCpw15cZnHkQx/t paBW2lpczsYpy1wI5TJCWT9F2JUsHQSqDdlSBCo5Jc3+ph6XxDS4u0riZmURyjolPP1s8EiUx+wu dleTdUlEKvqdJr+E7zfjUEJZhkp+SbOWfqfHL1Gd4SnVEWX9Ep6aQvKssM/tIx9rxo0McLOyBPvl k3Qy+6JTn0TV1Ews7q7SuFlCiKouCTFGJZdkuZrPZiY3g8XDU5bGem7v1tnSxhBKwVurQSW8HlOs hHEnVbCQ+xUNmAEvoM6S1PLLk2arGA+bcDTuTDtswoFWXh424Rg24cgsog5XV7IwX2AJOxlgdXm6 sBCsBjcJvDqevcfNEiNsOd7U5OhCkRmDQmUAFcYsHom4mSZRaimT/ji6HU08lKsLEIVjUObFEKGq GzisEtHV1ADSU0ue7spZmwaBrNtMDZgY07m93mQ1gp15uhq0SmAUEMym7OdevVsHnjzzAI/GeVb8 irBZxzqpHKluRufXzmBtT3d0g2Dtnqo3S+S3rQujn+MoKrY/yN4vCd3T1+jH2D9UXlNtlzu0XDBM /Kjc463ye9icg6hGsUbe7VsRQoDRhu+p9y396ZwGfujdoN9vaGMT/A2UYljXbVjXrTlh3nb7Zjlv gYdhDB57vvuAICgZPPbBYwe3CvU42rvqFzQ9eOxdeewk8KQ9dnu2mM/WVjbTrXW6PMO26+lyE/0V /jZ4Y/qAaz2FfZfMVG46Pyxjzh3R8P5fBePap7IECWUbFugGqajVSMlmzMUEwpxAHTQKEq4WrNZM EwmoB3oqZHY4dQ9akEQsRTLxUQOdgrQk3qyHphPMiJhOWUhRSphkgqcOUgVr7FqV2fdIj4UilYUW FUhlw4yqGJXALbNs2JeUFuyS7FPKV2AtKCOlwGTzMD0JdgGsWsvNUlaM02Vl3Rg1+QLFmpBIKIzP lJQ51tiwXRQtZRPZLaFSy+bc2xANc0g19GWBP1f3yC81QiVhq2biiTqUvJ3FbGHOVmtCFNvbES9q ttgtjZ21zPAr2o/G5XVkFdvNbGnYsGhumzly5SUaAHQrTZSgS/6L5L0GMfF0E2SEVFMZ0pRK3Q/b WBDp7aMgioHLFYhu2MYiRyBfvhVg5Mt78dUNnsL7URiFHuprCM6Mnx7WAXASvld4+fuGO0E38iWy 8QLHS9QnUy9M3dR/9dDyWXJQmjDxZukw+6pV75dIrGT1y0gFNkMlJqyuYUJzoSQ7MlHOH6sWSkrl jyeY5FOwhz4wRZrQzdK2wyrP96NeF0pU7UFXXaHXpRQVJnTTFbRUFXdUbFFhQHcLnve5HKPKhK66 AjMgUh4VML7bnEjrCv4loWIpIFrtlrP10uEFRLzS5NVqZtizbdelyb/n6Ka2lweUZIC20iUa1YIM VvmFfJmFWt0EoyIi+S1/P94ud69enDpDYfLOD/BkfIg1TnGSbtzk+RJ4DIXJQ2HyUJhML4guDD2H wmQc/UJcDxOhUTgPn7k5phfnECDodVC1mFfKia61pAz67Ctrwkf67AkrkMhBP3ru50JPgE4B/38+ 5LAXtW7A56KU1MKLGEHiAE5FjCldR9LY7Ovw4kUN15HMMPu6PAvJeh7JtLKvw6vGNjyPpC3Z1+Wg Pet5pDczr1sij7rhcSRtwryM95YkuGBexhMCWS6SeRkuSml4SZOsFc+8Lk+asXgCxShID5jX5cly 5nUcZeHpislTFo4QTI6y4HqaJr5wlIWnK9l2i0y+wKKszdpictSFVP40vSlHYUyuKDgqQy7EkPFP EKBAUTlUMddrjqg2HIflBEIuL29q7B4wH6hRg0yeymZr2zJZDOrczOJsiTbmhUWGmKW0sARb46ta vL4Md228EDST86oc9SNP7FY2HJNn8XQK3q2ZYJ5Nh7s2Xkiq6hrU3+JpMU82E47+fQCLJxwDCtBj s2pABrmRU2AlORdytBjMFudCjhYXs/pY/WbC0+J6T/18+Ku7d9J14Lnh+ZQ76/QTHrwY5qb88P8C AAAA//8DAFBLAwQUAAYACAAAACEAdD85esIAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVt MS54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITPwYoCMQwG4Lvg O5Tcnc54EJHpeFkWvIm44LV0MjPFaVOaKPr2Fk8rLOwxCfn+pN0/wqzumNlTNNBUNSiMjnofRwM/ 5+/VFhSLjb2dKaKBJzLsu+WiPeFspSzx5BOrokQ2MImkndbsJgyWK0oYy2SgHKyUMo86WXe1I+p1 XW90/m1A92GqQ28gH/oG1PmZSvL/Ng2Dd/hF7hYwyh8R2t1YKFzCfMyUuMg2jygGvGB4t5qq3Au6 a/XHf90LAAD//wMAUEsDBBQABgAIAAAAIQC2vdOa4gAAAFUBAAAYACgAY3VzdG9tWG1sL2l0ZW1Q cm9wczEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyQwWrDMAyG 74O9g9HdtdO1qVvilK5JoNexwq6u4ySG2A62MzbG3n0OO3XHncQnIX0/Ko4fZkTvygftLIdsRQEp K12rbc/h+tpgBihEYVsxOqs4WAfH8vGhaMOhFVGE6Ly6RGVQauhULxWHryrP9uenNcP5iVV4Q+tn zHbNGe+b7W7LTjWtN9k3oKS26UzgMMQ4HQgJclBGhJWblE3DznkjYkLfE9d1WqrKydkoG8ma0pzI OenNmxmhXPL8br+oLtzjEm32+r+Wm76N2vVeTMMnkLIgf1QL372i/AEAAP//AwBQSwMEFAAGAAgA AAAhAKnIXKqMAAAA2gAAABMAKABjdXN0b21YbWwvaXRlbTEueG1sIKIkACigIAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAALJJsgrOLy1KTi1WCE7NSU0uSU0JLqnMSbVVinEMcNSLCPZR UgAL+CXmAgWBYkoKFbk5ecVWSbZKGSUlBVb6+sXJGam5icV6+QWpeUC5tPyi3MQSILcoXT8/LS0z OdUlP7k0NzWvRN/IwMBMPykzKSczP70osSCjEmoYVYyys9GHe8aOlwsAAAD//wMAUEsDBBQABgAI AAAAIQA/x9XbhwEAANsCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACMkkFP3DAQhe+V+h8i37O2Cd1SK2ukguiltIimAvXm2sNikdiWPRD2 39fxblJQe+ASafSev7x5dnv6PPTVE8RkvdsQvmKkAqe9sW67IT+7i/qEVAmVM6r3DjZkB4mcyvfv Wh2E9hGuog8Q0UKqMsklocOG3CMGQWnS9zCotMoOl8U7HweFeYxbGpR+UFugR4yt6QCojEJFJ2Ad FiI5II1ekOEx9gVgNIUeBnCYKF9x+teLEIf03wNFeeEcLO5C3ukQ9yXb6L24uJ+TXYzjOK7GpsTI +Tm9vfz6o6xaWzd1pYHI1miBFnuQ3wBHHx+qm/zJrVZfon8MLV30yakjKPRRRvRFmeep5V4lvMwX cmfBfN7Ja/879119T711Lf1Xn45EeLLThcqmOJZxxl1F6xCMzOmPa87qo6Zjx4I1grFfC3M25Xyl uH1IMFWuQuyLm5Wb5uy8uyCZx3nN1jX72DEumg973uwqS+W/LsDhsNVbiCcdXwv26TVxBsgS+vVz lH8AAAD//wMAUEsDBBQABgAIAAAAIQBhkXUZwQIAAPcKAAASAAAAd29yZC9mb250VGFibGUueG1s 1JbfbtowFMbvJ+0dIt+3cUL4q9Kq0CLtphdbp12b4IC12I5s05TrvcL2Hnuvae+wYztAC0YFbes0 IpRw7Bycn77vcy6uHnkZPVClmRRDlJxjFFGRyxkT8yH6eD8566FIGyJmpJSCDtGKanR1+fbNRT0o pDA6gvuFHvB8iBbGVIM41vmCcqLPZUUFDBZScWLgp5rHnKjPy+osl7wihk1ZycwqTjHuoKaNOqaL LAqW0xuZLzkVxt0fK1pCRyn0glV63a0+plst1axSMqdawzPz0vfjhIlNmyTba8RZrqSWhTmHh4n9 imLbCm5PsLviJYp4Png3F1KRaQns6iRDlw24qB4IwqH4YcWnsnT1igipaQJDD6QcItyGI8G2YRd3 4NzGXRTbBvmCKE3NZmLqywXhrFytq0pyIvxAxUy+WNcfiGJ2PX5IszkMLPUUwx82H+QrCejheSXd m9N6Xsldn96Tu6ACfTadYfmxV84eiHvGqY7uaB29dyu3E3aJpEChg1tAIoNvCldZmAj+M0RuYeHp 9WSyJTKGSreXJU1lS6TfVIJE3PMnvs/xRMZyqRhVlklQHynoooX7wMFqIwUmp9DgckZVSCAFe6Sz fXUcZNF6DRafwJw2lHSQRHstsO05rIugU8jSSD/9vzDKiEAezx0HUpo7SJG1tX98//rzy7fmUXbC xJql43UIgeKOIKJe4su/GyYj+1/gna11Ov2bbnc8Ge3KpQV7jougQ9aBPOm7Psdb5xoyLhyqKR4B h8yZxhoHbBPkgIMRomumdQP4uFD9t7a5JwsI06Bn1iB8mlogfxkEbCbp7W6WdnB7TxDpS1kK6j05 S0nJpoodIDFx+enEADZ5DRI4fUoiA69cjzeVk3aVU60xJhxAHNKE3Ve9Iuw+exqJ0984rDn2SeAs QOKlkMA4eZFE8+qhL38BAAD//wMAUEsDBBQABgAIAAAAIQBxoNvcJAIAAEIUAAAUAAAAd29yZC93 ZWJTZXR0aW5ncy54bWzsWE1v2zAMvQ/YfzB0byz520GTAkHRYUC3FVu3u2IriTBJNCQ1Xvrrx9ht l6w9JIegOfhkiRafKD6Jonh59UerYC2sk2AmhI0oCYSpoJZmOSE/728uChI4z03NFRgxIRvhyNX0 44fLdtyK+Q/hPY50AaIYN9bVhKy8b8Zh6KqV0NyNoBEGfy7Aau6xa5eh5vb3Q3NRgW64l3OppN+E EaUZeYKxh6DAYiErcQ3VgxbGd/qhFQoRwbiVbNwzWnsIWgu2bixUwjlcj1Y9nubSvMCw5BWQlpUF Bws/wsWEvUXhFgrVGe1aWpFAV+PPSwOWzxV6sGUJmaL7arl2T9+gHcsavd/J0T23YuFRtuZqQigJ t6NQ+l0uV2+I76F5PXYG3oP+T44zzmq7RfP/dAzSSnCge9zOtW00vEIzu3YFCpAN/uChN0PtWHac 5nzPouN07e7Kj1ENOzd3i+6b+w6PBoe/TfOpHJ7QOMrjpN/oc6g313L9vEnZy0Yftv/+oTsZG3GW lGUed6dgYOPAEHgqNoqyYBlLh7Nx1IV0KjYYy/MoK8uBjrOgI6YZTcssy4dYdUy6dqrTkSQ0YXlW pAMd50BHnhdZgi8oOtBxFnSUeRrTpBiC1VncHSxNo5hGtOzf3UOi+86JLsvKGBOrIiqHcPVe4aqv hnT1J2i81PJR3ICdWWidsF3BCWtpm2/m15fbrseVgvbu6yfsoOpO5W/6FwAA//8DAFBLAwQUAAYA CAAAACEAVMrfEy0uAABoiQIAGgAAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1s7F1bc9s6kn7f qv0PKj3tPmQiyXfXeKZsJx6nNifjjTMzz5REx5xQopak4iS/fhtXAsSFAEVFoozZqs2xSIBAo7vx 9QWNP//1xyIdfI/zIsmWV8Pxn0bDQbycZfNk+fVq+I8vd2/Oh4OijJbzKM2W8dXwZ1wM//qX//yP P79cFuXPNC4G0MGyuHxZza6Gz2W5unz7tpg9x4uo+NMimeVZkT2Vf5pli7fZ01Myi9++ZPn87WQ0 HuH/WuXZLC4K+NpttPweFUPa3ULtLVvFS/jWU5YvorL4U5Z/fbuI8m/r1RvofRWVyTRJk/In9D06 Zd1kV8N1vrykA3rDB4SaXJIB0X9Yi1yZhea7pOW7bLZexMsSf/FtHqcwhmxZPCerahpte4MpPrMh fbdN4vsiZe+9rMbHyvf4lF3W4F0evcBSVB0q3WmIMSeNFimhA1rfalXrPY5HtsnQFUFd8DG4DEH+ JhvJIkqWvJt2pBGJC/KwCX//Lc/WKz6cVbJZbx+W33hfSCw9RjY6xZInTq3w6kAR3cfnaBUPB4vZ 5YevyyyPpimM6GV8PEAcOfwLqIp5NnsXP0XrtCzQn/lDTv+kf+F/7rJlWQxeLqNilgB5viQL0C6f 4pfB52wRwUq+XMZRUV4XSaR9+Hy9LPTNZjC/em9v0SfTaPkVuv0epVfDePnmH4/yR/hP02QOPUf5 m8frITR8i2fA/hVmsuLzIm/Vpg0KAtTFI1GbQJT46WM2+xbPH0t4cDUE1Yt//MeHhzzJctBl1W+P 8SK5T+bzGJQ0f2/5nMzjfz3Hy38U8bz6/X/vsIqkP8yy9bK8Gk5Oz/BKpMX8/Y9ZvEKqCj63jBbw 5U+oAeiRl8v/Y23HaKJAId3rz3GE9ofB2LvFxLvFkXeLY+8WJ94tYIPxpNWZdwvYeD2/ceHcosxm ZPXWScVrRxeWNUct8Op5tcCr59UCr55XC7x6Xi3w6nm1wKvn1QKvnlcLvHrOLWYRFmHnFf+SlCno aEeOelxPS68G9z9XcZ4maFd6uRQncWFjqscyzxDccBzV+8XqOSoSQFeODe6//PFx8JDHBDOWMaAK j9E9pNEsfs7SeZwPvsQ/StS4EPQwVn/Oc/2UDR5X0QzDK3kQ7mr0Y/L1uRzAdovUb30upyOL+JKW H5MCz0Ic9KlN05Nmf8sThXKnE8vX/ojnyXrBBqpqmtMj98aK0jk9bm6MJqr57IljS/Wbp80tEZU0 3zxzbKl+89yxpaJkT20y9w5spoGOEc5s/HObpVn+tE7ZmtaZ78zGRbyx9rM2RuItdSx4ZuMiSVQG 17MZIC/N6tjmXMmMub1t2pXwmNvbJl+XInMvNkLUepmYe3GWK3MXNgH7HH9PkJdhMzWKJfshyqOv ebQCE1lWpUfH6BcnEPu/66zEG6KoDCfuEOrDEsB8EQ+0/RxhjO40Dro+eF6WxXFWQObFcdZE5i6c VZK5CyfdZGzupaTMvdjEluscvCQmzXFmk1zeBd4TjF3YxFarv9Q9wk9/qe1thFD1l9reRoWa5hmz 5VB7sRGi1gsXEbUXb/2ldmHTX1pBVbvwFlS1C29BVbvwFlS1Cy9BVZq3ElS1Fxt/cikTBVXtwsai vAtRUNUubPypFVQVkvkJqtreRghVUNX2NirURIwLqtqLjRC1Xrigqr14C6rahbegql14C6rahbeg ql14C6rahZegKs1bCarai40/uZSJgqp2YWNR3oUoqGoXNv7UCirGiyICdLSi2V6mtrcRQhVUtb2N CjUR44Kq9mIjRK0XLqhqL96CqnbhLahqF96CqnbhLahqF96CqnbhJahK81aCqvZi408uZaKgql3Y WJR3IQqq2oWNP7WCqnh5PQVVbW8jhCqoansbFWoixgVV7cVGiFovXFDVXrwFVe3CW1DVLrwFVe3C W1DVLrwFVe3CS1CV5q0EVe3Fxp9cykRBVbuwsSjvQhRUtQsbf2oFVQmueAqq2t5GCFVQ1fY2KtRE jAuq2ouNELVeuKCqvXgLqtqFt6CqXXgLqtqFt6CqXXgLqtqFl6AqzVsJqtqLjT+5lImCqnZhY1He hSioahc2/kThvDQeiPEzEfOO/b2epq4m7sEsOqjP8VOcQ8pZrPhy3btivlhzX9imd/LH3mTZtwGP lopkOsL2hlsnyTRNMuyi/tno7z4i0eVaNoeNq778/XZwT5IwmnsncWWld8VPDlktYoIKyv7AGX7w YgnR3avhSvS6Q/IKSueBlEE8ApTT8gFyUGgmCWqMUkugLU6uoT/jlBJKQPzfkHY4Z++MRuOTk5v3 VLFAKg3qpIymOGMI/mXvpfFTib65yiCt5/iIio7phXMWLjS9MJ5cUHVofONsQlWV6Y3JmG1yxjdO LhoGejSa0M3B1MfR8UnDSI/OzxtGCvSinijTV47PThpGejI+bxjpyem4YaSno+OGkZ4enzeM9PRi 3DDSs6PjhpGenZ01jPR8MmoYKbBYw0gvRixcYKL6xcmoYaQXF0d4pCCm0AkWioLkE4AsRE9lDJmr ExgI/AV5GCCuwh+f1ygjL/4RzUoSU06WSOyQJHERgn6pzEF2HhK9vJaPd5ut8wRSISAjD32kysW7 iSA/GKcj0BS82pso/U78CUt+8Qv6wLqBsX3x6xZl/wm/CXl2WBM1qCT8DlJCVDWOccKbqIaqxDU8 hmkEeXN/R2lwipJaQr6H7nez8hrdgFhQbEYJ+S2OV5+gI/yx5XpB6Ar/8YErPdwA5smfZusSLd/H 7yn7POYttjrwbxtSTIykoBK0G1IkaTVNut/5Ugc3Y9SheZkC7yLeu84TSG4kK35b4H8T+q/Ec1jM oSvM/y0JfWQkNMVnuyc0XXFfQuNm3oSWCMz01yYEJvnEOqGm+nP3BKYr7Utg3Ewh8HRbnHpi5FSq xHZPSLqivoTEzYyE1Ip+F5x5aiQoRRi7JyhdWV+Csk1KxgdazmRaYhMRJ4nqOhGntsHuCUlX1JeQ jM0wIVvuMOdGNqMwdffUocvkSx3cTJFbIq/w8yYsdWEkGvUg7Z5odPV8icZAiyybHLvX8I+0HTvK 6uwZ7P4Z2BcI9RvMfnoGhuflIdNBITl9acDfGuDXMCCr/CwM9lI8WCVck/ckPwb8ZJYisJJIxrth zF/Qc6u/YoBfIchRHSDLbG8aIdhr05R6M6bpB2x5vdDDOcSxMv8RkY/Ai7dxmv4R5dj3ka2AGIZX ke1Gno7BPoX/qnU1zcoyW5jb5ziVHHev6wDIKg6G/IkmYaY3cO40zmliuoHmnzLkB1U4A3Lj8e8G VnCltOPYuJ04xv9TRvN3YoLhIcGZFzwoRT9U462tv+zS0liFQCeNIcjsGPoUptKwSUjkrqYUJfb5 ULHa+nyYcnGej+Rd5PNBpjxoHiQOdUAAP+uXBp9lw4/ktRiDh+2GQiCqLpknBf4FUcFegFkaR1jV Gf2L8hs6B6P8htbDWHtF52KUX9H6GGuv6JyM8itaL2PtFZ2bsfaKzs8ov6J1NNZe0Xka5Ve0rsba Kzpfo/yK1tlYe0Xnbay9onM3yq9o/Y21V3QOR/kVrcex9orO5Si/ovU51l7ROR1rr1CvI3Y6chGB sxQEDmAZgV5U/yfeX9C+hF8Zj6jfGW0kJu8l7UT0TW7k+7rLIMNf1R1P5Ged7qDaRqM77o7Ho1tq j2IgioIl+PBw5Qf9lr35n89IJ8EkW4FVCOuoPktyVFM3WjGoYvJXRusy+xzDbgw+RdyHimPYsU9Z WWo2LrZwQVlW+4M2JiOLkDYoI78SlCVXLdLuq43OyKTbe2XJFSHMDKDM1XCeVeHL8WhEolyNepEB QqpaAA5lD3mWPW2mbtS4ADnnHdRNJeLjgM200DhgM73S0oaDZaW1RWzWkbp5uRRhGLVxtqOD1JAZ 0kHtw2UB8piM2UmwD7WaLNiHek2mTUqpaTKdfbgVHcS8KBYltJlNpneoXedlAlN+jGeoYpLiiJJ8 hSad1bWvkEWKN/StgbmpRtOR7m0fSQ+6N+hewXuqzQOUFUjQvX3QvdQEYroX/vXKQgNNo6abIE3T PtWktaZ5Pzp5d3xDQgchCmD05QXHll4utUnHskp7JVGAraA8FuXaQNOoeVhI07TPwWqtaYIL/WoY 4o0GNRLijVpTnJ1ykOKN29E01BmygaZRExWRpmmfpBg0TbCegvWkSSaQ8VXfvOdsD9xA06hJv0jT tE/4DZomaJqgaQ5P09DUvQ00jZopjzRN+yz5oGmCpgma5vA0Dc0AbqtpblK4+QQX1a+nduMnpN5+ UxaSb+a9cl5+zIohiMkO42NYLbDasdUJ9S3QnyTLqiEjX5/BfpPNf+onCg9+7zw9F2u2LuAIySMq 7VEv8/H57vZ+/GaZgWN/mUEYUomLwguD+/HgzWCZDeAl9A96TbeirC/+3JTL2pigqp6dx/uW57T5 2QOUP7yEFGLt6qEsYvRwUKKbIXTzEtNznTmV5hYL1RFoVrR0cosxZEOWsXRyi0/r/XKOBl7VyqlL YExeGMC9GbQyj2569DQXP8xVneXynSzcPldep8lXXogBHU5BRRCo2DXMUi92t/R+lPrk2L0puimJ K2ZiQq8CEDRAj8s7VDUfJrX4/cvlv2fcS0hS62F0jGt5wqf2vO1GnMAY3MwKnMt3xgvFGi6WKWZ5 ssJSBlTxYQe7CuPzLlDRJ3SZoFaPVa8N+Hs69gFFVr1KVIKssm4ujm4vqDzT0KOeQ9iq8qfS/nR+ NkH70zOcP4DTdq13KFfaNNCkUffJNNAERVCZlI8g7qQ0B58z/EclM6SeEKw+f9zdaQTolXTGRA7+ dQlv2wmI90cYrZZ8bGtEz3Ws5KKJnNUsZTWpGo3IUJQj1d2TsSHtgO5N/GxxdfJFe7ke0VdAy+4E lpRlq6t0hDXIkyZSNrKighB5mMZJRbuRplOSfFgWZb7GyWmFltWkF5oIZNr1rLx2dHL2/pYyEeWR KXyo02miFLpP+IAxXOKlYwD0woC/0TRPmRHO7s7Oz2mAWBCWRp3Ezt6DFNOj0bh1J+rjerXSzhP9 rptdSxR9NplMTm5Jj3Tqq+hrfJPH0bcbdG8aOTVGZ1gDMlAQkazzlghwr56GQ7IOJADboksqXI9G F6M7iQp8xk01qogJCWvOW6iKlB3u7pQ97tXDO5w6+PT1y2XtlHdLHnGlDv0o0KHat12og9sBAX2o w60ZZl6rxEBPsH1tPMNfHRS36jcNZFH2CeRJAEyGrBaoqAdnuugfpPIecoJSUdlokupRiWqSWBaV JReBRCeTJAJPVQXV9pW1yso+itYqh24+OEBZ37skL8oPS7gAVy0fUREBvzWgr+nUJGMXIuu+FCGo 6QkNBW0OUGNxLGEkR82vTK5xXpYZbWOF5dM/R6S46aYSKqygTVjFJTRILltEkSr7tZS2CZJRG6bW +Wo2K6WtLDaZpE1fUTL8PrVlnSf3smxTl92mWYHq49TxK/tdp7A2YYhErvK6kap6F8FtifWB4x+b Rt3Kpqj2XF+d+v7NIkrSR3AnRuU6V8dMng+qF5rG76hZzOM0uGHZZcZ1ovLS6rqBmb2ubo5JumMn uO/NSqu9X36P02wVX8/neVyoxmdMnw8i+oJuPpuw91MOFcYfctBwUCPr7IIgsGfwh10Q/PUslj2G t54foV4yCmWQxy9wgejVEEMz9PB6OXvO4Hg+Mn8QevuBXdJXQ3RxLCl28pP+QkprEQQhitjknJ/l l/ERdwtExSxJWEFa8tFC/Fuq1gYM1QoxsXX5HAP/qyfW+LLk5Hlnq0JZq91kweNWFYSmvgQRRHI7 ooEkelm7y9I0e4nn1S3ldaFT39DRxSx9jkqCbzMzdJ8ycAAuOXU+YmUg4DZb9iPaKaB+HQyjmRH0 s0a3n1/P4Ib1n6oTEt+Mzh5uZapmfagP2ODRGlQJGW3XaqSVLjST+jbR7JB45PjJVojM+clPoVsm kc3VLZNMAj3Z7iTqqkMsGl9py9qvTdXlO1cmiBqgCJJloj0RjIklPN8uybpa9/+Jf06zKFd9q3g6 /Ol2J7Nv629WVA858o0uorLUuKMxyaQ3dGQTkQ+4jb4xvY9ai41vofwqkTu1dJehMKbs3a6gNNcW 29xr0fgfo8UK9q76JosJQ5/pSNLd9toVJ22y9X6BS3NectgUcj0hhOf9IMZ2MRpijn9GcFUDqtqr 5Rz+dLvk6kSlwtrnSKrVmfAnfrMwC3+jtEtYE6Dm6I6GOjrEmsgd+gnH55QZAxlilPwFxYG3gx98 kSYux1HnsKpGRy1oIuppZ5RP7T/ROkReVARiWNbGhl5VNF7Vy4ijoDQOs6V5nFE7u8N5qG5CPI/u XYPiekDV684XRC2ngifSXE9lE8Zi+apdctaJIsV4Is3lGjaaCNjBXYvIzTpNYzVihGdDn+n0sCj0 ygkG3znywLAUGcX5BqC66FP4r1ahQTQTMhGDNiAPHcINW5onu9Whs3katAWdZ7PS2NI8N0sG4SHB aj0NyoTOs1mnbGmeLKW6s/U06Bo6z2aVs6V58shuBxO9heswkuVaxbVYD/GnTZrIV/FosxTwR8SN sAMgwmZgUEHssYMS2s4UEWaBeW+iY9kcDNqHPXaoW7mdKWI409EcDZqHz7FZ92xpjhsexUHSxiZh 0DrssUNlqi3NEYGgDdfxk94Qw8qGPsNaoEMLgSrJWoLgmCW+daBDycANGoY83IJ+McyLpax1Ni+D WqHzagY1vsxomBf+UDeglAzdoErovLpXJIZ54Q91OS+D+qDzagYtHa0X/tDm8/oD4vcQ9jZctkOf 4hvHDT4c0V7yndrqZp4jb0yJr7vCAVEa+wR3SfHraojvukdYhh1DxA4tGrrHioxehtWqLb8oq1Vr fEiUue79ho3QCJ168cwvBF7NSuJgEScJH3hK0lScsojgFFdGHQxwx3/dL06uxkVuqetl95kIhCv+ FU8VbwJ5MvgvePbfWqdgK4YyZCDUT6dU09U8QeHE+s9kO27IPNAHi8g8PujzVikV6NOut2SRQzYE wJ/gvChSDrrkNfQMqwb0sGkOW8sF00e0H0CpEZWscCBK89krr/RjlK7LSBtSFh7tjMB69q6y6Or+ 9OpJ05B99wuRr9nFOUiX2m8n1DPIYwnpMWpCJv1ZN3JzjNIrAW9K+saXO8PgW+mWx/W0TEpNtIw/ 0E1A1KxuQ6bBDMWbQNLC9aeXXy4bTsFsfUuCI51AGtD13LX2Bf1yBAv4BMXcC/VsEX4+OHo3oG8M 9GeM8GsiFX0ZGEZWYMBTVYZBAAaN1XjnoPSC7spB6QVWK1+qoii/obvURnqDVWI196G9TkLqg1U+ M/ehLTMs96G7a1B6gykB81eOdTcNSn1oL7OR39DdMyi9oS1lLr/Bj5MCD8ByY8gpv6G7ZFB6Q1td WH5Dd8Wg9Ib20iz5Dd0Fg9Ib2ip88hu66wXlN+jtEaABmVAoWmbCaufU9L7oJIHmB3TFLsxmRm6I FeyCIkuTOVIR1C64HaH/Qz8Qy+AO/48ShbUHqjyi8i04SZpcEIwPL33OXjAgooBZ3IzoBxhzVqmp bJeitMZbC//O7CbL4XIzrNZcDSo8eDqbcwjGkuRp6D6dTHP2faguQ5Q42IG4AbUDxcYoAIAmDk3z yTRt0xQxYDUH/BeFExUJ8QdUgqZRUTJ6Yi40U8bJwhVnVi1q78iC+ew2S0185sxOjha2SLaecxOj WgM3IU3KeN3seRDp0mN2WsboYnTMTB5k8dMesuLya9szpbV8cSXnJkSRRPeg6Vk4s6ewB/hRRBR3 v5Y9482i4k2KTzBIYKoOJTDyc1b0hQaV0JrmB8nAsPNikxjhGfwfQFmCDQGDW01mNfj2BbUQTWZ9 7iF+LZjMUC9AdwOjZBIFk3ko0eM0mMwSPdgFGchGoX6kDkxmbCWCFXMTLeePya+YKVvqAQP9CkEK +BEO2mJASfTF/EdE7a5pivDEH1GOjSQcyDO8SrcxeApBKmS+1rrieMPQnqlkQweILMJgyJ/EmGbG 6g6MahiG407VL9tXMvK2tQlzjsDeMj/ow7ilIbYrGkmvw3hsQZgeW49TUGvj+yz/5WJACmjRzawW OUZmVrf2PSasitVFX+IBqD2YQkuwrGZ0KWBZn9YVwDKNgwWwXIPCo2N64w8gP4bQJHAYwLJMsV2B ZQynwY170HBaDYU0xZYOYD/A5gVe3npMzdFrL6ALPygrIwu/ti3QnghqeuZARBE5x9VoQZgeozUM g/8Jty2IQTnJucpCqTZJ3cx+hp7BUKQSZAiponFOuhwnJNWeiDaeQ/DcdZzBrEBp2SJxBR5qG1MP ZkU9be0WlFqRzExJa/RxyFij/kgDPg4WhYyPQ8aaTI+LPc1YE7KrBPwoe5fG+FIYTXoUCpiSM4VQ HTwr4UovZjt6d0A2RXE0gq8dNvbeOP75hcIY/VRVQOVTNmi6NBOvwiw8ZKGzdnS1gzDgecjNaWG2 RRHPPombrLioPYTnLGFOF+AX8INj0MTl4NiBEM8n4tLCuOkxWwkZYpRtRFc0FP9mWo8WhITix9Iv IOyO7NavGF3A0gYsbcpmYVg6pLKQLStgaTgSehJOf0iRhv6e/hDRqwk4BCztkUSzLSwtOSYrr6vz Pt1/WA0bV1UYoKgdAKIncwDDGA8AEXPN7mvd5vGVHqNJCWdr8KQzF+7eOLNyUUeecDv47hGxkMhg k99FdtxPUew5F3SkS1RTQ9LhSB34Zu7vra0F/FGgo5XOWfTUrDClBTGrI+QEBasDpUXjSgDB6qj5 50dn1Co3ZUD9Tg8+hQVuOo6GupvS6DuzTmievSbx+XcYN+BLS74+G46nOgyA7L4iMXoaaKijdge8 heMF2hSjmte85t/EepNc6VY7xB+Mp/oyUCjSpfHkpQ3MwaDN4nt7jjMpI25K9ibjrMb+lRkKaqXv Pv62uFMtxEnS0Rnu1JfiDLnoIRcdpFVTpyjkosv+8EPPHDHjSZcUBZsv1gEOWuFk8/cPBk1uy9Ue kCS6jrUqr4sYpioHJTlQ66nE+4skbTLXLDNAgZ373hoJT+4L2ij+0YQlDwAyag1KwXfd7/AGllXX Ym3BQ72CbH1wnunqvNwiJfi0To1J5vR5yDIfBh918FEb8qL2KzNG55UyugN/j48anSwkAmS2KSw2 QdXcBnCcOmjno64GkMCdCfP4nhnIcjq9GWIh+iMCHIxZonpXMY1sbj4tJsFYzNnJ3SNkJgFZlVrI hkD6dKtAFjKghQjBIREP1MmmxBPQcFMZo/2yirbETCpOrrkImM473GR6kBDPBA8Kj4155Qw+h8Ty AJ8DfO4FfMabgT8sbolMMQ44JGBYv8wMId8GqNMBMKyFf9FHOeB2C/9uuH575zutowSU79mwDsQ4 seeON/lOews50eSds4A9ys3smUu9zhYOyUkubBHAIzLt24FHY3owA48hPziAxwAeDxk8mjMAcb3s hgofFp+qS3Mr8nHpwOZTdWnfyqdKN65Dg84nSNBnSPNDhS3wmjc4upqhc4Nvy7b4Znc2s1r2HvU6 kNAF3kiot4GiZmk8ciGoRZhcmu853OxoPQTfrSaTYXNjcO+p6GvLtQGn68XSeGPqbZaixyEtIKQF VJfYhqNrPTi6JgZ1QCuIzjHq9MQOIBDw9pWsxUNcG9XbMO+llmB/BU5s4MapA8tm7NCeIAuRGL04 0cZL9QIStVwgWwsHTtvW1pIXaZ6tWaIaXP/aD8SD1tnLdVjPd+iKlLuHLV6kkFA1w3GvlBaiR/mV k6LzkuUoJCXb1b7wWWtmb6NkuTROFMPqIGTzOgu12CMSNeRD/Mus7qt4DGR/VSpMwTvegGw2S64K NulCqkqINoRoQy+iDQwoYIYFAE6c4Vsx6Xpw16eb3YJ96wxkoh3WM09k9xtCY2ZxQ8wAYXROK9Hm F643EksEMi5jRKP5n60Nvt1TcOtWSs0DjeAmADlVPMlO0y/cIXIPsATxEATzhZNiG+bLkaaUPXxw o8MDWzdfRqNgvohnyr20TjBfqHnzYX41xCVpaMjJki2FzZeQLEU2FQOADdchyTGacB2STI8dFFPc l4iULdjQfHzVpbUc6nA9O8oq6LauiMMGT/Ks/slwvO/3id1woOGsYBbu3Cw0RYpdJOsV2JSwPqJn J5iO1HVhu2atZ2zRuelY1C6Q6Oi0xzZMx/EWTNyDj3yBTmgVAzJWBqVpfaEyaDCiQgzIYELvV7Uf 8bjy5pl7IcwT5wUGFq+i5ocuzIM1nzaYeNCQ8xVMu3N4qRZGbTyw5GJl7iG8bAu0ToZImSyjRcy8 LrQEOwVaJ+T8wDQq4vnfl9I7n7J8EaXkeREvkvtkPo+XmE1zqEHG3oXA4s34/Jh2tEJVMSEoF02J FjNsYcdHDXeqnJ9SCAg9sS+hZGwOCsaTi1MyNuMbZ5Nz+xuT8SmNJZv6CN5q2TsbvNUyPX6nt7pb oCW6UU2OL+MRA6RlmVO3xREJsbnNJe30/TZHJMQBtHJK9/7wL8+/AeVqOWMhgJKWhVVs62tyrIrL 0zMPWmeA1iSTB0gz7TEMgfNek+P5FUy7cytgb5zMNduiBWZflvFileVR/tOI24VXCLME6K41EAJ0 l6FqgO4yPXYK3eEA5k20nD8mv7hdPqa26jT1uK/TWrlmbKp9U2WdA6jD9cQNORkOPRCdJ1oTh3TG WNiOaynV0brM0Ir1CJxIefv1Mpk4Q3zzotZ4c7/P8l94/6L5AlJuywEQbltnOQ+dbpPNQuzeeOp9 Gn+NlqUBSrGnAUURh21AUcNQQKaGkfbq7nPRAeqBkYTahv7FPUTvpn9r2fnl317ybfo3t6JDkyOJ AgGsFa3gsLmDnmJDehyueOYxrm3dgTmLVujMbP+hJVppXQUa7y37b3kyN+zX+FHYrMNmTa/HDpv1 YW/W8vGQYxT519QhZubky6W4Vfu2lTdq39bSNu3b2LpJN8/aukU3Ne/jBt1qSzFdL4r2lFBDtCFL 5uSiIVnnaDRpyNY5Oj5pyNY5Oj9vyNaBnKGGbJ3js5OGkZ5AppJ9tmFXeU27SrMNY9tXXFrbdhaX 9pa9xaW5dXdx78AQH2juoI87DLNlJH95FyagJjmkp/djomXV2Xvws5pZpKnNcmDTboVJTHXwMCYJ RfCwpR/ycrPiKrilrw4Qk4Sd+eXy5Wo4HuEsBZKDOv8R0Zg6bCP8KBjBEPRgwe9zzk6Jr1FX1ZDo JjqUsh/lWo1bc70YeKtp+6arilGGnqX4hnRVXgjiwESkFYwz1QPDMC4UAwswjh9ZC66lA4RxQnaB 7Plv9o3YXEvGo0/ixrlF35LT962xh+b5E1zXu9TR34BAcaaLGWRuuu67B1ySaw1SUaX6sig9uYNr JzTetgPDK0ZIf5ulYv7tgU27FUwzVRzCMC2UGwowLcA0Q6WF/S035JEEak4OcUI6liicU/vg7Ntz Z99mR1QCICNYHtf/oo5afRzQ4mzcOAu23z7I3wWJLdhw4xXYec0yxIa6uHQryGiqnYQhYyicFCBj gIyHDBmNnj0nxLch4LQhCqfvB8Rqii6/XHLiQvwZH0mVos/VNQf7GZ7ewDnoxDm79w6adnGjv8uC KqGvV1O1Hu/Ih105dfmC0kKwc7NBDiQ29g/NlPlkmrIj0ctsGePzJ3AlPFYYloMomHl5UMPEyvC7 X+F0BDpPLSfjBjS/PlTynLJVQ1swh2ihHJAcfA3lgGR67KockIcPMwDSeRwOInRxEAGnsHUBmjiS /h6lV8MWu+zeeoxcseZmjmOjSDdnT8AA+0W815o3+aoh65kNsp4NicUSKlgGyBoOuez1IRfqQ7Fk EuFrH7yKVxo3Pyc3VXCw2ip3NuMH5JmYptxRgf/iR27gLxxNNThIKe0N/tG+O1gZrzOlTKsOgGNN +gUI6OZZtIFkJ1bvGdDTJV5KlAMGaUtLo85oZvjDAMydEbJfxoPmDDn3820qnz0Tr1dtT5zb7Ala QCa4wLloBBe4pVxecIEfjgvctv0331Tl0tqG4lzaWxIyXJq3ziBms299WIt0EMyFhxywl+tdWZJb uLpvwdlm2D0mkfJRi9o97ugUIvAFEOQpScHzL81Qm4GJ7UuaH8zpqLMUhCSGw81HNVIjZOeWP1N0 JwoRNKj/k5LMC/Tzh/nV8Av65WNSlKaSjuhZKOlIPOuhfFIon4Qjs5IdsL8HuvD+AHHpTu5GMrqK LD43l2tNzWitam0Di06fb4UW2fd7itXUE0NNeQrynaQ1uHCOSyUgReiMumzLZl529B2qb3fuVLOi NnprbZeorSkJs99nspAg6Y4TaeHb4V99VbcCOuInRLjJod195cU6RZXVzIJPghnkrL52bzSaZg2/ +6U7IxRvKpCKEX4okIo5JCD8gPAPAeGzuv1eCSQ2uGZE2dXl8khZ9TADog1M3tQdaaN0D4ExVJw6 ky/xxKYTB8bIuUkwvWlD0yJA0Z0ZgDF34h0+MFYv0+2kglkAxgEYU+Asub5NJWcxMA4lZwMwRoG5 VQDGfQLGv+0coA3KGUEzdqVSJ2frTIQKUfUQdf+Gqq8a10/NpY2WgadjhORj02VD7GRjWwzuJAb7 62zT2iYqkhLvYNqcz/aXHK18j6ZysRhihXKxAWIFiBVqf+EEOOxag7Iw+H8kDPzKj6b11K+6FwhP SqR8NQjPmrVAHfbcOSuRSBueb7Xjm6p94h0/VPsMO37Y8V/lju8S3jJv+C6tbR4Zl/atcgURXCFo JfhzLrGjsDeFlQ7RPfEKigO1QiWmko8YlYSSjwGVBFTSO1Tye045uCCHHuOWg3EyQO7IicaRZDN3 tQ7+prMSQLBX409AzOGct98Z9LDg8EOEbHJaV1Osbb9OxqCELTkBENtDNqEjCoeeYMZnivwz2k3V EDGaC9UQA5oLaC6guRfijpCLKVs2EJaqbLtO2gwGq9Y2N5TT5y37n8v3X6cfyj+bf9tAruKI3ed0 WANDHR0/FLP2NSlYzuRud96ceWF3T+vdgOaezVtXhxDDlsO+dkfG+lRKpENF0brMvM7a737hJeWi HuHwtQi0Vrl8hKPfRhIKvIO62raRZCrxiI2kUOIxGEnBSApGktZIMlsZVbS7xy5vqHbzKku++5tI cl0gZwRvs4BdeGvPIE29XIv//q2FNFu3l/pB6mAuidxBb/+g7nGAiKR+YzCXoP70oZpLYgClI93S c3NJCuQiY2nL5tJDnj3FRZFky4jcibuMFqh4Ks5nw5VSB9IrxFMRrttiJEJgkFsT4YZYuRx8KI8v 06PPN8S6QKoDsIzumWDLwTOX2b9O02ovzjz13XVct7PQtr/ljf8xWazS2FQCnTwNRdBpUV6Dtyzs 9/L+FvZ7mR593u+d8jVs7i6HDpADJBRy0d0I0xDms9HdDFX2KS3Dy/cl+gsbKGNMoeg3WYBcfrmi ZAM31T+m23uogBxCodx5cXI6pqfBTBWhw/bej+29B3cw+wfkQAOGwydN5co0yYe1ulz+lvIrun8j nOPhl7l747PbjMQPNCzoLLqb+Q93Hzv3ItoyRnoaX0bcFc2W2ZJcdfcLqkmhjb1YRbOY/jfOtbwa MgUAptfOD1R50UstPzhtlTZb6bNDIReQsY1xYKoBTY2DUAU6GAfBODB4fvf3AsTfVgXavFlbPH84 rEHUdlaW2UIfbXPqwHJWzKE92nqC61HnetSAkZoNgTJ17u76fFRjF/G29bS0xNvw0xBvC/G2Kpso OORq7rbRGbvjy7Qrn4xoYW2TC/Pi4gg7OZH6j6YFyjlFNlKy/Ao7UfRUxvnVcHLMy9rN4Ve0z10N j4/wt6Hd6iGnqar8P3DO6kaXDvffZdd9XKZDrNAzU7eLeJcDBtoHFwDI3zOSMpxvWq+pggKWcFkF PH5K0vRqKAGPluV5Gvh0M1S5DxRFqs25cpGYXd9AmQ3xfs9EUD6u3ECaduH4Sr/tnjYNYogzBzYV w44cnrsnlpeEdeW23FtnLVDD0/uIbR1jagKxhEJqQvA+Bu+jyc7ZW0vIw/toxhPmVK1qy7TgtObm SIH30PnXkDSxAUjpibHgtfG+IiPKiy5SkkMDz1ikrCcsYwW29JLuTYHtazKirPRE9+z4HVvBihi7 zx5yWAZy5DsYCsSz2C6/4XAMhS/P8SLGCTLqoWTyjEQSw2lkEB31puJwOkmOH4T0ZZkefT6ddIxs Q2t2m9m8aG5r8+c1t7aApubG1hK2rs3/yfSBfIi5qXkfzSIYs5/36V/x1HToFR6FCHyIwJfB79Q7 vxOKnz/yQP4LBPFx2JDYE/MfEeXqaerhoBKOEmbrsogxXxSQWm1yMFWp1eLm49tW3nx8W0ubj2/j 2ubTrjnffPya93HzAYOVZsuBH8WFBdEkWYvfVzgDZ/4zSMCYFIbCRjJNH3ISbaBjKmf8HAgM+HAM StjgTWEntPeHmFOIOYW9P+z9kBQo7P2wKbbd+j2byju/Z2Np4/dsC68n85iXvmrVmm/7Xq3Drj/c 1qXBYde/GuIClrC1m466oV0/nHMLu37Y9cOuL+/6svE6aXKdyjeneTeWd37v5tLe7926tvvL7Zt9 HaQ53/79mof9P+z/vCQBYobK84D/QoFwwiM0ScB2beoqyqOvebR6xsGh8mcaf5gDBkjg3J0aRca/ 6uLHn7J8AbWw8aP/u0N/lPi/c8DIzIkCWQ434/PjE/IWPRFUHSSaxk9ZDnUX0EkiaELPFZ3SY0X/ nrFuZvESThyRTkBu0mQZf/yesqf4dZg87Z56a/K7bFkWqNdiliRXw+s8gdHC38/XgOKFv2cF+4PM kvz/2wL/+y3Ol+w7E3ojUvGL/ULOOkFk5dct+hIOLfPzT3gcMCxD2EVahNm6gEO+eOmuhmNpWT7f 3d4lX9e5ujTwZEAfkTHL8X1xfRrX5Fscrz7FP8gKoj8+Ao0JCarlousj0buTCaL7pm7WaQr2Izoy JmYxoEni66joc7+Znt2dnZ/Tal2UPeTJLdcLkkMC//GBs+0YXxAMU6OPGXN1Mtnr1epexdlonvBk AI90U4TH9+M3UIhjvSDPl7BYjOXMK309Gl2M8AlkLh58xklaiRD9qEQEiAzASCoivFyqoofbdU6d Yy0XYOrQY4tTmdW3TB36UW/q4HadU+fETB2qZ38vdehHvamD23VKnZssSeN8lUalXlmKz3VCJsqR Sb6KeJHcJ/N5vMQ9yIr1+ng8OR5TsXHR+/gdtPneRGmaZcsvINXK8tJnA/ywadywN35jekHo9PY5 ovunPOLT86O7G1lBaPQ9dIj2XL5Roz8+r1P4QYiS2LffL9FztoiE/bf6AW3A9C88u2p/ZYUWxf2V /AZ807C/zmDG0QzBBhi9ZX+tE6m+AYnUH1RkrMnYu/gpWqflA0NWCHwQRW1YEPLQvBgGFFNRLY6K 8rpIIsQ7ZbT8uoekvf/yx8eHHGE8wIZlPMfUq9MXvTQQ39qUyPWvEkqvk4c8yfKk/Mmk4+KCPLFL 9M3J9QSjAR4GrAPL22ydJ3E++BS/oDWwrEvtTcT34k/A/J5szdXHbbZYAEb+HD/FebycqeovWi6z Mirh+poBLAh9SadLzIws8+rk7ngyfke5mECobuRWwsX1CWr1ozC3EulP3bRE1S5KJCUc6reSbfNM qY6rVKSvWqxoROCVbDtwyNWRbqvPri579DneWTYVO+FblCskO1DDL7sVJCufPa6n/45n6lYssFpB X9Fxm0ILEU0oDzX8SL/vwpJ0o5iScWCz1VOLWDZHOlZxOCYeou+Y2UiYdzUv89z3gIleLu1UBTpj BVX85f8FAAAA//8DAFBLAwQUAAYACAAAACEAJwteeKIDAAA3JQAAEAAIAWRvY1Byb3BzL2FwcC54 bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUWl1vmzAUfZ+0/4B4b/lKIKkc qilV10rbWi20fZw8cBJUgpHtps1+/a4xTUjTTbgSUpyn649cLuceji/JRecvq8JaE8ZzWk5s79S1 LVKmNMvLxcS+Sy5PRrbFBS4zXNCSTOwN4fZ5/PkTumW0IkzkhFvgouQTeylEdeY4PF2SFeansFzC ypyyFRYwZAuHzud5Si5o+rQipXB81w0d8iJImZHspNo6tJXHs7X4qNOMpjI+fp9sKgg4RglZVQUW JP55ObVEM0DOdholVOAiyVckDjyY347QLV4QHns+cpSFHijLeBy44zFylI2mS8xwKgDF2IvCcISc 1gz6UlVFnmIBCMff85RRTufCuqmxsKQH5LS3IMBnRtInlotN7CKnPUTf8lJGM4iQo0yIj+EFw9WS xwOIvDVEsxQXZAo4xHNccIKc3QS6Iljm+BbnEDRai7M1SQVlFs//QJZ92/qNOZHoTew1ZjkuBaAo t6lBbRcVFyxOclGAb1hT49psb2vb+SCGIGEvGPsb5aSKARb2o6uvwG/mcG/inWC9drB1DCpUFc4P Ip4pe5RAP8INW18ZfaoOwq1vHi785lJTuqpwuYnvZlPnenYNeW0mZCIe+V2V0AvJqgbf/ckWLR5y sZxVOIXc+W7kh22CtNbQDIhEMsj4q8fdBLqqvR/myhvBM9shWxL6KBwPg8H7CXiTXNjuR8OuW4Gn 7yX10Gc3j0X1LKnVpGlnt6nUtpv9vxKa+sNR4PvhCJ5OuHrbUfsLbfsDwITK+wGJD+/3+IABdeoR mKArEY4PGNDU/oAZKu9GMgbkqkdg/nEemPAoKTHrSWMG3aQSGHV8j5I6YnoCJjBYfJU89gWMweIL 9XV/GuMbLL5KHntijG+w+CrV6wpM4LnRSJGswxnse+aKb6RX+WoC45orvpFe5asLjLniG+lVvnrA eGNzxTfSq3x1gTFXfJsfBvoRX29ksPjqVb6ajGmkvcMBdnSvBJFe5asLjMHiq1f5agITGiy+epWv LjAGi69m5RuFgadKnw7C4Q3NFd/mV9nOp5IeMANzK1/5j5TG23WgCYy54tvIY0+MCcwV31Cz8tVj jPyLFfjYQY6Oro4JlTz2xBjfYPHVrHz1GOMZLL6ala8mMAaLr2blqweMa7D4ala+msAYLL7/qXzl gbLrH2l6Ja6ggYUVslUDGnLKBcle+yoOF2Sbzr3qg4L+mlMXPnVfzusctNZsG5TivwAAAP//AwBQ SwECLQAUAAYACAAAACEA3AUhqOUBAACfCQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAAAB4EAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQDIyle1lwEAANkHAAAcAAAAAAAAAAAAAAAAAEIHAAB3b3Jk L19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAF+5OjAnSQAAh9ABABEAAAAA AAAAAAAAAAAAGwoAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhAOX2XRSWBAAAozYA ABAAAAAAAAAAAAAAAAAAcVMAAHdvcmQvaGVhZGVyMi54bWxQSwECLQAUAAYACAAAACEAmHNQo5AE AABFNgAAEAAAAAAAAAAAAAAAAAA1WAAAd29yZC9mb290ZXIxLnhtbFBLAQItABQABgAIAAAAIQD8 lfFomwIAALsHAAAQAAAAAAAAAAAAAAAAAPNcAAB3b3JkL2hlYWRlcjEueG1sUEsBAi0AFAAGAAgA AAAhAHJDaODBAQAAlAUAABEAAAAAAAAAAAAAAAAAvF8AAHdvcmQvZW5kbm90ZXMueG1sUEsBAi0A FAAGAAgAAAAhAF6kzLrBAQAAmgUAABIAAAAAAAAAAAAAAAAArGEAAHdvcmQvZm9vdG5vdGVzLnht bFBLAQItABQABgAIAAAAIQBOq9vrZgQAAKw2AAAQAAAAAAAAAAAAAAAAAJ1jAAB3b3JkL2Zvb3Rl cjIueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAAAAAAAAAAAAAAAMWgAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBzD2suVg4AAEw6AAARAAAAAAAAAAAAAAAA APpuAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCy2LdL4gAAAFgBAAAcAAAAAAAA AAAAAAAAAH99AAB3b3JkL19yZWxzL3NldHRpbmdzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAOtu LGWjLQAAd4YCAA8AAAAAAAAAAAAAAAAAm34AAHdvcmQvc3R5bGVzLnhtbFBLAQItABQABgAIAAAA IQDNnjZDlBUAAI3iAAASAAAAAAAAAAAAAAAAAGusAAB3b3JkL251bWJlcmluZy54bWxQSwECLQAU AAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAAAAAAAAAAAAAvwgAAY3VzdG9tWG1sL19yZWxzL2l0 ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALa905riAAAAVQEAABgAAAAAAAAAAAAAAAAANcQA AGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBLAQItABQABgAIAAAAIQCpyFyqjAAAANoAAAATAAAA AAAAAAAAAAAAAHXFAABjdXN0b21YbWwvaXRlbTEueG1sUEsBAi0AFAAGAAgAAAAhAD/H1duHAQAA 2wIAABEAAAAAAAAAAAAAAAAAWsYAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAGGR dRnBAgAA9woAABIAAAAAAAAAAAAAAAAAGMkAAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAI AAAAIQBxoNvcJAIAAEIUAAAUAAAAAAAAAAAAAAAAAAnMAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBL AQItABQABgAIAAAAIQBUyt8TLS4AAGiJAgAaAAAAAAAAAAAAAAAAAF/OAAB3b3JkL3N0eWxlc1dp dGhFZmZlY3RzLnhtbFBLAQItABQABgAIAAAAIQAnC154ogMAADclAAAQAAAAAAAAAAAAAAAAAMT8 AABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAAXABcA3QUAAJwBAQAAAA== --_006_F15941D3C8A2D54D92B341C20CACDF2311AC408AB1exchange_-- From robmcm@microsoft.com Wed Jun 8 12:11:25 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006EC11E8104 for ; Wed, 8 Jun 2011 12:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoKe+fJktLrB for ; Wed, 8 Jun 2011 12:11:23 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id B75E311E8124 for ; Wed, 8 Jun 2011 12:11:23 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 8 Jun 2011 12:11:23 -0700 Received: from DB3EHSOBE006.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 8 Jun 2011 12:11:23 -0700 Received: from mail10-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.22; Wed, 8 Jun 2011 19:11:12 +0000 Received: from mail10-db3 (localhost.localdomain [127.0.0.1]) by mail10-db3-R.bigfish.com (Postfix) with ESMTP id D02F74C0204 for ; Wed, 8 Jun 2011 19:11:12 +0000 (UTC) X-SpamScore: -35 X-BigFish: PS-35(zz9371M111aL4015L103eMzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT006.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail10-db3: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT006.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail10-db3 (localhost.localdomain [127.0.0.1]) by mail10-db3 (MessageSwitch) id 1307560272664149_29719; Wed, 8 Jun 2011 19:11:12 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.244]) by mail10-db3.bigfish.com (Postfix) with ESMTP id 93AE8160004F; Wed, 8 Jun 2011 19:11:12 +0000 (UTC) Received: from CH1PRD0302HT006.namprd03.prod.outlook.com (157.55.61.146) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 8 Jun 2011 19:11:11 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.42]) by CH1PRD0302HT006.namprd03.prod.outlook.com ([10.28.29.125]) with mapi id 14.01.0225.052; Wed, 8 Jun 2011 19:11:10 +0000 From: Robert McMurray To: Robert Oslin , "ftpext@ietf.org" Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: AQHMJfeJg/z1R+i7P06/FZc6+arpxJSzzQBQ Date: Wed, 8 Jun 2011 19:11:07 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT006.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GLOBALSCAPE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 19:11:25 -0000 Thanks, Robert. I like the idea behind the COMB command; I could see where this could be qu= ite useful for transferring large files. One consideration that I have in your draft is verbiage that "The server-FT= P process SHOULD delete each of the parts identified by the COMB command on= ce the target file is created." I would think that the cleanup behavior for= partial files would be left to the client, since the remaining parts of th= e draft place the responsibility on the client for splitting the file and k= eeping track of the parts. For example: C> STOR foo.txt S> 226 Transfer complete. C> STOR bar.txt S> 226 Transfer complete. C> COMB foobar.txt foo.txt bar.txt S> 250 COMB command successful. C> DELE foo.txt S> 250 DELE command successful. C> DELE bar.txt S> 250 DELE command successful. As you mentioned in your draft, it would be advantageous if COMB was used w= ith the HASH command to verify data integrity before the client takes care = of the deletion tasks. For example: C> OPTS HASH MD5 S> 200 MD5 C> STOR foo.txt S> 226 Transfer complete. C> STOR bar.txt S> 226 Transfer complete. C> COMB foobar.txt foo.txt bar.txt S> 250 COMB command successful. C> HASH foobar.txt S> 213 MD5 426f62526f636b73 foobar.txt C> DELE foo.txt S> 250 DELE command successful. C> DELE bar.txt S> 250 DELE command successful. Thanks again. Robert McMurray robmcm@microsoft.com ------------------------------ From: Robert Oslin [mailto:rto@globalscape.com]=20 Sent: Wednesday, June 08, 2011 9:15 AM To: ftpext@ietf.org Subject: [ftpext] COMB command IETF draft proposal "Any submission to the IETF intended by the Contributor for publication as = all or part of an IETF Internet-Draft or RFC and any statement made within = the context of an IETF activity is considered an "IETF Contribution". It only took me 10+ years, but here's my contribution the FTP ext community= (attached). Essentially an early draft to ratify the commonly used COMB command for sup= port of multi-part (a.k.a accelerated) uploads. I welcome comments/question= s from the community. Ideally redlining the document (or via comments in th= e doc). I will resubmit using formal IETF draft (in ASCII) once I've addres= sed all comments/questions in the MS Word version (hope that's ok and doesn= 't break and IETF rules).=20 Thanks, Robert Oslin Director of Product Management Tel: 1 (210) 293-7902 Fax: 1 (210) 690-8824 Send me large files securely www.globalscape.com (NYSE Amex:GSB) *This communication, including attachments, is for the = exclusive use of the addressee and may contain proprietary, confidential or= privileged information. If you are not the intended recipient, any use, co= pying, disclosure, dissemination or distribution is strictly prohibited. If= you are not the intended recipient, please notify the sender immediately b= y return email and delete this communication and destroy all copies. From rto@globalscape.com Wed Jun 8 12:59:30 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430E21F84D8 for ; Wed, 8 Jun 2011 12:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qervQjznD1hb for ; Wed, 8 Jun 2011 12:59:29 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id B481421F84D7 for ; Wed, 8 Jun 2011 12:59:29 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Wed, 8 Jun 2011 14:59:29 -0500 From: Robert Oslin To: Robert McMurray Date: Wed, 8 Jun 2011 14:59:27 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: AQHMJfeJg/z1R+i7P06/FZc6+arpxJSzzQBQgAARSZA= Message-ID: References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ftpext@ietf.org" Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 19:59:30 -0000 Thanks for the feedback! Issuing a hash (or XCRC until HASH is formally rat= ified) makes a lot of sense and will be inserted as a strongly recommended = practice (i.e. SHOULD). As for the delete operation, I would be careful to = make it mandatory of the client, rather leaving it open to interpretation, = as there are many ways for the server to execute the combine operation, whi= ch may or may not result in the original parts being available for deletion= . For example a rudimentary concatenate operation by the server on ascii ty= pe files (which would be quite slow) would result in each part being remove= d by nature of the concatenation operation, hence a subsequent delete opera= tion would result in 5xx errors returned to the client on each DELE request= . Perhaps it would be wise to recommend that the client check for parts pos= t operation and do cleanup if any parts remain? In our particular implement= ation (and in the handful of servers that support COMB so far), it is the s= erver that does the cleanup as a function of the combine operation. Let me = know if that makes sense, or if not, then how to deal with the myriad ways = in which servers may go about combining files and how to deal with corner c= ases. Robert Oslin -----Original Message----- From: Robert McMurray [mailto:robmcm@microsoft.com]=20 Sent: Wednesday, June 08, 2011 2:11 PM To: Robert Oslin; ftpext@ietf.org Subject: RE: [ftpext] COMB command IETF draft proposal Thanks, Robert. I like the idea behind the COMB command; I could see where this could be qu= ite useful for transferring large files. One consideration that I have in your draft is verbiage that "The server-FT= P process SHOULD delete each of the parts identified by the COMB command on= ce the target file is created." I would think that the cleanup behavior for= partial files would be left to the client, since the remaining parts of th= e draft place the responsibility on the client for splitting the file and k= eeping track of the parts. For example: C> STOR foo.txt S> 226 Transfer complete. C> STOR bar.txt S> 226 Transfer complete. C> COMB foobar.txt foo.txt bar.txt S> 250 COMB command successful. C> DELE foo.txt S> 250 DELE command successful. C> DELE bar.txt S> 250 DELE command successful. As you mentioned in your draft, it would be advantageous if COMB was used w= ith the HASH command to verify data integrity before the client takes care = of the deletion tasks. For example: C> OPTS HASH MD5 S> 200 MD5 C> STOR foo.txt S> 226 Transfer complete. C> STOR bar.txt S> 226 Transfer complete. C> COMB foobar.txt foo.txt bar.txt S> 250 COMB command successful. C> HASH foobar.txt S> 213 MD5 426f62526f636b73 foobar.txt C> DELE foo.txt S> 250 DELE command successful. C> DELE bar.txt S> 250 DELE command successful. Thanks again. Robert McMurray robmcm@microsoft.com ------------------------------ From: Robert Oslin [mailto:rto@globalscape.com]=20 Sent: Wednesday, June 08, 2011 9:15 AM To: ftpext@ietf.org Subject: [ftpext] COMB command IETF draft proposal "Any submission to the IETF intended by the Contributor for publication as = all or part of an IETF Internet-Draft or RFC and any statement made within = the context of an IETF activity is considered an "IETF Contribution". It only took me 10+ years, but here's my contribution the FTP ext community= (attached). Essentially an early draft to ratify the commonly used COMB command for sup= port of multi-part (a.k.a accelerated) uploads. I welcome comments/question= s from the community. Ideally redlining the document (or via comments in th= e doc). I will resubmit using formal IETF draft (in ASCII) once I've addres= sed all comments/questions in the MS Word version (hope that's ok and doesn= 't break and IETF rules).=20 Thanks, Robert Oslin Director of Product Management Tel: 1 (210) 293-7902 Fax: 1 (210) 690-8824 Send me large files securely www.globalscape.com (NYSE Amex:GSB) *This communication, including attachments, is for the = exclusive use of the addressee and may contain proprietary, confidential or= privileged information. If you are not the intended recipient, any use, co= pying, disclosure, dissemination or distribution is strictly prohibited. If= you are not the intended recipient, please notify the sender immediately b= y return email and delete this communication and destroy all copies. From vglass@jscape.com Wed Jun 8 13:15:31 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6D521F85C6 for ; Wed, 8 Jun 2011 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Nb+W2XLaWJ6 for ; Wed, 8 Jun 2011 13:15:30 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4321F85C5 for ; Wed, 8 Jun 2011 13:15:30 -0700 (PDT) Received: by yxm34 with SMTP id 34so568779yxm.31 for ; Wed, 08 Jun 2011 13:15:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.195.65 with SMTP id o41mr2558493yhn.337.1307564129192; Wed, 08 Jun 2011 13:15:29 -0700 (PDT) Received: by 10.236.153.7 with HTTP; Wed, 8 Jun 2011 13:15:29 -0700 (PDT) In-Reply-To: References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> Date: Wed, 8 Jun 2011 14:15:29 -0600 Message-ID: From: Van Glass To: Robert Oslin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" , Robert McMurray Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:15:31 -0000 I think that having the server perform the delete tasks is preferred for the simple reason that this would reduce the number of commands going across the command channel. We have not yet implemented COMB but would like to pursue it. With that said I'm curious to know your experience COMBing a large number of files or very large files. Have you experienced any issues where the COMBine process on the server side takes a long amount of time, possibly resulting in a command channel timeout on the client side? Thanks, Van Glass JSCAPE Managed File Transfer and Network Solutions http://www.jscape.com On Wed, Jun 8, 2011 at 1:59 PM, Robert Oslin wrote: > Thanks for the feedback! Issuing a hash (or XCRC until HASH is formally r= atified) makes a lot of sense and will be inserted as a strongly recommende= d practice (i.e. SHOULD). As for the delete operation, I would be careful t= o make it mandatory of the client, rather leaving it open to interpretation= , as there are many ways for the server to execute the combine operation, w= hich may or may not result in the original parts being available for deleti= on. For example a rudimentary concatenate operation by the server on ascii = type files (which would be quite slow) would result in each part being remo= ved by nature of the concatenation operation, hence a subsequent delete ope= ration would result in 5xx errors returned to the client on each DELE reque= st. Perhaps it would be wise to recommend that the client check for parts p= ost operation and do cleanup if any parts remain? In our particular impleme= ntation (and in the handful of servers that support COMB so far), it is the= server that does > =A0the cleanup as a function of the combine operation. Let me know if tha= t makes sense, or if not, then how to deal with the myriad ways in which se= rvers may go about combining files and how to deal with corner cases. > > Robert Oslin > > -----Original Message----- > From: Robert McMurray [mailto:robmcm@microsoft.com] > Sent: Wednesday, June 08, 2011 2:11 PM > To: Robert Oslin; ftpext@ietf.org > Subject: RE: [ftpext] COMB command IETF draft proposal > > Thanks, Robert. > > I like the idea behind the COMB command; I could see where this could be = quite useful for transferring large files. > > One consideration that I have in your draft is verbiage that "The server-= FTP process SHOULD delete each of the parts identified by the COMB command = once the target file is created." I would think that the cleanup behavior f= or partial files would be left to the client, since the remaining parts of = the draft place the responsibility on the client for splitting the file and= keeping track of the parts. For example: > > =A0 =A0 =A0C> STOR foo.txt > =A0 =A0 =A0S> 226 Transfer complete. > =A0 =A0 =A0C> STOR bar.txt > =A0 =A0 =A0S> 226 Transfer complete. > =A0 =A0 =A0C> COMB foobar.txt foo.txt bar.txt > =A0 =A0 =A0S> 250 COMB command successful. > =A0 =A0 =A0C> DELE foo.txt > =A0 =A0 =A0S> 250 DELE command successful. > =A0 =A0 =A0C> DELE bar.txt > =A0 =A0 =A0S> 250 DELE command successful. > > As you mentioned in your draft, it would be advantageous if COMB was used= with the HASH command to verify data integrity before the client takes car= e of the deletion tasks. For example: > > =A0 =A0 =A0C> OPTS HASH MD5 > =A0 =A0 =A0S> 200 MD5 > =A0 =A0 =A0C> STOR foo.txt > =A0 =A0 =A0S> 226 Transfer complete. > =A0 =A0 =A0C> STOR bar.txt > =A0 =A0 =A0S> 226 Transfer complete. > =A0 =A0 =A0C> COMB foobar.txt foo.txt bar.txt > =A0 =A0 =A0S> 250 COMB command successful. > =A0 =A0 =A0C> HASH foobar.txt > =A0 =A0 =A0S> 213 MD5 426f62526f636b73 foobar.txt > =A0 =A0 =A0C> DELE foo.txt > =A0 =A0 =A0S> 250 DELE command successful. > =A0 =A0 =A0C> DELE bar.txt > =A0 =A0 =A0S> 250 DELE command successful. > > Thanks again. > > Robert McMurray > robmcm@microsoft.com > > ------------------------------ > From: Robert Oslin [mailto:rto@globalscape.com] > Sent: Wednesday, June 08, 2011 9:15 AM > To: ftpext@ietf.org > Subject: [ftpext] COMB command IETF draft proposal > > "Any submission to the IETF intended by the Contributor for publication a= s all or part of an IETF Internet-Draft or RFC and any statement made withi= n the context of an IETF activity is considered an "IETF Contribution". > > It only took me 10+ years, but here's my contribution the FTP ext communi= ty (attached). > > Essentially an early draft to ratify the commonly used COMB command for s= upport of multi-part (a.k.a accelerated) uploads. I welcome comments/questi= ons from the community. Ideally redlining the document (or via comments in = the doc). I will resubmit using formal IETF draft (in ASCII) once I've addr= essed all comments/questions in the MS Word version (hope that's ok and doe= sn't break and IETF rules). > > Thanks, > > Robert Oslin > Director of Product Management > Tel: 1 (210) 293-7902 > Fax: 1 (210) 690-8824 > Send me large files securely > > www.globalscape.com > =A0 =A0(NYSE Amex:GSB) *This communication, including attachments, is for= the exclusive use of the addressee and may contain proprietary, confidenti= al or privileged information. If you are not the intended recipient, any us= e, copying, disclosure, dissemination or distribution is strictly prohibite= d. If you are not the intended recipient, please notify the sender immediat= ely by return email and delete this communication and destroy all copies. > > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext > From rto@globalscape.com Wed Jun 8 13:57:33 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719B621F84D4 for ; Wed, 8 Jun 2011 13:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtoiU2J7tF9W for ; Wed, 8 Jun 2011 13:57:32 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id A35A321F84C9 for ; Wed, 8 Jun 2011 13:57:27 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Wed, 8 Jun 2011 15:57:27 -0500 From: Robert Oslin To: Van Glass Date: Wed, 8 Jun 2011 15:57:24 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: AcwmGNDsY6HzakJdRC6ynlWWpBRxywAA/e/w Message-ID: References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ftpext@ietf.org" , Robert McMurray Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:57:33 -0000 "Have you experienced any issues" - yes, with larger (multi-GB) size files; however there are ways to combine= the file so that timeouts can be avoided in most cases. I made a couple of= fleeting references to those methods in the spec, but really it would be u= p to the server vendor to research and implement the optimal recombine tech= nique so that timeouts could all but be eliminated for everything but excee= dingly large files... and even that could be avoided by the client implemen= ting logic that extends or temporarily ignores timeouts when waiting for th= e result of a COMB operation, perhaps extending the timeout proportional to= the file size that was uploaded (same could apply for HASH operations on v= ery large files). I can update the draft to make note of such cases and rec= ommended workarounds; however I wouldn't make any mandatory requirements ou= t of those. BTW, one possibility is for the server to return 200 OK once th= e operation is approved but not yet consummated, i.e. making it more of an = asynchronous command, but that may lead to even more problems down the road= (like if client decides to do something with the resulting file even thoug= h it has not yet been fully created/recombined). Robert=20 -----Original Message----- From: Van Glass [mailto:vglass@jscape.com]=20 Sent: Wednesday, June 08, 2011 3:15 PM To: Robert Oslin Cc: Robert McMurray; ftpext@ietf.org Subject: Re: [ftpext] COMB command IETF draft proposal I think that having the server perform the delete tasks is preferred for th= e simple reason that this would reduce the number of commands going across = the command channel. We have not yet implemented COMB but would like to pu= rsue it. With that said I'm curious to know your experience COMBing a larg= e number of files or very large files. Have you experienced any issues whe= re the COMBine process on the server side takes a long amount of time, poss= ibly resulting in a command channel timeout on the client side? Thanks, Van Glass JSCAPE Managed File Transfer and Network Solutions http://www.jscape.com On Wed, Jun 8, 2011 at 1:59 PM, Robert Oslin wrote: > Thanks for the feedback! Issuing a hash (or XCRC until HASH is=20 > formally ratified) makes a lot of sense and will be inserted as a=20 > strongly recommended practice (i.e. SHOULD). As for the delete=20 > operation, I would be careful to make it mandatory of the client,=20 > rather leaving it open to interpretation, as there are many ways for=20 > the server to execute the combine operation, which may or may not=20 > result in the original parts being available for deletion. For example=20 > a rudimentary concatenate operation by the server on ascii type files=20 > (which would be quite slow) would result in each part being removed by=20 > nature of the concatenation operation, hence a subsequent delete=20 > operation would result in 5xx errors returned to the client on each=20 > DELE request. Perhaps it would be wise to recommend that the client=20 > check for parts post operation and do cleanup if any parts remain? In=20 > our particular implementation (and in the handful of servers that=20 > support COMB so far), it is the server that does > =A0the cleanup as a function of the combine operation. Let me know if tha= t makes sense, or if not, then how to deal with the myriad ways in which se= rvers may go about combining files and how to deal with corner cases. > > Robert Oslin > > -----Original Message----- > From: Robert McMurray [mailto:robmcm@microsoft.com] > Sent: Wednesday, June 08, 2011 2:11 PM > To: Robert Oslin; ftpext@ietf.org > Subject: RE: [ftpext] COMB command IETF draft proposal > > Thanks, Robert. > > I like the idea behind the COMB command; I could see where this could be = quite useful for transferring large files. > > One consideration that I have in your draft is verbiage that "The server-= FTP process SHOULD delete each of the parts identified by the COMB command = once the target file is created." I would think that the cleanup behavior f= or partial files would be left to the client, since the remaining parts of = the draft place the responsibility on the client for splitting the file and= keeping track of the parts. For example: > > =A0 =A0 =A0C> STOR foo.txt > =A0 =A0 =A0S> 226 Transfer complete. > =A0 =A0 =A0C> STOR bar.txt > =A0 =A0 =A0S> 226 Transfer complete. > =A0 =A0 =A0C> COMB foobar.txt foo.txt bar.txt > =A0 =A0 =A0S> 250 COMB command successful. > =A0 =A0 =A0C> DELE foo.txt > =A0 =A0 =A0S> 250 DELE command successful. > =A0 =A0 =A0C> DELE bar.txt > =A0 =A0 =A0S> 250 DELE command successful. > > As you mentioned in your draft, it would be advantageous if COMB was used= with the HASH command to verify data integrity before the client takes car= e of the deletion tasks. For example: > > =A0 =A0 =A0C> OPTS HASH MD5 > =A0 =A0 =A0S> 200 MD5 > =A0 =A0 =A0C> STOR foo.txt > =A0 =A0 =A0S> 226 Transfer complete. > =A0 =A0 =A0C> STOR bar.txt > =A0 =A0 =A0S> 226 Transfer complete. > =A0 =A0 =A0C> COMB foobar.txt foo.txt bar.txt > =A0 =A0 =A0S> 250 COMB command successful. > =A0 =A0 =A0C> HASH foobar.txt > =A0 =A0 =A0S> 213 MD5 426f62526f636b73 foobar.txt > =A0 =A0 =A0C> DELE foo.txt > =A0 =A0 =A0S> 250 DELE command successful. > =A0 =A0 =A0C> DELE bar.txt > =A0 =A0 =A0S> 250 DELE command successful. > > Thanks again. > > Robert McMurray > robmcm@microsoft.com > > ------------------------------ > From: Robert Oslin [mailto:rto@globalscape.com] > Sent: Wednesday, June 08, 2011 9:15 AM > To: ftpext@ietf.org > Subject: [ftpext] COMB command IETF draft proposal > > "Any submission to the IETF intended by the Contributor for publication a= s all or part of an IETF Internet-Draft or RFC and any statement made withi= n the context of an IETF activity is considered an "IETF Contribution". > > It only took me 10+ years, but here's my contribution the FTP ext communi= ty (attached). > > Essentially an early draft to ratify the commonly used COMB command for s= upport of multi-part (a.k.a accelerated) uploads. I welcome comments/questi= ons from the community. Ideally redlining the document (or via comments in = the doc). I will resubmit using formal IETF draft (in ASCII) once I've addr= essed all comments/questions in the MS Word version (hope that's ok and doe= sn't break and IETF rules). > > Thanks, > > Robert Oslin > Director of Product Management > Tel: 1 (210) 293-7902 > Fax: 1 (210) 690-8824 > Send me large files securely > > www.globalscape.com > =A0 =A0(NYSE Amex:GSB) *This communication, including attachments, is for= the exclusive use of the addressee and may contain proprietary, confidenti= al or privileged information. If you are not the intended recipient, any us= e, copying, disclosure, dissemination or distribution is strictly prohibite= d. If you are not the intended recipient, please notify the sender immediat= ely by return email and delete this communication and destroy all copies. > > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext > From lothar@kimmeringer.de Thu Jun 9 00:34:23 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3E1F0C45 for ; Thu, 9 Jun 2011 00:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8bdvajAOTeQ for ; Thu, 9 Jun 2011 00:34:22 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0961F0C3B for ; Thu, 9 Jun 2011 00:34:22 -0700 (PDT) Received: from [192.168.1.20] (mnch-5d85c581.pool.mediaWays.net [93.133.197.129]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LbCMI-1PpREr3IMc-00kwmu; Thu, 09 Jun 2011 09:34:16 +0200 Message-ID: <4DF07777.2010205@kimmeringer.de> Date: Thu, 09 Jun 2011 09:34:15 +0200 From: Lothar Kimmeringer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Robert Oslin References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:Em3sUFthHDquDxaWoQZUsZGnC+VEcg9c5Wdb2KLET/d 8Z2zPQnogzClTaJrNddk2+Kq0Ej+UgMypLf6U7EWr1XeoMYT48 uJjL70RnCsZsuQHbgkxylIvsO+QjqzoWqQlxylBNQwPQXQRWwG ANm0sde4T7XlsY6TBwS80Sf854Hem6klHPFrAZiG2S09xzQzr/ QAnmUzgHXI5k+Z71XAT5g== Cc: "ftpext@ietf.org" , Robert McMurray Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 07:34:23 -0000 Am 08.06.2011 22:57, schrieb Robert Oslin: > "Have you experienced any issues" > > - yes, with larger (multi-GB) size files; however there are ways to combine the > file so that timeouts can be avoided in most cases. I made a couple of fleeting > references to those methods in the spec, but really it would be up to the server > vendor to research and implement the optimal recombine technique so that timeouts > could all but be eliminated for everything but exceedingly large files... I have to find a way to open docx files so I might repeat something that is already supposed but a simple way would be to respond with the equivalent of a HTTP-100-response: C: COMB filea fileb filec S: 250-Start COMB 250-COMB for filea finished 250-COMB for fileb finished 250-COMB for filec finished 250 COMB command successful Since a client should in general start over with a timeout every time a line of the response has been received, it should help avoid timeouts with very large files. In addition to that you receive some feedback, that the server is still talking with you. Regards, Lothar -- Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! From evnikita2@gmail.com Thu Jun 9 03:13:37 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6DF11E80B1; Thu, 9 Jun 2011 03:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBgBkeflgXQg; Thu, 9 Jun 2011 03:13:36 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEC611E809F; Thu, 9 Jun 2011 03:13:35 -0700 (PDT) Received: by fxm15 with SMTP id 15so1002162fxm.31 for ; Thu, 09 Jun 2011 03:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=XqimNoyA0obDJ+v9Q2puv9SZtJNJmOIkET4bGzDamgs=; b=QRKlBI2YJ8aVijtcT/msLdKcMV0TXs4BPuwmxesdyaAd6E9PDU+yjbsmgHhIqq6OO2 qMTqpW9qfHjuTd6d2feoUpvP37/KQYBWFx1Ky7GrBV3l8bVEhxquSgjzseiDzMhkaIbq dn0tQ6ICFLfYHqdBc/lwiyEUj9E3nkAMg79OQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=dw4mWqTSf3Ajjxh/E5qJCuja9byC32/EoQ1Gp2SHrTiI/yEtIBWzGVs/HojswzJUGy rxbZIPEDuvY7FSyk3lZqN0PLrUed2R1eZwohhKn0Eazlus45zE2vyr4lNMTCrYQLZgse oR/gccMl2XXCv5ibKwd2TW0XVEjG/V/30rrso= Received: by 10.223.55.27 with SMTP id s27mr574463fag.121.1307614402182; Thu, 09 Jun 2011 03:13:22 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id y7sm585357fak.7.2011.06.09.03.13.20 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 03:13:21 -0700 (PDT) Message-ID: <4DF09CED.50904@gmail.com> Date: Thu, 09 Jun 2011 13:14:05 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ftpext@ietf.org, "uri-review@ietf.org" References: <4DDF617E.9050503@gmail.com> In-Reply-To: <4DDF617E.9050503@gmail.com> Content-Type: multipart/alternative; boundary="------------010306030507050607040703" Subject: Re: [ftpext] draft-yevstifeyev-ftp-uri-scheme-01 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 10:13:37 -0000 This is a multi-part message in MIME format. --------------010306030507050607040703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I've been working on this document to consider comments from Daniel. I'm ready to publish -02; however I'd like we achieved consensus with regard to the following issue. RFC 1738 clearly mentions: > Within a name or CWD component, the characters "/" and ";" are > reserved and must be encoded. In my draft, -01 there is: > ftp-path =/ [ ( [ cwd-part ] [ name ] ) ] [ typecode-part ] > cwd-part = *( "/" cwd ) > cwd = segment > name = segment-nz > typecode-part => > > where the and rules are defined inRFC 3986 > [RFC3986 ],Appendix A . The ";" character, even allowed byRFC 3986 > is the aforementioned productions, SHALL be escaped by percent > encoding. However, since ABNF is normative, restriction of ";" should also be reflected there. I've been thinking of: > ftp-path = [ [ cwd-part ] [ "/" name ] ] [ typecode-part ] > cwd-part = *( "/" cwd ) > cwd = ftp-segment > name = ftp-segment-nz > ftp-segment = *ftp-pchar > ftp-segment-nz = 1*ftp-pchar > ftp-pchar = unreserved / pct-encoded / ftp-sub-delims > / ":" / "@" > ftp-sub-delims = "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / "=" > ;RFC 3986 excluding ";" > typecode-part = ";typecode=" typecode > typecode = "a" / "i" / "d" Therefore I'd like to ask which ABNF is acceptable? Also, I haven't seen comments to Section 2.2.4, added per John's comment. Is it also acceptable? Mykyta Yevstifeyev 27.05.2011 11:31, Mykyta Yevstifeyev wrote: > Hi all, > > I've just posted draft-yevstifeyev-ftp-uri-scheme-01; please find it here: > > http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-01 > > The new revision tries to address comments from Daniel as well as from > John. It also incorporates various editorial improvements. The diffs > can be found here: > http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-scheme-01. > Please, if you have any comments and suggestions, feel free to express > them. > > Considering the necessity of wide community involvement, I'd like to > ask to adopt this draft as the ftpext2 WG item. I am copying this > message to WG chairs to let them know and decide if it is OK. > > All the best, > Mykyta Yevstifeyev > >> A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-01.txt has been successfully submitted by Mykyta Yevstifeyev and posted to the IETF repository. >> >> Filename: draft-yevstifeyev-ftp-uri-scheme >> Revision: 01 >> Title: The'ftp' URI Scheme >> Creation date: 2011-05-27 >> WG ID: Individual Submission >> Number of pages: 12 > --------------010306030507050607040703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello,

I've been working on this document to consider comments from Daniel.  I'm ready to publish -02; however I'd like we achieved consensus with regard to the following issue.

RFC 1738 clearly mentions:

   Within a name or CWD component, the characters "/" and ";" are
   reserved and must be encoded.
In my draft, -01 there is:

     ftp-path      =/ [ ( [ cwd-part ] [ name ] ) ] [ typecode-part ]
     cwd-part      =  *( "/" cwd )
     cwd           = segment
     name          = segment-nz
     typecode-part = <specified in Section 2.1>

   where the <segment> and <segment-nz> rules are defined in RFC 3986
   [RFC3986], Appendix A.  The ";" character, even allowed by RFC 3986
   is the aforementioned productions, SHALL be escaped by percent
   encoding.
However, since ABNF is normative, restriction of ";" should also be reflected there.  I've been thinking of:

ftp-path       = [ [ cwd-part ] [ "/" name ] ] [ typecode-part ]
cwd-part       =  *( "/" cwd )
cwd            = ftp-segment
name           = ftp-segment-nz
ftp-segment    = *ftp-pchar
ftp-segment-nz = 1*ftp-pchar
ftp-pchar      = unreserved / pct-encoded / ftp-sub-delims
               / ":" / "@"  
ftp-sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
               / "*" / "+" / "," / "="
               ;RFC 3986 <sub-delims> excluding ";"
typecode-part  = ";typecode=" typecode
typecode       = "a" / "i" / "d"
Therefore I'd like to ask which ABNF is acceptable?

Also, I haven't seen comments to Section 2.2.4, added per John's comment.  Is it also acceptable?

Mykyta Yevstifeyev

27.05.2011 11:31, Mykyta Yevstifeyev wrote:
Hi all,

I've just posted draft-yevstifeyev-ftp-uri-scheme-01; please find it here:

http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-01

The new revision tries to address comments from Daniel as well as from John.  It also incorporates various editorial improvements.  The diffs can be found here: http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-scheme-01.  Please, if you have any comments and suggestions, feel free to express them.

Considering the necessity of wide community involvement, I'd like to ask to adopt this draft as the ftpext2 WG item.  I am copying this message to WG chairs to let them know and decide if it is OK.

All the best,
Mykyta Yevstifeyev

A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-01.txt has been successfully submitted by Mykyta Yevstifeyev and posted to the IETF repository.

Filename:	 draft-yevstifeyev-ftp-uri-scheme
Revision:	 01
Title:		 The &#39;ftp&#39; URI Scheme
Creation date:	 2011-05-27
WG ID:		 Individual Submission
Number of pages: 12


--------------010306030507050607040703-- From vglass@jscape.com Thu Jun 9 07:07:37 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF6021F8545 for ; Thu, 9 Jun 2011 07:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xHI1kbxq--K for ; Thu, 9 Jun 2011 07:07:34 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 282AE21F8542 for ; Thu, 9 Jun 2011 07:07:30 -0700 (PDT) Received: by gxk19 with SMTP id 19so1121397gxk.31 for ; Thu, 09 Jun 2011 07:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.195.65 with SMTP id o41mr903909yhn.337.1307628450443; Thu, 09 Jun 2011 07:07:30 -0700 (PDT) Received: by 10.236.153.7 with HTTP; Thu, 9 Jun 2011 07:07:30 -0700 (PDT) In-Reply-To: <4DF07777.2010205@kimmeringer.de> References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> Date: Thu, 9 Jun 2011 08:07:30 -0600 Message-ID: From: Van Glass To: Lothar Kimmeringer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" , Robert McMurray , Robert Oslin Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:07:37 -0000 To expand on Lothar's idea, perhaps this could be achieved using positive preliminary (1XX) replies. ttp://en.wikipedia.org/wiki/List_of_FTP_server_return_codes e.g. C> COMB "dest" "part1" "part2" S> 1XX part1 complete S> 1XX part2 complete S> 250 success Van Glass JSCAPE Managed File Transfer and Network Solutions http://www.jscape.com On Thu, Jun 9, 2011 at 1:34 AM, Lothar Kimmeringer wrote: > Am 08.06.2011 22:57, schrieb Robert Oslin: >> >> "Have you experienced any issues" >> >> - yes, with larger (multi-GB) size files; however there are ways to >> combine the > >> file so that timeouts can be avoided in most cases. I made a couple of >> fleeting >> references to those methods in the spec, but really it would be up to th= e >> server >> vendor to research and implement the optimal recombine technique so that >> timeouts >> could all but be eliminated for everything but exceedingly large files..= . > > I have to find a way to open docx files so I might repeat something > that is already supposed but a simple way would be to respond with > the equivalent of a HTTP-100-response: > > C: COMB filea fileb filec > S: 250-Start COMB > =A0 250-COMB for filea finished > =A0 250-COMB for fileb finished > =A0 250-COMB for filec finished > =A0 250 COMB command successful > > Since a client should in general start over with a timeout every time > a line of the response has been received, it should help avoid timeouts > with very large files. In addition to that you receive some feedback, > that the server is still talking with you. > > > Regards, Lothar > -- > Lothar Kimmeringer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E-Mail: spamfang@kimmer= inger.de > =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP-encrypted mails preferred (Key-ID: 0x8BC3= CD81) > > Always remember: The answer is forty-two, there can only be wrong > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 questions! > From vglass@jscape.com Thu Jun 9 07:12:53 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81185228004 for ; Thu, 9 Jun 2011 07:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzmqGARn82VI for ; Thu, 9 Jun 2011 07:12:52 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA28228003 for ; Thu, 9 Jun 2011 07:12:52 -0700 (PDT) Received: by gxk19 with SMTP id 19so1126414gxk.31 for ; Thu, 09 Jun 2011 07:12:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.195.65 with SMTP id o41mr911727yhn.337.1307628771559; Thu, 09 Jun 2011 07:12:51 -0700 (PDT) Received: by 10.236.153.7 with HTTP; Thu, 9 Jun 2011 07:12:51 -0700 (PDT) In-Reply-To: References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> Date: Thu, 9 Jun 2011 08:12:51 -0600 Message-ID: From: Van Glass To: Lothar Kimmeringer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" , Robert McMurray , Robert Oslin Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:12:53 -0000 scratch that last commment ... forgot that 1XX replies are only on per command sent by client. Van Glass JSCAPE Managed File Transfer and Security Solutions http://www.jscape.com On Thu, Jun 9, 2011 at 8:07 AM, Van Glass wrote: > To expand on Lothar's idea, perhaps this could be achieved using > positive preliminary (1XX) replies. > > ttp://en.wikipedia.org/wiki/List_of_FTP_server_return_codes > > e.g. > > C> COMB "dest" "part1" "part2" > S> 1XX part1 complete > S> 1XX part2 complete > S> 250 success > > > Van Glass > JSCAPE > Managed File Transfer and Network Solutions > http://www.jscape.com > > > > > On Thu, Jun 9, 2011 at 1:34 AM, Lothar Kimmeringer > wrote: >> Am 08.06.2011 22:57, schrieb Robert Oslin: >>> >>> "Have you experienced any issues" >>> >>> - yes, with larger (multi-GB) size files; however there are ways to >>> combine the >> >>> file so that timeouts can be avoided in most cases. I made a couple of >>> fleeting >>> references to those methods in the spec, but really it would be up to t= he >>> server >>> vendor to research and implement the optimal recombine technique so tha= t >>> timeouts >>> could all but be eliminated for everything but exceedingly large files.= .. >> >> I have to find a way to open docx files so I might repeat something >> that is already supposed but a simple way would be to respond with >> the equivalent of a HTTP-100-response: >> >> C: COMB filea fileb filec >> S: 250-Start COMB >> =A0 250-COMB for filea finished >> =A0 250-COMB for fileb finished >> =A0 250-COMB for filec finished >> =A0 250 COMB command successful >> >> Since a client should in general start over with a timeout every time >> a line of the response has been received, it should help avoid timeouts >> with very large files. In addition to that you receive some feedback, >> that the server is still talking with you. >> >> >> Regards, Lothar >> -- >> Lothar Kimmeringer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E-Mail: spamfang@kimme= ringer.de >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP-encrypted mails preferred (Key-ID: 0x8BC= 3CD81) >> >> Always remember: The answer is forty-two, there can only be wrong >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 questions! >> > From Richard.Koenning@ts.fujitsu.com Thu Jun 9 08:18:10 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DAF11E80F8 for ; Thu, 9 Jun 2011 08:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m04vl8IulA1 for ; Thu, 9 Jun 2011 08:18:09 -0700 (PDT) Received: from dgate10.ts.fujitsu.com (dgate10.ts.fujitsu.com [80.70.172.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12711E8106 for ; Thu, 9 Jun 2011 08:18:08 -0700 (PDT) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=jWyuKB+FFXSr5/CZv8tpT7UfgW1pKw2USv32GAbg/ENKjX66JNwABJCg UXL8vCYhelS/+VUm+t081nV2fM9qdpVIp1fOUqM7dY6kKneBfGK4F9h6A uj0qlhqXcXYZQ+1F/KAUEj1SP1TtAh1/AN1JzoOlkhHeB5oXYJpmkh8W0 8sHWV8cfUZkb9wWAMAEjlp/QYZhzAv3qSqxom5fI8R6tnQLIw/dYc9XjU AHFS8Qag1mb5sUaKuPoiKyvWqWolu; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=Richard.Koenning@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1307632689; x=1339168689; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3QaADTh8WaoXAyrJIEGCxcp3GtohRSLKp1usWO1CYAw=; b=KAoKfqKj8zkSBj+IKt+9NmjJbHuxvrD7KJb6Yyvi4FS5GIrjxEk0AocW pbZRXGck8ZLH+d8pw0Rp0psGIh/eLbgngWlv9+FFMu5OLMwiClKiwL6ww Ev3wl2Zw0iSlESV4m0dMUb3RBntVQatRxF2HMEL8mKe9IUA3cj9M7w8cL oHn094k6Gr1JuXsWRl/JPuU/RT029qZ3Sw+Zx4Vs+pz5vHQRBgWQYexEk 5WpdWZRkjNP+E8abHHQ6K2Kcnp9w3; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.65,340,1304287200"; d="scan'208";a="79325588" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate10u.abg.fsc.net with ESMTP; 09 Jun 2011 17:18:08 +0200 X-IronPort-AV: E=Sophos;i="4.65,340,1304287200"; d="scan'208";a="115067439" Received: from mch8469d.mch.fsc.net (HELO [172.25.52.240]) ([172.25.52.240]) by abgdgate40u.abg.fsc.net with ESMTP; 09 Jun 2011 17:18:07 +0200 Message-ID: <4DF0E42F.1000104@ts.fujitsu.com> Date: Thu, 09 Jun 2011 17:18:07 +0200 From: Richard Koenning Organization: Fujitsu Technology Solutions GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: de, de-nds, en, en-US, it MIME-Version: 1.0 To: Lothar Kimmeringer References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> In-Reply-To: <4DF07777.2010205@kimmeringer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" , Robert Oslin Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Richard.Koenning@ts.fujitsu.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:18:10 -0000 Lothar Kimmeringer wrote: > Am 08.06.2011 22:57, schrieb Robert Oslin: >=20 >>"Have you experienced any issues" >> >>- yes, with larger (multi-GB) size files; however there are ways to com= bine the >=20 > > file so that timeouts can be avoided in most cases. I made a couple = of fleeting > > references to those methods in the spec, but really it would be up t= o the server > > vendor to research and implement the optimal recombine technique so = that timeouts > > could all but be eliminated for everything but exceedingly large fil= es... >=20 > I have to find a way to open docx files so I might repeat something > that is already supposed but a simple way would be to respond with > the equivalent of a HTTP-100-response: >=20 > C: COMB filea fileb filec > S: 250-Start COMB > 250-COMB for filea finished > 250-COMB for fileb finished > 250-COMB for filec finished > 250 COMB command successful How do you know already after the first partial file that the combining=20 of the files will be ultimately successful? (The reply code of the first = and the last line of the reply must be the same, see RFC 959, p. 36.) With the SIZE command we have already the same problem (at least=20 implementors have it, who don't limit the SIZE command to cases where=20 the file stat information delivers already the answer.) Ciao, Richard --=20 Dr. Richard W. K=F6nning Fujitsu Technology Solutions GmbH From keisial@gmail.com Thu Jun 9 08:24:16 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51C511E80FD for ; Thu, 9 Jun 2011 08:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwDHme8R0QrB for ; Thu, 9 Jun 2011 08:24:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C33CC11E8109 for ; Thu, 9 Jun 2011 08:24:13 -0700 (PDT) Received: by wyb29 with SMTP id 29so1365993wyb.31 for ; Thu, 09 Jun 2011 08:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=uJ9X1G2M1H0wDP8vl2BiYux2ghTpHA4gEt8BfYvdO9U=; b=paxAGLvLSu+Yl5gr0de+lwJa8P6zvaLdWV3RL5NsOp8lhKM7Y4NhQhjoe9HXjJLB7m 1Van0ubmYFZRYtDEELKo0fiwZEpTaxO+4jJ0EOfyEpWekaQOHag/6v5qfH3Zo9srE1mT 4moAiuH0dOQvJoi77JX8pAt3U8RrqS8joKk/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=iSwXi61NlMXF1QBffMiqHfe9ZSdVLvB4jA86OrCDLF4GRJpMOTAc5ryJyO7yKcjnNn ZwFDghETfbLAGj5ngvvXuZP/iNpYhdwckAT7gjEkY5PYoKshoHJ5h6wiV6T8QMxR/u98 tH0qIrH+EAMTVB9+nlLe1QhPeuW6fk0qKrLDw= Received: by 10.216.67.72 with SMTP id i50mr975021wed.29.1307633052590; Thu, 09 Jun 2011 08:24:12 -0700 (PDT) Received: from [192.168.1.26] (143.red-80-28-70.adsl.dynamic.ccgg.telefonica.net [80.28.70.143]) by mx.google.com with ESMTPS id n20sm905299weq.15.2011.06.09.08.24.10 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 08:24:11 -0700 (PDT) Message-ID: <4DF0E6C3.7020209@gmail.com> Date: Thu, 09 Jun 2011 17:29:07 +0200 From: "=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=" User-Agent: Thunderbird MIME-Version: 1.0 To: Robert Oslin References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040407010105020600050009" Cc: "ftpext@ietf.org" Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:24:16 -0000 This is a multi-part message in MIME format. --------------040407010105020600050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Oslin wrote: > > "Any submission to the IETF intended by the Contributor for > publication as all or part of an IETF Internet-Draft or RFC and any > statement made within the context of an IETF activity is considered an > "IETF Contribution". > > It only took me 10+ years, but here's my contribution the FTP ext > community (attached). > I still have some cuteftp binary ~12 years old :) > Essentially an early draft to ratify the commonly used COMB command > for support of multi-part (a.k.a accelerated) uploads. I welcome > comments/questions from the community. Ideally redlining the document > (or via comments in the doc). I will resubmit using formal IETF draft > (in ASCII) once I've addressed all comments/questions in the MS Word > version (hope that's ok and doesn't break and IETF rules). > Libreoffice opens it fine, but the Table of contents is garbled, and there's a footer 'Oslin Expires 666666000000FailFailFailFailFailFailDecemberDecemberDecemberDecemberDecemberDecember 9/06/11 6201192009201020102011' which I doubt is present in the original file. I would change the text > > in the rare case COMB is used as an append rather than a create > operation, which is why a single (source) part pathname is supported. > to > in such case COMB appends the partial pathnames to the existent file. Regardign the Client or Server delete question: a) Which is the behavior of current implementors? b) IMHO "The client MUST check that no partial files are left after they are no longer needed." Note that some interrupted upload could have left temporary files, so the client should always check. I'd suggest in the rfc using some specific pattern that the can application can easily recognise, maybe even containing the hash of what's supposedly there. So if connecting a new session, the client detects a file called partial-8418bfdb63bc5d6ccc434b33d6017cd4.tmp it could prompt the user about deleting temporary files it has found. But also, on resuming a temporary upload, that same file could be reused without needing to reupload it (eg. the connection dropped when uploading the 7th piece, on next run it can skip the first 6 blocks), by knowing which piece it is (from the hash) and verifying that the content indeed matches (with HASH command). Another option would be basing the temporary names on the target name, eg: mybigfile.iso.1 mybigfile.iso.2... Same resuming capabilities are available, by knowing the file sizes (and the block size it uses when splitting) and usage of the hash command. I would provide the server the ability of deleting files after COMB, specially in cases where copying the final file would exceed the quota, in which case it COULD generate the big file and remove the partial ones. I think there should be an error code for "I won't perform the action in this mode (text)" for cases where combining would involve some kind of transliteration. --------------040407010105020600050009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Robert Oslin wrote:

“Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution".

 

It only took me 10+ years, but here’s my contribution the FTP ext community (attached).

I still have some cuteftp binary ~12 years old :)

 

Essentially an early draft to ratify the commonly used COMB command for support of multi-part (a.k.a accelerated) uploads. I welcome comments/questions from the community. Ideally redlining the document (or via comments in the doc). I will resubmit using formal IETF draft (in ASCII) once I’ve addressed all comments/questions in the MS Word version (hope that’s ok and doesn’t break and IETF rules).

Libreoffice opens it fine, but the Table of contents is garbled, and there's a footer 'Oslin Expires 666666000000FailFailFailFailFailFailDecemberDecemberDecemberDecemberDecemberDecember 9/06/11 6201192009201020102011' which I doubt is present in the original file.


I would change the text

in the rare case COMB is used as an append rather than a create operation, which is why a single (source) part pathname is supported.

to
> in such case COMB appends the partial pathnames to the existent file.

Regardign the Client or Server delete question:
a) Which is the behavior of current implementors?

b) IMHO "The client MUST check that no partial files are left after they are no longer needed."
Note that some interrupted upload could have left temporary files, so the client should always check. I'd suggest in the rfc using some specific pattern that the can application can easily recognise, maybe even containing the hash of what's supposedly there.

So if connecting a new session, the client detects a file called partial-8418bfdb63bc5d6ccc434b33d6017cd4.tmp it could prompt the user about deleting temporary files it has found. But also, on resuming a temporary upload, that same file could be reused without needing to reupload it (eg. the connection dropped when uploading the 7th piece, on next run it can skip the first 6 blocks), by knowing which piece it is (from the hash) and verifying that the content indeed matches (with HASH command).
Another option would be basing the temporary names on the target name, eg: mybigfile.iso.1 mybigfile.iso.2... Same resuming capabilities are available, by knowing the file sizes (and the block size it uses when splitting) and usage of the hash command.

I would provide the server the ability of deleting files after COMB, specially in cases where copying the final file would exceed the quota, in which case it COULD generate the big file and remove the partial ones.

I think there should be an error code for "I won't perform the action in this mode (text)" for cases where combining would involve some kind of transliteration.

--------------040407010105020600050009-- From lothar@kimmeringer.de Thu Jun 9 12:05:02 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EDA11E80A4 for ; Thu, 9 Jun 2011 12:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzdLiG0ZTiTK for ; Thu, 9 Jun 2011 12:05:01 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA3011E8199 for ; Thu, 9 Jun 2011 12:04:52 -0700 (PDT) Received: from [192.168.1.20] (mnch-5d85c581.pool.mediaWays.net [93.133.197.129]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LtS7s-1PWUz835j2-010rJ1; Thu, 09 Jun 2011 21:04:51 +0200 Message-ID: <4DF11952.6060601@kimmeringer.de> Date: Thu, 09 Jun 2011 21:04:50 +0200 From: Lothar Kimmeringer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Richard.Koenning@ts.fujitsu.com References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> In-Reply-To: <4DF0E42F.1000104@ts.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:FeDEIxNsusRD3/zyzB706CeiYf0/qHbY5Rx+PMXtMxW EuSNAsAaFgxL664IkKcuoxm7lyvq9BGgiWets4N/lmio3B1OPl lLZoSNhkZV2MDa1LCAzhlFHaDA0hpUHHWCU6eDvSWzQgJR1A6D brGwAmOG9XHB8X1vlhUxuG64bgQAVSEmsCpsF50NRuIXL9jTbt JzLYmx6U0s5k5dq+m5vpA== Cc: "ftpext@ietf.org" , Robert Oslin Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 19:05:02 -0000 Am 09.06.2011 17:18, schrieb Richard Koenning: > Lothar Kimmeringer wrote: > >> C: COMB filea fileb filec >> S: 250-Start COMB >> 250-COMB for filea finished >> 250-COMB for fileb finished >> 250-COMB for filec finished >> 250 COMB command successful > > How do you know already after the first partial file that the combining > of the files will be ultimately successful? That happens if you write emails before drinking your first coffee ;-) You're correct, that way it can't work but I'd like to keep that direction. How about working in a similar way when opening a data connection. There the server sends two responses instead of one. C: COMB filea fileb filec S: 150-Start COMB 150-COMB for filea finished 150-COMB for fileb finished 150-COMB for filec finished 150 COMB finished 250 COMB command successful Or in case of an error: C: COMB filea fileb filec S: 150-Start COMB 150-COMB for filea finished 150-COMB for fileb finished 150 COMB finished 552 Requested file action aborted: Exceeded storage allocation So in general more or less what Van said (after reading his mail again). Regards, Lothar -- Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! From rto@globalscape.com Thu Jun 9 12:10:57 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A5111E8229 for ; Thu, 9 Jun 2011 12:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv2j+bTlh3CP for ; Thu, 9 Jun 2011 12:10:57 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id 628D311E8221 for ; Thu, 9 Jun 2011 12:10:56 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Thu, 9 Jun 2011 14:10:47 -0500 From: Robert Oslin To: Lothar Kimmeringer , "Richard.Koenning@ts.fujitsu.com" Date: Thu, 9 Jun 2011 14:10:47 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: Acwm2B5zoNcyitSTQtijKw3jA5dxFQAACICg Message-ID: References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> <4DF11952.6060601@kimmeringer.de> In-Reply-To: <4DF11952.6060601@kimmeringer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ftpext@ietf.org" Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 19:10:57 -0000 This assumes one method of recombining the file where each part is sequenti= ally tacked on to the next, e.g. open, seek, write, open, seek, write, ad n= auseam. There are likely OS and File System specific techniques for combini= ng multiple chunks (parts) into a single file that may only be able to prov= ide an all or nothing "finished" vs. a partial success for each chunk appen= ded in a sequential write operation. I'll provide more on that in a bit (cu= rrently writing my reply to the various comments)... -----Original Message----- From: Lothar Kimmeringer [mailto:lothar@kimmeringer.de]=20 Sent: Thursday, June 09, 2011 2:05 PM To: Richard.Koenning@ts.fujitsu.com Cc: Robert Oslin; ftpext@ietf.org Subject: Re: [ftpext] COMB command IETF draft proposal Am 09.06.2011 17:18, schrieb Richard Koenning: > Lothar Kimmeringer wrote: > >> C: COMB filea fileb filec >> S: 250-Start COMB >> 250-COMB for filea finished >> 250-COMB for fileb finished >> 250-COMB for filec finished >> 250 COMB command successful > > How do you know already after the first partial file that the=20 > combining > of the files will be ultimately successful? That happens if you write emails before drinking your first coffee ;-) You'= re correct, that way it can't work but I'd like to keep that direction. How about working in a similar way when opening a data connection. There th= e server sends two responses instead of one. C: COMB filea fileb filec S: 150-Start COMB 150-COMB for filea finished 150-COMB for fileb finished 150-COMB for filec finished 150 COMB finished 250 COMB command successful Or in case of an error: C: COMB filea fileb filec S: 150-Start COMB 150-COMB for filea finished 150-COMB for fileb finished 150 COMB finished 552 Requested file action aborted: Exceeded storage allocation So in general more or less what Van said (after reading his mail again). Regards, Lothar --=20 Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! From rto@globalscape.com Thu Jun 9 14:05:44 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA7211E80FF for ; Thu, 9 Jun 2011 14:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDI9HlO3kYrH for ; Thu, 9 Jun 2011 14:05:42 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5649D11E80FC for ; Thu, 9 Jun 2011 14:05:42 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Thu, 9 Jun 2011 16:05:41 -0500 From: Robert Oslin To: =?iso-8859-1?Q?=C1ngel_Gonz=E1lez?= Date: Thu, 9 Jun 2011 16:05:42 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: AcwmuUrddwycR2qNQ86NhEZeEHEdBAAL5FGg Message-ID: References: <4DF0E6C3.7020209@gmail.com> In-Reply-To: <4DF0E6C3.7020209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F15941D3C8A2D54D92B341C20CACDF2311AC51B84Aexchange_" MIME-Version: 1.0 Cc: "ftpext@ietf.org" Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:05:44 -0000 --_000_F15941D3C8A2D54D92B341C20CACDF2311AC51B84Aexchange_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Angel, I agree with text changes. I've answered (b) and (c) in a separate message. From: =C1ngel Gonz=E1lez [mailto:keisial@gmail.com] Sent: Thursday, June 09, 2011 10:29 AM To: Robert Oslin Cc: ftpext@ietf.org Subject: Re: [ftpext] COMB command IETF draft proposal Robert Oslin wrote: "Any submission to the IETF intended by the Contributor for publication as = all or part of an IETF Internet-Draft or RFC and any statement made within = the context of an IETF activity is considered an "IETF Contribution". It only took me 10+ years, but here's my contribution the FTP ext community= (attached). I still have some cuteftp binary ~12 years old :) Essentially an early draft to ratify the commonly used COMB command for sup= port of multi-part (a.k.a accelerated) uploads. I welcome comments/question= s from the community. Ideally redlining the document (or via comments in th= e doc). I will resubmit using formal IETF draft (in ASCII) once I've addres= sed all comments/questions in the MS Word version (hope that's ok and doesn= 't break and IETF rules). Libreoffice opens it fine, but the Table of contents is garbled, and there'= s a footer 'Oslin Expires 666666000000FailFailFailFailFailFailDecemberDecem= berDecemberDecemberDecemberDecember 9/06/11 6201192009201020102011' which I= doubt is present in the original file. I would change the text in the rare case COMB is used as an append rather than a create operation, = which is why a single (source) part pathname is supported. to > in such case COMB appends the partial pathnames to the existent file. Regardign the Client or Server delete question: a) Which is the behavior of current implementors? b) IMHO "The client MUST check that no partial files are left after they ar= e no longer needed." Note that some interrupted upload could have left temporary files, so the c= lient should always check. I'd suggest in the rfc using some specific patte= rn that the can application can easily recognise, maybe even containing the= hash of what's supposedly there. So if connecting a new session, the client detects a file called partial-84= 18bfdb63bc5d6ccc434b33d6017cd4.tmp it could prompt the user about deleting = temporary files it has found. But also, on resuming a temporary upload, tha= t same file could be reused without needing to reupload it (eg. the connect= ion dropped when uploading the 7th piece, on next run it can skip the first= 6 blocks), by knowing which piece it is (from the hash) and verifying that= the content indeed matches (with HASH command). Another option would be basing the temporary names on the target name, eg: = mybigfile.iso.1 mybigfile.iso.2... Same resuming capabilities are available= , by knowing the file sizes (and the block size it uses when splitting) and= usage of the hash command. I would provide the server the ability of deleting files after COMB, specia= lly in cases where copying the final file would exceed the quota, in which = case it COULD generate the big file and remove the partial ones. I think there should be an error code for "I won't perform the action in th= is mode (text)" for cases where combining would involve some kind of transl= iteration. --_000_F15941D3C8A2D54D92B341C20CACDF2311AC51B84Aexchange_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Angel, I agree with text changes. =

 

I’v= e answered (b) and (c) in a separate message.

 

From: =C1ng= el Gonz=E1lez [mailto:keisial@gmail.com]
Sent: Thursday, June 09= , 2011 10:29 AM
To: Robert Oslin
Cc: ftpext@ietf.orgSubject: Re: [ftpext] COMB command IETF draft proposal

 

Robert Oslin wrote:

“Any= submission to the IETF intended by the Contributor for publication as all = or part of an IETF Internet-Draft or RFC and any statement made within the = context of an IETF activity is considered an "IETF Contribution".=

 

It only took me 10+ years, but here’s my contribution the FTP ext = community (attached).

I still have some cute= ftp binary ~12 years old :)

 

Essentially an early draft to ratify the commonly used COMB comma= nd for support of multi-part (a.k.a accelerated) uploads. I welcome comment= s/questions from the community. Ideally redlining the document (or via comm= ents in the doc). I will resubmit using formal IETF draft (in ASCII) once I= ’ve addressed all comments/questions in the MS Word version (hope tha= t’s ok and doesn’t break and IETF rules).

Libreoffice opens it fine, but the Table of contents is garbled,= and there's a footer 'Oslin Expires 666666000000FailFailFailFailFailFailDe= cemberDecemberDecemberDecemberDecemberDecember 9/06/11 62011920092010201020= 11' which I doubt is present in the original file.


I would chang= e the text

in the rare case COMB is used as an append rather than a = create operation, which is why a single (source) part pathname is supported= .

to
>= in such case COMB appends the partial pathnames to the existent file.
<= br>Regardign the Client or Server delete question:
a) Which is the behav= ior of current implementors?

b) IMHO "The client MUST check tha= t no partial files are left after they are no longer needed."
Note = that some interrupted upload could have left temporary files, so the client= should always check. I'd suggest in the rfc using some specific pattern th= at the can application can easily recognise, maybe even containing the hash= of what's supposedly there.

So if connecting a new session, the cli= ent detects a file called partial-8418bfdb63bc5d6ccc434b33d6017cd4.tmp it c= ould prompt the user about deleting temporary files it has found. But also,= on resuming a temporary upload, that same file could be reused without nee= ding to reupload it (eg. the connection dropped when uploading the 7th piec= e, on next run it can skip the first 6 blocks), by knowing which piece it i= s (from the hash) and verifying that the content indeed matches (with HASH = command).
Another option would be basing the temporary names on the targ= et name, eg: mybigfile.iso.1 mybigfile.iso.2... Same resuming capabilities = are available, by knowing the file sizes (and the block size it uses when s= plitting) and usage of the hash command.

I would provide the server = the ability of deleting files after COMB, specially in cases where copying = the final file would exceed the quota, in which case it COULD generate the = big file and remove the partial ones.

I think there should be an err= or code for "I won't perform the action in this mode (text)" for = cases where combining would involve some kind of transliteration.

= --_000_F15941D3C8A2D54D92B341C20CACDF2311AC51B84Aexchange_-- From anthonybryan@gmail.com Thu Jun 9 14:14:14 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5F311E810E for ; Thu, 9 Jun 2011 14:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQGZm4pVpseL for ; Thu, 9 Jun 2011 14:14:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89DC111E80FC for ; Thu, 9 Jun 2011 14:14:13 -0700 (PDT) Received: by ywp31 with SMTP id 31so1404607ywp.31 for ; Thu, 09 Jun 2011 14:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=OxY5UvmSffgtWa9jyjkce4RRkkrP2GYDBw5dM4Ta0n0=; b=XvDuyVW/oTjEmAhF9tvNkCnZ1H+QbdgfGAzkjFt88mWHWhSwGvSfwgV4KKwar8ORTV qSVj59PBEtvNVBpqnHDPVkT+BFOvjgEBh/1QKdPd/vIrUzxMrleDtSokVPVXbsYejACv cP5RzLmXyudL8MY9D/a7uJbgTSaQleG2P+gUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=vhNbkjXur49CwBvPVVlyEFDc/ITB9tmUJoURyzOnEdGNlluUMasezra6MsWHGnm5Gp Rb9YR3b1Olf+rFxuCKtaGk6MHgjDiiHAvvH3OqorLtVu6EDhSVQeNRQ1AKfFqK8TIQle ZJCr4PO02Mz40FVdfuBCdQM6sk5p/BwkbBSkU= MIME-Version: 1.0 Received: by 10.91.21.35 with SMTP id y35mr2439596agi.131.1307654052980; Thu, 09 Jun 2011 14:14:12 -0700 (PDT) Received: by 10.90.73.1 with HTTP; Thu, 9 Jun 2011 14:14:12 -0700 (PDT) In-Reply-To: <4DF07777.2010205@kimmeringer.de> References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> Date: Thu, 9 Jun 2011 17:14:12 -0400 Message-ID: From: Anthony Bryan To: Robert Oslin , "ftpext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:14:14 -0000 On Thu, Jun 9, 2011 at 3:34 AM, Lothar Kimmeringer wrote: > Am 08.06.2011 22:57, schrieb Robert Oslin: >> >> "Have you experienced any issues" >> >> - yes, with larger (multi-GB) size files; however there are ways to >> combine the > >> file so that timeouts can be avoided in most cases. I made a couple of >> fleeting >> references to those methods in the spec, but really it would be up to th= e >> server >> vendor to research and implement the optimal recombine technique so that >> timeouts >> could all but be eliminated for everything but exceedingly large files..= . > > I have to find a way to open docx files so I might repeat something > that is already supposed but a simple way would be to respond with > the equivalent of a HTTP-100-response: it would help to have a text version available. > C: COMB filea fileb filec > S: 250-Start COMB > =A0 250-COMB for filea finished > =A0 250-COMB for fileb finished > =A0 250-COMB for filec finished > =A0 250 COMB command successful > > Since a client should in general start over with a timeout every time > a line of the response has been received, it should help avoid timeouts > with very large files. In addition to that you receive some feedback, > that the server is still talking with you. for HASH we have this: Depending on multiple conditions, the final server response to a HASH command could take long time, so a server could output a "213-" line every 5-10 seconds to avoid the connection being idle and silent. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From rto@globalscape.com Thu Jun 9 14:19:02 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC6C11E80FC for ; Thu, 9 Jun 2011 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hcK+wLXFPzC for ; Thu, 9 Jun 2011 14:18:59 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id 167A611E8116 for ; Thu, 9 Jun 2011 14:18:57 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Thu, 9 Jun 2011 16:18:56 -0500 From: Robert Oslin To: "ftpext@ietf.org" Date: Thu, 9 Jun 2011 16:18:57 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: AcwmuUrddwycR2qNQ86NhEZeEHEdBAAL7V9Q Message-ID: References: <4DF0E6C3.7020209@gmail.com> In-Reply-To: <4DF0E6C3.7020209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F15941D3C8A2D54D92B341C20CACDF2311AC51B85Cexchange_" MIME-Version: 1.0 Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:19:03 -0000 --_000_F15941D3C8A2D54D92B341C20CACDF2311AC51B85Cexchange_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you (all) for the feedback. It appears there three concerns so far: 1. Timeouts 2. Deletion 3. Integrity checking First let me state that it is my desire to keep the scope of the COMB comma= nd RFC as narrow as possible by leaving application specific logic to the c= lient or server application, and dealing only with protocol specific issues= . Timeout is one example of application level logic that should be handled by= the client in whichever manner it deems best, much like client implementat= ions must do today when dealing with long running operations, such as waiti= ng for the result of a custom command, hash operation, directory listing, e= tc. It is up to the client vendor to provide the necessary mechanisms and l= ogic for specifying timeout values, when those values are ignored or tempor= ary extended, and how to deal with a timeout when/if one occurs. It should = suffice to mention in the RFC that client vendors should take into consider= ation long running combine operations and design their client solutions acc= ordingly. Deletion is also an application level decision that should be completely up= to the server implementation. Why? Because whether or not parts are left o= ver largely depends on the method employed by the server to combine the fil= e, which may vary between server implementations on the same or different o= perating systems and/or underlying file systems. Therefore I believe it wou= ld be more correct to only require that the combine command be issued to th= e server indicating the client's intention, and if permissions allow, the s= erver would then be solely responsible for the process of reassembling the = file, and if necessary, deleting, archiving, or doing nothing with the cons= tituent parts as a by-product of the reassembly process (see notes on spars= e files - bottom). Keep in mind the example in the draft of the overall.log= and today.log that were appended using the COMB command. In that case it m= ay be desirable for the server to do nothing with the parts once the COMB t= akes place (i.e. leave all log parts intact), or perhaps archive the log pa= rts after the combine operation. Regardless of the server's decision, a 200= OK reply should be returned to the client once the entire operation (as de= fined by the server) has completed successfully. Integrity checking is a best practice and should certainly be recommended; = however it should not be mandatory, just as hash validation is not mandator= y for any other file creation or append operations today. Some of the discussion has centered on whether the server should reply with= a 250 for each part recombined, with the stated goal of "help[ing] avoid t= imeouts with very large files ". There are three reasons I recommend agains= t this approach. The first is because it only defers the problem, as extre= mely large files can have constituent parts that are in the multi-GB size r= ange. Hence the client's timeout threshold could be exceeded even while wai= ting for one of the parts to be combined. The second reason was already sta= ted (top), which is that it should be up to the client logic to determine h= ow best to deal with long (or potentially long) running operations. The thi= rd reason is because we have no idea what method the server will use to com= bine the parts, whether sequential (and slow) method or using advanced tech= niques such as sparse files, which brings me to my next point and answer to= =C1ngel 's question on the behavior of current implementations. Our implementation of COMB matches the draft. I.e. our client uploads each = part to the server (multiple parallel SEND commands), then sends the COMB c= ommand, after which the server combines the parts into the destination file= , and then it (the server) deletes the parts and sends a 200 reply to the c= lient. The client then (optionally) checks the integrity of the file using = our XCRC command, another proprietary command that will likely be replaced = by the HASH command. Unfortunately we (for historical reasons beyond this d= iscussion) implemented a rather crude technique for combing the source part= s into the destination file, essentially using a sequential copy of each so= urce file part to the new (destination) file at a certain byte offset, whic= h can take a horribly long time if each part is "large". The problem with = this isn't so much the potential for client timeouts (easily dealt with as = mentioned earlier), but rather the adverse effect of this long running oper= ation in that it negates the time gained from transferring the file in mult= iple parts to begin with! In some rare cases it can take longer to combine = the file than it took to upload the same - again, this is not by fault of t= he COMB command logic, but rather our poor choice of technique for combinin= g the file on the server. To that extent we have researched alternate methods for combining the file = that will all but eliminate this problem (and by nature and possible timeou= ts). Those include the use of sparse files and similar techniques, which li= kely exist for non-Windows operating systems as well. This brings me to my = final point, which is that I missed something very important in the draft t= hat that will require a bit of draft re-work... tomorrow or Monday I'll wr= ite up a summary of that change and why I think it helps augment the curren= t draft so that vendors can use advanced techniques for the combine process= if they so choose that may not be possible by just using the COMB command,= as those advanced techniques require foreknowledge of certain information = (byte size and number of parts) prior to receiving/writing the parts data, = in order to work properly. More to follow. Robert Oslin GlobalSCAPE --_000_F15941D3C8A2D54D92B341C20CACDF2311AC51B85Cexchange_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Thank you (all) for the feedback. It appears there three concerns so far:

 

1.       Timeouts

2. = ;      Deletion=

3.     &n= bsp; Integrity checking

First let me state that it is my desire to keep the scope of the CO= MB command RFC as narrow as possible by leaving application specific logic = to the client or server application, and dealing only with protocol specifi= c issues.

 

Timeout is one example of application level logic that should = be handled by the client in whichever manner it deems best, much like clien= t implementations must do today when dealing with long running operations, = such as waiting for the result of a custom command, hash operation, directo= ry listing, etc. It is up to the client vendor to provide the necessary mec= hanisms and logic for specifying timeout values, when those values are igno= red or temporary extended, and how to deal with a timeout when/if one occur= s. It should suffice to mention in the RFC that client vendors should take = into consideration long running combine operations and design their client = solutions accordingly.

 

Deletion is also an application level decision th= at should be completely up to the server implementation. Why? Because wheth= er or not parts are left over largely depends on the method employed by the= server to combine the file, which may vary between server implementations = on the same or different operating systems and/or underlying file systems. = Therefore I believe it would be more correct to only require that the combi= ne command be issued to the server indicating the client’s intention,= and if permissions allow, the server would then be solely responsible for = the process of reassembling the file, and if necessary, deleting, archiving= , or doing nothing with the constituent parts as a by-product of the reasse= mbly process (see notes on sparse files - bottom). Keep in mind the example= in the draft of the overall.log and today.log that were appended using the= COMB command. In that case it may be desirable for the server to do nothin= g with the parts once the COMB takes place (i.e. leave all log parts intact= ), or perhaps archive the log parts after the combine operation. Regardless= of the server’s decision, a 200 OK reply should be returned to the c= lient once the entire operation (as defined by the server) has completed su= ccessfully.

 

Integrity checking is a best practice and should certainly be= recommended; however it should not be mandatory, just as hash validation i= s not mandatory for any other file creation or append operations today.

 

S= ome of the discussion has centered on whether the server should reply with = a 250 for each part recombined, with the stated goal of “help[ing] av= oid timeouts with very large files “. There are three reasons I recom= mend against this approach.=A0 The first is because it only defers the prob= lem, as extremely large files can have constituent parts that are in the mu= lti-GB size range. Hence the client’s timeout threshold could be exce= eded even while waiting for one of the parts to be combined. The second rea= son was already stated (top), which is that it should be up to the client l= ogic to determine how best to deal with long (or potentially long) running = operations. The third reason is because we have no idea what method the ser= ver will use to combine the parts, whether sequential (and slow) method or = using advanced techniques such as sparse files, which brings me to my next = point and answer to =C1ngel ‘s question on the behavior of current im= plementations.

 

Our implementation of COMB matches the draft. I.e. our cl= ient uploads each part to the server (multiple parallel SEND commands), the= n sends the COMB command, after which the server combines the parts into th= e destination file, and then it (the server) deletes the parts and sends a = 200 reply to the client. The client then (optionally) checks the integrity = of the file using our XCRC command, another proprietary command that will l= ikely be replaced by the HASH command. Unfortunately we (for historical rea= sons beyond this discussion) implemented a rather crude technique for combi= ng the source parts into the destination file, essentially using a sequenti= al copy of each source file part to the new (destination) file at a certain= byte offset, which can take a horribly long time if each part is =A0“= ;large”. The problem with this isn’t so much the potential for = client timeouts (easily dealt with as mentioned earlier), but rather the ad= verse effect of this long running operation in that it negates the time gai= ned from transferring the file in multiple parts to begin with! In some rar= e cases it can take longer to combine the file than it took to upload the s= ame – again, this is not by fault of the COMB command logic, but rath= er our poor choice of technique for combining the file on the server.<= /o:p>

 

To = that extent we have researched alternate methods for combining the file tha= t will all but eliminate this problem (and by nature and possible timeouts)= . Those include the use of sparse files and similar techniques, which likel= y exist for non-Windows operating systems as well. This brings me to my fin= al point, which is that I missed something very important in the draft that= that will require a bit of draft re-work…=A0 tomorrow or Monday I= 217;ll write up a summary of that change and why I think it helps augment t= he current draft so that vendors can use advanced techniques for the combin= e process if they so choose that may not be possible by just using the COMB= command, as those advanced techniques require foreknowledge of certain inf= ormation (byte size and number of parts) prior to receiving/writing the par= ts data, in order to work properly. More to follow.

 

Robert Oslin

GlobalSCAPE

= --_000_F15941D3C8A2D54D92B341C20CACDF2311AC51B85Cexchange_-- From lothar@kimmeringer.de Thu Jun 9 14:51:25 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE33B11E80F5 for ; Thu, 9 Jun 2011 14:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG-KPg9yfNBc for ; Thu, 9 Jun 2011 14:51:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id BD89811E80BB for ; Thu, 9 Jun 2011 14:51:24 -0700 (PDT) Received: from [192.168.1.20] (mnch-5d85c581.pool.mediaWays.net [93.133.197.129]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lfpnu-1PlLRD3hPO-00ojAY; Thu, 09 Jun 2011 23:51:22 +0200 Message-ID: <4DF14059.9080709@kimmeringer.de> Date: Thu, 09 Jun 2011 23:51:21 +0200 From: Lothar Kimmeringer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Robert Oslin References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> <4DF11952.6060601@kimmeringer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:u+uKIOLuhXTw9Y9Dt8YW2v+hzaTKfCTdKZaMVHHe6z8 G3SdF5aF1aCH9Dn5EAM3VnmvDglkgBh/H/kK7lOtL5uJz2vBbX U467dDCD9XUnKNmOotFVwCGcQwJrQCdMcYByheAqts/Wz+4qBE 0SOzIvuG5uqKGnVlWtF7E4waqwoZoCB2v145bXLMUnmzJ5orKX sFC5sa2BhdSkThTMjEdvA== Cc: "ftpext@ietf.org" Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:51:26 -0000 Am 09.06.2011 21:10, schrieb Robert Oslin: > This assumes one method of recombining the file where each part is sequentially > tacked on to the next, e.g. open, seek, write, open, seek, write, ad nauseam. > There are likely OS and File System specific techniques for combining multiple > chunks (parts) into a single file that may only be able to provide an all or > nothing "finished" vs. a partial success for each chunk appended in a sequential > write operation. I'll provide more on that in a bit (currently writing my reply > to the various comments)... What the specific text after "150-" doesn't matter, it can also be 150-I'm still here, please wait or whatever you (the server) want. The only important thing is that something is given out at all that allows to reset the timeout on the client side. So if the server is working sequntially it might give out some kind of information that helps seeing some progress, but it might be something completely different like a poem ;-) In principle this technique is already in use, e.g. with "tarpits" (http://en.wikipedia.org/wiki/Tarpit_%28networking%29). Regards, Lothar -- Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! From rto@globalscape.com Thu Jun 9 14:57:18 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CAA21F846C for ; Thu, 9 Jun 2011 14:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWQBz+d6kygh for ; Thu, 9 Jun 2011 14:57:17 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.61]) by ietfa.amsl.com (Postfix) with ESMTP id 30EDD21F8464 for ; Thu, 9 Jun 2011 14:57:17 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Thu, 9 Jun 2011 16:57:16 -0500 From: Robert Oslin To: Lothar Kimmeringer Date: Thu, 9 Jun 2011 16:57:15 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: Acwm72B72LJ/7zTNTzW3JLaGonjzGAAACB5g Message-ID: References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> <4DF11952.6060601@kimmeringer.de> <4DF14059.9080709@kimmeringer.de> In-Reply-To: <4DF14059.9080709@kimmeringer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ftpext@ietf.org" Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:57:18 -0000 " So if the server is working sequntially it might give out some kind of in= formation that helps seeing some progress, but it might be something comple= tely different like a poem ;-)" Agreed. Sending the 150 at regular intervals (and not dependent on some pre= determined event, such as part1 combined), would work nicely. A server NOOP if you will. Robert -----Original Message----- From: Lothar Kimmeringer [mailto:lothar@kimmeringer.de]=20 Sent: Thursday, June 09, 2011 4:51 PM To: Robert Oslin Cc: Richard.Koenning@ts.fujitsu.com; ftpext@ietf.org Subject: Re: [ftpext] COMB command IETF draft proposal Am 09.06.2011 21:10, schrieb Robert Oslin: > This assumes one method of recombining the file where each part is=20 > sequentially > tacked on to the next, e.g. open, seek, write, open, seek, write, ad nau= seam. > There are likely OS and File System specific techniques for combining mu= ltiple > chunks (parts) into a single file that may only be able to provid= e an all or > nothing "finished" vs. a partial success for each chunk appe= nded in a sequential > write operation. I'll provide more on that in a bit= (currently writing my reply > to the various comments)... What the specific text after "150-" doesn't matter, it can also be 150-I'm = still here, please wait or whatever you (the server) want. The only importa= nt thing is that something is given out at all that allows to reset the tim= eout on the client side. So if the server is working sequntially it might give out some kind of info= rmation that helps seeing some progress, but it might be something complete= ly different like a poem ;-) In principle this technique is already in use, e.g. with "tarpits" (http://en.wikipedia.org/wiki/Tarpit_%28networking%29). Regards, Lothar --=20 Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! From anthonybryan@gmail.com Thu Jun 9 15:38:40 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB609228018; Thu, 9 Jun 2011 15:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvEOrnnY85ep; Thu, 9 Jun 2011 15:38:40 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E172C228017; Thu, 9 Jun 2011 15:38:39 -0700 (PDT) Received: by gxk19 with SMTP id 19so1474484gxk.31 for ; Thu, 09 Jun 2011 15:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RMz5bwRi47dLqE+8NnWFVXXrTvT/dUkWxanDwkm8xPk=; b=Vkt7MI7McG5QEzuQGjWOBgCIVuTMP3F+uVvsKqNYHAsLdtInAWMJbttouPwGh8IRFp SOciEuKoo5k1kE+dkSWd29Qtu+eSVJ/lX9y2vWJhge1YbNRuDsJO4zM0x78YpGQviUZV 1TUXPKEKgqpfz+FTZwRc7gZ320/MJNXqVOTK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xE8dxpcC+ONV7w6tei1m3i5MHfZ0beivvL5X7KPgyMGBURu5IyihpGBxCVvQBF7SeE u2WWkfyG2bnWRczhiED8ks/BfEeEuZRP1HrLqXujjXoXg+2vztO5hULjlnpkw4UUtwze fQhSvL0jE/BgGM4NlmCUnu0ZvhhkL/rHA6RFQ= MIME-Version: 1.0 Received: by 10.91.21.35 with SMTP id y35mr2490906agi.131.1307659117800; Thu, 09 Jun 2011 15:38:37 -0700 (PDT) Received: by 10.90.73.1 with HTTP; Thu, 9 Jun 2011 15:38:37 -0700 (PDT) In-Reply-To: <4DDF617E.9050503@gmail.com> References: <4DDF617E.9050503@gmail.com> Date: Thu, 9 Jun 2011 18:38:37 -0400 Message-ID: From: Anthony Bryan To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org, uri-review@ietf.org Subject: Re: [ftpext] draft-yevstifeyev-ftp-uri-scheme-01 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 22:38:41 -0000 On Fri, May 27, 2011 at 4:31 AM, Mykyta Yevstifeyev w= rote: > Hi all, > > I've just posted draft-yevstifeyev-ftp-uri-scheme-01; please find it here= : > > http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-01 > > Considering the necessity of wide community involvement, I'd like to ask = to > adopt this draft as the ftpext2 WG item.=A0 I am copying this message to = WG > chairs to let them know and decide if it is OK. after talking to our AD, this would require a re-charter of the FTPEXT2 WG to adopt it, as it is not an extension to FTP. there doesn't seem to be enough support to make this happen. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From Richard.Koenning@ts.fujitsu.com Fri Jun 10 06:07:09 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D4911E8130 for ; Fri, 10 Jun 2011 06:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ml800UL5i7t for ; Fri, 10 Jun 2011 06:07:08 -0700 (PDT) Received: from dgate20.ts.fujitsu.com (dgate20.ts.fujitsu.com [80.70.172.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1689B11E80F8 for ; Fri, 10 Jun 2011 06:07:07 -0700 (PDT) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=n7OtuyAFtqe61y0JRQMH071OmhKrTQPNs3BAmfleSLzu0+QIL1jkuOwR jsuQu4B1k8CzDnMHiH52jhUhqUCArituYKWZQE5GFgkIqqxQN4326Ejpc 2mX687RbzXIEeEQ7Fm5WMqP3YMmU1t0P6pAAyrglaM0D5gyv8dCm9kUd2 cwqoI9zk0kFANmdHz1swwcUZXMJR8w2gQCkh2ajeCwBrApw/WCiZyAsWe udS+l+0soaoj7Ypr56bnJRxnwYA37; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=Richard.Koenning@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1307711228; x=1339247228; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NOsvqGWEcWaoBzUKe2jrnT9QuPsYsshMEmEdv1K9XEc=; b=FcamLizfzEs+uNoqnIRACm5SNUzfD7K6ybDf45MV3fuAM0rglXJO3aCs 3awma5ie460K//J5SmluAsMr1D+XSFBXaa22AbfSEZXXSxr5aPftwSOjd b8KojIUe7O5s4QJLY5a5lbBuwMyx3qxCzH82BqhXYJzsDp2DjKquIiAI0 uQ7G3LPYgcSOUsR8iq3/IBi2h1Iex9Ob5dnCruaVHk64c7pIVS47DYYP4 0eYh5ScUnI8G87oro9yPMmnaTGP5C; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.65,346,1304287200"; d="scan'208";a="67710918" Received: from abgdgate30u.abg.fsc.net ([172.25.138.66]) by dgate20u.abg.fsc.net with ESMTP; 10 Jun 2011 15:07:06 +0200 X-IronPort-AV: E=Sophos;i="4.65,346,1304287200"; d="scan'208";a="114138366" Received: from mch8469d.mch.fsc.net (HELO [172.25.52.240]) ([172.25.52.240]) by abgdgate30u.abg.fsc.net with ESMTP; 10 Jun 2011 15:07:06 +0200 Message-ID: <4DF216F9.5000205@ts.fujitsu.com> Date: Fri, 10 Jun 2011 15:07:05 +0200 From: Richard Koenning Organization: Fujitsu Technology Solutions GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: de, de-nds, en, en-US, it MIME-Version: 1.0 To: "ftpext@ietf.org" References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> <4DF11952.6060601@kimmeringer.de> <4DF14059.9080709@kimmeringer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Robert Oslin Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Richard.Koenning@ts.fujitsu.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:07:09 -0000 As Van Glass already pointed out in an answer to his own similar=20 proposal only one 1yz message is allowed per command (see RFC 959,=20 p.37). Even when RFC 959 is not engraved into stone one should think=20 twice before violating/changing rules layed down in this RFC. Best regards, Richard Robert Oslin wrote: > " So if the server is working sequntially it might give out some kind o= f information that helps seeing some progress, but it might be something = completely different like a poem ;-)" >=20 > Agreed. Sending the 150 at regular intervals (and not dependent on some= predetermined event, such as part1 combined), would work nicely. >=20 > A server NOOP if you will. >=20 > Robert >=20 >=20 > -----Original Message----- > From: Lothar Kimmeringer [mailto:lothar@kimmeringer.de]=20 > Sent: Thursday, June 09, 2011 4:51 PM > To: Robert Oslin > Cc: Richard.Koenning@ts.fujitsu.com; ftpext@ietf.org > Subject: Re: [ftpext] COMB command IETF draft proposal >=20 > Am 09.06.2011 21:10, schrieb Robert Oslin: >=20 >>This assumes one method of recombining the file where each part is=20 >>sequentially >=20 > > tacked on to the next, e.g. open, seek, write, open, seek, write, ad= nauseam. > > There are likely OS and File System specific techniques for combinin= g multiple > chunks (parts) into a single file that may only be able to = provide an all or > nothing "finished" vs. a partial success for each ch= unk appended in a sequential > write operation. I'll provide more on tha= t in a bit (currently writing my reply > to the various comments)... >=20 > What the specific text after "150-" doesn't matter, it can also be 150-= I'm still here, please wait or whatever you (the server) want. The only i= mportant thing is that something is given out at all that allows to reset= the timeout on the client side. >=20 > So if the server is working sequntially it might give out some kind of = information that helps seeing some progress, but it might be something co= mpletely different like a poem ;-) >=20 > In principle this technique is already in use, e.g. with "tarpits" > (http://en.wikipedia.org/wiki/Tarpit_%28networking%29). >=20 >=20 > Regards, Lothar --=20 Dr. Richard W. K=F6nning Fujitsu Technology Solutions GmbH From rto@globalscape.com Fri Jun 10 06:53:55 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65311E817F for ; Fri, 10 Jun 2011 06:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocndt6IfL0SS for ; Fri, 10 Jun 2011 06:53:55 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id CC37C11E8135 for ; Fri, 10 Jun 2011 06:53:54 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Fri, 10 Jun 2011 08:53:53 -0500 From: Robert Oslin To: "Richard.Koenning@ts.fujitsu.com" , "ftpext@ietf.org" Date: Fri, 10 Jun 2011 08:53:52 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: Acwnb04vTn2dgvCRSG6+1hnAuci3jQABbSYQ Message-ID: References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> <4DF11952.6060601@kimmeringer.de> <4DF14059.9080709@kimmeringer.de> <4DF216F9.5000205@ts.fujitsu.com> In-Reply-To: <4DF216F9.5000205@ts.fujitsu.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:53:55 -0000 I totally missed/forgot about that: "The server-FTP process may send at mos= t, one 1yz reply per command.", which again gives favor to the argument tha= t the client app should take care of / handle timeouts, which can be done t= hrough configuration by the user or by adapting timeout thresholds dynamica= lly.=20 We should still include a recommendation (using "SHOULD") that the server o= ffer up a (single) 1xx reply at some point in the combine process, but even= so this (timeouts) may not be a problem if the server is "smart" about how= it combines the file upon receipt. Thanks, Robert Oslin -----Original Message----- From: Richard Koenning [mailto:Richard.Koenning@ts.fujitsu.com]=20 Sent: Friday, June 10, 2011 8:07 AM To: ftpext@ietf.org Cc: Robert Oslin; Lothar Kimmeringer Subject: Re: [ftpext] COMB command IETF draft proposal As Van Glass already pointed out in an answer to his own similar proposal o= nly one 1yz message is allowed per command (see RFC 959, p.37). Even when R= FC 959 is not engraved into stone one should think twice before violating/c= hanging rules layed down in this RFC. Best regards, Richard Robert Oslin wrote: > " So if the server is working sequntially it might give out some kind of = information that helps seeing some progress, but it might be something comp= letely different like a poem ;-)" >=20 > Agreed. Sending the 150 at regular intervals (and not dependent on some p= redetermined event, such as part1 combined), would work nicely. >=20 > A server NOOP if you will. >=20 > Robert >=20 >=20 > -----Original Message----- > From: Lothar Kimmeringer [mailto:lothar@kimmeringer.de] > Sent: Thursday, June 09, 2011 4:51 PM > To: Robert Oslin > Cc: Richard.Koenning@ts.fujitsu.com; ftpext@ietf.org > Subject: Re: [ftpext] COMB command IETF draft proposal >=20 > Am 09.06.2011 21:10, schrieb Robert Oslin: >=20 >>This assumes one method of recombining the file where each part is=20 >>sequentially >=20 > > tacked on to the next, e.g. open, seek, write, open, seek, write, ad n= auseam. > > There are likely OS and File System specific techniques for combining = multiple > chunks (parts) into a single file that may only be able to prov= ide an all or > nothing "finished" vs. a partial success for each chunk ap= pended in a sequential > write operation. I'll provide more on that in a b= it (currently writing my reply > to the various comments)... >=20 > What the specific text after "150-" doesn't matter, it can also be 150-I'= m still here, please wait or whatever you (the server) want. The only impor= tant thing is that something is given out at all that allows to reset the t= imeout on the client side. >=20 > So if the server is working sequntially it might give out some kind of=20 > information that helps seeing some progress, but it might be something=20 > completely different like a poem ;-) >=20 > In principle this technique is already in use, e.g. with "tarpits" > (http://en.wikipedia.org/wiki/Tarpit_%28networking%29). >=20 >=20 > Regards, Lothar -- Dr. Richard W. K=F6nning Fujitsu Technology Solutions GmbH From robmcm@microsoft.com Fri Jun 10 11:18:23 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72559E800D for ; Fri, 10 Jun 2011 11:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.317 X-Spam-Level: X-Spam-Status: No, score=-7.317 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS1gkK3Xb0VP for ; Fri, 10 Jun 2011 11:18:22 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB999E8016 for ; Fri, 10 Jun 2011 11:18:22 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 10 Jun 2011 11:18:15 -0700 Received: from VA3EHSOBE009.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 10 Jun 2011 11:18:14 -0700 Received: from mail153-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Fri, 10 Jun 2011 18:18:14 +0000 Received: from mail153-va3 (localhost.localdomain [127.0.0.1]) by mail153-va3-R.bigfish.com (Postfix) with ESMTP id E813410E031E for ; Fri, 10 Jun 2011 18:18:13 +0000 (UTC) X-SpamScore: 0 X-BigFish: PS0(zz103dKzz1202h1082kzzz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail153-va3: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT003.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail153-va3 (localhost.localdomain [127.0.0.1]) by mail153-va3 (MessageSwitch) id 1307729893713271_26675; Fri, 10 Jun 2011 18:18:13 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.236]) by mail153-va3.bigfish.com (Postfix) with ESMTP id 9C17A100050; Fri, 10 Jun 2011 18:18:13 +0000 (UTC) Received: from CH1PRD0302HT003.namprd03.prod.outlook.com (157.55.61.146) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 10 Jun 2011 18:18:06 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.42]) by CH1PRD0302HT003.namprd03.prod.outlook.com ([10.28.28.161]) with mapi id 14.01.0225.052; Fri, 10 Jun 2011 18:18:05 +0000 From: Robert McMurray To: =?iso-8859-1?Q?=C1ngel_Gonz=E1lez?= , Anthony Bryan , "ftpext@ietf.org" Thread-Topic: [ftpext] Single Port FTP Thread-Index: AQHMJfeJxUuP6qfeI02f/dZdxs3iJZS25S+g Date: Fri, 10 Jun 2011 18:18:05 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C1947095E@CH1PRD0302MB131.namprd03.prod.outlook.com> References: <4DEF90A6.8030602@gmail.com> In-Reply-To: <4DEF90A6.8030602@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Subject: Re: [ftpext] Single Port FTP X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:18:24 -0000 Single-port FTP is an interesting idea, though as John Klensin pointed out,= HTTP definitely takes the place of FTP for most single-port transfers. Just the same, I read through Anthony's draft and =C1ngel Gonz=E1lez's resp= onse a few times, and here is a quick brain dump of some additional thought= s that occurred to me while I was reading the draft. (I have to apologize u= p-front that several of these concepts are not fully thought-through, and a= s such I admit that they may have no merit - they're just what came to mind= while I was reading over the draft and taking a few notes.) First off, I like Anthony's idea of leveraging the MIME separator that ever= yone's already used to using in other areas. Should the response to a post-LOCK command be 125 and not 150 since the cha= nnel is already open? Should there be some sort of ABOR scenario? Should the draft have examples of all the common transfer commands, not jus= t RETR? For example: RETR Example: C> TYPE I S> 200 Type set to I. C> LOCK S> 200 LOCK OK to current connection C> RETR filename.ext S> 125 Command connection already open; transfer starting S> boundary=3Dseparator189dhde78b287734237842g3847g S> --separator189dhde78b287734237842g3847g S> [raw binary data] S> --separator189dhde78b287734237842g3847g-- S> 226 Transfer complete. STOR Example: C> TYPE I S> 200 Type set to I. C> LOCK S> 200 LOCK OK to current connection C> STOR filename.ext S> 125 Command connection already open; transfer starting C> boundary=3Dseparator189dhde78b287734237842g3847g C> --separator189dhde78b287734237842g3847g C> [raw binary data] C> --separator189dhde78b287734237842g3847g-- S> 226 Transfer complete. How long is the LOCK in effect? The draft makes it seem like it's for a sin= gle command; perhaps there should be a corresponding UNLK command, so all p= ost-LOCK commands are on a single channel until otherwise specified by the = UNLK command. For example: C> TYPE I S> 200 Type set to I. C> LOCK S> 200 LOCK OK to current connection C> STOR file1.ext S> 125 Command connection already open; transfer starting C> boundary=3Dseparator189dhde78b287734237842g3847g C> --separator189dhde78b287734237842g3847g C> [raw binary data] C> --separator189dhde78b287734237842g3847g-- S> 226 Transfer complete. C> STOR file2.ext S> 125 Command connection already open; transfer starting C> boundary=3Dseparator189dhde78b287734237842g3847g C> --separator189dhde78b287734237842g3847g C> [raw binary data] C> --separator189dhde78b287734237842g3847g-- S> 226 Transfer complete. C> UNLK S> 200 UNLK OK from current connection Instead of LOCK, how about a series of specific single-channel commands? So= the matching list of dual-channel to single-channel commands might include= : SRTR =3D RETR SSTR =3D STOR SLST =3D LIST SNLS =3D NLST SSTU =3D STOU SAPP =3D APPE I obviously prefixed everything with an "S" for "single channel command"; p= erhaps "C" might be a better prefix for "control channel command". (e.g. CR= TR, CSTR, etc.) For example: C> TYPE I S> 200 Type set to I. C> SSTR filename.ext S> 125 Command connection already open; transfer starting C> boundary=3Dseparator189dhde78b287734237842g3847g C> --separator189dhde78b287734237842g3847g C> [raw binary data] C> --separator189dhde78b287734237842g3847g-- S> 226 Transfer complete. Perhaps the boundary syntax could be simplified by one step - instead of de= claring a boundary, there could declare an end-of-file marker, then start d= ata immediately. For example: C> LOCK S> 200 LOCK OK to current connection C> STOR filename.ext S> 125 Command connection already open; transfer starting C> endoffile=3Dmarker189dhde78b287734237842g3847g C> [raw binary data] C> --marker189dhde78b287734237842g3847g-- S> 226 Transfer complete. That is, unless someone thinks that compound messages are feasible, which a= re not currently supported for FTP commands; this alludes somewhat to somet= hing that =C1ngel Gonz=E1lez mentioned about headers below the boundary. Fo= r example: C> LOCK S> 200 LOCK OK to current connection C> RETR /*.ext S> 125 Command connection already open; transfer starting C> boundary=3Dseparator189dhde78b287734237842g3847g C> --separator189dhde78b287734237842g3847g C> Content-Disposition: inline; filename=3D"file1.ext" C> [raw binary data] C> --separator189dhde78b287734237842g3847g C> Content-Disposition: inline; filename=3D" file2.ext" C> [raw binary data] C> --separator189dhde78b287734237842g3847g-- S> 226 Transfer complete. Of course, that last example starts to look a lot like HTTP or SMTP over FT= P, which brings us back to my opening liberally-worded paraphrase of John K= lensin's earlier response that FTP doesn't need to resemble HTTP; otherwise= we wouldn't need HTTP. ;-] Thanks! From iesg-secretary@ietf.org Thu Jun 16 06:05:53 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7E011E80E3; Thu, 16 Jun 2011 06:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wktlg7MjertS; Thu, 16 Jun 2011 06:05:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A998821F8572; Thu, 16 Jun 2011 06:05:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 06:05:03 -0700 Cc: ftpext@ietf.org Subject: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 13:05:53 -0000 The IESG has received a request from the FTP Extensions, 2nd edition WG (ftpext2) to consider the following document: - 'File Transfer Protocol HOST Command for Virtual Hosts' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/ No IPR declarations have been submitted directly on this I-D. From lothar@kimmeringer.de Thu Jun 16 09:39:53 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F431F0C47 for ; Thu, 16 Jun 2011 09:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1yJ3FFX3QhZ for ; Thu, 16 Jun 2011 09:39:52 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 525531F0C5C for ; Thu, 16 Jun 2011 09:39:52 -0700 (PDT) Received: from [192.168.1.20] (mnch-4d045d7e.pool.mediaWays.net [77.4.93.126]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MFsZi-1QKYZ32npe-00ExkM; Thu, 16 Jun 2011 18:39:49 +0200 Message-ID: <4DFA31D3.9010006@kimmeringer.de> Date: Thu, 16 Jun 2011 18:39:47 +0200 From: Lothar Kimmeringer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Richard.Koenning@ts.fujitsu.com References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> <4DF11952.6060601@kimmeringer.de> <4DF14059.9080709@kimmeringer.de> <4DF216F9.5000205@ts.fujitsu.com> In-Reply-To: <4DF216F9.5000205@ts.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:+OjBJYJHGh9theA/eSJI/HqW/48hjqQ8g7n+xEO5QAj Sl89UqyL0YSdE74EXbWh/GdIC0inlt6TsHOK3iq9p4PW9gzcQh Ys/A+KlVe6W7S6Rh7J4ZacaPnPPyhhC5Z5DBcFzOMyFY++xsUT w7/pCt+kRMDo+DIKe8ubf5hSlrIjUylqtntog83gXV9xVBYy5M MxrrIZlsVdXBf4ggsiTzg== Cc: "ftpext@ietf.org" , Robert Oslin Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 16:39:53 -0000 Am 10.06.2011 15:07, schrieb Richard Koenning: > As Van Glass already pointed out in an answer to his own similar > proposal only one 1yz message is allowed per command (see RFC 959, > p.37). Even when RFC 959 is not engraved into stone one should > think twice before violating/changing rules layed down in this RFC. There is a different between Van Glass' proposal and mine: Van Flass: C> COMB "dest" "part1" "part2" S> 1XX part1 complete S> 1XX part2 complete Mine: C: COMB filea fileb filec S: 150-Start COMB 150-COMB for filea finished 150-COMB for fileb finished 150-COMB for filec finished 150 COMB finished 250 COMB command successful In my example there is only one 150-response seperated into more than one lines. Best regards, Lothar Kimmeringer -- Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! From Richard.Koenning@ts.fujitsu.com Thu Jun 16 10:05:05 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4165C11E811B for ; Thu, 16 Jun 2011 10:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GvlAEfwf74I for ; Thu, 16 Jun 2011 10:05:04 -0700 (PDT) Received: from dgate10.ts.fujitsu.com (dgate10.ts.fujitsu.com [80.70.172.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4402E11E8118 for ; Thu, 16 Jun 2011 10:05:03 -0700 (PDT) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Transfer-Encoding; b=TlQLotC8PNSgWWPDh/R45QuZtSnChMZ6ePCMDKjk0YS1/u4TIpmDWe7u yNWf0qAKL74PdyV3afnvvYB8Z/eWaRgi4SpfTeYZ5KNceMMSTKC2cO6B0 7dz2wbhiIHGFz0GB29HI4bpxWUFhz3hg6Az3CKM5RXaw0d0wHvsdF5WoQ fcUU+Jdp4WjWgGEXy32E1aPoPIlaJelEMt/0tR0BnZ7Wxj2tztsni7Eoz mGan4YJ6zmKnDJ7RzevuV4VVrVJRb; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=Richard.Koenning@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1308243905; x=1339779905; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uqCsQjavzyY5FGG5yW4jKHWJv0O/1KDA1EkqDyLKY9s=; b=jXC6C8MoWQF+EZ0rOsgGmm2q67X1HPlSY5eCNIf1KrlEZpqmxeMHNlbK a1dVWKpMQ6Wc1mUrkvLad5aonzub0o2x6RrhRfT0qRpXeIya6H+dInus9 Fo1oi97i1DusFXV1cxOXnwf/su9dNvhMTam0uV+hIYZl00Jt6jfpU/tSc 6wAk6gX1+dFXZZsia3fDfwgYm5lmJz7Gm9yeUo7wGUIl9Lnfp8J/Omwx5 ZJ5vcUQdOU8e0YIpuWFJJQvI1mex7; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.65,375,1304287200"; d="scan'208";a="79878705" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate10u.abg.fsc.net with ESMTP; 16 Jun 2011 19:05:01 +0200 X-IronPort-AV: E=Sophos;i="4.65,375,1304287200"; d="scan'208";a="115342214" Received: from mch8469d.mch.fsc.net (HELO [172.25.52.240]) ([172.25.52.240]) by abgdgate40u.abg.fsc.net with ESMTP; 16 Jun 2011 19:05:01 +0200 Message-ID: <4DFA37BC.8030002@ts.fujitsu.com> Date: Thu, 16 Jun 2011 19:05:00 +0200 From: Richard Koenning Organization: Fujitsu Technology Solutions GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: de, de-nds, en, en-US, it MIME-Version: 1.0 To: "ftpext@ietf.org" References: <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> <4DF11952.6060601@kimmeringer.de> <4DF14059.9080709@kimmeringer.de> <4DF216F9.5000205@ts.fujitsu.com> <4DFA31D3.9010006@kimmeringer.de> In-Reply-To: <4DFA31D3.9010006@kimmeringer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Richard.Koenning@ts.fujitsu.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 17:05:05 -0000 Well, at the first look it seems a little bit like rape of RFC 959, but=20 currently i don't know anything which would speak against this solution. Best regards, Richard K=F6nning Lothar Kimmeringer wrote: > Am 10.06.2011 15:07, schrieb Richard Koenning: >=20 >>As Van Glass already pointed out in an answer to his own similar >=20 > > proposal only one 1yz message is allowed per command (see RFC 959, > > p.37). Even when RFC 959 is not engraved into stone one should > > think twice before violating/changing rules layed down in this RFC. >=20 > There is a different between Van Glass' proposal and mine: >=20 > Van Flass: > C> COMB "dest" "part1" "part2" > S> 1XX part1 complete > S> 1XX part2 complete >=20 > Mine: >=20 > C: COMB filea fileb filec > S: 150-Start COMB > 150-COMB for filea finished > 150-COMB for fileb finished > 150-COMB for filec finished > 150 COMB finished > 250 COMB command successful >=20 > In my example there is only one 150-response seperated into > more than one lines. >=20 >=20 > Best regards, >=20 > Lothar Kimmeringer --=20 Dr. Richard W. K=F6nning Fujitsu Technology Solutions GmbH, TSP ES&S SWE OS 5 Phone/Fax: +49-89-3222-2927 / -3222-329-2927 E-Mail: Richard.Koenning@ts.fujitsu.com From john-ietf@jck.com Fri Jun 17 19:31:27 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B2111E81C7 for ; Fri, 17 Jun 2011 19:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt7TUTLfQbW5 for ; Fri, 17 Jun 2011 19:31:25 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6811E80F8 for ; Fri, 17 Jun 2011 19:31:25 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QXlJk-000M7T-Bg; Fri, 17 Jun 2011 22:31:24 -0400 Date: Fri, 17 Jun 2011 22:31:23 -0400 From: John C Klensin To: Robert Oslin , ftpext@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 02:31:27 -0000 --On Wednesday, June 08, 2011 11:14 -0500 Robert Oslin wrote: >... > Essentially an early draft to ratify the commonly used COMB > command for support of multi-part (a.k.a accelerated) uploads. > I welcome comments/questions from the community. Ideally > redlining the document (or via comments in the doc). I will > resubmit using formal IETF draft (in ASCII) once I've > addressed all comments/questions in the MS Word version (hope > that's ok and doesn't break and IETF rules). As at least one other person has said, it doesn't break any rules, but ASCII is a lot easier for many of us to deal with and comment on, if only out of habit. To put what I'm about to say in context, I usually take the position of an FTP purist whose relationship with the protocol goes all the way back to some of the original design meetings. That makes me inclined to respond to a lot of proposals with "that isn't FTP but an attempt to graft another protocol onto it; why don't you use something else". That doesn't quite apply in this case, but... A few comments about your spec that I don't think others have made: (1) It is seriously unclear and needs work to describe what you intend. For example, if you say "recombine a file from its constituent parts" or "instruct the server to recombine the previously uploaded file parts", it could be read as requiring STOR /f.p1 STOR /f.p2 STOR /f.p3 STOR /f.pr COMB "/file.dat" "/f.p1" "/f.p2" "/f.p3" "/f.p4" I think you intend that COMB cause the transfer and then the combining function, but that is not what the document appears to say. Or, given "It is up to the user-FTP process to determine when, if, and how to split up a file into two or more parts, upload each part as a unique file over multiple parallel connections, retransmit one or more..." maybe the above is exactly what you do intend (one could substitute STOU, which would have some nice advantages, but, if that were your intention, it is wholly missing from the spec. (2) You need to be extremely careful with concepts like "file path" and "directory path". They are not defined in FTP the way your description of COMB seems to assume. (3) Your use of quotes is un-FTP-ish and your command makes assumptions about the syntax of a name that is not local to the working directory on the server-FTP. I'd rather you didn't do it at all, but, if you must, the specification has to identify how you would express a file name on the server-FTP system that was required to actually be, e.g., file/".dat Your U**x-ish assumptions would probably call for COMB "/file\/\".dat" ... or COMB "/file\/"".dat" ... but the spec isn't clear and both are error-prone. Note that the second is seriously pathological given your "spaces not needed" rule. (4) Remembering that we originally intended FTP to be asynchronous between the command and data streams, it may be too late now, but the FTP-ish way to do this probably would have been something like: CWD wherever-you-want-this-to-end-up BOMPT (Begin-Odd-Multipart-Transfer) PASV (or PORT, here and below) STRU local-name PASV STRU local-name PASV STRU local-name ... COMBine remote-name The STRU commands would presumably all get 2yz replies specifying the name used or failure codes permitting something else to be done. The server would be required to return those STRU replies in order even if the transfers finished out of order. Note that not only specifies completely separate and parallel data connections (rather than maybe trying to share a single TCP data stream), but, by using initiation and competition commands and letting the server keep track of its own part names, it completely eliminates the quotes, hoping the path syntax on the local or remote systems matches whatever you've assumed, and, by using STRU, eliminates both the need to be sure that the part names chosen on the sender machine are available on the receiver one and a small potential security problem. It also permits use of REST, etc., on the individual streams if needed. The use of STRU in that context would also permit an intelligent FTP-server to use some type of pool (or scratch or reserved temporary) space for the intermediate files, copying only the final, reassembled, file into the target directory. That would eliminate several of the operational or security risks you discuss. Arranging to disassemble the file into pool space on the client machine (or using the interleaved block approach discussed below) would eliminate a number of others. Of course, in a fully asynchronous environment, a sequence of APPE commands would give a very close approximation of the above. And that is how what you are looking for now was actually done for a while, long ago. FWIW, the above model could work rather well in the download direction, elegantly eliminating the need for odd tricks with the checkpoint/restart mechanism. All of that said, experience with a number of distributed/parallel storage systems, including some distributed database update models and RAID striping, would suggest that the most transfer-efficient way to do what you are trying to accomplish would be to use a completely different model: treat the file to be transferred as a sequence of blocks of specified size, open a bunch of connections, push block 1 onto connection 0, block 2 onto connection 1, and continue with each block, M, going out onto connection (M modulo number of connections). That would not only permit more optimization but would permit reassembly to start while the transfer was still in progress. (5) Some of the material in 3.3 don't make any sense. If the server "SHOULD" or "MAY" send the specified responses, it seems to me that is obligatory on you to specify what happens if the server chooses to do something else. Presumably it is not open season for anything you don't specify -- I'd predict severe interoperability problems if a server responded to your 550 case by returning, e.g., 987. (6) The first two paragraphs of your Security Considerations section are a little bogus. Providing COMB support only to authorized users, etc., may protect against certain classes of malicious attacks, but they provide absolutely no protection against ignorance, stupidity, or carelessness, any of which can be easily exploited by an attacker as well as creating risks of equally-damaging accidents. best, john From evnikita2@gmail.com Sat Jun 18 22:04:48 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4F11E80EE; Sat, 18 Jun 2011 22:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5plVUwny+knI; Sat, 18 Jun 2011 22:04:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65B9B11E80DA; Sat, 18 Jun 2011 22:04:47 -0700 (PDT) Received: by fxm15 with SMTP id 15so579698fxm.31 for ; Sat, 18 Jun 2011 22:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=QNCLIj2XBWx+8EisDxHHmQlFBj0VK4Iw3f/5XC8ylk8=; b=GeJfJOApUqR3dzi0b4pz5NY/UM31+cDbmyMPobGhX7pj3mr2Ob/6LB8QrhaJO0num+ GykLtGq80Hh1sPZPBm0eUgi2XP1FHjfB5djqr+kQQEw46lCU9lgIuN6BKsi/HTgX4D7P O2yuE3/J3DfS04VkfAYICEsndku4+sSx3YVms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=UEdtTlRFumzvCQIeiy9vDpj9uwJZfdO9a2T/Ssgl9tev4vIV0znie+38rjWcvot/+A y2zT513sEF4AiNX4o/yyC8gEt59pz2q+dZSuUQk/tSpgeWBY6hWgCyIHjtX8eHdPrPbT F1OL2LjQY7A6D1OKQgkn0fIY4FFjoKCb527Eg= Received: by 10.223.58.145 with SMTP id g17mr1093098fah.77.1308459886383; Sat, 18 Jun 2011 22:04:46 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q14sm2100723faa.3.2011.06.18.22.04.44 (version=SSLv3 cipher=OTHER); Sat, 18 Jun 2011 22:04:44 -0700 (PDT) Message-ID: <4DFD839A.6010601@gmail.com> Date: Sun, 19 Jun 2011 08:05:30 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "ftpext@ietf.org" , "uri-review@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ftpext] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 05:04:48 -0000 Hello, After working on the document a bit, I've submitted a new version of draft-yevstifeyev-ftp-uri-scheme-02: http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-02 The differences from -01 are at http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-scheme-02.txt I personally believe the document is almost ready, yet, I'd like to seek more community comments (if any) on it. Thanks, Mykyta Yevstifeyev From john-ietf@jck.com Sun Jun 19 07:38:37 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A166C11E8075; Sun, 19 Jun 2011 07:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IdyomugOTkI; Sun, 19 Jun 2011 07:38:36 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE4D11E8077; Sun, 19 Jun 2011 07:38:36 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QYJ91-0007pA-0o; Sun, 19 Jun 2011 10:38:35 -0400 X-Vipre-Scanned: 03F0236F00259C03F024BC-TDI Date: Sun, 19 Jun 2011 10:38:34 -0400 From: John C Klensin To: Mykyta Yevstifeyev Message-ID: <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> In-Reply-To: <4DFD839A.6010601@gmail.com> References: <4DFD839A.6010601@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ftpext@ietf.org, uri-review@ietf.org Subject: Re: [ftpext] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 14:38:37 -0000 --On Sunday, June 19, 2011 08:05 +0300 Mykyta Yevstifeyev wrote: > Hello, > > After working on the document a bit, I've submitted a new > version of draft-yevstifeyev-ftp-uri-scheme-02: > > http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-02 > > The differences from -01 are at > http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-s > cheme-02.txt > > I personally believe the document is almost ready, yet, I'd > like to seek more community comments (if any) on it. First of all, I appreciate the many improvements in this document. Most of my difficulties with the earlier version remain and, as a result, I don't think we are at "almost ready". For example: (1) Regardless of what was done in RFC 1738, if something is going to be called an "FTP" URI, it should reflect the FTP protocol is a serious and comprehensive way. Failure to do so is, IMO, a "known technical omission" and, using logic you have used in other contexts, would require deprecating the existing definition and moving it to Historic if it were in a stand-alone document. Perhaps, if you want to go down this path, you should think about a new "ftpanon" URI that would incorporate these capabilities (and maybe one or two more, see below), drop from the syntax entirely (always send "anonymous" and then respond to any password prompt based on what it says), and so on. If you did that, it would make sense to have the document also update 1738 to deprecate its definition of an FTP URI (or to have a discussion with the IESG about whether the "obsoleted by" status of 1738 already accomplished that), which I assume is part of your objective. (2) In a world in which a lot of servers (maybe a majority) run Linux or flavors of Unix and many client machines run something else and get confused when trying to interpret files with LF-only line terminations as text), I still believe that support for TYPE is critical, even in a the stripped-down "ftpanon" URI concept but certainly with a full FTP URI. (3) To the extent to which the FTPEXT2 WG is actually doing anything, a full FTP URI needs to consider the changes that are being made there, or at least to have a mechanism for being extended to recognize additional commands and keywords. Again, reducing your expectations to what I describe above as an "ftpanon" URI would eliminate at least most of that problem. If you want a general FTP URI, I think that WG should carefully review the spec once it has drained its queue of charter-specified pending work. (4) If your goal is not really to define a URI but to describe the way in which the "ftp" URI is being used today, that would be ok as an Informational document. But, to the extent to which what the description did or did not include constituted a known technical omission or defect, that document would be inappropriate for standards track. (5) It in just a nit compared to the above, but I can find absolutely nothing in this specification that updates RFC 959 in any way. All just my opinion, of course. john From evnikita2@gmail.com Mon Jun 20 02:10:24 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D9C11E8095; Mon, 20 Jun 2011 02:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK2eJ6VSAsCT; Mon, 20 Jun 2011 02:10:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8804111E80D6; Mon, 20 Jun 2011 02:10:21 -0700 (PDT) Received: by gya6 with SMTP id 6so945998gya.31 for ; Mon, 20 Jun 2011 02:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vyLhZMUTTRNhIrmtL3g5kHJvDgWEzScFwGulj6tFLZc=; b=D33UoDmha6bo2H0EoS5Z0rAKOopRUiLRhTfCScSa3zu94+6mWCJznEM1m7Jk2PjItx 5BaWvYob2DDeEEjwrhACrn9o2CU7xYQZ7sLRNheaObBs1h5sAL+mU1LqokDe4LekgoPR +t7mvzHxFi2E8eDg6+seIUXNvnvAltgjrI4Y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ep9R+FwGUM7ypQgPJZp773GMNhxHjHk6GKjD2EwFeDeC5eUutd4Kl1pBovm7N7nhZ8 XfEdH8IlbJVaDORILFFrMZSYwbg8lfo//+/5KRD3J0/lxAxKDRMJOMZXcFe9EXOzewpH 07jM0G8tXFDyXmKtAZU9dWSCDTZEI6GNBAkCQ= Received: by 10.150.114.2 with SMTP id m2mr438952ybc.3.1308561012982; Mon, 20 Jun 2011 02:10:12 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id w66sm3396430yhi.52.2011.06.20.02.10.11 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 02:10:12 -0700 (PDT) Message-ID: <4DFF0EA2.9030709@gmail.com> Date: Mon, 20 Jun 2011 12:10:58 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: John C Klensin References: <4DFD839A.6010601@gmail.com> <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> In-Reply-To: <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ftpext@ietf.org, uri-review@ietf.org Subject: Re: [ftpext] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 09:10:24 -0000 John, 19.06.2011 17:38, John C Klensin wrote: > --On Sunday, June 19, 2011 08:05 +0300 Mykyta Yevstifeyev > wrote: > >> Hello, >> >> After working on the document a bit, I've submitted a new >> version of draft-yevstifeyev-ftp-uri-scheme-02: >> >> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-02 >> >> The differences from -01 are at >> http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-s >> cheme-02.txt >> >> I personally believe the document is almost ready, yet, I'd >> like to seek more community comments (if any) on it. > First of all, I appreciate the many improvements in this > document. Most of my difficulties with the earlier version > remain and, as a result, I don't think we are at "almost ready". > For example: > > (1) Regardless of what was done in RFC 1738, if something is > going to be called an "FTP" URI, it should reflect the FTP > protocol is a serious and comprehensive way. Failure to do so > is, IMO, a "known technical omission" and, using logic you have > used in other contexts, would require deprecating the existing > definition and moving it to Historic if it were in a stand-alone > document. Perhaps, if you want to go down this path, you > should think about a new "ftpanon" URI that would incorporate > these capabilities (and maybe one or two more, see below), drop > from the syntax entirely (always send "anonymous" > and then respond to any password prompt based on what it says), > and so on. If you did that, it would make sense to have the > document also update 1738 to deprecate its definition of an FTP > URI (or to have a discussion with the IESG about whether the > "obsoleted by" status of 1738 already accomplished that), which > I assume is part of your objective. I really consider a number if technical omissions in the document. However, spontaneous deprecation of the 'ftp' scheme which is currently used and introducing the new 'ftp' URI scheme which no one has heard about isn't a good option (see Section 2.1 of RFC 4395). My proposal for experimentation is probably a solution. Let's proceed with this document first, and then undertake an effort to produce a completely new specification, first experimental, and then if success, deprecate this scheme entirely and move that experimental to Standard Track (see http://www.ietf.org/mail-archive/web/ftpext/current/msg00302.html). I really don't think 'ftpanon' scheme may be useful. It is inappropriate to create several schemes for one protocol (unless it is a secured variant, which is the "current practice"). Having the "userinfo" in the URI scheme for FTP is better that deprecating it since might decrease the possibilities (and, thus, usefulness) of such scheme. > (2) In a world in which a lot of servers (maybe a majority) run > Linux or flavors of Unix and many client machines run something > else and get confused when trying to interpret files with > LF-only line terminations as text), I still believe that support > for TYPE is critical, even in a the stripped-down "ftpanon" URI > concept but certainly with a full FTP URI. Leaving the type-code part will probably create a precedent - why do we provide the possibility to denote use of the only one option in the URI. If type-code is retained, we should provide the extension mechanism and make type-code a part of it. But see below. > (3) To the extent to which the FTPEXT2 WG is actually doing > anything, a full FTP URI needs to consider the changes that are > being made there, or at least to have a mechanism for being > extended to recognize additional commands and keywords. Again, > reducing your expectations to what I describe above as an > "ftpanon" URI would eliminate at least most of that problem. If > you want a general FTP URI, I think that WG should carefully > review the spec once it has drained its queue of > charter-specified pending work. Extension mechanism is really necessary. Yet, if we try to describe the scheme as it is currently used there is no place for it here. Of course, if we agree to undertake the effort to produce a completely new scheme specification, extension mechanism will be a must there. But not now. > (4) If your goal is not really to define a URI but to describe > the way in which the "ftp" URI is being used today, that would > be ok as an Informational document. But, to the extent to which > what the description did or did not include constituted a known > technical omission or defect, that document would be > inappropriate for standards track. I agree with Martin here. It's better to have what is currently used on Standards Track rather something invented for the first time. RFC 2026, Section 4.1.1: > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, > > [ . . . ] > > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > (5) It in just a nit compared to the above, but I can find > absolutely nothing in this specification that updates RFC 959 in > any way. I think updating RFC 959 is to reflect that we introduce (in fact, document) one of the protocol elements for FTP. Mykyta > All just my opinion, of course. > > john > > From evnikita2@gmail.com Mon Jun 20 02:55:44 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D7411E80D4; Mon, 20 Jun 2011 02:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.323 X-Spam-Level: X-Spam-Status: No, score=-4.323 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taHAFu4+tVZx; Mon, 20 Jun 2011 02:55:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75E3511E80D0; Mon, 20 Jun 2011 02:55:43 -0700 (PDT) Received: by yxt33 with SMTP id 33so3534254yxt.31 for ; Mon, 20 Jun 2011 02:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=pW8cZdLrAa7EA7zyD5jND8FopdwUNfqnHuW4wF6kAfI=; b=GlpQGBSn3idOOgnyuyRoDp1K3Z4XqDW7G2me/QGa0f8DeRptXFyDYr3IJdZmqWHChV ykbpRtjBHebYvtKwCoeq+xrsLtqatHPh2QOWnyOocd9sR0Ec+1hbylLfhpoXpzAKuSg2 FDdoClBfv4NRZMQUHTRhQ4PwZZABdflvOSTnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=qDNUOTw0MrbItRHPGk9v70TiIpwnHNUcRDBUWOh+d5j7qgFTQ1JrOBfv5JBHSEgZfx sIi527bmOCGnBBPuixYjDlAXGBh+fmHQJNe1c03Xe6NrL5ltS6x6lAEajpLxVleOHCpj /lfGJ/E8wLAARHYLs7MM6FNCaUN+AfKc/GGIs= Received: by 10.236.187.98 with SMTP id x62mr7183463yhm.238.1308563742429; Mon, 20 Jun 2011 02:55:42 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id o47sm3408480yhn.58.2011.06.20.02.55.39 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 02:55:41 -0700 (PDT) Message-ID: <4DFF194B.6080002@gmail.com> Date: Mon, 20 Jun 2011 12:56:27 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <4DFD839A.6010601@gmail.com> <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> <4DFF0759.6@it.aoyama.ac.jp> In-Reply-To: <4DFF0759.6@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="------------090202070802000000080506" Cc: ftpext@ietf.org, uri-review@ietf.org Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 09:55:45 -0000 This is a multi-part message in MIME format. --------------090202070802000000080506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 20.06.2011 11:39, "Martin J. Dürst" wrote: > Hello John, > > [ . . . ] > > With that, I don't want to necessarily say that I would disagree with > what you wrote e.g. specifically about the TYPE parameter. I may argue whether type-code part is really useful in the scheme. I've checked the behavior of the browsers with regard to this part. The results: * Firefox 4.0.1 (with no FTP-related addons): seems to ignore. ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt;type=aft has to return 500 (checked; see below), but it doesn't. The same is with ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt;type=f (F type-code isn't specified yet). * Google Chrome 12.0: the same. * Safari 3.2.1: the same. * IE 8: handles ";type=a" or ";type=i"; URIs with other one-letter type-codes are not resolved at all; if type-code has more than one letter - ignores. I've also checked this with 2 FTP clients. * FireZilla 3.3.2. Type-code part is simply handled as a part of a path resulting in URI ftp://ftp.rfc-editor.org/in-notes/;type=a being interpreted as: > Status: Resolving address of ftp.rfc-editor.org > Status: Connecting to 64.170.98.47:21... > Status: Connection established, waiting for welcome message... > Response: 220 "FTP Server Ready" > Command: USER anonymous > Response: 331 Please specify the password. > Command: PASS ************** > Response: 230 Login successful. > Command: OPTS UTF8 ON > Response: 200 Always in UTF8 mode. > Status: Connected > Status: Retrieving directory listing... > Command: CWD /in-notes/;type=a > Response: 550 Failed to change directory. > Command: PWD > Response: 257 "/" > Status: Directory listing successful * SmartFTP 4.0: the same. FYI: bare Telnet connection to the server for checking TYPE command: http://i51.tinypic.com/21b10jt.jpg So defining the scheme as currently used requires the deprecating the type-code part, I'm convinced. It is mostly useless. > But I very strongly think that this and other details have to be > argued on their merits, rather than on a on the base of a non-existing > principle of "if it's in the protocol, it has to be in the URI scheme". Agreed here. Mykyta > > Regards, Martin. > > > > On 2011/06/19 23:38, John C Klensin wrote: >> >> >> --On Sunday, June 19, 2011 08:05 +0300 Mykyta Yevstifeyev >> wrote: >> >>> Hello, >>> >>> After working on the document a bit, I've submitted a new >>> version of draft-yevstifeyev-ftp-uri-scheme-02: >>> >>> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-02 >>> >>> The differences from -01 are at >>> http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-s >>> cheme-02.txt >>> >>> I personally believe the document is almost ready, yet, I'd >>> like to seek more community comments (if any) on it. >> >> First of all, I appreciate the many improvements in this >> document. Most of my difficulties with the earlier version >> remain and, as a result, I don't think we are at "almost ready". >> For example: >> >> (1) Regardless of what was done in RFC 1738, if something is >> going to be called an "FTP" URI, it should reflect the FTP >> protocol is a serious and comprehensive way. Failure to do so >> is, IMO, a "known technical omission" and, using logic you have >> used in other contexts, would require deprecating the existing >> definition and moving it to Historic if it were in a stand-alone >> document. Perhaps, if you want to go down this path, you >> should think about a new "ftpanon" URI that would incorporate >> these capabilities (and maybe one or two more, see below), drop >> from the syntax entirely (always send "anonymous" >> and then respond to any password prompt based on what it says), >> and so on. If you did that, it would make sense to have the >> document also update 1738 to deprecate its definition of an FTP >> URI (or to have a discussion with the IESG about whether the >> "obsoleted by" status of 1738 already accomplished that), which >> I assume is part of your objective. >> >> (2) In a world in which a lot of servers (maybe a majority) run >> Linux or flavors of Unix and many client machines run something >> else and get confused when trying to interpret files with >> LF-only line terminations as text), I still believe that support >> for TYPE is critical, even in a the stripped-down "ftpanon" URI >> concept but certainly with a full FTP URI. >> >> (3) To the extent to which the FTPEXT2 WG is actually doing >> anything, a full FTP URI needs to consider the changes that are >> being made there, or at least to have a mechanism for being >> extended to recognize additional commands and keywords. Again, >> reducing your expectations to what I describe above as an >> "ftpanon" URI would eliminate at least most of that problem. If >> you want a general FTP URI, I think that WG should carefully >> review the spec once it has drained its queue of >> charter-specified pending work. >> >> (4) If your goal is not really to define a URI but to describe >> the way in which the "ftp" URI is being used today, that would >> be ok as an Informational document. But, to the extent to which >> what the description did or did not include constituted a known >> technical omission or defect, that document would be >> inappropriate for standards track. >> >> (5) It in just a nit compared to the above, but I can find >> absolutely nothing in this specification that updates RFC 959 in >> any way. >> >> All just my opinion, of course. >> >> john >> >> _______________________________________________ >> Uri-review mailing list >> Uri-review@ietf.org >> https://www.ietf.org/mailman/listinfo/uri-review >> > --------------090202070802000000080506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 20.06.2011 11:39, "Martin J. Dürst" wrote:
Hello John,

[ . . . ]

With that, I don't want to necessarily say that I would disagree with what you wrote e.g. specifically about the TYPE parameter.
I may argue whether type-code part is really useful in the scheme.  I've checked the behavior of the browsers with regard to this part.  The results:


I've also checked this with 2 FTP clients. 


Status:    Resolving address of ftp.rfc-editor.org
Status:    Connecting to 64.170.98.47:21...
Status:    Connection established, waiting for welcome message...
Response:   220 "FTP Server Ready"
Command:    USER anonymous
Response:   331 Please specify the password.
Command:    PASS **************
Response:   230 Login successful.
Command:    OPTS UTF8 ON
Response:   200 Always in UTF8 mode.
Status:    Connected
Status:    Retrieving directory listing...
Command:    CWD /in-notes/;type=a
Response:   550 Failed to change directory.
Command:    PWD
Response:   257 "/"
Status:    Directory listing successful
  • SmartFTP 4.0: the same.
FYI: bare Telnet connection to the server for checking TYPE command: http://i51.tinypic.com/21b10jt.jpg

So defining the scheme as currently used requires the deprecating the type-code part, I'm convinced.  It is mostly useless.

But I very strongly think that this and other details have to be argued on their merits, rather than on a on the base of a non-existing principle of "if it's in the protocol, it has to be in the URI scheme".
Agreed here.

Mykyta

Regards,   Martin.



On 2011/06/19 23:38, John C Klensin wrote:


--On Sunday, June 19, 2011 08:05 +0300 Mykyta Yevstifeyev
<evnikita2@gmail.com>  wrote:

Hello,

After working on the document a bit, I've submitted a new
version of draft-yevstifeyev-ftp-uri-scheme-02:

http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-02

The differences from -01 are at
http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-s
cheme-02.txt

I personally believe the document is almost ready, yet, I'd
like to seek more community comments (if any) on it.

First of all, I appreciate the many improvements in this
document.  Most of my difficulties with the earlier version
remain and, as a result, I don't think we are at "almost ready".
For example:

(1) Regardless of what was done in RFC 1738, if something is
going to be called an "FTP" URI, it should reflect the FTP
protocol is a serious and comprehensive way.   Failure to do so
is, IMO, a "known technical omission" and, using logic you have
used in other contexts, would require deprecating the existing
definition and moving it to Historic if it were in a stand-alone
document.   Perhaps, if you want to go down this path, you
should think about a new "ftpanon" URI that would incorporate
these capabilities (and maybe one or two more, see below), drop
<user-pass>  from the syntax entirely (always send "anonymous"
and then respond to any password prompt based on what it says),
and so on.   If you did that, it would make sense to have the
document also update 1738 to deprecate its definition of an FTP
URI (or to have a discussion with the IESG about whether the
"obsoleted by" status of 1738 already accomplished that), which
I assume is part of your objective.

(2) In a world in which a lot of servers (maybe a majority) run
Linux or flavors of Unix and many client machines run something
else and get confused when trying to interpret files with
LF-only line terminations as text), I still believe that support
for TYPE is critical, even in a the stripped-down "ftpanon" URI
concept but certainly with a full FTP URI.

(3) To the extent to which the FTPEXT2 WG is actually doing
anything, a full FTP URI needs to consider the changes that are
being made there, or at least to have a mechanism for being
extended to recognize additional commands and keywords.   Again,
reducing your expectations to what I describe above as an
"ftpanon" URI would eliminate at least most of that problem.  If
you want a general FTP URI, I think that WG should carefully
review the spec once it has drained its queue of
charter-specified pending work.

(4) If your goal is not really to define a URI but to describe
the way in which the "ftp" URI is being used today, that would
be ok as an Informational document.  But, to the extent to which
what the description did or did not include constituted a known
technical omission or defect, that document would be
inappropriate for standards track.

(5) It in just a nit compared to the above, but I can find
absolutely nothing in this specification that updates RFC 959 in
any way.

All just my opinion, of course.

     john

_______________________________________________
Uri-review mailing list
Uri-review@ietf.org
https://www.ietf.org/mailman/listinfo/uri-review



--------------090202070802000000080506-- From duerst@it.aoyama.ac.jp Mon Jun 20 01:40:17 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF6011E8114 for ; Mon, 20 Jun 2011 01:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.93 X-Spam-Level: X-Spam-Status: No, score=-99.93 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvMOBZ5M25TC for ; Mon, 20 Jun 2011 01:40:16 -0700 (PDT) Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 201D511E80E9 for ; Mon, 20 Jun 2011 01:40:15 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p5K8eAd3000435 for ; Mon, 20 Jun 2011 17:40:10 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 33c6_1d50_e8b8505a_9b18_11e0_83e8_001d0969ab06; Mon, 20 Jun 2011 17:40:10 +0900 Received: from [IPv6:::1] ([133.2.210.5]:59388) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 20 Jun 2011 17:40:05 +0900 Message-ID: <4DFF0759.6@it.aoyama.ac.jp> Date: Mon, 20 Jun 2011 17:39:53 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <4DFD839A.6010601@gmail.com> <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> In-Reply-To: <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Jun 2011 05:09:22 -0700 Cc: ftpext@ietf.org, uri-review@ietf.org Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:40:17 -0000 Hello John, I'm not at all an expert in FTP, nor in the details of the current ftp: URI implementations. But the overall direction of your mail seems to be "if it's in the FTP protocol, then it has to be in the ftp URI scheme". In my eyes, that's just a non sequitur. If you look at HTTP, there are a lot of bits and pieces that are in the protocol but are not in the URI scheme, for good reasons. If you look at the mailto: URI scheme, then there are also a lot of features in SMTP and in the message format that are not available in the scheme. In fact for the mailto: scheme, in my understanding, the header part of the message format is now covered, but it was the spec that caught up with implementations, not the other way round. Also, to claim that a spec that describes what's currently implemented (let's assume it does) can only go to informational, and that for standards track, it's necessary to cover all the features in the base protocol is totally new to me. As far as I understand it, the IETF is first and foremost about "rough consensus and running code" and only later about "known technical omissions". With that, I don't want to necessarily say that I would disagree with what you wrote e.g. specifically about the TYPE parameter. But I very strongly think that this and other details have to be argued on their merits, rather than on a on the base of a non-existing principle of "if it's in the protocol, it has to be in the URI scheme". Regards, Martin. On 2011/06/19 23:38, John C Klensin wrote: > > > --On Sunday, June 19, 2011 08:05 +0300 Mykyta Yevstifeyev > wrote: > >> Hello, >> >> After working on the document a bit, I've submitted a new >> version of draft-yevstifeyev-ftp-uri-scheme-02: >> >> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-02 >> >> The differences from -01 are at >> http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-s >> cheme-02.txt >> >> I personally believe the document is almost ready, yet, I'd >> like to seek more community comments (if any) on it. > > First of all, I appreciate the many improvements in this > document. Most of my difficulties with the earlier version > remain and, as a result, I don't think we are at "almost ready". > For example: > > (1) Regardless of what was done in RFC 1738, if something is > going to be called an "FTP" URI, it should reflect the FTP > protocol is a serious and comprehensive way. Failure to do so > is, IMO, a "known technical omission" and, using logic you have > used in other contexts, would require deprecating the existing > definition and moving it to Historic if it were in a stand-alone > document. Perhaps, if you want to go down this path, you > should think about a new "ftpanon" URI that would incorporate > these capabilities (and maybe one or two more, see below), drop > from the syntax entirely (always send "anonymous" > and then respond to any password prompt based on what it says), > and so on. If you did that, it would make sense to have the > document also update 1738 to deprecate its definition of an FTP > URI (or to have a discussion with the IESG about whether the > "obsoleted by" status of 1738 already accomplished that), which > I assume is part of your objective. > > (2) In a world in which a lot of servers (maybe a majority) run > Linux or flavors of Unix and many client machines run something > else and get confused when trying to interpret files with > LF-only line terminations as text), I still believe that support > for TYPE is critical, even in a the stripped-down "ftpanon" URI > concept but certainly with a full FTP URI. > > (3) To the extent to which the FTPEXT2 WG is actually doing > anything, a full FTP URI needs to consider the changes that are > being made there, or at least to have a mechanism for being > extended to recognize additional commands and keywords. Again, > reducing your expectations to what I describe above as an > "ftpanon" URI would eliminate at least most of that problem. If > you want a general FTP URI, I think that WG should carefully > review the spec once it has drained its queue of > charter-specified pending work. > > (4) If your goal is not really to define a URI but to describe > the way in which the "ftp" URI is being used today, that would > be ok as an Informational document. But, to the extent to which > what the description did or did not include constituted a known > technical omission or defect, that document would be > inappropriate for standards track. > > (5) It in just a nit compared to the above, but I can find > absolutely nothing in this specification that updates RFC 959 in > any way. > > All just my opinion, of course. > > john > > _______________________________________________ > Uri-review mailing list > Uri-review@ietf.org > https://www.ietf.org/mailman/listinfo/uri-review > From john-ietf@jck.com Mon Jun 20 05:13:56 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AD711E807A; Mon, 20 Jun 2011 05:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.584 X-Spam-Level: X-Spam-Status: No, score=-101.584 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOEz82GRmwkO; Mon, 20 Jun 2011 05:13:55 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id B091211E8078; Mon, 20 Jun 2011 05:13:54 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QYdMT-0005lm-Jh; Mon, 20 Jun 2011 08:13:50 -0400 Date: Mon, 20 Jun 2011 08:13:41 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <3AFED76CBFF900979DE770F6@PST.JCK.COM> In-Reply-To: <4DFF0759.6@it.aoyama.ac.jp> References: <4DFD839A.6010601@gmail.com> <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> <4DFF0759.6@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: ftpext@ietf.org, uri-review@ietf.org Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:13:56 -0000 --On Monday, June 20, 2011 17:39 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: > Hello John, >=20 > I'm not at all an expert in FTP, nor in the details of the > current ftp: URI implementations. But the overall direction of > your mail seems to be > "if it's in the FTP protocol, then it has to be in the ftp URI > scheme". Not really what I'm saying. I just think that an FTP URI has to be sensitive to FTP usage and the way the protocol actually works. At least IMO, a poor job was done of that in 1738; if one proposes a standalone, standards-track FTP URI today, I'm going to do parts of that analysis and then keep repeating "known technical omission". As far as the extensions are concerned, I imagine that some of them are important and some are not. Since both the URI review and FTPEXT2 mailing lists are being copied on this, I suggest that the latter ought to be considering whether, if a given extension is not important enough to be included in the URI, it is really worth the trouble as an extension. I can well imagine the answer for some extensions being "not important enough for the URI but still worth doing", but I think that is a discussion the WG needs to have". =20 Three examples of the "known technical omission" problem:=20 (i) At least historically, the most-used command in the FTP protocol, other than the basic authentication ones (USER, PASS), CWD and PWD and the basic ones actually involved in transferring files (RETR, STOR, and probably PASV) has been TYPE. It is not like, e.g., STRU or the file structuring commands, which many people and servers can go for many years without ever seeing. TYPE was really important in the early days of the net when we not only had EBCDIC floating around, but had at least three different ways to encode ASCII. A decade and a half ago, only the CRLF issue remained and, if examined from a narrow web perspective (see below), it doesn't make much difference (the number of problems it causes every year, with lusers not understanding the symptoms and a distinct shortage of standard, user-accessible, conversion utilities on most systems, remains non-trivial). It gets more important again as we see more and more files in non-ASCII character sets, both Unicode and non-Unicode. Even with the former alone, an IMAGE transfer may yield any of more than a half-dozen forms (see draft-ietf-appsawg-3536bis for a list that still does not include the obscure ones). So, to me, saying "TYPE" is not needed or should be treated like any other extension indicates a lack of understanding of the underlying protocol. (2) There is currently a proposal in the FTPEXT2 WG to add a HOST command to FTP (draft-ietf-ftpext2-hosts) for exactly the same reason we needed to add one to HTTP. I'm personally not a fan of that particular way of doing the job, but one of the strong arguments for it is that it could potentially be automated in a shim or API that connects an FTP URI processor to the FTP protocol as "always send HOST, if it is rejected as not recognized, ignore and pretend it wasn't sent". But, if we think HOST is important, that needs to be considered and explicitly discussed in any FTP URI document. If it isn't important enough to be considered and discussed, then the extension probably isn't important enough to adopt and use. Since the WG hasn't acted on the proposal, the issue is somewhat forward-looking, but that puts the current FTP URI proposal in the same boat as MAILTO -- it is hard to define a URI for a protocol to which it is not integral and has to be retrofitted when the protocol itself is being changed/extended in ways that should rationally affect the URI. (3) For obvious security reasons, username-password pairs ceased being popular around the IETF many years ago. Username-password pairs embedded in URIs in clear text are much worse. Some of the extensions you (and Mykyta) dismiss provide ways around that problem. In addition, for the very popular 'anonymous' use of FTP, we know what the password patterns are: a reserved/known keyword, such as "guest"; an email address; or "server simply doesn't care what is sent". That could be built into the URI-interpreting protocol interface mechanism as well, but the current document circles around it with a lot of handwaving. Note that neither (2) nor (3) would require any changes to the URI or its syntax, only a specification that understood the FTP protocol and its use much better. > In my eyes, that's just a non sequitur. If you look at HTTP, > there are a lot of bits and pieces that are in the protocol > but are not in the URI scheme, for good reasons.=20 Sure. I trust I don't need to point out to you either that URLs and HTTP were designed together for use with each other and that most of the decisions as to what was left out were made after careful consideration, not by accident and in haste (and, for the record, I'm criticizing 1739, not Mykyta's proposal). > If you look > at the mailto: URI scheme, then there are also a lot of > features in SMTP and in the message format that are not > available in the scheme. In fact for the mailto: scheme, in my > understanding, the header part of the message format is now > covered, but it was the spec that caught up with > implementations, not the other way round. And the mailto: spec is also an example of the difficulties one can get into when one naively retrofits a URI on top of an established and widely-deployed protocol. > Also, to claim that a spec that describes what's currently > implemented (let's assume it does) can only go to > informational, and that for standards track, it's necessary to > cover all the features in the base protocol is totally new to > me. As far as I understand it, the IETF is first and foremost > about "rough consensus and running code" and only later about > "known technical omissions". Informational documents that describe something as already deployed and unlikely to change are actually common and are written with the understanding that the IETF has little to offer in terms of adding value to the protocol other than to document it. For standards track, I invite you to read 2026, where "known technical omissions" is one of the few clear bars to adopting a Proposed Standard. > With that, I don't want to necessarily say that I would > disagree with what you wrote e.g. specifically about the TYPE > parameter. But I very strongly think that this and other > details have to be argued on their merits, rather than on a on > the base of a non-existing principle of "if it's in the > protocol, it has to be in the URI scheme". See above. I'm not arguing "if it's in the protocol, it has to be in the URI scheme". I'm arguing precisely for some careful consideration on a case-by-case basis and against a different non-existent principle of "if it was omitted from RFF 1738, we don't need it". regards, john From daniel@haxx.se Mon Jun 20 05:30:40 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D81A9E801A; Mon, 20 Jun 2011 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo8w91t62GQ0; Mon, 20 Jun 2011 05:30:39 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id DF5BF9E801E; Mon, 20 Jun 2011 05:30:38 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id p5KCUSsQ024879; Mon, 20 Jun 2011 14:30:28 +0200 Date: Mon, 20 Jun 2011 14:30:28 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mykyta Yevstifeyev In-Reply-To: <4DFF194B.6080002@gmail.com> Message-ID: References: <4DFD839A.6010601@gmail.com> <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> <4DFF0759.6@it.aoyama.ac.jp> <4DFF194B.6080002@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.8 (giant.haxx.se [80.67.6.50]); Mon, 20 Jun 2011 14:30:28 +0200 (CEST) Cc: =?ISO-8859-15?Q?Martin_J=2E_D=FCrst?= , uri-review@ietf.org, ftpext@ietf.org Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:30:40 -0000 On Mon, 20 Jun 2011, Mykyta Yevstifeyev wrote: > I've also checked this with 2 FTP clients. As a counter-example: curl has supported type= in FTP URLs since many years. Even sent over HTTP proxies when a FTP URL using type= was used and a HTTP proxy is specified, and I know there are HTTP proxies that deal with it properly. -- / daniel.haxx.se From internet-drafts@ietf.org Mon Jun 20 09:06:31 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ECB1F0C4E; Mon, 20 Jun 2011 09:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAtmtyftikEB; Mon, 20 Jun 2011 09:06:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC9F1F0C36; Mon, 20 Jun 2011 09:06:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620160631.14534.46793.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 09:06:31 -0700 Cc: ftpext@ietf.org Subject: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-01.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:06:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FTP Extensions, 2nd edition Working G= roup of the IETF. Title : FTP Extension for Internationalized Text Author(s) : John C Klensin Filename : draft-ietf-ftpext2-typeu-01.txt Pages : 9 Date : 2011-06-20 The original FTP protocol supported TYPE values for ASCII and EBCDIC text, plus binary ("IMAGE") transmission. As the Internet bec= omes more international, there is a growing requirement to be able to transmit textual data, encoded in Unicode, in a way that is independent of the coding and line representation forms of particular operating systems. This memo specifies a new FTP TYPE value for Unicode data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ftpext2-typeu-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext2-typeu-01.txt From rto@globalscape.com Mon Jun 20 13:33:26 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272BC11E8097 for ; Mon, 20 Jun 2011 13:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3nWIF+t7f1G for ; Mon, 20 Jun 2011 13:33:24 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5418F11E808E for ; Mon, 20 Jun 2011 13:33:24 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Mon, 20 Jun 2011 15:33:23 -0500 From: Robert Oslin To: John C Klensin , "ftpext@ietf.org" Date: Mon, 20 Jun 2011 15:33:22 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: AcwtX9L+8jbJpaJmSuaCffI9RjO5YgB7rDTg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:33:26 -0000 >>ASCII is a lot easier ... Noted. >>I usually take the position of an FTP purist whose relationship with the = protocol goes all the way back to some of the original design meetings. I greatly appreciate the academic "FTP purist" viewpoint. I am coming at th= is from a purely tactical and practical angle, i.e. we have millions of use= rs and businesses worldwide using our FTP client and server products that a= re regularly performing multi-part uploads. My goal is to formalize (and po= tentially improve) the process so that other vendors can extend this existi= ng benefit to their users, ideally in a non-proprietary fashion, much like = our proprietary XCRC command which has been used for performing integrity c= hecking for years and is now finally being formalized as the HASH command (= albeit with many improvements) by Mr. Anthony Bryan, for the benefit of the= entire FTP client/server vendor and user community. >>I think you intend that COMB cause the transfer and then the combining fu= nction Originally that was not my intent. Presently COMB is nothing more than an o= peration for combining a unique set of files. My original intent was for th= e client process to determine whether to perform a multi-part transfer and = for the client to use its own programmatic logic to determine byte offsets = and what not, and then issue multiple parallel STOR commands for each part = over discreet data channels. As far as the server was concerned these were = unique (whole) file uploads. Only the client knew that those uploads were a= ctually parts of larger file or not. See notes on (4) for more information. >>You need to be extremely careful with concepts like "file path" and "dire= ctory path". Agreed. >>(3) Your use of quotes is un-FTP-ish and your command makes assumptions a= bout the syntax of a name that is not local to the working directory on the= server-FTP. Thanks. This may be a moot point though. See notes on (4) >>Note that the second is seriously pathological given your "spaces not nee= ded" rule. Agreed. >>(4) Remembering that we originally intended FTP to be asynchronous betwee= n the command and data streams, it may be too late now, but the FTP-ish way= to do this probably would have been something like: CWD wherever-you-want-this-to-end-up BOMPT (Begin-Odd-Multipart-Transfer) PASV (or PORT, here and below) STRU local-name PASV STRU local-name PASV STRU local-name ... COMBine remote-name I don't think it is too late, given the early stages of this draft, but yes= from a practical standpoint it would require that vendors who are using CO= MB in its current incarnation to update their products; however it may be p= ossible to both improve upon the design and grandfather the current design. >>The STRU commands would presumably all get 2yz replies specifying the nam= e used or failure codes permitting something else to be done. The server w= ould be required to return those STRU replies in order even if the transfer= s finished out of order. Unfortunately my knowledge of the STRU command is quite limited. I don't se= e (in any RFC) where a local-name value can be provided as an argument. Per= haps you mean STOU (store unique), or is there a way in which STRU is used = that I'm totally missing? >>Note that not only specifies completely separate and parallel data connec= tions (rather than maybe trying to share a single TCP data stream), but, by= using initiation and competition commands and letting the server keep trac= k of its own part names, it completely eliminates the quotes, hoping the p= ath syntax on the local or remote systems matches whatever you've assumed, = and, by using STRU, eliminates both the need to be sure that the part names= chosen on the sender machine are available on the receiver one and a small= potential security problem. It also permits use of REST, etc., on the ind= ividual streams if needed. I agree with the concept of initiation and completion commands. That was wh= at I was referring to when I wrote in a prior message "I missed something v= ery important in the draft that that will require a bit of draft re-work". = I believe a preparatory command is needed in order to alert the server of t= he client's intent, although my motives are slightly different from yours: = I wanted to provide the server with all necessary information needed to (op= tionally) employ advanced combine techniques, such as streaming the combine= process vs. post transfer combine. Here is what I was going to propose, ex= cept that I failed to consider STOU, which appears superior to STOR in that= STOU eliminates the need for temporary filenames managed by the client (in= stead, as you indicated, allowing the 2zy reply could include the temporary= unique name managed by the server. Example: CWD wherever-you-want-this-to-end-up BMPT remote-name, number-of-parts, original-size-in-bytes PASV (or PORT, here and below) STOU local-name (chunk1) PASV STOU local-name (chunk2) PASV STOU local-name (chunk3) ... COMB remote-name Here is how my proposed logic differs (but only slightly) from yours: 1. Use of four letter command name for the prepare portion, call it BMPT, P= REP, or whatever. 2. The prepare command needs to provide sufficient information to the remot= e server so that advanced file combine techniques can be used, whether use = of scratch or reserved temporary space, or sequence of blocks, or whatever.= In our case (since we are thinking sparse files), the server needs to know= the name of the destination file, the number of bytes, and total parts tha= t will be transferred. With this information the server can deduce each of = the part sizes that will subsequently be sent by the client, and therefore = where the server should begin writing each byte offset within the sparse fi= le. For other techniques there may be more or less information required; ho= wever I cannot think of any additional parameters aside from size and numbe= r of expected parts at the moment. 3. STOU instead of STRU used (which is what I believe you meant). 4. The one concern I have with NOT providing the client-managed individual = part names in the preparatory command or in each STOR command is that it is= possible for the order of the parts to be received out of sequence. Rememb= er that the client will likely open up multiple data streams in parallel fa= shion (or nearly so), and the server might not handle them in the order rec= eived, hence the server would not know at which byte offset to begin writin= g each part received (i.e. is this part the beginning of the sparse file, s= omewhere in the middle, end of file, etc.). I believe the way to overcome t= his problem is for the client to not begin sending each subsequent part unt= il it has received a 1xx reply from the server indicating that the server h= as accepted the STOU command, opened a data channel, and recognized it as p= art X of Y (Y being the number of parts communicated in the BMPT command). = Once the 1xx reply is received the client would spawn a new thread and issu= e the next STOU command. Ideally (depending on latency and such), each part= would be initiated within a second or two from each prior part and only af= ter the initiation of the transfer has been recognized by the server. What = I have NOT addressed in this email is problems such as a started MP transfe= r but not all parts are sent, aborted transfers, and inter-session transfer= s (started MP but lost connection and some parts still remain or were parti= ally transferred). 5. The other problem is when the client has multiple multi-part and standar= d (single-part) transfers initiated in parallel. I.e. what happens if I sen= d two files using 8 parts and another smaller file using no parts (standard= transfer) at the same time. This is a likely scenario, given current clien= t's multi-threaded capabilities. What we don't want is the server confusin= g transfers and assigning wrong parts to wrong files. Yes, keeping the STOU= commands identical for each unique source filename makes a lot = of sense, but how does the server know which BMPT command to associate with= the subsequent STOU commands? Assuming parallelism but showing both logs c= ombined, in chronological order: BMPT blah.dat, 4, 2235478 BMPT blah2.dat, 4, 2431234 STOU A.dat STOU A.dat STOU B.dat STOU A.dat STOU B.dat STOU A.dat STOU B.dat STOU B.dat COMB blah.dat COMB blah2.dat Notice here that the server will have received sequential (back to back) BM= PT (preparatory) commands, followed by back-to-back STOU commands. There ne= eds to be a way for the server to identify which batch of STOU commands bel= ong to which BMTP command. I think the way to solve this problem is to require that the val= ue provided in the preparatory command (BMPT in this example) match the fil= ename provided in the STOU commands (and vice versa). The user could always= rename the file later if desired, e.g. BMPT A.dat, 4, 2235478 BMPT B.dat, 4, 2431234 STOU A.dat STOU A.dat STOU B.dat STOU A.dat STOU B.dat STOU A.dat STOU B.dat STOU B.dat COMB A.dat COMB B.dat RNFR A.dat RNTO blah.dat RNFR B.dat RNTO blah2.dat Let me make one more point here: Depending on the combine techniques used b= ye server, the COMB command may not be of any use other than to indicate to= the server that it (the client) is done transferring all parts, kind of li= ke a "hey, I'm done now, did you get everything and combine ok?", to which = the server would reply in the affirmative if for example the sparse file ha= d filled out and all bytes were accounted for. If the server received the c= ommand but something was missing or there were others errors somewhere alon= g the combine process, the server would reply with a transitive negative co= mpletion reply (hey, send me the last part again), or permanent negative co= mpletion reply (the bytes received don't match what the preparatory command= said I was going to receive, therefore COMB failed"). Likewise the COMB co= mmand could retain it's original syntax for backwards compatibility, i.e. i= f the server receives a COMB command that wasn't preceded by a preparatory = BMPT command, then it will expect the COMB command to supply all necessary = parameters (dst name, part1, part2, etc.) which means I still need to solve= the naming/syntax issues. Here is an example of a complete sequence (less CWD and PASV/PORT mode oper= ations) that helps summarize what I've stated so far: On Command Channel u> BMPT A.dat, 4, 2235478 s> 200 OK, ready for MP transfer ...(wait for 2yz on the various data channels) u> COMB A.dat s> 200 Combine successful On Data Channel 1 u> STOU A.dat s> 150 Data connection opened for A.dat as part 1 of 4, ready for next part s> 226 Transfer complete On Data Channel 2 u> STOU A.dat s> 150 Data connection opened for A.dat as part 2 of 4, ready for next part s> 226 Transfer complete On Data Channel 3 u> STOU A.dat s> 150 Data connection opened for A.dat as part 3 of 4, ready for next part s> 226 Transfer complete On Data Channel 4 u> STOU A.dat s> 150 Data connection opened for A.dat as part 4 of 4 s> 226 Transfer complete <--client waits for last part to get 226 reply th= en command channel sends COMB to confirm all is well and recombined. >>The use of STRU in that context would also permit an intelligent FTP-serv= er to use some type of pool (or scratch or reserved temporary) space for th= e intermediate files, copying only the final, reassembled, file into the ta= rget directory. That would eliminate several of the operational or securit= y risks you discuss. Arranging to disassemble the file into pool space on = the client machine (or using the interleaved block approach discussed below= ) would eliminate a number of others. Agreed, which is why sending a preparatory command is so important. We just= need to make sure that all necessary information is provided so that intel= ligent FTP servers can use different techniques for combining the files, wh= ile making sure we avoid potential problemd associated with parallel multi-= part transfers and out-of-sequence sending of parts. >>FWIW, the above model could work rather well in the download direction, e= legantly eliminating the need for odd tricks with the checkpoint/restart me= chanism. Yes it could. Currently we use multiple REST commands at various offsets to= accomplish this, but from an FTP purists perspective, that was ever the in= tended manner for REST to be used. I just don't know if I want to tackle MP= downloads in this draft, given that this problem is already solved, albeit= in a non-elegant manner. >>All of that said, experience with a number of distributed/parallel storag= e systems, including some distributed database update models and RAID strip= ing, would suggest that the most transfer-efficient way to do what you are = trying to accomplish would be to use a completely different model: treat t= he file to be transferred as a sequence of blocks of specified size, open a= bunch of connections, push block 1 onto connection 0, block 2 onto connect= ion 1, and continue with each block, M, going out onto connection (M modulo= number of connections). That would not only permit more optimization but would permit reassembly to= start while the transfer was still in progress. This is how sparse files work and why it is necessary for the client tell t= he server how many parts and total size of bytes (so that it can perform th= e M modulo number of connections calculation on the server side). http://en= .wikipedia.org/wiki/Sparse_file >>(5) Some of the material in 3.3 don't make any sense. If the server "SHO= ULD" or "MAY" send the specified responses, it seems to me that is obligato= ry on you to specify what happens if the server chooses to do something els= e. Presumably it is not open season for anything you don't specify -- I'd = predict severe interoperability problems if a server responded to your 550 = case by returning, e.g., 987. Noted. >>(6) The first two paragraphs of your Security Considerations section are = a little bogus. Providing COMB support only to authorized users, etc., may= protect against certain classes of malicious attacks, but they provide abs= olutely no protection against ignorance, stupidity, or carelessness, any of= which can be easily exploited by an attacker as well as creating risks of = equally-damaging accidents. I think it goes without saying that we can never protect fully against user= ignorance and stupidity. Heck, the DELE command is pretty efficient at des= troying data as well. My notes in #6 are simply the warning labels that rem= ind you not to use your hairdryer in the bathtub. I.e. misuse (or abuse) of= the COMB command can lead to file corruption, which is the same (or worse = in some cases) than the destruction of data using DELE. I do think these wa= rnings are necessary and appropriate, but may change them a bit to match th= e proposed logic changes (which are quite substantial). Thanks John for your feedback. I wish I had thought of the necessary prepar= atory commands BEFORE submitting my first draft, but I suppose that is what= the working group is for - to point out flaws in the design and ways to im= prove, even if it does mean wholesale changes are required. I'll wait until I hear from others and if everyone is on board I'll float a= revamped draft that includes an initiation (preparatory) and completion co= mmand sequence for MP uploads. Robert From sob@nvnet.cz Mon Jun 20 22:08:19 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A7211E81AC for ; Mon, 20 Jun 2011 22:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_CZ=0.445, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIhJ+VCtlsVJ for ; Mon, 20 Jun 2011 22:08:19 -0700 (PDT) Received: from mail.nvnet.cz (mail.nvnet.cz [IPv6:2002:d5d3:2ff6:80::3]) by ietfa.amsl.com (Postfix) with ESMTP id E233511E8081 for ; Mon, 20 Jun 2011 22:08:17 -0700 (PDT) X-AuthUser: sob@nvnet.cz Received: from Sob-PC.nvnet.cz ([213.211.47.246]:56588) by mail.nvnet.cz with [XMail 1.25 ESMTP Server] id for from ; Tue, 21 Jun 2011 07:08:10 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Jun 2011 07:07:50 +0200 To: Anthony Bryan ,ftpext@ietf.org, Daniel Stenberg , Tatsuhiro Tsujikawa From: Sob In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20110621050818.E233511E8081@ietfa.amsl.com> Subject: Re: [ftpext] Single Port FTP X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 05:08:20 -0000 At 01:21 8.6.2011, Anthony Bryan wrote: >fyi, some thoughts on single port FTP (i.e. avoiding opening a >separate data connection by doing data transfers over the control >connection). Draft-bryan-ftp-lock is more "single connection". There's also less heretic "single port, separate connections", now expired draft-rosenau-ftp-single-port. The other draft solves problem that users have all the time. They install FTP server, forward only port 21 from NAT router and then wonder why it doesn't work. Well, it does in active mode, but active mode itself can be problematic when clients are also behind NAT. Your draft solves it too, no problem, it's just that MIME separators don't exactly feel like FTP. Your additional bonus is saving time and resources by not establishing separate data connections. But it could be solved as well by using one permanent MODE B data connection (IIS FTP resurrected this mode recently, but unfortunately clients don't support it). Personally I'd go with the other draft (it seems to be smaller change to how things work now) only with few updates (allow not just MODE S that it currently assumes, add FEAT line, remove strange/confusing section 6). -- From john-ietf@jck.com Tue Jun 21 00:21:01 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A85111E8098 for ; Tue, 21 Jun 2011 00:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.361 X-Spam-Level: X-Spam-Status: No, score=-103.361 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McG-zDFjnPqY for ; Tue, 21 Jun 2011 00:20:59 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id C0F6711E80BC for ; Tue, 21 Jun 2011 00:20:57 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QYvGZ-0000s4-Nf; Tue, 21 Jun 2011 03:20:56 -0400 Date: Tue, 21 Jun 2011 03:20:53 -0400 From: John C Klensin To: Robert Oslin , ftpext@ietf.org Message-ID: <4AD0C916B08DFA1CE8E938E5@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 07:21:01 -0000 --On Monday, June 20, 2011 15:33 -0500 Robert Oslin wrote: >>> ASCII is a lot easier ... > > Noted. > >>> I usually take the position of an FTP purist whose >>> relationship with the protocol goes all the way back to some >>> of the original design meetings. > > I greatly appreciate the academic "FTP purist" viewpoint. I am > coming at this from a purely tactical and practical angle, > i.e. we have millions of users and businesses worldwide using > our FTP client and server products that are regularly >... Part of the question when one brings something to the IETF for standardization is to try to understand what value is added by the process. I'm trying to get you to think about a few things -- if you do, and the conclusion is "impractical given deployed base", I promise to be unhappy but I can live with it. >... >>> (4) Remembering that we originally intended FTP to be >>> asynchronous between the command and data streams, it may be >>> too late now, but the FTP-ish way to do this probably would >>> have been something like: > > CWD wherever-you-want-this-to-end-up > BOMPT (Begin-Odd-Multipart-Transfer) > PASV (or PORT, here and below) > STRU local-name > PASV > STRU local-name > PASV > STRU local-name > ... > COMBine remote-name > > I don't think it is too late, given the early stages of this > draft, but yes from a practical standpoint it would require > that vendors who are using COMB in its current incarnation to > update their products; however it may be possible to both > improve upon the design and grandfather the current design. That is really good news from my point of view. >>> The STRU commands would presumably all get 2yz replies >>> specifying the name used or failure codes permitting >>> something else to be done. The server would be required to >>> return those STRU replies in order even if the transfers >>> finished out of order. > > Unfortunately my knowledge of the STRU command is quite > limited. I don't see (in any RFC) where a local-name value can > be provided as an argument. Perhaps you mean STOU (store > unique), or is there a way in which STRU is used that I'm > totally missing? Nope. I just demonstrated that I should never write from memory when I'm tired and/or preoccupied with other things. STOU was intended. My apologies. >>> Note that not only specifies completely separate and >>> parallel data connections (rather than maybe trying to share >>> a single TCP data stream), but, by using initiation and >>> competition commands and letting the server keep track of >>> its own part names, it completely eliminates the quotes, >>> hoping the path syntax on the local or remote systems >>> matches whatever you've assumed, and, by using STRU, >>> eliminates both the need to be sure that the part names >>> chosen on the sender machine are available on the receiver >>> one and a small potential security problem. It also permits >>> use of REST, etc., on the individual streams if needed. > > I agree with the concept of initiation and completion > commands. Obviously that requires introducing a new state into FTP. At one level, that is a big step. At another... well, maybe not so big and more cleanliness may be important. > That was what I was referring to when I wrote in a > prior message "I missed something very important in the draft > that that will require a bit of draft re-work". I believe a > preparatory command is needed in order to alert the server of > the client's intent, although my motives are slightly > different from yours: I wanted to provide the server with all > necessary information needed to (optionally) employ advanced > combine techniques, such as streaming the combine process vs. > post transfer combine. Here is what I was going to propose, > except that I failed to consider STOU, which appears superior > to STOR in that STOU eliminates the need for temporary > filenames managed by the client (instead, as you indicated, > allowing the 2zy reply could include the temporary unique name > managed by the server. I haven't gone back and checked the spec today, but I think the 2yz reply to STOU is actually required to return the generated/unique name. So nothing new there. > Example: > CWD wherever-you-want-this-to-end-up > BMPT remote-name, number-of-parts, original-size-in-bytes > PASV (or PORT, here and below) > STOU local-name (chunk1) > PASV > STOU local-name (chunk2) > PASV > STOU local-name (chunk3) > ... > COMB remote-name > > Here is how my proposed logic differs (but only slightly) from > yours: > > 1. Use of four letter command name for the prepare portion, > call it BMPT, PREP, or whatever. Of course. You and I haven't worked together, but I'm notoriously bad at picking names and so tend to use things in examples and preliminary proposals that no sane person would actually pick for real use :-) > 2. The prepare command needs to provide sufficient information > to the remote server so that advanced file combine techniques > can be used, whether use of scratch or reserved temporary > space, or sequence of blocks, or whatever. In our case (since > we are thinking sparse files), the server needs to know the > name of the destination file, the number of bytes, and total > parts that will be transferred. With this information the > server can deduce each of the part sizes that will > subsequently be sent by the client, and therefore where the > server should begin writing each byte offset within the sparse > file. For other techniques there may be more or less > information required; however I cannot think of any additional > parameters aside from size and number of expected parts at the > moment. Interesting. I need to think about this more, but my sense is that your model would work well with some media in which it is possible to write from several positions in a "file" at more or less the same time and badly when that was not the case. I remember long ago having to worry about FTP transfers writing directly to tape on the target systems, for which that would be a terrible model and one would need to buffer, assemble, and then write instead. Perhaps we have reached the point where purely sequential devices aren't worth worrying about any more, but I'd like to think about it a bit. > 3. STOU instead of STRU used (which is what I believe you > meant). yes > 4. The one concern I have with NOT providing the > client-managed individual part names in the preparatory > command or in each STOR command is that it is possible for the > order of the parts to be received out of sequence. Remember > that the client will likely open up multiple data streams in > parallel fashion (or nearly so), and the server might not > handle them in the order received, hence the server would not > know at which byte offset to begin writing each part received > (i.e. is this part the beginning of the sparse file, somewhere > in the middle, end of file, etc.). I believe the way to > overcome this problem is for the client to not begin sending > each subsequent part until it has received a 1xx reply from > the server indicating that the server has accepted the STOU > command, opened a data channel, and recognized it as part X of > Y (Y being the number of parts communicated in the BMPT > command). Once the 1xx reply is received the client would > spawn a new thread and issue the next STOU command. Ideally > (depending on latency and such), each part would be initiated > within a second or two from each prior part and only after the > initiation of the transfer has been recognized by the server. > What I have NOT addressed in this email is problems such as a > started MP transfer but not all parts are sent, aborted > transfers, and inter-session transfers (started MP but lost > connection and some parts still remain or were partially > transferred). Right. The other slightly-problematic issue is when other FTP commands change the format or encoding of the file on the source system into a network-standard form, possibly to be converted to something else on the target system. If those conversions are done in as part of the data stream reading or writing process, rather than creating temporary intermediaries, notions like "byte offsets" might become problematic... and things are sort of downhill from there. One could have that problem with any TYPE other than Image, with any use of (the real) STRU, and maybe in other cases. On the other hand, note that a variation on the (actual) STRU command (RFC 959, Section 3.1.2.3) can be used to specify the parameters for paged, random-access, transfers. Noting that it requires a "page index" internal to each block, perhaps it would be useful for your case rather than doing what first occurred to me, which would have been adding an extra sequencing argument to STOU. (If you want to initiate a bunch of transfers in parallel, having to queue them up behind 1yz acknowledgements strikes me as a bad idea if it can be avoided). > 5. The other problem is when the client has multiple > multi-part and standard (single-part) transfers initiated in > parallel. I.e. what happens if I send two files using 8 parts > and another smaller file using no parts (standard transfer) at > the same time. This is a likely scenario, given current > client's multi-threaded capabilities. What we don't want is > the server confusing transfers and assigning wrong parts to > wrong files. Yes, keeping the STOU commands > identical for each unique source filename makes a lot of > sense, but how does the server know which BMPT command to > associate with the subsequent STOU commands? Assuming > parallelism but showing both logs combined, in chronological > order: > > BMPT blah.dat, 4, 2235478 > BMPT blah2.dat, 4, 2431234 > STOU A.dat > STOU A.dat > STOU B.dat > STOU A.dat > STOU B.dat > STOU A.dat > STOU B.dat > STOU B.dat > COMB blah.dat > COMB blah2.dat > Notice here that the server will have received sequential > (back to back) BMPT (preparatory) commands, followed by > back-to-back STOU commands. There needs to be a way for the > server to identify which batch of STOU commands belong to > which BMTP command. And, of course, if one were trying to map a revised FTP state model with that setup, things would get to be bad news indeed. If there were no wait-for-next-command conditions at all, one could recast that as BMPT blah.dat, 4, 2235478 STOU A.dat (or any other fragment identifiers one STOU A.dat (liked ) STOU A.dat STOU A.dat COMB blah.dat TPMB (using a cousin of the "if... fi" convention) BMPT blah2.dat, 4, 2431234 STOU B.dat (note that repeating A.dat and B.dat STOU B.dat (in this way could be a serious problem STOU B.dat (if they represented real file names STOU B.dat (on the client.. but see below) COMB blah2.dat TPMB SYNC (wait for everything to complete on the (server side) That difference is partially dictated by trying to avoid nested states (serial stacked states seem less problematic in the FTP model) plus some distributed database experience that argues for a a "commit and wait for everything at once" operation, applied infrequently, rather than a lot of individual completion states. Actually designing "SYNC" would require some rather careful analysis of error replies and conditions (see below) but so would COMB as you describe it above. > I think the way to solve this problem is to require that the > value provided in the preparatory command (BMPT in > this example) match the filename provided in the STOU commands > (and vice versa). The user could always rename the file later > if desired, e.g. > > BMPT A.dat, 4, 2235478 > BMPT B.dat, 4, 2431234 > STOU A.dat > STOU A.dat > STOU B.dat > STOU A.dat > STOU B.dat > STOU A.dat > STOU B.dat > STOU B.dat > COMB A.dat > COMB B.dat > RNFR A.dat > RNTO blah.dat > RNFR B.dat > RNTO blah2.dat First, as mentioned above, this doesn't work well if the client needs to build the fragments and keep them, however temporarily, as real file names. More to the point, if you are going to get this far out into extension-space, nothing prevents you from either inventing a new STOU-like command, or changing the syntax of STOU if it occurs inside BMTP-state, to have an additional transfer identifier. So you would have, e.g., BMPT foo, 4, 2235478 BMPT bar, 4, 2431234 STOU foo A1.dat STOU foo A2.dat STOU bar B1.dat STOU foo A3.dat [...] COMB foo A.dat COMB bar B.dat which strikes me as more flexible and a lot less error-prone. I like it less than some of the other suggestions here, but that is partially just a matter of taste. > Let me make one more point here: Depending on the combine > techniques used bye server, the COMB command may not be of any > use other than to indicate to the server that it (the client) > is done transferring all parts, kind of like a "hey, I'm done > now, did you get everything and combine ok?", to which the > server would reply in the affirmative if for example the > sparse file had filled out and all bytes were accounted for. > If the server received the command but something was missing > or there were others errors somewhere along the combine > process, the server would reply with a transitive negative > completion reply (hey, send me the last part again), or > permanent negative completion reply (the bytes received don't > match what the preparatory command said I was going to > receive, therefore COMB failed"). Two observations, without suggesting specific remedies right now: (i) Go back and reread the discussion of PAGE-structured STRU in RFC 959. We've been through parts of this before and there was actually some significant experience with the construct... including, if I recall, discovering that keeping the page index as a header for each transmission was a whole lot safer than anything involving keeping track of transmission initiation sequencing. It may not be exactly right for your purposes -- in particular, STRU does not assume multiple data channels running in parallel although I guess it could use them-- but the idea of attaching sequencing/ locational headers to what is transmitted in the data channel(s) has some appeal. (ii) It is important to try to preserve the simplicity of FTP responses. If possible, a client should be able to tell what to do from the codes alone. If not, the response text should be sufficiently rigorously constructed so as to permit _really_ simple parsing and analysis. It seems to me that some of your suggestion above would require a rather complex response structure and that is pretty scary. > Likewise the COMB command > could retain it's original syntax for backwards compatibility, > i.e. if the server receives a COMB command that wasn't > preceded by a preparatory BMPT command, then it will expect > the COMB command to supply all necessary parameters (dst name, > part1, part2, etc.) which means I still need to solve the > naming/syntax issues. > > Here is an example of a complete sequence (less CWD and > PASV/PORT mode operations) that helps summarize what I've > stated so far: > > On Command Channel > u> BMPT A.dat, 4, 2235478 > s> 200 OK, ready for MP transfer > ...(wait for 2yz on the various data channels) > u> COMB A.dat > s> 200 Combine successful > > On Data Channel 1 > u> STOU A.dat > s> 150 Data connection opened for A.dat as part 1 of 4, ready > for next part s> 226 Transfer complete Whoops! Maybe this is why I was confused about multiple above. As soon as you start sending commands down the data channels, rather than the control one, you aren't doing FTP any more because you are violating a few key assumptions of the protocol. Note that STRU (again, the real one) deals with that by sending STRU P (and then STOR or STOU) on the control connection and then using special "page" headers on the data connection(s) to keep things sorted out. > On Data Channel 2 > u> STOU A.dat > s> 150 Data connection opened for A.dat as part 2 of 4, ready > for next part s> 226 Transfer complete > > On Data Channel 3 > u> STOU A.dat > s> 150 Data connection opened for A.dat as part 3 of 4, ready > for next part s> 226 Transfer complete > > On Data Channel 4 > u> STOU A.dat > s> 150 Data connection opened for A.dat as part 4 of 4 > s> 226 Transfer complete <--client waits for last part to get > 226 reply then command channel sends COMB to confirm all is > well and recombined. >>> The use of STRU in that context would also permit an >>> intelligent FTP-server to use some type of pool (or scratch >>> or reserved temporary) space for the intermediate files, >>> copying only the final, reassembled, file into the target >>> directory. That would eliminate several of the operational >>> or security risks you discuss. Arranging to disassemble the >>> file into pool space on the client machine (or using the >>> interleaved block approach discussed below) would eliminate >>> a number of others. > > Agreed, which is why sending a preparatory command is so > important. We just need to make sure that all necessary > information is provided so that intelligent FTP servers can > use different techniques for combining the files, while making > sure we avoid potential problemd associated with parallel > multi-part transfers and out-of-sequence sending of parts. Ack >>> FWIW, the above model could work rather well in the download >>> direction, elegantly eliminating the need for odd tricks >>> with the checkpoint/restart mechanism. > > Yes it could. Currently we use multiple REST commands at > various offsets to accomplish this, but from an FTP purists > perspective, that was ever the intended manner for REST to be > used. I just don't know if I want to tackle MP downloads in > this draft, given that this problem is already solved, albeit > in a non-elegant manner. Really a separate issue. My point was only that, if one first established the concept of a new state for bundled transfer groups, it might later be applicable to other things. >>> All of that said, experience with a number of >>> distributed/parallel storage systems, including some >>> distributed database update models and RAID striping, would >>> suggest that the most transfer-efficient way to do what you >>> are trying to accomplish would be to use a completely >>> different model: treat the file to be transferred as a >>> sequence of blocks of specified size, open a bunch of >>> connections, push block 1 onto connection 0, block 2 onto >>> connection 1, and continue with each block, M, going out >>> onto connection (M modulo number of connections). > That would not only permit more optimization but would permit > reassembly to start while the transfer was still in progress. > > This is how sparse files work and why it is necessary for the > client tell the server how many parts and total size of bytes > (so that it can perform the M modulo number of connections > calculation on the server side). > http://en.wikipedia.org/wiki/Sparse_file Not clear from your spec that this is what you intend to do. More important, if you are going to stripe files on the network, the model outlined above with separate file-pieces being assembled on the client and then sent and reassembled is hopelessly cumbersome because striping doesn't require pre-structuring anything or even accurately knowing the size of the file to be sent because one could rotate through stripe segments dynamically. Ideally one would probably use segments whose sizes were calculated from the datagram size with sliding windows on each channel. It would imply no need for an explicit recombination step and could be really fast. But it is very different. >... >>> (6) The first two paragraphs of your Security Considerations >>> section are a little bogus. Providing COMB support only to >>> authorized users, etc., may protect against certain classes >>> of malicious attacks, but they provide absolutely no >>> protection against ignorance, stupidity, or carelessness, >>> any of which can be easily exploited by an attacker as well >>> as creating risks of equally-damaging accidents. > > I think it goes without saying that we can never protect fully > against user ignorance and stupidity. Heck, the DELE command > is pretty efficient at destroying data as well. My notes in #6 > are simply the warning labels that remind you not to use your > hairdryer in the bathtub. I.e. misuse (or abuse) of the COMB > command can lead to file corruption, which is the same (or > worse in some cases) than the destruction of data using DELE. > I do think these warnings are necessary and appropriate, but > may change them a bit to match the proposed logic changes > (which are quite substantial). Sorry... I was trying to make two slightly different points, which were (i) that designing a command that is unnecessarily fragile is a bad idea (some of the ideas above make it less fragile) and (ii) there is a difference between problems resulting from "plain" ignorance, stupidity, or carelessness and situations where those same properties can easily be used by an attacker. Again, explicit "start of..." and "end of..." state-establishing commands eliminate some of the problem. As far as DELE is concerned, there is a very long history of FTP servers being configured to let selected users upload files but not delete or overwrite anything... for precisely that reason. Having server-generated intermediate file names (potentially stored at server-selected special locations) reduces that problem significantly as well. > Thanks John for your feedback. I wish I had thought of the > necessary preparatory commands BEFORE submitting my first > draft, but I suppose that is what the working group is for - > to point out flaws in the design and ways to improve, even if > it does mean wholesale changes are required. Exactly. See my comment about value-added above. > I'll wait until I hear from others and if everyone is on board > I'll float a revamped draft that includes an initiation > (preparatory) and completion command sequence for MP uploads. Ack. best, john From rto@globalscape.com Tue Jun 21 07:33:03 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D801511E8139 for ; Tue, 21 Jun 2011 07:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qo-wwR5cykVh for ; Tue, 21 Jun 2011 07:33:02 -0700 (PDT) Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id A29D711E8078 for ; Tue, 21 Jun 2011 07:33:02 -0700 (PDT) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Tue, 21 Jun 2011 09:33:01 -0500 From: Robert Oslin To: John C Klensin , "ftpext@ietf.org" Date: Tue, 21 Jun 2011 09:33:01 -0500 Thread-Topic: [ftpext] COMB command IETF draft proposal Thread-Index: Acwv48aE/dWlvsBvRFK02s4spBuMZgAMFwzg Message-ID: References: <4AD0C916B08DFA1CE8E938E5@PST.JCK.COM> In-Reply-To: <4AD0C916B08DFA1CE8E938E5@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] COMB command IETF draft proposal X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 14:33:04 -0000 >>Interesting. I need to think about this more, but my sense is that your = model would work well with some media in which it is possible to write from= several positions in a "file" at more or less the same time and badly when= that was not the case. I remember long ago having to worry about FTP tran= sfers writing directly to tape on the target systems, for which that would = be a terrible model and one would need to buffer, assemble, and then write = instead. Perhaps we have reached the point where purely sequential device= s aren't worth worrying about any more, but I'd like to think about it a bi= t. All I am saying is that we cannot (and should not) control or care HOW the = server puts the files together. We just need to give it sufficient informat= ion in the preparatory command so that recombine techniques that require mo= re upfront information will have it. I think the destination name, size, an= d number of parts expected is good for now. I thought about also providing = the hash of the file but there are purpose built commands for that, therefo= re I left hash out. If there are any other parameters we feel could aid the= server then we should provide those as well. I'd rather that than a future= RFC "extending" the BMPT command portion of the multi-part RFC (assuming i= t ever gets that far). >>Right. The other slightly-problematic issue is when other FTP commands c= hange the format or encoding of the file on the source system into a networ= k-standard form, possibly to be converted to something else on the target s= ystem. If those conversions are done in as part of the data stream reading= or writing process, rather than creating temporary intermediaries, notions= like "byte offsets" might become problematic... and things are sort of dow= nhill from there. One could have that problem with any TYPE other than Im= age, with any use of (the real) STRU, and maybe in other cases. I don't see this as a problem. In our case we never create temporary interm= ediaries when doing a MP upload. Presently our client (CuteFTP) simply read= s the source file from different byte offsets into the buffer and transfers= each chunk of bytes from the same source file name to different destinatio= n file names (using STOR command). This method conserves the existing forma= t/encoding, unless the client chooses to modify it on send. >>If you want to initiate a bunch of transfers in parallel, having to queue= them up behind 1yz acknowledgements strikes me as a bad idea if it can be = avoided.=20 That will not be the case as long as long as each preparatory command (BMPT= ) and subsequent STOU commands have matching filename parameters. Yes you w= ould have to queue up individual parts behind 1yx acknowledgements for each= MP transfer, but that would not prevent other parallel MP transfers from i= nitiating MP state and starting their own STOU sequence. Again, this absolu= tely requires that the filename parameter of the STOU command match the des= tination filename provided in the BMPT command, as the server will need to = associate the various incoming STOUs with previously dictated BMPTs across = multiple parallel sessions. =20 >>That difference is partially dictated by trying to avoid nested states (s= erial stacked states seem less problematic in the FTP model) plus some dist= ributed database experience that argues for a a "commit and wait for everyt= hing at once" operation, applied infrequently, rather than a lot of individ= ual completion states. Actually designing "SYNC" would require some rather = careful analysis of error replies and conditions (see below) but so would C= OMB as you describe it above. I'm not advocating for nested states, but rather serial stacked over variou= s parallel sessions (sessions being both control and data channel combinati= ons). Yes it requires "heavy" client logic, but heck, we (client vendors) a= lready do that today for a myriad commands that we've pushed to the limits = (and beyond) from which those commands were originally intended. Perfect ex= ample being the REST and how it's overloaded for multi-part downloads. (I t= hink a few sequence diagrams would help here) >>First, as mentioned above, this doesn't work well if the client needs to = build the fragments and keep them, however temporarily,as real file names. = More to the point, if you are going to get this far out into extension-sp= ace, nothing prevents you from either inventing a new STOU-like command, or= changing the syntax of STOU if it occurs inside BMTP-state, to have an add= itional transfer identifier. which strikes me as more flexible and a lot = less error-prone. I like it less than some of the other suggestions here, = but that is partially just a matter of taste. We should not assume to know how the client will build its fragments, wheth= er in memory as we do (reading the same file into the buffer from different= offsets, which is exceedingly fast), or using archaic/slow splitting techn= iques into temporary real files and then sending those. In the latter case = then yes STOU would present a bit of a problem but not an insurmountable on= e: client logic could rename each part into a temporary folder with the sou= rce name prior to send, rather than with unique names in the same folder. E= .g. /temp1/myfile.dat, /temp2/myfile.dat, /temp3/myfile.dat, etc. While I a= gree that we could invent a new STOU command that accepts more parameters, = I just don't see why that would be necessary, given the current "best pract= ice" of reading from the file into the buffer from different offsets, hence= conserving the original filename for each STOU command. >> (ii) It is important to try to preserve the simplicity of FTP responses. If possible, a client should be able to tell what to do from the codes alone. If not, the response text should be sufficiently rigorously constructed so as to permit _really_ simple parsing and analysis. It seems to me that some of your suggestion above would require a rather complex response structure and that is pretty scary. What I'm trying to say is that this (updated) proposal now shifts the bulk = of what COMB does today to the preparatory command (BMPT), hence COMB is re= ally nothing more than a confirmation of success (again, depending on what = logic the server is using for combining the files). In fact, it is quite po= ssible that issuing BMPT followed by STOUs is sufficient to produce the rec= ombined file! The COMB is merely a nicety, i.e. a way of providing confirma= tion to the client that the process was completed successfully. That means = the reply codes I already mentioned in the draft would be sufficient in mos= t if not all cases (in fact I may be able to remove some). The beauty of th= e proposed system is that each STOU session is responsible for getting its = part across, using APPE as necessary, and handing existing error codes for = STOU. As long as the parts all arrive and bytes received match the bytes pa= rameter of the BMPT command, then in theory the server will be able to reco= nstitute the file (if it has not already); whether or not COMB is sent by t= he client would be icing on the cake (and useful for legacy support - cover= ed in future draft). > Here is an example of a complete sequence (less CWD and PASV/PORT mode op= erations) that helps summarize what I've stated so far: >> As soon as you start sending commands down the data channels, rather tha= n the control one, you aren't doing FTP any more because you are violating = a few key assumptions of the protocol. Forgive me. I meant separate sessions (consisting of both control and data = channels) one session for the command process (sets up the COMB sequence), = with each separate session handling data (part) transfers (STOUs). The clie= nt logic would spawn these control/data channel pairs as needed for each pa= rt. The server would be responsible for maintaining overall state, meaning = if it received BMPT then it will be ready for the subsequent STOUs (and kno= w what to do with them).=20 > This is how sparse files work=20 >>Not clear from your spec that this is what you intend to do. I do want be clear in that we must NOT dictate how the server should recons= titute the files. We (GlobalSCAPE) may use sparse files (on the server side= ) or some other technique applicable to Windows file systems, but other ven= dors may use different, OS specific techniques; I think it is sufficient to= only specify that the client MUST send chunks of the same file, and identi= fy for each chunk the byte offset and size of that chunk. Those two paramet= ers can be deduced by the server if the client provides the number of parts= it intends to send and the total number of bytes that make up the file. I = want to make it abundantly clear in the draft that the techniques used by t= he client for chunking the file or those used by the server for recombining= the file are outside the scope of the draft, leaving it wide open to vendo= r implementation. The only thing we must do is provide protocol by which t= he server is aware of the fact that a MP upload will occur, so that it can = determine how to handle the constituent parts it receives, based on the inf= ormation provided in the preparatory command.=20 >>designing a command that is unnecessarily fragile is a bad idea.... Again= , explicit "start of..." and "end of..." state-establishing commands elimin= ate some of the problem. Agreed. From a security perspective we would need to shift the bulk of secu= rity and consequently error codes to the BMPT command, as you could imagine= a user sending many BMPTs with large byte parameters, which could result i= n the server allocating disk space for each one, potentially resulting in a= DoS if disk allocation exceeds available space. When BMPT is issued the se= rver would need to verify write permissions (in the current working directo= ry), and potentially dele permissions (depending on what/how it handles eac= h part received), and also verify that disk space being requested doesn't e= xceed the user's quota or acceptable usage policies, etc. I don't see any h= uge problems here but I think it would be beneficial to point out the need = for properly vetting the BMPT request. Now whether the server chooses to di= sallow subsequent STOUs or not depending on BMPT success/fail is a whole 'n= other story. If it would benefit everyone on this list I could summarize these changes i= n a fresh email. I would prefer to do so using swim lane or sequence diagra= ms, i.e. visually, as it is very difficult to convey parallel session logic= in plaintext! Then again, maybe I just need to give up on the whole idea (especially now = that I'm deviating from the current COMB single command implementation that= we and others have used for years) and continue doing MP uploads in our pr= oducts in a proprietary fashion, after all we've sold lots of client/server= due to this feature, but that would be the easy route and I don't want to = give up just yet.=20 Robert Oslin From evnikita2@gmail.com Tue Jun 21 21:10:28 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B5821F8438; Tue, 21 Jun 2011 21:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNUBIXFJrWxv; Tue, 21 Jun 2011 21:10:27 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7557F11E8127; Tue, 21 Jun 2011 21:10:26 -0700 (PDT) Received: by fxm15 with SMTP id 15so387431fxm.31 for ; Tue, 21 Jun 2011 21:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q9qTA3kwfsFfQIWUh12FgPYI6PP2g0BoUD9hMd6P1y8=; b=ukUH8gY2eIWYN32NfurLwcRjEj5f5xHCMLpO1e+5a61JY6XCDVgTr89HDbn9YhDJ5f 1TtfU5jgO75L0WLSJZg8lCK536SUI7ahdsZkEQk/exAQzdhA4q23ueG/ScnIfp2Wioy+ qiuCVqESsNQU3YwlE7bmbxX6Lmzoiu0b40oJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SU4iWGTL3aC4EeFUirnkONv3cVk25mdmcMkkHIinbpXWvayCykR0MyqDHWqZ+ebhnt qtgAHMytNeIN9sMk+RzD1/mqtXZSNlBURADnBUvrDqgYDX6ImdcvWx9r0jGLIE8ah9bz Ju+MC9X6NLsYKdntqOFN/3rrjH6HVimvfcBTM= Received: by 10.223.77.92 with SMTP id f28mr237979fak.37.1308715811837; Tue, 21 Jun 2011 21:10:11 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 10sm69057faw.24.2011.06.21.21.10.08 (version=SSLv3 cipher=OTHER); Tue, 21 Jun 2011 21:10:10 -0700 (PDT) Message-ID: <4E016B4F.9010409@gmail.com> Date: Wed, 22 Jun 2011 07:10:55 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: John C Klensin References: <4DFD839A.6010601@gmail.com> <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> <4DFF0759.6@it.aoyama.ac.jp> <3AFED76CBFF900979DE770F6@PST.JCK.COM> In-Reply-To: <3AFED76CBFF900979DE770F6@PST.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , uri-review@ietf.org, ftpext@ietf.org Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 04:10:28 -0000 Hello all, 20.06.2011 15:13, John C Klensin wrote: > > --On Monday, June 20, 2011 17:39 +0900 "\"Martin J. Dürst\"" > wrote: > >> Hello John, >> >> I'm not at all an expert in FTP, nor in the details of the >> current ftp: URI implementations. But the overall direction of >> your mail seems to be >> "if it's in the FTP protocol, then it has to be in the ftp URI >> scheme". > Not really what I'm saying. I just think that an FTP URI has to > be sensitive to FTP usage and the way the protocol actually > works. At least IMO, a poor job was done of that in 1738; if > one proposes a standalone, standards-track FTP URI today, I'm > going to do parts of that analysis and then keep repeating > "known technical omission". As far as the extensions are > concerned, I imagine that some of them are important and some > are not. Since both the URI review and FTPEXT2 mailing lists > are being copied on this, I suggest that the latter ought to be > considering whether, if a given extension is not important > enough to be included in the URI, it is really worth the trouble > as an extension. I can well imagine the answer for some > extensions being "not important enough for the URI but still > worth doing", but I think that is a discussion the WG needs to > have". I agree here, so let's have a discussion. > Three examples of the "known technical omission" problem: > > (i) At least historically, the most-used command in the FTP > protocol, other than the basic authentication ones (USER, PASS), > CWD and PWD and the basic ones actually involved in transferring > files (RETR, STOR, and probably PASV) has been TYPE. It is not > like, e.g., STRU or the file structuring commands, which many > people and servers can go for many years without ever seeing. > TYPE was really important in the early days of the net when we > not only had EBCDIC floating around, but had at least three > different ways to encode ASCII. A decade and a half ago, only > the CRLF issue remained and, if examined from a narrow web > perspective (see below), it doesn't make much difference (the > number of problems it causes every year, with lusers not > understanding the symptoms and a distinct shortage of standard, > user-accessible, conversion utilities on most systems, remains > non-trivial). It gets more important again as we see more and > more files in non-ASCII character sets, both Unicode and > non-Unicode. Even with the former alone, an IMAGE transfer may > yield any of more than a half-dozen forms (see > draft-ietf-appsawg-3536bis for a list that still does not > include the obscure ones). So, to me, saying "TYPE" is not > needed or should be treated like any other extension indicates a > lack of understanding of the underlying protocol. Probably. However, if we agree on leaving this part, we will need to have a discussion on the handling of this part in the URI, since RFC 1738 isn't clear with this regard. > (2) There is currently a proposal in the FTPEXT2 WG to add a > HOST command to FTP (draft-ietf-ftpext2-hosts) for exactly the > same reason we needed to add one to HTTP. I'm personally not a > fan of that particular way of doing the job, but one of the > strong arguments for it is that it could potentially be > automated in a shim or API that connects an FTP URI processor to > the FTP protocol as "always send HOST, if it is rejected as not > recognized, ignore and pretend it wasn't sent". But, if we > think HOST is important, that needs to be considered and > explicitly discussed in any FTP URI document. If it isn't > important enough to be considered and discussed, then the > extension probably isn't important enough to adopt and use. > Since the WG hasn't acted on the proposal, the issue is somewhat > forward-looking, but that puts the current FTP URI proposal in > the same boat as MAILTO -- it is hard to define a URI for a > protocol to which it is not integral and has to be retrofitted > when the protocol itself is being changed/extended in ways that > should rationally affect the URI. I've carefully read the FTPEXT2's draft on the proposed HOST command. HOST is surely a good proposal to use at all and I currently think including it in the URI specification for FTP is probably a good idea. So, with this respect I can agree with you and, therefore, agree to include this proposal in the 'ftp' URI specification. > (3) For obvious security reasons, username-password pairs ceased > being popular around the IETF many years ago. Username-password > pairs embedded in URIs in clear text are much worse. Some of > the extensions you (and Mykyta) dismiss provide ways around that > problem. In addition, for the very popular 'anonymous' use of > FTP, we know what the password patterns are: a reserved/known > keyword, such as "guest"; an email address; or "server simply > doesn't care what is sent". That could be built into the > URI-interpreting protocol interface mechanism as well, but the > current document circles around it with a lot of handwaving. In the current draft we have the following situation: if there are no user credentials in the URI at all, anonymous FTP is used; however, if there are a user name and password (or just a user name), they are first used. IMO, denoting user credentials in the URI isn't bad enough to abandon such capability. Those people who care about security much will be free not to include the user information in the URIs. Yet, if, for instance, some person wants to share their FTP account with the other one, including the user-info in the URI is the best option among all possibilities to do this. So I don't think removing the user-info part from the URI and making use of anonymous FTP mandatory is a good idea. I'd better care about denoting the account information in the URI, which is one of the "technical omissions" too. > Note that neither (2) nor (3) would require any changes to the > URI or its syntax, only a specification that understood the FTP > protocol and its use much better. > >> In my eyes, that's just a non sequitur. If you look at HTTP, >> there are a lot of bits and pieces that are in the protocol >> but are not in the URI scheme, for good reasons. > Sure. I trust I don't need to point out to you either that URLs > and HTTP were designed together for use with each other and that > most of the decisions as to what was left out were made after > careful consideration, not by accident and in haste (and, for > the record, I'm criticizing 1739 Maybe you meant 1738 here. > , not Mykyta's proposal). > >> If you look >> at the mailto: URI scheme, then there are also a lot of >> features in SMTP and in the message format that are not >> available in the scheme. In fact for the mailto: scheme, in my >> understanding, the header part of the message format is now >> covered, but it was the spec that caught up with >> implementations, not the other way round. > And the mailto: spec is also an example of the difficulties one > can get into when one naively retrofits a URI on top of an > established and widely-deployed protocol. >> Also, to claim that a spec that describes what's currently >> implemented (let's assume it does) can only go to >> informational, and that for standards track, it's necessary to >> cover all the features in the base protocol is totally new to >> me. As far as I understand it, the IETF is first and foremost >> about "rough consensus and running code" and only later about >> "known technical omissions". > Informational documents that describe something as already > deployed and unlikely to change are actually common and are > written with the understanding that the IETF has little to offer > in terms of adding value to the protocol other than to document > it. For standards track, I invite you to read 2026, where > "known technical omissions" is one of the few clear bars to > adopting a Proposed Standard. This is mostly a question to discuss. My personal opinion is a bit double. From the one side, Standards Track document should describe what is widely-accepted. From the other side, it must not have different technical issues which aren't clear enough. I think something like this is appropriate for our case: taking the existing URI specification and appending any necessary features to it. >> With that, I don't want to necessarily say that I would >> disagree with what you wrote e.g. specifically about the TYPE >> parameter. But I very strongly think that this and other >> details have to be argued on their merits, rather than on a on >> the base of a non-existing principle of "if it's in the >> protocol, it has to be in the URI scheme". > See above. I'm not arguing "if it's in the protocol, it has to > be in the URI scheme". I'm arguing precisely for some careful > consideration on a case-by-case basis and against a different > non-existent principle of "if it was omitted from RFF 1738, we > don't need it". All the best, Mykyta Yevstifeyev > regards, > john > > From evnikita2@gmail.com Wed Jun 22 20:48:40 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518C321F84F4 for ; Wed, 22 Jun 2011 20:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9h7otSF+Ts8O for ; Wed, 22 Jun 2011 20:48:39 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8DE721F84F2 for ; Wed, 22 Jun 2011 20:48:38 -0700 (PDT) Received: by fxm15 with SMTP id 15so1155976fxm.31 for ; Wed, 22 Jun 2011 20:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R/sOMftbLgLBFSsJuE+jta4dgnnZEsziBiqA/jTTbJE=; b=O3rUlatXapBjAfL7xrVDf44aQiAqVZaZzd6orzyq9lRKngPjpxbOj7XHT7GVL73mD6 HteKsOTg+3vaJhbcu3dpfql4Mn6ouRw54xMEmQSg37UOad6y4rUMQqcknskDzXfUyvDH AWIw6aWBcUY/1geEF6NRy9NHuC4SOzLw33pIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=KwDGg9hXoQ3yTf6Gf/3MWogg8jI7T6ZxYCwWRIwY95w3ZkRTN+RWO78goZWzhctwsi 5eYEkfioL+i/28Kh1SuJpUQGHzQ83NWPOnge/BBuvM43JUih1JRacRkM83ntsF4XvK03 r+FMVmGi2fh9mj8YQXCi1d8nQPRYWxs9GSkck= Received: by 10.223.13.207 with SMTP id d15mr2025619faa.38.1308800917827; Wed, 22 Jun 2011 20:48:37 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id m5sm708871fai.1.2011.06.22.20.48.36 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 20:48:36 -0700 (PDT) Message-ID: <4E02B7C3.10402@gmail.com> Date: Thu, 23 Jun 2011 06:49:23 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ftpext@ietf.org References: <20110620160631.14534.46793.idtracker@ietfa.amsl.com> In-Reply-To: <20110620160631.14534.46793.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-01.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 03:48:40 -0000 Hello John, all, I'd like to comment the new revision of draft-ietf-ftpext2-typeu, which was uploaded on 20 June. Probably, my comments are mostly minor and editorial, but I believe they will help in improving the document. > FTP Extension for Internationalized Text > draft-ietf-ftpext2-typeu-01 The title reads "FTP Extension for Internationalized Text". I'd better changed this to "FTP Data Type for Internationalized Text" not to create confusion with RFC 2640, which has contiguous title. Next, > Abstract > > The original FTP protocol supported TYPE values I'd like to recommend you to change "TYPE values" to "data types"; TYPE values van be referred to only in Section 2, which is technical specification of new data type, since the preceding sections explain what does the TYPE command mean and what is it used for. You could also use "data types (and, respectively, TYPE command values)" or something like this. > for ASCII and EBCDIC > text, plus binary ("IMAGE") transmission. As the Internet becomes > more international, there is a growing requirement to be able to > transmit textual data, encoded in Unicode, in a way that is > independent of the coding and line representation forms of particular > operating systems. This memo specifies a new FTP TYPE value The same concerns this and Section 1.1. > for > Unicode data. Section 1.4: > It also uses the ABNF > of [RFC2389] and [RFC5234] in preference to the BNF of RFC 959. I haven't noticed any use of ABNF in the draft. So the reference to RFC 5234 is redundant, as well as the above sentence. Ibid: > Those terms, especially reply, server-FTP > process, user-FTP process, server-PI, user-PI, logical byte size, and > user, I don't see any occurrences of "user" in the document. Also Section 1.4: > For > the convenience of contemporary readers, the terms "client" and > "server" are used interchangeably with the historic terms "user-FTP > process" and "server-FTP process". Why not completely replace server-FTP process and user-FTP process with server and client, respectively, within the whole document at all? In this case this phrase will read: > In this document the terms "client" and "server" are used in the > meaning of "user-FTP process" and "server-FTP process", respectively, > which are defined ibidem. Respectively, any occurrences of "user-FTP process" and "server-FTP process" are to be replaced by "client" and "server". Section 2.1: > E The data are expected to be in, and are transformed by the server > if needed to, an EBCDIC data stream as specified in RFC 959. For the reader's convenience, the reference to some material concerning EBCDIC could be provided. Section 2.2: > If it does, the server MAY Probably SHOULD or SHALL is more appropriate here; what is an other way to indicate that U data type isn't supported, in this case? > return reply-code 504, indicating that the TYPE U feature I'd better replace this with "Unicode data type" (as well as the section title). > is not supported (unchanged from RFC 959) or MUST I suppose your document should mention here that 200 reply must be returned before the data in Net-Unicode will be sent. > respond to any data retrieval request (e.g., GET) You probably meant RETR here, since GET is related to HTTP only. > by sending the data in a stream > conformant to the Net-Unicode format specified in Section 3. Section 3: > Unicode characters must be transmitted in UTF-8 I think the reference to RFC 3629 is missing here. Section 5: > When this specification is approved, an entry for "TYPE U" that > refers to it should be incorporated into the FTP Extensions Registry > established by RFC 5797 [RFC5797]. I've checked IANA registry (http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xml) and I see IANA doesn't officially track arguments to TYPE command. It says: > TYPE base Representation Type p m [4][RFC959] and the [4] footnote is: > [4] FEAT String: TYPE {semicolon-separated list of supported types} so I think there are no IANA considerations here. Section 8.1: > [Unicode52] > The Unicode Consortium. The Unicode Standard, Version > 5.2.0, defined by:, "The Unicode Standard, Version 5.2.0", > (Mountain View, CA: The Unicode Consortium, 2009. ISBN > 978-1-936213-00-9)., > . This may be considered to be obsoleted normative reference, since Unicode 5.2 has been obsoleted by Unicode 6.0.0. The reference should be: > The Unicode Consortium, "The Unicode Standard, Version 6.0.0", > (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6), > . Or, if you want to be independent from version: > The Unicode Consortium, "The Unicode Standard", > . Thanks, Mykyta Yevstifeyev 20.06.2011 19:06, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF. > > Title : FTP Extension for Internationalized Text > Author(s) : John C Klensin > Filename : draft-ietf-ftpext2-typeu-01.txt > Pages : 9 > Date : 2011-06-20 > > [ . . . ] > > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext > From evnikita2@gmail.com Wed Jun 22 21:15:54 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF57811E80C5; Wed, 22 Jun 2011 21:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORz4BURFQ17t; Wed, 22 Jun 2011 21:15:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4611E8075; Wed, 22 Jun 2011 21:15:52 -0700 (PDT) Received: by fxm15 with SMTP id 15so1164648fxm.31 for ; Wed, 22 Jun 2011 21:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Uq1vRT15rbRgsIzniaYaF0ixDzDd52rw7x6pyswTxgo=; b=LDMJDDDzJYpZgzAhEz0Q337FsPXLyHNZWYxnGPWE4hxKZeaUK1J7/xvBhXC5z8hNiY AsiEGcNe9M5bugNnQo+QxNtEDSAlOKCCFO07satg5A9f8PSAVaHnmItpjYFQB93nnx+4 hAWMmOdCco+h0dJIq2GzGvPcXu03Ub9lCTDCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=scfCLlTB8s9ZKN1yOmEpAO9hD1Sj56Fy/CPcLMhr7mduXCbCrjNaJOfVJckvu93Q3C 8P0GTUSRVyAmlyvT3DqZ/jd3lTqD52o5az707x1sTStyoVafvPnrPaufLMDIOCbz/gZw v/8X202kCXIOh8Vqbhn7giz9BuG83Y8CI5HCU= Received: by 10.223.1.10 with SMTP id 10mr1650549fad.134.1308802551574; Wed, 22 Jun 2011 21:15:51 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id n27sm714958faa.28.2011.06.22.21.15.49 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 21:15:50 -0700 (PDT) Message-ID: <4E02BE24.8090102@gmail.com> Date: Thu, 23 Jun 2011 07:16:36 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: John C Klensin References: <4DFD839A.6010601@gmail.com> <3B577BB53D9ADA3FC12E770F@[192.168.1.128]> <4DFF0759.6@it.aoyama.ac.jp> <3AFED76CBFF900979DE770F6@PST.JCK.COM> <4E016B4F.9010409@gmail.com> In-Reply-To: <4E016B4F.9010409@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , uri-review@ietf.org, ftpext@ietf.org Subject: Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-02 posted X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 04:15:54 -0000 22.06.2011 7:10, Mykyta Yevstifeyev wrote: > Hello all, Hello, I've made several changes to the draft-yevstifeyev-ftp-uri-scheme based on comments from John and I'd like to request community feedback on them. Please find my changes descriptions in-line. > > 20.06.2011 15:13, John C Klensin wrote: >> >> --On Monday, June 20, 2011 17:39 +0900 "\"Martin J. Dürst\"" >> wrote: >> [ . . . ] > I agree here, so let's have a discussion. >> Three examples of the "known technical omission" problem: >> >> (i) At least historically, the most-used command in the FTP >> protocol, other than the basic authentication ones (USER, PASS), >> CWD and PWD and the basic ones actually involved in transferring >> files (RETR, STOR, and probably PASV) has been TYPE. It is not >> like, e.g., STRU or the file structuring commands, which many >> people and servers can go for many years without ever seeing. >> TYPE was really important in the early days of the net when we >> not only had EBCDIC floating around, but had at least three >> different ways to encode ASCII. A decade and a half ago, only >> the CRLF issue remained and, if examined from a narrow web >> perspective (see below), it doesn't make much difference (the >> number of problems it causes every year, with lusers not >> understanding the symptoms and a distinct shortage of standard, >> user-accessible, conversion utilities on most systems, remains >> non-trivial). It gets more important again as we see more and >> more files in non-ASCII character sets, both Unicode and >> non-Unicode. Even with the former alone, an IMAGE transfer may >> yield any of more than a half-dozen forms (see >> draft-ietf-appsawg-3536bis for a list that still does not >> include the obscure ones). So, to me, saying "TYPE" is not >> needed or should be treated like any other extension indicates a >> lack of understanding of the underlying protocol. > Probably. However, if we agree on leaving this part, we will need to > have a discussion on the handling of this part in the URI, since RFC > 1738 isn't clear with this regard. Currently the syntax for is: > ftp-path = cwd-part [ "/" name ] [ typecode-part ] > cwd-part = *( "/" cwd ) > cwd = segment-nsc > name = segment-nsc > segment-nsc = *pchar-nsc > pchar-nsc = unreserved / pct-encoded / sub-delims-nsc / ":" > / "@" > sub-delims-nsc = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / > / "," / "=" > ; RFC 3986 excluding semicolon (";") > ; character (ASCII [ASCII, RFC0020] character 0x3B) > typecode-part = ";type=" typecode > typecode = "a" / "e" / "i" / "u" / typecode-ext > typecode-ext = ALPHA The appropriate step was added in the algorithm in Section 2.2.3: > (2) if the is present, perform the TYPE command with > the as an argument; > > Note: There are currently four options of the part. > They include "a", "e", "i", which are specified in RFC 959 > [RFC0959] and stand for ASCII, EBCDIC text and binary transmission, > respectively, and "u", which is specified in RFC mmmm [I-D ietf- > ftpext2-typeu] and stands for Unicode data. Additional data types > may be accommodated in the URI via the production. This incorporates the ongoing work of FTPEXT2 WG regarding U data type for Unicode data and provides a possibility to add new data types in the URI. >> (2) There is currently a proposal in the FTPEXT2 WG to add a >> HOST command to FTP (draft-ietf-ftpext2-hosts) for exactly the >> same reason we needed to add one to HTTP. I'm personally not a >> fan of that particular way of doing the job, but one of the >> strong arguments for it is that it could potentially be >> automated in a shim or API that connects an FTP URI processor to >> the FTP protocol as "always send HOST, if it is rejected as not >> recognized, ignore and pretend it wasn't sent". But, if we >> think HOST is important, that needs to be considered and >> explicitly discussed in any FTP URI document. If it isn't >> important enough to be considered and discussed, then the >> extension probably isn't important enough to adopt and use. >> Since the WG hasn't acted on the proposal, the issue is somewhat >> forward-looking, but that puts the current FTP URI proposal in >> the same boat as MAILTO -- it is hard to define a URI for a >> protocol to which it is not integral and has to be retrofitted >> when the protocol itself is being changed/extended in ways that >> should rationally affect the URI. > I've carefully read the FTPEXT2's draft on the proposed HOST command. > HOST is surely a good proposal to use at all and I currently think > including it in the URI specification for FTP is probably a good > idea. So, with this respect I can agree with you and, therefore, > agree to include this proposal in the 'ftp' URI specification. Now 2 new paragraphs were added in Section 2.2.1: > Upon establishing a successful TCP connection, the client SHALL first > try to identify the host it is trying to access using the HOST > command [I-D ietf-ftpext2-hosts]. It is performed by sending this > command with the part of the URI as an argument. > > If either 500 or 502 reply is received in response (which identify > that the HOST command is unrecognized or unimplemented, > respectively), the client SHALL act as if a HOST command had not been > sent and continue processing the URI. If either 501 or 504 reply is > received (which identify that the supplied hostname is syntactically > invalid or it is unavailable, respectively), the client's behavior > depends on how does the server react. If, in accordance with Section > 3.3 of RFC nnnn [I-D ietf-ftpext2-hosts], the server chooses to > terminate the connection, the client SHALL notify the user and take > no further actions. Otherwise, if the server does not terminate the > connection, the client SHALL act as if a HOST command had not been > sent and continue processing the URI. Best, Mykyta Yevstifeyev > [ . . . ] > > All the best, > Mykyta Yevstifeyev >> regards, >> john >> >> > From evnikita2@gmail.com Fri Jun 24 09:51:51 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF05611E815B; Fri, 24 Jun 2011 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQvUCpgLjGqT; Fri, 24 Jun 2011 09:51:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F311E815C; Fri, 24 Jun 2011 09:51:49 -0700 (PDT) Received: by fxm15 with SMTP id 15so2264934fxm.31 for ; Fri, 24 Jun 2011 09:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Gdd+/QUuFtrUd/7TZsPew9FPGxIA5LDiIlnEx8fa0ak=; b=RMgAU7jtYbrzD4bm1mLMgL1Yi9OZiudXSz+xvkaEMbuH9ilR+mJq1eSvorSf+2qXAf yYiIr5KgBjiHHq31AZG2+H2G00BzNEBO9S6ovUlOvpAeM2QlV3j22y7FRluRxYRUT+6Z fJW2ScBYzczT2PMxruTjf5CVJr0J+MYPQGtAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=R4zjeuEt+WzzyRvAcHqGYKRRtoRNrvsgfnzX8BiK4Id1aGEyvkCTaip61qX//5/AoA q2eB/2hKx81aIB1TBCD9QQ4tzfn3VbKFfEnCvS3wQieRvNpifFAcp/1GHkr7AJ3wQ1zo XV3ygdcngrYVmuOoJe/Re04rXnC1XiSFqT7do= Received: by 10.223.1.201 with SMTP id 9mr4697128fag.91.1308934306925; Fri, 24 Jun 2011 09:51:46 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id y14sm1758091fah.37.2011.06.24.09.51.44 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 09:51:45 -0700 (PDT) Message-ID: <4E04C0CE.1030807@gmail.com> Date: Fri, 24 Jun 2011 19:52:30 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ietf@ietf.org, ftpext@ietf.org References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> In-Reply-To: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 16:51:51 -0000 Hello, This document is well written; I'm strongly for its publication on Standards Track. I have an only remark. This document doesn't seem to mention what is the behavior of the server if HOST command is sent after one HOST has already been sent. Eg. C> HOST example.com S> 220 Host OK C> USER foo S> 331 Specify password C> PASS bar S> 230 Logged in C> HOST example.org S> ???? I suppose the server may treat this as REIN and then switching to specified host, if the user is authenticated, and just switch to such host if the user isn't already logged in. Another option is sending 503 reply, as invalid sequence of commands. Thanks, Mykyta Yevstifeyev 16.06.2011 16:05, The IESG wrote: > The IESG has received a request from the FTP Extensions, 2nd edition WG > (ftpext2) to consider the following document: > - 'File Transfer Protocol HOST Command for Virtual Hosts' > as a Proposed Standard > > [ . . . ] From robmcm@microsoft.com Fri Jun 24 12:08:24 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2845011E80FB; Fri, 24 Jun 2011 12:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.984 X-Spam-Level: X-Spam-Status: No, score=-6.984 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NHpbMcXK8ze; Fri, 24 Jun 2011 12:08:23 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB4711E80F1; Fri, 24 Jun 2011 12:08:23 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 24 Jun 2011 12:08:23 -0700 Received: from AM1EHSOBE006.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 24 Jun 2011 12:08:22 -0700 Received: from mail93-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jun 2011 19:08:20 +0000 Received: from mail93-am1 (localhost.localdomain [127.0.0.1]) by mail93-am1-R.bigfish.com (Postfix) with ESMTP id 4CE7B17980DB; Fri, 24 Jun 2011 19:08:20 +0000 (UTC) X-SpamScore: -35 X-BigFish: PS-35(zz9371M111aL4015L542Mzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT006.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail93-am1: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT006.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail93-am1 (localhost.localdomain [127.0.0.1]) by mail93-am1 (MessageSwitch) id 130894250069656_30765; Fri, 24 Jun 2011 19:08:20 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.253]) by mail93-am1.bigfish.com (Postfix) with ESMTP id 02A40F8804B; Fri, 24 Jun 2011 19:08:20 +0000 (UTC) Received: from CH1PRD0302HT006.namprd03.prod.outlook.com (157.55.61.146) by AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 24 Jun 2011 19:08:20 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.234]) by CH1PRD0302HT006.namprd03.prod.outlook.com ([10.28.29.125]) with mapi id 14.01.0225.056; Fri, 24 Jun 2011 19:08:18 +0000 From: Robert McMurray To: Mykyta Yevstifeyev , "ietf@ietf.org" , "ftpext@ietf.org" Thread-Topic: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard Thread-Index: AQHMMqEmcdEZfuFND0GouWGSZJApmpTM3a+w Date: Fri, 24 Jun 2011 19:08:18 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C1949D19E@CH1PRD0302MB131.namprd03.prod.outlook.com> References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> <4E04C0CE.1030807@gmail.com> In-Reply-To: <4E04C0CE.1030807@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT006.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com Subject: Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 19:08:24 -0000 Thanks, Mykyta. Section 3.3 already addresses that scenario in the second paragraph - and t= he server behaviors are exactly what you were suggesting: As discussed in section 3 of this document, if a HOST command is sent after a user has been authenticated the server SHOULD do one of the following: a. Send a 503 reply for an invalid sequence of commands. b. Treat the HOST command as though a REIN command was sent and reset the user-PI to the state that existed after the previous HOST command was sent and before the user had been authenticated, and then return the appropriate reply for the HOST command. Thanks again! Robert McMurray -----Original Message----- From: Mykyta Yevstifeyev [mailto:evnikita2@gmail.com]=20 Sent: Friday, June 24, 2011 9:53 AM To: ietf@ietf.org; ftpext@ietf.org Subject: Re: [ftpext] Last Call: (File Tr= ansfer Protocol HOST Command for Virtual Hosts) to Proposed Standard Hello, This document is well written; I'm strongly for its publication on Standard= s Track. I have an only remark. This document doesn't seem to mention wha= t is the behavior of the server if HOST command is sent after one HOST has = already been sent. Eg. C> HOST example.com S> 220 Host OK C> USER foo S> 331 Specify password C> PASS bar S> 230 Logged in C> HOST example.org S> ???? I suppose the server may treat this as REIN and then switching to specified= host, if the user is authenticated, and just switch to such host if the us= er isn't already logged in. Another option is sending 503 reply, as invali= d sequence of commands. Thanks, Mykyta Yevstifeyev From evnikita2@gmail.com Fri Jun 24 21:31:54 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B811121F84F8; Fri, 24 Jun 2011 21:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDa11LNb0elr; Fri, 24 Jun 2011 21:31:54 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 780EE21F84F7; Fri, 24 Jun 2011 21:31:53 -0700 (PDT) Received: by fxe6 with SMTP id 6so200502fxe.31 for ; Fri, 24 Jun 2011 21:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GF1rzVnsRBczTDx6kW8TaPZOfwy7Yi9gn0dMt4AdoMQ=; b=TaaEWxHBNi64psZ6g9H5CTx6FvPqropt9J22QBf3mb/X8SElIwEIXSZaqjO6+D2AIJ /NDnexpq/H6sAF99a5BTtA4UbKJHvdkRoGDx+ahwhBQdboCX9EkE9Xky8w6aaTkVH5qm GsAg2Fia78XnfIEHd+0Oq/vb6T3Q/KWG4l8tA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gmqVZvIbj4tn27vQgA8e5duDEnotcAArMBJZBoY7iaKsIM6vcwfqd0tbqPlGXntOT8 z6bl8fc6zMGihBgPcpW0F3ra3HRV0ldwWRJKwwG1VKN+317iGLHEQmIo9j9bD5c8OaNR t3Te7/8+s770/dVdzFJ1xyN1as97FnKXv3/CQ= Received: by 10.223.2.205 with SMTP id 13mr5423912fak.138.1308976312554; Fri, 24 Jun 2011 21:31:52 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id m26sm2031357fab.34.2011.06.24.21.31.50 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 21:31:51 -0700 (PDT) Message-ID: <4E0564E4.9010200@gmail.com> Date: Sat, 25 Jun 2011 07:32:36 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Robert McMurray References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> <4E04C0CE.1030807@gmail.com> <01AA9EC92749BF4894AC2B3039EA4A2C1949D19E@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: <01AA9EC92749BF4894AC2B3039EA4A2C1949D19E@CH1PRD0302MB131.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ftpext@ietf.org" , "ietf@ietf.org" Subject: Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 04:31:54 -0000 24.06.2011 22:08, Robert McMurray wrote: > Thanks, Mykyta. > > Section 3.3 already addresses that scenario in the second paragraph - and the server behaviors are exactly what you were suggesting: > > As discussed in section 3 of this document, if a HOST command is sent > after a user has been authenticated the server SHOULD do one of the > following: > > a. Send a 503 reply for an invalid sequence of commands. > > b. Treat the HOST command as though a REIN command was sent and > reset the user-PI to the state that existed after the previous > HOST command was sent and before the user had been authenticated, > and then return the appropriate reply for the HOST command. OK, and if HOST is sent for the second time when the user hasn't got authenticated, eg. S> 220 Server ready C> HOST example.com S> 220 HOST OK C> HOST example.org S> ??? I suppose it may be 503 reply or switching to the identified host with 220 reply. This situation isn't mentioned in your document. Mykyta Yevstifeyev > Thanks again! > > Robert McMurray > > -----Original Message----- > From: Mykyta Yevstifeyev [mailto:evnikita2@gmail.com] > Sent: Friday, June 24, 2011 9:53 AM > To: ietf@ietf.org; ftpext@ietf.org > Subject: Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard > > Hello, > > This document is well written; I'm strongly for its publication on Standards Track. I have an only remark. This document doesn't seem to mention what is the behavior of the server if HOST command is sent after one HOST has already been sent. Eg. > > C> HOST example.com > S> 220 Host OK > C> USER foo > S> 331 Specify password > C> PASS bar > S> 230 Logged in > C> HOST example.org > S> ???? > > I suppose the server may treat this as REIN and then switching to specified host, if the user is authenticated, and just switch to such host if the user isn't already logged in. Another option is sending 503 reply, as invalid sequence of commands. > > Thanks, > Mykyta Yevstifeyev > > > From iljitsch@muada.com Mon Jun 27 06:50:51 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB5021F8419 for ; Mon, 27 Jun 2011 06:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCkDzBd0s3s2 for ; Mon, 27 Jun 2011 06:50:50 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 7A93911E8106 for ; Mon, 27 Jun 2011 06:35:17 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p5RDZdlh084383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Jun 2011 15:35:40 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 27 Jun 2011 15:35:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EFB0822-247B-4B8A-818F-1E09EC90B07B@muada.com> References: <20110520224813.2156.61466.idtracker@ietfa.amsl.com> To: ftpext@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [ftpext] Fwd: [BEHAVE] Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 13:50:51 -0000 On 24 mei 2011, at 11:30, Iljitsch van Beijnum wrote: > FYI: the BEHAVE FTP64 draft is now in IETF last call. One comment that I got was: > The document does not mention or discuss LPRT and LPSV. Is that = intentional? > The IANA registry says these are now obsolete, but RFC1639 is still > experimental and no document has (formally) obsoleted these. RFC 1639 is an experimental RFC from 1994: "FTP Operation Over Big = Address Records (FOOBAR)". It predates IPv6 and thus predates RFC 2428 = which has this to say: RFC 1639 [Pis94] specifies extensions to FTP to enable its use over various network protocols. Unfortunately, the mechanism can fail in a multi-protocol environment. During the transition between IPv4 and IPv6, FTP needs the ability to negotiate the network protocol that will be used for data transfer. I have to admit that I was unaware of RFC 1639, and to my knowledge = there are no (surviving) implementations. Or does anyone know of any? Iljitsch= From daniel@haxx.se Mon Jun 27 06:59:38 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC54611E80E4 for ; Mon, 27 Jun 2011 06:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NGFfo49DrOs for ; Mon, 27 Jun 2011 06:59:38 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 79BC811E80E3 for ; Mon, 27 Jun 2011 06:59:34 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id p5RDxTwH024895; Mon, 27 Jun 2011 15:59:29 +0200 Date: Mon, 27 Jun 2011 15:59:29 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Iljitsch van Beijnum In-Reply-To: <0EFB0822-247B-4B8A-818F-1E09EC90B07B@muada.com> Message-ID: References: <20110520224813.2156.61466.idtracker@ietfa.amsl.com> <0EFB0822-247B-4B8A-818F-1E09EC90B07B@muada.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.8 (giant.haxx.se [80.67.6.50]); Mon, 27 Jun 2011 15:59:29 +0200 (CEST) Cc: ftpext@ietf.org Subject: Re: [ftpext] Fwd: [BEHAVE] Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 13:59:38 -0000 On Mon, 27 Jun 2011, Iljitsch van Beijnum wrote: >> The document does not mention or discuss LPRT and LPSV. Is that intentional? > > I have to admit that I was unaware of RFC 1639, and to my knowledge there > are no (surviving) implementations. Or does anyone know of any? curl used to support LPRT and family out of some idea of correctness but since we basically never saw a server support them and EPRT/EPSV were supported we removed support of the RFC 1639 commands again already back in January 2006... -- / daniel.haxx.se From wmaton@ottix.net Mon Jun 27 07:13:29 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BCC21F85CF for ; Mon, 27 Jun 2011 07:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVV+2b2M2dac for ; Mon, 27 Jun 2011 07:13:29 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [192.231.228.2]) by ietfa.amsl.com (Postfix) with ESMTP id F40EA21F85A7 for ; Mon, 27 Jun 2011 07:13:28 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id p5RED3Pk023808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jun 2011 10:13:03 -0400 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id p5RED35F023805; Mon, 27 Jun 2011 10:13:03 -0400 Date: Mon, 27 Jun 2011 10:13:03 -0400 (EDT) From: "William F. Maton" To: Daniel Stenberg In-Reply-To: Message-ID: References: <20110520224813.2156.61466.idtracker@ietfa.amsl.com> <0EFB0822-247B-4B8A-818F-1E09EC90B07B@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ftpext@ietf.org Subject: Re: [ftpext] Fwd: [BEHAVE] Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:13:29 -0000 On Mon, 27 Jun 2011, Daniel Stenberg wrote: > On Mon, 27 Jun 2011, Iljitsch van Beijnum wrote: > >>> The document does not mention or discuss LPRT and LPSV. Is that >>> intentional? >> >> I have to admit that I was unaware of RFC 1639, and to my knowledge there >> are no (surviving) implementations. Or does anyone know of any? > > curl used to support LPRT and family out of some idea of correctness but > since we basically never saw a server support them and EPRT/EPSV were > supported we removed support of the RFC 1639 commands again already back in > January 2006... These are still supported for wu-ftpd, but like curl, EPRT/EPSV are favoured for a long time now. wfms From robmcm@microsoft.com Mon Jun 27 10:25:07 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE811E8117; Mon, 27 Jun 2011 10:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV5km3SKYjCa; Mon, 27 Jun 2011 10:25:06 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0B11E810B; Mon, 27 Jun 2011 10:25:03 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 27 Jun 2011 10:25:03 -0700 Received: from CH1EHSOBE012.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 27 Jun 2011 10:25:00 -0700 Received: from mail107-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Mon, 27 Jun 2011 17:24:59 +0000 Received: from mail107-ch1 (localhost.localdomain [127.0.0.1]) by mail107-ch1-R.bigfish.com (Postfix) with ESMTP id 0F57CFE0133; Mon, 27 Jun 2011 17:25:00 +0000 (UTC) X-SpamScore: -31 X-BigFish: PS-31(zz9371M111aL542Mzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail107-ch1: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT002.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail107-ch1 (localhost.localdomain [127.0.0.1]) by mail107-ch1 (MessageSwitch) id 1309195499926219_17229; Mon, 27 Jun 2011 17:24:59 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail107-ch1.bigfish.com (Postfix) with ESMTP id D1CB1136004F; Mon, 27 Jun 2011 17:24:59 +0000 (UTC) Received: from CH1PRD0302HT002.namprd03.prod.outlook.com (157.55.61.146) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 27 Jun 2011 17:24:55 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.234]) by CH1PRD0302HT002.namprd03.prod.outlook.com ([10.28.28.64]) with mapi id 14.01.0225.056; Mon, 27 Jun 2011 17:24:54 +0000 From: Robert McMurray To: Mykyta Yevstifeyev Thread-Topic: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard Thread-Index: AQHMMqEmcdEZfuFND0GouWGSZJApmpTM3a+wgACe3wCAA/wiIA== Date: Mon, 27 Jun 2011 17:24:53 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C1949EC06@CH1PRD0302MB131.namprd03.prod.outlook.com> References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> <4E04C0CE.1030807@gmail.com> <01AA9EC92749BF4894AC2B3039EA4A2C1949D19E@CH1PRD0302MB131.namprd03.prod.outlook.com> <4E0564E4.9010200@gmail.com> In-Reply-To: <4E0564E4.9010200@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com Cc: "ftpext@ietf.org" , "ietf@ietf.org" Subject: Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 17:25:07 -0000 Thanks Mykyta, Ah, now I see your point - that's a great catch, and I will add a section t= o a new version of the draft that I am working on for other IETF comments. Thanks again! -----Original Message----- From: Mykyta Yevstifeyev [mailto:evnikita2@gmail.com]=20 Sent: Friday, June 24, 2011 9:33 PM To: Robert McMurray Cc: ietf@ietf.org; ftpext@ietf.org Subject: Re: [ftpext] Last Call: (File Tr= ansfer Protocol HOST Command for Virtual Hosts) to Proposed Standard OK, and if HOST is sent for the second time when the user hasn't got=20 authenticated, eg. S> 220 Server ready C> HOST example.com S> 220 HOST OK C> HOST example.org S> ??? I suppose it may be 503 reply or switching to the identified host with=20 220 reply. This situation isn't mentioned in your document. Mykyta Yevstifeyev From paulfordh@uk.ibm.com Mon Jun 27 13:39:08 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C891611E817D; Mon, 27 Jun 2011 13:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Te0Z71JTLQrX; Mon, 27 Jun 2011 13:39:07 -0700 (PDT) Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [194.196.100.161]) by ietfa.amsl.com (Postfix) with ESMTP id CBB6211E80D5; Mon, 27 Jun 2011 13:39:06 -0700 (PDT) Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p5RKd4HB025532; Mon, 27 Jun 2011 20:39:04 GMT Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5RKcvw31912958; Mon, 27 Jun 2011 21:39:04 +0100 Received: from d06av09.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5RKcvdr030572; Mon, 27 Jun 2011 14:38:57 -0600 Received: from d06ml069.portsmouth.uk.ibm.com (d06ml069.portsmouth.uk.ibm.com [9.149.38.218]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5RKcvHR030569; Mon, 27 Jun 2011 14:38:57 -0600 In-Reply-To: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> To: ietf@ietf.org MIME-Version: 1.0 X-KeepSent: A9997572:88B3CCF9-802578BC:006F9F84; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 From: Paul Ford-Hutchinson Message-ID: Date: Mon, 27 Jun 2011 21:38:54 +0100 X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 27/06/2011 21:38:56, Serialize complete at 27/06/2011 21:38:56 Content-Type: multipart/alternative; boundary="=_alternative 00716646802578BC_=" Cc: ftpext@ietf.org Subject: Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 20:39:08 -0000 This is a multipart message in MIME format. --=_alternative 00716646802578BC_= Content-Type: text/plain; charset="US-ASCII" Folks, some comments on the FTP HOST draft.... Section 3: > Server-FTP processes SHOULD treat a situation where the HOST command > is issued after the user has been authenticated using one of the > following two behaviors: > > a. Treat the late HOST command as an erroneous sequence of commands > and return a 503 reply. > > b. Treat the late HOST command as though a REIN command was sent > before the HOST command and reset the user-PI to the state that > existed after the TCP connection was first established and before > the initial user authentication and then return the appropriate > reply for the HOST command. Surely the first SHOULD has to be a MUST. Otherwise we have a situation where, upon receipt of a valid HOST, some server implementations will implicitly REIN and clear AUTH/USER/ACCT and some will not. That would be an interoperability nightmare. Section 3.2: > The "220" reply code for the HOST command is the same as the code > that is used in the initial "welcome" message that is sent after the > connection is established. This reply code is used deliberately in > order to allow the implementation of a front-end FTP server as a > wrapper, which simply waits for the HOST command, and then invokes a > server that is compliant with [RFC0959] in the appropriate > environment for the particular hostname received. I'm a little concerned that this presents the "wrapper" to be a lot more lightweight than it actually will need to be. Such a wrapper will need to stay in the session in order to monitor for future HOST commands (which presumably will not be understood by the [RFC0959] compliant servers) and implicitly close and reopen a new session (or issue a REIN). If the session between the client and real FTP server is AUTH protected then this may be impossible. If we really do allow for such a lightweight wrapper, then this draft needs to mention that there is a perfectly expected mode of operation for a client where a FEAT command may initially return HOST and an initial HOST may indeed work - but after that - all bets are off. I suggest that either the "wrapper" concept is dropped from the document altogether, or a fuller description of what a wrapper might be expected to do (and - more importantly, how a client may need to be written to allow for one to be there) is included. Section 3.2.2: > This is also true when the HOST command is used with the AUTH and > ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this > scenario, the user-PI sends a HOST command which the server-PI uses > to route activity to the correct virtual host, then the user-PI uses > the AUTH and ADAT commands to negotiate the security mechanism and > certificate with the server-PI ... "to negotiate the security mechanism and certificate" should be "to negotiate the security mechanism and relevant authentication token(s)" (RFC2228 is not dependent on 'certificates') Section 4: > Some organizations may > use private hostnames, and that information SHOULD be protected when > transmitted between the client and server by using a strong method of > encryption. The "strong method of encryption" is a bit vague. Are we suggesting something like TLS? In which case it won't work - as the HOST precedes the AUTH. Or are we suggesting some mutually shared secret between the client and the server for the parameter to the HOST command - somehow bootstrapped by some unspecified mechanism? (or are we simply assuming such environments would be expected to be running over a VPN anyway?) I don't think we can publish this paragraph without being more explicit about what this really means. > Server implementations SHOULD reset the security environment when a > HOST command is sent after a user has logged in. I repeat my initial point - this has to be a MUST - otherwise the client has no idea what the state of a session is after the HOST is processed. In the case of RFC4217, this is crucial - because a REIN closes the TLS session. A client has to know if that is expected or not, this cannot be left to a server implementation decision. I believe that there's a good argument for stating that a HOST following a successful initial HOST MUST be preceded by an explicit REIN, but if we are going to let that slide, then we must be clear that a HOST always implies an implicit REIN. (Note that RFC4217 has some words about the REIN response being transmitted on the protected channel prior to the dropping of the TLS session, it is precisely due to nuances like this, that I fee the REIN should be explicit - otherwise a similar statement would need to be made about the response to the HOST) Finally, I would like some mention of the linkage (or more importantly, lack of mandated linkage) between the identity returned in an X.509 certificate (in the case of RFC4217) and the parameter to the HOST command at the protocol specification level. A pointer to the first paragraph of section 15.1.1 of [RFC4217] would be fine.... >Although it is entirely an implementation decision, it is >recommended that certificates used for server authentication of the >TLS session contain the server identification information in a >similar manner to those used for http servers (see [RFC-2818]) Paul. -- Paul Ford-Hutchinson CISSP - Tivoli Security Consultant IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU IBM Certified Deployment Professional - Tivoli Compliance Insight Manager V8.5 Tel +44 (0)7500 078379 (internal: 37269105) From: The IESG To: IETF-Announce Cc: ftpext@ietf.org Date: 16/06/2011 14:06 Subject: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard Sent by: ftpext-bounces@ietf.org The IESG has received a request from the FTP Extensions, 2nd edition WG (ftpext2) to consider the following document: - 'File Transfer Protocol HOST Command for Virtual Hosts' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ ftpext mailing list ftpext@ietf.org https://www.ietf.org/mailman/listinfo/ftpext --=_alternative 00716646802578BC_= Content-Type: text/html; charset="US-ASCII"
Folks, some comments on the FTP HOST draft....

Section 3:

> Server-FTP processes SHOULD treat a situation where the HOST command
> is issued after the user has been authenticated using one of the
> following two behaviors:
>
>  a.  Treat the late HOST command as an erroneous sequence of commands
>       and return a 503 reply.
>
>  b.  Treat the late HOST command as though a REIN command was sent
>      before the HOST command and reset the user-PI to the state that
>      existed after the TCP connection was first established and before
>      the initial user authentication and then return the appropriate
>      reply for the HOST command.

Surely the first SHOULD has to be a MUST.  Otherwise we have a situation where, upon receipt of a valid HOST, some server implementations will implicitly REIN and clear AUTH/USER/ACCT and some will not.  That would be an interoperability nightmare.


Section 3.2:

> The "220" reply code for the HOST command is the same as the code
> that is used in the initial "welcome" message that is sent after the
> connection is established.  This reply code is used deliberately in
> order to allow the implementation of a front-end FTP server as a
> wrapper, which simply waits for the HOST command, and then invokes a
> server that is compliant with [RFC0959] in the appropriate
> environment for the particular hostname received.

I'm a little concerned that this presents the "wrapper" to be a lot more lightweight than it actually will need to be.  Such a wrapper will need to stay in the session in order to monitor for future HOST commands (which presumably will not be understood by the [RFC0959] compliant servers) and implicitly close and reopen a new session (or issue a REIN).  If the session between the client and real FTP server is AUTH protected then this may be impossible.

If we really do allow for such a lightweight wrapper, then this draft needs to mention that there is a perfectly expected mode of operation for a client where a FEAT command may initially return HOST and an initial HOST may indeed work - but after that - all bets are off.

I suggest that either the "wrapper" concept is dropped from the document altogether, or a fuller description of what a wrapper might be expected to do (and - more importantly, how a client may need to be written to allow for one to be there) is included.


Section 3.2.2:

> This is also true when the HOST command is used with the AUTH and
> ADAT commands that are discussed in [RFC2228] and [RFC4217].  In this
> scenario, the user-PI sends a HOST command which the server-PI uses
> to route activity to the correct virtual host, then the user-PI uses
> the AUTH and ADAT commands to negotiate the security mechanism and
> certificate with the server-PI ...

"to negotiate the security mechanism and certificate"

should be

"to negotiate the security mechanism and relevant authentication token(s)" (RFC2228 is not dependent on 'certificates')

Section 4:

> Some organizations may
> use private hostnames, and that information SHOULD be protected when
> transmitted between the client and server by using a strong method of
> encryption.

The "strong method of encryption" is a bit vague.  Are we suggesting something like TLS?  In which case it won't work - as the HOST precedes the AUTH.  Or are we suggesting some mutually shared secret between the client and the server for the parameter to the HOST command - somehow bootstrapped by some unspecified mechanism?  (or are we simply assuming such environments would be expected to be running over a VPN anyway?)

I don't think we can publish this paragraph without being more explicit about what this really means.

   
> Server implementations SHOULD reset the security environment when a
> HOST command is sent after a user has logged in.

I repeat my initial point - this has to be a MUST - otherwise the client has no idea what the state of a session is after the HOST is processed.

In the case of RFC4217, this is crucial - because a REIN closes the TLS session.  A client has to know if that is expected or not, this cannot be left to a server implementation decision.

I believe that there's a good argument for stating that a HOST following a successful initial HOST MUST be preceded by an explicit REIN, but if we are going to let that slide, then we must be clear that a HOST always implies an implicit REIN.  (Note that RFC4217 has some words about the REIN response being transmitted on the protected channel prior to the dropping of the TLS session, it is precisely due to nuances like this, that I fee the REIN should be explicit - otherwise a similar statement would need to be made about the response to the HOST)

Finally, I would like some mention of the linkage (or more importantly, lack of mandated linkage) between the identity returned in an X.509 certificate (in the case of RFC4217) and the parameter to the HOST command at the protocol specification level.  A pointer to the first paragraph of section 15.1.1 of [RFC4217] would be fine....

>Although it is entirely an implementation decision, it is
>recommended that certificates used for server authentication of the
>TLS session contain the server identification information in a
>similar manner to those used for http servers (see [RFC-2818])
 

Paul.

--

Paul Ford-Hutchinson CISSP - Tivoli Security Consultant
IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU
IBM Certified Deployment Professional - Tivoli Compliance Insight Manager V8.5

Tel +44 (0)7500 078379  (internal: 37269105)


From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: ftpext@ietf.org
Date: 16/06/2011 14:06
Subject: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File        Transfer Protocol        HOST Command for Virtual Hosts) to Proposed        Standard
Sent by: ftpext-bounces@ietf.org





The IESG has received a request from the FTP Extensions, 2nd edition WG
(ftpext2) to consider the following document:
- 'File Transfer Protocol HOST Command for Virtual Hosts'
 <draft-ietf-ftpext2-hosts-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not
  provide a way for FTP clients and servers to differentiate between
  multiple DNS names that are registered for a single IP address.  This
  document defines a new FTP command that provides a mechanism for FTP
  clients and servers to identify individual virtual hosts on an FTP
  server.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/


No IPR declarations have been submitted directly on this I-D.


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

--=_alternative 00716646802578BC_=-- From evnikita2@gmail.com Mon Jun 27 20:41:24 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD6F21F8605; Mon, 27 Jun 2011 20:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgcazJeJyAaB; Mon, 27 Jun 2011 20:41:23 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0127E21F8601; Mon, 27 Jun 2011 20:41:22 -0700 (PDT) Received: by fxe4 with SMTP id 4so3088984fxe.27 for ; Mon, 27 Jun 2011 20:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=AFGQoDNDZcP+wh7cTqy3wJ9DOmXydAkkWJNhzEWUun4=; b=eGiyfpdJA8UFhisDYmsdSriTd13DZeyG+Lui1Xte9N+lM8DH26MyioxpMAr9F25FxD +LnQG2aVYTL3DGU7PP/XDWaY0RmyOEUZntA8a5tVsWuKMAPqjUhDvNviE3/Lthkz707j w8d7hrKYZuOKe4oUm/5/W5Jx2NDBuzz83o3u4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=fun7e3Q4TobGxrsR77WLXuxB6gCamGj/MMh/8qg8Ao3H3WR/4HTo8UGIqNGgLSFgSy X0ijdbNNFXJGrnJnnYb5QJ2NJZMbZ7BsU9eZdKjqmpoIP8mocoguveAr8QSrEi+zTNUK u/Wmd/tz+aPoI7GPSlxMXqTUG6Rr7EfvDSIDk= Received: by 10.223.132.210 with SMTP id c18mr1131235fat.97.1309232480585; Mon, 27 Jun 2011 20:41:20 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id n7sm3926002fam.43.2011.06.27.20.41.19 (version=SSLv3 cipher=OTHER); Mon, 27 Jun 2011 20:41:19 -0700 (PDT) Message-ID: <4E094D8D.8090001@gmail.com> Date: Tue, 28 Jun 2011 06:42:05 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "uri-review@ietf.org" , "ftpext@ietf.org" , URI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ftpext] FWD: New Version Notification for draft-yevstifeyev-ftp-uri-scheme-03.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 03:41:24 -0000 Hello, > A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-03.txt has been successfully submitted by Mykyta Yevstifeyev and posted to the IETF repository. > > Filename: draft-yevstifeyev-ftp-uri-scheme > Revision: 03 > Title: The'ftp' URI Scheme > Creation date: 2011-06-28 > WG ID: Individual Submission > Number of pages: 20 > > Abstract: > This document specifies the'ftp' Uniform Resource Identifier (URI) > scheme, which is used to refer to resources accessible via File > Transfer Protocol (FTP). It updates RFC 959 and RFC 1738. Any comments are still welcome. Mykyta Yevstifeyev From Internet-Drafts@ietf.org Tue Jun 28 08:31:17 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904F911E80E6; Tue, 28 Jun 2011 08:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itJTxC8w47qL; Tue, 28 Jun 2011 08:31:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB421F84C5; Tue, 28 Jun 2011 08:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110628153002.4969.14888.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 08:30:02 -0700 Cc: ftpext@ietf.org Subject: [ftpext] I-D ACTION:draft-ietf-ftpext2-hosts-03.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 15:31:17 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF. Title : File Transfer Protocol HOST Command for Virtual Hosts Author(s) : P. Hethmon, et al Filename : draft-ietf-ftpext2-hosts-03.txt Pages : 23 Date : 2011-06-28 The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ftpext2-hosts-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ftpext2-hosts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-06-28082156.I-D@ietf.org> --NextPart-- From daniel@haxx.se Tue Jun 28 13:50:32 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8842821F8640; Tue, 28 Jun 2011 13:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yo0f5FH3G6J; Tue, 28 Jun 2011 13:50:31 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5F221F85E8; Tue, 28 Jun 2011 13:50:30 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id p5SKoMjb008084; Tue, 28 Jun 2011 22:50:22 +0200 Date: Tue, 28 Jun 2011 22:50:22 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mykyta Yevstifeyev In-Reply-To: <4E094D8D.8090001@gmail.com> Message-ID: References: <4E094D8D.8090001@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.8 (giant.haxx.se [80.67.6.50]); Tue, 28 Jun 2011 22:50:23 +0200 (CEST) Cc: "uri-review@ietf.org" , "ftpext@ietf.org" , URI Subject: Re: [ftpext] FWD: New Version Notification for draft-yevstifeyev-ftp-uri-scheme-03.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:50:32 -0000 On Tue, 28 Jun 2011, Mykyta Yevstifeyev wrote: >> A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-03.txt has been >> successfully submitted by Mykyta Yevstifeyev and posted to the IETF >> repository. I'm afraid this draft is drifting even further into a territory where it dictates how to do FTP in a way I don't think it can or should. Some random remarks on the -03 version: Section 2.2 Introduced a typo on line 2, "a file a directory" should be "a file or a directory". Section 2.2.3 I object to (1b) as it is present and then mentioned to be NOT RECOMMENDED and then it is claimed to be there due to "compatibility with some FTP clients" but the only times I've had to use that method it has been to overcome problems caused by FTP servers (or server installations at least). Its existance in the spec is utterly confusing to me. (3) seems to mandate PORT or PASV to be used. This is not how many clients of today work - they prefer EPSV or EPRT and a lot of them also use STAT instead of opening a second connection. I strongly oppose to the the URI spec to dictate this. Similarly, I object to (4a) and (4b) claiming that NLST should be used to list directories. That's entirely up to the client on how it thinks is best to get the contents of a directory. -- / daniel.haxx.se From robmcm@microsoft.com Tue Jun 28 19:20:50 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D599E8019; Tue, 28 Jun 2011 19:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR7dA7jFdrou; Tue, 28 Jun 2011 19:20:47 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id EF1DA9E8004; Tue, 28 Jun 2011 19:20:46 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 28 Jun 2011 19:20:46 -0700 Received: from VA3EHSOBE005.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 28 Jun 2011 19:20:45 -0700 Received: from mail112-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 29 Jun 2011 02:05:27 +0000 Received: from mail112-va3 (localhost.localdomain [127.0.0.1]) by mail112-va3-R.bigfish.com (Postfix) with ESMTP id 9C0811398121; Wed, 29 Jun 2011 02:05:27 +0000 (UTC) X-SpamScore: -4 X-BigFish: PS-4(zz4015L103dKzz1202h1082kzzz31h793h2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail112-va3: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT002.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail112-va3 (localhost.localdomain [127.0.0.1]) by mail112-va3 (MessageSwitch) id 1309313111999234_13394; Wed, 29 Jun 2011 02:05:11 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.242]) by mail112-va3.bigfish.com (Postfix) with ESMTP id BB295580125; Wed, 29 Jun 2011 02:04:23 +0000 (UTC) Received: from CH1PRD0302HT002.namprd03.prod.outlook.com (157.55.61.146) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 29 Jun 2011 02:04:20 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.234]) by CH1PRD0302HT002.namprd03.prod.outlook.com ([10.28.28.64]) with mapi id 14.01.0225.056; Wed, 29 Jun 2011 02:04:19 +0000 From: Robert McMurray To: Paul Ford-Hutchinson , "ietf@ietf.org" Thread-Topic: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard Thread-Index: AQHMNcZDcdEZfuFND0GouWGSZJApmpTTjkbg Date: Wed, 29 Jun 2011 02:04:16 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C194A07E2@CH1PRD0302MB131.namprd03.prod.outlook.com> References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.114] Content-Type: multipart/mixed; boundary="_004_01AA9EC92749BF4894AC2B3039EA4A2C194A07E2CH1PRD0302MB131_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%UK.IBM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com Cc: "ftpext@ietf.org" Subject: Re: [ftpext] Last Call: (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 02:20:50 -0000 --_004_01AA9EC92749BF4894AC2B3039EA4A2C194A07E2CH1PRD0302MB131_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Paul. I believe that I have addressed all of your comments with the following act= ions: -------------------- Section 3: -------------------- > Surely the first SHOULD has to be a MUST. > Otherwise we have a situation where, upon > receipt of a valid HOST, some server > implementations will implicitly REIN and > clear AUTH/USER/ACCT and some will not. Agreed - I changed that verbiage. -------------------- Section 3.2: -------------------- > I suggest that either the "wrapper" concept is > dropped from the document altogether... I removed that verbiage. (That was detail for a possible server implementat= ion anyway.) -------------------- Section 3.2.2: -------------------- > should be "to negotiate the security mechanism > and relevant authentication token(s)" I changed that as well. -------------------- Section 4 -------------------- > The "strong method of encryption" is a bit > vague. I don't think we can publish this > paragraph without being more explicit about > what this really means.=20 I removed that paragraph. By way of explanation, this was in reference a se= rver implementation detail that in hindsight probably shouldn't be in this = document. More specifically, some FTP servers and clients support Implicit = FTPS, but that is not defined by RFC and lately considered deprecated, so i= t's best to just remove that information. > I repeat my initial point - this has to be a MUST. Agreed - I changed that verbiage. > I would like some mention of the linkage > between the identity returned in an X.509 > certificate and the parameter to the HOST > command at the protocol specification level. I have attached a new version of the draft that contains suggested wording = for this request, with all of the other changes that I have addressed as we= ll. Thanks! Robert --_004_01AA9EC92749BF4894AC2B3039EA4A2C194A07E2CH1PRD0302MB131_ Content-Type: application/pdf; name="draft-ietf-ftpext2-hosts-04.pdf" Content-Description: draft-ietf-ftpext2-hosts-04.pdf Content-Disposition: attachment; filename="draft-ietf-ftpext2-hosts-04.pdf"; size=34609; creation-date="Wed, 29 Jun 2011 01:37:15 GMT"; modification-date="Wed, 29 Jun 2011 01:37:15 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nI1W21IbORB991d05WFjqvCVZAl5C7eELch68eylKs6DPNNjK4ykiaQB/Pd7 pJENxqQAF+XxjLp1+pzTrflJw/6IhuGTvnPVGVwf0sJ1hvQZ/4vOz84oLqD0lSs6zrDoA43GlJWd Nm5E4wM6fI87qtM9zyZn/2Vj+tfYG6kX9NmapqbX/k369IX9Uhm9l/3ojA4ou+x0L7Rnq9n3Tq0o /atzrTPRsTV+ydbtve10/64L4dl9pKP3RzTrypJEXVtzy8Vs7xUpr/t0lV811opVyBaQ6YILcl74 BlmnXuhC2MJRZkV+80yGK5lb4wzqODG2NlZ4iWKR6+y+ljYgO+Wc1ZwtHYz2aTwcjV5E9UejmcZH 7WrkOjiKvG2en8uKAyDtSqSdgA6Tm4q+/DnNgEIpYKbSWPpHWt8IPDDOB7YS/89vWgQxepJ92St9 zfd+3FuGuN7wHULHv8fQT3PnQYQPBSImW/IvwOyTcFRwKTXYlJquz0+iRN9wMcTF930qDDvSxm8B C9rJgknQnVjFImBAyivJ2jsKhTm2txCfvKFCltgTTyQ8QHP2d8w6QVNN5WUNaKdfp6SFwl5+KTwJ y2R5IR08yC1NghycjaUXExJFAdFcP9QmXcpVmLxR2CYVBByk+a5FluiOuRP48FxxvhRaOrWuIaX6 RSWIQhXlClQVEjmCardJvagCwfdCP0rUBvcfpJlGy5IpgUU6umJlNirh95Omwx3XzJX0vtWnbKoK xWigRT050530S2TiXXUcDB73OT6Z0OGHWEq8PHqEBou3d3SR+bs0RdaMJry8WUxnegGK2WLV1taZ cDd0biygzboXZ9n5bA8ifTUQPnIfRwItwnRypOAdUbngEPhVzhvPiYtdAOIpN634TBViA7wc4yGI v1mVUqWywCS2X3pffxwMMIxEaJAbSBNaqW/sYhA7yw1SnsHLLMWARxBvRSXXVlXiXqpGBWBO3hPm oV9u93bQIxAwZ2ridCz24fi6Enm4QhIzd6biIPx8lXh7RAdaRK9SiV4qBhsX0S9Sx9Fa29htMG3j eBe+w16xKfM15QrLEVOFrRGVyygZq7Q11NMh7E2QJlgReyxiD77ZIuo5F99JuJbjoA0NsjNpA9Xd E1OvrFwsfXCL3MB6uD3r5jgs4mQOxsIwa5yntquZarRoMHxqUQnahNvpjM2IEI1fGhs89AnY4gaB ktiuRX+3ok1g25E/OPeBpUe9Fdtjg+uto0teiGpr98lDX15zhSMIDkeSGHW6ljbVPesmr/qQjvnB pxXI0Y57ElMAhEAKxnwFHlAbQAQvwXcpT93MERCPu83QWReD6icVCxdG7a3EqEQ4fhRPoOQwexg8 q/1E6QoT1uVoWKaVaeyavsACKEQn5z4WGYcT7tS8OYpQ7lMIJwYHCc7D2uhobZxp4ewKU98atb0c 54Vbp5I6rxqETqWqq1bx4+kpXbb0kEee9nRrocb5OeUIjd71E0Xh9QnirN9Zftu8Z7SnbXo7ePHl 4NtELJhG35HxLOv8hc//RAEGjWVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagoxMTQ4CmVuZG9iagox MiAwIG9iago8PC9MZW5ndGggMTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyd lttS2zAQhu/9FHtVYKaksQ0kXDoHCh0OaWLai04vhLw2KrEUJDmBt+9KOZAAM4ljT0YZjfX539Wv XT9DsxFC092LkZfBt2ELChM04Tv9iuA5CP0DsBh4CZ2UHmpDGEGaB/N1IUQxtFptSMvg8Epa1BLt cU+z3IK7LtIBXN6NUuiqsmQyg1xp+CW0rdgYLpWxBlbXj0oiRM0wPEr/BfE5pNfBIU3bR4RUV8bC NRa0aqDVVBihpAEHZBph4qYyzGAm7KOqLMyY1kzaV2Dm6CAI4yUrQ8O1eKAnhfTgkSgnY5ELmumM enAtOEqDDVq0EJCyhzGCyikAik5ax4vOlrywAUBRa5VV3JIkaNS+Id5QGNFMT/GqpHe5d05p9LHW JB76lEYNp7DDjOCQqiesxfGskzWW0zZCPUUNQ6S0YT3aihXT/5SS743BF8aoqet0pSv2MY5epWUv bqNsXfIGy8W4sdogDVbw3WKF9oo1pzltw/7V7R68Dyyn7d6gPh5cQWVY4X3pxW5nnb9juT0YWWYR eoIVmpW772XYXMtX/D5fqLXSZruiBau1xjoh1kU/SUGjmZDn0VeLnfcyXObrxPuUV1pQBaAzZKg2 aDY/RrvqWrJO3QlPbpM9OZ61zP2Z8wLmqFHymmfnA8vRnLdulS5J0hTrkzdYka9k+b60aOmJZDJB mYkXSJxZ5UzpJ19Bk7HrDZ69jRi9+SvxMd5RxRkrlglZ+NPd/d1bGWIbK1xjRZ+wkm5310qxwYo/ Yd2P+sNdWdEay/mV7MXHldmnh0Tx+9x3CJjwJ6lmY8wKdL1kR8e+sSrqpNocQJJldBzNHn71rKg9 b5aXaB9LCu4L3PCbirrz67wW9V8mgvjQQ47lA3WWOPzqPwJg8/ozcPUu+kvIfhr8pPs/aTXy+GVu ZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKNjg1CmVuZG9iagoxNyAwIG9iago8PC9MZW5ndGggMTgg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxtVtly2zgQfNdXTOlhN6lSHFPeHH5J ldey10r5UCwmVVuJHyASErEhCRogrejvt2cA6nAsHzwANAY9PT16pOOjhI75J16zavD2/gOt/OCY /sHfavA4SGQCxUtW0d8pJn2kZEzpchDWJTQ+oQ8fPlJaDV5N61a7WrdvJk4tW+LPZTqjq7t5Sue2 qlSd09I6+mZc26mSrqxvPW0/n7ta0/g4SV6n/w1OTim9HrxKjogA62zeZa2x9es/B+P3MoIF05aM pwzItib8toWmPgbZCDtuaHI7p1pV2lNryWlvyyfNtwpYyUmP5U29KrF8RirPMctj47QAfOMUds40 FcqTiaHoXDbLbJ3ppiW7FDTGGT7FwxU43HBE60I7TUoeSTWNVk4C0b8Mv/CkaqDmutH4V7cRBXem 3Yxo0eGINaJWJZ7JFwqhkQFrTbHxJsM+fKLOZXi9Nm0BGjTxya3TEcubypTKSQT+6IDAeZcVHIBy TtUrXWFbnFd7XD15W2k82UWpKy90cjK9dk/a+VEMHa8OaZRhynE4ENoZX3C8NXKERwEAZ7WWXHpa bJhG4/Zo134U465tG0e3GQQhOlOd1+EwiFtTV5vHTpcbMsyfWRrkpseNSBGanMJbhyEEzniSYsUi wnHKcl8p/FrY5kNOZ8+A+D1A8nK7F3ms2yOIWOsBYDt6q9u1dT8jVl8Elwaym298qyv68er22+X8 x+vDLIkMK63qGFdulkuICrna1xoKQdXMmeXR3aSD9PQLlrypl01FjVlpOOcjkO4Yh4PevIAkJHQY BNOZ4iT2KODyDMXmswIyYkgLFjKWUMvhG+87TbXWOe8XkaB7RtGSaluXgclcs3YC+E4XoRZU6a1M igeJQFJcnLlAEPZT3tvMADsPZRGBjcOLnoRdto4iTrpppKagMPeGhyH/TERJWeeYA8TYy2/rKY12 qI5qL5YQit0LPxhPJ4diaTCFZFagex+MiwwjEQlLxFo49hCr91g/4hdOL62IcwNlZNCi8dVvrPc0 C/dr25U5MB87kAB/QFpjCuUQvIkcezYN2hVi8HT03HJ9IUgLSZsYoWpDkkXl0TGCwelg+FdpOnub HB0jLQdyzPXS1JgDi/t+f3menP717mEk26+V771ahiNCwrazWxUPyGvH75P3DwjD2W4V0g3mjfAd KeRuI+dnWgutcuSdi0vTym6VJHNxlNxmndihEXYWju1Lbb201E+65MlLrdoOfDbKsUFjanBExoIz 9P0irK71OjTDLDZDoQ7OY9f+Jc1tC8U3OjPLDZqJgWHvV70Ub3BUvmWyVZ+7PbCI01eHeBfHFOkI yqu6sjVNqZ/ZCit21x4PnZDFETv1GGROetbObf3EHgFxPbMyTT/hLPBBGMHw5us8RY+UK93eyf39 xZev0/uLCd/Pr86ur7c3YcaBgDBw9/U6zuW7Hcr53c3Nxe0kAN2c/TsMwhrezdLp3e3Z9ZBltVcl 24yLZ1vWt+HvEuiHLGPRnc+cWez0Ok6S04dn9VFD+KoCi3Cs4fmnYdh0/mm4czswj+Ryk+2bR7Bf nvpCMx1xITTcMqG5zQutYRc5u2PHykFlBgN9VmHHp+9OHyQkqbdkfCLx77ZE/JAyzL2DzMVpCByg SQydbsoNc8lC5Su3qnAVxrmlDPvePWzQatnTeCR0fVG85+dJOutx9jW6fTeb7nDkRVzwu6z33vKi 7UNcAJMLIb0by/mudFvwV8U/6Ca7gZ+rTfjiefGrMfy9aqIzXS3Q8k6SkXwRpcPP95laaTp5AOJF OviCn/8BiD2PgGVuZHN0cmVhbQplbmRvYmoKMTggMCBvYmoKMTM0NQplbmRvYmoKMjIgMCBvYmoK PDwvTGVuZ3RoIDIzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicdVbbbts4EH33 Vwz8sJssHNd2km2Dog9O2tRe9JImarFAkwdaGtncSqJCUo799zszpOQISGUkgkTyzOWcmdEjTMZT mPAv3tNy8Or2NazdYAIf6W89eBxMZQPEW1rCZUKb3sB0Bkk+COemMDuF16/fQFIOjpaVR1uhP3lv Ve6Br+vkBhZf7xK4MmWpqgxyY+GHtr5RBSyM8w6665+mQphNptPj5L/B6QUknwZH9Hro9zUORzBM TeWtKYDuFaZem4rfZsqr/is2M5zfXS2X/GARVFEc/zmYnraIjcMMNsgrDjLMdUXPnl+Mad/s73bf 3b7yagcWHxttaYs+7G6crtZ8BubNukQKPIPLL9fduq56Fn/eXl+dz07PHsaEakqENVZoKQXz7pBm 75342xn0G2ua9cY0nk0RImNlJm3Y4lt6ZxzCky4KWGFnulDEAjlAy+SwC2khu3MPubbORxiLKqMY RqA9lGrPCE+a4LwBp8u62NOOlDJHMErMO+w5ijvdYXHqQt7dL10zBGemwp3v7B8SOxtPyZtL5XQK ifmFlYsoCfvbRgfkg7EkD0ZKje0bX+stVhzjvK6xyvQOLsHkv015ImQ/B2iTlpsminIlDgkfWCC7 0PpV6F9E86ebxXwE75cfl8kI7m5GgD5laCMJGomfuSkK8yTKQFuyXlSWoeBHLJJeR00bal90ciVX i/ktvIMfcn9F9ujfIplf8uJb2GqnVwVCXTQUykZ7BFerFLtEYjx5f5RbUx5ycX8sLAV42xQYUhmD TzfKqpTVwyXneukUnK2ye47ONasTh0SOyUMNcLE9O05rktMYLR3TpmnTmYZO4MQTi64mPtD1k/DF UEgiPOaYOBmB85ZNFxQsFU4olFSJAUcaIl63KFQr33OcWgNphVlnPmoyiHYrFdpnIeiXla/RBdvU vF7yuaYwSyQ34jZpMcLzah+LrsZU5zpVYnajti0zW1U0LXqqKlagRfFJOgj5pKq9hBVDIZ+px3EH HbL7hy7gyAVuX0PqAZ774KK73/Gd1RlbYe7rMe4URYZjCuR3QNe07UPcRt2asfKETv4bT34tI+zz Up5xQ+OEWrhFSV2EvQt1D2fjGauEFTi5OL94iG3KxXqxJSeQvCxRVcwv7bUBiLLZI5IPCHf25GbJ PYZnS0eM6JO3kOZ4g+SP2yOj7TsaWy0E/RwGwZP20mZJw9UaX6hItNbYk1auVJrhRWoy5Or8K5TU 1e2n657Tz87KVr7eUVkOz4ZU0cPzIVXkTJpKz+SSUy5jhUTmyLMig6qrCSk5blQuDKj7I+oB6Qae iEbaFcJ6YQIJAWQwrr+kf8NjUDJrkQdJ1q27USsYml9elyiOPbmOrsNINDTHCyI58ktUfK+o1biA zlMmQuGOjqba07Bxnq2NYtGHODTFX3FdEdlhJMlq2RRen7CBbpTFJiKk8sma2q/2BDh+OZfKOQoq du5GnGujEz/aESafHNT0RlKXIiVe4odn6iMCdJUWDc9T+PZ9mdwft4ILNR7b5MHxVvkZutTqVaCj o6gvv+T5R0CPsDbz7TDTGYs7120n4gAtYk8HmV7TwBcttqmmjdqGb4N29En1NKFIZZQNzyeTEP+Q 4M5nArdAvympxv+Az+nnxlr6ipDrw66mzxcH7zHFckV6Op2O5MMO+tfPG7VGOHsgxA/J4Bv9/gdn hUvLZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iagoxMjY4CmVuZG9iagoyNyAwIG9iago8PC9MZW5n dGggMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy9Vk1z2zYQvfNX7OjQOjOK Skp1nPbm2k7sjJ24NtNLJgeIXIrokAANgJbVX99dEFBIeWrfSo0sCR9v3759WPgB0kUGKb/CZ9Em v9ydwMYmKXyk9yZ5SDK/AMJH0cIfOS16D9kS8ioZ9mWwXMHJyXvI2+ToSjk0Ct3bcyMqB/x8yG/h 8st9Dme6bYUqodIG/pLG9aKBS22dhf3zqVcIyzTL3uR/J6vfIL9Ojmi4RaEsCDDYNTuojG7B1QgW zSOat7dX0FupNn7M1QYRSrmRDgpdIsyO03S2ePNzcrRaAOS0xJMpBjI0vnwXw5yCwm2cgRmvm4Gk wGWJJTjtA3A6cYlFx8OiafSWJwktW0W0wI7Xd0YXaC2vLZEEaiWlST+2tSxq0BV02lq5ptwIdgeP gzjMmXBqLxGHLhqJysFW2ho9WKGVwsL5vIhnpHV/+eXr9TmskcjbHssAtEZSHj1ST+R8Zj39Uk4W wmE5HxKJSo7mpFZgixpbnAesmD1xb3BDhWREO2dSFLbEDlXJXPuOtjJayMlnAwX9RbWYiH//TC7K 8eYrlcoZFI6qbyUheC7bGkMi41pSQpMCDMlDOyQtFGhV4DMVamFpDNVUCxA2ZOpq3W9qCn93cfV5 H2pLuywnGOBQUCHHZOZeIkYMOAa9W0JYNm0wlHUUkAk6wCdpffCKTOIn87PbWGVKPEBx8EoaEhJp 87phP5Q+nkHXm0Fw0ZGMnZEMHs6NNnvNAlIg+z9V4kdaLym/3oXjrOmQkL+Gc8Uwld77c8s+q8Wj 1Mb+PmEv+DR4nhyo4fQn1CgoWQGNIXjdcxUfemRjUKiwZkoegt2DtgKO09Wg6FS29euBX/bSs6gj q06RPJtX7RRU4+c1Y71gqYHECIt3SyWdDKf+sFFE3/+HGUdIz235kiFJJJKvKUHpeF54GwlBPcZi zP/AhyAOmrLiRkurZeu30ICnKw3MttjQRpzRfWOt2GDsq74t2pERw3zodh1x00o08h8cLrdRD993 bz43VEvbd5023GxHjVQ0Vo+CxD4/vS3q0WZyl9r0xIA6rjb7BtOxKZTzZaCZKGxgO3QkTSMmDtGi RymGa+3iNP/Rqbyi89DlG/IIn5lxR+GzGbden37+uC8cVyvK9O3uw9ny3a/pd0/F92Gp6GvrGY5q vFpkvHFH3J/CkT+8pRnv8PLm8pZYkTz+dA3twS58wVMPfImubsmTP8FNcdMbI3aD8y6eOklpwjkW 2K5JkFU29/93wPT5dstlPv5OkBd58ie9/gUPpe3bZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iago5 NjAKZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAzMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nJVWW1PbOBR+z68445ndBQZD7Fwo7fQhS2iTDrQpuDu7AzwothJr15cgKQn8+/0k 27m4JBRlEsXS+b5z0dE5fqTmiUdN8ynnMG2c3pzRVDWa9BnfaeOx4VkBKqcwpT8DCL0jz6dg0ihw HvktOjt7R0HaOBhmmsuMa7cv2USTGZ+CEQ2+3QZ0kacpyyKa5JL+ElLPWUKDXGlFq/FlnnHym553 GPzbaJ1TcNU4sBsx5NywJKCP5BhGh25HdidjKaeLm6tPh380vNY2yu7Z8ZGiPGUio1MajtxEwFKW AOF314hSgiqEmo/dcu3o/sA5cTZW7g9r6jaELThBHCIxpbskil2l5QPkC8lqp1LTuxoNerCrP/w8 DNZSBWwlBQu2JTE7rkP3hxVhzZu1mwUB8M6dg+VFl0WR5EqR82DxJiSLdrm4MmBT0OD3ji7YY69L zvvCItXya/Gpj9MdTM57UHRepNtFdFdbMciHgqj9RqIjbxuwQdV6K5W/k8p/K1VrJ1XprmP/vk7U 3ke0Hq8TdX6NCOv7ebq7eGrZbCxaQ202VzAzv5DF+5LvA+4MQ1FRYpqJiQhZpgn8Y4F6lE9oTbJp gtGzaYJ31B5c/o27+KoyAGvUJPkMM0fFjAglI+ZPLOKhSH8qShtOWa2QcvNQc02mIP3S0+oE1vuF B0Ud+dnepnv+6u397anluajSmxzwFNDzPSfueMj+mlqDarrefpzvGI1Nt9VeafyAZtF0/fZ+XKcC dtb6/A5wnU79fE2bQZxneaY4omOf8//AwqXM5WrrhT5jxKgMquP7TQepjfZ0FFwMejdI6LI9rbX1 FC2Fjoklie2RZXdTx6RjXjW4quUtc4kkURSymnKRRXzG8ZPpYzKS171/aMxJzZBKE1GkFsueKYyZ ZDh4aTmQB0pIHp1smRQYxVXTxGU8mIoFB1wRoxngKQce96wiV9bURdnLDZB0vmXeMhYhXAxDk7uw v1JrdOHxdvDtx1Xf2GuIlGnVlsU2bR0zTUtWtaO5gjM6p3ysTYc1gOFodZmwUegy60U4My3zxMwZ D7XIsw2uFDcN4ZqYcNjgJAIBNLILLhVkFcVswWEY3McZzNBfjXZjUSFU3SiG8IzHki8EMxJ4tUny EMFgiWDWKrbCI56TeZI80yOiZc8GoSzeF0oy4/YxjecaivGWxFEiVJ4sRDYFTf/rbcl6f5AvM1hu agldfO1dX1rBuQx5SSR5iIQBPQwwVQfVLc+EscuoMIfe7dgjGnAdpwjN73QdXs+lZM9FDl8+zXBO ivo85OkYulresX0xq12vuxGbcuqaN5vLoPEdn/8BVheCzmVuZHN0cmVhbQplbmRvYmoKMzMgMCBv YmoKOTk1CmVuZG9iagozNyAwIG9iago8PC9MZW5ndGggMzggMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJyNVtFy2zYQfNdX3OShTWYkVZScONFbmiaNO3XjJmozncQPEAmKaEhABkDL 6td3DwQpUkympcdDDQnsHfb29nhHi3lCC/6L97Sa/PD+knZusqCf8b+b3E2SsIDiLa3oxw0WPadk SZt80uxLaLmiy8vntKkmj6+0l1ZLP/vJitwTX282N/T23YcNvTJVJXRGubH0p7K+FiW9Nc476q5f ai1puUiSJ5u/J6sXtPl18hiPG1ThldGiVP+EH2RyykwllCYtKulIOTK6PJKr93tjvczIF9bUuwJ3 +eT7SbJq4WonefdNrY+pySQJR5l0qVVbbALep/dvXq0uXixv59i2fNZlkTMS77Z0wJ6dupeahKar m/sLwqFwf0alQq44mcgyK52bYkE2iJ4a7eRdLbVHsoyjjSeLJ8pyzga5WCCHWGdglFtTkQAcAxXg jo8+DUvTUgGSrl/+RU7qLDwLtKeR9oPygYpBuhHqPA6ycnuZqlw1KSk/J/pYqFLiJ1UCLEtZAbrm yswiitK+Vj7kbuL+I4kR+PYIDpXejVKMMBAOGO6dqUA6orRSZEdmT8vUN2nxGlTjHssbxC5YC9UW wReQhytMXWa0lSQf9g3IVhbiXoGMrUwF60KE+s5YtHtrUmyOUHEzFwsAg3qpPJcWiSrhJV76g2Rd UF6XqPAdZB54jDg9zbI0RvpB8xyM/XLOGvjfFIJj45xtSkJlU1L5qKojyk/FBPknZruUZKPCSvi0 +LrwjO2xPe0zf/3Hh00EwtK9aaUm6OniAo/2IIElpDOVMkGej/GtjId1457mvO5BYTZsxo8FOGaU tgtoLyxuLB1oxINjN9belBzqYYd2sLUi/SJhQ3hxUkYorBPVVu1qTjtk2fF5RISHph3ZbGLauq62 0ravQ8kgDHAnuzKdE4sTNgp4NpbsWVAs7cuOZazT0rjGtLqDDY70+XHTTbJUlWIH5SbRx/YAoRaV 2hUeDeYMzWhb+8h6V9NTyNl50DZOcLmGjkOhooYafbQak1mdBk9GxLEnFIJ7ESXtlDr//ASzA/KQ D6Lal43LRbDclKU58FniSxd8b8sx4ReR6s49IjQU4W0di9tTLOoNzyo7b+GTPkpeLOeL+XKePJrS ozevny/W63SxWKwXmE54ZNpz9RYGDkLFIrvgcY/ySwv61gP1hitYX7d9IMnT+09nsW9j3N6K9boD uR1E2fTGApqUfnu3Oc0Glm0ULNs9usfzUDz35OkgL8kT79C2Xs+exwT32RTQk545DzxhWyPkBJoW QRWEw0RvTOYk8yoU050cI1jzzRX8pSwR9r7VgwT0tlSuQGTRBuZvhMGM4J3b0I3j4ag6m0fMILWm b9sx1gyXzukb9rqJOoACHa0dGKqk0Ng7H0u5l1Qozsg7k8Y729k60DRXke1tPOCj9Er1BZ2q+Byx qt9snf9U5nqZJMv/K8928VCFXzFp/lzj9A7KyWhnHjpg8fC4b6bnIGo3SQczFLRaWYrw2dEMVRaM YVBpq8bUM5krHRyrq3KjjxW+fUEPf/Ali9XFbdAjMlNgRsme8gIyS5ETjSCDdFPh5AwzTu5RmlAi b8HytFVAA4VPU2l5Kb388OrqCkBPl+F4b6UvKiT0HV2n17W1+MIK1+uHPRrB0U8ylaFVV8k0fCDT 8Pp0I3aSLrn/X28mv+PvX7wOvn1lbmRzdHJlYW0KZW5kb2JqCjM4IDAgb2JqCjEyNjIKZW5kb2Jq CjQyIDAgb2JqCjw8L0xlbmd0aCA0MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nI1WYVPbOBD9nl+xw4e7dibQJEBpP9LSHrkplCvhZm46fFDsdaLDllxJTsq/v7eybOy2zJwZMLGl p923b9/mG82O5jSTn3TPqsmrL2e08ZMZ/YHfzeTbZB4XULplFb1bYdEbmi9oVUzafXNaHNPZ2Rta VZMXSxPYGQ6HF04VgeT6uLqhy8+3K3pvq0qZnArr6G/tQqNKurQ+eOqvPxvDtJjN5y9X/06O39Lq 0+QFHmdb5VQGZE/KMQVLa/x1rALnpDzxt0bvVMkmyLuwZe0os86xr63Jtdm8/H0yP+7QSrtnlynP dH77frkcoE9p3QSyAHB7jfc1ENjt2kM2esfmiGgZgCY4qvSWdFWXmj15WzGVutJIxxqJgRDPJmzJ FvFTjUMqxikkHLQPE1BmK8SJ6D0eqkBZzIwESkc+QZQPrslC4xgRrLbW94cJIcY+xYT1iFcbHPNI e/VISIaP8HrxuiPgmrWkSF+/fHw/nx2f3AOg/3R6LznJAQIQuSDQEJzOgrbGU4NYR3zuJeYHbXIv aRlk6SlTRmrkg03RCAUX17cxeg26as50oTMlmNMU/BaF2bGbgsDyEamgUD5ubBBND91S1OJrU7CT EwpnqwGj5++uP9IGhFfKtYWLqhOsA5AXBOlgQMrx0QKRRZVmSaWecQs68wnyDmmDiIz1DoKKUMP1 kA7jCLDW4JVsRGppHcJ3hzfLKakRb1Fa7lD6o3Y2Y+/p9vLz3acLgpZ1LhKIuQpEF3RKxnGUJhTT 1b3dQ7vUV7I+pQyE9qQpxTh1AWURahB3TAm1VetS+22CkuNUjYhqpyUGNgC1ppLu6hGH58Sasoik KQM460JKejHMOSqExky6jgBD1CThThRYLJqN4SasCjp2ymy4LXRuhVps2codaNDKVE6o2SHEKj4l L73J0t6y0RYJa2/dgyzINaoJfT5O2yVx06B4KLfPtiySQyCvkLnUUYrQJQiV1Mp7AOboRhgZlOsQ a4SvmmxLlSiCS7W2TjIH06ELyNNhwvGyEgYT6ZGt2tsyWtuAJB+5Z4WlIhgPtSDCcV9LFQ4Wi9mB 6AMdlNmce92PxK3bvvKiKNX+L4tH8oxlwkJk3XewNjpolP1gzyWw+IBAj1cb7lf7WNBCfG5ocMZw lIMs6QXH+Tj+ZTHW+pMe9rYpc3GpCpV+lM5XWca14HBr2pImDGuUAfj07ZGBYWlOOY3NjVE7pct2 a2ThuT5M0bdktoNlTOMePgqhnSzmaZE8zEoxz5bSLu2jBLUUGhEPhgFE1pRwJ6/RSNEFnwvm6vwf aMZGVJuAHpjrH84gW8MZUCjIUdi3rYMOHQjxYRWYCA0K+dg1vO3glWn9fuQiKUnfrD3mrJR3yMH/ raAIyTwYuzeULK0zJRROF4MnoxJi29M4bsxel2V0VduO/26ydmQO2ICs1c/yS1X8OcAh+50Np+8P kYHeZ09nJ22xfxgfc9jglw/L62cHyLkf0mHivJ29PX173x492usYo96kJo2m0X9heOJmnFacwjD2 PRLXVcW5mLdIsutFMKaMl+IPdnaeiE0iH3Tkrwa0eBoMy9jeuyKPOHDNW7XT1nUCFwviogC4RKzG 7XJ1hw/rOCk4SNHVOGvdUZVsXKoizxVmyP7XUNr7pqWzV31K7kncajyt8OL1aeTwksO2Qna/0VV2 1TiHIROvD99rzAZPF5j21Rqox/Np/FZK4+vrjTjfm3sgflhN/sLPf/rtrzplbmRzdHJlYW0KZW5k b2JqCjQzIDAgb2JqCjEyOTkKZW5kb2JqCjQ3IDAgb2JqCjw8L0xlbmd0aCA0OCAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM1WwW7jNhC96yvm1N0FvKllF81uCyyQerONi6Z1Y6WX ogeKHllsJFIhKSv++85QlGM53m2BXirDEGxxHufNvDfUI0wvUpjyJ95lnXx9dwlbl0zhR/puk8ck DQsg3mQNP2S06B2kM8iKpI9LYTaHy8t3kNXJ66X2aDX6tx+tKDzw9Slbwc2v6wwWpq6F3kBhLPyu rG9FBTfGeQeH66dWI8ymafom+yuZv4fs5+T1/GJGH4B7h/btagmtE1sEUwTQN6+S2bdhGUVf0bN+ jS+FB2k0bVU78Ib+UA5cg1IVSgqvjIbbe8rJISXkSxzA0vkAJmO2RAMtmAa10tuw1FuhXWNs2EGj ZLQJEKl+qdB7uLte/kJoRzgTyJGyQRDeY934AGZAtISoPeeEAZwZQKd8GX7dr6/vxjhUiIweFKaq TMcg+CTqpkJQVdU6Ss2jg47pC/D7hoArqMxW6Qjj8LFFLRFqtS09PTIPUKkHpBjUh0oc2FPVKKPN d6M6h2vxoV9Z+OYi5nBBUaMahmv9AWazaeg0CCmx8biJyQxATJMomeO/KWw+T2ElnOuM3YClxJV9 Ebq6Wq8hF/YkdDafBsEw9y0SDz1isCyoPINYWAOO2gZis1HcTNblcRHOdW7E82wXJ7QF3Xa0CVug sUaic+elOTTnpUC9RVrPmJ/LTjCmabcl7fdSd9DRc2LoKR3NVXToDykGq5jw0/k+d9oMn5R77lEv al6SLVZHig/AhbLUVaTgvFKuRJbnJ3JCFMQEFBU6AgVlR4boAmJnDRVzF2dByQrJ96RMwnugYG4M V3tAcG3ey9ePK9CR9okZpVXsAy5aa+ypUyLIZ/3CgcEp/+yRCHXqFC4z+E5R5CCZnnVJpcqRYo+F 8kVTGfOfTRWAyBknQP9rX2an80eSLfMgVl7Lf+dK9/Y4DMmrxeI54MSZG1UUaLnkLO8cfRfaENry ysFOWGVax/xNq+kkMvxwsOGgzMiB9UmiWup4mkjUHD4Z2SkOkxOBlkqWR8KJYyEcZhiGgDUt5SdI wjvl94MppbEs65FDvj/CGW8qqQuBacVDezitQg85idCRmJH7Qko7UakN2yLspM/S02eK/jzA9uEM PJpXsbzUQZ56ffv4LSAMnmHjCKFYqzXxCMv+1XEnomOZ+jMdHjL0liArxbY8EA8jbsgzN74cmsVE mNXkoKxRaXh0NkZzv0yt6CjoX2Ryi9wx9nI6/SbI7gZ9WRPDr+BW3rbWin0v/+unhozi4CNKrHNC nKeT8LID4+uPFb/gvP+TIK+z5Df6/A3ZIP5BZW5kc3RyZWFtCmVuZG9iago0OCAwIG9iago5NzMK ZW5kb2JqCjUyIDAgb2JqCjw8L0xlbmd0aCA1MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nK1W224bNxB911cM9NDagKzqEt+CIIB8q13UjWspLYrIDxR3JDHdJdckV7L+vjMkd3VJ HlqgkoW1lsPDMzPnzOoVet0+9PidrrJo/fR8DgvX6sHP9Fm0Xlv9EADpIgu4mlDQBfQHMJm34r4+ DIZwfn4Bk6J19KA9Wo3+5MaKuQd+3U2e4P7TeALXpiiEzmBuLPyhrK9EDvfGeQfN65dKIwx6/f7x 5GtreAmTX1tH9dr1xwgz92UX30RR5tiVpjj+sdUfHgZ+Ht8+0zmGFndvP43GY5gJe3B7dH09gdKa ryh9n9YGZzXeZKkc0J/InQFvK4T1EjX4JUYuMqVEIZXDDNbKL8Pq6PPkHmhlj93oZtRscRQmPAiL kCknK8fblYYvz3fXg8Hg4oV3h2/vBv3zly7AA5+rXOLuJGphlemE4+hwe/L0AA4ZWeyTWy+VjKwo ahUDaUON5A1YU3kEIb1aKb/hOxwtjbVUEVilXi2pV+E4vXfmLtRO5ofZGtC4MF4JOilykZXl0wqU S6GVK1K9GMhijiuhqT4Vn+eVFF4ZOtf8jXp65KbH21I3SX3Lra5VqArfA2kxYzxqKN1QehHCg1yY cxBIw7kpXINTl28lcpVRJo76MpqT5HeKXNflcfRXOJmAg8ISSN0VKogrUar5hgLok2WKU6Q6CylN RbkrTU4pYuLsme8RUWyDgjIKYV1WLFJwnps1J5d8AirPK+ctMwbRgLxWsRSMp2jFzEHmiu4diLTm OTNU8iSuba+Ce4ItqqRhafTXSstAfKdNqd/fGCDh/BsbdA7bTkpxpdFbCZpCeY9xyMwssp7f71n6 P8+SIOgPjUpPtCjw4+EEYa1/mAmHZ+9IF+Jw/X+ZR8PuoDukFo89e+hGiYUVRZ03992FhSwtcBl5 YHDlQyu2IgC/KclSedKApN5Tvfayr2XKH4tlviE40jkXYYEwQ7/GgznAkY0wu1tabocSj7vCZOTu DEzc7lShcmH3aNeMz0iSCYgl0Ls8vXzp7nWThiIKMl7aHafh9OiKBkR7hgul26kqPMSdqwoMzjOS xAgiODfaaps5VUiTpiy7QOvEZCnIHiVqzDpg6p0Cnm8ffmtKRTG1tSopkQZNRt36RPh2K3oaXhXx Jbi7W9JM0Pnw4vKFCAc/WOqIoirpWisHE7AQGzpohbEdK2a0X5FRM0jyTYco+qVFPMnUQvmmkRmj 8SgglZG13Y6bKOBABxnykAMeljm3koGIiEhopSBD7kDSLNsFC1mlVEJDXG1hSjaAdWhKSSw9zxBK /PucAg9onn4ZzpWOGhLahAozDyJ6R91Jjubs91i3T9t0eE4Ttoxppsdf+7TXa3f40o+XAV3Qy26n ftwborPlEXVM5yYIfCPKztFqzUtFbSdV1rRYqM34j8lajA1KSKVxTs2IMD2QKRLd+6glx8IZT487 MBcqryxr/I6/MhRaS+jTo9vpcf0zoXlQ7E+EGdJzAdbBs9F8m2JmcrgK4zIZJoJuVxPUnzFmLaiQ /F8oR5u1dzoIYrlHvyyoIT/Ao3ysrCWhhtftW0mCdnCDEosZdWrY74TfeLD3+vIkaLD0ey+EeDtp /U7vfwDAYEi5ZW5kc3RyZWFtCmVuZG9iago1MyAwIG9iagoxMjAxCmVuZG9iago1NyAwIG9iago8 PC9MZW5ndGggNTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVd9vmzAQfuev OPVhS9Wkw9Au3R4qLWuyZFq3LGHZw7pJLnWACUxim2WV+ON3OEBCIU0yIzA29913v8wtwTwnYGZX PruR8WrSBU8aJnzA2zOWBtECkE9uBD0Hha6AWODMjTWOgGVDt3sFTmS0RlwxwZnq3Ag6V5CNgTOG 4ZepA+/jKKL8AeaxgFkgVEJDGMZSSSjHx4QzsExCTp3fhv0GnE9GC7dHHBh1fYjnoHwmGTwE1BM0 km2gMOmPPoOb614FYQiCqUTwTLQQBBWfvjSIXSjMPt21enencHLPvICfgFRUsXMUsl4XQg4K6e1S S8BhEHiJYOi09OOVRHr1uAhc9ESyZcK4yzIj52G8wrlC6cZciTiElc/4Oh6BhESyzGblw7dpfwKZ B+N30ymaC2HsZXz4RlFPpmFBhQrcJKRCx/RPHkIfQ1g1fGucdTqdM5w1Ybkmbbt9WbFua6TQg7RT jusUvm+v85Hb1EC1a51rrwPrMngdAbTal6aJt6WBF/hG8EYPzYvdwKo31Y3nGBssq32cNQFnDfKk AtQB2x1XXSHFumo+5qjfZG6mtpZKsI5hraw38ck9/XVcNtMSuL8M7CKbhwCbs7kfuCOb6fHA2gFp OiI1HEnL7XQH09O62SByzus9GdQ/lHJtFRrS9WN6cN08Kblj6mZj9yHHf9vFQxHrOvlfDnjGoZ1Q 2I7P4DDWWpmUrA1/76LVvAUn7zHYE7AllJ1GNw79Z8/bX6bHIlrRkCk/ijm8gFv3NhGCPq6V9v8u AsEk3DCXRfdMgE3auuNW7fwxph5Sk5+osu8YX/H6B3fTmIVlbmRzdHJlYW0KZW5kb2JqCjU4IDAg b2JqCjYxNwplbmRvYmoKNjIgMCBvYmoKPDwvTGVuZ3RoIDYzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnictVbbbtNAEH33V5wnaNW02E5LAg9IlCYE1IrQmPKAQFqcjW3kS7u7JkTy xzO+JXbjOE4RY202E8+euezJ7jxAPzOgp08x24H24nYAR2o63tNwtAfNyAxQTHaAS4uMhjBMWAst X2fA7GMwGMIKtKMPoeIi5Or0SrCFQipja4rJp5mFd1EQsHCORSRw5wkVMx+TSCqJtXyMQw5TN4xj 65fWfwXrWjuiny2XQyqmOOYecwQL4IUYe04syBrSjZYSimwWfrREtIAdhUpEPpYuD8Ey78fPNaNf 4tlFJJ6E5KEChcoFGcaSJpdJMF9wNl9BxrbNpVzEvr+CHzkOn6euVQRGgCnU7yIRlxLB0lMuvsxG t0jRp29nszMyM1+WftvltFVqCbRKsud1Efl/x7g7GOOE8jyhOaPLWjd6/d5FZ4wEl0g2ZXuT4GtV L6RbHLv00lMbRoN5Q1E7YZi9C12nYWYY5/TNoEFF0c87YWylvl2IfRitfCheVva7EaOJD0YNo1bn ln3J/mKlXs+O9nu0ibaRH9jmB50iT4mjpm8KWrj/sacej6TCj2SNcRDH+iU/DsTYwY9DMHbwI/kn jIZTsGreAcPYuE6aguzE00r4BWeK/c+PqRZ+pDfARjdLqCT/mG142JGmj6iewR5weiW7c94qTHXq tiLn3VN9oCWhnUtRrc+4m9ctVq29NtzTZY/xGteRQxe/5A8xD22e3/SC33NqSuY5EYqmIgXShxnS hCs3iEI8w419EwvBVjnq6M+9J7jEFbd58JNajr7Ry7qeeqDfpszh1Gp9J8iRpX2m5y/KRMOxZW5k c3RyZWFtCmVuZG9iago2MyAwIG9iago2MTEKZW5kb2JqCjY3IDAgb2JqCjw8L0xlbmd0aCA2OCAw IFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nLVWXU+cQBR951ecp1bjruVDq+2DiR9r baOpdak+NH1AGGCahVEY3G7Cj+9l+JBdQHebOIQMM8w5986Zm3vnEfquAb14qt6NtA83BwhSTccX egPtUTPUAlSdG+HEpkWHMEzYvlbiDJgWDg4OYUfa1tdYsiRmcnyWOL5E0c7ta1x8n9o4FVHkxB58 keCWJzJzZrgQqUzRtG9ZzGDqhrFt/9GsT7AvtS2aPvaJFQ6ylLrQSTETQcA88HgEJ4bjeVxyEROf 47oiiyUiZ4F7hoQ9ZjyhlfeL7feaYdWEMmQgrqeClTxKH5jLfa7WqX/ujDNioVGW8jjA8empDbf0 fxe44zIkvpKJp+QHIh57o5JXOpLB406QOFHx65wHWcJgIQ3FPKVtyMUDd8nZlLxjscsqKuHDn4l5 0bsilomYYR6yuBSPrNDuPczJNH5OJzfK8evj6RRSFHoUlqSoqEiUQvanSuWQVFbr1T5qKsKVG18o EUvldonB/Fjr1Go74/F4h3rlTTM2RtZof0naVstxgnzctKMcd+1x1SqXe0wNjSv2LrC7hp4NgOZo X9fpNRVwj74MemmH+t4wcHk3qxPDFns86/zuBd72rDZWgLfDqqrgqcfLzh+puS60oOwcJMy2ADQ3 6XO39yxraXIFHrLaI0ne+srXiACrPshXMP1n+CJm4PjyN8e0/VwPY+TPdgYxq1H1OqY+WpWEmrFZ H+vGAbUSizmmawfUkiybBlQdVmsHFMXTa5jBpIBGnrUDRNnKn0/kbYGd5LUOkMpA3rb4ErAv0MwV 4AvpS5UwNImkRP1P+iqyQnvufMP01Ym2btmsK/9nXIqA6nNd8MsqrippU5Wr20VaFNO9sppeMBlG IsY7XLlXWZLQnUa1yd8HutSkOGMui+7pDmMZI3VrWvb917UTMBjWb6Kc2NoPev4Bhvv6y2VuZHN0 cmVhbQplbmRvYmoKNjggMCBvYmoKNzA0CmVuZG9iago3MiAwIG9iago8PC9MZW5ndGggNzMgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxVUsFS2zAQvesr3qmFGUhjBybpMSWkoQND CqY9MBwUeW2rtS1Hkgn5+64cxwVpPGuvnt++fastxqMI47D7qCrx5WGK3IkxvvOTi62IOgD6oCp8 Sxg0QxQjycThvwjxBNPpDEklTm5qT7Ymf76wMvMIa5mssbp/THBlqkrWKTJj8Utb38oSK+O8w7B+ tDUhHkfRafJHTL4iuRUnnP5dUA1f0IFH9TzaoXXEsQ6pja6l16bGTvuiA4fCjlRrtd+ffhbR5EhH b55qx1jHOOmxI0vM4q1JW3UgfH5YXsVxPHs5g/Z4XN0/3S7QWOJjCuTMF5iO9ChYkCvkXxoBScHK ZFmancPGsBhWac/XNwii+fWVv1hbT9FYo8g5Yi0GlWwY9d8yTg0lUuklZMP4xmrpqdx3tQYpnnNI tcytrEILS5233NcFXBGUSPh9oxV77mjbUq0IJkPGKkNUJrRf9ly74Hcn4OjxYOr8KVl1jcwX82EU vY/SBgFOtdxO2lO993LEucvZZTeGFfmi4ml9wp26a62V+8MNuH5rtGUzFmx1tSGLSXTW3Qh8WM9r mROiixemvE7ET97/AGkz1lhlbmRzdHJlYW0KZW5kb2JqCjczIDAgb2JqCjQ0MwplbmRvYmoKNzcg MCBvYmoKPDwvTGVuZ3RoIDc4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicnVZb b5swFH73rzhPW6uGFZuk6fZQKV2SpVOrZoWyh2mVGHMo04AFiLZJ/PgaKBdjLibHQs6J/Z3P5+LL HtR3GNS0vfa2h84f5uBESIVP7HPQHuFsArx2tgfXBpt0CZiAsUM5DgPRYD6/BMNDJzd+TEOfxsoy tHYxpLI2trC51w34GHie5f+EXRCC6YbxwfoNmyCKIyjl88GnQFSMT41fSHsPxi06AU7OFEU5Y31m sdTxRJvMTt8irLVAEriGRCnlKoGvdb0QBu/g6tIL+yJSnMPaGCSZzFSVfSRDTtkvzD7mpDrtQfIO Nf/o4WxbnDDcijSPRBaxXDwam0pnjg4i04G+dF4NcnbpfX7WRNOmQj77kM2sSCO5iSRjHYMUcy+B NJu8TGSykscygcVyUe1Lqay05pMFWZ6T0+vu9vj51PAz4fuB2B6HbFRCMzkD1dfGOYysJ5+wmEoj k5bjRBbZf5zko2YL0mw7TjCPzJLcvbcf9dVDqTfizEprJV+BZBQvp9cjlnv7NO6OSCrk8O2iFXeE FFJIKncsyZ5G4rLHINs2gQQQV1st6SRrVlBtexb5HUjldqHrlU4qG/nO14+5lGR4Rb3glSge4RiS wtSL5jge6ParGwv1QK3leMWiKXnJBf/qW7vOIaQw/QC3geP6ENH9gfo2hb9u/Jy/HNN3aPr0OM/u Kzt/mUbM1sUss7Wh8bMX+PAG7uy7Qxha/3PTq39/3JBGsKQ29X7QEDQ8yR6s/Fq/bS2HAp59ZxZX BvrC2gsRce2sZW5kc3RyZWFtCmVuZG9iago3OCAwIG9iago1ODQKZW5kb2JqCjgyIDAgb2JqCjw8 L0xlbmd0aCA4MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJ1WWU/bQBB+96+Y p5aKhPogQF+QQghNq6JSYtIHRKXFXttbxTZ416SR/OM7PjbxmTiMZa1nvd9c316voJ5ooKZP0Vq+ 8vn+HFyuqPAVX1d5VbRsABSN5cOViYMuQNPBdJQcp4FuwPn5BZi+cvQtEDQKqBheR8QRkMqNeQez n3MTJqHvk8AGJ4xgwSIRkyXMQi44bOR7HFDQVU37ZP5VjC9g/lCOsHvsoFUgEHNsPMJhGboutYEF sGLCA+FR4NSKIybWYOVuOPYSASSinz4qmiFN2YxbMec5+PH+ZqLr+sXTAEgAxLaZYGGAYRHLCuNA gE/W8Ewhoq8xixDzvE59ocHUFAbzloaFKfEXajGHbUaAtWQU8ajFnAUujCcTU0Z2AmCmAQsipCmb ETcifhrTDXPjiMIIuBeuOCYt1i/Mwpg4BkEDi0LogLMMV2lrhYGIwiWsPBoUprJSM57Wyt5WZ/xg zrJIx9djs1SiMC1l6ha/sATIVWHmrSDIQ4JyYJqBtIuj85TXWeHyap0gVD+ThS7J8XA4PJahbXRt YAxGFW5KksAVJMONXCbwu6xLKYJt8dWlS/tNZHMMPocg9cFIVfHVM+Qpfmn4YpLqaTfyuJoQ9jQ6 OpBtwTX+tyIX70TKWmaTaaNjonuRaf9OOi/3+ezSd+VZEsM4bfK5A1knoTeyMlDPvB6CbFDfB7mo +0Xpw0peyyTfE6Tei5VWPrHI/X1W9Eq63Xn+qeWZtLWdtX0fsjYTGuTsnn1tPvcjK+Trxqg3Mmnd Pfoh92wnnchF23ai1ZGL7pX9MJ/eb/RalS+zzr7zT5e/Zee0945SXug7/LaUJSl/Jj0OFkMeD/tA DSq3MXaCulhMDgJV3PYDadullC+2XidPD5Ck6248n291Hcqz/aBpUp9iCcwPOXj6TM+GyPyKhPNE R3p28ZlR4flhAB/g1rqNowivnJlM/73gnZPDNbWo/4wXTUMbZHfjqunHO+JS0M6e0OLUVH7h8x+O nUVhZW5kc3RyZWFtCmVuZG9iago4MyAwIG9iago3NTcKZW5kb2JqCjg3IDAgb2JqCjw8L0xlbmd0 aCA4OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1W23LbNhB951fsU5tMZFmU ojjNQ2ZUX2pl7MaJaXc6nT5A5IpChwRkgJSjjj4+uwBJCZLiCWUNRQC7e87ZC/0Eg34MA/4097SM Tr+eQW6jAfxB3zx6imJ3AJpbWsLvCR16D/EQknnk7WIYjuDs7D0kZfRqqio0CquTCyPmFfB1ldzB 9ef7BM51WQqVwVwbeJSmqkUB19pWFrrrU60QhoM4fp38F41+g+QmegUvXSPYwOZtb7wB+sEXPb7+ NYpHx01Pgmt3wZm6RzI/MNwci73Z+XPPP2W5j+DnLOPeaBPEfMny8Yin4b7l46HlG0L0hu6T8/Ok e26laYB/dIuHtnxisyX2cQN/0RplZocxLV4dQ9zGDZ7DVG3jDt/tpPZK5rVBGH+AG51LBRafalQp wrOsFr7quOImD8n16eRikpw6aqkvRMtIRv1RH/zJZhnQGG1sAzNZIHk1KzQnd1O4v/78cHMBBpfF 2scQMB4MgCp6PBg263IOFVmxz6AUW//SQq0MpjpX8n/M2LhWslwWWCK1T9YPWE4sZNKmtbV01FFM K6kVVb7mOOQs02nNlj2OLEIutG1pK8BBjYmGDtbECxbCwgxRgagJtKpkKgiCI+Bpt5wzDZqa0wXF Rpy5Lgr9LFX+IYAsSNF7pOgszqhRhbteKGKwEoXMtpkih20++o3bGdknBkXV6djxIbTVQtc5C//1 cvpnt/EsPFPO98EAMGjRO2POnMhKe4oVsaVfFAq/ScvMvTq8uTS4krq2OwUbYNkNSRoSQexikK7Z EV17O77YircIXVUb5UzFcmn00khGtZVtX4W9AiGR4+Z0k6sZemBNJS5oyCpRIuRyRfG4JtaqEimD Kop1IFeTn56Dx/l7+0PXInQDzrAh2IWkYEqTRH4XVs3c531wB1qCvtoo81PSrCgaP7ZOF5AKi7a3 c+qE3ymkVIrWwu0DKRNU50t1Oc1Vm6ewsPibVlxgh13EyWQWnNCD4mI5+pwGV1sBssnfPsPWN4Ot Z77sq8D9Tk00IyWT8zkaPtfqGKacG+S80NbzSLVSfii0DTTp6pzGDMoVKXFsUFET7BH1SQ6nhbU0 XXyPVMEwzDT65Hazq0uvP0STZU1IKHqD66CQ/XxtwXZ6OQF5Cmko3Fz3WdkOnh9mx2djrz+OiKH8 lG+FYHI8STvd50aXDm73Mtgq4k4vxAp9xAxtauSM4C7Itu2TfdlaZRxy2c6UWomVkIWYFeg7jmZP KRW3P7Oj1wKNDUqsG43vxg7BNVaLkl4Av8BtelsbI9a+di6/LSUNOrggluWMRtAo7rn/pcKX7T93 IkeIz/4lj5dJ9IU+3wGWOcprZW5kc3RyZWFtCmVuZG9iago4OCAwIG9iagoxMDA2CmVuZG9iago5 MiAwIG9iago8PC9MZW5ndGggOTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyV Vl1vGzcQfNevWPihTQBZtaS2cYrCgOuP2kXspLaSogjyQN3tSQzuyDPJs+x/31mSJ+sSB21P8BdN zu7Ozg7vjg4mUzqQT/5ZNKMfbl7Ryo8O6Hd8rUZ3o2ncQPlH0dBvC2w6pOmMFtUonZvSbE6vXh3S ohm9uDSBneGwf+pUFUie88U7unh7u6AT2zTKlFRZRx+0C52q6cL64Gn7/NEZptnBdPpy8Xk0f02L N6MXWD4mz+6e3f67SwprFchxwfqePSl6f3t2Q0WGDpaWvNIGu5hUh+8m6EIFbc3L70fTeQ/o+a5j UzBtdFjbLtBa3Wuz6nFL4MaUe9zbi7fv35zS9dsFtnzmIkgAIArWbgITopNaI6jHikGhjaAiK1YO 6y6S4VsudJXT8lTaDGRsQGKIthvaA/JS6tGAVJ5jZYkNujr+mxRyUZ50Rd42fUolV6qrA91nltdg GSWWIIcN8UNb60KH+hFANYrhckw2wbH0j5TJQGwAYU2D5UQ8sih1VbGTlcrZJi3bCmcA17WtdcDr I2cYie/H1LJbq9aTRZPRo81aF2sw3RnwECHqmtS90rVa1mhfUdhOmOQHjeMZSrqRDraOfWRaGbr+ cH6bMlFtC669cI4OBIU4vluWGp0N1mnuceLmfodwGiFEmpLFV4WkEiY4PPs5img++RGdOT87FkX4 Fo3keHq3dznUX1AhNrX1YxaDhIsne3l9vDk/mc0PX38ag44sdVFK62zB3g+kGxPP+fkINVDq1Xv8 oU1RdyUopFqD61xmjL6VrcefYHljXUl7ArGHehYis7jUy02jMON1wFSMI/mikqVI0ISMBAKl+Y1+ CJ1jaSSyg4rARm03+EWAxmBww6JaHfpxyjAAyEjpnGyPuUS9jWONW463R3956kXvHidHkdYBXfG5 PaLZdLpPv0qeJfvC6VYqosAP4SgH73fSZDL5ckn4+fdtiEFnse1PiS2QPNe1bj3cSptSxp6prRXM Z23rkqHVzZqFN9TpqGIlLHpq1COqHNSS21qmRiicEctw8DLIu5ykYBiufd8KPKKB3egy0pSn1ucY URxeOi3KURiPxyclSm3ZgEXot1x0TodHmDjUgKyTeQ1KPRZv8EXnPeZG5g4jJ7HnKbpYhy068ZIn mZNu2pqbPs9BuVHKwbFM9VDkcQY2sL0onyVj8ETsHTBhcz7aXO8XT5eA2LpMjO1WYjs3Z5fXW8Qe LFObs+sFPsgxTsB/SAv3n1hpzKr3wZzb/80q3QGsRSEZKjUUA+ELNsppmwflWVoTleKXuxfX8H7c 9fpxSkmqsV1diiXaTbQ3zyvHq75XgrLksJGSUvCskh0sH8+xgmMPriMrriH3Ye9HMfEs4i/SLxn+ VfucwXMxMC0Z515BxitpD+63pRItWpM9JA5KOgD+Yk7fkmF/19g2ah3W6R994CYJBO0C9X1aMol4 iZC5SDQUODUcOTh5sIWt4X64cyu5OoSVByVxZRwG3OxV1k7yPycQw15iK2PFd4iUdqNX6yAKE8nm 14ooOKMajpm2yvto6DUu0bFcnTXv5DUMu1Tuq7CxIEF7Pmz/xrF9Kfh29KRi38VLv5ftOMlSGN7e zM8LSYzKsNyH0mGRguzsC0iZyb0PmJ9m0UMuOKwblPAdXRVXnXNw1PicPbRaLPYUaM0S9cyn4/jW SYPn4zu1YpoefgLi2WL0Jz7/AJk/l2JlbmRzdHJlYW0KZW5kb2JqCjkzIDAgb2JqCjEyODAKZW5k b2JqCjk3IDAgb2JqCjw8L0xlbmd0aCA5OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nK1WUVPbOBB+z6/Y4WauZS5J46QhpG/QwEGnkFzw3dxMy4OQ14kOWzKSDM0MP767skIwR+fu oc4QYVn69tO3365zB4N+AgP+xFGWnXfLCaxcZwC/09+qc9dJwgKIgyzhOKVFh5AMIc07zb4EhiOY TA4hLTtvz7VHq9H3ZlbkHvg6TRdwNr9K4aMpS6EzyI2Fv5T1tSjgzDjv4On6VGuE4SBJ9tN/OqMp pJ87b2laVBUKC97ADa7FPYLSGVZIX9oXG8itKUGALBTdQ4XWVSi9uscuPKxVgeDXuP+mk4ye8GQI 7tDeowVVVgWWtFV4ZTRk6IUqHAhLcazFAu8FwQrPMFBZ4400BeExEj3Eok83w4Mt+BXHJpxk3E9I WpPDl+Xpx/fDZHINmXKydg5dwKod8uO/++PBFCRar3IlhUfXIstyRaaipm3a8yKK0AdIxa3SqwCm NC0smyMEQfyaKGdG1ny0SFdp0lBIaWrtWRzUBC1ryyCcJ2LmCMDBg/LrANs89hsoUa6FVq50ESvg s0gZ5kpjRuC7k3a32WiL6+DqbP7n5xnQaVS+eY7EwdbkBi3KkLANcBZpEeMG5YWlR2SvoAjPBFfJ xlURigSQ6yivYnsw9YCvXARUDdXmcCzrG9ekIEI8SwSvMzbDYL3KUq7pRBStp3SP9vdKlWVkL+G9 kLeubYMjWKFGSzaLSefEULaVczURJF9RgIyBWzLTCk6EFJq8/sIHtX4SeTieTK45YCySMZnh/Ojy iIpMOzq4beRuMQrPFYe+IwYxuMWVciwqs8hNUZiHrRnwm0cdaLNjbEbzLUKROlWExKwmIxCouCmU WxP0zSbwHE+mk+sPLRq/9cIVh9Z/z+7+taq9qEXkkTpTxsPpyVEKYSJDJ62qQjU8gt9UyKuMzmkg Wr+4d0vM0aKWlAtuSo8x+49NI3okITOE3QRs59vDpaFyhRfXFutnnbThFdweh2ZiWy3hTjSDaYb0 ePaS1c/ntcspwOU8PYF0zuLCyew8nS8/wKJAQS2urjKuJaYU607cGGribBZ86jStjL5+6bq8IadS ifg1+Xjb256VwQGVwS6xO4oH1IqJY9MgKXRrDQdkrw6m4+k1wIJkxaILn/rBGDQscaNNkbku7J3y 6yS1QjsCgMXuZfAq969vqY6+7u914SqdwbQb1KEoXZhLb/gsyfRw3O4bzCQZjN4Tkwsjb0WF3ioK vehT+JkpBWl4SVl30ONil1j5xsGnQqpCeYVur/sjQkwjGTU8OEiXNLnHMjKZvMpk/H+YnLffoU1D fp1C04SbV1hU5hml8X9TSoYjonRsBfV32sdsltTSlA0EXHg9bH+HxB8Yvd6P6BxVVRHJBBWv6qoy 1kdiW14UspWzKdM6GAe8M/Trknb/ChfyorZWbBrkk28VUXIwQ9kcZ5R0w2+bNoEvC7FCwrwmxJO0 8wd9vgPMT6nPZW5kc3RyZWFtCmVuZG9iago5OCAwIG9iagoxMDkwCmVuZG9iagoxMDIgMCBvYmoK PDwvTGVuZ3RoIDEwMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJVWXVfiSBB9 51fU8WFXz4kZEhBk31BkcAaVlezuw8w8tEkBvSbd2N1R46/fqnygqHlYOBzQ01331q1bVXmArh9A l9/1d5x1vtwOYW07XfhKn3XnoROUB6D+ijM4i+jQKQQhRKtOdS+AsAfD4SlEWefwUjk0Ct3xxIiV A35NowXMbpYRnOssEyqBlTbwtzQuFynMtHUWdq9vuUIIu0FwFP3b6Y0gmncO6d8/bqfnYRCMfgGc GZEoNB4sfQ8OvmMBT9oktgyaWwSpgA5bcBouVSJj4fDo907Qa0K9ed3iQy4NZqgczPERU3vgwdn5 AoK+x0GAIT24EibeQDAaDX2KFA72SIXhKZGaaaOfpHuhwz5wiksf5rlyxJCzX2KcG+kKuHh2qKzU ipBaWTEwhfXgJnb6Dk0bdO+U9Zih22RaebCokG99uEhfGBiFyw2CwrV2UjhChQzjjVDSZixXGwG3 QZjKFCEyQtkVEVgY7XSs04NaFkL2YJyvc+uY3Okn5Ab9LpE7z42TxO0frlVljZKISOVLxUivPuK1 EXtPgzA8ckxaMInRRxK9/ihkEmQxTFNNlJnGIldFrBP8A8ZwprWzzki1BlT0T/5BjP5Skk+08WCr vUsGE5joTJD5rkWGll043m5Tth9XmyK9i/Hz8HJyPf55VOfCVBunhd1u72My/TAYUjJTMvvxLHfx RipblZ1yqgxG5NltZMQN3VzWofliq9kaixHmyUfMk7DXZwGNju+55SaVxchpN49oSFOCJhtwA5EA Z9fTUpploZx4bkNcbjGWq0YYKgJdq5kyHBVUqFyYgim9NdbAD30g2Qkho7uPSO1LXqGyYSMvUw5G /ROeEjyEjD2eI3oQkURTiSmXl5DoL85i5sPUFNYV95TFrNiicfjs2mh/6AU4PoZZFC2+BH635s/Y XMTSj4NPmuJkyCUcpymNwbej4oYMSlkp9W5etJE5J+VkgqbSsGkHir5D/6QbwkEwYAPtCfEVnSss iU6/r/Q6T6ufO2Fmfqt1roSV3AQezOnGHEW8qdzISUX+fgn2BP4f0ga7Xg8GXrUdPs/uZDhibb+n PF8VZ1HyGPs0m1GhrZVtVhB/dsO4fT+sJU2HorEnQbz2aNBlEvWKol5HWjbPjEfTgzbSvbijiTZO 6ynxWJr0lfIkR95QPPpS3jw8dWyst1h2kEjKSSRodj9BXFOm45QByQt3RuJqj3QibZxbWw9Um6/X aLklxRt8DiCqRRy/UYEoSFMXxaCl7iybK5WZdJW/QFp4EoaqRCEpv4hIt0FsRFNgQaunpkWnaB66 DcURjVAbQSB3iAq2Rm/17gzCVljam3d5E4iNVa8JXu8JCqZjIUHa3HzL5iuaJ5K3OIvHMQwdYubM h5nUoVJZUuYBSWBlYMv5vu6hhh/Xlp9oSN56wcJvcBVf5SRDUbnj4nlLDw8WJhhjxjO0F3jlo8u+ iX4sxJofaX5RxIuo8ye9/wPb2aIOZW5kc3RyZWFtCmVuZG9iagoxMDMgMCBvYmoKMTExNAplbmRv YmoKMTA3IDAgb2JqCjw8L0xlbmd0aCAxMDggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJx9Vl1TG0cQfNevmOIhsasEQcI2kIdUEWzHdsUxMbL9YPOwutuTNr7bFfuBrH+fnrm9406Q iKKE0F1vT09Pz93S8dGMjvknvxfN5JePp7QKk2P6A7+rye1kJhdQfisa+n2Bi85oNqdFNWnvm9H8 hE5Pz2jRTJ68tVF7q+PhS6+qSPx6vbiiNx+uF3TpmkbZkirn6bPxMama3rgQA/Wvd8lqmh/PZk8X /0xOzmnx5+TJxdHsiOjDnfa1U6WxK4prTZdfXlLRAj79eTJ/IZcC4QMAQlqtdIi6pEbHtSspOtJN qlXUpPj4hlxFd5nCWihsXapLWmr+GoCzkw6QDytqo21kmGCaTb2joFGHogOwOOhoEArWHp+s1UUE zymlkOkCkbGGR5JVDegEOUD5VWryEXvVofbF2mSCGUfVtdvKhUF7CHPIGm+8K3QIDMEkdYuHaypT 48LovA5c9+N0AlMJaXlYGg/6zhtcbSwZfPPX59fXHY2srXH4KmQcEUXz1Si+0Js4Jdaj4SoHBHtW im9nqM3GeebYI20N+pUieX2bjGfxlN0BtUQP1sriZPD4suaC+K6uv8yr5RBdRip1KLxZ6pbKUJMp asLZVaV9oMq7BhxBETqUXm2Xqvgefh1ZSknteq/bOFPdKVOrJY51FqZo+8+KJ1R9ePWW1iqMvMQv lXCFjaZQbFDIq+uqa/vDbsrRKUy55bkyetC53rutbFrqDWvl2e7MF80aHAvxB1ChWEMWMmKMHVMv h9oejaRYMh9HjfquhfDI0NEnqBC9smGDs1lpjX5mTe5reyBJ51yrdSn+RSmNK01l2lKMLepUssF4 dqUAQCp0ce22YVCLnLPRhQElq2KCAGJ4VFMZD4qDuaJvT6xeKR7U1qmu2kNS5Z2CWVf3IK1W355O CRGGjkijoVQSo7eSBIz1AMiUreq1TBEE01tKG2cHOQEmIr3A5H/zMN0PqvSJ48JYE7m4bkh3mQsf LPiCsTf+CUSDjgOsvfSj4cxDVq2KNW1cCGZZP3LmAIijnCe0v5gFGVumgGU+2VqSqbeBTGzbKFim 6zVcLgBDbXI4jA2zVTv2hRpX0Y+BjCRnvgpG4O/kIxN17Mf/GKQukGA6FftePjKU8PUPVAx6e44Z em48HANNLo7mj+yzi8vLxWChMeqFFbYP11lf6P1CchlOsA4Y7ODBJuMKRsExpWVq45crQ0X4An8n qwpOcZGRO5zzMdPykJXjm7MaH1bKy5BuES8PKpE+sxHL5MerkKMKRVGFTQY5rrndjPr86Jkk9gtW 8evH15fH58/Pb6h0Reodne/NSIzQGpFqt8LcBP4ae4g32qfrVx/p8De6uri+5ncm160yubGf+swY 0wxzsYnuNZDSdi4RJyq8GTDU7XIiNkG2fcZZqzuJlFRHwxsJOC5ZpDSHsJUmtI5q1a+wQiTzMALY SBwWWAwZa6njVuPsvbjv6HRU2jF3/FAgIm8RmSFAosf3WBuF6Dhqa9o2uv9xIz0ygIX2ESPLOwyp vXJMmlNZqPVPPbnYAr2PO8xM1OALzqOpwaixrF2DeSdaafx8Pj+7ES/wp2fz2ekNCnhrkXdSsxuF Y6VXiZ3Y5gd2oChZw+M9gUbzM4QJjYAOShgADYuRLHUF7kYjYDCd/TVAF+pi8OVuL6/bZ8Ys+Ujs e33GMttuyWirvBmWZ0IrFMeB5k/WSQZiRCBpN1o5tIa9wbLEymLBn8+lf2+QIPw48BO9L94n7wEi r1c/NoafD1/qQjdLSHgym8qDOI1eX694Hc5nN0B8tZj8jZ9/AdDS9kplbmRzdHJlYW0KZW5kb2Jq CjEwOCAwIG9iagoxMzQ5CmVuZG9iagoxMTIgMCBvYmoKPDwvTGVuZ3RoIDExMyAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJVWTXPbNhC961fs6NAkM7Kij0zt9pCJaju1M/XEsej2 kPEBApckapKQAdCy/n0eQFIipbRpqdFIJIC3u28fHvhEk/GUJv7T/Mpi8PbulFI7mNDv+KaDp8E0 TKDmRxb0W4RJZzSdUZQM6nVTms3p9PSMomLw+rp0bEp2JxdGJI789TG6pavPy4jOdVGIMqZEG/pT GVeJnK60dZZ216eqZJpNptM30d+D+S8U/TF43Qy5jElqY1g6em5WZ1hNKwYgh/HKsiFpOObSKZFb EhiwuBm/eTWY/dzCrcZEUeZHpEY+a6NXORe0US4j/cwm1yJWZRogF+fnEeLWmSuLkJsQBoDTeTe/ w7CqWAMUT7iu2NPQzduOa2qA9RzgWqDdQuGULi0VYksizxG3KZF0QrKyThfHBeuSRAdrzeakCXpS kyWsCpGREb8IH2pEqsQ6prUwTskqF/+cTUihx37JqUboMKilrIwdkacKE8PsDtR3u5Nr/QiGqjWG W86FlLoqHRUsM1EqW+CpcN2kLNk1S5UoSU6H0V5WKHCpUZMEVirUcdodrG4BBVglJx7BRS6w+H9K azGeI/LnAwXdLy/vWgU1cRfoUhwrHxMJ2SpN2YYENrrKY4T1VbVKpA3n+cljqTcl2S0a8dLTnsuM rtIshOIXBRzE7cZEPyypPEdtRng1Nnwk2osKs5ukGjn82tsq4Tp/XwMmWn9oZo0BfrQFaPme5vMp 3QprN9rEZPipUuCsQ7cHu10sl1BiV2Z+6Ww+oXtPc65BiM+zl8q1Txud38l215YhEhtSodLMuwEJ 57hYBx5AI8D8rggy4V7KPR0PO4UNwzYqO9szGIZX3b5V2JZN/pZhHhAMBAwfQXhKlLFuRKvKoQhn dFxJxmIGEuL1t1QD0pjQwd7sN0MEXRcMzTrw+0hcogZdeiwIMjcs4m1wCE/N0HNTioI/+AL9n+FR x2o9BX9qMTsaH9Em40b/wx0IrbXpJO4vwwkb23AMxmXjB8muR69sb/N4q1WH/tBmkCnQZGS2Rbn3 O1MYHqhv2CavfNPxgG0HK1ZJ4r3M+aT8DerwsZ3f1G7DtTl15eNF52OhYbrnoX27AwPxD8RC+NrK 7gJ0sI6L6IftwYTzqNSt1fW2Uc/tjg63v7z57v20xoQ3K7eFshyXNpwswTe9j8VaVs1RFTZdXyRf 7z6ez2azs4dg7P7u3Wx6+jDaY+6N2s+QDH2AfZD9bz4bTovWYkED9PA9f6XV9kAnMlfed4lu/Mr2 IMARua09YXEfXb1dXCx257atA65qwA5Sx9+7jhkORBOjBeiJFQmnlYCbHR4B4w7SdUJbXe09+xAy ZObfCqzv6AZHOjYH+gD+dgZMwc3RkvCqsycRVuNkxva/vAL96LjtMNry6Ps9eRcafsUuK9Cfn+hG 3lTGIM1wXb6sYeOWLlhysQLsfDoKr2nUu77eihSvb7MHQF5Ggy/4fAMOEklPZW5kc3RyZWFtCmVu ZG9iagoxMTMgMCBvYmoKMTEwNQplbmRvYmoKMTE3IDAgb2JqCjw8L0xlbmd0aCAxMTggMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx9Vdty2zYQfddX7PihdmZcVZekttuXyIkS26kb 12HrznT6AIErERUI0ACoS76+ByBoW5lOSWk4XGAv5+xZ8JFGwzGN4p2fsh78cH9GKz8Y0Uf8V4PH wThtoPyQNV0W2HRO4wkVy0HnN6bJlM7OzqmoByfXJrAzHL5/78QyULw+FHd09flLQe9sXQtT0tI6 +kO50ApNV9YHT0/XTWuYJqPx+FXxz2B6QcUvg5PZ8PWQ4Gykbr2y5tXxYPJjWoFDUTHJpyVaOltT gI13olZGhGi0y2xSPiizosZ6rxZKq6DYI9p42kfzzLWnYGnBcBGBFLxdyS7a7CIIvAv8Sn5sRUDI utVPOY4cC32EeCcZtGe3YedPSWrFJlDE3tmotqVaKpl8U0LfNo11gTaZlyrykmMJx2RYsvfC7YcJ s2OQyCRg36ZcMnObEQBujQik1Zr1PsfxVrepWORrnN2oktNOBzTKcUmaN6wjlFzNEI59E5qGTal2 dIkCZnJt7FZzueIawPxBR+7tggFkrr8mwHeiRZc5VDUS56wlCi8ZbCIElcrL1vvnRh10JAmnBwf2 sa4c9SqjMqksqBAjHc13gY3vKQUtRyR6EhuBoroECLC1bk1bFapEAHbO/yzoAcaoj4/Otg2h+3Ht el586DhXLodKzuC/Rs64ZSG88knVdSurLgkMpZVtpOc08dDlrVg3VD0VtWA2tIJugt6TaBrHUkFX ZZdwj0ytBlna29TJiEqiUSrQJfBXwpU50L31bNZOsPkKdcVSKrGJWJbKQQa+Xa3Yh0g8SinZS6cW ufrIcI6SeR4e9HOmeYdSblkbtbabUxiWUSxXlg1D3De2MvRJR+JNB/XGMhU2UoEiIESMyzdThhGA xnNVqV9iYdtALBxGxVEcm2T+lsufEc3sYc4Vd6y+DJRSJl6VkdZBxpHQlz3AcREAv82JHedYq7hz 2erYimeBx15cx5EH63CI8FmC7y1rfQx3KNcHYSQjXw5UiyQjzzL8JwiMpotTJ0qx0Exb4eG7EbqN ry9nrg2Vdf6YZmXpMP18OGgvJ+twZvK0XToLxK4X22Q6ekPvqnYtHOoXvXQ+GbvbKK35lIpfiaZn F5NpXvr9y+wg47zGyP5ETdUleJufQ+jmuernI+BW3rbOif1BcbdKOustpvZd7k53pMe1zzj8n9cf RH9w3XOJNGjiw4zo4nz0ZvL/BTq7qGX9tu5D5QLHo9dpY8/Pd08Vdh+f+a7BMejpPc7aGghoOj5N HyM6uP66Eyt8pKZ/I+S8GPyG+18pMkmZZW5kc3RyZWFtCmVuZG9iagoxMTggMCBvYmoKOTY2CmVu ZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSA5IDAgUgovRm9udCAxMCAwIFIKPj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9iagoxMSAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTQgMCBSCi9G b250IDE1IDAgUgo+PgovQ29udGVudHMgMTIgMCBSCj4+CmVuZG9iagoxNiAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTkgMCBSCi9Gb250IDIwIDAg Ugo+PgovQ29udGVudHMgMTcgMCBSCj4+CmVuZG9iagoyMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjQgMCBSCi9Gb250IDI1IDAgUgo+PgovQ29u dGVudHMgMjIgMCBSCj4+CmVuZG9iagoyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAg MCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMjkgMCBSCi9Gb250IDMwIDAgUgo+PgovQ29udGVudHMgMjcg MCBSCj4+CmVuZG9iagozMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgMzQgMCBSCi9Gb250IDM1IDAgUgo+PgovQ29udGVudHMgMzIgMCBSCj4+CmVu ZG9iagozNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgMzkgMCBSCi9Gb250IDQwIDAgUgo+PgovQ29udGVudHMgMzcgMCBSCj4+CmVuZG9iago0MSAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNDQgMCBS Ci9Gb250IDQ1IDAgUgo+PgovQ29udGVudHMgNDIgMCBSCj4+CmVuZG9iago0NiAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNDkgMCBSCi9Gb250IDUw IDAgUgo+PgovQ29udGVudHMgNDcgMCBSCj4+CmVuZG9iago1MSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNTQgMCBSCi9Gb250IDU1IDAgUgo+Pgov Q29udGVudHMgNTIgMCBSCj4+CmVuZG9iago1NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNTkgMCBSCi9Gb250IDYwIDAgUgo+PgovQ29udGVudHMg NTcgMCBSCj4+CmVuZG9iago2MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgNjQgMCBSCi9Gb250IDY1IDAgUgo+PgovQ29udGVudHMgNjIgMCBSCj4+ CmVuZG9iago2NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRH U3RhdGUgNjkgMCBSCi9Gb250IDcwIDAgUgo+PgovQ29udGVudHMgNjcgMCBSCj4+CmVuZG9iago3 MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNzQg MCBSCi9Gb250IDc1IDAgUgo+PgovQ29udGVudHMgNzIgMCBSCj4+CmVuZG9iago3NiAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNzkgMCBSCi9Gb250 IDgwIDAgUgo+PgovQ29udGVudHMgNzcgMCBSCj4+CmVuZG9iago4MSAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgODQgMCBSCi9Gb250IDg1IDAgUgo+ PgovQ29udGVudHMgODIgMCBSCj4+CmVuZG9iago4NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgODkgMCBSCi9Gb250IDkwIDAgUgo+PgovQ29udGVu dHMgODcgMCBSCj4+CmVuZG9iago5MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgOTQgMCBSCi9Gb250IDk1IDAgUgo+PgovQ29udGVudHMgOTIgMCBS Cj4+CmVuZG9iago5NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9F eHRHU3RhdGUgOTkgMCBSCi9Gb250IDEwMCAwIFIKPj4KL0NvbnRlbnRzIDk3IDAgUgo+PgplbmRv YmoKMTAxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAxMDQgMCBSCi9Gb250IDEwNSAwIFIKPj4KL0NvbnRlbnRzIDEwMiAwIFIKPj4KZW5kb2JqCjEw NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTA5 IDAgUgovRm9udCAxMTAgMCBSCj4+Ci9Db250ZW50cyAxMDcgMCBSCj4+CmVuZG9iagoxMTEgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDExNCAwIFIK L0ZvbnQgMTE1IDAgUgo+PgovQ29udGVudHMgMTEyIDAgUgo+PgplbmRvYmoKMTE2IDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMTkgMCBSCi9Gb250 IDEyMCAwIFIKPj4KL0NvbnRlbnRzIDExNyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUg L1BhZ2VzIC9LaWRzIFsKNCAwIFIKMTEgMCBSCjE2IDAgUgoyMSAwIFIKMjYgMCBSCjMxIDAgUgoz NiAwIFIKNDEgMCBSCjQ2IDAgUgo1MSAwIFIKNTYgMCBSCjYxIDAgUgo2NiAwIFIKNzEgMCBSCjc2 IDAgUgo4MSAwIFIKODYgMCBSCjkxIDAgUgo5NiAwIFIKMTAxIDAgUgoxMDYgMCBSCjExMSAwIFIK MTE2IDAgUgpdIC9Db3VudCAyMwo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9Q YWdlcyAzIDAgUgovTWV0YWRhdGEgMTIxIDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4 dEdTdGF0ZQovT1BNIDE+PmVuZG9iago5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwIDAg b2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE1 IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2Jq CjIwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjI0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5k b2JqCjI1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjI5IDAgb2JqCjw8L1I3CjcgMCBSPj4K ZW5kb2JqCjMwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjM0IDAgb2JqCjw8L1I3CjcgMCBS Pj4KZW5kb2JqCjM1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjM5IDAgb2JqCjw8L1I3Cjcg MCBSPj4KZW5kb2JqCjQwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjQ0IDAgb2JqCjw8L1I3 CjcgMCBSPj4KZW5kb2JqCjQ1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjQ5IDAgb2JqCjw8 L1I3CjcgMCBSPj4KZW5kb2JqCjUwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjU0IDAgb2Jq Cjw8L1I3CjcgMCBSPj4KZW5kb2JqCjU1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjU5IDAg b2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjYwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjY0 IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjY1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2Jq CjY5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjcwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5k b2JqCjc0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjc1IDAgb2JqCjw8L1I4CjggMCBSPj4K ZW5kb2JqCjc5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjgwIDAgb2JqCjw8L1I4CjggMCBS Pj4KZW5kb2JqCjg0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjg1IDAgb2JqCjw8L1I4Cjgg MCBSPj4KZW5kb2JqCjg5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjkwIDAgb2JqCjw8L1I4 CjggMCBSPj4KZW5kb2JqCjk0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjk1IDAgb2JqCjw8 L1I4CjggMCBSPj4KZW5kb2JqCjk5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwMCAwIG9i ago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMDQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTA1 IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjEwOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i agoxMTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTE0IDAgb2JqCjw8L1I3CjcgMCBSPj4K ZW5kb2JqCjExNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMTkgMCBvYmoKPDwvUjcKNyAw IFI+PgplbmRvYmoKMTIwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwvQmFz ZUZvbnQvQ291cmllci9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTIxIDAgb2Jq Cjw8L1R5cGUvTWV0YWRhdGEKL1N1YnR5cGUvWE1ML0xlbmd0aCAxMzI4Pj5zdHJlYW0KPD94cGFj a2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14 YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRh LycgeDp4bXB0az0nWE1QIHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYnPgo8cmRmOlJE RiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMn IHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0nZDg5NWQ1ZmEtZGEwYy0xMWViLTAwMDAtNjUwOGViOWFkOWM0JyB4bWxuczpw ZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0 c2NyaXB0IDguNzEnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2Q4OTVkNWZhLWRhMGMt MTFlYi0wMDAwLTY1MDhlYjlhZDljNCcgeG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUuY29tL3hh cC8xLjAvJz48eG1wOk1vZGlmeURhdGU+MjAxMS0wNi0yOVQwMzozNzowNiswMjowMDwveG1wOk1v ZGlmeURhdGU+Cjx4bXA6Q3JlYXRlRGF0ZT4yMDExLTA2LTI5VDAzOjM3OjA2KzAyOjAwPC94bXA6 Q3JlYXRlRGF0ZT4KPHhtcDpDcmVhdG9yVG9vbD5HTlUgRW5zY3JpcHQgMS42LjUuMjwveG1wOkNy ZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0n ZDg5NWQ1ZmEtZGEwYy0xMWViLTAwMDAtNjUwOGViOWFkOWM0JyB4bWxuczp4YXBNTT0naHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0nZDg5NWQ1ZmEtZGEw Yy0xMWViLTAwMDAtNjUwOGViOWFkOWM0Jy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSdk ODk1ZDVmYS1kYTBjLTExZWItMDAwMC02NTA4ZWI5YWQ5YzQnIHhtbG5zOmRjPSdodHRwOi8vcHVy bC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Zm9ybWF0PSdhcHBsaWNhdGlvbi9wZGYnPjxkYzp0 aXRsZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPkVuc2NyaXB0IE91dHB1 dDwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjwvcmRmOkRlc2NyaXB0aW9uPgo8L3JkZjpS REY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tl dCBlbmQ9J3cnPz4KZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBHaG9z dHNjcmlwdCA4LjcxKQovQ3JlYXRpb25EYXRlKEQ6MjAxMTA2MjkwMzM3MDYrMDInMDAnKQovTW9k RGF0ZShEOjIwMTEwNjI5MDMzNzA2KzAyJzAwJykKL1RpdGxlKEVuc2NyaXB0IE91dHB1dCkKL0Ny ZWF0b3IoR05VIEVuc2NyaXB0IDEuNi41LjIpPj5lbmRvYmoKeHJlZgowIDEyMgowMDAwMDAwMDAw IDY1NTM1IGYgCjAwMDAwMjg4NzIgMDAwMDAgbiAKMDAwMDAzMTgzNSAwMDAwMCBuIAowMDAwMDI4 NjU0IDAwMDAwIG4gCjAwMDAwMjQ5MTQgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAw MDAxMjMzIDAwMDAwIG4gCjAwMDAwMjg5MzggMDAwMDAgbiAKMDAwMDAzMDM2NyAwMDAwMCBuIAow MDAwMDI4OTc5IDAwMDAwIG4gCjAwMDAwMjkwMDggMDAwMDAgbiAKMDAwMDAyNTA3MyAwMDAwMCBu IAowMDAwMDAxMjUzIDAwMDAwIG4gCjAwMDAwMDIwMTAgMDAwMDAgbiAKMDAwMDAyOTAzOCAwMDAw MCBuIAowMDAwMDI5MDY4IDAwMDAwIG4gCjAwMDAwMjUyMzUgMDAwMDAgbiAKMDAwMDAwMjAzMCAw MDAwMCBuIAowMDAwMDAzNDQ3IDAwMDAwIG4gCjAwMDAwMjkwOTggMDAwMDAgbiAKMDAwMDAyOTEy OCAwMDAwMCBuIAowMDAwMDI1Mzk3IDAwMDAwIG4gCjAwMDAwMDM0NjggMDAwMDAgbiAKMDAwMDAw NDgwOCAwMDAwMCBuIAowMDAwMDI5MTU4IDAwMDAwIG4gCjAwMDAwMjkxODggMDAwMDAgbiAKMDAw MDAyNTU1OSAwMDAwMCBuIAowMDAwMDA0ODI5IDAwMDAwIG4gCjAwMDAwMDU4NjEgMDAwMDAgbiAK MDAwMDAyOTIxOCAwMDAwMCBuIAowMDAwMDI5MjQ4IDAwMDAwIG4gCjAwMDAwMjU3MjEgMDAwMDAg biAKMDAwMDAwNTg4MSAwMDAwMCBuIAowMDAwMDA2OTQ4IDAwMDAwIG4gCjAwMDAwMjkyNzggMDAw MDAgbiAKMDAwMDAyOTMwOCAwMDAwMCBuIAowMDAwMDI1ODgzIDAwMDAwIG4gCjAwMDAwMDY5Njgg MDAwMDAgbiAKMDAwMDAwODMwMiAwMDAwMCBuIAowMDAwMDI5MzM4IDAwMDAwIG4gCjAwMDAwMjkz NjggMDAwMDAgbiAKMDAwMDAyNjA0NSAwMDAwMCBuIAowMDAwMDA4MzIzIDAwMDAwIG4gCjAwMDAw MDk2OTQgMDAwMDAgbiAKMDAwMDAyOTM5OCAwMDAwMCBuIAowMDAwMDI5NDI4IDAwMDAwIG4gCjAw MDAwMjYyMDcgMDAwMDAgbiAKMDAwMDAwOTcxNSAwMDAwMCBuIAowMDAwMDEwNzYwIDAwMDAwIG4g CjAwMDAwMjk0NTggMDAwMDAgbiAKMDAwMDAyOTQ4OCAwMDAwMCBuIAowMDAwMDI2MzY5IDAwMDAw IG4gCjAwMDAwMTA3ODAgMDAwMDAgbiAKMDAwMDAxMjA1MyAwMDAwMCBuIAowMDAwMDI5NTE4IDAw MDAwIG4gCjAwMDAwMjk1NDggMDAwMDAgbiAKMDAwMDAyNjUzMSAwMDAwMCBuIAowMDAwMDEyMDc0 IDAwMDAwIG4gCjAwMDAwMTI3NjMgMDAwMDAgbiAKMDAwMDAyOTU3OCAwMDAwMCBuIAowMDAwMDI5 NjA4IDAwMDAwIG4gCjAwMDAwMjY2OTMgMDAwMDAgbiAKMDAwMDAxMjc4MyAwMDAwMCBuIAowMDAw MDEzNDY2IDAwMDAwIG4gCjAwMDAwMjk2MzggMDAwMDAgbiAKMDAwMDAyOTY2OCAwMDAwMCBuIAow MDAwMDI2ODU1IDAwMDAwIG4gCjAwMDAwMTM0ODYgMDAwMDAgbiAKMDAwMDAxNDI2MiAwMDAwMCBu IAowMDAwMDI5Njk4IDAwMDAwIG4gCjAwMDAwMjk3MjggMDAwMDAgbiAKMDAwMDAyNzAxNyAwMDAw MCBuIAowMDAwMDE0MjgyIDAwMDAwIG4gCjAwMDAwMTQ3OTcgMDAwMDAgbiAKMDAwMDAyOTc1OCAw MDAwMCBuIAowMDAwMDI5Nzg4IDAwMDAwIG4gCjAwMDAwMjcxNzkgMDAwMDAgbiAKMDAwMDAxNDgx NyAwMDAwMCBuIAowMDAwMDE1NDczIDAwMDAwIG4gCjAwMDAwMjk4MTggMDAwMDAgbiAKMDAwMDAy OTg0OCAwMDAwMCBuIAowMDAwMDI3MzQxIDAwMDAwIG4gCjAwMDAwMTU0OTMgMDAwMDAgbiAKMDAw MDAxNjMyMiAwMDAwMCBuIAowMDAwMDI5ODc4IDAwMDAwIG4gCjAwMDAwMjk5MDggMDAwMDAgbiAK MDAwMDAyNzUwMyAwMDAwMCBuIAowMDAwMDE2MzQyIDAwMDAwIG4gCjAwMDAwMTc0MjAgMDAwMDAg biAKMDAwMDAyOTkzOCAwMDAwMCBuIAowMDAwMDI5OTY4IDAwMDAwIG4gCjAwMDAwMjc2NjUgMDAw MDAgbiAKMDAwMDAxNzQ0MSAwMDAwMCBuIAowMDAwMDE4NzkzIDAwMDAwIG4gCjAwMDAwMjk5OTgg MDAwMDAgbiAKMDAwMDAzMDAyOCAwMDAwMCBuIAowMDAwMDI3ODI3IDAwMDAwIG4gCjAwMDAwMTg4 MTQgMDAwMDAgbiAKMDAwMDAxOTk3NiAwMDAwMCBuIAowMDAwMDMwMDU4IDAwMDAwIG4gCjAwMDAw MzAwODggMDAwMDAgbiAKMDAwMDAyNzk5MCAwMDAwMCBuIAowMDAwMDE5OTk3IDAwMDAwIG4gCjAw MDAwMjExODUgMDAwMDAgbiAKMDAwMDAzMDExOSAwMDAwMCBuIAowMDAwMDMwMTUwIDAwMDAwIG4g CjAwMDAwMjgxNTYgMDAwMDAgbiAKMDAwMDAyMTIwNyAwMDAwMCBuIAowMDAwMDIyNjMwIDAwMDAw IG4gCjAwMDAwMzAxODEgMDAwMDAgbiAKMDAwMDAzMDIxMiAwMDAwMCBuIAowMDAwMDI4MzIyIDAw MDAwIG4gCjAwMDAwMjI2NTIgMDAwMDAgbiAKMDAwMDAyMzgzMSAwMDAwMCBuIAowMDAwMDMwMjQz IDAwMDAwIG4gCjAwMDAwMzAyNzQgMDAwMDAgbiAKMDAwMDAyODQ4OCAwMDAwMCBuIAowMDAwMDIz ODUzIDAwMDAwIG4gCjAwMDAwMjQ4OTMgMDAwMDAgbiAKMDAwMDAzMDMwNSAwMDAwMCBuIAowMDAw MDMwMzM2IDAwMDAwIG4gCjAwMDAwMzA0MjkgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxMjIg L1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lEIFs8Mzg1NUQyRkVEOUZGMTY0NDhBOUE5RDJDQTJG OEFDNzQ+PDM4NTVEMkZFRDlGRjE2NDQ4QTlBOUQyQ0EyRjhBQzc0Pl0KPj4Kc3RhcnR4cmVmCjMy MDEzCiUlRU9GCg== --_004_01AA9EC92749BF4894AC2B3039EA4A2C194A07E2CH1PRD0302MB131_ Content-Type: text/plain; name="draft-ietf-ftpext2-hosts-04.txt" Content-Description: draft-ietf-ftpext2-hosts-04.txt Content-Disposition: attachment; filename="draft-ietf-ftpext2-hosts-04.txt"; size=53419; creation-date="Wed, 29 Jun 2011 01:36:51 GMT"; modification-date="Wed, 29 Jun 2011 01:37:54 GMT" Content-Transfer-Encoding: base64 DQoNCg0KRlRQRVhUMiBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQLiBIZXRobW9uDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEhldGhtb24gQnJvdGhlcnMNClVwZGF0ZXM6IDk1OSAoaWYg YXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBNY011cnJheQ0K SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgTWljcm9z b2Z0IENvcnBvcmF0aW9uDQpFeHBpcmVzOiBEZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEp1bmUgMjksIDIwMTENCg0KDQogICAgICAgICBGaWxlIFRyYW5z ZmVyIFByb3RvY29sIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cw0KICAgICAgICAgICAg ICAgICAgICAgIGRyYWZ0LWlldGYtZnRwZXh0Mi1ob3N0cy0wNA0KDQpBYnN0cmFjdA0KDQogICBU aGUgRmlsZSBUcmFuc2ZlciBQcm90b2NvbCwgYXMgZGVmaW5lZCBpbiBSRkMgOTU5IFtSRkMwOTU5 XSwgZG9lcyBub3QNCiAgIHByb3ZpZGUgYSB3YXkgZm9yIEZUUCBjbGllbnRzIGFuZCBzZXJ2ZXJz IHRvIGRpZmZlcmVudGlhdGUgYmV0d2Vlbg0KICAgbXVsdGlwbGUgRE5TIG5hbWVzIHRoYXQgYXJl IHJlZ2lzdGVyZWQgZm9yIGEgc2luZ2xlIElQIGFkZHJlc3MuICBUaGlzDQogICBkb2N1bWVudCBk ZWZpbmVzIGEgbmV3IEZUUCBjb21tYW5kIHRoYXQgcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIEZU UA0KICAgY2xpZW50cyBhbmQgc2VydmVycyB0byBpZGVudGlmeSBpbmRpdmlkdWFsIHZpcnR1YWwg aG9zdHMgb24gYW4gRlRQDQogICBzZXJ2ZXIuDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAg VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRo IHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcN CiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50 cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gRGVjZW1iZXIgMzEsIDIwMTEuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29w eXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMg dGhlDQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQog ICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1 bWVudHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVz dHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxp ZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KDQoN Cg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAg ICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQIEhPU1QgQ29tbWFu ZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTENCg0KDQogICB0aGUgVHJ1c3Qg TGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMNCiAg IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4NCg0KDQpUYWJsZSBvZiBD b250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIuICBEb2N1bWVudCBDb252ZW50aW9ucyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgICAyLjEuICBC YXNpYyBUb2tlbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA0DQogICAgIDIuMi4gIFNlcnZlciBSZXBsaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDMuICBUaGUgSE9TVCBjb21tYW5kIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAzLjEuICBTeW50YXgg b2YgdGhlIEhPU1QgY29tbWFuZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQog ICAgIDMuMi4gIEhPU1QgY29tbWFuZCBzZW1hbnRpY3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDgNCiAgICAgICAzLjIuMS4gIFJFSU4gY29tbWFuZCBzZW1hbnRpY3MgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAgIDMuMi4yLiAgVXNlci1QSSB1 c2FnZSBvZiBIT1NUICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgICAg My4yLjMuICBTdGF0ZSBEaWFncmFtcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTANCiAgICAgMy4zLiAgSE9TVCBjb21tYW5kIGVycm9ycyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0KICAgICAzLjQuICBGRUFUIHJlc3BvbnNlIGZvciBI T1NUIGNvbW1hbmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICA0LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTgNCiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxOQ0KICAgNi4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DQogICAgIDYuMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkNCiAg ICAgNi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyMA0KICAgQXBwZW5kaXggQS4gIFVud29ya2FibGUgQWx0ZXJuYXRpdmVzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDQogICAgIEEuMS4gIE92ZXJsb2FkaW5nIHRo ZSBDV0QgY29tbWFuZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjENCiAgICAgQS4y LiAgT3ZlcmxvYWRpbmcgdGhlIEFDQ1QgY29tbWFuZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyMQ0KICAgICBBLjMuICBPdmVybG9hZGluZyB0aGUgVVNFUiBjb21tYW5kIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQogICAgIEEuNC4gIENvbmNsdXNpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMNCiAgIEFwcGVuZGl4IEIu ICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAy Mw0KICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDIzDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVzIERlY2VtYmVyIDMxLCAyMDExICAg ICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICBGVFAgSE9TVCBDb21t YW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1bmUgMjAxMQ0KDQoNCjEuICBJbnRyb2R1 Y3Rpb24NCg0KICAgSXQgaXMgY29tbW9uIG9uIHRoZSBJbnRlcm5ldCBmb3IgbWFueSBETlMgbmFt ZXMgdG8gcmVzb2x2ZSB0byBhDQogICBzaW5nbGUgSVAgYWRkcmVzcy4gIFRoaXMgcHJhY3RpY2Ug aGFzIGludHJvZHVjZWQgdGhlIGNvbmNlcHQgb2YgYQ0KICAgInZpcnR1YWwgaG9zdCIsIHdoZXJl IGEgaG9zdCBhcHBlYXJzIHRvIGV4aXN0IGFzIGFuIGluZGVwZW5kZW50DQogICBlbnRpdHksIGJ1 dCBpbiByZWFsaXR5IHNoYXJlcyBpdHMgcGh5c2ljYWwgcmVzb3VyY2VzIHdpdGggb25lIG9yIG1v cmUNCiAgIHNpbWlsYXIgaG9zdHMuDQoNCiAgIFN1Y2ggYW4gYXJyYW5nZW1lbnQgcHJlc2VudHMg c29tZSBwcm9ibGVtcyBmb3IgRlRQIHNlcnZlcnMsIGFzIGFuIEZUUA0KICAgc2VydmVyIGRpc3Rp bmd1aXNoZXMgaW5jb21pbmcgRlRQIGNvbm5lY3Rpb25zIGJ5IHRoZWlyIElQIGFkZHJlc3NlcywN CiAgIG5vdCB0aGVpciBETlMgbmFtZXMsIGJlY2F1c2UgaG9zdHMgYXJlIHVuaXF1ZWx5IGlkZW50 aWZpZWQgYnkgdGhlaXINCiAgIGFkZHJlc3MgcmF0aGVyIHRoYW4gbmFtZS4gIFRoYXQgaXMsIGFs bCBETlMgbmFtZXMgdGhhdCBzaGFyZSBhbiBJUA0KICAgYWRkcmVzcyBhcmUgaGFuZGxlZCBieSB0 aGUgc2FtZSBGVFAgc2VydmVyIGFuZCBzaGFyZSB0aGUgc2FtZSBOZXR3b3JrDQogICBWaXJ0dWFs IEZpbGUgU3lzdGVtIChOVkZTKS4NCg0KICAgVGhpcyBtZWFucyB0aGF0IGRpZmZlcmVudCB2aXJ0 dWFsIGhvc3RzIGNhbm5vdCBvZmZlciBkaWZmZXJlbnQNCiAgIHZpcnR1YWwgZmlsZSBzeXN0ZW1z IHRvIGNsaWVudHMsIG5vciBjYW4gdGhleSBvZmZlciBkaWZmZXJlbnQNCiAgIGF1dGhlbnRpY2F0 aW9uIHN5c3RlbXMuICBBbnkgc2NoZW1lIHRvIG92ZXJjb21lIHRoaXMgaXNzdWUgbmVlZHMgdG8N CiAgIGluZGljYXRlIG5vdCBvbmx5IHRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzLCBidXQgYWxz byB0aGUgdmlydHVhbA0KICAgaG9zdCBuYW1lIHRoYXQgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBk ZXNpcmVkIHZpcnR1YWwgRlRQIHNlcnZlci4NCiAgIFR5cGljYWwgdXNlci1GVFAgcHJvY2Vzc2Vz IGN1cnJlbnRseSB1c2UgaG9zdG5hbWVzIHRvIHBlcmZvcm0NCiAgIGhvc3RuYW1lIHRvIElQIGFk ZHJlc3MgcmVzb2x1dGlvbiBhbmQgdGhlbiBpZ25vcmUgaG9zdG5hbWVzIGZvciB0aGUNCiAgIHJl c3Qgb2YgdGhlIEZUUCBzZXNzaW9uLCB0aGVyZWZvcmUgYW55IG1lY2hhbmlzbSB0byBvdmVyY29t ZSB0aGlzDQogICBpc3N1ZSB3b3VsZCByZXF1aXJlIG1vZGlmaWNhdGlvbnMgdG8gdGhlIHVzZXIt UEkgYW5kIHNlcnZlci1QSS4NCg0KICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhpcyBzYW1l IHByb2JsZW0gZXhpc3RlZCBmb3IgSFRUUC8xLjAgYXMNCiAgIGRlZmluZWQgaW4gW1JGQzE5NDVd LCBhbmQgd2FzIHJlc29sdmVkIGluIEhUVFAvMS4xIGFzIGRlZmluZWQgaW4NCiAgIFtSRkMyNjE2 XSB0aHJvdWdoIHRoZSBhZGRpdGlvbiBvZiB0aGUgSG9zdCByZXF1ZXN0IGhlYWRlci4gIFRoZSBn b2FsDQogICBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGJyaW5nIGEgc2ltaWxhciBsZXZlbCBvZiBm ZWF0dXJlIHBhcml0eSB0byBGVFANCiAgIGJ5IGludHJvZHVjaW5nIGEgbmV3IEhPU1QgY29tbWFu ZCB0aGF0IGFsbG93cyB1c2VyLUZUUCBwcm9jZXNzZXMgdG8NCiAgIHNwZWNpZnkgd2hpY2ggdmly dHVhbCBob3N0IHRvIGNvbm5lY3QgdG8gZm9yIGEgc2VydmVyLUZUUCBwcm9jZXNzDQogICB0aGF0 IGlzIGhhbmRsaW5nIHJlcXVlc3RzIGZvciBtdWx0aXBsZSB2aXJ0dWFsIGhvc3RzIG9uIGEgc2lu Z2xlIElQDQogICBhZGRyZXNzLg0KDQoNCjIuICBEb2N1bWVudCBDb252ZW50aW9ucw0KDQogICBU aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNI QUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZ IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJl dGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoNCiAgIEluIGV4YW1wbGVzLCAiQz4iIGFu ZCAiUz4iIGluZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQNCiAgIHNlcnZlciwg cmVzcGVjdGl2ZWx5Lg0KDQogICBUaGlzIGRvY3VtZW50IGFsc28gdXNlcyBub3RhdGlvbiBkZWZp bmVkIGluIFtSRkMwOTU5XSBhbmQgW1JGQzExMjNdLg0KICAgSW4gcGFydGljdWxhciwgdGhlIHRl cm1zICJyZXBseSIsICJ1c2VyIiwgIk5WRlMiLCAiTlZUIiwgImZpbGUiLA0KICAgInBhdGhuYW1l IiwgIkZUUCBjb21tYW5kcyIsICJEVFAiLCAidXNlci1GVFAgcHJvY2VzcyIsICJ1c2VyLVBJIiwN CiAgICJ1c2VyLURUUCIsICJzZXJ2ZXItRlRQIHByb2Nlc3MiLCAic2VydmVyLVBJIiwgInNlcnZl ci1EVFAiLCAibW9kZSIsDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVzIERl Y2VtYmVyIDMxLCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0 ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1bmUgMjAx MQ0KDQoNCiAgICJ0eXBlIiwgImNvbnRyb2wgY29ubmVjdGlvbiIsICJkYXRhIGNvbm5lY3Rpb24i LCBhbmQgIkFTQ0lJIiwgYXJlIGFsbA0KICAgdXNlZCBoZXJlIGFzIGRlZmluZWQgdGhlcmUuDQoN CiAgIFN5bnRheCByZXF1aXJlZCBpcyBkZWZpbmVkIHVzaW5nIHRoZSBBdWdtZW50ZWQgQk5GIGRl ZmluZWQgaW4NCiAgIFtSRkM1MjM0XS4gIFNvbWUgZ2VuZXJhbCBBQk5GIGRlZmluaXRpb25zIGFy ZSByZXF1aXJlZCB0aHJvdWdob3V0IHRoZQ0KICAgZG9jdW1lbnQ7IHRob3NlIHdpbGwgYmUgZGVm aW5lZCBsYXRlciBpbiB0aGlzIHNlY3Rpb24uICBBdCBmaXJzdA0KICAgcmVhZGluZywgaXQgbWF5 IGJlIHdpc2UgdG8gc2ltcGx5IHJlY2FsbCB0aGF0IHRoZXNlIGRlZmluaXRpb25zIGV4aXN0DQog ICBoZXJlLCBhbmQgc2tpcCB0byB0aGUgbmV4dCBzZWN0aW9uLg0KDQoyLjEuICBCYXNpYyBUb2tl bnMNCg0KICAgVGhpcyBkb2N1bWVudCBpbXBvcnRzIHRoZSBjb3JlIGRlZmluaXRpb25zIGdpdmVu IGluIEFwcGVuZGl4IEIgb2YNCiAgIFtSRkM1MjM0XS4gIFRoZXJlIGRlZmluaXRpb25zIHdpbGwg YmUgZm91bmQgZm9yIGJhc2ljIEFCTkYgZWxlbWVudHMNCiAgIGxpa2UgQUxQSEEsIERJR0lULCBT UCwgZXRjLiAgVG8gdGhhdCwgdGhlIGZvbGxvd2luZyB0ZXJtIGlzIGFkZGVkIGZvcg0KICAgdXNl IGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgVENIQVIgPSBWQ0hBUiAvIFNQIC8gSFRBQiAg ICA7IHZpc2libGUgcGx1cyB3aGl0ZSBzcGFjZQ0KDQogICBUaGUgVkNIQVIgKGZyb20gW1JGQzUy MzRdKSBhbmQgVENIQVIgcnVsZXMgZ2l2ZSBiYXNpYyBjaGFyYWN0ZXIgdHlwZXMNCiAgIGZyb20g dmFyeWluZyBzdWItc2V0cyBvZiB0aGUgQVNDSUkgY2hhcmFjdGVyIHNldCBmb3IgdXNlIGluIHZh cmlvdXMNCiAgIGNvbW1hbmRzIGFuZCByZXNwb25zZXMuDQoNCiAgIE5vdGUgdGhhdCBpbiBBQk5G LCBzdHJpbmcgbGl0ZXJhbHMgYXJlIGNhc2UgaW5zZW5zaXRpdmUuICBUaGF0DQogICBjb252ZW50 aW9uIGlzIHByZXNlcnZlZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgaW1wbGllcyB0aGF0IEZUUA0K ICAgY29tbWFuZHMgYW5kIHBhcmFtZXRlcnMgdGhhdCBhcmUgYWRkZWQgYnkgdGhpcyBzcGVjaWZp Y2F0aW9uIGhhdmUNCiAgIHZhbHVlcyB0aGF0IGNhbiBiZSByZXByZXNlbnRlZCBpbiBhbnkgY2Fz ZS4gIFRoYXQgaXMsICJIT1NUIiBpcyB0aGUNCiAgIHNhbWUgYXMgImhvc3QiLCAiSG9zdCIsICJI b1N0IiwgZXRjLiwgYW5kICJmdHAuZXhhbXBsZS5jb20iIGlzIHRoZQ0KICAgc2FtZSBhcyAiRnRw LkV4YW1wbGUuQ29tIiwgImZUcC5lWGFtcGxlLmNPbSIsIGV0Yy4NCg0KMi4yLiAgU2VydmVyIFJl cGxpZXMNCg0KICAgU2VjdGlvbiA0LjIgb2YgW1JGQzA5NTldIGRlZmluZXMgdGhlIGZvcm1hdCBh bmQgbWVhbmluZyBvZiByZXBsaWVzIGJ5DQogICB0aGUgc2VydmVyLVBJIHRvIEZUUCBjb21tYW5k cyBmcm9tIHRoZSB1c2VyLVBJLiAgVGhvc2UgcmVwbHkNCiAgIGNvbnZlbnRpb25zIGFyZSB1c2Vk IGhlcmUgd2l0aG91dCBjaGFuZ2UuDQoNCiAgICAgICAgZXJyb3ItcmVzcG9uc2UgPSBlcnJvci1j b2RlIFNQICpUQ0hBUiBDUkxGDQogICAgICAgIGVycm9yLWNvZGUgICAgID0gKCI0IiAvICI1Iikg MkRJR0lUDQoNCiAgIEltcGxlbWVudGVycyBzaG91bGQgbm90ZSB0aGF0IHRoZSBBQk5GIHN5bnRh eCAod2hpY2ggd2FzIG5vdCB1c2VkIGluDQogICBbUkZDMDk1OV0pIHVzZWQgaW4gdGhpcyBkb2N1 bWVudCwgYW5kIG90aGVyIEZUUCByZWxhdGVkIGRvY3VtZW50cywNCiAgIHNvbWV0aW1lcyBzaG93 cyByZXBsaWVzIHVzaW5nIHRoZSBvbmUgbGluZSBmb3JtYXQuICBVbmxlc3Mgb3RoZXJ3aXNlDQog ICBleHBsaWNpdGx5IHN0YXRlZCwgdGhhdCBpcyBub3QgaW50ZW5kZWQgdG8gaW1wbHkgdGhhdCBt dWx0aS1saW5lDQogICByZXNwb25zZXMgYXJlIG5vdCBwZXJtaXR0ZWQuICBJbXBsZW1lbnRlcnMg c2hvdWxkIGFzc3VtZSB0aGF0LCB1bmxlc3MNCiAgIHN0YXRlZCB0byB0aGUgY29udHJhcnksIGFu eSByZXBseSB0byBhbnkgRlRQIGNvbW1hbmQgKGluY2x1ZGluZyBRVUlUKQ0KICAgY2FuIGJlIG9m IHRoZSBtdWx0aS1saW5lIGZvcm1hdCBkZXNjcmliZWQgaW4gW1JGQzA5NTldLg0KDQogICBUaHJv dWdob3V0IHRoaXMgZG9jdW1lbnQsIHJlcGxpZXMgd2lsbCBiZSBpZGVudGlmaWVkIGJ5IHRoZSB0 aHJlZQ0KICAgZGlnaXQgY29kZSB0aGF0IGlzIHRoZWlyIGZpcnN0IGVsZW1lbnQuICBUaHVzIHRo ZSB0ZXJtICI1MDAgcmVwbHkiDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVz IERlY2VtYmVyIDMxLCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURy YWZ0ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1bmUg MjAxMQ0KDQoNCiAgIG1lYW5zIGEgcmVwbHkgZnJvbSB0aGUgc2VydmVyLVBJIHVzaW5nIHRoZSB0 aHJlZSBkaWdpdCBjb2RlICI1MDAiLg0KDQoNCjMuICBUaGUgSE9TVCBjb21tYW5kDQoNCiAgIEEg bmV3IGNvbW1hbmQgIkhPU1QiIGlzIGFkZGVkIHRvIHRoZSBGVFAgY29tbWFuZCBzZXQgdG8gYWxs b3cgdGhlDQogICBzZXJ2ZXItRlRQIHByb2Nlc3MgdG8gZGV0ZXJtaW5lIHRvIHdoaWNoIG9mIHBv c3NpYmx5IG1hbnkgdmlydHVhbA0KICAgaG9zdHMgdGhlIGNsaWVudCB3aXNoZXMgdG8gY29ubmVj dC4gIFRoaXMgY29tbWFuZCBTSE9VTEQgYmUgaXNzdWVkDQogICBiZWZvcmUgdGhlIHVzZXIgaXMg YXV0aGVudGljYXRlZCwgYWxsb3dpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwNCiAgIGFu ZCBzZXQgb2YgbGVnYWwgdXNlcnMsIHRvIGJlIGRlcGVuZGVudCB1cG9uIHRoZSB2aXJ0dWFsIGhv c3QgY2hvc2VuLg0KDQogICBTZXJ2ZXItRlRQIHByb2Nlc3NlcyBNVVNUIHRyZWF0IGEgc2l0dWF0 aW9uIHdoZXJlIHRoZSBIT1NUIGNvbW1hbmQgaXMNCiAgIGlzc3VlZCBtb3JlIHRoYW4gb25jZSBi ZWZvcmUgdGhlIHVzZXIgaGFzIGJlZW4gYXV0aGVudGljYXRlZCBhcw0KICAgdGhvdWdoIGEgUkVJ TiBjb21tYW5kIHdhcyBzZW50IGJlZm9yZSBlYWNoIEhPU1QgY29tbWFuZCwgYW5kIHRoZW4NCiAg IHJlc2V0IHRoZSB1c2VyLVBJIHRvIHRoZSBzdGF0ZSB0aGF0IGV4aXN0ZWQgYWZ0ZXIgdGhlIFRD UCBjb25uZWN0aW9uDQogICB3YXMgZmlyc3QgZXN0YWJsaXNoZWQgYW5kIHJldHVybiB0aGUgYXBw cm9wcmlhdGUgcmVwbHkgZm9yIHRoZSBIT1NUDQogICBjb21tYW5kLg0KDQogICBTZXJ2ZXItRlRQ IHByb2Nlc3NlcyBNVVNUIHRyZWF0IGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBIT1NUIGNvbW1hbmQg aXMNCiAgIGlzc3VlZCBhZnRlciB0aGUgdXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIGJ5IHVz aW5nIG9uZSBvZiB0aGUNCiAgIGZvbGxvd2luZyB0d28gYmVoYXZpb3JzOg0KDQogICBhLiAgVHJl YXQgdGhlIGxhdGUgSE9TVCBjb21tYW5kIGFzIGFuIGVycm9uZW91cyBzZXF1ZW5jZSBvZiBjb21t YW5kcw0KICAgICAgIGFuZCByZXR1cm4gYSA1MDMgcmVwbHkuDQoNCiAgIGIuICBUcmVhdCB0aGUg bGF0ZSBIT1NUIGNvbW1hbmQgYXMgdGhvdWdoIGEgUkVJTiBjb21tYW5kIHdhcyBzZW50DQogICAg ICAgYmVmb3JlIHRoZSBIT1NUIGNvbW1hbmQgYW5kIHJlc2V0IHRoZSB1c2VyLVBJIHRvIHRoZSBz dGF0ZSB0aGF0DQogICAgICAgZXhpc3RlZCBhZnRlciB0aGUgVENQIGNvbm5lY3Rpb24gd2FzIGZp cnN0IGVzdGFibGlzaGVkIGFuZCBiZWZvcmUNCiAgICAgICB0aGUgaW5pdGlhbCB1c2VyIGF1dGhl bnRpY2F0aW9uIGFuZCB0aGVuIHJldHVybiB0aGUgYXBwcm9wcmlhdGUNCiAgICAgICByZXBseSBm b3IgdGhlIEhPU1QgY29tbWFuZC4NCg0KICAgU2VydmVycyBzaG91bGQgbm90ZSB0aGF0IHRoZSBy ZXNwb25zZSB0byB0aGUgSE9TVCBjb21tYW5kIGlzIGENCiAgIHNlbnNpYmxlIHRpbWUgdG8gc2Vu ZCB0aGVpciAid2VsY29tZSIgbWVzc2FnZS4gIFRoaXMgYWxsb3dzIHRoZQ0KICAgbWVzc2FnZSB0 byBiZSBwZXJzb25hbGl6ZWQgZm9yIGFueSB2aXJ0dWFsIGhvc3RzIHRoYXQgYXJlIHN1cHBvcnRl ZCwNCiAgIGFuZCBhbHNvIGFsbG93cyB0aGUgY2xpZW50IHRvIGRldGVybWluZSB0aGUgc3VwcG9y dGVkIGxhbmd1YWdlcywgb3INCiAgIHJlcHJlc2VudGF0aW9ucywgZm9yIHRoZSBtZXNzYWdlLCBh bmQgb3RoZXIgbWVzc2FnZXMsIHZpYSB0aGUgRkVBVA0KICAgcmVzcG9uc2UsIGFuZCBzZWxlY3Qg YW4gYXBwcm9wcmlhdGUgb25lIHZpYSB0aGUgTEFORyBjb21tYW5kLiAgU2VlDQogICBbUkZDMjY0 MF0gZm9yIG1vcmUgaW5mb3JtYXRpb24uDQoNCjMuMS4gIFN5bnRheCBvZiB0aGUgSE9TVCBjb21t YW5kDQoNCiAgIFRoZSBIT1NUIGNvbW1hbmQgaXMgZGVmaW5lZCBhcyBmb2xsb3dzLg0KDQoNCg0K DQoNCg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNlbWJlciAzMSwg MjAxMSAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQIEhP U1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTENCg0KDQogICAg IGhvc3QtY29tbWFuZCAgPSAiSE9TVCIgU1AgaG9zdG5hbWUgQ1JMRg0KICAgICBob3N0bmFtZSAg ICAgID0gZG9tYWluIC8gSVAtbGl0ZXJhbA0KDQogICAgIGRvbWFpbiAgICAgICAgPSBzdWItZG9t YWluICooIi4iIHN1Yi1kb21haW4pDQogICAgIHN1Yi1kb21haW4gICAgPSBsZXQtZGlnIFtsZGgt c3RyXQ0KICAgICBsZXQtZGlnICAgICAgID0gQUxQSEEgLyBESUdJVA0KICAgICBsZGgtc3RyICAg ICAgID0gKiggQUxQSEEgLyBESUdJVCAvICItIiApIGxldC1kaWcNCg0KICAgICBJUC1saXRlcmFs ICAgID0gKCAiWyIgSVB2NmFkZHJlc3MgIl0iICkgLyBJUHY0YWRkcmVzcw0KDQogICAgIElQdjZh ZGRyZXNzICAgPSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYoIGgxNiAiOiIgKSBsczMy DQogICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICAgICAgICAiOjoiIDUoIGgx NiAiOiIgKSBsczMyDQogICAgICAgICAgICAgICAgICAgICAvIFsgICAgICAgICAgICAgICBoMTYg XSAiOjoiIDQoIGgxNiAiOiIgKSBsczMyDQogICAgICAgICAgICAgICAgICAgICAvIFsgKjEoIGgx NiAiOiIgKSBoMTYgXSAiOjoiIDMoIGgxNiAiOiIgKSBsczMyDQogICAgICAgICAgICAgICAgICAg ICAvIFsgKjIoIGgxNiAiOiIgKSBoMTYgXSAiOjoiIDIoIGgxNiAiOiIgKSBsczMyDQogICAgICAg ICAgICAgICAgICAgICAvIFsgKjMoIGgxNiAiOiIgKSBoMTYgXSAiOjoiICAgIGgxNiAiOiIgICBs czMyDQogICAgICAgICAgICAgICAgICAgICAvIFsgKjQoIGgxNiAiOiIgKSBoMTYgXSAiOjoiICAg ICAgICAgICAgICBsczMyDQogICAgICAgICAgICAgICAgICAgICAvIFsgKjUoIGgxNiAiOiIgKSBo MTYgXSAiOjoiICAgICAgICAgICAgICBoMTYNCiAgICAgICAgICAgICAgICAgICAgIC8gWyAqNigg aDE2ICI6IiApIGgxNiBdICI6OiINCg0KICAgICBsczMyICAgICAgICAgID0gKCBoMTYgIjoiIGgx NiApIC8gSVB2NGFkZHJlc3MNCiAgICAgICAgICAgICAgICAgICAgIDsgbGVhc3Qtc2lnbmlmaWNh bnQgMzIgYml0cyBvZiBhZGRyZXNzDQoNCiAgICAgaDE2ICAgICAgICAgICA9IDEqNEhFWERJRw0K ICAgICAgICAgICAgICAgICAgICAgOyAxNiBiaXRzIG9mIGFkZHJlc3MgcmVwcmVzZW50ZWQgaW4g aGV4YWRlY2ltYWwNCg0KICAgICBJUHY0YWRkcmVzcyAgID0gZGVjLW9jdGV0ICIuIiBkZWMtb2N0 ZXQgIi4iIGRlYy1vY3RldCAiLiIgZGVjLW9jdGV0DQoNCiAgICAgZGVjLW9jdGV0ICAgICA9IERJ R0lUICAgICAgICAgICAgICAgICA7IDAtOQ0KICAgICAgICAgICAgICAgICAgICAgLyAleDMxLTM5 IERJR0lUICAgICAgIDsgMTAtOTkNCiAgICAgICAgICAgICAgICAgICAgIC8gIjEiIDJESUdJVCAg ICAgICAgICA7IDEwMC0xOTkNCiAgICAgICAgICAgICAgICAgICAgIC8gIjIiICV4MzAtMzQgRElH SVQgICA7IDIwMC0yNDkNCiAgICAgICAgICAgICAgICAgICAgIC8gIjI1IiAleDMwLTM1ICAgICAg ICA7IDI1MC0yNTUNCg0KICAgICBob3N0LXJlc3BvbnNlID0gaG9zdC1vayAvIGVycm9yLXJlc3Bv bnNlDQogICAgIGhvc3Qtb2sgICAgICAgPSAiMjIwIiBbIFNQICpUQ0hBUiBdIENSTEYNCg0KICAg QXMgd2l0aCBhbGwgRlRQIGNvbW1hbmRzLCB0aGUgIkhPU1QiIGNvbW1hbmQgd29yZCBpcyBjYXNl DQogICBpbmRlcGVuZGVudCwgYW5kIE1BWSBiZSBzcGVjaWZpZWQgaW4gYW55IGNoYXJhY3RlciBj YXNlIGRlc2lyZWQuDQoNCiAgIFRoZSAiaG9zdG5hbWUiIChnaXZlbiBhcyBhIHBhcmFtZXRlcikg c3BlY2lmaWVzIHRoZSB2aXJ0dWFsIGhvc3QgdG8NCiAgIHdoaWNoIGFjY2VzcyBpcyBkZXNpcmVk LiAgVGhpcyBTSE9VTEQgYmUgdGhlIHNhbWUgaG9zdCBuYW1lIHRoYXQgd2FzDQogICB1c2VkIHRv IG9idGFpbiB0aGUgSVAgYWRkcmVzcyB0byB3aGljaCB0aGUgRlRQIGNvbnRyb2wgY29ubmVjdGlv biB3YXMNCiAgIG1hZGUsIGFmdGVyIGFueSBjbGllbnQgY29udmVyc2lvbnMgaGF2ZSBiZWVuIGNv bXBsZXRlZCB0aGF0IGNvbnZlcnQNCiAgIGFuIGFiYnJldmlhdGVkIG9yIGxvY2FsIGFsaWFzIHRv IGEgY29tcGxldGUgKGZ1bGx5IHF1YWxpZmllZCkgZG9tYWluDQogICBuYW1lLCBidXQgYmVmb3Jl IHJlc29sdmluZyBhIEROUyBhbGlhcyAob3duZXIgb2YgYSBDTkFNRSByZXNvdXJjZQ0KICAgcmVj b3JkKSB0byBpdHMgY2Fub25pY2FsIG5hbWUuDQoNCg0KDQoNCkhldGhtb24gJiBNY011cnJheSAg ICAgIEV4cGlyZXMgRGVjZW1iZXIgMzEsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAg ICAgICAgSnVuZSAyMDExDQoNCg0KICAgSW50ZXJuYXRpb25hbGl6YXRpb24gb2YgZG9tYWluIG5h bWVzIGlzIG9ubHkgc3VwcG9ydGVkIHRocm91Z2ggdGhlDQogICB1c2Ugb2YgUHVueWNvZGUgYXMg ZGVzY3JpYmVkIGluIFtSRkMzNDkyXS4NCg0KICAgSWYgdGhlIHVzZXIgd2FzIGdpdmVuIGFuIElQ djQgb3IgSVB2NiBsaXRlcmFsIGFkZHJlc3MsIGFuZA0KICAgY29uc2VxdWVudGx5IHdhcyBub3Qg cmVxdWlyZWQgdG8gZGVyaXZlIHRoZSBsaXRlcmFsIGFkZHJlc3MgZnJvbSBhDQogICBob3N0bmFt ZSwgdGhlIGNsaWVudCBNQVkgc2VuZCB0aGUgSE9TVCBjb21tYW5kIHdpdGggdGhlIElQdjQgb3Ig SVB2Ng0KICAgbGl0ZXJhbCBhZGRyZXNzIGFzIHNwZWNpZmllZCB0byBpdC4gIFdoaWxlIGl0IG1h eSBzZWVtIGNvdW50ZXItDQogICBpbnR1aXRpdmUgdG8gc3BlY2lmeSBhIGxpdGVyYWwgYWRkcmVz cyBieSB1c2luZyB0aGUgSE9TVCBjb21tYW5kDQogICBhZnRlciB0aGUgY2xpZW50IGhhcyBhbHJl YWR5IGNvbm5lY3RlZCB0byB0aGUgc2VydmVyIHVzaW5nIGEgbGl0ZXJhbA0KICAgYWRkcmVzcywg dGhpcyBzaG91bGQgYmUgZXhwZWN0ZWQgYmVoYXZpb3IgYmVjYXVzZSBhIHVzZXItRlRQIHByb2Nl c3MNCiAgIHNob3VsZCBub3QgYmUgcmVxdWlyZWQgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGEg ZnVsbHkgcXVhbGlmaWVkDQogICBkb21haW4gbmFtZSBhbmQgYW4gSVB2NCBvciBJUHY2IG5ldHdv cmsgbGl0ZXJhbCBhZGRyZXNzLiAgVGhhdCBiZWluZw0KICAgc2FpZCwgaWYgdGhlIElQdjQgb3Ig SVB2NiBsaXRlcmFsIGFkZHJlc3Mgc3BlY2lmaWVkIGJ5IHRoZSBjbGllbnQNCiAgIGRvZXMgbm90 IG1hdGNoIHRoZSBsaXRlcmFsIGFkZHJlc3MgZm9yIHRoZSBzZXJ2ZXIsIHRoZSBzZXJ2ZXIgTVVT VA0KICAgcmVzcG9uZCB3aXRoIGEgNTA0IHJlcGx5IHRvIGluZGljYXRlIHRoYXQgdGhlIElQdjQg b3IgSVB2NiBsaXRlcmFsDQogICBhZGRyZXNzIGlzIG5vdCB2YWxpZC4NCg0KICAgV2hlbiB0aGUg aG9zdG5hbWUgcGFyYW1ldGVyIGNvbnRhaW5zIGEgbGl0ZXJhbCBhZGRyZXNzLCBzcXVhcmUNCiAg IGJyYWNrZXRzIGFyZSBleHBlY3RlZCB0byBkaXNhbWJpZ3VhdGUgSVB2NiBhZGRyZXNzIHN5bnRh eCBmcm9tIHBvcnQNCiAgIG51bWJlcnMgc3ludGF4LiAgVGhlcmVmb3JlLCBpZiB0aGUgbGl0ZXJh bCBhZGRyZXNzIGlzIGFuIElQdjYNCiAgIGFkZHJlc3MsIHRoZSBJUHY2IGFkZHJlc3MgaXMgcmVx dWlyZWQgdG8gYmUgZW5jbG9zZWQgaW4gc3F1YXJlDQogICBicmFja2V0cyAoYWZ0ZXIgZWxpbWlu YXRpbmcgYW55IHN5bnRheCB0aGF0IG1pZ2h0IGFsc28gLSBidXQgaXMgbm90DQogICByZXF1aXJl ZCB0byAtIGJlIGVuY2xvc2VkIGluIGJyYWNrZXRzLCBhbmQgZnJvbSB3aGljaCB0aGUgc2VydmVy DQogICBkZWR1Y2VkIHRoYXQgYSBsaXRlcmFsIGFkZHJlc3MgaGFkIGJlZW4gc3BlY2lmaWVkLikg IEZvciBleGFtcGxlLCB0aGUNCiAgIGZvbGxvd2luZyBleGFtcGxlcyBNQVkgYmUgc2VudCBpZiB0 aGUgY2xpZW50IGhhZCBiZWVuIGluc3RydWN0ZWQgdG8NCiAgIHJlc3BlY3RpdmVseSBjb25uZWN0 IHRvICIxOTIuMC4yLjEiLCAiRkU4MDo6YzAwMDowMjAxIiwgb3INCiAgICIxOTIuMC4yLjEiIGFu ZCBJUHY2IHN5bnRheCBpcyBwcmVmZXJyZWQ6DQoNCiAgICAgICAgSE9TVCAxOTIuMC4yLjENCiAg ICAgICAgSE9TVCBbRkU4MDo6YzAwMDowMjAxXQ0KICAgICAgICBIT1NUIFs6OjE5Mi4wLjIuMV0N Cg0KICAgVGhlIGNsaWVudCBNVVNUIE5PVCBzZW5kIHRoZSBwb3J0IG51bWJlciBhcyBwYXJ0IG9m IHRoZSBIT1NUIGNvbW1hbmQsDQogICBldmVuIHdoZW4gdGhlIGNsaWVudCBoYXMgYmVlbiBpbnN0 cnVjdGVkIHRvIGNvbm5lY3QgdG8gYSBub24tc3RhbmRhcmQNCiAgIHBvcnQuICBUaGUgcmVhc29u IGZvciB0aGlzIHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlIHVzZXItUEkgd2lsbCBoYXZlDQogICBl c3RhYmxpc2hlZCBhIGNvbm5lY3Rpb24gdG8gdGhlIHNlcnZlci1QSSBiZWZvcmUgdGhlIEhPU1Qg Y29tbWFuZCBpcw0KICAgc2VudCwgdGhlcmVmb3JlIHNwZWNpZnlpbmcgYSBkaWZmZXJlbnQgcG9y dCB3aXRoIHRoZSBIT1NUIGNvbW1hbmQgaGFzDQogICBubyBtZWFuaW5nLiAgRm9yIGV4YW1wbGUs IHRoZSBzZXJ2ZXItUEkgTVVTVCByZXNwb25kIHdpdGggYSA1MDEgcmVwbHkNCiAgIGlmIHRoZSBj bGllbnQgc2VuZHMgYSBIT1NUIGNvbW1hbmQgd2l0aCBzeW50YXggbGlrZSBlaXRoZXIgb2YgdGhl DQogICBmb2xsb3dpbmcgZXhhbXBsZXM6DQoNCiAgICAgICAgSE9TVCAxOTIuMC4yLjE6MjExMg0K ICAgICAgICBIT1NUIFtGRTgwOjpjMDAwOjAyMDFdOjIxMTINCg0KICAgVGhlIGhvc3RuYW1lIHBh cmFtZXRlciBpcyBvdGhlcndpc2UgdG8gYmUgdHJlYXRlZCBhcyBhIGZ1bGx5DQogICBxdWFsaWZp ZWQgZG9tYWluIG5hbWUgb3IgcmVsYXRpdmUgbmFtZSBhcyB0aG9zZSB0ZXJtcyBhcmUgZGVmaW5l ZCBpbg0KICAgc2VjdGlvbiAzLjEgb2YgW1JGQzEwMzRdLiAgVGhpcyBpbXBsaWVzIHRoYXQgdGhl IG5hbWUgaXMgdG8gYmUNCiAgIHRyZWF0ZWQgYXMgYSBjYXNlLWluZGVwZW5kZW50IHN0cmluZywg bWVhbmluZyB0aGF0IHVwcGVyY2FzZSBBU0NJSQ0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAg ICAgRXhwaXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAg ICAgICBKdW5lIDIwMTENCg0KDQogICBjaGFyYWN0ZXJzIGFyZSB0byBiZSB0cmVhdGVkIGFzIGVx dWl2YWxlbnQgdG8gdGhlaXIgY29ycmVzcG9uZGluZw0KICAgbG93ZXJjYXNlIEFTQ0lJIGNoYXJh Y3RlcnMsIGJ1dCBvdGhlcndpc2UgcHJlc2VydmVkIGFzIGdpdmVuLiAgSXQNCiAgIGFsc28gaW1w bGllcyBzb21lIGxpbWl0cyBvbiB0aGUgbGVuZ3RoIG9mIHRoZSBwYXJhbWV0ZXIgYW5kIG9mIHRo ZQ0KICAgY29tcG9uZW50cyB0aGF0IGNyZWF0ZSBpdHMgaW50ZXJuYWwgc3RydWN0dXJlLiAgVGhv c2UgbGltaXRzIGFyZSBub3QNCiAgIGFsdGVyZWQgaW4gYW55IHdheSBoZXJlLg0KDQogICBOZWl0 aGVyIFtSRkMxMDM0XSBub3IgW1JGQzEwMzVdIGltcG9zZSBhbnkgb3RoZXIgcmVzdHJpY3Rpb25z IHVwb24NCiAgIHdoYXQga2luZHMgb2YgbmFtZXMgY2FuIGJlIHN0b3JlZCBpbiB0aGUgRE5TLiAg VGhpcyBzcGVjaWZpY2F0aW9uLA0KICAgaG93ZXZlciwgb25seSBhbGxvd3MgdGhlIHVzZSBvZiBu YW1lcyB0aGF0IGNhbiBiZSBpbmZlcnJlZCBmcm9tIHRoZQ0KICAgQUJORiBncmFtbWFyIGdpdmVu IGZvciB0aGUgImhvc3RuYW1lIi4NCg0KMy4yLiAgSE9TVCBjb21tYW5kIHNlbWFudGljcw0KDQog ICBVcG9uIHJlY2VpdmluZyB0aGUgSE9TVCBjb21tYW5kLCBiZWZvcmUgYXV0aGVudGljYXRpbmcg dGhlIHVzZXItUEksIGENCiAgIHNlcnZlci1GVFAgcHJvY2VzcyBTSE9VTEQgdmFsaWRhdGUgdGhh dCB0aGUgaG9zdG5hbWUgZ2l2ZW4gcmVwcmVzZW50cw0KICAgYSB2YWxpZCB2aXJ0dWFsIGhvc3Qg Zm9yIHRoYXQgc2VydmVyLCBhbmQsIGlmIGl0IGlzIHZhbGlkLCBlc3RhYmxpc2gNCiAgIHRoZSBh cHByb3ByaWF0ZSBlbnZpcm9ubWVudCBmb3IgdGhhdCB2aXJ0dWFsIGhvc3QuICBUaGUgcmVzdWx0 YW50DQogICBhY3Rpb25zIG5lZWRlZCB0byBjcmVhdGUgdGhhdCBlbnZpcm9ubWVudCBhcmUgbm90 IHNwZWNpZmllZCBoZXJlLCBhbmQNCiAgIG1heSByYW5nZSBmcm9tIGRvaW5nIG5vdGhpbmcgYXQg YWxsLCB0byBwZXJmb3JtaW5nIGEgc2ltcGxlIGNoYW5nZSBvZg0KICAgd29ya2luZyBkaXJlY3Rv cnksIGNoYW5naW5nIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgYW5kL29yIHVzZXJuYW1lDQogICBh bmQgcGFzc3dvcmQgbGlzdHMsIG9yIG1ha2luZyBtdWNoIG1vcmUgZWxhYm9yYXRlIHN0YXRlIGNo YW5nZXMgLQ0KICAgc3VjaCBhcyBjcmVhdGluZyBpc29sYXRlZCBlbnZpcm9ubWVudHMgZm9yIGVh Y2ggRlRQIHNlc3Npb24uDQoNCiAgIFRoZSAiMjIwIiByZXBseSBjb2RlIGZvciB0aGUgSE9TVCBj b21tYW5kIGlzIHRoZSBzYW1lIGFzIHRoZSBjb2RlDQogICB0aGF0IGlzIHVzZWQgaW4gdGhlIGlu aXRpYWwgIndlbGNvbWUiIG1lc3NhZ2UgdGhhdCBpcyBzZW50IGFmdGVyIHRoZQ0KICAgY29ubmVj dGlvbiBpcyBlc3RhYmxpc2hlZC4NCg0KICAgSWYgdGhlIGhvc3RuYW1lIHNwZWNpZmllZCB3b3Vs ZCBub3JtYWxseSBiZSBhY2NlcHRhYmxlLCBidXQgZm9yIGFueQ0KICAgcmVhc29uIGlzIHRlbXBv cmFyaWx5IHVuYXZhaWxhYmxlLCB0aGUgc2VydmVyLUZUUCBwcm9jZXNzIFNIT1VMRA0KICAgcmVw bHkgdG8gdGhlIEhPU1QgY29tbWFuZCB3aXRoIGEgNDIxIHJlcGx5IGFuZCBjbG9zZSB0aGUgY29u bmVjdGlvbi4NCiAgIEluIHRoaXMgcGFydGljdWxhciBzaXR1YXRpb24sIHRoZSBzZXJ2ZXItRlRQ IHByb2Nlc3MgTUFZIGNob29zZSB0bw0KICAga2VlcCB0aGUgY29ubmVjdGlvbiBvcGVuIGluIG9y ZGVyIHRvIGFsbG93IHRoZSB1c2VyLVBJIGFuIG9wcG9ydHVuaXR5DQogICB0byBjaG9vc2UgYW5v dGhlciB2aXJ0dWFsIGhvc3Qgd2l0aCBhIHN1YnNlcXVlbnQgSE9TVCBjb21tYW5kLg0KDQogICBJ ZiB0aGUgaG9zdG5hbWUgc3BlY2lmaWVkIGlzIHVua25vd24gYXQgdGhlIHNlcnZlciwgb3IgaWYg dGhlIHNlcnZlcg0KICAgaXMgb3RoZXJ3aXNlIHVud2lsbGluZyB0byB0cmVhdCB0aGUgcGFydGlj dWxhciBjb25uZWN0aW9uIGFzIGENCiAgIGNvbm5lY3Rpb24gdG8gdGhlIGhvc3RuYW1lIHNwZWNp ZmllZCwgdGhlIHNlcnZlciBTSE9VTEQgcmVzcG9uZCB3aXRoDQogICBhIDUwNCByZXBseS4NCg0K My4yLjEuICBSRUlOIGNvbW1hbmQgc2VtYW50aWNzDQoNCiAgIEFzIHNwZWNpZmllZCBpbiBbUkZD MDk1OV0sIHRoZSBSRUlOIGNvbW1hbmQgcmV0dXJucyB0aGUgc3RhdGUgb2YgdGhlDQogICBjb25u ZWN0aW9uIHRvIHdoYXQgaXQgd2FzIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSB0cmFuc3BvcnQgY29u bmVjdGlvbg0KICAgd2FzIG9wZW5lZC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBtYWtlcyBubyBjaGFu Z2VzIHRvIHRoYXQgYmVoYXZpb3IuDQogICBUaGUgZWZmZWN0IG9mIGEgSE9TVCBjb21tYW5kIE1V U1QgYmUgcmVzZXQgaWYgYSBSRUlOIGNvbW1hbmQgaXMNCiAgIHBlcmZvcm1lZCwgYW5kIGEgbmV3 IEhPU1QgY29tbWFuZCBNVVNUIGJlIGlzc3VlZCBpbiBvcmRlciB0byBjb25uZWN0DQogICB0byBh IHZpcnR1YWwgaG9zdC4NCg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBE ZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIw MTENCg0KDQozLjIuMi4gIFVzZXItUEkgdXNhZ2Ugb2YgSE9TVA0KDQogICBBIHVzZXItUEkgdGhh dCBjb25mb3JtcyB0byB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBzZW5kIHRoZSBIT1NUDQogICBj b21tYW5kIGFmdGVyIG9wZW5pbmcgdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uLCBvciBhZnRlciBh bnkgUkVJTg0KICAgY29tbWFuZCwgYmVmb3JlIGF0dGVtcHRpbmcgdG8gYXV0aGVudGljYXRlIHRo ZSB1c2VyIHdpdGggdGhlIFVTRVINCiAgIGNvbW1hbmQuICBUaGUgZm9sbG93aW5nIGV4YW1wbGUg aWxsdXN0cmF0ZXMgd2hhdCBhIHR5cGljYWwgbG9naW4NCiAgIHNlcXVlbmNlIG1pZ2h0IGxvb2sg bGlrZSB3aGVuIHRoZSBIT1NUIGNvbW1hbmQgaXMgdXNlZDoNCg0KICAgICAgICBDPiBIT1NUIGZ0 cC5leGFtcGxlLmNvbQ0KICAgICAgICBTPiAyMjAgSG9zdCBhY2NlcHRlZA0KICAgICAgICBDPiBV U0VSIGZvbw0KICAgICAgICBTPiAzMzEgUGFzc3dvcmQgcmVxdWlyZWQNCiAgICAgICAgQz4gUEFT UyBiYXINCiAgICAgICAgUz4gMjMwIFVzZXIgbG9nZ2VkIGluDQoNCiAgIElmIGEgdXNlci1QSSBz ZW5kcyBhbiBhZGRpdGlvbmFsIEhPU1QgY29tbWFuZCBiZWZvcmUgYXR0ZW1wdGluZyB0bw0KICAg YXV0aGVudGljYXRlIHRoZSB1c2VyLCBhIHNlcnZlci1GVFAgcHJvY2VzcyB0aGF0IGNvbmZvcm1z IHRvIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gTVVTVCB0cmVhdCB0aGUgYWRkaXRpb25hbCBIT1NU IGNvbW1hbmQgYXMgdGhvdWdoIGEgUkVJTg0KICAgY29tbWFuZCB3YXMgc2VudCwgYW5kIHJlc2V0 IHRoZSB1c2VyLVBJIHRvIHRoZSBzdGF0ZSB0aGF0IGV4aXN0ZWQNCiAgIGFmdGVyIHRoZSBUQ1Ag Y29ubmVjdGlvbiB3YXMgZmlyc3QgZXN0YWJsaXNoZWQuICBGb3IgZXhhbXBsZSwgaWYgYQ0KICAg dXNlciBzcGVjaWZpZXMgdGhlIHdyb25nIHZpcnR1YWwgaG9zdCBieSBtaXN0YWtlLCBzZW5kaW5n IGENCiAgIHN1YnNlcXVlbnQgSE9TVCBjb21tYW5kIHdpbGwgcmVjdGlmeSB0aGUgZXJyb3IuICBU aGUgZm9sbG93aW5nDQogICBleGFtcGxlIGlsbHVzdHJhdGVzIHdoYXQgdGhlIGxvZ2luIHNlcXVl bmNlIG1pZ2h0IGxvb2sgbGlrZSB3aGVuIHRoZQ0KICAgSE9TVCBjb21tYW5kIGlzIHNlbnQgdHdp Y2UgYmVmb3JlIGEgdXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkOg0KDQogICAgICAgIEM+IEhP U1QgZm9vLmV4YW1wbGUuY29tDQogICAgICAgIFM+IDIyMCBIb3N0IGFjY2VwdGVkDQogICAgICAg IEM+IEhPU1QgYmFyLmV4YW1wbGUuY29tDQogICAgICAgIFM+IDIyMCBIb3N0IGFjY2VwdGVkDQog ICAgICAgIEM+IFVTRVIgZm9vDQogICAgICAgIFM+IDMzMSBQYXNzd29yZCByZXF1aXJlZA0KICAg ICAgICBDPiBQQVNTIGJhcg0KICAgICAgICBTPiAyMzAgVXNlciBsb2dnZWQgaW4NCg0KICAgVGhl IEhPU1QgY29tbWFuZCBjYW4gYmUgdXNlZCBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZSBBQ0NUIGNv bW1hbmQgdG8NCiAgIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBhIHVzZXIncyB2YXJpb3VzIGFjY291 bnRzIG9uIGEgc3BlY2lmaWMgdmlydHVhbA0KICAgaG9zdC4gIEluIHRoaXMgc2NlbmFyaW8sIHRo ZSB1c2VyLVBJIHNlbmRzIGEgSE9TVCBjb21tYW5kIHdoaWNoIHRoZQ0KICAgc2VydmVyLVBJIHVz ZXMgdG8gcm91dGUgYWN0aXZpdHkgdG8gdGhlIGNvcnJlY3QgdmlydHVhbCBob3N0OyB0aGUNCiAg IHVzZXItUEkgc2VuZHMgY3JlZGVudGlhbHMgdXNpbmcgdGhlIFVTRVIgYW5kIFBBU1MgY29tbWFu ZHMgd2hpY2ggdGhlDQogICBzZXJ2ZXItUEkgdmFsaWRhdGVzOyB0aGVuLCB0aGUgdXNlci1QSSBz ZW5kcyBhbiBBQ0NUIGNvbW1hbmQgdG8NCiAgIHNwZWNpZnkgYW55IGFkZGl0aW9uYWwgYWNjb3Vu dCBpbmZvcm1hdGlvbiBmb3IgdGhlIHNlcnZlci1QSQ0KICAgaW1wbGVtZW50YXRpb24uICBUaGUg Zm9sbG93aW5nIGV4YW1wbGUgaWxsdXN0cmF0ZXMgYSBzZXF1ZW50aWFsDQogICBzZXJpZXMgb2Yg Y2xpZW50IGNvbW1hbmRzIHRoYXQgc3BlY2lmeSBib3RoIGEgSE9TVCBhbmQgQUNDVCwgd2l0aCB0 aGUNCiAgIHNlcnZlciByZXNwb25zZXMgb21pdHRlZCBmb3IgYnJldml0eToNCg0KDQoNCg0KDQoN Cg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAg ICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQIEhPU1QgQ29tbWFu ZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTENCg0KDQogICAgICAgIEM+IEhP U1QgZnRwLmV4YW1wbGUuY29tDQogICAgICAgIEM+IFVTRVIgZm9vDQogICAgICAgIEM+IFBBU1Mg YmFyDQogICAgICAgIEM+IEFDQ1QgcHJvamVjdDENCg0KICAgVGhpcyBpcyBhbHNvIHRydWUgd2hl biB0aGUgSE9TVCBjb21tYW5kIGlzIHVzZWQgd2l0aCB0aGUgQVVUSCBhbmQNCiAgIEFEQVQgY29t bWFuZHMgdGhhdCBhcmUgZGlzY3Vzc2VkIGluIFtSRkMyMjI4XSBhbmQgW1JGQzQyMTddLiAgSW4g dGhpcw0KICAgc2NlbmFyaW8sIHRoZSB1c2VyLVBJIHNlbmRzIGEgSE9TVCBjb21tYW5kIHdoaWNo IHRoZSBzZXJ2ZXItUEkgdXNlcw0KICAgdG8gcm91dGUgYWN0aXZpdHkgdG8gdGhlIGNvcnJlY3Qg dmlydHVhbCBob3N0LCB0aGVuIHRoZSB1c2VyLVBJIHVzZXMNCiAgIHRoZSBBVVRIIGFuZCBBREFU IGNvbW1hbmRzIHRvIG5lZ290aWF0ZSB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtIGFuZA0KICAgcmVs ZXZhbnQgYXV0aGVudGljYXRpb24gdG9rZW4ocykgd2l0aCB0aGUgc2VydmVyLVBJLCB0aGVuIHRo ZSB1c2VyLVBJDQogICBzZW5kcyB1c2VyIGNyZWRlbnRpYWxzIHVzaW5nIHRoZSBVU0VSIGFuZCBQ QVNTIGNvbW1hbmRzIHdoaWNoIHRoZQ0KICAgc2VydmVyLVBJIHZhbGlkYXRlcy4gIEFmdGVyIHdo aWNoIHRoZSB1c2VyLVBJIE1BWSBzZW5kIGFuIEFDQ1QNCiAgIGNvbW1hbmQgdG8gc3BlY2lmeSBh bnkgYWRkaXRpb25hbCBhY2NvdW50IGluZm9ybWF0aW9uIGZvciB0aGUNCiAgIHNlcnZlci1QSSBp bXBsZW1lbnRhdGlvbi4gIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3RyYXRlcyBhDQogICBz ZXF1ZW50aWFsIHNlcmllcyBvZiBjbGllbnQgY29tbWFuZHMgdGhhdCBzcGVjaWZ5IGJvdGggYSBI T1NUIGFuZA0KICAgQUNDVCB3aGVuIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgc2VjdXJp dHkgY29tbWFuZHMgdGhhdCBhcmUNCiAgIGRpc2N1c3NlZCBpbiBbUkZDMjIyOF0gYW5kIFtSRkM0 MjE3XSwgd2l0aCB0aGUgc2VydmVyIHJlc3BvbnNlcw0KICAgb21pdHRlZCBmb3IgYnJldml0eToN Cg0KICAgICAgICBDPiBIT1NUIGZ0cC5leGFtcGxlLmNvbQ0KICAgICAgICBDPiBBVVRIIDxtZWNo YW5pc20tbmFtZT4NCiAgICAgICAgQz4gQURBVCA8YmFzZTY0ZGF0YT4NCiAgICAgICAgQz4gVVNF UiBmb28NCiAgICAgICAgQz4gUEFTUyBiYXINCiAgICAgICAgQz4gQUNDVCBwcm9qZWN0MQ0KDQoz LjIuMy4gIFN0YXRlIERpYWdyYW1zDQoNCiAgIFRoZSBzdGF0ZSBkaWFncmFtcyBpbiB0aGlzIHNl Y3Rpb24gaWxsdXN0cmF0ZSB0eXBpY2FsIHNlcXVlbmNlcyBmb3INCiAgIGNvbW1hbmQgYW5kIHJl cGx5IGludGVyY2hhbmdlIGJldHdlZW4gdGhlIHVzZXItUEkgYW5kIHNlcnZlci1QSS4NCiAgIFRo ZXNlIGRpYWdyYW1zIGFyZSBtb2RlbGVkIG9uIHRoZSBzaW1pbGFyIGRpYWdyYW1zIGluIHNlY3Rp b24gNiBvZg0KICAgW1JGQzA5NTldLg0KDQogICBJbiBlYWNoIGRpYWdyYW0sIHRoZSAoQikgImJl Z2luIiBzdGF0ZSBpcyBhc3N1bWVkIHRvIG9jY3VyIGFmdGVyIHRoZQ0KICAgdHJhbnNwb3J0IGNv bm5lY3Rpb24gaGFzIG9wZW5lZCwgb3IgYWZ0ZXIgYSBSRUlOIGNvbW1hbmQgaGFzDQogICBzdWNj ZWVkZWQuICBPdGhlciBjb21tYW5kcyAoc3VjaCBhcyBGRUFUIFtSRkMyMzg5XSkgdGhhdCByZXF1 aXJlIG5vDQogICBhdXRoZW50aWNhdGlvbiBtYXkgaGF2ZSBpbnRlcnZlbmVkLg0KDQogICBBZGRp dGlvbmFsbHksIGEgdGhyZWUtZGlnaXQgcmVwbHkgaW5kaWNhdGVzIGEgcHJlY2lzZSBzZXJ2ZXIg cmVwbHkNCiAgIGNvZGUuICBBIHNpbmdsZSBkaWdpdCBvbiBhIHJlcGx5IHBhdGggaW5kaWNhdGVz IGFueSBzZXJ2ZXIgcmVwbHkgdGhhdA0KICAgYmVnaW5zIHdpdGggdGhhdCBkaWdpdCwgZXhjZXB0 IHdoZXJlIGEgcHJlY2lzZSBzZXJ2ZXIgcmVwbHkgY29kZSBpcw0KICAgZGVmaW5lZCBvbiBhbm90 aGVyIHBhdGguICBGb3IgZXhhbXBsZSwgYSBzaW5nbGUgZGlnaXQgIjUiIHdpbGwgYXBwbHkNCiAg IHRvICI1MDAiLCAiNTAxIiwgIjUwMiIsIGV0Yy4sIHdoZW4gdGhvc2UgcmVwbHkgY29kZXMgYXJl IG5vdA0KICAgZXhwcmVzc2x5IGRlZmluZWQgaW4gdGhlIGRpYWdyYW0uICBGb3IgZWFjaCBjb21t YW5kIHRoZXJlIGFyZSB0aHJlZQ0KICAgcG9zc2libGUgb3V0Y29tZXM6IHN1Y2Nlc3MgKFMpLCBm YWlsdXJlIChGKSwgYW5kIGVycm9yIChFKS4gIEluIHRoZQ0KICAgc3RhdGUgZGlhZ3JhbXMgYmVs b3cgd2UgdXNlIHRoZSBzeW1ib2wgQiBmb3IgImJlZ2luIiwgYW5kIHRoZSBzeW1ib2wNCiAgIFcg Zm9yICJ3YWl0IGZvciByZXBseSIuDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBp cmVzIERlY2VtYmVyIDMxLCAyMDExICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1 bmUgMjAxMQ0KDQoNCiAgIEluIGVhY2ggb2YgdGhlc2UgZGlhZ3JhbXMsIGEgUkVJTiBjb21tYW5k IHdpbGwgcmV0dXJuIHRoZSBkaWFncmFtIHRvDQogICB0aGUgKEIpICJiZWdpbiIgc3RhdGUuDQoN CiAgIFRoZSBzdGF0ZSBkaWFncmFtIGluIEZpZ3VyZSAxIHNob3dzIGEgdHlwaWNhbCBzZXF1ZW5j ZSBvZiBmbG93IG9mDQogICBjb250cm9sIHdoZW4gSE9TVCBpcyB1c2VkIHdpdGggVVNFUiBhbmQg UEFTUyB0byBsb2cgaW4gdG8gYQ0KICAgcGFydGljdWxhciBGVFAgdmlydHVhbCBob3N0Lg0KDQog ICAgICAgICAgICAgICstLS0rICAgSE9TVCAgICArLS0tKyAxLDMsNQ0KICAgICAgICAgICAgICB8 IEIgfC0tLS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICArLS0t KyAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IHwgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAy LDUwMCw1MDIgfCB8IDQsNTAxLDUwMyw1MDQgICAgfA0KICAgICAgICAgICAgICAgICAtLS0tLS0t LS0tLS0tLSAgIC0tLS0tLS0tLS0tICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICBWDQogICAgICAgICAgICAgICAgViAgICAgICAgICAg ICAgICAgICAxICAgICAgICB8ICAgICstLS0rDQogICAgICAgICAgICAgICstLS0rICAgVVNFUiAg ICArLS0tKy0tLS0tLS0tLS0tLS0tPnwgRSB8DQogICAgICAgICAgICAgIHwgICB8LS0tLS0tLS0t LT58IFcgfCAyICAgICAgICB8ICAgICstLS0rDQogICAgICAgICAgICAgICstLS0rICAgICAgICAg ICArLS0tKy0tLS0tLS0gICB8ICAgICAgXg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgfCAgICAgICAgfCAgfCAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMyB8 IHwgNCw1ICAgIHwgIHwgICAgICB8DQogICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAg LS0tLS0gICB8ICB8ICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgfCAgfCAgfCAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAxfCAgICAgIHwg IHwgIHwNCiAgICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgfCAgICAgIHwgICAtLS0tLS0+ Ky0tLSsNCiAgICAgICAgICAgICAgKy0tLSsgICBQQVNTICAgICstLS0rIDIgIHwgICAgIHwgICAg fCBTIHwNCiAgICAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0tLS0+ Ky0tLSsNCiAgICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rICAgIHwgICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfDQsNSAgIHwgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgIHwgICAgICAtLS0+Ky0tLSsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAtLS0tLS0tLS0+fCBGIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0+Ky0tLSsNCg0KICAgICAgICAgICAgRmlndXJl IDE6IFR5cGljYWwgbG9naW4gc2VxdWVuY2Ugd2l0aCBIT1NUIGNvbW1hbmQNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNl bWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTEN Cg0KDQogICBUaGUgc3RhdGUgZGlhZ3JhbSBpbiBGaWd1cmUgMiBzaG93cyB0aGUgZmxvdyBvZiBj b250cm9sIHdoZW4gYSBIT1NUDQogICBjb21tYW5kIGlzIHNlbnQgYWZ0ZXIgYSB1c2VyIGhhcyBh bHJlYWR5IHN1Y2Nlc3NmdWxseSBsb2dnZWQgaW4gdG8gYQ0KICAgdmlydHVhbCBob3N0IHdpdGgg VVNFUiBhbmQgUEFTUy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgICAgICAgICstLS0rICAgSE9TVCAgICArLS0tKyAxLDMsNSAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICAgICAgICAgIHwgQiB8LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0tLS0tLS0tLS0t ICAgICAgICAgICB8DQogICAgICAgICAgICAgICstLS0rICAgICAgICAgICArLS0tKyAgICAgICAg ICAgICAgICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8 ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAyLDUw MCw1MDIgfCB8IDQsNTAxLDUwMyw1MDQgICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAg IC0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0gICAgICAgfCAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgViAgICAgICAgICB8 DQogICAgICAgICAgICAgICAgViAgICAgICAgICAgICAgICAgICAxICAgICAgICB8ICAgICstLS0r ICAgICAgICB8DQogICAgICAgICAgICAgICstLS0rICAgVVNFUiAgICArLS0tKy0tLS0tLS0tLS0t LS0tPnwgRSB8ICAgICAgICB8DQogICAgICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfCAy ICAgICAgICB8ICAgICstLS0rICAgICAgICB8DQogICAgICAgICAgICAgICstLS0rICAgICAgICAg ICArLS0tKy0tLS0tLS0gICB8ICAgICAgXiAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCB8ICAgICAgICB8ICB8ICAgICAgfCAgICAgICAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDMgfCB8IDQsNSAgICB8ICB8ICAgICAgfCAgICAgICAgICB8DQog ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAgLS0tLS0tICB8ICB8ICAgICAgfCAgICAg ICAgICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICB8ICB8ICAg ICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAtLS0tLS0t LS0tLS0tLS0tLS0tICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg MXwgICAgICB8ICB8ICB8ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgViAgICAg ICAgICAgICAgIHwgICAgICB8ICAgLS0tLS0tPistLS0rICBIT1NUICB8DQogICAgICAgICAgICAg ICstLS0rICAgUEFTUyAgICArLS0tKyAyICB8ICAgICB8ICAgIHwgUyB8LS0tLS0tLS0NCiAgICAg ICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0tLS0+Ky0tLSsNCiAgICAg ICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rICAgIHwgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfDQsNSAgIHwgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgIHwgICAgICAtLS0+Ky0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAtLS0tLS0tLS0+fCBGIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tLS0tLS0tLS0tLS0tLS0+Ky0tLSsNCg0KICAgICAgICAgICAgRmlndXJlIDI6IExvZ2luIHNl cXVlbmNlIHdpdGggcmVwZWF0ZWQgSE9TVCBjb21tYW5kDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVzIERlY2VtYmVyIDMxLCAyMDEx ICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICBGVFAgSE9TVCBD b21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1bmUgMjAxMQ0KDQoNCiAgIEFmdGVy IGEgdXNlciBoYXMgbG9nZ2VkIGluLCBhbiBhZGRpdGlvbmFsIGFjY291bnQgbWF5IGJlIHJlcXVp cmVkIGJ5DQogICB0aGUgc2VydmVyIGFuZCBzcGVjaWZpZWQgYnkgdGhlIGNsaWVudCBieSB1c2lu ZyBBQ0NUIGNvbW1hbmQuICBXaXRoDQogICB0aGlzIGluIG1pbmQsIHRoZSBzdGF0ZSBkaWFncmFt IGluIEZpZ3VyZSAzIHNob3dzIGEgdHlwaWNhbCBzZXF1ZW5jZQ0KICAgb2YgZmxvdyBvZiBjb250 cm9sIHdoZW4gSE9TVCBpcyB1c2VkIHdpdGggVVNFUiBhbmQgUEFTUyB0byBsb2cgaW4gdG8NCiAg IGFuIEZUUCB2aXJ0dWFsIGhvc3QgYW5kIEFDQ1QgaXMgdXNlZCB0byBzcGVjaWZ5IGFuIGFjY291 bnQuDQoNCiAgICAgICAgICAgICAgKy0tLSsgICBIT1NUICAgICstLS0rIDEsMyw1DQogICAgICAg ICAgICAgIHwgQiB8LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAg ICAgICstLS0rICAgICAgICAgICArLS0tKyAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgIDIsNTAwLDUwMiB8IHwgNCw1MDEsNTAzLDUwNCAgICB8DQogICAgICAgICAgICAgICAg IC0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0tLSAgICAgfA0KICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICAgICBWICAg ICAgICAgICAgICAgICAgIDEgICAgICAgICAgfCAgICBWDQogICAgICAgICAgICAgICstLS0rICAg VVNFUiAgICArLS0tKy0tLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICAgIHwgICB8LS0t LS0tLS0tLT58IFcgfCAyICAgICAgIC0tLS0tPnwgRSB8DQogICAgICAgICAgICAgICstLS0rICAg ICAgICAgICArLS0tKy0tLS0tLSAgfCAgLS0tPistLS0rDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCB8ICAgICAgIHwgfCB8IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MyB8IHwgNCw1ICAgfCB8IHwgfA0KICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0t LS0tICB8IHwgfCB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8IHwg fCB8IHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgfCB8IHwgfA0K ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLSAgfCB8DQogICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgMXwgICAgICB8IHwgICB8IHwNCiAgICAgICAgICAgICAg ICBWICAgICAgICAgICAgICAgfCAgICAgIHwgfCAgIHwgfA0KICAgICAgICAgICAgICArLS0tKyAg IFBBU1MgICAgKy0tLSsgMiAgfCAgLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICAgICB8ICAgfC0t LS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLT58IFMgfA0KICAgICAgICAgICAgICArLS0tKyAg ICAgICAgICAgKy0tLSsgICAtLS0tLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgfCAgIHwgfCAgICAgfCB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg IDMgfCB8NCw1fCB8ICAgICB8IHwNCiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAt LS0tLS0tLSAgIHwgIC0tLS0NCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8 IHwgIHwgIHwgICAgICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCB8 ICB8ICB8ICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0t LS0tICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgMSwzfCAgICB8IHwgIHwg ICAgICAgICB8DQogICAgICAgICAgICAgICAgViAgICAgICAgICAgICAgIHwgICAyfCB8ICB8ICAg ICAgICAgVg0KICAgICAgICAgICAgICArLS0tKyAgIEFDQ1QgICAgKy0tLSstLSAgfCAgIC0tLS0t LT4rLS0tKw0KICAgICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgNCw1IC0tLS0tLS0t LT58IEYgfA0KICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSstLS0tLS0tLS0tLS0t LT4rLS0tKw0KDQogICAgICAgICAgIEZpZ3VyZSAzOiBMb2dpbiBzZXF1ZW5jZSB3aXRoIEhPU1Qg YW5kIEFDQ1QgY29tbWFuZHMNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5 ICAgICAgRXhwaXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAg ICAgICAgICBKdW5lIDIwMTENCg0KDQogICBXaGVuIHRoZSBIT1NUIGNvbW1hbmQgaXMgdXNlZCBp biBjb21iaW5hdGlvbiB3aXRoIHRoZSBGVFAgc2VjdXJpdHkNCiAgIGV4dGVuc2lvbnMgdGhhdCB3 ZXJlIGludHJvZHVjZWQgaW4gW1JGQzIyMjhdLCBpdCBTSE9VTEQgcHJlY2VkZSB0aGUNCiAgIHNl Y3VyaXR5IGhhbmRzaGFrZS4gIFRoaXMgYWxsb3dzIGJvdGggdXNlci1QSSBhbmQgc2VydmVyLUZU UA0KICAgcHJvY2Vzc2VzIHRvIG1hcCBhbiBGVFAgSE9TVCB0byBzZWN1cml0eSBkYXRhIGFwcHJv cHJpYXRlbHkuICBUaGUNCiAgIHN0YXRlIGRpYWdyYW0gaW4gRmlndXJlIDQgc2hvd3MgYSB0eXBp Y2FsIHNlcXVlbmNlIG9mIGZsb3cgb2YgY29udHJvbA0KICAgd2hlbiBIT1NUIGlzIHVzZWQgd2l0 aCB0aGUgQVVUSCBhbmQgQURBVCBjb21tYW5kcyB0aGF0IGFyZSBkaXNjdXNzZWQNCiAgIGluIFtS RkMyMjI4XS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIZXRobW9uICYgTWNNdXJy YXkgICAgICBFeHBpcmVzIERlY2VtYmVyIDMxLCAyMDExICAgICAgICAgICAgICBbUGFnZSAxNF0N CgwNCkludGVybmV0LURyYWZ0ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3Rz ICAgICAgICAgIEp1bmUgMjAxMQ0KDQoNCiAgICAgICAgICAgICAgKy0tLSsgICBIT1NUICAgICst LS0rIDEsMyw1DQogICAgICAgICAgICAgIHwgQiB8LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0tLS0t LS0tLS0tLQ0KICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8ICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgIDIsNTAwLDUwMiB8IHwgNCw1MDEsNTAzLDUwNCAg ICAgfA0KICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0tLS0gICAg ICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg IHwNCiAgICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg fA0KICAgICAgICAgICAgICArLS0tKyAgIEFVVEggICAgKy0tLSsgNCw1ICAgICAgICB8ICAgICB8 DQogICAgICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0tLS0tPnwgICAgIHwN CiAgICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rICAgICAgICAgICAgfCAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgMzM0IHwgfCAgICAgICAgICAgICB8ICAgICB8DQog ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICB8ICAgICAgICAgICAgIHwgICAgIHwNCiAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgMjM0IHwgICAgICAgICAgICAgfCAgICAgfA0KICAg ICAgICAgICAgICAgIHwgICAgLS0tLS0tLS0tLS0tICAgICAgICAgICAgICB8ICAgICB8DQogICAg ICAgICAgICAgICAgViAgIHwgICAgICAgICAgICAgICA0LDUgICAgICAgIHwgICAgIHwNCiAgICAg ICAgICAgICAgKy0tLSsgfCBBREFUICAgICstLS0rLS0tLS0tLS0tLS0+fCAgICAgfA0KICAgICAg ICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgMzM1ICAgICAgICB8ICAgICB8DQogICAgICAg ICAgICAgICstLS0rIHwgICAgICAgICArLS0tKy0tLS0tICAgICAgIHwgICAgIHwNCiAgICAgICAg ICAgICAgICBeICAgfCAgICAgICAgICAgfCAgICAgICB8ICAgICAgfCAgICAgfA0KICAgICAgICAg ICAgICAgIHwgICB8ICAgICAgICAgICB8ICAgICAgIHwgICAgICB8ICAgICB8DQogICAgICAgICAg ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgICAgIHwgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAg ICAgIC0tLS0gICAgICAgIDIzNSB8ICAgICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAg ICB8ICAtLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAg IHwgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgVg0KICAgICAgICAgICAgICAg ViBWICAgICAgICAgICAgICAgICAgMSAgICAgICAgICB8ICAgKy0tLSsNCiAgICAgICAgICAgICAg Ky0tLSsgICBVU0VSICAgICstLS0rLS0tLS0tLS0tLS0tLS0tPnwgRSB8DQogICAgICAgICAgICAg IHwgICB8LS0tLS0tLS0tLT58IFcgfCAyICAgICAgICAgIHwgICArLS0tKw0KICAgICAgICAgICAg ICArLS0tKyAgICAgICAgICAgKy0tLSstLS0tLS0tICAgICB8ICAgICBeDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCB8ICAgICAgICB8ICAgIHwgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMyB8IHwgNCw1ICAgIHwgICAgfCAgICAgfA0KICAgICAgICAgICAgICAg ICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLSAgfCAgICB8ICAgICB8DQogICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgfCB8ICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgMXwgICAgICAgfCB8ICAgIHwNCiAgICAgICAgICAgICAgICBWICAgICAgICAg ICAgICAgfCAgICAgICB8ICAtLS0tLS0tPistLS0rDQogICAgICAgICAgICAgICstLS0rICAgUEFT UyAgICArLS0tKyAyICAgfCAgICAgIHwgICB8IFMgfA0KICAgICAgICAgICAgICB8ICAgfC0tLS0t LS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgICAgKy0tLSsgICAg ICAgICAgICstLS0rICAgICB8ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgIHwgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw0LDUg ICAgfCAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAg ICAgIC0tPistLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIC0t LS0tLS0tLT58IEYgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0t LS0tLS0tLS0+Ky0tLSsNCg0KICAgICAgICAgRmlndXJlIDQ6IExvZ2luIHNlcXVlbmNlIHdpdGgg SE9TVCBhbmQgQVVUSC9BREFUIGNvbW1hbmRzDQoNCg0KDQoNCkhldGhtb24gJiBNY011cnJheSAg ICAgIEV4cGlyZXMgRGVjZW1iZXIgMzEsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAg ICAgICAgSnVuZSAyMDExDQoNCg0KICAgQWZ0ZXIgYSB1c2VyIGhhcyBsb2dnZWQgaW4gd2l0aCB0 aGUgc2VjdXJpdHkgY29tbWFuZHMgdGhhdCBhcmUNCiAgIGRpc2N1c3NlZCBpbiBbUkZDMjIyOF0s IGFuIGFkZGl0aW9uYWwgYWNjb3VudCBtYXkgYmUgcmVxdWlyZWQgYnkgdGhlDQogICBzZXJ2ZXIg YW5kIHNwZWNpZmllZCBieSB0aGUgY2xpZW50IGJ5IHVzaW5nIEFDQ1QgY29tbWFuZC4gIFRoZSBz dGF0ZQ0KICAgZGlhZ3JhbSBpbiBGaWd1cmUgNSBzaG93cyBhIHR5cGljYWwgc2VxdWVuY2Ugb2Yg ZmxvdyBvZiBjb250cm9sIHdoZW4NCiAgIEhPU1QgaXMgdXNlZCB3aXRoIHRoZSBBVVRIIGFuZCBB REFUIGNvbW1hbmRzIHRvIGxvZyBpbiB0byBhbiBGVFANCiAgIHZpcnR1YWwgaG9zdCBhbmQgQUND VCBpcyB1c2VkIHRvIHNwZWNpZnkgYW4gYWNjb3VudC4NCg0KICAgICAgICAgICAgICArLS0tKyAg IEhPU1QgICAgKy0tLSsgMSwzLDUNCiAgICAgICAgICAgICAgfCBCIHwtLS0tLS0tLS0tPnwgVyB8 LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICstLS0rICAgICAgICAgICArLS0tKyAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgMiw1MDAsNTAyIHwgfCA0LDUw MSw1MDMsNTA0ICAgICB8DQogICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tICAgLS0tLS0t LS0tLS0tLS0gICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgfA0KICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICB8DQogICAgICAgICAgICAgICstLS0rICAgQVVUSCAgICArLS0tKyA0LDUgICAg ICAgICB8ICAgIHwNCiAgICAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0t LS0tPnwgICAgfA0KICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgICAgICAg ICAgfCAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAzMzQgfCB8ICAgICAgICAgICAg ICB8ICAgIHwNCiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gIHwgICAgICAgICAgICAg IHwgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAyMzQgfCAgICAgICAgICAgICAg fCAgICB8DQogICAgICAgICAgICAgICAgfCAgICAtLS0tLS0tLS0tLS0gICAgICAgICAgICAgICB8 ICAgIHwNCiAgICAgICAgICAgICAgICBWICAgfCAgICAgICAgICAgICAgIDQsNSAgICAgICAgIHwg ICAgfA0KICAgICAgICAgICAgICArLS0tKyB8IEFEQVQgICAgKy0tLSstLS0tLS0tLS0tLS0+fCAg ICB8DQogICAgICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfCAzMzUgICAgICAgICB8ICAg IHwNCiAgICAgICAgICAgICAgKy0tLSsgfCAgICAgICAgICstLS0rLS0tLS0gICAgICAgIHwgICAg fA0KICAgICAgICAgICAgICAgIF4gICB8ICAgICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICB8 DQogICAgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgIHwN CiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgIHwgICAgfA0K ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICB8DQog ICAgICAgICAgICAgICAgLS0tLSAgICAgICAgIDIzNXwgICAgICAgICAgICAgICB8ICAgIHwNCiAg ICAgICAgICAgICAgIHwgIC0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgICAgIHwgICAgfA0KICAg ICAgICAgICAgICAgfCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8DQogICAg ICAgICAgICAgICBWIFYgICAgICAgICAgICAgICAgICAxICAgICAgICAgICB8ICAgIFYNCiAgICAg ICAgICAgICAgKy0tLSsgICBVU0VSICAgICstLS0rLS0tLS0tLS0tLS0tLS0tPistLS0rDQogICAg ICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfCAyICAgICAgICAtLS0tLT58IEUgfA0KICAg ICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSstLS0tLS0tICB8ICAtLS0+Ky0tLSsNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgIHwgfCB8IHwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMyB8IHwgNCw1ICAgIHwgfCB8IHwNCiAgICAgICAgICAgICAg ICAgLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0gIHwgfCB8IHwNCiAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICB8IHwgfCB8IHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgIC0tLS0tLS0tLS0tICB8IHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAx fCAgICAgICB8IHwgICB8IHwNCiAgICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgfCAgICAg ICB8IHwgICB8IHwNCiAgICAgICAgICAgICAgKy0tLSsgICBQQVNTICAgICstLS0rIDIgICB8ICAt LS0tLS0tPistLS0rDQogICAgICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0t LS0tLS0tLT58IFMgfA0KICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAtLS0t LS0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICB8ICB8 ICAgICB8IHwNCg0KDQoNCkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIg MzEsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZU UCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzIHwgfDQsNXwgIHwgICAgIHwgfA0KICAgICAg ICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLSAgIHwgIC0tLS0NCiAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8ICB8ICB8ICB8ICAgICAgfA0KICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLSAgICAgICB8DQogICAgICAgICAg ICAgICAgfCAgICAgICAgICAgIDEsM3wgICAgfCAgfCAgfCAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICBWICAgICAgICAgICAgICAgfCAgIDJ8ICB8ICB8ICAgICAgICAgVg0KICAgICAgICAgICAg ICArLS0tKyAgIEFDQ1QgICAgKy0tLSstLSAgIHwgICAtLS0tLS0+Ky0tLSsNCiAgICAgICAgICAg ICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8IDQsNSAgLS0tLS0tLS0tPnwgRiB8DQogICAgICAgICAg ICAgICstLS0rICAgICAgICAgICArLS0tKy0tLS0tLS0tLS0tLS0tLT4rLS0tKw0KDQogICAgICBG aWd1cmUgNTogTG9naW4gc2VxdWVuY2Ugd2l0aCBIT1NUIGFuZCBBVVRIL0FEQVQvQUNDVCBjb21t YW5kcw0KDQozLjMuICBIT1NUIGNvbW1hbmQgZXJyb3JzDQoNCiAgIFRoZSBzZXJ2ZXItUEkgU0hP VUxEIHJlcGx5IHdpdGggYSA1MDAgb3IgNTAyIHJlcGx5IGlmIHRoZSBIT1NUDQogICBjb21tYW5k IGlzIHVucmVjb2duaXplZCBvciB1bmltcGxlbWVudGVkLg0KDQogICBBcyBkaXNjdXNzZWQgaW4g c2VjdGlvbiAzIG9mIHRoaXMgZG9jdW1lbnQsIGlmIGEgSE9TVCBjb21tYW5kIGlzIHNlbnQNCiAg IGFmdGVyIGEgdXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIHRoZSBzZXJ2ZXIgU0hPVUxEIGRv IG9uZSBvZiB0aGUNCiAgIGZvbGxvd2luZzoNCg0KICAgYS4gIFNlbmQgYSA1MDMgcmVwbHkgZm9y IGFuIGludmFsaWQgc2VxdWVuY2Ugb2YgY29tbWFuZHMuDQoNCiAgIGIuICBUcmVhdCB0aGUgSE9T VCBjb21tYW5kIGFzIHRob3VnaCBhIFJFSU4gY29tbWFuZCB3YXMgc2VudCBhbmQNCiAgICAgICBy ZXNldCB0aGUgdXNlci1QSSB0byB0aGUgc3RhdGUgdGhhdCBleGlzdGVkIGFmdGVyIHRoZSBwcmV2 aW91cw0KICAgICAgIEhPU1QgY29tbWFuZCB3YXMgc2VudCBhbmQgYmVmb3JlIHRoZSB1c2VyIGhh ZCBiZWVuIGF1dGhlbnRpY2F0ZWQsDQogICAgICAgYW5kIHRoZW4gcmV0dXJuIHRoZSBhcHByb3By aWF0ZSByZXBseSBmb3IgdGhlIEhPU1QgY29tbWFuZC4NCg0KICAgQSA1MDEgcmVwbHkgU0hPVUxE IGJlIHNlbnQgaWYgdGhlIGhvc3RuYW1lIGdpdmVuIGlzIHN5bnRhY3RpY2FsbHkNCiAgIGludmFs aWQsIGFuZCBhIDUwNCByZXBseSBTSE9VTEQgYmUgc2VudCBpZiBhIHN5bnRhY3RpY2FsbHkgdmFs aWQNCiAgIGhvc3RuYW1lIGlzIG5vdCBhIHZhbGlkIHZpcnR1YWwgaG9zdCBuYW1lIGZvciB0aGUg c2VydmVyLiAgSW4gYWxsDQogICBzdWNoIGNhc2VzLCB0aGUgc2VydmVyLUZUUCBwcm9jZXNzIE1V U1QgZG8gb25lIG9mIHRoZSBmb2xsb3dpbmc6DQoNCiAgIGEuICBJZ25vcmUgdGhlIEhPU1QgY29t bWFuZCBhbmQgYWN0IGFzIGlmIGEgSE9TVCBjb21tYW5kIGhhZCBub3QgYmVlbg0KICAgICAgIHNl bnQuICBBIHVzZXItRlRQIHByb2Nlc3MgTUFZIHRoZW4gc2VuZCBhIHN1YnNlcXVlbnQgSE9TVCBj b21tYW5kDQogICAgICAgd2l0aCBhIGRpZmZlcmVudCBob3N0bmFtZS4NCg0KICAgYi4gIENsb3Nl IHRoZSBjb25uZWN0aW9uLg0KDQogICBBIHVzZXItUEkgcmVjZWl2aW5nIGEgNTAwIG9yIDUwMiBy ZXBseSB0byBhIEhPU1QgY29tbWFuZCBTSE9VTEQNCiAgIGFzc3VtZSB0aGF0IHRoZSBzZXJ2ZXIt UEkgZG9lcyBub3QgaW1wbGVtZW50IHZpcnR1YWwgc2VydmVycyBieSB1c2luZw0KICAgdGhlIEhP U1QgY29tbWFuZC4gIFRoZSB1c2VyLVBJIE1BWSB0aGVuIHByb2NlZWQgdG8gbG9naW4gYXMgaWYg dGhlDQogICBIT1NUIGNvbW1hbmQgaGFkIG5vdCBiZWVuIHNlbnQuDQoNCiAgIEEgdXNlci1QSSBy ZWNlaXZpbmcgYW4gZXJyb3IgcmVwbHkgdGhhdCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZXJyb3Jz DQogICB0aGF0IGhhdmUgYmVlbiBkZXNjcmliZWQgaGVyZSBTSE9VTEQgYXNzdW1lIHRoYXQgdGhl IHZpcnR1YWwgSE9TVCBpcw0KICAgdW5hdmFpbGFibGUsIGFuZCB0ZXJtaW5hdGUgY29tbXVuaWNh dGlvbnMuDQoNCg0KDQoNCkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIg MzEsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZU UCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0K ICAgQSBzZXJ2ZXItUEkgdGhhdCByZWNlaXZlcyBhIFVTRVIgY29tbWFuZCB0byBiZWdpbiB0aGUg YXV0aGVudGljYXRpb24NCiAgIHNlcXVlbmNlIHdpdGhvdXQgaGF2aW5nIHJlY2VpdmVkIGEgSE9T VCBjb21tYW5kIFNIT1VMRCBOT1QgcmVqZWN0IHRoZQ0KICAgVVNFUiBjb21tYW5kLiAgQ2xpZW50 cyBjb25mb3JtaW5nIHRvIGVhcmxpZXIgRlRQIHNwZWNpZmljYXRpb25zIGRvDQogICBub3Qgc2Vu ZCBIT1NUIGNvbW1hbmRzLiAgSW4gdGhpcyBjYXNlIHRoZSBzZXJ2ZXIgTUFZIGFjdCBhcyBpZiBz b21lDQogICBkZWZhdWx0IHZpcnR1YWwgaG9zdCBoYWQgYmVlbiBleHBsaWNpdGx5IHNlbGVjdGVk LCBvciBNQVkgZW50ZXIgYW4NCiAgIGVudmlyb25tZW50IHRoYXQgaXMgZGlmZmVyZW50IGZyb20g dGhhdCBvZiBhbnkgc3VwcG9ydGVkIHZpcnR1YWwNCiAgIGhvc3RzLCBwZXJoYXBzIG9uZSBpbiB3 aGljaCBhIHVuaW9uIG9mIGFsbCBhdmFpbGFibGUgYWNjb3VudHMgZXhpc3RzDQogICBhbmQgd2hp Y2ggcHJlc2VudHMgYW4gTlZGUyB0aGF0IGFwcGVhcnMgdG8gY29udGFpbiBzdWJkaXJlY3Rvcmll cw0KICAgdGhhdCBjb250YWluIHRoZSBOVkZTIGZvciBhbGwgc3VwcG9ydGVkIHZpcnR1YWwgaG9z dHMuDQoNCjMuNC4gIEZFQVQgcmVzcG9uc2UgZm9yIEhPU1QgY29tbWFuZA0KDQogICBXaGVuIHJl cGx5aW5nIHRvIHRoZSBGRUFUIGNvbW1hbmQgW1JGQzIzODldLCBhIHNlcnZlci1GVFAgcHJvY2Vz cw0KICAgdGhhdCBzdXBwb3J0cyB0aGUgSE9TVCBjb21tYW5kIE1VU1QgaW5jbHVkZSBhIGxpbmUg Y29udGFpbmluZyB0aGUNCiAgIHNpbmdsZSB3b3JkICJIT1NUIi4gIFRoaXMgd29yZCBpcyBjYXNl IGluc2Vuc2l0aXZlLCBhbmQgTUFZIGJlIHNlbnQNCiAgIGluIGFueSBtaXh0dXJlIG9mIHVwcGVy IG9yIGxvd2VyIGNhc2UsIGhvd2V2ZXIgaXQgU0hPVUxEIGJlIHNlbnQgaW4NCiAgIHVwcGVyIGNh c2UuICBUaGF0IGlzLCB0aGUgcmVzcG9uc2UgU0hPVUxEIGJlOg0KDQogICAgICAgIEM+IEZFQVQN CiAgICAgICAgUz4gMjExLSA8YW55IGRlc2NyaXB0aXZlIHRleHQ+DQogICAgICAgIFM+ICAuLi4N CiAgICAgICAgUz4gIEhPU1QNCiAgICAgICAgUz4gIC4uLg0KICAgICAgICBTPiAyMTEgRW5kDQoN CiAgIFRoZSBlbGxpcHNlcyBpbmRpY2F0ZSBwbGFjZSBob2xkZXJzIHdoZXJlIG90aGVyIGZlYXR1 cmVzIG1heSBiZQ0KICAgaW5jbHVkZWQsIGFuZCBhcmUgbm90IHJlcXVpcmVkLiAgVGhlIG9uZS1z cGFjZSBpbmRlbnRhdGlvbiBvZiB0aGUNCiAgIGZlYXR1cmUgbGluZXMgaXMgbWFuZGF0b3J5IFtS RkMyMzg5XS4NCg0KDQo0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgQXMgZGlzY3Vz c2VkIGluIHNlY3Rpb24gMyBvZiB0aGlzIGRvY3VtZW50LCBhIHNlcnZlciBpbXBsZW1lbnRhdGlv bg0KICAgTVVTVCB0cmVhdCBhIEhPU1QgY29tbWFuZCB0aGF0IHdhcyBzZW50IGJlZm9yZSBhIHVz ZXIgaGFzIGJlZW4NCiAgIGF1dGhlbnRpY2F0ZWQgYXMgdGhvdWdoIGEgUkVJTiBjb21tYW5kIHdh cyBzZW50LCBhbmQgYSBzZXJ2ZXINCiAgIGltcGxlbWVudGF0aW9uIE1BWSB0cmVhdCBhIEhPU1Qg Y29tbWFuZCB0aGF0IHdhcyBzZW50IGFmdGVyIGEgdXNlcg0KICAgaGFzIGJlZW4gYXV0aGVudGlj YXRlZCBhcyB0aG91Z2ggYSBSRUlOIGNvbW1hbmQgd2FzIHNlbnQuICBJbiBlaXRoZXINCiAgIG9m IHRoZXNlIHNjZW5hcmlvcywgdGhlIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBNVVNUIHJlc2V0IHRo ZQ0KICAgYXV0aGVudGljYXRpb24gZW52aXJvbm1lbnQsIGFzIHRoYXQgd291bGQgYWxsb3cgZm9y IHNlZ3JlZ2F0aW9uDQogICBiZXR3ZWVuIHRoZSBzZWN1cml0eSBlbnZpcm9ubWVudHMgZm9yIGVh Y2ggdmlydHVhbCBob3N0IG9uIGFuIEZUUA0KICAgc2VydmVyLiAgVGhlIGltcGxlbWVudGF0aW9u IGRldGFpbHMgZm9yIHNlY3VyaXR5IGVudmlyb25tZW50cyBtYXkNCiAgIHZhcnkgZ3JlYXRseSBi YXNlZCBvbiB0aGUgcmVxdWlyZW1lbnRzIG9mIGVhY2ggc2VydmVyIGltcGxlbWVudGF0aW9uDQog ICBhbmQgb3BlcmF0aW5nIHN5c3RlbSwgYW5kIHRob3NlIGRldGFpbHMgYXJlIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoZQ0KICAgcHJvdG9jb2wgaXRzZWxmLiAgRm9yIGV4YW1wbGUsIGEgdmlydHVh bCBob3N0ICJmb28uZXhhbXBsZS5jb20iIG9uIGFuDQogICBGVFAgc2VydmVyIG1pZ2h0IHVzZSBh IHNwZWNpZmljIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBsaXN0LCB3aGlsZSB0aGUNCiAgIHZpcnR1 YWwgaG9zdCAiYmFyLmV4YW1wbGUuY29tIiBvbiB0aGUgc2FtZSBGVFAgc2VydmVyIG1pZ2h0IHVz ZSBhDQogICBkaWZmZXJlbnQgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGxpc3QuICBJbiBzdWNoIGEg c2NlbmFyaW8sIHJlc2V0dGluZw0KICAgdGhlIHNlY3VyaXR5IGVudmlyb25tZW50IGlzIG5lY2Vz c2FyeSBmb3IgdGhlIHZpcnR1YWwgc2VydmVycyB0bw0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5 ICAgICAgRXhwaXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMThdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAg ICAgICAgICBKdW5lIDIwMTENCg0KDQogICBhcHBlYXIgdG8gYmVoYXZlIGluZGVwZW5kZW50bHkg ZnJvbSBhIGNsaWVudCBwZXJzcGVjdGl2ZSwgd2hpbGUgdGhlDQogICBhY3R1YWwgc2VydmVyIGlt cGxlbWVudGF0aW9uIGRldGFpbHMgYXJlIGlycmVsZXZhbnQgYXQgdGhlIHByb3RvY29sDQogICBs ZXZlbC4NCg0KICAgU2VjdGlvbiAxNS4xLjEgb2YgW1JGQzQyMTddIGRpc2N1c3NlcyB0aGUgdXNl IG9mIFguNTA5IGNlcnRpZmljYXRlcw0KICAgZm9yIHNlcnZlciBhdXRoZW50aWNhdGlvbi4gIFRh a2luZyB0aGUgaW5mb3JtYXRpb24gZnJvbSB0aGF0IGRvY3VtZW50DQogICBpbnRvIGFjY291bnQs IHdoZW4gc2VjdXJpbmcgRlRQIHNlc3Npb25zIHdpdGggdGhlIHNlY3VyaXR5IG1lY2hhbmlzbXMN CiAgIHRoYXQgYXJlIGRlZmluZWQgaW4gW1JGQzQyMTddLCBjbGllbnQgaW1wbGVtZW50YXRpb25z IFNIT1VMRCB2ZXJpZnkNCiAgIHRoYXQgdGhlIGhvc3RuYW1lIHRoZXkgc3BlY2lmeSBpbiB0aGUg cGFyYW1ldGVyIGZvciB0aGUgSE9TVCBjb21tYW5kDQogICBtYXRjaGVzIHRoZSBpZGVudGl0eSB0 aGF0IGlzIHNwZWNpZmllZCBpbiB0aGUgc2VydmVyJ3MgWC41MDkNCiAgIGNlcnRpZmljYXRlIGlu IG9yZGVyIHRvIHByZXZlbnQgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcy4NCg0KICAgQSBnZW5l cmFsIGRpc2N1c3Npb24gb2YgaXNzdWVzIHJlbGF0ZWQgdG8gdGhlIHNlY3VyaXR5IG9mIEZUUCBj YW4gYmUNCiAgIGZvdW5kIGluIFtSRkMyNTc3XS4NCg0KDQo1LiAgSUFOQSBDb25zaWRlcmF0aW9u cw0KDQogICBJQU5BIGlzIHJlcXVlc3RlZCB0byByZWdpc3RlciB0aGUgZm9sbG93aW5nIEZUUCBl eHRlbnNpb24gYWNjb3JkaW5nDQogICB0byB0aGUgcHJvY2VkdXJlIGVzdGFibGlzaGVkIGJ5IFtS RkM1Nzk3XToNCg0KICAgKy0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IGNtZCAgfCBGRUFUICAgIHwgZGVzY3Jp cHRpb24gfCB0eXBlIHwgY29uZiB8IFJGQyNzL1JlZmVyZW5jZXMgYW5kIHwNCiAgIHwgICAgICB8 IENvZGUgICAgfCAgICAgICAgICAgICB8ICAgICAgfCAgICAgIHwgTm90ZXMgICAgICAgICAgICAg ICAgfA0KICAgKy0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IEhPU1QgfCBIT1NUICAgIHwgSG9zdG5hbWUgICAg fCBhICAgIHwgbyAgICB8IFRCRCAgICAgICAgICAgICAgICAgIHwNCiAgICstLS0tLS0rLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0K DQogICAgIE5PVEUgVE8gUkZDIEVESVRPUjogUGxlYXNlIHVwZGF0ZSBUQkQgaW4gdGhlIGFib3Zl IHRhYmxlIHdpdGggdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgbnVtYmVyIG9mIHRoaXMg ZG9jdW1lbnQuDQoNCg0KNi4gIFJlZmVyZW5jZXMNCg0KNi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMNCg0KICAgW1JGQzA5NTldICBQb3N0ZWwsIEouIGFuZCBKLiBSZXlub2xkcywgIkZpbGUgVHJh bnNmZXIgUHJvdG9jb2wNCiAgICAgICAgICAgICAgKEZUUCkiLCBTVEQgOSwgUkZDIDk1OSwgT2N0 b2JlciAxOTg1Lg0KDQogICBbUkZDMTAzNF0gIE1vY2thcGV0cmlzLCBQLiwgIkRvbWFpbiBOYW1l cyAtIENvbmNlcHRzIGFuZCBGYWNpbGl0aWVzIiwNCiAgICAgICAgICAgICAgU1REIDEzLCBSRkMg MTAzNCwgTm92ZW1iZXIgMTk4Ny4NCg0KICAgW1JGQzEwMzVdICBNb2NrYXBldHJpcywgUC4sICJE b21haW4gTmFtZXMgLSBJbXBsZW1lbnRhdGlvbiBhbmQNCiAgICAgICAgICAgICAgU3BlY2lmaWNh dGlvbiIsIFNURCAxMywgUkZDIDEwMzUsIE5vdmVtYmVyIDE5ODcuDQoNCiAgIFtSRkMxMTIzXSAg QnJhZGVuLCBSLiwgIlJlcXVpcmVtZW50cyBmb3IgSW50ZXJuZXQgSG9zdHMgLS0NCiAgICAgICAg ICAgICAgQXBwbGljYXRpb24gYW5kIFN1cHBvcnQiLCBTVEQgMywgUkZDIDExMjMsIE9jdG9iZXIg MTk4OS4NCg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNlbWJlciAz MSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQ IEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTENCg0KDQog ICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJ bmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAy MTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDMjIyOF0gIEhvcm93aXR6LCBNLiBhbmQgUy4gTHVu dCwgIkZUUCBTZWN1cml0eSBFeHRlbnNpb25zIiwNCiAgICAgICAgICAgICAgUkZDIDIyMjgsIE9j dG9iZXIgMTk5Ny4NCg0KICAgW1JGQzIzODldICBIZXRobW9uLCBQLiBhbmQgUi4gRWx6LCAiRmVh dHVyZSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gZm9yDQogICAgICAgICAgICAgIHRoZSBGaWxlIFRy YW5zZmVyIFByb3RvY29sIiwgUkZDIDIzODksIEF1Z3VzdCAxOTk4Lg0KDQogICBbUkZDMjY0MF0g IEN1cnRpbiwgVy4sICJJbnRlcm5hdGlvbmFsaXphdGlvbiBvZiB0aGUgRmlsZSBUcmFuc2Zlcg0K ICAgICAgICAgICAgICBQcm90b2NvbCIsIFJGQyAyNjQwLCBKdWx5IDE5OTkuDQoNCiAgIFtSRkMz NDkyXSAgQ29zdGVsbG8sIEEuLCAiUHVueWNvZGU6IEEgQm9vdHN0cmluZyBlbmNvZGluZyBvZiBV bmljb2RlDQogICAgICAgICAgICAgIGZvciBJbnRlcm5hdGlvbmFsaXplZCBEb21haW4gTmFtZXMg aW4gQXBwbGljYXRpb25zDQogICAgICAgICAgICAgIChJRE5BKSIsIFJGQyAzNDkyLCBNYXJjaCAy MDAzLg0KDQogICBbUkZDNDIxN10gIEZvcmQtSHV0Y2hpbnNvbiwgUC4sICJTZWN1cmluZyBGVFAg d2l0aCBUTFMiLCBSRkMgNDIxNywNCiAgICAgICAgICAgICAgT2N0b2JlciAyMDA1Lg0KDQogICBb UkZDNTIzNF0gIENyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3Ig U3ludGF4DQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb25zOiBBQk5GIiwgUkZDIDUyMzQsIEph bnVhcnkgMjAwOC4NCg0KNi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMTk0 NV0gIEJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgSC4gRnJ5c3R5aywgIkh5cGVy dGV4dA0KICAgICAgICAgICAgICBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMCIsIFJGQyAx OTQ1LCBNYXkgMTk5Ni4NCg0KICAgW1JGQzI1NzddICBBbGxtYW4sIE0uIGFuZCBTLiBPc3Rlcm1h bm4sICJGVFAgU2VjdXJpdHkNCiAgICAgICAgICAgICAgQ29uc2lkZXJhdGlvbnMiLCBSRkMgMjU3 NywgTWF5IDE5OTkuDQoNCiAgIFtSRkMyNjE2XSAgRmllbGRpbmcsIFIuLCBHZXR0eXMsIEouLCBN b2d1bCwgSi4sIEZyeXN0eWssIEguLA0KICAgICAgICAgICAgICBNYXNpbnRlciwgTC4sIExlYWNo LCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAiSHlwZXJ0ZXh0DQogICAgICAgICAgICAgIFRyYW5z ZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xIiwgUkZDIDI2MTYsIEp1bmUgMTk5OS4NCg0KICAgW1JG QzU3OTddICBLbGVuc2luLCBKLiBhbmQgQS4gSG9lbmVzLCAiRlRQIENvbW1hbmQgYW5kIEV4dGVu c2lvbg0KICAgICAgICAgICAgICBSZWdpc3RyeSIsIFJGQyA1Nzk3LCBNYXJjaCAyMDEwLg0KDQoN CkFwcGVuZGl4IEEuICBVbndvcmthYmxlIEFsdGVybmF0aXZlcw0KDQogICBEdWUgdG8gdGhlIGxl dmVsIG9mIHNjb3BlIGZvciBhZGRpbmcgYSBuZXcgY29tbWFuZCB0byBGVFAsIGEgYnJpZWYNCiAg IGRpc2N1c3Npb24gb2Ygc3VnZ2VzdGVkIGFsdGVybmF0aXZlcyB0byBhIEhPU1QgY29tbWFuZCBh bmQgdGhlaXINCiAgIHJlc3BlY3RpdmUgbGltaXRhdGlvbnMgaXMgd2FycmFudGVkLiAgVGhlIHN1 Z2dlc3RlZCBhbHRlcm5hdGl2ZXMgdGhhdA0KICAgYXJlIGRpc2N1c3NlZCBpbiB0aGlzIGFwcGVu ZGl4IGhhdmUgYmVlbiBwcm9wb3NlZCBpbiB0aGUgcGFzdCwgYnV0DQogICBlYWNoIG9mIHRoZXNl IGlkZWFzIHdhcyBkZWVtZWQgaW5zdWZmaWNpZW50IGZvciB0aGUgcmVhc29ucyB0aGF0IGFyZQ0K ICAgbGlzdGVkIHdpdGhpbiBlYWNoIHNlY3Rpb24gb2YgdGhlIGFwcGVuZGl4Lg0KDQoNCg0KDQoN CkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMzEsIDIwMTEgICAgICAg ICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQg Zm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KQS4xLiAgT3ZlcmxvYWRp bmcgdGhlIENXRCBjb21tYW5kDQoNCiAgIE9uZSBzdWdnZXN0ZWQgbWV0aG9kIHRvIGVtdWxhdGUg YSBmb3JtIG9mIHZpcnR1YWwgaG9zdHMgd291bGQgYmUgZm9yDQogICB0aGUgY2xpZW50IHRvIHNp bXBseSBzZW5kIGEgIkNXRCIgY29tbWFuZCBhZnRlciBjb25uZWN0aW5nLCB1c2luZyB0aGUNCiAg IHZpcnR1YWwgaG9zdCBuYW1lIGFzIHRoZSBhcmd1bWVudCB0byB0aGUgQ1dEIGNvbW1hbmQuICBU aGlzIHdvdWxkDQogICBhbGxvdyB0aGUgc2VydmVyLUZUUCBwcm9jZXNzIHRvIGltcGxlbWVudCB0 aGUgZmlsZSBzdG9yZXMgb2YgdGhlDQogICB2aXJ0dWFsIGhvc3RzIGFzIHN1Yi1kaXJlY3Rvcmll cyBpbiBpdHMgTlZGUy4gIFRoaXMgc3VnZ2VzdGlvbiBpcw0KICAgc2ltcGxlIGluIGNvbmNlcHQs IGFuZCBtb3N0IHNlcnZlci1GVFAgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgdGhpcw0KICAgd2l0 aG91dCByZXF1aXJpbmcgYW55IGNvZGUgY2hhbmdlcy4gIFdoaWxlIHRoaXMgbWV0aG9kIGlzIHNp bXBsZSB0bw0KICAgZGVzY3JpYmUsIGFuZCB0byBpbXBsZW1lbnQsIGl0IHN1ZmZlcnMgZnJvbSBz ZXZlcmFsIGRyYXdiYWNrczoNCg0KICAgYS4gIFRoZSAiQ1dEIiBjb21tYW5kIGlzIGF2YWlsYWJs ZSBvbmx5IGFmdGVyIHRoZSB1c2VyLVBJIGhhcw0KICAgICAgIGF1dGhlbnRpY2F0ZWQgaXRzZWxm IHRvIHRoZSBzZXJ2ZXItRlRQIHByb2Nlc3MuICBUaHVzLCBhbGwNCiAgICAgICB2aXJ0dWFsIGhv c3RzIHdvdWxkIGJlIHJlcXVpcmVkIHRvIHNoYXJlIGEgY29tbW9uIGF1dGhlbnRpY2F0aW9uDQog ICAgICAgc2NoZW1lIGlmIHRoZXkgdXNlZCB0aGlzIG1ldGhvZC4NCg0KICAgYi4gIFRvIG1ha2Ug dGhlIHZpcnR1YWwgaG9zdCB0cnVseSB0cmFuc3BhcmVudCwgZWl0aGVyIHRoZSBzZXJ2ZXItRlRQ DQogICAgICAgcHJvY2VzcyBuZWVkcyB0byBiZSBtb2RpZmllZCB0byBpbmNsdWRlIGluZm9ybWF0 aW9uIHRoYXQgc2hvd3MNCiAgICAgICB0aGUgc3BlY2lhbCBuYXR1cmUgb2YgdGhpcyBmaXJzdCBD V0QgY29tbWFuZCAobmVnYXRpbmcgbW9zdCBvZg0KICAgICAgIHRoZSBhZHZhbnRhZ2Ugb2YgdGhp cyBzY2hlbWUpLCBvciBhbGwgdXNlcnMgbXVzdCBzZWUgdGhlIHNhbWUNCiAgICAgICBpZGVudGlj YWwgTlZGUyB2aWV3IHVwb24gY29ubmVjdGluZyAodGhleSBtdXN0IGNvbm5lY3QgaW4gdGhlDQog ICAgICAgc2FtZSBpbml0aWFsIGRpcmVjdG9yeSksIG9yIHRoZSBOVkZTIG11c3QgaW1wbGVtZW50 IHRoZSBmdWxsIHNldA0KICAgICAgIG9mIHZpcnR1YWwgaG9zdCBkaXJlY3RvcmllcyBhdCBlYWNo IHBvc3NpYmxlIGluaXRpYWwgZGlyZWN0b3J5DQogICAgICAgZm9yIGFueSBwb3NzaWJsZSB1c2Vy Lg0KDQogICBjLiAgVW5sZXNzIHRoZSBzZXJ2ZXIgaXMgc3BlY2lhbGx5IG1vZGlmaWVkLCBhIHVz ZXIgY29ubmVjdGluZyB0aGlzDQogICAgICAgd2F5IHRvIGEgdmlydHVhbCBob3N0IHdvdWxkIGJl IGFibGUgdG8gZWFzaWx5IG1vdmUgdG8gYW55IG90aGVyDQogICAgICAgdmlydHVhbCBob3N0IHN1 cHBvcnRlZCBhdCB0aGUgc2FtZSBzZXJ2ZXItRlRQIHByb2Nlc3MsIGV4cG9zaW5nDQogICAgICAg dGhlIG5hdHVyZSBvZiB0aGUgdmlydHVhbCBob3N0Lg0KDQpBLjIuICBPdmVybG9hZGluZyB0aGUg QUNDVCBjb21tYW5kDQoNCiAgIEFub3RoZXIgc3VnZ2VzdGVkIG1ldGhvZCB3b3VsZCBiZSB0byBz aW1wbHkgb3ZlcmxvYWQgdGhlICJBQ0NUIiBmb3INCiAgIEZUUCB2aXJ0dWFsIGhvc3RzLCBidXQg dGhpcyBwcm9wb3NhbCBpcyB1bmFjY2VwdGFibGUgZm9yIHNldmVyYWwNCiAgIHJlYXNvbnMgd2l0 aCByZWdhcmQgdG8gd2hlbiB0aGUgQUNDVCBjb21tYW5kIGlzIHNlbnQgZHVyaW5nIHRoZQ0KICAg cmVxdWVzdCBmbG93LiAgU2VjdGlvbnMgNS40IGFuZCA2IG9mIFtSRkMwOTU5XSBkb2N1bWVudCB0 aGUgcmVxdWVzdA0KICAgZmxvdyBmb3IgYSBsb2dpbiBzZXF1ZW5jZSBhcyBVU0VSIC0+IFBBU1Mg LT4gQUNDVC4gIFRoaXMgZmxvdyBvZg0KICAgY29tbWFuZHMgbWF5IGJlIGFjY2VwdGFibGUgd2hl biB5b3UgYXJlIGNvbnNpZGVyaW5nIGEgc2luZ2xlIHVzZXINCiAgIGhhdmluZyBtdWx0aXBsZSBh Y2NvdW50cyBvbiBhbiBGVFAgc2VydmVyLCBidXQgZmFpbHMgdG8gZGlmZmVyZW50aWF0ZQ0KICAg YmV0d2VlbiB2aXJ0dWFsIGhvc3RzIHdoZW4geW91IGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgdHdv IGlzc3VlczoNCg0KICAgYS4gIFRoZSBmaXJzdCBwcm9ibGVtIHdpdGggb3ZlcmxvYWRpbmcgdGhl IEFDQ1QgY29tbWFuZCBpcw0KICAgICAgIGNlcnRpZmljYXRlIG5lZ290aWF0aW9uIHdoZW4gdXNp bmcgdGhlIEZUUCBzZWN1cml0eSBleHRlbnNpb25zDQogICAgICAgdGhhdCBhcmUgZG9jdW1lbnRl ZCBpbiBbUkZDMjIyOF0gYW5kIFtSRkM0MjE3XS4gIEluIG9yZGVyIHRvDQogICAgICAgc2FmZWd1 YXJkIHVzZXIgY3JlZGVudGlhbHMsIHNlY3VyaXR5IG1lY2hhbmlzbSBhbmQgY2VydGlmaWNhdGUN CiAgICAgICBuZWdvdGlhdGlvbiBtdXN0IG9jY3VyIGJlZm9yZSBsb2dpbiBjcmVkZW50aWFscyBh cmUgc2VudCBieSB0aGUNCiAgICAgICBjbGllbnQuICBUaGUgcHJvYmxlbSB3aXRoIHVzaW5nIHRo ZSBBQ0NUIGNvbW1hbmQgaW4gdGhpcyBzY2VuYXJpbw0KICAgICAgIGlzIHRoYXQgdGhlcmUgaXMg bm8gd2F5IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNlcnRpZmljYXRlIG1hdGNoZXMNCg0KDQoNCkhl dGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMzEsIDIwMTEgICAgICAgICAg ICAgIFtQYWdlIDIxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQgZm9y IFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KICAgICAgIHRoZSBjb3JyZWN0 IHZpcnR1YWwgaG9zdCBiZWZvcmUgdGhlIHVzZXIgY3JlZGVudGlhbHMgYXJlIHNlbnQuDQoNCiAg IGIuICBUaGUgc2Vjb25kIHByb2JsZW0gd2l0aCBvdmVybG9hZGluZyB0aGUgQUNDVCBjb21tYW5k IGlzIGhvdyB1c2VyDQogICAgICAgY3JlZGVudGlhbHMgYXJlIGltcGxlbWVudGVkIGZvciBGVFAg dmlydHVhbCBob3N0cy4gIEZUUCBzZXJ2ZXINCiAgICAgICBpbXBsZW1lbnRhdGlvbnMgbWF5IGFs bG93IHRoZSB1c2Ugb2YgY3VzdG9tIHVzZXIgY3JlZGVudGlhbHMgb24gYQ0KICAgICAgIHBlci12 aXJ0dWFsLWhvc3QgYmFzaXMuICBGb3IgZXhhbXBsZSwgaW4gb25lIHBhcnRpY3VsYXINCiAgICAg ICBpbXBsZW1lbnRhdGlvbiB0aGUgdmlydHVhbCBob3N0IG5lZ290aWF0aW9uIG9jY3VycywgYW5k IHRoZW4gdGhlDQogICAgICAgdXNlciBjcmVkZW50aWFscyBhcmUgbG9va2VkIHVwIHVzaW5nIHRo ZSBhY2NvdW50IG1lY2hhbmlzbSB0aGF0DQogICAgICAgaXMgc3BlY2lmaWMgdG8gdGhhdCB2aXJ0 dWFsIGhvc3QuICBTbyBvbmNlIGFnYWluIHRoZSB2aXJ0dWFsIGhvc3QNCiAgICAgICBuZWdvdGlh dGlvbiBtdXN0IHRha2UgcGxhY2UgYmVmb3JlIHRoZSB1c2VyIGNyZWRlbnRpYWxzIGFyZSBzZW50 Lg0KDQpBLjMuICBPdmVybG9hZGluZyB0aGUgVVNFUiBjb21tYW5kDQoNCiAgIEFuIGFkZGl0aW9u YWwgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBvdmVybG9hZCB3ZWxsLWtub3duIHN5bnRheA0KICAg dGhyb3VnaCB0aGUgZXhpc3RpbmcgVVNFUiBjb21tYW5kLCBhcyBpbGx1c3RyYXRlZCBpbiB0aGUg Zm9sbG93aW5nDQogICBleGFtcGxlOg0KDQogICAgICAgIEM+IFVTRVIgZm9vQGV4YW1wbGUuY29t DQogICAgICAgIFM+IDMzMSBQYXNzd29yZCByZXF1aXJlZA0KICAgICAgICBDPiBQQVNTIGJhcg0K ICAgICAgICBTPiAyMzAgVXNlciBsb2dnZWQgaW4NCg0KICAgSW4gdGhpcyBleGFtcGxlLCB0aGUg dXNlciAiZm9vIiBtaWdodCBiZSBhdHRlbXB0aW5nIHRvIGxvZyBvbiB0byB0aGUNCiAgIHZpcnR1 YWwgaG9zdCAiZXhhbXBsZS5jb20iIG9uIGFuIEZUUCBzZXJ2ZXIuICBUaGlzIHN1Z2dlc3Rpb24g bWF5DQogICBzZWVtIHBsYXVzaWJsZSBhdCBmaXJzdCwgYnV0IGludHJvZHVjZXMgc2V2ZXJhbCBp bXBsZW1lbnRhdGlvbg0KICAgcHJvYmxlbXMuICBGb3IgZXhhbXBsZToNCg0KICAgYS4gIFNvbWUg bmV0d29yayBlbnZpcm9ubWVudHMgYWxyZWFkeSB1c2UgdGhlICJ1c2VybmFtZUBob3N0bmFtZSIN CiAgICAgICBzeW50YXggZm9yIG5ldHdvcmsgY3JlZGVudGlhbHMsIHdoZXJlIHRoZSAiaG9zdG5h bWUiIHBvcnRpb24NCiAgICAgICByZWZlcnMgdG8gdGhlIGxvY2F0aW9uIG9mIHRoZSB1c2VyJ3Mg Y3JlZGVudGlhbHMgd2l0aGluIHRoZQ0KICAgICAgIG5ldHdvcmsgaGllcmFyY2h5LiAgVXNpbmcg dGhlICJmb29AZXhhbXBsZS5jb20iIHN5bnRheCBpdCBiZWNvbWVzDQogICAgICAgZGlmZmljdWx0 IHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aGUgdXNlciAiZm9vIiBsb2dnaW5nIGludG8gYQ0K ICAgICAgIHZpcnR1YWwgaG9zdCBuYW1lZCAiZXhhbXBsZS5jb20iIG9uIGFuIEZUUCBzZXJ2ZXIg dmVyc3VzIHRoZSB1c2VyDQogICAgICAgImZvb0BleGFtcGxlLmNvbSIgbG9nZ2luZyBpbnRvIGFu IEZUUCBzZXJ2ZXIgd2l0aCBubyBzcGVjaWZpZWQNCiAgICAgICB2aXJ0dWFsIGhvc3QuDQoNCiAg IGIuICBXaGVuIHVzaW5nIHRoZSBGVFAgc2VjdXJpdHkgZXh0ZW5zaW9ucyB0aGF0IGFyZSBkb2N1 bWVudGVkIGluDQogICAgICAgW1JGQzIyMjhdIGFuZCBbUkZDNDIxN10sIHNlY3VyaXR5IG1lY2hh bmlzbSBhbmQgY2VydGlmaWNhdGUNCiAgICAgICBuZWdvdGlhdGlvbiBtdXN0IG9jY3VyIGJlZm9y ZSBsb2dpbiBjcmVkZW50aWFscyBhcmUgc2VudCBieSB0aGUNCiAgICAgICBjbGllbnQuICBNb3Jl IHNwZWNpZmljYWxseSwgdGhlIEFVVEgvQURBVCBjb21tYW5kcyBtdXN0IGJlIHNlbnQNCiAgICAg ICBiZWZvcmUgdGhlIFVTRVIgY29tbWFuZCBpbiBvcmRlciB0byBzYWZlZ3VhcmQgdXNlciBjcmVk ZW50aWFscy4NCiAgICAgICBJZiB5b3Ugb3ZlcmxvYWQgdGhlIFVTRVIgY29tbWFuZCwgdGhlcmUg aXMgbm8gd2F5IG9mIGVuc3VyaW5nDQogICAgICAgdGhhdCB0aGUgY2VydGlmaWNhdGUgbWF0Y2hl cyB0aGUgY29ycmVjdCB2aXJ0dWFsIGhvc3QgYmVmb3JlIHRoZQ0KICAgICAgIHVzZXIgY3JlZGVu dGlhbHMgYXJlIHNlbnQgYnkgdGhlIGNsaWVudC4NCg0KDQoNCg0KDQoNCg0KSGV0aG1vbiAmIE1j TXVycmF5ICAgICAgRXhwaXJlcyBEZWNlbWJlciAzMSwgMjAxMSAgICAgICAgICAgICAgW1BhZ2Ug MjJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBI b3N0cyAgICAgICAgICBKdW5lIDIwMTENCg0KDQpBLjQuICBDb25jbHVzaW9uDQoNCiAgIFRoZSBj b25jbHVzaW9uIGZyb20gdGhlIGV4YW1pbmF0aW9uIG9mIHRoZSBleGlzdGluZyBwb3NzaWJpbGl0 aWVzDQogICBzZWVtcyB0byBiZSB0aGF0IGluIG9yZGVyIHRvIG9idGFpbiBhbiBhZGVxdWF0ZSBl bXVsYXRpb24gb2YgInJlYWwiDQogICBGVFAgc2VydmVycywgY2xpZW50IGFuZCBzZXJ2ZXIgbW9k aWZpY2F0aW9ucyB0byBzdXBwb3J0IHZpcnR1YWwgaG9zdHMNCiAgIGFyZSBuZWNlc3NhcnkuICBU aGVyZWZvcmUgYSBuZXcgRlRQIGNvbW1hbmQgc2VlbXMgdGhlIG1vc3QgbGlrZWx5DQogICBzb2x1 dGlvbiB0byBwcm92aWRlIHRoZSByZXF1aXJlZCBsZXZlbCBvZiBzdXBwb3J0Lg0KDQoNCkFwcGVu ZGl4IEIuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFJvYmVydCBFbHogYW5kIFBhdWwgSGV0aG1v biBwcm92aWRlZCBhIGRldGFpbGVkIGRpc2N1c3Npb24gb2YgdGhlDQogICBIT1NUIGNvbW1hbmQg aW4gdGhlaXIgSW50ZXJuZXQgZHJhZnQgdGl0bGVkICJFeHRlbnNpb25zIHRvIEZUUCIgYXMNCiAg IHBhcnQgb2YgdGhlaXIgd29yayB3aXRoIHRoZSBGVFBFWFQgV29ya2luZyBHcm91cCBhdCB0aGUg SUVURi4gIFRoZWlyDQogICB3b3JrIGZvcm1lZCB0aGUgYmFzaXMgZm9yIG11Y2ggb2YgdGhpcyBk b2N1bWVudCwgYW5kIHRoZWlyIGhlbHAgaGFzDQogICBiZWVuIGdyZWF0bHkgYXBwcmVjaWF0ZWQu ICBUaGV5IHdvdWxkIGFsc28gbGlrZSB0byBjcmVkaXQgQmVybmhhcmQNCiAgIFJvc2Vua3JhZW56 ZXIgZm9yIGhhdmluZyBmaXJzdCBzdWdnZXN0ZWQgYW5kIGRlc2NyaWJlZCB0aGUgSE9TVA0KICAg Y29tbWFuZC4NCg0KICAgQWxleGV5IE1lbG5pa292LCBBbGZyZWQgSG9lbmVzLCBKb2huIEtsZW5z aW4sIGFuZCBKb2UgVG91Y2ggaGF2ZSBtYWRlDQogICBzZXZlcmFsIHN1Z2dlc3Rpb25zIGFib3V0 IGVhcmxpZXIgdmVyc2lvbnMgb2YgdGhpcyBkb2N1bWVudDsgbWFueSBvZg0KICAgdGhlaXIgc3Vn Z2VzdGlvbnMgaGF2ZSBiZWVuIGluY29ycG9yYXRlZCwgYW5kIHRoZWlyIGNvbnRyaWJ1dGlvbnMg YXJlDQogICBncmF0ZWZ1bGx5IGFja25vd2xlZGdlZC4gIEluIGFkZGl0aW9uLCBBbGVjIFJvd2Vs bCdzIGFzc2lzdGFuY2UgaW4NCiAgIG1ha2luZyBzZWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50IG1v cmUgcmVhZGFibGUgd2FzIGludmFsdWFibGUuDQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAg IFBhdWwgSGV0aG1vbg0KICAgSGV0aG1vbiBCcm90aGVycw0KICAgMjMwNSBDaHVrYXIgUm9hZA0K ICAgS25veHZpbGxlLCBUTiAgMzc5MjMNCiAgIFVTQQ0KDQogICBFbWFpbDogcGhldGhtb25AaGV0 aG1vbi5jb20NCg0KDQogICBSb2JlcnQgTWNNdXJyYXkNCiAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlv bg0KICAgT25lIE1pY3Jvc29mdCBXYXkNCiAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KICAgVVNBDQoN CiAgIEVtYWlsOiByb2JtY21AbWljcm9zb2Z0LmNvbQ0KDQoNCg0KDQoNCg0KDQpIZXRobW9uICYg TWNNdXJyYXkgICAgICBFeHBpcmVzIERlY2VtYmVyIDMxLCAyMDExICAgICAgICAgICAgICBbUGFn ZSAyM10NCgwNCg== --_004_01AA9EC92749BF4894AC2B3039EA4A2C194A07E2CH1PRD0302MB131_ Content-Type: application/xml; name="draft-ietf-ftpext2-hosts-04.xml" Content-Description: draft-ietf-ftpext2-hosts-04.xml Content-Disposition: attachment; filename="draft-ietf-ftpext2-hosts-04.xml"; size=57525; creation-date="Fri, 24 Jun 2011 17:26:09 GMT"; modification-date="Wed, 29 Jun 2011 01:35:48 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXMtYXNjaWkiPz4NCjwhRE9DVFlQRSByZmMg U1lTVEVNICJyZmMyNjI5LmR0ZCJbCgoKPCFFTlRJVFkgUkZDMjExOSBTWVNURU0gImh0dHA6Ly94 bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjExOS54bWwi Pgo8IUVOVElUWSBSRkMyNjI5IFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGlj L3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yNjI5LnhtbCI+CjwhRU5USVRZIFJGQzM1NTIgU1lT VEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjM1NTIueG1sIj4KPCFFTlRJVFkgSS1ELm5hcnRlbi1pYW5hLWNvbnNpZGVyYXRpb25zLXJm YzI0MzRiaXMgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnht bDMvcmVmZXJlbmNlLkktRC5uYXJ0ZW4taWFuYS1jb25zaWRlcmF0aW9ucy1yZmMyNDM0YmlzLnht bCI+Cl0+DQo8P3htbC1zdHlsZXNoZWV0IHR5cGU9J3RleHQveHNsJyBocmVmPSdyZmMyNjI5Lnhz bHQnID8+DQo8P3JmYyBzdHJpY3Q9InllcyIgPz4NCjw/cmZjIHRvYz0ieWVzIj8+DQo8P3JmYyB0 b2NkZXB0aD0iNCI/Pg0KPD9yZmMgc3ltcmVmcz0ieWVzIj8+DQo8P3JmYyBzb3J0cmVmcz0ieWVz IiA/Pg0KPD9yZmMgY29tcGFjdD0ieWVzIiA/Pg0KPD9yZmMgc3ViY29tcGFjdD0ibm8iID8+DQo8 cmZjIGNhdGVnb3J5PSJzdGQiIGRvY05hbWU9ImRyYWZ0LWlldGYtZnRwZXh0Mi1ob3N0cy0wNCIg aXByPSJ0cnVzdDIwMDkwMiIgb2Jzb2xldGVzPSIiIHVwZGF0ZXM9Ijk1OSIgc3VibWlzc2lvblR5 cGU9IklFVEYiIHhtbDpsYW5nPSJlbiI+DQogIDxmcm9udD4NCiAgICA8dGl0bGUgYWJicmV2PSJG VFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzIj5GaWxlIFRyYW5zZmVyIFByb3RvY29s IEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0czwvdGl0bGU+DQogICAgPGF1dGhvciBmdWxs bmFtZT0iUGF1bCBIZXRobW9uIiBpbml0aWFscz0iUC4iIHN1cm5hbWU9IkhldGhtb24iPg0KICAg ICAgPG9yZ2FuaXphdGlvbj5IZXRobW9uIEJyb3RoZXJzPC9vcmdhbml6YXRpb24+DQogICAgICA8 YWRkcmVzcz4NCiAgICAgICAgPHBvc3RhbD4NCiAgICAgICAgICA8c3RyZWV0PjIzMDUgQ2h1a2Fy IFJvYWQ8L3N0cmVldD4NCiAgICAgICAgICA8Y2l0eT5Lbm94dmlsbGU8L2NpdHk+DQogICAgICAg ICAgPHJlZ2lvbj5UTjwvcmVnaW9uPg0KICAgICAgICAgIDxjb2RlPjM3OTIzPC9jb2RlPg0KICAg ICAgICAgIDxjb3VudHJ5PlVTQTwvY291bnRyeT4NCiAgICAgICAgPC9wb3N0YWw+DQogICAgICAg IDxlbWFpbD5waGV0aG1vbkBoZXRobW9uLmNvbTwvZW1haWw+DQogICAgICA8L2FkZHJlc3M+DQog ICAgPC9hdXRob3I+DQogICAgPGF1dGhvciBmdWxsbmFtZT0iUm9iZXJ0IE1jTXVycmF5IiBpbml0 aWFscz0iUi4iIHN1cm5hbWU9Ik1jTXVycmF5Ij4NCiAgICAgIDxvcmdhbml6YXRpb24+TWljcm9z b2Z0IENvcnBvcmF0aW9uPC9vcmdhbml6YXRpb24+DQogICAgICA8YWRkcmVzcz4NCiAgICAgICAg PHBvc3RhbD4NCiAgICAgICAgICA8c3RyZWV0Pk9uZSBNaWNyb3NvZnQgV2F5PC9zdHJlZXQ+DQog ICAgICAgICAgPGNpdHk+UmVkbW9uZDwvY2l0eT4NCiAgICAgICAgICA8cmVnaW9uPldBPC9yZWdp b24+DQogICAgICAgICAgPGNvZGU+OTgwNTI8L2NvZGU+DQogICAgICAgICAgPGNvdW50cnk+VVNB PC9jb3VudHJ5Pg0KICAgICAgICA8L3Bvc3RhbD4NCiAgICAgICAgPGVtYWlsPnJvYm1jbUBtaWNy b3NvZnQuY29tPC9lbWFpbD4NCiAgICAgIDwvYWRkcmVzcz4NCiAgICA8L2F1dGhvcj4NCiAgICA8 ZGF0ZSBtb250aD0iSnVuZSIgeWVhcj0iMjAxMSIgLz4NCiAgICA8d29ya2dyb3VwPkZUUEVYVDIg V29ya2luZyBHcm91cDwvd29ya2dyb3VwPg0KICAgIDxrZXl3b3JkPkZUUDwva2V5d29yZD4NCiAg ICA8a2V5d29yZD5IT1NUPC9rZXl3b3JkPg0KICAgIDxhYnN0cmFjdD4NCiAgICAgIDx0PlRoZSBG aWxlIFRyYW5zZmVyIFByb3RvY29sLCBhcyBkZWZpbmVkIGluIFJGQyA5NTkgW1JGQzA5NTldLCBk b2VzIG5vdCBwcm92aWRlIGEgd2F5IGZvciBGVFAgY2xpZW50cyBhbmQgc2VydmVycyB0byBkaWZm ZXJlbnRpYXRlIGJldHdlZW4gbXVsdGlwbGUgRE5TIG5hbWVzIHRoYXQgYXJlIHJlZ2lzdGVyZWQg Zm9yIGEgc2luZ2xlIElQIGFkZHJlc3MuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgRlRQ IGNvbW1hbmQgdGhhdCBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgRlRQIGNsaWVudHMgYW5kIHNl cnZlcnMgdG8gaWRlbnRpZnkgaW5kaXZpZHVhbCB2aXJ0dWFsIGhvc3RzIG9uIGFuIEZUUCBzZXJ2 ZXIuPC90Pg0KICAgIDwvYWJzdHJhY3Q+DQogIDwvZnJvbnQ+DQogIDxtaWRkbGU+DQogICAgPHNl Y3Rpb24gdGl0bGU9IkludHJvZHVjdGlvbiIgdG9jPSJkZWZhdWx0Ij4NCiAgICAgIDx0Pkl0IGlz IGNvbW1vbiBvbiB0aGUgSW50ZXJuZXQgZm9yIG1hbnkgRE5TIG5hbWVzIHRvIHJlc29sdmUgdG8g YSBzaW5nbGUgSVAgYWRkcmVzcy4gIFRoaXMgcHJhY3RpY2UgaGFzIGludHJvZHVjZWQgdGhlIGNv bmNlcHQgb2YgYSAidmlydHVhbCBob3N0Iiwgd2hlcmUgYSBob3N0IGFwcGVhcnMgdG8gZXhpc3Qg YXMgYW4gaW5kZXBlbmRlbnQgZW50aXR5LCBidXQgaW4gcmVhbGl0eSBzaGFyZXMgaXRzIHBoeXNp Y2FsIHJlc291cmNlcyB3aXRoIG9uZSBvciBtb3JlIHNpbWlsYXIgaG9zdHMuPC90Pg0KICAgICAg PHQ+U3VjaCBhbiBhcnJhbmdlbWVudCBwcmVzZW50cyBzb21lIHByb2JsZW1zIGZvciBGVFAgc2Vy dmVycywgYXMgYW4gRlRQIHNlcnZlciBkaXN0aW5ndWlzaGVzIGluY29taW5nIEZUUCBjb25uZWN0 aW9ucyBieSB0aGVpciBJUCBhZGRyZXNzZXMsIG5vdCB0aGVpciBETlMgbmFtZXMsIGJlY2F1c2Ug aG9zdHMgYXJlIHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgdGhlaXIgYWRkcmVzcyByYXRoZXIgdGhh biBuYW1lLiAgVGhhdCBpcywgYWxsIEROUyBuYW1lcyB0aGF0IHNoYXJlIGFuIElQIGFkZHJlc3Mg YXJlIGhhbmRsZWQgYnkgdGhlIHNhbWUgRlRQIHNlcnZlciBhbmQgc2hhcmUgdGhlIHNhbWUgTmV0 d29yayBWaXJ0dWFsIEZpbGUgU3lzdGVtIChOVkZTKS48L3Q+DQogICAgICA8dD5UaGlzIG1lYW5z IHRoYXQgZGlmZmVyZW50IHZpcnR1YWwgaG9zdHMgY2Fubm90IG9mZmVyIGRpZmZlcmVudCB2aXJ0 dWFsIGZpbGUgc3lzdGVtcyB0byBjbGllbnRzLCBub3IgY2FuIHRoZXkgb2ZmZXIgZGlmZmVyZW50 IGF1dGhlbnRpY2F0aW9uIHN5c3RlbXMuICBBbnkgc2NoZW1lIHRvIG92ZXJjb21lIHRoaXMgaXNz dWUgbmVlZHMgdG8gaW5kaWNhdGUgbm90IG9ubHkgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Ms IGJ1dCBhbHNvIHRoZSB2aXJ0dWFsIGhvc3QgbmFtZSB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgZGVzaXJlZCB2aXJ0dWFsIEZUUCBzZXJ2ZXIuICBUeXBpY2FsIHVzZXItRlRQIHByb2Nlc3Nl cyBjdXJyZW50bHkgdXNlIGhvc3RuYW1lcyB0byBwZXJmb3JtIGhvc3RuYW1lIHRvIElQIGFkZHJl c3MgcmVzb2x1dGlvbiBhbmQgdGhlbiBpZ25vcmUgaG9zdG5hbWVzIGZvciB0aGUgcmVzdCBvZiB0 aGUgRlRQIHNlc3Npb24sIHRoZXJlZm9yZSBhbnkgbWVjaGFuaXNtIHRvIG92ZXJjb21lIHRoaXMg aXNzdWUgd291bGQgcmVxdWlyZSBtb2RpZmljYXRpb25zIHRvIHRoZSB1c2VyLVBJIGFuZCBzZXJ2 ZXItUEkuPC90Pg0KICAgICAgPHQ+SXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhpcyBzYW1lIHBy b2JsZW0gZXhpc3RlZCBmb3IgSFRUUC8xLjAgYXMgZGVmaW5lZCBpbiA8eHJlZiB0YXJnZXQ9IlJG QzE5NDUiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCI+PC94cmVmPiwgYW5kIHdhcyBy ZXNvbHZlZCBpbiBIVFRQLzEuMSBhcyBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0iUkZDMjYxNiIg cGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0Ij48L3hyZWY+IHRocm91Z2ggdGhlIGFkZGl0 aW9uIG9mIHRoZSBIb3N0IHJlcXVlc3QgaGVhZGVyLiAgVGhlIGdvYWwgb2YgdGhpcyBkb2N1bWVu dCBpcyB0byBicmluZyBhIHNpbWlsYXIgbGV2ZWwgb2YgZmVhdHVyZSBwYXJpdHkgdG8gRlRQIGJ5 IGludHJvZHVjaW5nIGEgbmV3IEhPU1QgY29tbWFuZCB0aGF0IGFsbG93cyB1c2VyLUZUUCBwcm9j ZXNzZXMgdG8gc3BlY2lmeSB3aGljaCB2aXJ0dWFsIGhvc3QgdG8gY29ubmVjdCB0byBmb3IgYSBz ZXJ2ZXItRlRQIHByb2Nlc3MgdGhhdCBpcyBoYW5kbGluZyByZXF1ZXN0cyBmb3IgbXVsdGlwbGUg dmlydHVhbCBob3N0cyBvbiBhIHNpbmdsZSBJUCBhZGRyZXNzLjwvdD4NCiAgICA8L3NlY3Rpb24+ DQogICAgPHNlY3Rpb24gdGl0bGU9IkRvY3VtZW50IENvbnZlbnRpb25zIiB0b2M9ImRlZmF1bHQi Pg0KICAgICAgPHQ+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIs ICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5E RUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGlu dGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzIxMTkiIHBhZ2Vubz0i ZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCI+PC94cmVmPi48L3Q+DQogICAgICA8dD5JbiBleGFtcGxl cywgIkMmZ3Q7IiBhbmQgIlMmZ3Q7IiBpbmRpY2F0ZSBsaW5lcyBzZW50IGJ5IHRoZSBjbGllbnQg YW5kIHNlcnZlciwgcmVzcGVjdGl2ZWx5LjwvdD4NCiAgICAgIDx0PlRoaXMgZG9jdW1lbnQgYWxz byB1c2VzIG5vdGF0aW9uIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMwOTU5IiBwYWdlbm89 ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiPjwveHJlZj4gYW5kIDx4cmVmIHRhcmdldD0iUkZDMTEy MyIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0Ij48L3hyZWY+LiAgSW4gcGFydGljdWxh ciwgdGhlIHRlcm1zICJyZXBseSIsICJ1c2VyIiwgIk5WRlMiLCAiTlZUIiwgImZpbGUiLCAicGF0 aG5hbWUiLCAiRlRQIGNvbW1hbmRzIiwgIkRUUCIsICJ1c2VyLUZUUCBwcm9jZXNzIiwgInVzZXIt UEkiLCAidXNlci1EVFAiLCAic2VydmVyLUZUUCBwcm9jZXNzIiwgInNlcnZlci1QSSIsICJzZXJ2 ZXItRFRQIiwgIm1vZGUiLCAidHlwZSIsICJjb250cm9sIGNvbm5lY3Rpb24iLCAiZGF0YSBjb25u ZWN0aW9uIiwgYW5kICJBU0NJSSIsIGFyZSBhbGwgdXNlZCBoZXJlIGFzIGRlZmluZWQgdGhlcmUu PC90Pg0KICAgICAgPHQ+U3ludGF4IHJlcXVpcmVkIGlzIGRlZmluZWQgdXNpbmcgdGhlIEF1Z21l bnRlZCBCTkYgZGVmaW5lZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzUyMzQiIHBhZ2Vubz0iZmFsc2Ui IGZvcm1hdD0iZGVmYXVsdCI+PC94cmVmPi4gIFNvbWUgZ2VuZXJhbCBBQk5GIGRlZmluaXRpb25z IGFyZSByZXF1aXJlZCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudDsgdGhvc2Ugd2lsbCBiZSBkZWZp bmVkIGxhdGVyIGluIHRoaXMgc2VjdGlvbi4gIEF0IGZpcnN0IHJlYWRpbmcsIGl0IG1heSBiZSB3 aXNlIHRvIHNpbXBseSByZWNhbGwgdGhhdCB0aGVzZSBkZWZpbml0aW9ucyBleGlzdCBoZXJlLCBh bmQgc2tpcCB0byB0aGUgbmV4dCBzZWN0aW9uLjwvdD4NCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJC YXNpYyBUb2tlbnMiIHRvYz0iZGVmYXVsdCI+DQogICAgICAgIDx0PlRoaXMgZG9jdW1lbnQgaW1w b3J0cyB0aGUgY29yZSBkZWZpbml0aW9ucyBnaXZlbiBpbiBBcHBlbmRpeCBCIG9mIDx4cmVmIHRh cmdldD0iUkZDNTIzNCIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPi4gIFRoZXJl IGRlZmluaXRpb25zIHdpbGwgYmUgZm91bmQgZm9yIGJhc2ljIEFCTkYgZWxlbWVudHMgbGlrZSBB TFBIQSwgRElHSVQsIFNQLCBldGMuICBUbyB0aGF0LCB0aGUgZm9sbG93aW5nIHRlcm0gaXMgYWRk ZWQgZm9yIHVzZSBpbiB0aGlzIGRvY3VtZW50LjwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAg PGZpZ3VyZSB0aXRsZT0iIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9 IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgPGFydHdvcmsgdHlwZT0iQUJORiIg eG1sOnNwYWNlPSJwcmVzZXJ2ZSIgbmFtZT0iIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIi IGhlaWdodD0iIj48IVtDREFUQVsgICAgIFRDSEFSID0gVkNIQVIgLyBTUCAvIEhUQUIgICAgOyB2 aXNpYmxlIHBsdXMgd2hpdGUgc3BhY2VdXT48L2FydHdvcms+DQogICAgICAgICAgPC9maWd1cmU+ DQogICAgICAgIDwvdD4NCiAgICAgICAgPHQ+VGhlIFZDSEFSIChmcm9tIDx4cmVmIHRhcmdldD0i UkZDNTIzNCIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPikgYW5kIFRDSEFSIHJ1 bGVzIGdpdmUgYmFzaWMgY2hhcmFjdGVyIHR5cGVzIGZyb20gdmFyeWluZyBzdWItc2V0cyBvZiB0 aGUgQVNDSUkgY2hhcmFjdGVyIHNldCBmb3IgdXNlIGluIHZhcmlvdXMgY29tbWFuZHMgYW5kIHJl c3BvbnNlcy48L3Q+DQogICAgICAgIDx0Pk5vdGUgdGhhdCBpbiBBQk5GLCBzdHJpbmcgbGl0ZXJh bHMgYXJlIGNhc2UgaW5zZW5zaXRpdmUuICBUaGF0IGNvbnZlbnRpb24gaXMgcHJlc2VydmVkIGlu IHRoaXMgZG9jdW1lbnQsIGFuZCBpbXBsaWVzIHRoYXQgRlRQIGNvbW1hbmRzIGFuZCBwYXJhbWV0 ZXJzIHRoYXQgYXJlIGFkZGVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiBoYXZlIHZhbHVlcyB0aGF0 IGNhbiBiZSByZXByZXNlbnRlZCBpbiBhbnkgY2FzZS4gIFRoYXQgaXMsICJIT1NUIiBpcyB0aGUg c2FtZSBhcyAiaG9zdCIsICJIb3N0IiwgIkhvU3QiLCBldGMuLCBhbmQgImZ0cC5leGFtcGxlLmNv bSIgaXMgdGhlIHNhbWUgYXMgIkZ0cC5FeGFtcGxlLkNvbSIsICJmVHAuZVhhbXBsZS5jT20iLCBl dGMuPC90Pg0KICAgICAgPC9zZWN0aW9uPg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IlNlcnZlciBS ZXBsaWVzIiB0b2M9ImRlZmF1bHQiPg0KICAgICAgICA8dD5TZWN0aW9uIDQuMiBvZiA8eHJlZiB0 YXJnZXQ9IlJGQzA5NTkiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4gZGVmaW5l cyB0aGUgZm9ybWF0IGFuZCBtZWFuaW5nIG9mIHJlcGxpZXMgYnkgdGhlIHNlcnZlci1QSSB0byBG VFAgY29tbWFuZHMgZnJvbSB0aGUgdXNlci1QSS4gIFRob3NlIHJlcGx5IGNvbnZlbnRpb25zIGFy ZSB1c2VkIGhlcmUgd2l0aG91dCBjaGFuZ2UuPC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICA8 ZmlndXJlIHRpdGxlPSIiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249ImxlZnQiIGFsdD0i IiB3aWR0aD0iIiBoZWlnaHQ9IiI+DQogICAgICAgICAgICA8YXJ0d29yayB0eXBlPSJBQk5GIiB4 bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIg aGVpZ2h0PSIiPjwhW0NEQVRBWyAgICAgZXJyb3ItcmVzcG9uc2UgPSBlcnJvci1jb2RlIFNQICpU Q0hBUiBDUkxGDQogICAgIGVycm9yLWNvZGUgICAgID0gKCI0IiAvICI1IikgMkRJR0lUXV0+PC9h cnR3b3JrPg0KICAgICAgICAgIDwvZmlndXJlPg0KICAgICAgICA8L3Q+DQogICAgICAgIDx0Pklt cGxlbWVudGVycyBzaG91bGQgbm90ZSB0aGF0IHRoZSBBQk5GIHN5bnRheCAod2hpY2ggd2FzIG5v dCB1c2VkIGluIDx4cmVmIHRhcmdldD0iUkZDMDk1OSIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJk ZWZhdWx0IiAvPikgdXNlZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgb3RoZXIgRlRQIHJlbGF0ZWQg ZG9jdW1lbnRzLCBzb21ldGltZXMgc2hvd3MgcmVwbGllcyB1c2luZyB0aGUgb25lIGxpbmUgZm9y bWF0LiAgVW5sZXNzIG90aGVyd2lzZSBleHBsaWNpdGx5IHN0YXRlZCwgdGhhdCBpcyBub3QgaW50 ZW5kZWQgdG8gaW1wbHkgdGhhdCBtdWx0aS1saW5lIHJlc3BvbnNlcyBhcmUgbm90IHBlcm1pdHRl ZC4gIEltcGxlbWVudGVycyBzaG91bGQgYXNzdW1lIHRoYXQsIHVubGVzcyBzdGF0ZWQgdG8gdGhl IGNvbnRyYXJ5LCBhbnkgcmVwbHkgdG8gYW55IEZUUCBjb21tYW5kIChpbmNsdWRpbmcgUVVJVCkg Y2FuIGJlIG9mIHRoZSBtdWx0aS1saW5lIGZvcm1hdCBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0 PSJSRkMwOTU5IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+LjwvdD4NCiAgICAg ICAgPHQ+VGhyb3VnaG91dCB0aGlzIGRvY3VtZW50LCByZXBsaWVzIHdpbGwgYmUgaWRlbnRpZmll ZCBieSB0aGUgdGhyZWUgZGlnaXQgY29kZSB0aGF0IGlzIHRoZWlyIGZpcnN0IGVsZW1lbnQuICBU aHVzIHRoZSB0ZXJtICI1MDAgcmVwbHkiIG1lYW5zIGEgcmVwbHkgZnJvbSB0aGUgc2VydmVyLVBJ IHVzaW5nIHRoZSB0aHJlZSBkaWdpdCBjb2RlICI1MDAiLjwvdD4NCiAgICAgIDwvc2VjdGlvbj4N CiAgICA8L3NlY3Rpb24+DQogICAgPHNlY3Rpb24gdGl0bGU9IlRoZSBIT1NUIGNvbW1hbmQiIHRv Yz0iZGVmYXVsdCI+DQogICAgICA8dD5BIG5ldyBjb21tYW5kICJIT1NUIiBpcyBhZGRlZCB0byB0 aGUgRlRQIGNvbW1hbmQgc2V0IHRvIGFsbG93IHRoZSBzZXJ2ZXItRlRQIHByb2Nlc3MgdG8gZGV0 ZXJtaW5lIHRvIHdoaWNoIG9mIHBvc3NpYmx5IG1hbnkgdmlydHVhbCBob3N0cyB0aGUgY2xpZW50 IHdpc2hlcyB0byBjb25uZWN0LiAgVGhpcyBjb21tYW5kIFNIT1VMRCBiZSBpc3N1ZWQgYmVmb3Jl IHRoZSB1c2VyIGlzIGF1dGhlbnRpY2F0ZWQsIGFsbG93aW5nIHRoZSBhdXRoZW50aWNhdGlvbiBz Y2hlbWUsIGFuZCBzZXQgb2YgbGVnYWwgdXNlcnMsIHRvIGJlIGRlcGVuZGVudCB1cG9uIHRoZSB2 aXJ0dWFsIGhvc3QgY2hvc2VuLjwvdD4NCiAgICAgIDx0PlNlcnZlci1GVFAgcHJvY2Vzc2VzIE1V U1QgdHJlYXQgYSBzaXR1YXRpb24gd2hlcmUgdGhlIEhPU1QgY29tbWFuZCBpcyBpc3N1ZWQgbW9y ZSB0aGFuIG9uY2UgYmVmb3JlIHRoZSB1c2VyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgYXMgdGhv dWdoIGEgUkVJTiBjb21tYW5kIHdhcyBzZW50IGJlZm9yZSBlYWNoIEhPU1QgY29tbWFuZCwgYW5k IHRoZW4gcmVzZXQgdGhlIHVzZXItUEkgdG8gdGhlIHN0YXRlIHRoYXQgZXhpc3RlZCBhZnRlciB0 aGUgVENQIGNvbm5lY3Rpb24gd2FzIGZpcnN0IGVzdGFibGlzaGVkIGFuZCByZXR1cm4gdGhlIGFw cHJvcHJpYXRlIHJlcGx5IGZvciB0aGUgSE9TVCBjb21tYW5kLjwvdD4NCiAgICAgIDx0PlNlcnZl ci1GVFAgcHJvY2Vzc2VzIE1VU1QgdHJlYXQgYSBzaXR1YXRpb24gd2hlcmUgdGhlIEhPU1QgY29t bWFuZCBpcyBpc3N1ZWQgYWZ0ZXIgdGhlIHVzZXIgaGFzIGJlZW4gYXV0aGVudGljYXRlZCBieSB1 c2luZyBvbmUgb2YgdGhlIGZvbGxvd2luZyB0d28gYmVoYXZpb3JzOjwvdD4NCiAgICAgIDx0Pg0K ICAgICAgICA8bGlzdCBzdHlsZT0ibGV0dGVycyI+DQogICAgICAgICAgPHQ+VHJlYXQgdGhlIGxh dGUgSE9TVCBjb21tYW5kIGFzIGFuIGVycm9uZW91cyBzZXF1ZW5jZSBvZiBjb21tYW5kcyBhbmQg cmV0dXJuIGEgNTAzIHJlcGx5LjwvdD4NCiAgICAgICAgICA8dD5UcmVhdCB0aGUgbGF0ZSBIT1NU IGNvbW1hbmQgYXMgdGhvdWdoIGEgUkVJTiBjb21tYW5kIHdhcyBzZW50IGJlZm9yZSB0aGUgSE9T VCBjb21tYW5kIGFuZCByZXNldCB0aGUgdXNlci1QSSB0byB0aGUgc3RhdGUgdGhhdCBleGlzdGVk IGFmdGVyIHRoZSBUQ1AgY29ubmVjdGlvbiB3YXMgZmlyc3QgZXN0YWJsaXNoZWQgYW5kIGJlZm9y ZSB0aGUgaW5pdGlhbCB1c2VyIGF1dGhlbnRpY2F0aW9uIGFuZCB0aGVuIHJldHVybiB0aGUgYXBw cm9wcmlhdGUgcmVwbHkgZm9yIHRoZSBIT1NUIGNvbW1hbmQuPC90Pg0KICAgICAgICA8L2xpc3Q+ DQogICAgICA8L3Q+DQogICAgICA8dD5TZXJ2ZXJzIHNob3VsZCBub3RlIHRoYXQgdGhlIHJlc3Bv bnNlIHRvIHRoZSBIT1NUIGNvbW1hbmQgaXMgYSBzZW5zaWJsZSB0aW1lIHRvIHNlbmQgdGhlaXIg IndlbGNvbWUiIG1lc3NhZ2UuICBUaGlzIGFsbG93cyB0aGUgbWVzc2FnZSB0byBiZSBwZXJzb25h bGl6ZWQgZm9yIGFueSB2aXJ0dWFsIGhvc3RzIHRoYXQgYXJlIHN1cHBvcnRlZCwgYW5kIGFsc28g YWxsb3dzIHRoZSBjbGllbnQgdG8gZGV0ZXJtaW5lIHRoZSBzdXBwb3J0ZWQgbGFuZ3VhZ2VzLCBv ciByZXByZXNlbnRhdGlvbnMsIGZvciB0aGUgbWVzc2FnZSwgYW5kIG90aGVyIG1lc3NhZ2VzLCB2 aWEgdGhlIEZFQVQgcmVzcG9uc2UsIGFuZCBzZWxlY3QgYW4gYXBwcm9wcmlhdGUgb25lIHZpYSB0 aGUgTEFORyBjb21tYW5kLiAgU2VlIDx4cmVmIHRhcmdldD0iUkZDMjY0MCIgcGFnZW5vPSJmYWxz ZSIgZm9ybWF0PSJkZWZhdWx0Ij48L3hyZWY+IGZvciBtb3JlIGluZm9ybWF0aW9uLjwvdD4NCiAg ICAgIDxzZWN0aW9uIHRpdGxlPSJTeW50YXggb2YgdGhlIEhPU1QgY29tbWFuZCIgdG9jPSJkZWZh dWx0Ij4NCiAgICAgICAgPHQ+VGhlIEhPU1QgY29tbWFuZCBpcyBkZWZpbmVkIGFzIGZvbGxvd3Mu PC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICA8ZmlndXJlIHRpdGxlPSIiIHN1cHByZXNzLXRp dGxlPSJmYWxzZSIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+DQogICAg ICAgICAgICA8YXJ0d29yayB0eXBlPSJBQk5GIiB4bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIi IGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPjwhW0NEQVRBWyAgaG9zdC1j b21tYW5kICA9ICJIT1NUIiBTUCBob3N0bmFtZSBDUkxGDQogIGhvc3RuYW1lICAgICAgPSBkb21h aW4gLyBJUC1saXRlcmFsDQoNCiAgZG9tYWluICAgICAgICA9IHN1Yi1kb21haW4gKigiLiIgc3Vi LWRvbWFpbikNCiAgc3ViLWRvbWFpbiAgICA9IGxldC1kaWcgW2xkaC1zdHJdDQogIGxldC1kaWcg ICAgICAgPSBBTFBIQSAvIERJR0lUDQogIGxkaC1zdHIgICAgICAgPSAqKCBBTFBIQSAvIERJR0lU IC8gIi0iICkgbGV0LWRpZw0KDQogIElQLWxpdGVyYWwgICAgPSAoICJbIiBJUHY2YWRkcmVzcyAi XSIgKSAvIElQdjRhZGRyZXNzDQoNCiAgSVB2NmFkZHJlc3MgICA9ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgNiggaDE2ICI6IiApIGxzMzINCiAgICAgICAgICAgICAgICAgIC8gICAgICAg ICAgICAgICAgICAgICAgICI6OiIgNSggaDE2ICI6IiApIGxzMzINCiAgICAgICAgICAgICAgICAg IC8gWyAgICAgICAgICAgICAgIGgxNiBdICI6OiIgNCggaDE2ICI6IiApIGxzMzINCiAgICAgICAg ICAgICAgICAgIC8gWyAqMSggaDE2ICI6IiApIGgxNiBdICI6OiIgMyggaDE2ICI6IiApIGxzMzIN CiAgICAgICAgICAgICAgICAgIC8gWyAqMiggaDE2ICI6IiApIGgxNiBdICI6OiIgMiggaDE2ICI6 IiApIGxzMzINCiAgICAgICAgICAgICAgICAgIC8gWyAqMyggaDE2ICI6IiApIGgxNiBdICI6OiIg ICAgaDE2ICI6IiAgIGxzMzINCiAgICAgICAgICAgICAgICAgIC8gWyAqNCggaDE2ICI6IiApIGgx NiBdICI6OiIgICAgICAgICAgICAgIGxzMzINCiAgICAgICAgICAgICAgICAgIC8gWyAqNSggaDE2 ICI6IiApIGgxNiBdICI6OiIgICAgICAgICAgICAgIGgxNg0KICAgICAgICAgICAgICAgICAgLyBb ICo2KCBoMTYgIjoiICkgaDE2IF0gIjo6Ig0KDQogIGxzMzIgICAgICAgICAgPSAoIGgxNiAiOiIg aDE2ICkgLyBJUHY0YWRkcmVzcw0KICAgICAgICAgICAgICAgICAgOyBsZWFzdC1zaWduaWZpY2Fu dCAzMiBiaXRzIG9mIGFkZHJlc3MNCg0KICBoMTYgICAgICAgICAgID0gMSo0SEVYRElHDQogICAg ICAgICAgICAgICAgICA7IDE2IGJpdHMgb2YgYWRkcmVzcyByZXByZXNlbnRlZCBpbiBoZXhhZGVj aW1hbA0KDQogIElQdjRhZGRyZXNzICAgPSBkZWMtb2N0ZXQgIi4iIGRlYy1vY3RldCAiLiIgZGVj LW9jdGV0ICIuIiBkZWMtb2N0ZXQNCg0KICBkZWMtb2N0ZXQgICAgID0gRElHSVQgICAgICAgICAg ICAgICAgIDsgMC05DQogICAgICAgICAgICAgICAgICAvICV4MzEtMzkgRElHSVQgICAgICAgOyAx MC05OQ0KICAgICAgICAgICAgICAgICAgLyAiMSIgMkRJR0lUICAgICAgICAgIDsgMTAwLTE5OQ0K ICAgICAgICAgICAgICAgICAgLyAiMiIgJXgzMC0zNCBESUdJVCAgIDsgMjAwLTI0OQ0KICAgICAg ICAgICAgICAgICAgLyAiMjUiICV4MzAtMzUgICAgICAgIDsgMjUwLTI1NQ0KDQogIGhvc3QtcmVz cG9uc2UgPSBob3N0LW9rIC8gZXJyb3ItcmVzcG9uc2UNCiAgaG9zdC1vayAgICAgICA9ICIyMjAi IFsgU1AgKlRDSEFSIF0gQ1JMRl1dPjwvYXJ0d29yaz4NCiAgICAgICAgICA8L2ZpZ3VyZT4NCiAg ICAgICAgPC90Pg0KICAgICAgICA8dD5BcyB3aXRoIGFsbCBGVFAgY29tbWFuZHMsIHRoZSAiSE9T VCIgY29tbWFuZCB3b3JkIGlzIGNhc2UgaW5kZXBlbmRlbnQsIGFuZCBNQVkgYmUgc3BlY2lmaWVk IGluIGFueSBjaGFyYWN0ZXIgY2FzZSBkZXNpcmVkLjwvdD4NCiAgICAgICAgPHQ+VGhlICJob3N0 bmFtZSIgKGdpdmVuIGFzIGEgcGFyYW1ldGVyKSBzcGVjaWZpZXMgdGhlIHZpcnR1YWwgaG9zdCB0 byB3aGljaCBhY2Nlc3MgaXMgZGVzaXJlZC4gIFRoaXMgU0hPVUxEIGJlIHRoZSBzYW1lIGhvc3Qg bmFtZSB0aGF0IHdhcyB1c2VkIHRvIG9idGFpbiB0aGUgSVAgYWRkcmVzcyB0byB3aGljaCB0aGUg RlRQIGNvbnRyb2wgY29ubmVjdGlvbiB3YXMgbWFkZSwgYWZ0ZXIgYW55IGNsaWVudCBjb252ZXJz aW9ucyBoYXZlIGJlZW4gY29tcGxldGVkIHRoYXQgY29udmVydCBhbiBhYmJyZXZpYXRlZCBvciBs b2NhbCBhbGlhcyB0byBhIGNvbXBsZXRlIChmdWxseSBxdWFsaWZpZWQpIGRvbWFpbiBuYW1lLCBi dXQgYmVmb3JlIHJlc29sdmluZyBhIEROUyBhbGlhcyAob3duZXIgb2YgYSBDTkFNRSByZXNvdXJj ZSByZWNvcmQpIHRvIGl0cyBjYW5vbmljYWwgbmFtZS48L3Q+DQogICAgICAgIDx0PkludGVybmF0 aW9uYWxpemF0aW9uIG9mIGRvbWFpbiBuYW1lcyBpcyBvbmx5IHN1cHBvcnRlZCB0aHJvdWdoIHRo ZSB1c2Ugb2YgUHVueWNvZGUgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0iUkZDMzQ5MiIg cGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPi48L3Q+DQogICAgICAgIDx0PklmIHRo ZSB1c2VyIHdhcyBnaXZlbiBhbiBJUHY0IG9yIElQdjYgbGl0ZXJhbCBhZGRyZXNzLCBhbmQgY29u c2VxdWVudGx5IHdhcyBub3QgcmVxdWlyZWQgdG8gZGVyaXZlIHRoZSBsaXRlcmFsIGFkZHJlc3Mg ZnJvbSBhIGhvc3RuYW1lLCB0aGUgY2xpZW50IE1BWSBzZW5kIHRoZSBIT1NUIGNvbW1hbmQgd2l0 aCB0aGUgSVB2NCBvciBJUHY2IGxpdGVyYWwgYWRkcmVzcyBhcyBzcGVjaWZpZWQgdG8gaXQuICBX aGlsZSBpdCBtYXkgc2VlbSBjb3VudGVyLWludHVpdGl2ZSB0byBzcGVjaWZ5IGEgbGl0ZXJhbCBh ZGRyZXNzIGJ5IHVzaW5nIHRoZSBIT1NUIGNvbW1hbmQgYWZ0ZXIgdGhlIGNsaWVudCBoYXMgYWxy ZWFkeSBjb25uZWN0ZWQgdG8gdGhlIHNlcnZlciB1c2luZyBhIGxpdGVyYWwgYWRkcmVzcywgdGhp cyBzaG91bGQgYmUgZXhwZWN0ZWQgYmVoYXZpb3IgYmVjYXVzZSBhIHVzZXItRlRQIHByb2Nlc3Mg c2hvdWxkIG5vdCBiZSByZXF1aXJlZCB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYSBmdWxseSBx dWFsaWZpZWQgZG9tYWluIG5hbWUgYW5kIGFuIElQdjQgb3IgSVB2NiBuZXR3b3JrIGxpdGVyYWwg YWRkcmVzcy4gIFRoYXQgYmVpbmcgc2FpZCwgaWYgdGhlIElQdjQgb3IgSVB2NiBsaXRlcmFsIGFk ZHJlc3Mgc3BlY2lmaWVkIGJ5IHRoZSBjbGllbnQgZG9lcyBub3QgbWF0Y2ggdGhlIGxpdGVyYWwg YWRkcmVzcyBmb3IgdGhlIHNlcnZlciwgdGhlIHNlcnZlciBNVVNUIHJlc3BvbmQgd2l0aCBhIDUw NCByZXBseSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBJUHY0IG9yIElQdjYgbGl0ZXJhbCBhZGRyZXNz IGlzIG5vdCB2YWxpZC48L3Q+DQogICAgICAgIDx0PldoZW4gdGhlIGhvc3RuYW1lIHBhcmFtZXRl ciBjb250YWlucyBhIGxpdGVyYWwgYWRkcmVzcywgc3F1YXJlIGJyYWNrZXRzIGFyZSBleHBlY3Rl ZCB0byBkaXNhbWJpZ3VhdGUgSVB2NiBhZGRyZXNzIHN5bnRheCBmcm9tIHBvcnQgbnVtYmVycyBz eW50YXguICBUaGVyZWZvcmUsIGlmIHRoZSBsaXRlcmFsIGFkZHJlc3MgaXMgYW4gSVB2NiBhZGRy ZXNzLCB0aGUgSVB2NiBhZGRyZXNzIGlzIHJlcXVpcmVkIHRvIGJlIGVuY2xvc2VkIGluIHNxdWFy ZSBicmFja2V0cyAoYWZ0ZXIgZWxpbWluYXRpbmcgYW55IHN5bnRheCB0aGF0IG1pZ2h0IGFsc28g LSBidXQgaXMgbm90IHJlcXVpcmVkIHRvIC0gYmUgZW5jbG9zZWQgaW4gYnJhY2tldHMsIGFuZCBm cm9tIHdoaWNoIHRoZSBzZXJ2ZXIgZGVkdWNlZCB0aGF0IGEgbGl0ZXJhbCBhZGRyZXNzIGhhZCBi ZWVuIHNwZWNpZmllZC4pIEZvciBleGFtcGxlLCB0aGUgZm9sbG93aW5nIGV4YW1wbGVzIE1BWSBi ZSBzZW50IGlmIHRoZSBjbGllbnQgaGFkIGJlZW4gaW5zdHJ1Y3RlZCB0byByZXNwZWN0aXZlbHkg Y29ubmVjdCB0byAiMTkyLjAuMi4xIiwgIkZFODA6OmMwMDA6MDIwMSIsIG9yICIxOTIuMC4yLjEi IGFuZCBJUHY2IHN5bnRheCBpcyBwcmVmZXJyZWQ6PC90Pg0KICAgICAgICA8dD4NCiAgICAgICAg ICA8ZmlndXJlIHRpdGxlPSIiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249ImxlZnQiIGFs dD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+DQogICAgICAgICAgICA8YXJ0d29yayB4bWw6c3BhY2U9 InByZXNlcnZlIiBuYW1lPSIiIHR5cGU9IiIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBo ZWlnaHQ9IiI+PCFbQ0RBVEFbICAgICBIT1NUIDE5Mi4wLjIuMQ0KICAgICBIT1NUIFtGRTgwOjpj MDAwOjAyMDFdDQogICAgIEhPU1QgWzo6MTkyLjAuMi4xXV1dPjwvYXJ0d29yaz4NCiAgICAgICAg ICA8L2ZpZ3VyZT4NCiAgICAgICAgPC90Pg0KICAgICAgICA8dD5UaGUgY2xpZW50IE1VU1QgTk9U IHNlbmQgdGhlIHBvcnQgbnVtYmVyIGFzIHBhcnQgb2YgdGhlIEhPU1QgY29tbWFuZCwgZXZlbiB3 aGVuIHRoZSBjbGllbnQgaGFzIGJlZW4gaW5zdHJ1Y3RlZCB0byBjb25uZWN0IHRvIGEgbm9uLXN0 YW5kYXJkIHBvcnQuICBUaGUgcmVhc29uIGZvciB0aGlzIHJlcXVpcmVtZW50IGlzIHRoYXQgdGhl IHVzZXItUEkgd2lsbCBoYXZlIGVzdGFibGlzaGVkIGEgY29ubmVjdGlvbiB0byB0aGUgc2VydmVy LVBJIGJlZm9yZSB0aGUgSE9TVCBjb21tYW5kIGlzIHNlbnQsIHRoZXJlZm9yZSBzcGVjaWZ5aW5n IGEgZGlmZmVyZW50IHBvcnQgd2l0aCB0aGUgSE9TVCBjb21tYW5kIGhhcyBubyBtZWFuaW5nLiAg Rm9yIGV4YW1wbGUsIHRoZSBzZXJ2ZXItUEkgTVVTVCByZXNwb25kIHdpdGggYSA1MDEgcmVwbHkg aWYgdGhlIGNsaWVudCBzZW5kcyBhIEhPU1QgY29tbWFuZCB3aXRoIHN5bnRheCBsaWtlIGVpdGhl ciBvZiB0aGUgZm9sbG93aW5nIGV4YW1wbGVzOjwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAg PGZpZ3VyZSB0aXRsZT0iIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9 IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgPGFydHdvcmsgeG1sOnNwYWNlPSJw cmVzZXJ2ZSIgbmFtZT0iIiB0eXBlPSIiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVp Z2h0PSIiPjwhW0NEQVRBWyAgICAgSE9TVCAxOTIuMC4yLjE6MjExMg0KICAgICBIT1NUIFtGRTgw OjpjMDAwOjAyMDFdOjIxMTJdXT48L2FydHdvcms+DQogICAgICAgICAgPC9maWd1cmU+DQogICAg ICAgIDwvdD4NCiAgICAgICAgPHQ+VGhlIGhvc3RuYW1lIHBhcmFtZXRlciBpcyBvdGhlcndpc2Ug dG8gYmUgdHJlYXRlZCBhcyBhIGZ1bGx5IHF1YWxpZmllZCBkb21haW4gbmFtZSBvciByZWxhdGl2 ZSBuYW1lIGFzIHRob3NlIHRlcm1zIGFyZSBkZWZpbmVkIGluIHNlY3Rpb24gMy4xIG9mIDx4cmVm IHRhcmdldD0iUkZDMTAzNCIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPi4gIFRo aXMgaW1wbGllcyB0aGF0IHRoZSBuYW1lIGlzIHRvIGJlIHRyZWF0ZWQgYXMgYSBjYXNlLWluZGVw ZW5kZW50IHN0cmluZywgbWVhbmluZyB0aGF0IHVwcGVyY2FzZSBBU0NJSSBjaGFyYWN0ZXJzIGFy ZSB0byBiZSB0cmVhdGVkIGFzIGVxdWl2YWxlbnQgdG8gdGhlaXIgY29ycmVzcG9uZGluZyBsb3dl cmNhc2UgQVNDSUkgY2hhcmFjdGVycywgYnV0IG90aGVyd2lzZSBwcmVzZXJ2ZWQgYXMgZ2l2ZW4u ICBJdCBhbHNvIGltcGxpZXMgc29tZSBsaW1pdHMgb24gdGhlIGxlbmd0aCBvZiB0aGUgcGFyYW1l dGVyIGFuZCBvZiB0aGUgY29tcG9uZW50cyB0aGF0IGNyZWF0ZSBpdHMgaW50ZXJuYWwgc3RydWN0 dXJlLiAgVGhvc2UgbGltaXRzIGFyZSBub3QgYWx0ZXJlZCBpbiBhbnkgd2F5IGhlcmUuPC90Pg0K ICAgICAgICA8dD5OZWl0aGVyIDx4cmVmIHRhcmdldD0iUkZDMTAzNCIgcGFnZW5vPSJmYWxzZSIg Zm9ybWF0PSJkZWZhdWx0IiAvPiBub3IgPHhyZWYgdGFyZ2V0PSJSRkMxMDM1IiBwYWdlbm89ImZh bHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+IGltcG9zZSBhbnkgb3RoZXIgcmVzdHJpY3Rpb25zIHVw b24gd2hhdCBraW5kcyBvZiBuYW1lcyBjYW4gYmUgc3RvcmVkIGluIHRoZSBETlMuICBUaGlzIHNw ZWNpZmljYXRpb24sIGhvd2V2ZXIsIG9ubHkgYWxsb3dzIHRoZSB1c2Ugb2YgbmFtZXMgdGhhdCBj YW4gYmUgaW5mZXJyZWQgZnJvbSB0aGUgQUJORiBncmFtbWFyIGdpdmVuIGZvciB0aGUgImhvc3Ru YW1lIi48L3Q+DQogICAgICA8L3NlY3Rpb24+DQogICAgICA8c2VjdGlvbiB0aXRsZT0iSE9TVCBj b21tYW5kIHNlbWFudGljcyIgdG9jPSJkZWZhdWx0Ij4NCiAgICAgICAgPHQ+VXBvbiByZWNlaXZp bmcgdGhlIEhPU1QgY29tbWFuZCwgYmVmb3JlIGF1dGhlbnRpY2F0aW5nIHRoZSB1c2VyLVBJLCBh IHNlcnZlci1GVFAgcHJvY2VzcyBTSE9VTEQgdmFsaWRhdGUgdGhhdCB0aGUgaG9zdG5hbWUgZ2l2 ZW4gcmVwcmVzZW50cyBhIHZhbGlkIHZpcnR1YWwgaG9zdCBmb3IgdGhhdCBzZXJ2ZXIsIGFuZCwg aWYgaXQgaXMgdmFsaWQsIGVzdGFibGlzaCB0aGUgYXBwcm9wcmlhdGUgZW52aXJvbm1lbnQgZm9y IHRoYXQgdmlydHVhbCBob3N0LiAgVGhlIHJlc3VsdGFudCBhY3Rpb25zIG5lZWRlZCB0byBjcmVh dGUgdGhhdCBlbnZpcm9ubWVudCBhcmUgbm90IHNwZWNpZmllZCBoZXJlLCBhbmQgbWF5IHJhbmdl IGZyb20gZG9pbmcgbm90aGluZyBhdCBhbGwsIHRvIHBlcmZvcm1pbmcgYSBzaW1wbGUgY2hhbmdl IG9mIHdvcmtpbmcgZGlyZWN0b3J5LCBjaGFuZ2luZyBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGFu ZC9vciB1c2VybmFtZSBhbmQgcGFzc3dvcmQgbGlzdHMsIG9yIG1ha2luZyBtdWNoIG1vcmUgZWxh Ym9yYXRlIHN0YXRlIGNoYW5nZXMgLSBzdWNoIGFzIGNyZWF0aW5nIGlzb2xhdGVkIGVudmlyb25t ZW50cyBmb3IgZWFjaCBGVFAgc2Vzc2lvbi48L3Q+DQogICAgICAgIDx0PlRoZSAiMjIwIiByZXBs eSBjb2RlIGZvciB0aGUgSE9TVCBjb21tYW5kIGlzIHRoZSBzYW1lIGFzIHRoZSBjb2RlIHRoYXQg aXMgdXNlZCBpbiB0aGUgaW5pdGlhbCAid2VsY29tZSIgbWVzc2FnZSB0aGF0IGlzIHNlbnQgYWZ0 ZXIgdGhlIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQuPC90Pg0KICAgICAgICA8dD5JZiB0aGUg aG9zdG5hbWUgc3BlY2lmaWVkIHdvdWxkIG5vcm1hbGx5IGJlIGFjY2VwdGFibGUsIGJ1dCBmb3Ig YW55IHJlYXNvbiBpcyB0ZW1wb3JhcmlseSB1bmF2YWlsYWJsZSwgdGhlIHNlcnZlci1GVFAgcHJv Y2VzcyBTSE9VTEQgcmVwbHkgdG8gdGhlIEhPU1QgY29tbWFuZCB3aXRoIGEgNDIxIHJlcGx5IGFu ZCBjbG9zZSB0aGUgY29ubmVjdGlvbi4gIEluIHRoaXMgcGFydGljdWxhciBzaXR1YXRpb24sIHRo ZSBzZXJ2ZXItRlRQIHByb2Nlc3MgTUFZIGNob29zZSB0byBrZWVwIHRoZSBjb25uZWN0aW9uIG9w ZW4gaW4gb3JkZXIgdG8gYWxsb3cgdGhlIHVzZXItUEkgYW4gb3Bwb3J0dW5pdHkgdG8gY2hvb3Nl IGFub3RoZXIgdmlydHVhbCBob3N0IHdpdGggYSBzdWJzZXF1ZW50IEhPU1QgY29tbWFuZC48L3Q+ DQogICAgICAgIDx0PklmIHRoZSBob3N0bmFtZSBzcGVjaWZpZWQgaXMgdW5rbm93biBhdCB0aGUg c2VydmVyLCBvciBpZiB0aGUgc2VydmVyIGlzIG90aGVyd2lzZSB1bndpbGxpbmcgdG8gdHJlYXQg dGhlIHBhcnRpY3VsYXIgY29ubmVjdGlvbiBhcyBhIGNvbm5lY3Rpb24gdG8gdGhlIGhvc3RuYW1l IHNwZWNpZmllZCwgdGhlIHNlcnZlciBTSE9VTEQgcmVzcG9uZCB3aXRoIGEgNTA0IHJlcGx5Ljwv dD4NCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9IlJFSU4gY29tbWFuZCBzZW1hbnRpY3MiIHRvYz0i ZGVmYXVsdCI+DQogICAgICAgICAgPHQ+QXMgc3BlY2lmaWVkIGluIDx4cmVmIHRhcmdldD0iUkZD MDk1OSIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPiwgdGhlIFJFSU4gY29tbWFu ZCByZXR1cm5zIHRoZSBzdGF0ZSBvZiB0aGUgY29ubmVjdGlvbiB0byB3aGF0IGl0IHdhcyBpbW1l ZGlhdGVseSBhZnRlciB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gd2FzIG9wZW5lZC4gIFRoaXMg c3BlY2lmaWNhdGlvbiBtYWtlcyBubyBjaGFuZ2VzIHRvIHRoYXQgYmVoYXZpb3IuICBUaGUgZWZm ZWN0IG9mIGEgSE9TVCBjb21tYW5kIE1VU1QgYmUgcmVzZXQgaWYgYSBSRUlOIGNvbW1hbmQgaXMg cGVyZm9ybWVkLCBhbmQgYSBuZXcgSE9TVCBjb21tYW5kIE1VU1QgYmUgaXNzdWVkIGluIG9yZGVy IHRvIGNvbm5lY3QgdG8gYSB2aXJ0dWFsIGhvc3QuPC90Pg0KICAgICAgICA8L3NlY3Rpb24+DQog ICAgICAgIDxzZWN0aW9uIHRpdGxlPSJVc2VyLVBJIHVzYWdlIG9mIEhPU1QiIHRvYz0iZGVmYXVs dCI+DQogICAgICAgICAgPHQ+QSB1c2VyLVBJIHRoYXQgY29uZm9ybXMgdG8gdGhpcyBzcGVjaWZp Y2F0aW9uIE1VU1Qgc2VuZCB0aGUgSE9TVCBjb21tYW5kIGFmdGVyIG9wZW5pbmcgdGhlIHRyYW5z cG9ydCBjb25uZWN0aW9uLCBvciBhZnRlciBhbnkgUkVJTiBjb21tYW5kLCBiZWZvcmUgYXR0ZW1w dGluZyB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIgd2l0aCB0aGUgVVNFUiBjb21tYW5kLiAgVGhl IGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIHdoYXQgYSB0eXBpY2FsIGxvZ2luIHNlcXVl bmNlIG1pZ2h0IGxvb2sgbGlrZSB3aGVuIHRoZSBIT1NUIGNvbW1hbmQgaXMgdXNlZDo8L3Q+DQog ICAgICAgICAgPHQ+DQogICAgICAgICAgICA8ZmlndXJlIHRpdGxlPSIiIHN1cHByZXNzLXRpdGxl PSJmYWxzZSIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+DQogICAgICAg ICAgICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJlc2VydmUiIG5hbWU9IiIgdHlwZT0iIiBhbGln bj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj48IVtDREFUQVsgICAgIEM+IEhPU1Qg ZnRwLmV4YW1wbGUuY29tDQogICAgIFM+IDIyMCBIb3N0IGFjY2VwdGVkDQogICAgIEM+IFVTRVIg Zm9vDQogICAgIFM+IDMzMSBQYXNzd29yZCByZXF1aXJlZA0KICAgICBDPiBQQVNTIGJhcg0KICAg ICBTPiAyMzAgVXNlciBsb2dnZWQgaW5dXT48L2FydHdvcms+DQogICAgICAgICAgICA8L2ZpZ3Vy ZT4NCiAgICAgICAgICA8L3Q+DQogICAgICAgICAgPHQ+SWYgYSB1c2VyLVBJIHNlbmRzIGFuIGFk ZGl0aW9uYWwgSE9TVCBjb21tYW5kIGJlZm9yZSBhdHRlbXB0aW5nIHRvIGF1dGhlbnRpY2F0ZSB0 aGUgdXNlciwgYSBzZXJ2ZXItRlRQIHByb2Nlc3MgdGhhdCBjb25mb3JtcyB0byB0aGlzIHNwZWNp ZmljYXRpb24gTVVTVCB0cmVhdCB0aGUgYWRkaXRpb25hbCBIT1NUIGNvbW1hbmQgYXMgdGhvdWdo IGEgUkVJTiBjb21tYW5kIHdhcyBzZW50LCBhbmQgcmVzZXQgdGhlIHVzZXItUEkgdG8gdGhlIHN0 YXRlIHRoYXQgZXhpc3RlZCBhZnRlciB0aGUgVENQIGNvbm5lY3Rpb24gd2FzIGZpcnN0IGVzdGFi bGlzaGVkLiAgRm9yIGV4YW1wbGUsIGlmIGEgdXNlciBzcGVjaWZpZXMgdGhlIHdyb25nIHZpcnR1 YWwgaG9zdCBieSBtaXN0YWtlLCBzZW5kaW5nIGEgc3Vic2VxdWVudCBIT1NUIGNvbW1hbmQgd2ls bCByZWN0aWZ5IHRoZSBlcnJvci4gIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3RyYXRlcyB3 aGF0IHRoZSBsb2dpbiBzZXF1ZW5jZSBtaWdodCBsb29rIGxpa2Ugd2hlbiB0aGUgSE9TVCBjb21t YW5kIGlzIHNlbnQgdHdpY2UgYmVmb3JlIGEgdXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkOjwv dD4NCiAgICAgICAgICA8dD4NCiAgICAgICAgICAgIDxmaWd1cmUgdGl0bGU9IiIgc3VwcHJlc3Mt dGl0bGU9ImZhbHNlIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj4NCiAg ICAgICAgICAgICAgPGFydHdvcmsgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIgbmFtZT0iIiB0eXBlPSIi IGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPjwhW0NEQVRBWyAgICAgQz4g SE9TVCBmb28uZXhhbXBsZS5jb20NCiAgICAgUz4gMjIwIEhvc3QgYWNjZXB0ZWQNCiAgICAgQz4g SE9TVCBiYXIuZXhhbXBsZS5jb20NCiAgICAgUz4gMjIwIEhvc3QgYWNjZXB0ZWQNCiAgICAgQz4g VVNFUiBmb28NCiAgICAgUz4gMzMxIFBhc3N3b3JkIHJlcXVpcmVkDQogICAgIEM+IFBBU1MgYmFy DQogICAgIFM+IDIzMCBVc2VyIGxvZ2dlZCBpbl1dPjwvYXJ0d29yaz4NCiAgICAgICAgICAgIDwv ZmlndXJlPg0KICAgICAgICAgIDwvdD4NCiAgICAgICAgICA8dD5UaGUgSE9TVCBjb21tYW5kIGNh biBiZSB1c2VkIGluIGNvbWJpbmF0aW9uIHdpdGggdGhlIEFDQ1QgY29tbWFuZCB0byBkaWZmZXJl bnRpYXRlIGJldHdlZW4gYSB1c2VyJ3MgdmFyaW91cyBhY2NvdW50cyBvbiBhIHNwZWNpZmljIHZp cnR1YWwgaG9zdC4gIEluIHRoaXMgc2NlbmFyaW8sIHRoZSB1c2VyLVBJIHNlbmRzIGEgSE9TVCBj b21tYW5kIHdoaWNoIHRoZSBzZXJ2ZXItUEkgdXNlcyB0byByb3V0ZSBhY3Rpdml0eSB0byB0aGUg Y29ycmVjdCB2aXJ0dWFsIGhvc3Q7IHRoZSB1c2VyLVBJIHNlbmRzIGNyZWRlbnRpYWxzIHVzaW5n IHRoZSBVU0VSIGFuZCBQQVNTIGNvbW1hbmRzIHdoaWNoIHRoZSBzZXJ2ZXItUEkgdmFsaWRhdGVz OyB0aGVuLCB0aGUgdXNlci1QSSBzZW5kcyBhbiBBQ0NUIGNvbW1hbmQgdG8gc3BlY2lmeSBhbnkg YWRkaXRpb25hbCBhY2NvdW50IGluZm9ybWF0aW9uIGZvciB0aGUgc2VydmVyLVBJIGltcGxlbWVu dGF0aW9uLiAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIGEgc2VxdWVudGlhbCBz ZXJpZXMgb2YgY2xpZW50IGNvbW1hbmRzIHRoYXQgc3BlY2lmeSBib3RoIGEgSE9TVCBhbmQgQUND VCwgd2l0aCB0aGUgc2VydmVyIHJlc3BvbnNlcyBvbWl0dGVkIGZvciBicmV2aXR5OjwvdD4NCiAg ICAgICAgICA8dD4NCiAgICAgICAgICAgIDxmaWd1cmUgdGl0bGU9IiIgc3VwcHJlc3MtdGl0bGU9 ImZhbHNlIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj4NCiAgICAgICAg ICAgICAgPGFydHdvcmsgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIgbmFtZT0iIiB0eXBlPSIiIGFsaWdu PSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPjwhW0NEQVRBWyAgICAgQz4gSE9TVCBm dHAuZXhhbXBsZS5jb20NCiAgICAgQz4gVVNFUiBmb28NCiAgICAgQz4gUEFTUyBiYXINCiAgICAg Qz4gQUNDVCBwcm9qZWN0MV1dPjwvYXJ0d29yaz4NCiAgICAgICAgICAgIDwvZmlndXJlPg0KICAg ICAgICAgIDwvdD4NCiAgICAgICAgICA8dD5UaGlzIGlzIGFsc28gdHJ1ZSB3aGVuIHRoZSBIT1NU IGNvbW1hbmQgaXMgdXNlZCB3aXRoIHRoZSBBVVRIIGFuZCBBREFUIGNvbW1hbmRzIHRoYXQgYXJl IGRpc2N1c3NlZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzIyMjgiIHBhZ2Vubz0iZmFsc2UiIGZvcm1h dD0iZGVmYXVsdCIgLz4gYW5kIDx4cmVmIHRhcmdldD0iUkZDNDIxNyIgcGFnZW5vPSJmYWxzZSIg Zm9ybWF0PSJkZWZhdWx0IiAvPi4gIEluIHRoaXMgc2NlbmFyaW8sIHRoZSB1c2VyLVBJIHNlbmRz IGEgSE9TVCBjb21tYW5kIHdoaWNoIHRoZSBzZXJ2ZXItUEkgdXNlcyB0byByb3V0ZSBhY3Rpdml0 eSB0byB0aGUgY29ycmVjdCB2aXJ0dWFsIGhvc3QsIHRoZW4gdGhlIHVzZXItUEkgdXNlcyB0aGUg QVVUSCBhbmQgQURBVCBjb21tYW5kcyB0byBuZWdvdGlhdGUgdGhlIHNlY3VyaXR5IG1lY2hhbmlz bSBhbmQgcmVsZXZhbnQgYXV0aGVudGljYXRpb24gdG9rZW4ocykgd2l0aCB0aGUgc2VydmVyLVBJ LCB0aGVuIHRoZSB1c2VyLVBJIHNlbmRzIHVzZXIgY3JlZGVudGlhbHMgdXNpbmcgdGhlIFVTRVIg YW5kIFBBU1MgY29tbWFuZHMgd2hpY2ggdGhlIHNlcnZlci1QSSB2YWxpZGF0ZXMuICBBZnRlciB3 aGljaCB0aGUgdXNlci1QSSBNQVkgc2VuZCBhbiBBQ0NUIGNvbW1hbmQgdG8gc3BlY2lmeSBhbnkg YWRkaXRpb25hbCBhY2NvdW50IGluZm9ybWF0aW9uIGZvciB0aGUgc2VydmVyLVBJIGltcGxlbWVu dGF0aW9uLiAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIGEgc2VxdWVudGlhbCBz ZXJpZXMgb2YgY2xpZW50IGNvbW1hbmRzIHRoYXQgc3BlY2lmeSBib3RoIGEgSE9TVCBhbmQgQUND VCB3aGVuIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgc2VjdXJpdHkgY29tbWFuZHMgdGhh dCBhcmUgZGlzY3Vzc2VkIGluIDx4cmVmIHRhcmdldD0iUkZDMjIyOCIgcGFnZW5vPSJmYWxzZSIg Zm9ybWF0PSJkZWZhdWx0IiAvPiBhbmQgPHhyZWYgdGFyZ2V0PSJSRkM0MjE3IiBwYWdlbm89ImZh bHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+LCB3aXRoIHRoZSBzZXJ2ZXIgcmVzcG9uc2VzIG9taXR0 ZWQgZm9yIGJyZXZpdHk6PC90Pg0KICAgICAgICAgIDx0Pg0KICAgICAgICAgICAgPGZpZ3VyZSB0 aXRsZT0iIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9 IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgICA8YXJ0d29yayB4bWw6c3BhY2U9InByZXNlcnZl IiBuYW1lPSIiIHR5cGU9IiIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+ PCFbQ0RBVEFbICAgICBDPiBIT1NUIGZ0cC5leGFtcGxlLmNvbQ0KICAgICBDPiBBVVRIIDxtZWNo YW5pc20tbmFtZT4NCiAgICAgQz4gQURBVCA8YmFzZTY0ZGF0YT4NCiAgICAgQz4gVVNFUiBmb28N CiAgICAgQz4gUEFTUyBiYXINCiAgICAgQz4gQUNDVCBwcm9qZWN0MV1dPjwvYXJ0d29yaz4NCiAg ICAgICAgICAgIDwvZmlndXJlPg0KICAgICAgICAgIDwvdD4NCiAgICAgICAgPC9zZWN0aW9uPg0K ICAgICAgICA8c2VjdGlvbiB0aXRsZT0iU3RhdGUgRGlhZ3JhbXMiIHRvYz0iZGVmYXVsdCI+DQog ICAgICAgICAgPHQ+VGhlIHN0YXRlIGRpYWdyYW1zIGluIHRoaXMgc2VjdGlvbiBpbGx1c3RyYXRl IHR5cGljYWwgc2VxdWVuY2VzIGZvciBjb21tYW5kIGFuZCByZXBseSBpbnRlcmNoYW5nZSBiZXR3 ZWVuIHRoZSB1c2VyLVBJIGFuZCBzZXJ2ZXItUEkuICBUaGVzZSBkaWFncmFtcyBhcmUgbW9kZWxl ZCBvbiB0aGUgc2ltaWxhciBkaWFncmFtcyBpbiBzZWN0aW9uIDYgb2YgPHhyZWYgdGFyZ2V0PSJS RkMwOTU5IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+LjwvdD4NCiAgICAgICAg ICA8dD5JbiBlYWNoIGRpYWdyYW0sIHRoZSAoQikgImJlZ2luIiBzdGF0ZSBpcyBhc3N1bWVkIHRv IG9jY3VyIGFmdGVyIHRoZSB0cmFuc3BvcnQgY29ubmVjdGlvbiBoYXMgb3BlbmVkLCBvciBhZnRl ciBhIFJFSU4gY29tbWFuZCBoYXMgc3VjY2VlZGVkLiAgT3RoZXIgY29tbWFuZHMgKHN1Y2ggYXMg RkVBVCA8eHJlZiB0YXJnZXQ9IlJGQzIzODkiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVs dCIgLz4pIHRoYXQgcmVxdWlyZSBubyBhdXRoZW50aWNhdGlvbiBtYXkgaGF2ZSBpbnRlcnZlbmVk LjwvdD4NCiAgICAgICAgICA8dD5BZGRpdGlvbmFsbHksIGEgdGhyZWUtZGlnaXQgcmVwbHkgaW5k aWNhdGVzIGEgcHJlY2lzZSBzZXJ2ZXIgcmVwbHkgY29kZS4gIEEgc2luZ2xlIGRpZ2l0IG9uIGEg cmVwbHkgcGF0aCBpbmRpY2F0ZXMgYW55IHNlcnZlciByZXBseSB0aGF0IGJlZ2lucyB3aXRoIHRo YXQgZGlnaXQsIGV4Y2VwdCB3aGVyZSBhIHByZWNpc2Ugc2VydmVyIHJlcGx5IGNvZGUgaXMgZGVm aW5lZCBvbiBhbm90aGVyIHBhdGguICBGb3IgZXhhbXBsZSwgYSBzaW5nbGUgZGlnaXQgIjUiIHdp bGwgYXBwbHkgdG8gIjUwMCIsICI1MDEiLCAiNTAyIiwgZXRjLiwgd2hlbiB0aG9zZSByZXBseSBj b2RlcyBhcmUgbm90IGV4cHJlc3NseSBkZWZpbmVkIGluIHRoZSBkaWFncmFtLiAgRm9yIGVhY2gg Y29tbWFuZCB0aGVyZSBhcmUgdGhyZWUgcG9zc2libGUgb3V0Y29tZXM6IHN1Y2Nlc3MgKFMpLCBm YWlsdXJlIChGKSwgYW5kIGVycm9yIChFKS4gIEluIHRoZSBzdGF0ZSBkaWFncmFtcyBiZWxvdyB3 ZSB1c2UgdGhlIHN5bWJvbCBCIGZvciAiYmVnaW4iLCBhbmQgdGhlIHN5bWJvbCBXIGZvciAid2Fp dCBmb3IgcmVwbHkiLjwvdD4NCiAgICAgICAgICA8dD5JbiBlYWNoIG9mIHRoZXNlIGRpYWdyYW1z LCBhIFJFSU4gY29tbWFuZCB3aWxsIHJldHVybiB0aGUgZGlhZ3JhbSB0byB0aGUgKEIpICJiZWdp biIgc3RhdGUuPC90Pg0KICAgICAgICAgIDx0Pg0KICAgICAgICAgICAgPGZpZ3VyZSB0aXRsZT0i RmlndXJlIDE6IFR5cGljYWwgbG9naW4gc2VxdWVuY2Ugd2l0aCBIT1NUIGNvbW1hbmQiIHN1cHBy ZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+ DQogICAgICAgICAgICAgIDxwcmVhbWJsZT5UaGUgc3RhdGUgZGlhZ3JhbSBpbiBGaWd1cmUgMSBz aG93cyBhIHR5cGljYWwgc2VxdWVuY2Ugb2YgZmxvdyBvZiBjb250cm9sIHdoZW4gSE9TVCBpcyB1 c2VkIHdpdGggVVNFUiBhbmQgUEFTUyB0byBsb2cgaW4gdG8gYSBwYXJ0aWN1bGFyIEZUUCB2aXJ0 dWFsIGhvc3QuPC9wcmVhbWJsZT4NCiAgICAgICAgICAgICAgPGFydHdvcmsgeG1sOnNwYWNlPSJw cmVzZXJ2ZSIgbmFtZT0iIiB0eXBlPSIiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVp Z2h0PSIiPjwhW0NEQVRBWw0KICAgICAgICAgICArLS0tKyAgIEhPU1QgICAgKy0tLSsgMSwzLDUN CiAgICAgICAgICAgfCBCIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0tLS0tLS0NCiAgICAg ICAgICAgKy0tLSsgICAgICAgICAgICstLS0rICAgICAgICAgICAgICAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCB8ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg ICAgMiw1MDAsNTAyIHwgfCA0LDUwMSw1MDMsNTA0ICAgIHwNCiAgICAgICAgICAgICAgLS0tLS0t LS0tLS0tLS0gICAtLS0tLS0tLS0tLSAgICAgICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgVg0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgfCAgICArLS0tKw0KICAgICAgICAgICArLS0tKyAgIFVTRVIgICAgKy0tLSst LS0tLS0tLS0tLS0tLT58IEUgfA0KICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgMiAg ICAgICAgfCAgICArLS0tKw0KICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSstLS0tLS0t ICAgfCAgICAgIF4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgIHwgIHwg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIDMgfCB8IDQsNSAgICB8ICB8ICAgICAg fA0KICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tICAgfCAgfCAgICAgIHwNCiAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICB8DQogICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAg fCAgICAgICAgICAgICAgMXwgICAgICB8ICB8ICB8DQogICAgICAgICAgICAgViAgICAgICAgICAg ICAgIHwgICAgICB8ICAgLS0tLS0tPistLS0rDQogICAgICAgICAgICstLS0rICAgUEFTUyAgICAr LS0tKyAyICB8ICAgICB8ICAgIHwgUyB8DQogICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcg fC0tLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICstLS0rICAgICAgICAgICArLS0tKyAg ICB8ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICB8DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw0LDUgICB8ICAgICB8DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgLS0tPistLS0rDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgLS0tLS0tLS0tPnwgRiB8DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tPistLS0rXV0+PC9hcnR3b3JrPg0KICAgICAgICAg ICAgPC9maWd1cmU+DQogICAgICAgICAgPC90Pg0KICAgICAgICAgIDx0Pg0KICAgICAgICAgICAg PGZpZ3VyZSB0aXRsZT0iRmlndXJlIDI6IExvZ2luIHNlcXVlbmNlIHdpdGggcmVwZWF0ZWQgSE9T VCBjb21tYW5kIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lk dGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgICA8cHJlYW1ibGU+VGhlIHN0YXRlIGRpYWdy YW0gaW4gRmlndXJlIDIgc2hvd3MgdGhlIGZsb3cgb2YgY29udHJvbCB3aGVuIGEgSE9TVCBjb21t YW5kIGlzIHNlbnQgYWZ0ZXIgYSB1c2VyIGhhcyBhbHJlYWR5IHN1Y2Nlc3NmdWxseSBsb2dnZWQg aW4gdG8gYSB2aXJ0dWFsIGhvc3Qgd2l0aCBVU0VSIGFuZCBQQVNTLjwvcHJlYW1ibGU+DQogICAg ICAgICAgICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJlc2VydmUiIG5hbWU9IiIgdHlwZT0iIiBh bGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj48IVtDREFUQVsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICArLS0tKyAgIEhPU1QgICAgKy0tLSsgMSwzLDUgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICB8IEIgfC0tLS0tLS0tLS0+fCBXIHwtLS0t LS0tLS0tLS0tLS0tLSAgICAgICAgICAgfA0KICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0t LSsgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAg Miw1MDAsNTAyIHwgfCA0LDUwMSw1MDMsNTA0ICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAg ICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0tICAgICAgIHwgICAgICAgICAgfA0KICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFYgICAgICAgICAgfA0K ICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgMSAgICAgICAgfCAgICArLS0tKyAgICAg ICAgfA0KICAgICAgICAgICArLS0tKyAgIFVTRVIgICAgKy0tLSstLS0tLS0tLS0tLS0tLT58IEUg fCAgICAgICAgfA0KICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgMiAgICAgICAgfCAg ICArLS0tKyAgICAgICAgfA0KICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSstLS0tLS0t ICAgfCAgICAgIF4gICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfCAg ICAgICAgfCAgfCAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAz IHwgfCA0LDUgICAgfCAgfCAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAtLS0tLS0t LS0tLS0tLSAgIC0tLS0tLSAgfCAgfCAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgfA0KICAg ICAgICAgICAgIHwgICAgICAgICAgICAgIDF8ICAgICAgfCAgfCAgfCAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICB8ICAgICAgfCAgIC0tLS0tLT4rLS0tKyAg SE9TVCAgfA0KICAgICAgICAgICArLS0tKyAgIFBBU1MgICAgKy0tLSsgMiAgfCAgICAgfCAgICB8 IFMgfC0tLS0tLS0tDQogICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0tLS0t LS0tPistLS0rDQogICAgICAgICAgICstLS0rICAgICAgICAgICArLS0tKyAgICB8ICAgICB8DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICB8DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHw0LDUgICB8ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICB8ICAgICAgLS0tPistLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgLS0tLS0tLS0tPnwgRiB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LS0tLS0tLS0tLS0tLS0tPistLS0rXV0+PC9hcnR3b3JrPg0KICAgICAgICAgICAgPC9maWd1cmU+ DQogICAgICAgICAgPC90Pg0KICAgICAgICAgIDx0Pg0KICAgICAgICAgICAgPGZpZ3VyZSB0aXRs ZT0iRmlndXJlIDM6IExvZ2luIHNlcXVlbmNlIHdpdGggSE9TVCBhbmQgQUNDVCBjb21tYW5kcyIg c3VwcHJlc3MtdGl0bGU9ImZhbHNlIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdo dD0iIj4NCiAgICAgICAgICAgICAgPHByZWFtYmxlPkFmdGVyIGEgdXNlciBoYXMgbG9nZ2VkIGlu LCBhbiBhZGRpdGlvbmFsIGFjY291bnQgbWF5IGJlIHJlcXVpcmVkIGJ5IHRoZSBzZXJ2ZXIgYW5k IHNwZWNpZmllZCBieSB0aGUgY2xpZW50IGJ5IHVzaW5nIEFDQ1QgY29tbWFuZC4gIFdpdGggdGhp cyBpbiBtaW5kLCB0aGUgc3RhdGUgZGlhZ3JhbSBpbiBGaWd1cmUgMyBzaG93cyBhIHR5cGljYWwg c2VxdWVuY2Ugb2YgZmxvdyBvZiBjb250cm9sIHdoZW4gSE9TVCBpcyB1c2VkIHdpdGggVVNFUiBh bmQgUEFTUyB0byBsb2cgaW4gdG8gYW4gRlRQIHZpcnR1YWwgaG9zdCBhbmQgQUNDVCBpcyB1c2Vk IHRvIHNwZWNpZnkgYW4gYWNjb3VudC48L3ByZWFtYmxlPg0KICAgICAgICAgICAgICA8YXJ0d29y ayB4bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIHR5cGU9IiIgYWxpZ249ImxlZnQiIGFsdD0i IiB3aWR0aD0iIiBoZWlnaHQ9IiI+PCFbQ0RBVEFbDQogICAgICAgICAgICstLS0rICAgSE9TVCAg ICArLS0tKyAxLDMsNQ0KICAgICAgICAgICB8IEIgfC0tLS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0t LS0tLS0tLQ0KICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgICAgICAgICAgICB8DQog ICAgICAgICAgICAgICAgICAyLDUwMCw1MDIgfCB8IDQsNTAxLDUwMyw1MDQgICAgfA0KICAgICAg ICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0tLS0gICAgIHwNCiAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8DQogICAgICAgICAgICAgViAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgIHwgICAgVg0KICAgICAgICAgICArLS0tKyAgIFVT RVIgICAgKy0tLSstLS0tLS0tLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICB8ICAgfC0tLS0tLS0t LS0+fCBXIHwgMiAgICAgICAtLS0tLT58IEUgfA0KICAgICAgICAgICArLS0tKyAgICAgICAgICAg Ky0tLSstLS0tLS0gIHwgIC0tLT4rLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg fCAgICAgICB8IHwgfCB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIDMgfCB8IDQsNSAgIHwg fCB8IHwNCiAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAtLS0tLSAgfCB8IHwgfA0KICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfCB8IHwgfCB8DQogICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICB8IHwgfCB8IHwNCiAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgIC0tLS0tLS0tLS0gIHwgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgIDF8ICAg ICAgfCB8ICAgfCB8DQogICAgICAgICAgICAgViAgICAgICAgICAgICAgIHwgICAgICB8IHwgICB8 IHwNCiAgICAgICAgICAgKy0tLSsgICBQQVNTICAgICstLS0rIDIgIHwgIC0tLS0tLS0+Ky0tLSsN CiAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0tLS0+fCBTIHwNCiAg ICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rICAgLS0tLS0tLS0tLS0+Ky0tLSsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IHwgICB8IHwgICAgIHwgfA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAzIHwgfDQsNXwgfCAgICAgfCB8DQogICAgICAgICAgICAgIC0tLS0tLS0tLS0t LS0tICAgLS0tLS0tLS0gICB8ICAtLS0tDQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgfCB8ICB8ICB8ICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwg fCAgfCAgfCAgICAgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0t LSAgICAgICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAgIDEsM3wgICAgfCB8ICB8ICAgICAg ICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICB8ICAgMnwgfCAgfCAgICAgICAgIFYN CiAgICAgICAgICAgKy0tLSsgICBBQ0NUICAgICstLS0rLS0gIHwgICAtLS0tLS0+Ky0tLSsNCiAg ICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8IDQsNSAtLS0tLS0tLS0+fCBGIHwNCiAgICAg ICAgICAgKy0tLSsgICAgICAgICAgICstLS0rLS0tLS0tLS0tLS0tLS0+Ky0tLStdXT48L2FydHdv cms+DQogICAgICAgICAgICA8L2ZpZ3VyZT4NCiAgICAgICAgICA8L3Q+DQogICAgICAgICAgPHQ+ DQogICAgICAgICAgICA8ZmlndXJlIHRpdGxlPSJGaWd1cmUgNDogTG9naW4gc2VxdWVuY2Ugd2l0 aCBIT1NUIGFuZCBBVVRIL0FEQVQgY29tbWFuZHMiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWxp Z249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+DQogICAgICAgICAgICAgIDxwcmVh bWJsZT5XaGVuIHRoZSBIT1NUIGNvbW1hbmQgaXMgdXNlZCBpbiBjb21iaW5hdGlvbiB3aXRoIHRo ZSBGVFAgc2VjdXJpdHkgZXh0ZW5zaW9ucyB0aGF0IHdlcmUgaW50cm9kdWNlZCBpbiA8eHJlZiB0 YXJnZXQ9IlJGQzIyMjgiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4sIGl0IFNI T1VMRCBwcmVjZWRlIHRoZSBzZWN1cml0eSBoYW5kc2hha2UuICBUaGlzIGFsbG93cyBib3RoIHVz ZXItUEkgYW5kIHNlcnZlci1GVFAgcHJvY2Vzc2VzIHRvIG1hcCBhbiBGVFAgSE9TVCB0byBzZWN1 cml0eSBkYXRhIGFwcHJvcHJpYXRlbHkuICBUaGUgc3RhdGUgZGlhZ3JhbSBpbiBGaWd1cmUgNCBz aG93cyBhIHR5cGljYWwgc2VxdWVuY2Ugb2YgZmxvdyBvZiBjb250cm9sIHdoZW4gSE9TVCBpcyB1 c2VkIHdpdGggdGhlIEFVVEggYW5kIEFEQVQgY29tbWFuZHMgdGhhdCBhcmUgZGlzY3Vzc2VkIGlu IDx4cmVmIHRhcmdldD0iUkZDMjIyOCIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAv Pi48L3ByZWFtYmxlPg0KICAgICAgICAgICAgICA8YXJ0d29yayB4bWw6c3BhY2U9InByZXNlcnZl IiBuYW1lPSIiIHR5cGU9IiIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+ PCFbQ0RBVEFbDQogICAgICAgICAgICstLS0rICAgSE9TVCAgICArLS0tKyAxLDMsNQ0KICAgICAg ICAgICB8IEIgfC0tLS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICAg ICstLS0rICAgICAgICAgICArLS0tKyAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IHwgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAg Miw1MDAsNTAyIHwgfCA0LDUwMSw1MDMsNTA0ICAgICB8DQogICAgICAgICAgICAgIC0tLS0tLS0t LS0tLS0tICAgLS0tLS0tLS0tLS0tLSAgICAgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICstLS0rICAgQVVUSCAgICArLS0tKyA0 LDUgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0t LS0tLS0+fCAgICAgfA0KICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgICAgICAg ICB8ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAzMzQgfCB8ICAgICAgICAgICAgIHwg ICAgIHwNCiAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gIHwgICAgICAgICAgICAgfCAgICAg fA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAyMzQgfCAgICAgICAgICAgICB8ICAgICB8DQog ICAgICAgICAgICAgfCAgICAtLS0tLS0tLS0tLS0gICAgICAgICAgICAgIHwgICAgIHwNCiAgICAg ICAgICAgICBWICAgfCAgICAgICAgICAgICAgIDQsNSAgICAgICAgfCAgICAgfA0KICAgICAgICAg ICArLS0tKyB8IEFEQVQgICAgKy0tLSstLS0tLS0tLS0tLT58ICAgICB8DQogICAgICAgICAgIHwg ICB8LS0tLS0tLS0tLT58IFcgfCAzMzUgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgKy0tLSsg fCAgICAgICAgICstLS0rLS0tLS0gICAgICAgfCAgICAgfA0KICAgICAgICAgICAgIF4gICB8ICAg ICAgICAgICB8ICAgICAgIHwgICAgICB8ICAgICB8DQogICAgICAgICAgICAgfCAgIHwgICAgICAg ICAgIHwgICAgICAgfCAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAg ICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgLS0tLSAgICAgICAgMjM1IHwgICAgICAg ICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgIHwgIC0tLS0tLS0tLS0tLS0tICAgICAgICAgICAg ICAgfCAgICAgfA0KICAgICAgICAgICAgfCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICBWDQogICAgICAgICAgICBWIFYgICAgICAgICAgICAgICAgICAxICAgICAgICAgIHwgICAr LS0tKw0KICAgICAgICAgICArLS0tKyAgIFVTRVIgICAgKy0tLSstLS0tLS0tLS0tLS0tLS0+fCBF IHwNCiAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8IDIgICAgICAgICAgfCAgICstLS0r DQogICAgICAgICAgICstLS0rICAgICAgICAgICArLS0tKy0tLS0tLS0gICAgIHwgICAgIF4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgIHwgICAgfCAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAzIHwgfCA0LDUgICAgfCAgICB8ICAgICB8DQogICAgICAgICAg ICAgIC0tLS0tLS0tLS0tLS0tICAgLS0tLS0tICB8ICAgIHwgICAgIHwNCiAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgfCAgICAgfA0KICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAxfCAgICAgICB8IHwgICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICB8ICAg ICAgIHwgIC0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgKy0tLSsgICBQQVNTICAgICstLS0rIDIg ICB8ICAgICAgfCAgIHwgUyB8DQogICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfC0tLS0t LS0tLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgIHwg ICAgICB8ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8NCw1ICAgIHwgICAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAtLT4rLS0tKw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAtLS0tLS0tLS0+fCBGIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tPistLS0rXV0+PC9hcnR3b3JrPg0KICAg ICAgICAgICAgPC9maWd1cmU+DQogICAgICAgICAgPC90Pg0KICAgICAgICAgIDx0Pg0KICAgICAg ICAgICAgPGZpZ3VyZSB0aXRsZT0iRmlndXJlIDU6IExvZ2luIHNlcXVlbmNlIHdpdGggSE9TVCBh bmQgQVVUSC9BREFUL0FDQ1QgY29tbWFuZHMiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249 ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+DQogICAgICAgICAgICAgIDxwcmVhbWJs ZT5BZnRlciBhIHVzZXIgaGFzIGxvZ2dlZCBpbiB3aXRoIHRoZSBzZWN1cml0eSBjb21tYW5kcyB0 aGF0IGFyZSBkaXNjdXNzZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMjI4IiBwYWdlbm89ImZhbHNl IiBmb3JtYXQ9ImRlZmF1bHQiIC8+LCBhbiBhZGRpdGlvbmFsIGFjY291bnQgbWF5IGJlIHJlcXVp cmVkIGJ5IHRoZSBzZXJ2ZXIgYW5kIHNwZWNpZmllZCBieSB0aGUgY2xpZW50IGJ5IHVzaW5nIEFD Q1QgY29tbWFuZC4gIFRoZSBzdGF0ZSBkaWFncmFtIGluIEZpZ3VyZSA1IHNob3dzIGEgdHlwaWNh bCBzZXF1ZW5jZSBvZiBmbG93IG9mIGNvbnRyb2wgd2hlbiBIT1NUIGlzIHVzZWQgd2l0aCB0aGUg QVVUSCBhbmQgQURBVCBjb21tYW5kcyB0byBsb2cgaW4gdG8gYW4gRlRQIHZpcnR1YWwgaG9zdCBh bmQgQUNDVCBpcyB1c2VkIHRvIHNwZWNpZnkgYW4gYWNjb3VudC48L3ByZWFtYmxlPg0KICAgICAg ICAgICAgICA8YXJ0d29yayB4bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIHR5cGU9IiIgYWxp Z249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+PCFbQ0RBVEFbDQogICAgICAgICAg ICstLS0rICAgSE9TVCAgICArLS0tKyAxLDMsNQ0KICAgICAgICAgICB8IEIgfC0tLS0tLS0tLS0+ fCBXIHwtLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICAgICstLS0rICAgICAgICAgICArLS0t KyAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgMiw1MDAsNTAyIHwgfCA0LDUwMSw1 MDMsNTA0ICAgICB8DQogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0t LS0gICAgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8 DQogICAgICAgICAgICstLS0rICAgQVVUSCAgICArLS0tKyA0LDUgICAgICAgICB8ICAgIHwNCiAg ICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0tPnwgICAgfA0KICAgICAg ICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgfCAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAzMzQgfCB8ICAgICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICAg LS0tLS0tLS0tLS0tLS0gIHwgICAgICAgICAgICAgIHwgICAgfA0KICAgICAgICAgICAgIHwgICAg ICAgICAgICAyMzQgfCAgICAgICAgICAgICAgfCAgICB8DQogICAgICAgICAgICAgfCAgICAtLS0t LS0tLS0tLS0gICAgICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICBWICAgfCAgICAgICAg ICAgICAgIDQsNSAgICAgICAgIHwgICAgfA0KICAgICAgICAgICArLS0tKyB8IEFEQVQgICAgKy0t LSstLS0tLS0tLS0tLS0+fCAgICB8DQogICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfCAz MzUgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgKy0tLSsgfCAgICAgICAgICstLS0rLS0tLS0g ICAgICAgIHwgICAgfA0KICAgICAgICAgICAgIF4gICB8ICAgICAgICAgICB8ICAgICAgIHwgICAg ICAgfCAgICB8DQogICAgICAgICAgICAgfCAgIHwgICAgICAgICAgIHwgICAgICAgfCAgICAgICB8 ICAgIHwNCiAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgIHwgICAg fA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICB8DQog ICAgICAgICAgICAgLS0tLSAgICAgICAgIDIzNXwgICAgICAgICAgICAgICB8ICAgIHwNCiAgICAg ICAgICAgIHwgIC0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgICAgIHwgICAgfA0KICAgICAgICAg ICAgfCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8DQogICAgICAgICAgICBW IFYgICAgICAgICAgICAgICAgICAxICAgICAgICAgICB8ICAgIFYNCiAgICAgICAgICAgKy0tLSsg ICBVU0VSICAgICstLS0rLS0tLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgIHwgICB8LS0t LS0tLS0tLT58IFcgfCAyICAgICAgICAtLS0tLT58IEUgfA0KICAgICAgICAgICArLS0tKyAgICAg ICAgICAgKy0tLSstLS0tLS0tICB8ICAtLS0+Ky0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8IHwgICAgICAgIHwgfCB8IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgMyB8IHwg NCw1ICAgIHwgfCB8IHwNCiAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0gIHwg fCB8IHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IHwgfCB8IHwNCiAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tICB8IHwNCiAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAxfCAgICAgICB8IHwgICB8IHwNCiAgICAgICAgICAgICBWICAgICAg ICAgICAgICAgfCAgICAgICB8IHwgICB8IHwNCiAgICAgICAgICAgKy0tLSsgICBQQVNTICAgICst LS0rIDIgICB8ICAtLS0tLS0tPistLS0rDQogICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcg fC0tLS0tLS0tLS0tLS0tLT58IFMgfA0KICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsg ICAtLS0tLS0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICB8 ICB8ICAgICB8IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgMyB8IHw0LDV8ICB8ICAgICB8 IHwNCiAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0tLS0gICB8ICAtLS0tDQog ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgfCAgfCAgfCAgICAgIHwNCiAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0gICAgICAgfA0KICAgICAgICAg ICAgIHwgICAgICAgICAgICAxLDN8ICAgIHwgIHwgIHwgICAgICAgICB8DQogICAgICAgICAgICAg ViAgICAgICAgICAgICAgIHwgICAyfCAgfCAgfCAgICAgICAgIFYNCiAgICAgICAgICAgKy0tLSsg ICBBQ0NUICAgICstLS0rLS0gICB8ICAgLS0tLS0tPistLS0rDQogICAgICAgICAgIHwgICB8LS0t LS0tLS0tLT58IFcgfCA0LDUgIC0tLS0tLS0tLT58IEYgfA0KICAgICAgICAgICArLS0tKyAgICAg ICAgICAgKy0tLSstLS0tLS0tLS0tLS0tLS0+Ky0tLStdXT48L2FydHdvcms+DQogICAgICAgICAg ICA8L2ZpZ3VyZT4NCiAgICAgICAgICA8L3Q+DQogICAgICAgIDwvc2VjdGlvbj4NCiAgICAgIDwv c2VjdGlvbj4NCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJIT1NUIGNvbW1hbmQgZXJyb3JzIiB0b2M9 ImRlZmF1bHQiPg0KICAgICAgICA8dD5UaGUgc2VydmVyLVBJIFNIT1VMRCByZXBseSB3aXRoIGEg NTAwIG9yIDUwMiByZXBseSBpZiB0aGUgSE9TVCBjb21tYW5kIGlzIHVucmVjb2duaXplZCBvciB1 bmltcGxlbWVudGVkLjwvdD4NCiAgICAgICAgPHQ+QXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gMyBv ZiB0aGlzIGRvY3VtZW50LCBpZiBhIEhPU1QgY29tbWFuZCBpcyBzZW50IGFmdGVyIGEgdXNlciBo YXMgYmVlbiBhdXRoZW50aWNhdGVkIHRoZSBzZXJ2ZXIgU0hPVUxEIGRvIG9uZSBvZiB0aGUgZm9s bG93aW5nOjwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAgPGxpc3Qgc3R5bGU9ImxldHRlcnMi Pg0KICAgICAgICAgICAgPHQ+U2VuZCBhIDUwMyByZXBseSBmb3IgYW4gaW52YWxpZCBzZXF1ZW5j ZSBvZiBjb21tYW5kcy48L3Q+DQogICAgICAgICAgICA8dD5UcmVhdCB0aGUgSE9TVCBjb21tYW5k IGFzIHRob3VnaCBhIFJFSU4gY29tbWFuZCB3YXMgc2VudCBhbmQgcmVzZXQgdGhlIHVzZXItUEkg dG8gdGhlIHN0YXRlIHRoYXQgZXhpc3RlZCBhZnRlciB0aGUgcHJldmlvdXMgSE9TVCBjb21tYW5k IHdhcyBzZW50IGFuZCBiZWZvcmUgdGhlIHVzZXIgaGFkIGJlZW4gYXV0aGVudGljYXRlZCwgYW5k IHRoZW4gcmV0dXJuIHRoZSBhcHByb3ByaWF0ZSByZXBseSBmb3IgdGhlIEhPU1QgY29tbWFuZC48 L3Q+DQogICAgICAgICAgPC9saXN0Pg0KICAgICAgICA8L3Q+DQogICAgICAgIDx0PkEgNTAxIHJl cGx5IFNIT1VMRCBiZSBzZW50IGlmIHRoZSBob3N0bmFtZSBnaXZlbiBpcyBzeW50YWN0aWNhbGx5 IGludmFsaWQsIGFuZCBhIDUwNCByZXBseSBTSE9VTEQgYmUgc2VudCBpZiBhIHN5bnRhY3RpY2Fs bHkgdmFsaWQgaG9zdG5hbWUgaXMgbm90IGEgdmFsaWQgdmlydHVhbCBob3N0IG5hbWUgZm9yIHRo ZSBzZXJ2ZXIuICBJbiBhbGwgc3VjaCBjYXNlcywgdGhlIHNlcnZlci1GVFAgcHJvY2VzcyBNVVNU IGRvIG9uZSBvZiB0aGUgZm9sbG93aW5nOjwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAgPGxp c3Qgc3R5bGU9ImxldHRlcnMiPg0KICAgICAgICAgICAgPHQ+SWdub3JlIHRoZSBIT1NUIGNvbW1h bmQgYW5kIGFjdCBhcyBpZiBhIEhPU1QgY29tbWFuZCBoYWQgbm90IGJlZW4gc2VudC4gIEEgdXNl ci1GVFAgcHJvY2VzcyBNQVkgdGhlbiBzZW5kIGEgc3Vic2VxdWVudCBIT1NUIGNvbW1hbmQgd2l0 aCBhIGRpZmZlcmVudCBob3N0bmFtZS48L3Q+DQogICAgICAgICAgICA8dD5DbG9zZSB0aGUgY29u bmVjdGlvbi48L3Q+DQogICAgICAgICAgPC9saXN0Pg0KICAgICAgICA8L3Q+DQogICAgICAgIDx0 PkEgdXNlci1QSSByZWNlaXZpbmcgYSA1MDAgb3IgNTAyIHJlcGx5IHRvIGEgSE9TVCBjb21tYW5k IFNIT1VMRCBhc3N1bWUgdGhhdCB0aGUgc2VydmVyLVBJIGRvZXMgbm90IGltcGxlbWVudCB2aXJ0 dWFsIHNlcnZlcnMgYnkgdXNpbmcgdGhlIEhPU1QgY29tbWFuZC4gIFRoZSB1c2VyLVBJIE1BWSB0 aGVuIHByb2NlZWQgdG8gbG9naW4gYXMgaWYgdGhlIEhPU1QgY29tbWFuZCBoYWQgbm90IGJlZW4g c2VudC48L3Q+DQogICAgICAgIDx0PkEgdXNlci1QSSByZWNlaXZpbmcgYW4gZXJyb3IgcmVwbHkg dGhhdCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZXJyb3JzIHRoYXQgaGF2ZSBiZWVuIGRlc2NyaWJl ZCBoZXJlIFNIT1VMRCBhc3N1bWUgdGhhdCB0aGUgdmlydHVhbCBIT1NUIGlzIHVuYXZhaWxhYmxl LCBhbmQgdGVybWluYXRlIGNvbW11bmljYXRpb25zLjwvdD4NCiAgICAgICAgPHQ+QSBzZXJ2ZXIt UEkgdGhhdCByZWNlaXZlcyBhIFVTRVIgY29tbWFuZCB0byBiZWdpbiB0aGUgYXV0aGVudGljYXRp b24gc2VxdWVuY2Ugd2l0aG91dCBoYXZpbmcgcmVjZWl2ZWQgYSBIT1NUIGNvbW1hbmQgU0hPVUxE IE5PVCByZWplY3QgdGhlIFVTRVIgY29tbWFuZC4gIENsaWVudHMgY29uZm9ybWluZyB0byBlYXJs aWVyIEZUUCBzcGVjaWZpY2F0aW9ucyBkbyBub3Qgc2VuZCBIT1NUIGNvbW1hbmRzLiAgSW4gdGhp cyBjYXNlIHRoZSBzZXJ2ZXIgTUFZIGFjdCBhcyBpZiBzb21lIGRlZmF1bHQgdmlydHVhbCBob3N0 IGhhZCBiZWVuIGV4cGxpY2l0bHkgc2VsZWN0ZWQsIG9yIE1BWSBlbnRlciBhbiBlbnZpcm9ubWVu dCB0aGF0IGlzIGRpZmZlcmVudCBmcm9tIHRoYXQgb2YgYW55IHN1cHBvcnRlZCB2aXJ0dWFsIGhv c3RzLCBwZXJoYXBzIG9uZSBpbiB3aGljaCBhIHVuaW9uIG9mIGFsbCBhdmFpbGFibGUgYWNjb3Vu dHMgZXhpc3RzIGFuZCB3aGljaCBwcmVzZW50cyBhbiBOVkZTIHRoYXQgYXBwZWFycyB0byBjb250 YWluIHN1YmRpcmVjdG9yaWVzIHRoYXQgY29udGFpbiB0aGUgTlZGUyBmb3IgYWxsIHN1cHBvcnRl ZCB2aXJ0dWFsIGhvc3RzLjwvdD4NCiAgICAgIDwvc2VjdGlvbj4NCiAgICAgIDxzZWN0aW9uIHRp dGxlPSJGRUFUIHJlc3BvbnNlIGZvciBIT1NUIGNvbW1hbmQiIHRvYz0iZGVmYXVsdCI+DQogICAg ICAgIDx0PldoZW4gcmVwbHlpbmcgdG8gdGhlIEZFQVQgY29tbWFuZCA8eHJlZiB0YXJnZXQ9IlJG QzIzODkiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4sIGEgc2VydmVyLUZUUCBw cm9jZXNzIHRoYXQgc3VwcG9ydHMgdGhlIEhPU1QgY29tbWFuZCBNVVNUIGluY2x1ZGUgYSBsaW5l IGNvbnRhaW5pbmcgdGhlIHNpbmdsZSB3b3JkICJIT1NUIi4gIFRoaXMgd29yZCBpcyBjYXNlIGlu c2Vuc2l0aXZlLCBhbmQgTUFZIGJlIHNlbnQgaW4gYW55IG1peHR1cmUgb2YgdXBwZXIgb3IgbG93 ZXIgY2FzZSwgaG93ZXZlciBpdCBTSE9VTEQgYmUgc2VudCBpbiB1cHBlciBjYXNlLiAgVGhhdCBp cywgdGhlIHJlc3BvbnNlIFNIT1VMRCBiZTo8L3Q+DQogICAgICAgIDx0Pg0KICAgICAgICAgIDxm aWd1cmUgdGl0bGU9IiIgc3VwcHJlc3MtdGl0bGU9ImZhbHNlIiBhbGlnbj0ibGVmdCIgYWx0PSIi IHdpZHRoPSIiIGhlaWdodD0iIj4NCiAgICAgICAgICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJl c2VydmUiIG5hbWU9IiIgdHlwZT0iIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdo dD0iIj48IVtDREFUQVsgICAgIEM+IEZFQVQNCiAgICAgUz4gMjExLSA8YW55IGRlc2NyaXB0aXZl IHRleHQ+DQogICAgIFM+ICAuLi4NCiAgICAgUz4gIEhPU1QNCiAgICAgUz4gIC4uLg0KICAgICBT PiAyMTEgRW5kXV0+PC9hcnR3b3JrPg0KICAgICAgICAgIDwvZmlndXJlPg0KICAgICAgICA8L3Q+ DQogICAgICAgIDx0PlRoZSBlbGxpcHNlcyBpbmRpY2F0ZSBwbGFjZSBob2xkZXJzIHdoZXJlIG90 aGVyIGZlYXR1cmVzIG1heSBiZSBpbmNsdWRlZCwgYW5kIGFyZSBub3QgcmVxdWlyZWQuICBUaGUg b25lLXNwYWNlIGluZGVudGF0aW9uIG9mIHRoZSBmZWF0dXJlIGxpbmVzIGlzIG1hbmRhdG9yeSA8 eHJlZiB0YXJnZXQ9IlJGQzIzODkiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4u PC90Pg0KICAgICAgPC9zZWN0aW9uPg0KICAgIDwvc2VjdGlvbj4NCiAgICA8c2VjdGlvbiBhbmNo b3I9IlNlY3VyaXR5IiB0aXRsZT0iU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiIHRvYz0iZGVmYXVs dCI+DQogICAgICA8dD5BcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiAzIG9mIHRoaXMgZG9jdW1lbnQs IGEgc2VydmVyIGltcGxlbWVudGF0aW9uIE1VU1QgdHJlYXQgYSBIT1NUIGNvbW1hbmQgdGhhdCB3 YXMgc2VudCBiZWZvcmUgYSB1c2VyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgYXMgdGhvdWdoIGEg UkVJTiBjb21tYW5kIHdhcyBzZW50LCBhbmQgYSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gTUFZIHRy ZWF0IGEgSE9TVCBjb21tYW5kIHRoYXQgd2FzIHNlbnQgYWZ0ZXIgYSB1c2VyIGhhcyBiZWVuIGF1 dGhlbnRpY2F0ZWQgYXMgdGhvdWdoIGEgUkVJTiBjb21tYW5kIHdhcyBzZW50LiAgSW4gZWl0aGVy IG9mIHRoZXNlIHNjZW5hcmlvcywgdGhlIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBNVVNUIHJlc2V0 IHRoZSBhdXRoZW50aWNhdGlvbiBlbnZpcm9ubWVudCwgYXMgdGhhdCB3b3VsZCBhbGxvdyBmb3Ig c2VncmVnYXRpb24gYmV0d2VlbiB0aGUgc2VjdXJpdHkgZW52aXJvbm1lbnRzIGZvciBlYWNoIHZp cnR1YWwgaG9zdCBvbiBhbiBGVFAgc2VydmVyLiAgVGhlIGltcGxlbWVudGF0aW9uIGRldGFpbHMg Zm9yIHNlY3VyaXR5IGVudmlyb25tZW50cyBtYXkgdmFyeSBncmVhdGx5IGJhc2VkIG9uIHRoZSBy ZXF1aXJlbWVudHMgb2YgZWFjaCBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGluZyBz eXN0ZW0sIGFuZCB0aG9zZSBkZXRhaWxzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgcHJv dG9jb2wgaXRzZWxmLiAgRm9yIGV4YW1wbGUsIGEgdmlydHVhbCBob3N0ICJmb28uZXhhbXBsZS5j b20iIG9uIGFuIEZUUCBzZXJ2ZXIgbWlnaHQgdXNlIGEgc3BlY2lmaWMgdXNlcm5hbWUgYW5kIHBh c3N3b3JkIGxpc3QsIHdoaWxlIHRoZSB2aXJ0dWFsIGhvc3QgImJhci5leGFtcGxlLmNvbSIgb24g dGhlIHNhbWUgRlRQIHNlcnZlciBtaWdodCB1c2UgYSBkaWZmZXJlbnQgdXNlcm5hbWUgYW5kIHBh c3N3b3JkIGxpc3QuICBJbiBzdWNoIGEgc2NlbmFyaW8sIHJlc2V0dGluZyB0aGUgc2VjdXJpdHkg ZW52aXJvbm1lbnQgaXMgbmVjZXNzYXJ5IGZvciB0aGUgdmlydHVhbCBzZXJ2ZXJzIHRvIGFwcGVh ciB0byBiZWhhdmUgaW5kZXBlbmRlbnRseSBmcm9tIGEgY2xpZW50IHBlcnNwZWN0aXZlLCB3aGls ZSB0aGUgYWN0dWFsIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIGFyZSBpcnJlbGV2YW50 IGF0IHRoZSBwcm90b2NvbCBsZXZlbC48L3Q+DQogICAgICA8dD5TZWN0aW9uIDE1LjEuMSBvZiA8 eHJlZiB0YXJnZXQ9IlJGQzQyMTciIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4g ZGlzY3Vzc2VzIHRoZSB1c2Ugb2YgWC41MDkgY2VydGlmaWNhdGVzIGZvciBzZXJ2ZXIgYXV0aGVu dGljYXRpb24uIFRha2luZyB0aGUgaW5mb3JtYXRpb24gZnJvbSB0aGF0IGRvY3VtZW50IGludG8g YWNjb3VudCwgd2hlbiBzZWN1cmluZyBGVFAgc2Vzc2lvbnMgd2l0aCB0aGUgc2VjdXJpdHkgbWVj aGFuaXNtcyB0aGF0IGFyZSBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0iUkZDNDIxNyIgcGFnZW5v PSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPiwgY2xpZW50IGltcGxlbWVudGF0aW9ucyBTSE9V TEQgdmVyaWZ5IHRoYXQgdGhlIGhvc3RuYW1lIHRoZXkgc3BlY2lmeSBpbiB0aGUgcGFyYW1ldGVy IGZvciB0aGUgSE9TVCBjb21tYW5kIG1hdGNoZXMgdGhlIGlkZW50aXR5IHRoYXQgaXMgc3BlY2lm aWVkIGluIHRoZSBzZXJ2ZXIncyBYLjUwOSBjZXJ0aWZpY2F0ZSBpbiBvcmRlciB0byBwcmV2ZW50 IG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MuPC90Pg0KICAgICAgPHQ+QSBnZW5lcmFsIGRpc2N1 c3Npb24gb2YgaXNzdWVzIHJlbGF0ZWQgdG8gdGhlIHNlY3VyaXR5IG9mIEZUUCBjYW4gYmUgZm91 bmQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyNTc3IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1 bHQiIC8+LjwvdD4NCiAgICA8L3NlY3Rpb24+DQogICAgPHNlY3Rpb24gYW5jaG9yPSJJQU5BIiB0 aXRsZT0iSUFOQSBDb25zaWRlcmF0aW9ucyIgdG9jPSJkZWZhdWx0Ij4NCiAgICAgIDx0PklBTkEg aXMgcmVxdWVzdGVkIHRvIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcgRlRQIGV4dGVuc2lvbiBhY2Nv cmRpbmcgdG8gdGhlIHByb2NlZHVyZSBlc3RhYmxpc2hlZCBieSA8eHJlZiB0YXJnZXQ9IlJGQzU3 OTciIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCI+PC94cmVmPjo8L3Q+DQogICAgICA8 dGV4dHRhYmxlIHRpdGxlPSIiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249ImNlbnRlciIg c3R5bGU9ImZ1bGwiPg0KICAgICAgICA8dHRjb2wgYWxpZ249ImxlZnQiPmNtZDwvdHRjb2w+DQog ICAgICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+RkVBVA0KQ29kZTwvdHRjb2w+DQogICAgICAgIDx0 dGNvbCBhbGlnbj0ibGVmdCI+ZGVzY3JpcHRpb248L3R0Y29sPg0KICAgICAgICA8dHRjb2wgYWxp Z249ImxlZnQiPnR5cGU8L3R0Y29sPg0KICAgICAgICA8dHRjb2wgYWxpZ249ImxlZnQiPmNvbmY8 L3R0Y29sPg0KICAgICAgICA8dHRjb2wgYWxpZ249ImxlZnQiPlJGQyNzL1JlZmVyZW5jZXMNCmFu ZCBOb3RlczwvdHRjb2w+DQogICAgICAgIDxjPkhPU1Q8L2M+DQogICAgICAgIDxjPkhPU1Q8L2M+ DQogICAgICAgIDxjPkhvc3RuYW1lPC9jPg0KICAgICAgICA8Yz5hPC9jPg0KICAgICAgICA8Yz5v PC9jPg0KICAgICAgICA8Yz5UQkQ8L2M+DQogICAgICAgIDxwb3N0YW1ibGU+Tk9URSBUTyBSRkMg RURJVE9SOiBQbGVhc2UgdXBkYXRlIFRCRCBpbiB0aGUgYWJvdmUgdGFibGUgd2l0aCB0aGUgbnVt YmVyIG9mIHRoaXMgZG9jdW1lbnQuPC9wb3N0YW1ibGU+DQogICAgICA8L3RleHR0YWJsZT4NCiAg ICA8L3NlY3Rpb24+DQogIDwvbWlkZGxlPg0KICA8YmFjaz4NCiAgICA8cmVmZXJlbmNlcyB0aXRs ZT0iTm9ybWF0aXZlIFJlZmVyZW5jZXMiPg0KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlJGQzA5 NTkiPg0KICAgICAgICA8ZnJvbnQ+DQogICAgICAgICAgPHRpdGxlPkZpbGUgVHJhbnNmZXIgUHJv dG9jb2wgKEZUUCk8L3RpdGxlPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IkouIiBzdXJu YW1lPSJQb3N0ZWwiPjwvYXV0aG9yPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IkouIiBz dXJuYW1lPSJSZXlub2xkcyI+PC9hdXRob3I+DQogICAgICAgICAgPGRhdGUgeWVhcj0iMTk4NSIg bW9udGg9Ik9jdG9iZXIiIC8+DQogICAgICAgIDwvZnJvbnQ+DQogICAgICAgIDxzZXJpZXNJbmZv IG5hbWU9IlNURCIgdmFsdWU9IjkiIC8+DQogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlJGQyIg dmFsdWU9Ijk1OSIgLz4NCiAgICAgIDwvcmVmZXJlbmNlPg0KICAgICAgPHJlZmVyZW5jZSBhbmNo b3I9IlJGQzEwMzQiPg0KICAgICAgICA8ZnJvbnQ+DQogICAgICAgICAgPHRpdGxlPkRvbWFpbiBO YW1lcyAtIENvbmNlcHRzIGFuZCBGYWNpbGl0aWVzPC90aXRsZT4NCiAgICAgICAgICA8YXV0aG9y IGluaXRpYWxzPSJQLiIgc3VybmFtZT0iTW9ja2FwZXRyaXMiPjwvYXV0aG9yPg0KICAgICAgICAg IDxkYXRlIHllYXI9IjE5ODciIG1vbnRoPSJOb3ZlbWJlciI+PC9kYXRlPg0KICAgICAgICA8L2Zy b250Pg0KICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJTVEQiIHZhbHVlPSIxMyIgLz4NCiAgICAg ICAgPHNlcmllc0luZm8gbmFtZT0iUkZDIiB2YWx1ZT0iMTAzNCIgLz4NCiAgICAgIDwvcmVmZXJl bmNlPg0KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlJGQzEwMzUiPg0KICAgICAgICA8ZnJvbnQ+ DQogICAgICAgICAgPHRpdGxlPkRvbWFpbiBOYW1lcyAtIEltcGxlbWVudGF0aW9uIGFuZCBTcGVj aWZpY2F0aW9uPC90aXRsZT4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJQLiIgc3VybmFt ZT0iTW9ja2FwZXRyaXMiPjwvYXV0aG9yPg0KICAgICAgICAgIDxkYXRlIHllYXI9IjE5ODciIG1v bnRoPSJOb3ZlbWJlciI+PC9kYXRlPg0KICAgICAgICA8L2Zyb250Pg0KICAgICAgICA8c2VyaWVz SW5mbyBuYW1lPSJTVEQiIHZhbHVlPSIxMyIgLz4NCiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0i UkZDIiB2YWx1ZT0iMTAzNSIgLz4NCiAgICAgIDwvcmVmZXJlbmNlPg0KICAgICAgPHJlZmVyZW5j ZSBhbmNob3I9IlJGQzExMjMiPg0KICAgICAgICA8ZnJvbnQ+DQogICAgICAgICAgPHRpdGxlPlJl cXVpcmVtZW50cyBmb3IgSW50ZXJuZXQgSG9zdHMgLS0gQXBwbGljYXRpb24gYW5kIFN1cHBvcnQ8 L3RpdGxlPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IlIuIiBzdXJuYW1lPSJCcmFkZW4i IC8+DQogICAgICAgICAgPGRhdGUgeWVhcj0iMTk4OSIgbW9udGg9Ik9jdG9iZXIiIC8+DQogICAg ICAgIDwvZnJvbnQ+DQogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlNURCIgdmFsdWU9IjMiIC8+ DQogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlJGQyIgdmFsdWU9IjExMjMiIC8+DQogICAgICA8 L3JlZmVyZW5jZT4NCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJSRkMyMTE5Ij4NCiAgICAgICAg PGZyb250Pg0KICAgICAgICAgIDx0aXRsZT5LZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlIFJlcXVpcmVtZW50IExldmVsczwvdGl0bGU+DQogICAgICAgICAgPGF1dGhvciBpbml0 aWFscz0iUy4iIHN1cm5hbWU9IkJyYWRuZXIiPjwvYXV0aG9yPg0KICAgICAgICAgIDxkYXRlIHll YXI9IjE5OTciIG1vbnRoPSJNYXJjaCIgLz4NCiAgICAgICAgPC9mcm9udD4NCiAgICAgICAgPHNl cmllc0luZm8gbmFtZT0iQkNQIiB2YWx1ZT0iMTQiIC8+DQogICAgICAgIDxzZXJpZXNJbmZvIG5h bWU9IlJGQyIgdmFsdWU9IjIxMTkiIC8+DQogICAgICA8L3JlZmVyZW5jZT4NCiAgICAgIDxyZWZl cmVuY2UgYW5jaG9yPSJSRkMyMjI4Ij4NCiAgICAgICAgPGZyb250Pg0KICAgICAgICAgIDx0aXRs ZT5GVFAgU2VjdXJpdHkgRXh0ZW5zaW9uczwvdGl0bGU+DQogICAgICAgICAgPGF1dGhvciBpbml0 aWFscz0iTS4iIHN1cm5hbWU9Ikhvcm93aXR6Ij48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9y IGluaXRpYWxzPSJTLiIgc3VybmFtZT0iTHVudCI+PC9hdXRob3I+DQogICAgICAgICAgPGRhdGUg eWVhcj0iMTk5NyIgbW9udGg9Ik9jdG9iZXIiIC8+DQogICAgICAgIDwvZnJvbnQ+DQogICAgICAg IDxzZXJpZXNJbmZvIG5hbWU9IlJGQyIgdmFsdWU9IjIyMjgiIC8+DQogICAgICA8L3JlZmVyZW5j ZT4NCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJSRkMyMzg5Ij4NCiAgICAgICAgPGZyb250Pg0K ICAgICAgICAgIDx0aXRsZT5GZWF0dXJlIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBmb3IgdGhlIEZp bGUgVHJhbnNmZXIgUHJvdG9jb2w8L3RpdGxlPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9 IlAuIiBzdXJuYW1lPSJIZXRobW9uIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGluaXRp YWxzPSJSLiIgc3VybmFtZT0iRWx6Ij48L2F1dGhvcj4NCiAgICAgICAgICA8ZGF0ZSB5ZWFyPSIx OTk4IiBtb250aD0iQXVndXN0IiAvPg0KICAgICAgICA8L2Zyb250Pg0KICAgICAgICA8c2VyaWVz SW5mbyBuYW1lPSJSRkMiIHZhbHVlPSIyMzg5IiAvPg0KICAgICAgPC9yZWZlcmVuY2U+DQogICAg ICA8cmVmZXJlbmNlIGFuY2hvcj0iUkZDMjY0MCI+DQogICAgICAgIDxmcm9udD4NCiAgICAgICAg ICA8dGl0bGU+SW50ZXJuYXRpb25hbGl6YXRpb24gb2YgdGhlIEZpbGUgVHJhbnNmZXIgUHJvdG9j b2w8L3RpdGxlPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IlcuIiBzdXJuYW1lPSJDdXJ0 aW4iPjwvYXV0aG9yPg0KICAgICAgICAgIDxkYXRlIHllYXI9IjE5OTkiIG1vbnRoPSJKdWx5IiAv Pg0KICAgICAgICA8L2Zyb250Pg0KICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJSRkMiIHZhbHVl PSIyNjQwIiAvPg0KICAgICAgPC9yZWZlcmVuY2U+DQogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0i UkZDMzQ5MiI+DQogICAgICAgIDxmcm9udD4NCiAgICAgICAgICA8dGl0bGU+UHVueWNvZGU6IEEg Qm9vdHN0cmluZyBlbmNvZGluZyBvZiBVbmljb2RlIGZvciBJbnRlcm5hdGlvbmFsaXplZCBEb21h aW4gTmFtZXMgaW4gQXBwbGljYXRpb25zIChJRE5BKTwvdGl0bGU+DQogICAgICAgICAgPGF1dGhv ciBpbml0aWFscz0iQS4iIHN1cm5hbWU9IkNvc3RlbGxvIj48L2F1dGhvcj4NCiAgICAgICAgICA8 ZGF0ZSB5ZWFyPSIyMDAzIiBtb250aD0iTWFyY2giIC8+DQogICAgICAgIDwvZnJvbnQ+DQogICAg ICAgIDxzZXJpZXNJbmZvIG5hbWU9IlJGQyIgdmFsdWU9IjM0OTIiIC8+DQogICAgICA8L3JlZmVy ZW5jZT4NCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJSRkM0MjE3Ij4NCiAgICAgICAgPGZyb250 Pg0KICAgICAgICAgIDx0aXRsZT5TZWN1cmluZyBGVFAgd2l0aCBUTFM8L3RpdGxlPg0KICAgICAg ICAgIDxhdXRob3IgaW5pdGlhbHM9IlAuIiBzdXJuYW1lPSJGb3JkLUh1dGNoaW5zb24iPjwvYXV0 aG9yPg0KICAgICAgICAgIDxkYXRlIHllYXI9IjIwMDUiIG1vbnRoPSJPY3RvYmVyIiAvPg0KICAg ICAgICA8L2Zyb250Pg0KICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJSRkMiIHZhbHVlPSI0MjE3 IiAvPg0KICAgICAgPC9yZWZlcmVuY2U+DQogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iUkZDNTIz NCI+DQogICAgICAgIDxmcm9udD4NCiAgICAgICAgICA8dGl0bGU+QXVnbWVudGVkIEJORiBmb3Ig U3ludGF4IFNwZWNpZmljYXRpb25zOiBBQk5GPC90aXRsZT4NCiAgICAgICAgICA8YXV0aG9yIGlu aXRpYWxzPSJELiIgc3VybmFtZT0iQ3JvY2tlciI+PC9hdXRob3I+DQogICAgICAgICAgPGF1dGhv ciBpbml0aWFscz0iUC4iIHN1cm5hbWU9Ik92ZXJlbGwiPjwvYXV0aG9yPg0KICAgICAgICAgIDxk YXRlIHllYXI9IjIwMDgiIG1vbnRoPSJKYW51YXJ5IiAvPg0KICAgICAgICA8L2Zyb250Pg0KICAg ICAgICA8c2VyaWVzSW5mbyBuYW1lPSJSRkMiIHZhbHVlPSI1MjM0IiAvPg0KICAgICAgPC9yZWZl cmVuY2U+DQogICAgPC9yZWZlcmVuY2VzPg0KICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJJbmZvcm1h dGl2ZSBSZWZlcmVuY2VzIj4NCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJSRkMxOTQ1Ij4NCiAg ICAgICAgPGZyb250Pg0KICAgICAgICAgIDx0aXRsZT5IeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9j b2wgLS0gSFRUUC8xLjA8L3RpdGxlPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IlQuIiBz dXJuYW1lPSJCZXJuZXJzLUxlZSI+PC9hdXRob3I+DQogICAgICAgICAgPGF1dGhvciBpbml0aWFs cz0iUi4iIHN1cm5hbWU9IkZpZWxkaW5nIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGlu aXRpYWxzPSJILiIgc3VybmFtZT0iRnJ5c3R5ayI+PC9hdXRob3I+DQogICAgICAgICAgPGRhdGUg eWVhcj0iMTk5NiIgbW9udGg9Ik1heSIgLz4NCiAgICAgICAgPC9mcm9udD4NCiAgICAgICAgPHNl cmllc0luZm8gbmFtZT0iUkZDIiB2YWx1ZT0iMTk0NSIgLz4NCiAgICAgIDwvcmVmZXJlbmNlPg0K ICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlJGQzI1NzciPg0KICAgICAgICA8ZnJvbnQ+DQogICAg ICAgICAgPHRpdGxlPkZUUCBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvdGl0bGU+DQogICAgICAg ICAgPGF1dGhvciBpbml0aWFscz0iTS4iIHN1cm5hbWU9IkFsbG1hbiI+PC9hdXRob3I+DQogICAg ICAgICAgPGF1dGhvciBpbml0aWFscz0iUy4iIHN1cm5hbWU9Ik9zdGVybWFubiI+PC9hdXRob3I+ DQogICAgICAgICAgPGRhdGUgeWVhcj0iMTk5OSIgbW9udGg9Ik1heSIgLz4NCiAgICAgICAgPC9m cm9udD4NCiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iUkZDIiB2YWx1ZT0iMjU3NyIgLz4NCiAg ICAgIDwvcmVmZXJlbmNlPg0KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlJGQzI2MTYiPg0KICAg ICAgICA8ZnJvbnQ+DQogICAgICAgICAgPHRpdGxlPkh5cGVydGV4dCBUcmFuc2ZlciBQcm90b2Nv bCAtLSBIVFRQLzEuMTwvdGl0bGU+DQogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iUi4iIHN1 cm5hbWU9IkZpZWxkaW5nIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJK LiIgc3VybmFtZT0iR2V0dHlzIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxz PSJKLiIgc3VybmFtZT0iTW9ndWwiPjwvYXV0aG9yPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlh bHM9IkguIiBzdXJuYW1lPSJGcnlzdHlrIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGlu aXRpYWxzPSJMLiIgc3VybmFtZT0iTWFzaW50ZXIiPjwvYXV0aG9yPg0KICAgICAgICAgIDxhdXRo b3IgaW5pdGlhbHM9IlAuIiBzdXJuYW1lPSJMZWFjaCI+PC9hdXRob3I+DQogICAgICAgICAgPGF1 dGhvciBpbml0aWFscz0iVC4iIHN1cm5hbWU9IkJlcm5lcnMtTGVlIj48L2F1dGhvcj4NCiAgICAg ICAgICA8ZGF0ZSB5ZWFyPSIxOTk5IiBtb250aD0iSnVuZSIgLz4NCiAgICAgICAgPC9mcm9udD4N CiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iUkZDIiB2YWx1ZT0iMjYxNiIgLz4NCiAgICAgIDwv cmVmZXJlbmNlPg0KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlJGQzU3OTciPg0KICAgICAgICA8 ZnJvbnQ+DQogICAgICAgICAgPHRpdGxlPkZUUCBDb21tYW5kIGFuZCBFeHRlbnNpb24gUmVnaXN0 cnk8L3RpdGxlPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IkouIiBzdXJuYW1lPSJLbGVu c2luIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJBLiIgc3VybmFtZT0i SG9lbmVzIj48L2F1dGhvcj4NCiAgICAgICAgICA8ZGF0ZSBtb250aD0iTWFyY2giIHllYXI9IjIw MTAiIC8+DQogICAgICAgIDwvZnJvbnQ+DQogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlJGQyIg dmFsdWU9IjU3OTciIC8+DQogICAgICA8L3JlZmVyZW5jZT4NCiAgICA8L3JlZmVyZW5jZXM+DQog ICAgPHNlY3Rpb24gdGl0bGU9IlVud29ya2FibGUgQWx0ZXJuYXRpdmVzIiB0b2M9ImRlZmF1bHQi Pg0KICAgICAgPHQ+RHVlIHRvIHRoZSBsZXZlbCBvZiBzY29wZSBmb3IgYWRkaW5nIGEgbmV3IGNv bW1hbmQgdG8gRlRQLCBhIGJyaWVmIGRpc2N1c3Npb24gb2Ygc3VnZ2VzdGVkIGFsdGVybmF0aXZl cyB0byBhIEhPU1QgY29tbWFuZCBhbmQgdGhlaXIgcmVzcGVjdGl2ZSBsaW1pdGF0aW9ucyBpcyB3 YXJyYW50ZWQuICBUaGUgc3VnZ2VzdGVkIGFsdGVybmF0aXZlcyB0aGF0IGFyZSBkaXNjdXNzZWQg aW4gdGhpcyBhcHBlbmRpeCBoYXZlIGJlZW4gcHJvcG9zZWQgaW4gdGhlIHBhc3QsIGJ1dCBlYWNo IG9mIHRoZXNlIGlkZWFzIHdhcyBkZWVtZWQgaW5zdWZmaWNpZW50IGZvciB0aGUgcmVhc29ucyB0 aGF0IGFyZSBsaXN0ZWQgd2l0aGluIGVhY2ggc2VjdGlvbiBvZiB0aGUgYXBwZW5kaXguPC90Pg0K ICAgICAgPHNlY3Rpb24gdGl0bGU9Ik92ZXJsb2FkaW5nIHRoZSBDV0QgY29tbWFuZCIgdG9jPSJk ZWZhdWx0Ij4NCiAgICAgICAgPHQ+T25lIHN1Z2dlc3RlZCBtZXRob2QgdG8gZW11bGF0ZSBhIGZv cm0gb2YgdmlydHVhbCBob3N0cyB3b3VsZCBiZSBmb3IgdGhlIGNsaWVudCB0byBzaW1wbHkgc2Vu ZCBhICJDV0QiIGNvbW1hbmQgYWZ0ZXIgY29ubmVjdGluZywgdXNpbmcgdGhlIHZpcnR1YWwgaG9z dCBuYW1lIGFzIHRoZSBhcmd1bWVudCB0byB0aGUgQ1dEIGNvbW1hbmQuICBUaGlzIHdvdWxkIGFs bG93IHRoZSBzZXJ2ZXItRlRQIHByb2Nlc3MgdG8gaW1wbGVtZW50IHRoZSBmaWxlIHN0b3JlcyBv ZiB0aGUgdmlydHVhbCBob3N0cyBhcyBzdWItZGlyZWN0b3JpZXMgaW4gaXRzIE5WRlMuICBUaGlz IHN1Z2dlc3Rpb24gaXMgc2ltcGxlIGluIGNvbmNlcHQsIGFuZCBtb3N0IHNlcnZlci1GVFAgaW1w bGVtZW50YXRpb25zIHN1cHBvcnQgdGhpcyB3aXRob3V0IHJlcXVpcmluZyBhbnkgY29kZSBjaGFu Z2VzLiAgV2hpbGUgdGhpcyBtZXRob2QgaXMgc2ltcGxlIHRvIGRlc2NyaWJlLCBhbmQgdG8gaW1w bGVtZW50LCBpdCBzdWZmZXJzIGZyb20gc2V2ZXJhbCBkcmF3YmFja3M6PC90Pg0KICAgICAgICA8 dD4NCiAgICAgICAgICA8bGlzdCBzdHlsZT0ibGV0dGVycyI+DQogICAgICAgICAgICA8dD5UaGUg IkNXRCIgY29tbWFuZCBpcyBhdmFpbGFibGUgb25seSBhZnRlciB0aGUgdXNlci1QSSBoYXMgYXV0 aGVudGljYXRlZCBpdHNlbGYgdG8gdGhlIHNlcnZlci1GVFAgcHJvY2Vzcy4gIFRodXMsIGFsbCB2 aXJ0dWFsIGhvc3RzIHdvdWxkIGJlIHJlcXVpcmVkIHRvIHNoYXJlIGEgY29tbW9uIGF1dGhlbnRp Y2F0aW9uIHNjaGVtZSBpZiB0aGV5IHVzZWQgdGhpcyBtZXRob2QuPC90Pg0KICAgICAgICAgICAg PHQ+VG8gbWFrZSB0aGUgdmlydHVhbCBob3N0IHRydWx5IHRyYW5zcGFyZW50LCBlaXRoZXIgdGhl IHNlcnZlci1GVFAgcHJvY2VzcyBuZWVkcyB0byBiZSBtb2RpZmllZCB0byBpbmNsdWRlIGluZm9y bWF0aW9uIHRoYXQgc2hvd3MgdGhlIHNwZWNpYWwgbmF0dXJlIG9mIHRoaXMgZmlyc3QgQ1dEIGNv bW1hbmQgKG5lZ2F0aW5nIG1vc3Qgb2YgdGhlIGFkdmFudGFnZSBvZiB0aGlzIHNjaGVtZSksIG9y IGFsbCB1c2VycyBtdXN0IHNlZSB0aGUgc2FtZSBpZGVudGljYWwgTlZGUyB2aWV3IHVwb24gY29u bmVjdGluZyAodGhleSBtdXN0IGNvbm5lY3QgaW4gdGhlIHNhbWUgaW5pdGlhbCBkaXJlY3Rvcnkp LCBvciB0aGUgTlZGUyBtdXN0IGltcGxlbWVudCB0aGUgZnVsbCBzZXQgb2YgdmlydHVhbCBob3N0 IGRpcmVjdG9yaWVzIGF0IGVhY2ggcG9zc2libGUgaW5pdGlhbCBkaXJlY3RvcnkgZm9yIGFueSBw b3NzaWJsZSB1c2VyLjwvdD4NCiAgICAgICAgICAgIDx0PlVubGVzcyB0aGUgc2VydmVyIGlzIHNw ZWNpYWxseSBtb2RpZmllZCwgYSB1c2VyIGNvbm5lY3RpbmcgdGhpcyB3YXkgdG8gYSB2aXJ0dWFs IGhvc3Qgd291bGQgYmUgYWJsZSB0byBlYXNpbHkgbW92ZSB0byBhbnkgb3RoZXIgdmlydHVhbCBo b3N0IHN1cHBvcnRlZCBhdCB0aGUgc2FtZSBzZXJ2ZXItRlRQIHByb2Nlc3MsIGV4cG9zaW5nIHRo ZSBuYXR1cmUgb2YgdGhlIHZpcnR1YWwgaG9zdC48L3Q+DQogICAgICAgICAgPC9saXN0Pg0KICAg ICAgICA8L3Q+DQogICAgICA8L3NlY3Rpb24+DQogICAgICA8c2VjdGlvbiB0aXRsZT0iT3Zlcmxv YWRpbmcgdGhlIEFDQ1QgY29tbWFuZCIgdG9jPSJkZWZhdWx0Ij4NCiAgICAgICAgPHQ+QW5vdGhl ciBzdWdnZXN0ZWQgbWV0aG9kIHdvdWxkIGJlIHRvIHNpbXBseSBvdmVybG9hZCB0aGUgIkFDQ1Qi IGZvciBGVFAgdmlydHVhbCBob3N0cywgYnV0IHRoaXMgcHJvcG9zYWwgaXMgdW5hY2NlcHRhYmxl IGZvciBzZXZlcmFsIHJlYXNvbnMgd2l0aCByZWdhcmQgdG8gd2hlbiB0aGUgQUNDVCBjb21tYW5k IGlzIHNlbnQgZHVyaW5nIHRoZSByZXF1ZXN0IGZsb3cuICBTZWN0aW9ucyA1LjQgYW5kIDYgb2Yg PHhyZWYgdGFyZ2V0PSJSRkMwOTU5IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+ IGRvY3VtZW50IHRoZSByZXF1ZXN0IGZsb3cgZm9yIGEgbG9naW4gc2VxdWVuY2UgYXMgVVNFUiAt Jmd0OyBQQVNTIC0mZ3Q7IEFDQ1QuICBUaGlzIGZsb3cgb2YgY29tbWFuZHMgbWF5IGJlIGFjY2Vw dGFibGUgd2hlbiB5b3UgYXJlIGNvbnNpZGVyaW5nIGEgc2luZ2xlIHVzZXIgaGF2aW5nIG11bHRp cGxlIGFjY291bnRzIG9uIGFuIEZUUCBzZXJ2ZXIsIGJ1dCBmYWlscyB0byBkaWZmZXJlbnRpYXRl IGJldHdlZW4gdmlydHVhbCBob3N0cyB3aGVuIHlvdSBjb25zaWRlciB0aGUgZm9sbG93aW5nIHR3 byBpc3N1ZXM6PC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICA8bGlzdCBzdHlsZT0ibGV0dGVy cyI+DQogICAgICAgICAgICA8dD5UaGUgZmlyc3QgcHJvYmxlbSB3aXRoIG92ZXJsb2FkaW5nIHRo ZSBBQ0NUIGNvbW1hbmQgaXMgY2VydGlmaWNhdGUgbmVnb3RpYXRpb24gd2hlbiB1c2luZyB0aGUg RlRQIHNlY3VyaXR5IGV4dGVuc2lvbnMgdGhhdCBhcmUgZG9jdW1lbnRlZCBpbiA8eHJlZiB0YXJn ZXQ9IlJGQzIyMjgiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4gYW5kIDx4cmVm IHRhcmdldD0iUkZDNDIxNyIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPi4gIElu IG9yZGVyIHRvIHNhZmVndWFyZCB1c2VyIGNyZWRlbnRpYWxzLCBzZWN1cml0eSBtZWNoYW5pc20g YW5kIGNlcnRpZmljYXRlIG5lZ290aWF0aW9uIG11c3Qgb2NjdXIgYmVmb3JlIGxvZ2luIGNyZWRl bnRpYWxzIGFyZSBzZW50IGJ5IHRoZSBjbGllbnQuICBUaGUgcHJvYmxlbSB3aXRoIHVzaW5nIHRo ZSBBQ0NUIGNvbW1hbmQgaW4gdGhpcyBzY2VuYXJpbyBpcyB0aGF0IHRoZXJlIGlzIG5vIHdheSBv ZiBlbnN1cmluZyB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBtYXRjaGVzIHRoZSBjb3JyZWN0IHZpcnR1 YWwgaG9zdCBiZWZvcmUgdGhlIHVzZXIgY3JlZGVudGlhbHMgYXJlIHNlbnQuPC90Pg0KICAgICAg ICAgICAgPHQ+VGhlIHNlY29uZCBwcm9ibGVtIHdpdGggb3ZlcmxvYWRpbmcgdGhlIEFDQ1QgY29t bWFuZCBpcyBob3cgdXNlciBjcmVkZW50aWFscyBhcmUgaW1wbGVtZW50ZWQgZm9yIEZUUCB2aXJ0 dWFsIGhvc3RzLiAgRlRQIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgbWF5IGFsbG93IHRoZSB1c2Ug b2YgY3VzdG9tIHVzZXIgY3JlZGVudGlhbHMgb24gYSBwZXItdmlydHVhbC1ob3N0IGJhc2lzLiAg Rm9yIGV4YW1wbGUsIGluIG9uZSBwYXJ0aWN1bGFyIGltcGxlbWVudGF0aW9uIHRoZSB2aXJ0dWFs IGhvc3QgbmVnb3RpYXRpb24gb2NjdXJzLCBhbmQgdGhlbiB0aGUgdXNlciBjcmVkZW50aWFscyBh cmUgbG9va2VkIHVwIHVzaW5nIHRoZSBhY2NvdW50IG1lY2hhbmlzbSB0aGF0IGlzIHNwZWNpZmlj IHRvIHRoYXQgdmlydHVhbCBob3N0LiAgU28gb25jZSBhZ2FpbiB0aGUgdmlydHVhbCBob3N0IG5l Z290aWF0aW9uIG11c3QgdGFrZSBwbGFjZSBiZWZvcmUgdGhlIHVzZXIgY3JlZGVudGlhbHMgYXJl IHNlbnQuPC90Pg0KICAgICAgICAgIDwvbGlzdD4NCiAgICAgICAgPC90Pg0KICAgICAgPC9zZWN0 aW9uPg0KICAgICAgPHNlY3Rpb24gdGl0bGU9Ik92ZXJsb2FkaW5nIHRoZSBVU0VSIGNvbW1hbmQi IHRvYz0iZGVmYXVsdCI+DQogICAgICAgIDx0PkFuIGFkZGl0aW9uYWwgc3VnZ2VzdGlvbiB3b3Vs ZCBiZSB0byBvdmVybG9hZCB3ZWxsLWtub3duIHN5bnRheCB0aHJvdWdoIHRoZSBleGlzdGluZyBV U0VSIGNvbW1hbmQsIGFzIGlsbHVzdHJhdGVkIGluIHRoZSBmb2xsb3dpbmcgZXhhbXBsZTo8L3Q+ DQogICAgICAgIDx0Pg0KICAgICAgICAgIDxmaWd1cmUgdGl0bGU9IiIgc3VwcHJlc3MtdGl0bGU9 ImZhbHNlIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj4NCiAgICAgICAg ICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJlc2VydmUiIG5hbWU9IiIgdHlwZT0iIiBhbGlnbj0i bGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj48IVtDREFUQVsgICAgIEM+IFVTRVIgZm9v QGV4YW1wbGUuY29tDQogICAgIFM+IDMzMSBQYXNzd29yZCByZXF1aXJlZA0KICAgICBDPiBQQVNT IGJhcg0KICAgICBTPiAyMzAgVXNlciBsb2dnZWQgaW5dXT48L2FydHdvcms+DQogICAgICAgICAg PC9maWd1cmU+DQogICAgICAgIDwvdD4NCiAgICAgICAgPHQ+SW4gdGhpcyBleGFtcGxlLCB0aGUg dXNlciAiZm9vIiBtaWdodCBiZSBhdHRlbXB0aW5nIHRvIGxvZyBvbiB0byB0aGUgdmlydHVhbCBo b3N0ICJleGFtcGxlLmNvbSIgb24gYW4gRlRQIHNlcnZlci4gIFRoaXMgc3VnZ2VzdGlvbiBtYXkg c2VlbSBwbGF1c2libGUgYXQgZmlyc3QsIGJ1dCBpbnRyb2R1Y2VzIHNldmVyYWwgaW1wbGVtZW50 YXRpb24gcHJvYmxlbXMuICBGb3IgZXhhbXBsZTo8L3Q+DQogICAgICAgIDx0Pg0KICAgICAgICAg IDxsaXN0IHN0eWxlPSJsZXR0ZXJzIj4NCiAgICAgICAgICAgIDx0PlNvbWUgbmV0d29yayBlbnZp cm9ubWVudHMgYWxyZWFkeSB1c2UgdGhlICJ1c2VybmFtZUBob3N0bmFtZSIgc3ludGF4IGZvciBu ZXR3b3JrIGNyZWRlbnRpYWxzLCB3aGVyZSB0aGUgImhvc3RuYW1lIiBwb3J0aW9uIHJlZmVycyB0 byB0aGUgbG9jYXRpb24gb2YgdGhlIHVzZXIncyBjcmVkZW50aWFscyB3aXRoaW4gdGhlIG5ldHdv cmsgaGllcmFyY2h5LiAgVXNpbmcgdGhlICJmb29AZXhhbXBsZS5jb20iIHN5bnRheCBpdCBiZWNv bWVzIGRpZmZpY3VsdCB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlIHVzZXIgImZvbyIgbG9n Z2luZyBpbnRvIGEgdmlydHVhbCBob3N0IG5hbWVkICJleGFtcGxlLmNvbSIgb24gYW4gRlRQIHNl cnZlciB2ZXJzdXMgdGhlIHVzZXIgImZvb0BleGFtcGxlLmNvbSIgbG9nZ2luZyBpbnRvIGFuIEZU UCBzZXJ2ZXIgd2l0aCBubyBzcGVjaWZpZWQgdmlydHVhbCBob3N0LjwvdD4NCiAgICAgICAgICAg IDx0PldoZW4gdXNpbmcgdGhlIEZUUCBzZWN1cml0eSBleHRlbnNpb25zIHRoYXQgYXJlIGRvY3Vt ZW50ZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMjI4IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRl ZmF1bHQiIC8+IGFuZCA8eHJlZiB0YXJnZXQ9IlJGQzQyMTciIHBhZ2Vubz0iZmFsc2UiIGZvcm1h dD0iZGVmYXVsdCIgLz4sIHNlY3VyaXR5IG1lY2hhbmlzbSBhbmQgY2VydGlmaWNhdGUgbmVnb3Rp YXRpb24gbXVzdCBvY2N1ciBiZWZvcmUgbG9naW4gY3JlZGVudGlhbHMgYXJlIHNlbnQgYnkgdGhl IGNsaWVudC4gIE1vcmUgc3BlY2lmaWNhbGx5LCB0aGUgQVVUSC9BREFUIGNvbW1hbmRzIG11c3Qg YmUgc2VudCBiZWZvcmUgdGhlIFVTRVIgY29tbWFuZCBpbiBvcmRlciB0byBzYWZlZ3VhcmQgdXNl ciBjcmVkZW50aWFscy4gIElmIHlvdSBvdmVybG9hZCB0aGUgVVNFUiBjb21tYW5kLCB0aGVyZSBp cyBubyB3YXkgb2YgZW5zdXJpbmcgdGhhdCB0aGUgY2VydGlmaWNhdGUgbWF0Y2hlcyB0aGUgY29y cmVjdCB2aXJ0dWFsIGhvc3QgYmVmb3JlIHRoZSB1c2VyIGNyZWRlbnRpYWxzIGFyZSBzZW50IGJ5 IHRoZSBjbGllbnQuPC90Pg0KICAgICAgICAgIDwvbGlzdD4NCiAgICAgICAgPC90Pg0KICAgICAg PC9zZWN0aW9uPg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IkNvbmNsdXNpb24iIHRvYz0iZGVmYXVs dCI+DQogICAgICAgIDx0PlRoZSBjb25jbHVzaW9uIGZyb20gdGhlIGV4YW1pbmF0aW9uIG9mIHRo ZSBleGlzdGluZyBwb3NzaWJpbGl0aWVzIHNlZW1zIHRvIGJlIHRoYXQgaW4gb3JkZXIgdG8gb2J0 YWluIGFuIGFkZXF1YXRlIGVtdWxhdGlvbiBvZiAicmVhbCIgRlRQIHNlcnZlcnMsIGNsaWVudCBh bmQgc2VydmVyIG1vZGlmaWNhdGlvbnMgdG8gc3VwcG9ydCB2aXJ0dWFsIGhvc3RzIGFyZSBuZWNl c3NhcnkuICBUaGVyZWZvcmUgYSBuZXcgRlRQIGNvbW1hbmQgc2VlbXMgdGhlIG1vc3QgbGlrZWx5 IHNvbHV0aW9uIHRvIHByb3ZpZGUgdGhlIHJlcXVpcmVkIGxldmVsIG9mIHN1cHBvcnQuPC90Pg0K ICAgICAgPC9zZWN0aW9uPg0KICAgIDwvc2VjdGlvbj4NCiAgICA8c2VjdGlvbiBhbmNob3I9IkFj a25vd2xlZGdlbWVudHMiIHRpdGxlPSJBY2tub3dsZWRnZW1lbnRzIiB0b2M9ImRlZmF1bHQiPg0K ICAgICAgPHQ+Um9iZXJ0IEVseiBhbmQgUGF1bCBIZXRobW9uIHByb3ZpZGVkIGEgZGV0YWlsZWQg ZGlzY3Vzc2lvbiBvZiB0aGUgSE9TVCBjb21tYW5kIGluIHRoZWlyIEludGVybmV0IGRyYWZ0IHRp dGxlZCAiRXh0ZW5zaW9ucyB0byBGVFAiIGFzIHBhcnQgb2YgdGhlaXIgd29yayB3aXRoIHRoZSBG VFBFWFQgV29ya2luZyBHcm91cCBhdCB0aGUgSUVURi4gIFRoZWlyIHdvcmsgZm9ybWVkIHRoZSBi YXNpcyBmb3IgbXVjaCBvZiB0aGlzIGRvY3VtZW50LCBhbmQgdGhlaXIgaGVscCBoYXMgYmVlbiBn cmVhdGx5IGFwcHJlY2lhdGVkLiAgVGhleSB3b3VsZCBhbHNvIGxpa2UgdG8gY3JlZGl0IEJlcm5o YXJkIFJvc2Vua3JhZW56ZXIgZm9yIGhhdmluZyBmaXJzdCBzdWdnZXN0ZWQgYW5kIGRlc2NyaWJl ZCB0aGUgSE9TVCBjb21tYW5kLjwvdD4NCiAgICAgIDx0PkFsZXhleSBNZWxuaWtvdiwgQWxmcmVk IEhvZW5lcywgSm9obiBLbGVuc2luLCBhbmQgSm9lIFRvdWNoIGhhdmUgbWFkZSBzZXZlcmFsIHN1 Z2dlc3Rpb25zIGFib3V0IGVhcmxpZXIgdmVyc2lvbnMgb2YgdGhpcyBkb2N1bWVudDsgbWFueSBv ZiB0aGVpciBzdWdnZXN0aW9ucyBoYXZlIGJlZW4gaW5jb3Jwb3JhdGVkLCBhbmQgdGhlaXIgY29u dHJpYnV0aW9ucyBhcmUgZ3JhdGVmdWxseSBhY2tub3dsZWRnZWQuICBJbiBhZGRpdGlvbiwgQWxl YyBSb3dlbGwncyBhc3Npc3RhbmNlIGluIG1ha2luZyBzZWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50 IG1vcmUgcmVhZGFibGUgd2FzIGludmFsdWFibGUuPC90Pg0KICAgIDwvc2VjdGlvbj4NCiAgPC9i YWNrPg0KPC9yZmM+ --_004_01AA9EC92749BF4894AC2B3039EA4A2C194A07E2CH1PRD0302MB131_-- From evnikita2@gmail.com Tue Jun 28 21:59:53 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC1321F86DB; Tue, 28 Jun 2011 21:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9oEpxRD3ndU; Tue, 28 Jun 2011 21:59:52 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4E61F21F86D7; Tue, 28 Jun 2011 21:59:52 -0700 (PDT) Received: by fxe4 with SMTP id 4so1129810fxe.27 for ; Tue, 28 Jun 2011 21:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bT12qsfFDGIusVWvm3Lqcc2vE/aWQLpkvYZqdQ9OcB0=; b=NDRFO4fpUuee8tX40H4GWKOTcdUHcQYCU7B8U+zgPr6S4Ypi6aw6SKSb4SdjfcuYTZ P7Nwu4mjsWF7agpA/Wx+MabvQ+vYFFPquh6WFuw72825cZei8V3WOEkCfitaW3YsmuEP lrb9t8XSmbVaUvIvR7VVy3IbiXdFX8BqY3h3U= Received: by 10.223.13.211 with SMTP id d19mr606399faa.67.1309323591371; Tue, 28 Jun 2011 21:59:51 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 7sm554465fat.42.2011.06.28.21.59.48 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 21:59:49 -0700 (PDT) Message-ID: <4E0AB172.4030005@gmail.com> Date: Wed, 29 Jun 2011 08:00:34 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Daniel Stenberg References: <4E094D8D.8090001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "uri-review@ietf.org" , "ftpext@ietf.org" , URI Subject: Re: [ftpext] FWD: New Version Notification for draft-yevstifeyev-ftp-uri-scheme-03.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 04:59:53 -0000 28.06.2011 23:50, Daniel Stenberg wrote: > On Tue, 28 Jun 2011, Mykyta Yevstifeyev wrote: > >>> A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-03.txt has >>> been successfully submitted by Mykyta Yevstifeyev and posted to the >>> IETF repository. > > I'm afraid this draft is drifting even further into a territory where > it dictates how to do FTP in a way I don't think it can or should. > > Some random remarks on the -03 version: > > Section 2.2 > > Introduced a typo on line 2, "a file a directory" should be "a file or > a directory". Agreed here. I'll correct. > > Section 2.2.3 > > I object to (1b) as it is present and then mentioned to be NOT > RECOMMENDED and then it is claimed to be there due to "compatibility > with some FTP clients" but the only times I've had to use that method > it has been to overcome problems caused by FTP servers (or server > installations at least). Its existance in the spec is utterly > confusing to me. With regard to this, I think this isn't a problem, so I'll remove this step. > > (3) seems to mandate PORT or PASV to be used. This is not how many > clients of today work - they prefer EPSV or EPRT and a lot of them > also use STAT instead of opening a second connection. I strongly > oppose to the the URI spec to dictate this. I agree here as well - so it will be "arrange data connection using an appropriate method (eg. PORT, PASV [RFC0959], EPRT or EPSV [RFC2428] command; using historical LPRT and LPSV [RFC1639] for this purpose is strongly discouraged);" > > Similarly, I object to (4a) and (4b) claiming that NLST should be used > to list directories. That's entirely up to the client on how it thinks > is best to get the contents of a directory. With this respect NLST was borrowed from RFC 1738. So I'll change so that (4a) and (4b) will not mention NLST but rather "an appropriate method, like LIST, NLST [RFC0959] or MLST [RFC3659] command" Thanks for your feedback. Mykyta Yevstifeyev From iljitsch@muada.com Thu Jun 30 06:45:31 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC79E11E80CC; Thu, 30 Jun 2011 06:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT2NW0q2OXmF; Thu, 30 Jun 2011 06:45:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD5511E80BF; Thu, 30 Jun 2011 06:45:30 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p5UDjq4O011921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 15:45:53 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> Date: Thu, 30 Jun 2011 15:45:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44C34387-A958-41E9-9363-D8DB7EBBCEF0@muada.com> References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 30 Jun 2011 08:04:49 -0700 Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , "ietf@ietf.org Discussion" , Daniel Stenberg , ftpext@ietf.org, TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , draft-ietf-behave-ftp64.all@tools.ietf.org, David Harrington , Pekka Savola Subject: Re: [ftpext] [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 13:45:31 -0000 [Please note that this message is going to many mailing lists, please = trim as appropriate when responding.] I submitted a new version of the draft which addresses most, if not all = comments. The most notable change, which I would like to ask previous reviewers to = look at again, is the handling of the AUTH command, which is now made = much less prominent as a way to make the ALG transparent (clients should = use ALGS for this) so text specifying interaction of multiple ALGs could = be removed. The draft: http://tools.ietf.org/html/draft-ietf-behave-ftp64-11 The diff with -10: = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-behave= -ftp64-11.txt Thanks everyone for reviewing.= From evnikita2@gmail.com Thu Jun 30 20:40:47 2011 Return-Path: X-Original-To: ftpext@ietfa.amsl.com Delivered-To: ftpext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF5C21F8658 for ; Thu, 30 Jun 2011 20:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWREGeTtKatO for ; Thu, 30 Jun 2011 20:40:46 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4C97B21F864A for ; Thu, 30 Jun 2011 20:40:36 -0700 (PDT) Received: by fxe4 with SMTP id 4so3634605fxe.27 for ; Thu, 30 Jun 2011 20:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=bhmYd133owpEbEsGeLYqqAWXgCNpoHny8rNwLV5PQ+g=; b=hwhT9MgfuF0cxE5OucoRseJxx0GjM5RqyHDVcJZmDdu1JlPVTgpRCNpaRucQ+1BfCN Es+w2lxTiZfChbTC/c2LbOLYoDAZQexCHYBReVPXcK05UFWuCR748SZFZ2f6wO9WXlkY rucRreFTRUDbao31U3SyAzal47IthaY5QHeMU= Received: by 10.223.75.139 with SMTP id y11mr4192147faj.133.1309491633623; Thu, 30 Jun 2011 20:40:33 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id r10sm2040067fah.26.2011.06.30.20.40.32 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 20:40:32 -0700 (PDT) Message-ID: <4E0D41DE.4010603@gmail.com> Date: Fri, 01 Jul 2011 06:41:18 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "ftpext@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ftpext] RFC 1639 to Historic X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 03:40:47 -0000 Hello, RFC 1639 specified FTP Operations Over Big Address Records (FOOBAR). With creation of the registry for FTO command per RFC 5797, the LPRT and LPSV commands specified there were designated as historical - 'h' in Conformance column (see http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xml). Therefore, it would be logical to move RFC 1639 and its predecessor - RFC 1545 - to Historic, which RFC 5797 failed to do. Any thoughts on this? Mykyta Yevstifeyev