From nobody Sat Jan 3 05:13:23 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE71A1A67 for ; Sat, 3 Jan 2015 05:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.297 X-Spam-Level: * X-Spam-Status: No, score=1.297 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucV4k1FxkYav for ; Sat, 3 Jan 2015 05:13:18 -0800 (PST) Received: from cs8-dallas.accountservergroup.com (cs8-dallas.accountservergroup.com [108.174.144.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B461A1A55 for ; Sat, 3 Jan 2015 05:13:18 -0800 (PST) Received: from a213-22-18-232.cpe.netcabo.pt ([213.22.18.232]:63363 helo=Samsung-RF711.maclean.com) by cs8-dallas.accountservergroup.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y7OW4-000FPv-V5; Sat, 03 Jan 2015 07:13:17 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 03 Jan 2015 08:11:00 -0500 To: Jayantheesh S B , "'imapext@ietf.org'" From: Pete Maclean In-Reply-To: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna .samsung.com> References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cs8-dallas.accountservergroup.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - maclean.com X-Get-Message-Sender-Via: cs8-dallas.accountservergroup.com: authenticated_id: pete+maclean.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/rTY3al3526rD0dEfu_cclO0kWDw Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 13:13:20 -0000 Jay, I have not said anything on APPENDLIMIT before but, reading your latest draft now, there are a few things I wonder about. I don't think any of these necessarily requires any changes to the draft but some may merit additional consideration. In section 5 you make reference to "the server's fixed maximum mail upload size". What is the intended scope of said fixedness. Should a client assume that a maximum upload size obtained in one session applies in a later session? I think it should not. Hardware or other changes at the server could surely lead to a maximum upload size changing over time. How should a client behave if it obtains a maximum upload size for a given mailbox in a LIST command and then later in the same session it does a SELECT/EXAMINE for the same mailbox that quotes a different maximum upload size? For that matter, is it valid for a server to return different maximum upload sizes in CAPABILITY responses within a single session? In cases where a maximum upload size is dependent on a quota, it could make sense for these things to happen. Surely it would be very valuable to include in this extension a means for a server to indicate that it does not accept APPENDs at all. For IMAP servers fronting email archives, it is entirely reasonable for APPENDs to be unsupported. In other cases, it seems reasonable for APPENDs to be disallowed for certain mailboxes (as, for example, in a proxy situation or when a mailbox reaches maximum capacity). An easy way to deal with this would perhaps be to change the syntax to allow an append limit of 0 with the meaning, not that zero-length messages may be APPENDed (something that my checks show that many servers disallow anyway), but that APPENDs are not allowed period. This could avoid a lot of trouble, I believe. Pete Maclean At 05:12 PM 12/19/2014, Jayantheesh S B wrote: >Hi All, > >Please find the next version of the draft attached with all the >review comments addressed. > >If you have any comments/suggestions in the attached version, kindly share it. > >Regards, >Jay > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext From nobody Sat Jan 3 15:25:38 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6911A1A0C for ; Sat, 3 Jan 2015 15:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLtPq73ICgmc for ; Sat, 3 Jan 2015 15:25:34 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8771A19FE for ; Sat, 3 Jan 2015 15:25:33 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 9E0E76128B; Sun, 4 Jan 2015 00:25:23 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Sun, 04 Jan 2015 00:25:30 +0100 User-Agent: Trojita/v0.4.1-465-g0c3397f; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: <5b0dbeec-bf0e-4122-bfd4-651d3356ae64@flaska.net> In-Reply-To: <20150103131324.4421E1A1A76@ietfa.amsl.com> References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> <20150103131324.4421E1A1A76@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/D1eu3cMVujEmlqJD-MExypZ7pzU Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 23:25:36 -0000 On Saturday, 3 January 2015 14:11:00 CEST, Pete Maclean wrote: > Surely it would be very valuable to include in this extension a=20 > means for a server to indicate that it does not accept APPENDs=20 > at all. That's IMHO what the ACL extension is for -- the "i" right defined in=20 RFC4314. With kind regards, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From nobody Sun Jan 4 10:49:42 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B7C1A8A52 for ; Sun, 4 Jan 2015 10:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-AkF8It_AEB for ; Sun, 4 Jan 2015 10:49:40 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id D8FA91A1BCB for ; Sun, 4 Jan 2015 10:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1420397379; d=isode.com; s=selector; i=@isode.com; bh=hfMXoQEwqc7ngz1MGYHxUuFD4ACgdN69/8wIQCxZe/c=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=GBR7mAKJspm6jEAFlnGcSwKKTHOmfnSb6ZHIMkJd/WLZJkU9+As8EwdXXWt8lm61S9XDoc cawIEHMk9QhGidr9NX2oUH8LcaI4E3oiFj3NwO6Gcj1kbXF+Ucas4J1ZNiaRDrkbeG8XXe VM9YXesNLinxnTkPfOwLpwpSS7C15+c=; Received: from [192.168.0.5] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 4 Jan 2015 18:49:38 +0000 Message-ID: <54A983C5.9070008@isode.com> Date: Sun, 04 Jan 2015 18:17:41 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Pete Maclean , Jayantheesh S B , "'imapext@ietf.org'" References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> <20150103131325.159C31A1A55@ietfa.amsl.com> In-Reply-To: <20150103131325.159C31A1A55@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/ZXWcDzTP8hoXfCuZbL0y37Apfxk Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 18:49:41 -0000 Hi Pete, On 03/01/2015 13:11, Pete Maclean wrote: > Jay, > > I have not said anything on APPENDLIMIT before but, reading your > latest draft now, there are a few things I wonder about. I don't > think any of these necessarily requires any changes to the draft but > some may merit additional consideration. > > In section 5 you make reference to "the server's fixed maximum mail > upload size". What is the intended scope of said fixedness. Should a > client assume that a maximum upload size obtained in one session > applies in a later session? I think it should not. I don't think this matters, because the limit would be always advertised in CAPABILITY response and/or on SELECT anyway. > Hardware or other changes at the server could surely lead to a maximum > upload size changing over time. > > How should a client behave if it obtains a maximum upload size for a > given mailbox in a LIST command and then later in the same session it > does a SELECT/EXAMINE for the same mailbox that quotes a different > maximum upload size? For that matter, is it valid for a server to > return different maximum upload sizes in CAPABILITY responses within a > single session? In cases where a maximum upload size is dependent on > a quota, it could make sense for these things to happen. Yes, it is probably sensible to allow for that. > Surely it would be very valuable to include in this extension a means > for a server to indicate that it does not accept APPENDs at all. APPENDLIMIT=0? > For IMAP servers fronting email archives, it is entirely reasonable > for APPENDs to be unsupported. In other cases, it seems reasonable > for APPENDs to be disallowed for certain mailboxes (as, for example, > in a proxy situation or when a mailbox reaches maximum capacity). An > easy way to deal with this would perhaps be to change the syntax to > allow an append limit of 0 with the meaning, not that zero-length > messages may be APPENDed (something that my checks show that many > servers disallow anyway), but that APPENDs are not allowed period. > This could avoid a lot of trouble, I believe. Yes, I think this is a good idea. From nobody Sun Jan 4 11:23:58 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084F21A8AA9 for ; Sun, 4 Jan 2015 11:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzRzRER0r70A for ; Sun, 4 Jan 2015 11:23:54 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C23D1A8AA3 for ; Sun, 4 Jan 2015 11:23:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5C92A7E1B2A; Sun, 4 Jan 2015 14:23:53 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05ETrZYYoWQf; Sun, 4 Jan 2015 14:23:53 -0500 (EST) Received: from [10.0.1.25] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id A683C7E1B20; Sun, 4 Jan 2015 14:23:52 -0500 (EST) Date: Sun, 04 Jan 2015 14:23:50 -0500 From: Cyrus Daboo To: =?UTF-8?Q?Jan_Kundr=C3=A1t?= , imapext@ietf.org Message-ID: <4E9B892B5DDEE7391F135D3A@cyrus.local> In-Reply-To: <5b0dbeec-bf0e-4122-bfd4-651d3356ae64@flaska.net> References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> <20150103131324.4421E1A1A76@ietfa.amsl.com> <5b0dbeec-bf0e-4122-bfd4-651d3356ae64@flaska.net> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=896 Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/xXTC9ZI69AL6xbht9wX2eLsnWt8 Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:23:57 -0000 Hi Jan, --On January 4, 2015 at 12:25:30 AM +0100 Jan Kundr=C3=A1t = wrote: >> Surely it would be very valuable to include in this extension a >> means for a server to indicate that it does not accept APPENDs >> at all. > > That's IMHO what the ACL extension is for -- the "i" right defined in > RFC4314. > Tru,e but I think we need to distinguish between what is "allowed" (ACL) vs = what the size limit is (APPENDLIMIT). As others have noted, the limit may=20 well reach zero because of some quota on the mailbox. I don't think that=20 the ACL should depend on the the available quota in that case (i.e., the=20 "i" right would remain set because if messages were deleted, APPENDs would=20 be OK). So I think APPENDLIMIT=3D0 should be a valid response (though I think = Pete's=20 example of a "read-only" email archive would be better served via removing=20 the "i" ACL right). --=20 Cyrus Daboo From nobody Sun Jan 4 11:25:16 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128B41A8AAC for ; Sun, 4 Jan 2015 11:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwbRWKOrdBO7 for ; Sun, 4 Jan 2015 11:25:12 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0F11A8AA8 for ; Sun, 4 Jan 2015 11:25:12 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0E85CFA0004; Sun, 4 Jan 2015 19:25:10 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1420399509-3758-3757/12/52; Sun, 4 Jan 2015 19:25:09 +0000 From: Arnt Gulbrandsen To: imapext@ietf.org Date: Sun, 4 Jan 2015 20:25:09 +0100 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: <99db95b6-b009-4a9b-9b96-fe52fd47988b@gulbrandsen.priv.no> In-Reply-To: <4E9B892B5DDEE7391F135D3A@cyrus.local> References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> <20150103131324.4421E1A1A76@ietfa.amsl.com> <5b0dbeec-bf0e-4122-bfd4-651d3356ae64@flaska.net> <4E9B892B5DDEE7391F135D3A@cyrus.local> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/VnQYy0wp5l3zM9-S_F0tRwIFvBA Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:25:14 -0000 Allowed, but with a zero quota... Does any of you really care about supporting that case? Arnt From nobody Mon Jan 5 05:52:10 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FAA1A87BB for ; Mon, 5 Jan 2015 05:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfdh1F3objSq for ; Mon, 5 Jan 2015 05:52:03 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C741A00A8 for ; Mon, 5 Jan 2015 05:52:02 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 3EC186128B; Mon, 5 Jan 2015 14:51:52 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Mon, 05 Jan 2015 14:51:59 +0100 User-Agent: Trojita/v0.4.1-466-g7e2d89e; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: <4E9B892B5DDEE7391F135D3A@cyrus.local> References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> <20150103131324.4421E1A1A76@ietfa.amsl.com> <5b0dbeec-bf0e-4122-bfd4-651d3356ae64@flaska.net> <4E9B892B5DDEE7391F135D3A@cyrus.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/NUcZFFewgEwu1-A-MVa7DJH1Rnk Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:52:05 -0000 On Sunday, 4 January 2015 20:23:50 CEST, Cyrus Daboo wrote: > Tru,e but I think we need to distinguish between what is=20 > "allowed" (ACL) vs what the size limit is (APPENDLIMIT). As=20 > others have noted, the limit may well reach zero because of some=20 > quota on the mailbox. I don't think that the ACL should depend=20 > on the the available quota in that case (i.e., the "i" right=20 > would remain set because if messages were deleted, APPENDs would=20 > be OK). I do not think that the per-mailbox APPENDLIMIT should take quotas into=20 account at all. If you send an * OK [APPENDLIMIT 10] at a time your quota=20 is almost exhausted, then you have to have a channel to asynchronously=20 update that information when space gets freed. This means unsolicited * OK=20= [APPENDLIMIT ...] on selected mailboxes, something pretty ugly already. How=20= do you propose to pass this information for non-selected mailboxes where=20 the client has already asked in STATUS or LIST-STATUS? Seriously, if this switches from a rarely changing limit which is valid for=20= at least the duration of the IMAP session, then you have to invent a=20 syncing mechanism. That starts to get a bit complex soon enough. With kind regards, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From nobody Mon Jan 5 06:01:19 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9638A1A87EE for ; Mon, 5 Jan 2015 06:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.597 X-Spam-Level: * X-Spam-Status: No, score=1.597 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO-a4Cqy0ywK for ; Mon, 5 Jan 2015 06:01:17 -0800 (PST) Received: from cs8-dallas.accountservergroup.com (cs8-dallas.accountservergroup.com [108.174.144.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB511A87E8 for ; Mon, 5 Jan 2015 06:01:17 -0800 (PST) Received: from a213-22-18-232.cpe.netcabo.pt ([213.22.18.232]:60462 helo=Samsung-RF711.maclean.com) by cs8-dallas.accountservergroup.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y88Dc-0006M2-6C; Mon, 05 Jan 2015 08:01:16 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Jan 2015 09:00:51 -0500 To: Jan =?iso-8859-1?Q?Kundr=E1t?= , From: Pete Maclean In-Reply-To: <5b0dbeec-bf0e-4122-bfd4-651d3356ae64@flaska.net> References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> <20150103131324.4421E1A1A76@ietfa.amsl.com> <5b0dbeec-bf0e-4122-bfd4-651d3356ae64@flaska.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cs8-dallas.accountservergroup.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - maclean.com X-Get-Message-Sender-Via: cs8-dallas.accountservergroup.com: authenticated_id: pete+maclean.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/xUwA6sjYka1WUsjJvrw3k1KzVKQ Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:01:18 -0000 Jan, Thank you for pointing that out. While I have=20 looked at the RFC, I am not well up on ACL=20 commands having never had reason to support them=20 in my server. I see an account's right to use=20 APPEND as a different matter from a server's=20 ability to allow APPENDs though (the former is,=20 as it were, subjective while the latter is=20 objective) and I still think it would be valuable=20 for servers to have an ability to indicate that=20 APPENDs are not acceptable. Of course this does=20 mean that the interaction of the two must be=20 defined but I think that should be easy and, I=20 hope, obvious in that nothing a server says about=20 its willingness to accept APPENDs should be taken=20 as any indication that that overrides a user's=20 rights. After all, we are not suggesting that a=20 server should inhibit its sending of APPENDLIMIT=20 data to clients operating without the "i" right. Pete Maclean At 06:25 PM 1/3/2015, Jan Kundr=E1t wrote: >On Saturday, 3 January 2015 14:11:00 CEST, Pete=20 >Maclean wrote: > Surely it would be very=20 >valuable to include in this extension a > means=20 >for a server to indicate that it does not accept=20 >APPENDs > at all. That's IMHO what the ACL=20 >extension is for -- the "i" right defined in=20 >RFC4314. With kind regards, Jan -- Trojit=C3=A1, a=20 >fast Qt IMAP e-mail client --=20 >http://trojita.flaska.net/=20 >_______________________________________________=20 >imapext mailing list imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext From nobody Mon Jan 5 09:50:33 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3033C1A8720 for ; Mon, 5 Jan 2015 09:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx2LL6ZvGC39 for ; Mon, 5 Jan 2015 09:50:30 -0800 (PST) Received: from smg1.telecom.sna.samsung.com (unknown [63.166.115.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8581A870A for ; Mon, 5 Jan 2015 09:50:30 -0800 (PST) X-AuditID: 41a9fa1f-f79486d0000004ef-54-54aacedad7ac Received: from exHub2.telecom.sna.samsung.com (Unknown_Domain [105.52.12.243]) by smg1.telecom.sna.samsung.com (SMGOUT STA) with SMTP id 0A.5C.01263.ADECAA45; Mon, 5 Jan 2015 11:50:18 -0600 (CST) Received: from EXMB5.telecom.sna.samsung.com ([fe80::5f4:56d9:ea68:f480]) by exHub2.telecom.sna.samsung.com ([2002:6934:cf3::6934:cf3]) with mapi id 14.03.0146.000; Mon, 5 Jan 2015 11:50:28 -0600 From: Jayantheesh S B To: Pete Maclean , "'imapext@ietf.org'" Thread-Topic: [imapext] The IMAP APPENDLIMIT Extension Thread-Index: AQHQJ2k+w9SxyQNle0KVLYSkU9nuIJyxzLrA Date: Mon, 5 Jan 2015 17:50:27 +0000 Message-ID: <02454F842DD7B449B96715A2AD90C0364CE951B9@exMB5.telecom.sna.samsung.com> References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [105.52.12.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsWSacLzWffWuVUhBuu/iVtc23qFxeLxLC4H Jo8lS34yebyZHhrAFMVtk5RYUhacmZ6nb5fAnbF6/wWWgiPiFX0PDrI0MH4X6mLk5JAQMJHY t+0JO4QtJnHh3nq2LkYuDiGBY4wSLybcYIdwjjNK7N1zkamLkZ2DTUBH4kkwSL2IgJ/Eh18/ mEBsYQFTiSvHZrNDxM0kft/8AGUbSfQ0nmAEsVkEVCT2XW0Bs3kFQiQe/O5mBbGFBLoYJebs NAOxOQUcJBZ9OAlWwwh0z/dTa8DmMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwFSXm/rrJ DFGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYwyxbnphnol qTmpyfm5esV5iXrFibnFpXnpekD+JkZgxDiu/CW/g3HddvtDjEwcnIcYJTi4pESKU/NSUosS S0sy4kFREl8MjBOpBsa9POrlhtfsDDm3cN3Yu6Fkgt/ng/Vzur9ZyIfFzZu2jOnc/d/VU+6U tfBezJqZxfO1pLozXHFzDqv0tivL0txWZJgdmSp3e0nVYbYtj9nO/HjQKJn7Jsfix74LKRl1 5sGdK43E5b+V9srcZ770dMKCPwW/zJ6efvD+jUKokdvVfr+ZfxnZthxUYinOSDTUYi4qTgQA jwWSr2MCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/Zb2CAz9me2oZf7ENUb70FB-F2Rw Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:50:32 -0000 Hi Pete, Thanks for your review comments.=20 Please find my comments inline.=20 Regards, Jay -----Original Message----- From: Pete Maclean [mailto:groups@maclean.com]=20 Sent: Saturday, January 03, 2015 8:11 AM To: Jayantheesh S B; 'imapext@ietf.org' Subject: Re: [imapext] The IMAP APPENDLIMIT Extension Jay, I have not said anything on APPENDLIMIT before but, reading your latest dra= ft now, there are a few things I wonder about. I don't think any of these = necessarily requires any changes to the draft but some may merit additional= consideration. In section 5 you make reference to "the server's fixed maximum mail upload = size". What is the intended scope of said fixedness. Should a client assu= me that a maximum upload size obtained in one session applies in a later se= ssion? I think it should not. Hardware or other changes at the server cou= ld surely lead to a maximum upload size changing over time. [Jay] Upload size obtained using SELECT/EXAMINE always overrides the CAPABI= LITY response. So, maximum upload size obtained in one session does not app= ly for another session. How should a client behave if it obtains a maximum upload size for a given = mailbox in a LIST command and then later in the same session it does a SELE= CT/EXAMINE for the same mailbox that quotes a different maximum upload size= ? For that matter, is it valid for a server to return different maximum up= load sizes in CAPABILITY responses within a single session? In cases where= a maximum upload size is dependent on a quota, it could make sense for the= se things to happen. Surely it would be very valuable to include in this extension a means for a= server to indicate that it does not accept APPENDs at all. For IMAP serve= rs fronting email archives, it is entirely reasonable for APPENDs to be uns= upported. In other cases, it seems reasonable for APPENDs to be disallowed= for certain mailboxes (as, for example, in a proxy situation or when a mai= lbox reaches maximum capacity). An easy way to deal with this would perhap= s be to change the syntax to allow an append limit of 0 with the meaning, n= ot that zero-length messages may be APPENDed (something that my checks show= that many servers disallow anyway), but that APPENDs are not allowed perio= d. This could avoid a lot of trouble, I believe. [Jay] This is the good idea. I will change the next version of the draft to= accept the APPENDLIMIT=3D0, indicates the server will not accept any APPEN= D command due to size restriction. Pete Maclean At 05:12 PM 12/19/2014, Jayantheesh S B wrote: >Hi All, > >Please find the next version of the draft attached with all the review=20 >comments addressed. > >If you have any comments/suggestions in the attached version, kindly share= it. > >Regards, >Jay > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext From nobody Wed Jan 21 14:37:46 2015 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC491A1A80 for ; Wed, 21 Jan 2015 14:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.795 X-Spam-Level: ** X-Spam-Status: No, score=2.795 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01kyYZ3stToo for ; Wed, 21 Jan 2015 14:37:41 -0800 (PST) Received: from smg2.telecom.sna.samsung.com (unknown [63.166.115.32]) by ietfa.amsl.com (Postfix) with ESMTP id 738301A896C for ; Wed, 21 Jan 2015 14:37:41 -0800 (PST) X-AuditID: 41a9fa20-f79696d000002323-e1-54c02a25fc3f Received: from exHub4.telecom.sna.samsung.com (Unknown_Domain [105.52.12.225]) by smg2.telecom.sna.samsung.com (SMGOUT STA) with SMTP id 04.7F.08995.52A20C45; Wed, 21 Jan 2015 16:37:25 -0600 (CST) Received: from EXMB6.telecom.sna.samsung.com ([169.254.2.42]) by exHub4.telecom.sna.samsung.com ([::1]) with mapi id 14.03.0210.002; Wed, 21 Jan 2015 16:37:40 -0600 From: Jayantheesh S B To: Jayantheesh S B , Pete Maclean , "'imapext@ietf.org'" Thread-Topic: [imapext] The IMAP APPENDLIMIT Extension Thread-Index: AQHQKSZ6cHtzN5sRcUuyYLuqEuTGXZzLQjiw Date: Wed, 21 Jan 2015 22:37:39 +0000 Message-ID: <02454F842DD7B449B96715A2AD90C0364F2A5560@exMB6.telecom.sna.samsung.com> References: <02454F842DD7B449B96715A2AD90C0363E99E411@exMB5.telecom.sna.samsung.com> <02454F842DD7B449B96715A2AD90C0364CE951B9@exMB5.telecom.sna.samsung.com> In-Reply-To: <02454F842DD7B449B96715A2AD90C0364CE951B9@exMB5.telecom.sna.samsung.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [105.52.12.197] Content-Type: multipart/mixed; boundary="_002_02454F842DD7B449B96715A2AD90C0364F2A5560exMB6telecomsna_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsWSacLzUFdV60CIwYefUhYzVhdZXNt6hcXi 8SwuB2aPJUt+Mnmcajb0eDM9NIA5itsmKbGkLDgzPU/fLoE741r/K5aCaesZK96cb2VuYHy7 lLGLkZNDQsBEYsrtmywQtpjEhXvr2boYuTiEBI4xSjzbspoFwlnBKPH63A32LkZ2DjYBHYkn wSD1IgIVEl+uvGEFsZkFfCVu/PvFDmILC5hKXDk2mx2ixkzi980PULaRxJ4vC8DqWQRUJbre ngSzeQVCJPp+3GOHWHWVUeL8nidADgcHp0CoxJ03riA1jEC3fT+1hglil7jErSfzmSBuFpF4 ePE0G4QtKvHy8T9WCFtRYu6vm8wQ9ZkSn2b/YoPYJShxcuYTlgmMorOQjJqFpGwWkrIFjMyr GGWKc9ON9EpSc1KT83P1ivMS9YoTc4tL89L1gPxNjMBocVz5S2EHY8Mu+0OMTBychxglOLik RIpT81JSixJLSzLiQRERXwyMCakGxviWTTHnlhpdCDU3dnJdIKR56df69pmWNlNXuXU/dePT 8H4l01Iy09iCad6jXfdzhVU3WCtMra0Nee9ozD/r8t9T+Xx/PGd0RRyrCuOfM/NFSZ7dxI6J NZ8evZXhbdja7af0vap86Wuxvgl2Wz8rJeTqsk2brZfl7eiuXaxR1jHhh+mtnXP+KbEUZyQa ajEXFScCACgS06lhAgAA Archived-At: Cc: "Alexey Melnikov \(alexey.melnikov@isode.com\)" Subject: Re: [imapext] The IMAP APPENDLIMIT Extension X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 22:37:44 -0000 --_002_02454F842DD7B449B96715A2AD90C0364F2A5560exMB6telecomsna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Please find the next version of the draft updated with APPENDLIMIT=3D0 case= addressed. Share comments in this version to make the final version of draft. Regards, Jay -----Original Message----- From: Jayantheesh S B [mailto:j.sb@sta.samsung.com]=20 Sent: Monday, January 05, 2015 12:50 PM To: Pete Maclean; 'imapext@ietf.org' Subject: Re: [imapext] The IMAP APPENDLIMIT Extension Hi Pete, Thanks for your review comments.=20 Please find my comments inline.=20 Regards, Jay -----Original Message----- From: Pete Maclean [mailto:groups@maclean.com] Sent: Saturday, January 03, 2015 8:11 AM To: Jayantheesh S B; 'imapext@ietf.org' Subject: Re: [imapext] The IMAP APPENDLIMIT Extension Jay, I have not said anything on APPENDLIMIT before but, reading your latest dra= ft now, there are a few things I wonder about. I don't think any of these = necessarily requires any changes to the draft but some may merit additional= consideration. In section 5 you make reference to "the server's fixed maximum mail upload = size". What is the intended scope of said fixedness. Should a client assu= me that a maximum upload size obtained in one session applies in a later se= ssion? I think it should not. Hardware or other changes at the server cou= ld surely lead to a maximum upload size changing over time. [Jay] Upload size obtained using SELECT/EXAMINE always overrides the CAPABI= LITY response. So, maximum upload size obtained in one session does not app= ly for another session. How should a client behave if it obtains a maximum upload size for a given = mailbox in a LIST command and then later in the same session it does a SELE= CT/EXAMINE for the same mailbox that quotes a different maximum upload size= ? For that matter, is it valid for a server to return different maximum up= load sizes in CAPABILITY responses within a single session? In cases where= a maximum upload size is dependent on a quota, it could make sense for the= se things to happen. Surely it would be very valuable to include in this extension a means for a= server to indicate that it does not accept APPENDs at all. For IMAP serve= rs fronting email archives, it is entirely reasonable for APPENDs to be uns= upported. In other cases, it seems reasonable for APPENDs to be disallowed= for certain mailboxes (as, for example, in a proxy situation or when a mai= lbox reaches maximum capacity). An easy way to deal with this would perhap= s be to change the syntax to allow an append limit of 0 with the meaning, n= ot that zero-length messages may be APPENDed (something that my checks show= that many servers disallow anyway), but that APPENDs are not allowed perio= d. This could avoid a lot of trouble, I believe. [Jay] This is the good idea. I will change the next version of the draft to= accept the APPENDLIMIT=3D0, indicates the server will not accept any APPEN= D command due to size restriction. Pete Maclean At 05:12 PM 12/19/2014, Jayantheesh S B wrote: >Hi All, > >Please find the next version of the draft attached with all the review=20 >comments addressed. > >If you have any comments/suggestions in the attached version, kindly share= it. > >Regards, >Jay > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext --_002_02454F842DD7B449B96715A2AD90C0364F2A5560exMB6telecomsna_ Content-Type: text/plain; name="draft-jayantheesh-imap-appendlimit-extension-03.txt" Content-Description: draft-jayantheesh-imap-appendlimit-extension-03.txt Content-Disposition: attachment; filename="draft-jayantheesh-imap-appendlimit-extension-03.txt"; size=13367; creation-date="Wed, 21 Jan 2015 22:13:26 GMT"; modification-date="Wed, 21 Jan 2015 22:22:59 GMT" Content-Transfer-Encoding: base64 SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SmF5YW50aGVlc2ggUyBCIApJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNhbXN1bmcKRXhwaXJlczogSnVseSAyMDE1ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5hcmVuZHJhIFNpbmdoIEJpc2h0CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U2Ftc3VuZwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEphbnVhcnkgMjEsIDIwMTUKCiAgICAgICAgICAgICAgICAgICAgICBUaGUgSU1BUCBB UFBFTkRMSU1JVCBFeHRlbnNpb24KICAgICAgICAgICAgICAgIGRyYWZ0LWpheWFudGhlZXNoLWlt YXAtYXBwZW5kbGltaXQtZXh0ZW5zaW9uLTAzCgpBYnN0cmFjdAoKVGhpcyBtZW1vIGRlZmluZXMg YW4gZXh0ZW5zaW9uIHRvIHRoZSBJTUFQIHNlcnZpY2Ugd2hlcmVieSBhIHNlcnZlciBjYW4KYWR2 ZXJ0aXNlIGl0cyBjYXBhYmlsaXR5LCB0byBzdXBwb3J0IG1heGltdW0gbWFpbCB1cGxvYWQgc2l6 ZSB1c2luZwpDQVBBQklMSVRZLCBTRUxFQ1QvRVhBTUlORSBhbmQgTElTVCBjb21tYW5kLgoKU3Rh dHVzIG9mIHRoaXMgTWVtbwoKVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVs bCBjb25mb3JtYW5jZSB3aXRoIHRoZQpwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiBU aGlzIGRvY3VtZW50IG1heSBub3QgYmUgbW9kaWZpZWQsIGFuZApkZXJpdmF0aXZlIHdvcmtzIG9m IGl0IG1heSBub3QgYmUgY3JlYXRlZCwgZXhjZXB0IHRvIHB1Ymxpc2ggaXQgYXMgYW4KUkZDIGFu ZCB0byB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLgoKSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcgVGFzawpGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vw cy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMKbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuCgpJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKYW5kIG1heSBiZSB1cGRh dGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKdGlt ZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2UgbWF0ZXJpYWwKb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jl c3MuIgoKVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2Vk IGF0Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dAoKVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdApo dHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sCgpUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg ZXhwaXJlIG9uIEp1bHksIDIwMTUuCgpDb3B5cmlnaHQgTm90aWNlCgpDb3B5cmlnaHQgKGMpIDIw MTQgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKZG9jdW1lbnQg YXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgpUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg dG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsClByb3Zpc2lvbnMgUmVsYXRpbmcg dG8gSUVURiBEb2N1bWVudHMKKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykg aW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCnB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQ bGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVsbHksCmFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QgdG8gdGhpcwpkb2N1bWVu dC4KCkpheWFudGhlZXNoICYgTmFyZW5kcmEgICAgICAgRXhwaXJlcyBKdWx5LCAyMDE1ICAgICAg ICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIElNQVAgQVBQ RU5ETElNSVQgICAgICAgICAgICAgSmFudWFyeSAyMDE1CgpUYWJsZSBvZiBDb250ZW50cwoKICAg MS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAyCiAgICAgMS4xLiBDb252ZW50aW9ucyBhbmQgVGVybWlub2xvZ3kgLiAuIC4g LiAuIC4gLiAuIC4gLiAgLiAuIC4gLiAuICAgMgogICAyLiBBUFBFTkRMSU1JVCBFeHRlbnNpb24g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIKICAgMy4gTWFpbGJv eCBzcGVjaWZpYyBBUFBFTkRMSU1JVCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzCiAgICAgMy4xLiBTRUxFQ1QgcmVzcG9uc2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDMuMi4gTElTVCByZXNwb25zZSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgNC4gQVBQRU5EIHJlc3BvbnNl IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgIDUu IEZvcm1hbCBzeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNQogICA2LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYKICAgNy4gSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgIDguIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NgogICAgOC4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDYKICAgIDguMiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3CiAgIDkuIEFja25vd2xlZGdlbWVudCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAxMC4g QXV0aG9yJ3MgQWRkcmVzcyAuIC4uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDcKICAgCgoxLiBJbnRyb2R1Y3Rpb24KClNldmVyYWwgSU1BUCBzZXJ2ZXIgaGF2ZSBs aW1pdGF0aW9uIGZvciBtYWlsIHVwbG9hZCBzaXplIHdoaWNoIGlzIG5vdApwdWJsaXNoZWQgdG8g dGhlIGVtYWlsIGNsaWVudC4gIFdoZW4gZW1haWwgY2xpZW50IEFQUEVORCBhIG1haWwgd2l0aApo dWdlIGF0dGFjaG1lbnRzLCBpdCBmYWlscyBkdWUgdG8gc2l6ZSByZXN0cmljdGlvbiBzZXQgYnkg dGhlIElNQVAKc2VydmVyLiAgVGhpcyByZXN1bHRzIGluIHVubmVjZXNzYXJ5IHJlc291cmNlIHVz YWdlLiAgRXNwZWNpYWxseSBpbiB0aGUgCm1vYmlsZSBkZXZpY2UgZW52aXJvbm1lbnQsIGFwcGVu ZGluZyBtYWlsIHdpdGggaHVnZSBhdHRhY2htZW50IGNvbnN1bWVzCmRldmljZSByZXNvdXJjZXMg bGlrZSBkZXZpY2UgYmF0dGVyeSBwb3dlciBhbmQgbW9iaWxlIGRhdGEuCgpUaGUgSU1BUCBBUFBF TkRMSU1JVCBleHRlbnNpb24gcHJvdmlkZXMgYW4gYWJpbGl0eSB0byBhZHZlcnRpc2UgbWF4aW11 bQp1cGxvYWQgc2l6ZSBhbGxvd2VkIGJ5IHRoZSBJTUFQIHNlcnZlciwgc28gdGhhdCBlbWFpbCBj bGllbnQga25vd3MgdGhlCnNpemUgbGltaXRhdGlvbiBiZWZvcmVoYW5kLgoKMS4xLiBDb252ZW50 aW9ucyBhbmQgVGVybWlub2xvZ3kKClRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi UkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgCk5PVCIsIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwg IlJFQ09NTUVOREVEIiwgICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbgp0aGlzIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkuCgpFeGFtcGxlIGxp bmVzIHByZWZhY2VkIGJ5ICJDOiIgYXJlIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQgb25lcyBwcmVm YWNlZApieSAiUzoiIGJ5IHRoZSBzZXJ2ZXIuICBUaGUgZml2ZSBjaGFyYWN0ZXJzIFsuLi5dIG1l YW5zIHRoYXQgc29tZXRoaW5nCmhhcyBiZWVuIGVsaWRlZC4KCjIuIEFQUEVORExJTUlUIEV4dGVu c2lvbgoKQW4gSU1BUCBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBBUFBFTkRMSU1JVCBhZHZlcnRpc2Vz IHRoaXMgYnkgaW5jbHVkaW5nCnRoZSB3b3JkIEFQUEVORExJTUlUIGluIGl0cyBjYXBhYmlsaXR5 IGxpc3QuICBJTUFQIHNlcnZlciBzaGFsbCBwdWJsaXNoCnRoZSBzdXBwb3J0ZWQgbWFpbCB1cGxv YWQgc2l6ZSBhcyBwYXJ0IG9mIENBUEFCSUxJVFkgcmVzcG9uc2UuICBUaGUKCkpheWFudGhlZXNo ICYgTmFyZW5kcmEgICAgICAgRXhwaXJlcyBKdWx5LCAyMDE1ICAgICAgICAgICAgICBbUGFnZSAy XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgSU1BUCBBUFBFTkRMSU1JVCAgICAgICAg ICAgIEphbnVhcnkgMjAxNQoKYWR2ZXJ0aXNlZCB1cGxvYWQgbGltaXQgaXMgY29tbW9uIGFjcm9z cyB0aGUgbWFpbGJveGVzLCBidXQgY2xpZW50CmNhbiBzdGlsbCBpc3N1ZSBTRUxFQ1QvRVhBTUlO RSBvciBMSVNUIGNvbW1hbmQgdG8gZ2V0IHRoZSBtYWlsYm94CnNwZWNpZmljIHVwbG9hZCBsaW1p dCBzZXQgYnkgdGhlIElNQVAgc2VydmVyLiAgSW4gdGhpcyBjYXNlLApBUFBFTkRMSU1JVCB2YWx1 ZSBvYnRhaW5lZCBhcyBwYXJ0IG9mIFNFTEVDVC9FWEFNSU5FIG9yIExJU1QgY29tbWFuZAp0YWtl cyBwcmVjZWRlbmNlIG92ZXIgdGhlIHZhbHVlIHJldHVybmVkIGFzIHBhcnQgb2YgQ0FQQUJJTElU WQpyZXNwb25zZS4KClRoZSBmb2xsb3dpbmcgZXhhbXBsZSwgZGVtb25zdHJhdGVzIHRoZSBBUFBF TkRMSU1JVCBjYXBhYmlsaXR5IHdpdGgKbWFpbGJveCBsaW1pdC4KCkM6IHQxIENBUEFCSUxJVFkK UzogKiBDQVBBQklMSVRZIElNQVA0cmV2MSBJRCBBUFBFTkRMSU1JVD0yNTc4OTAKUzogdDEgT0sg Zm9vCgpJZiBBUFBFTkRMSU1JVCB2YWx1ZSBpcyBvbWl0dGVkIGluIENBUEFCSUxJVFkgcmVzcG9u c2UsIHRoZW4gY2xpZW50ClNIT1VMRCBpc3N1ZSBTRUxFQ1QvRVhBTUlORSBvciBMSVNUIGNvbW1h bmQgdG8gZ2V0IHRoZSBtYWlsYm94IHNwZWNpZmljCmxpbWl0IHNldCBieSB0aGUgc2VydmVyLiAg TmV3IHJlc3BvbnNlIGNvZGUgQVBQRU5ETElNSVQgaXMgYWRkZWQgdG8gZ2V0CnRoZSBtYWlsYm94 IHNwZWNpZmljIGxpbWl0LiAgUmVmZXIgc2VjdGlvbiA1IGZvciByZXNwb25zZSBjb2RlIHN5bnRh eC4KClRoZSBmb2xsb3dpbmcgZXhhbXBsZSBkZW1vbnN0cmF0ZXMsIGl0cyB1c2FnZS4KCkM6IHQx IENBUEFCSUxJVFkKUzogKiBDQVBBQklMSVRZIElNQVA0cmV2MSBJRCBBUFBFTkRMSU1JVApTOiB0 MSBPSyBmb28KCkM6IHQyIFNFTEVDVCBJTkJPWApTOiAqIDE3MiBFWElTVFMKUzogKiBPSyBbQVBQ RU5ETElNSVQgMjU3ODkwXSBNYXhpbXVtIHVwbG9hZCBsaW1pdApTOiAqIE9LIFtVSURWQUxJRElU WSAzODU3NTI5MDQ1XSBVSURzIHZhbGlkClM6ICogRkxBR1MgKFxBbnN3ZXJlZCBcRmxhZ2dlZCBc RGVsZXRlZCBcU2VlbiBcRHJhZnQpClM6ICogT0sgW1BFUk1BTkVOVEZMQUdTIChcRGVsZXRlZCBc U2VlbiBcKildIExpbWl0ZWQKUzogdDIgT0sgW1JFQUQtV1JJVEVdIFNFTEVDVCBjb21wbGV0ZWQK CkJ5IGxvb2tpbmcgYXQgdGhlIHVwbG9hZCBzaXplIHJlc3RyaWN0aW9uIHNldCBieSB0aGUgSU1B UCBzZXJ2ZXIsIGNsaWVudApNVVNUIG5vdCB0cnkgdG8gdXBsb2FkIG1haWwgbW9yZSB0aGFuIGFk dmVydGlzZWQgbGltaXQgaW4gdGhlIEFQUEVORApjb21tYW5kLiAKCjMuIE1haWxib3ggc3BlY2lm aWMgQVBQRU5ETElNSVQKCklNQVAgc2VydmVyIGNhbiBzdGlsbCBoYXZlIG1haWxib3ggc3BlY2lm aWMgQVBQRU5ETElNSVQgcmVzdHJpY3Rpb24sCndoaWNoIG1heSBub3QgYmUgYWR2ZXJ0aXNlZCBh cyBwYXJ0IG9mIENBUEFCSUxJVFkgcmVzcG9uc2UuICBJbiB0aGlzCmNhc2UsIGNsaWVudCBjYW4g aXNzdWUgU0VMRUNUL0VYQU1JTkUgY29tbWFuZCB0byBnZXQgdGhlIHBlciBtYWlsYm94CnNwZWNp ZmljIGxpbWl0IHNldCBieSB0aGUgc2VydmVyLiAgU2ltaWxhcmx5LCBpZiBjbGllbnQgd2lzaCB0 byBrbm93CnRoZSBtYWlsYm94IHNwZWNpZmljIGxpbWl0IGluIGF1dGhlbnRpY2F0ZWQgc3RhdGUs IGNhbiBiZSBkb25lIGJ5Cmlzc3VpbmcgdGhlIExJU1QgY29tbWFuZCBpbiBjb21iaW5hdGlvbiB3 aXRoIFNUQVRVUyBjb21tYW5kLgoKCgpKYXlhbnRoZWVzaCAmIE5hcmVuZHJhICAgICAgIEV4cGly ZXMgSnVseSwgMjAxNSAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgIElNQVAgQVBQRU5ETElNSVQgICAgICAgICAgICBKYW51YXJ5IDIwMTUKCjMuMSBT RUxFQ1QgcmVzcG9uc2UKCkNsaWVudCBjYW4gZ2V0IHRoZSBwZXIgbWFpbGJveCBhcHBlbmQgbGlt aXQgYnkgaXNzdWluZyB0aGUgU0VMRUNULwpFWEFNSU5FIGNvbW1hbmQuICBBUFBFTkRMSU1JVCBz aXplIHRvIHRoaXMgbWFpbGJveCBpcyBvYnRhaW5lZCBhcyBwYXJ0Cm9mIHVudGFnZ2VkIE9LIHJl c3BvbnNlLiAgSW4gdGhpcyBjYXNlLCB0aGlzIEFQUEVORExJTUlUIHZhbHVlIHdpbGwKc3VwZXJz ZWRlIHRoZSB2YWx1ZSByZWNlaXZlZCBhcyBwYXJ0IG9mIENBUEFCSUxJVFkgcmVzcG9uc2UuICBJ ZiBubwpwZXItbWFpbGJveCBBUFBFTkRMSU1JVCBpcyBzcGVjaWZpZWQgZm9yIGEgZm9sZGVyLCBi dXQgdGhlIHNlcnZlciBkaWQKc3BlY2lmeSBhIGNvbW1vbiBBUFBFTkRMSU1JVCBpbiB0aGUgQ0FQ QUJJTElUWSByZXNwb25zZSwgdGhlbiB0aGUKY29tbW9uIEFQUEVORExJTUlUIGFwcGxpZXMgdG8g dGhhdCBmb2xkZXIuCgpDOiB0MiBTRUxFQ1QgSU5CT1gKUzogKiAxNzIgRVhJU1RTClM6ICogT0sg W0FQUEVORExJTUlUIDI1Nzg5MF0gTWF4aW11bSB1cGxvYWQgbGltaXQKUzogWy4uLl0KUzogdDIg T0sgW1JFQUQtV1JJVEVdIFNFTEVDVCBjb21wbGV0ZWQKCgpJbiB0aGUgYWJvdmUgZXhhbXBsZSwg QVBQRU5ETElNSVQgcmVwcmVzZW50cyB0aGUgbWF4aW11bSB1cGxvYWQgc2l6ZSBmb3IKdGhpcyBt YWlsYm94LgoKT0sgW0FQUEVORExJTUlUIDxuPl0gTWF4aW11bSB1cGxvYWQgbGltaXQgZm9yIHRo aXMgbWFpbGJveCwgaW4gYnl0ZXMuCiAgICAgICAgICAgICAgICAgICAgIFJlZmVyIHRvIHNlY3Rp b24gNSBmb3IgbW9yZSBpbmZvcm1hdGlvbi4gIElmIHRoaXMKICAgICAgICAgICAgICAgICAgICAg aXMgbWlzc2luZywgdGhlIGNsaWVudCBjYW4gYWx3YXlzIGhvbm91ciB0aGUKICAgICAgICAgICAg ICAgICAgICAgdmFsdWUgcmVjZWl2ZWQgYXMgcGFydCBvZiBDQVBBQklMSVRZIHJlc3BvbnNlLgoK CjMuMiBMSVNUIHJlc3BvbnNlCgpJTUFQIGNsaWVudCBjYW4gZ2V0IHRoZSBtYWlsYm94IHNwZWNp ZmljIEFQUEVORExJTUlUIGluIGF1dGhlbnRpY2F0ZWQKc3RhdGUsIHdoZXJlIGl0IGRvIG5vdCBu ZWVkIHRvIGlzc3VlIFNFTEVDVC9FWEFNSU5FIGNvbW1hbmQuICBMSVNUCmNvbW1hbmQgaW4gY29t YmluYXRpb24gd2l0aCBTVEFUVVMgY29tbWFuZCBjYW4gYmUgaXNzdWVkIHRvIGdldCB0aGUgcGVy Cm1haWxib3ggc3BlY2lmaWMgQVBQRU5ETElNSVQgc2V0IGJ5IHRoZSBzZXJ2ZXIuICBSZWZlciBS RkMgNTgxOSBmb3IgdGhlCnVzYWdlIG9mIExJU1QgY29tbWFuZCBpbiBjb21iaW5hdGlvbiB3aXRo IFNUQVRVUyBjb21tYW5kLiAgTm90ZSB0aGF0IGEKc2VydmVyIGltcGxlbWVudGluZyB0aGlzIGV4 dGVuc2lvbiwgaXMgc3ludGFjdGljYWxseSBjb21wYXRpYmxlIHdpdGgKUkZDIDU4MTksIGhvd2V2 ZXIgc3VwcG9ydCBmb3IgUkZDIDUyNTggb3IgUkZDIDU4MTkgaXMgbm90IHJlcXVpcmVkLAp3aGVu IGltcGxlbWVudGluZyB0aGlzIGV4dGVuc2lvbi4KClRoZSBmb2xsb3dpbmcgZXhhbXBsZSBkZW1v bnN0cmF0ZXMsIGl0cyB1c2FnZS4KCkM6IHQxIExJU1QgIiIgJSBSRVRVUk4gKFNUQVRVUyAoQVBQ RU5ETElNSVQpKQpTOiAqIExJU1QgKCkgIi4iICAiSU5CT1giClM6ICogU1RBVFVTICJJTkJPWCIg KEFQUEVORExJTUlUIDI1Nzg5MCkKUzogdDEgT0sgTGlzdCBjb21wbGV0ZWQuCgpOZXcgYXR0cmli dXRlIEFQUEVORExJTUlUIGlzIGFkZGVkIHRvIGdldCB0aGUgbGltaXQgc2V0IGJ5IHRoZSBzZXJ2 ZXIKZm9yIHRoaXMgbWFpbGJveCBhcyBwYXJ0IG9mIFNUQVRVUyBjb21tYW5kLiAgVGhlIFNUQVRV UyByZXNwb25zZSBvY2N1cnMKYXMgYSByZXN1bHQgb2YgYW4gU1RBVFVTIGNvbW1hbmQuICBJdCBy ZXR1cm5zIHRoZSBtYWlsYm94IG5hbWUgdGhhdAoKSmF5YW50aGVlc2ggJiBOYXJlbmRyYSAgICAg ICBFeHBpcmVzIEp1bHksIDIwMTUgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICBJTUFQIEFQUEVORExJTUlUICAgICAgICAgICAgSmFudWFyeSAyMDE1 CgptYXRjaGVzIHRoZSBTVEFUVVMgc3BlY2lmaWNhdGlvbiBhbmQgdGhlIHJlcXVlc3RlZCBtYWls Ym94IHN0YXR1cwppbmZvcm1hdGlvbi4gIElNQVAgc2VydmVyIHNob3VsZCByZWNvZ25pemUgYW4g ZXh0cmEgIlJFVFVSTiAoU1RBVFVTCiAoQVBQRU5ETElNSVQpKSIgYXQgdGhlIGVuZCBvZiBhIExJ U1QgY29tbWFuZCBhbmQgZW1pdCBhbiBleHRyYSBTVEFUVVMKcmVzcG9uc2UgZm9yIGVhY2ggbWF0 Y2hpbmcgbWFpbGJveC4gIFJlZmVyIHRvIHNlY3Rpb24gNSBmb3IgdGhlIHN5bnRheC4KCkludm9r aW5nIFNUQVRVUyBjb21tYW5kIHdpdGggQVBQRU5ETElNSVQgaXMgYWxzbyBhY2NlcHRhYmxlLiAg QmVsb3cKZXhhbXBsZSBkZW1vbnN0cmF0ZXMsIGl0cyB1c2FnZS4KCkM6IHQxIFNUQVRVUyBJTkJP WCAoQVBQRU5ETElNSVQpClM6ICogU1RBVFVTIElOQk9YIChBUFBFTkRMSU1JVCAyNTc4OTApClM6 IHQxIE9LIFNUQVRVUyBjb21wbGV0ZWQKCjQuIEFQUEVORCByZXNwb25zZQoKSWYgY2xpZW50IHVw bG9hZHMgYSBtYWlsIHdoaWNoIGV4Y2VlZHMgdGhlIG1heGltdW0gdXBsb2FkIHNpemUgc2V0CnRv IHRoYXQgbWFpbGJveCwgdGhlbiBzZXJ2ZXIgU0hBTEwgcmVqZWN0IHRoZSBBUFBFTkQgY29tbWFu ZCB3aXRoIGEKdGFnZ2VkIFRPT0JJRyByZXNwb25zZSBjb2RlLiAgUmVmZXIgUkZDIDQ0NjkgU2Vj dGlvbiAoNCkgZm9yIHZhcmlvdXMKQVBQRU5EIHJlc3BvbnNlIGNvZGVzIGFuZCBpdHMgaGFuZGxp bmcuCgpDbGllbnQgY2FuIGF2b2lkIHVzZSBvZiBMSVRFUkFMKywgd2hlbiBtYXhpbXVtIHVwbG9h ZCBzaXplCnN1cHBvcnRlZCBieSB0aGUgSU1BUCBzZXJ2ZXIgaXMgdW5rbm93bi4gCgo1LiBGb3Jt YWwgc3ludGF4CgpUaGUgZm9sbG93aW5nIHN5bnRheCBzcGVjaWZpY2F0aW9uIHVzZXMgdGhlIEF1 Z21lbnRlZCBCYWNrdXMtTmF1cgpGb3JtIChBQk5GKSBub3RhdGlvbiBhcyBzcGVjaWZpZWQgaW4g W1JGQzUyMzRdIGluY2x1ZGluZyB0aGUgY29yZQpydWxlcyBpbiBBcHBlbmRpeCBCLjEuICBbUkZD MzUwMV0gZGVmaW5lcyB0aGUgbm9uLXRlcm1pbmFscwoiY2FwYWJpbGl0eSIsICJyZXNwLXRleHQt Y29kZSIgYW5kICJzdGF0dXMtYXR0Ii4KRXhjZXB0IGFzIG5vdGVkIG90aGVyd2lzZSwgYWxsIGFs cGhhYmV0aWMgY2hhcmFjdGVycyBhcmUgY2FzZS0KaW5zZW5zaXRpdmUuICBUaGUgdXNlIG9mIHVw cGVyIG9yIGxvd2VyIGNhc2UgY2hhcmFjdGVycyB0byBkZWZpbmUKdG9rZW4gc3RyaW5ncyBpcyBm b3IgZWRpdG9yaWFsIGNsYXJpdHkgb25seS4gIEltcGxlbWVudGF0aW9ucyBNVVNUCmFjY2VwdCB0 aGVzZSBzdHJpbmdzIGluIGEgY2FzZS1pbnNlbnNpdGl2ZSBmYXNoaW9uLgogICAgCmFwcGVuZGxp bWl0LWNhcCA9ICJBUFBFTkRMSU1JVCIgWyI9IiBudW1iZXJdCmNhcGFiaWxpdHkgLz0gYXBwZW5k bGltaXQtY2FwCgphcHBlbmRsaW1pdC1yZXNwY29kZSA9ICJBUFBFTkRMSU1JVCIgU1AgbnVtYmVy CnJlc3AtdGV4dC1jb2RlIC89IGFwcGVuZGxpbWl0LXJlc3Bjb2RlCgphcHBlbmRsaW1pdC1zdGF0 dXMtYXR0ID0gIkFQUEVORExJTUlUIgpzdGF0dXMtYXR0IC89YXBwZW5kbGltaXQtc3RhdHVzLWF0 dAoKQSBudW1iZXIgaW5kaWNhdGluZyB0aGUgZml4ZWQgbWF4aW11bSBtZXNzYWdlIHNpemUgaW4g Ynl0ZXMgdGhhdCB0aGUKc2VydmVyIHdpbGwgYWNjZXB0LiAgQVBQRU5ETElNSVQ9MCBpbmRpY2F0 ZXMgdGhlIHNlcnZlciBTSEFMTCBub3QKYWNjZXB0IEFQUEVORCBjb21tYW5kIGR1ZSB0byBzaXpl IHJlc3RyaWN0aW9uLiAgVGhlIHN5bnRheCBvZiB0aGUKcGFyYW1ldGVyIGZvbGxvd3MgdGhlIGF1 Z21lbnRlZCBCTkYgbm90YXRpb24gb2YgW1JGQzUyMzRdLiAgSWYgdGhpcwpjYXBhYmlsaXR5IGlz IG9taXR0ZWQsIG5vIGluZm9ybWF0aW9uIGlzIGNvbnZleWVkIGFib3V0IHRoZSBzZXJ2ZXIncwpm aXhlZCBtYXhpbXVtIG1haWwgdXBsb2FkIHNpemUuCkpheWFudGhlZXNoICYgTmFyZW5kcmEgICAg ICAgRXhwaXJlcyBKdWx5LCAyMDE1ICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgSU1BUCBBUFBFTkRMSU1JVCAgICAgICAgICAgIEphbnVhcnkgMjAx NQoKNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbgoKSXQgaXMgYmVsaWV2ZWQgdGhhdCB0aGlzIGV4 dGVuc2lvbiBkb2Vzbid0IGFkZCBhbnkgbmV3IHNlY3VyaXR5CmNvbnNpZGVyYXRpb25zIHRoYXQg YXJlIG5vdCBhbHJlYWR5IHByZXNlbnQgaW4gdGhlIGJhc2UgSU1BUApwcm90b2NvbCBbUkZDMzUw MV0uCgo3LiBJQU5BIENvbnNpZGVyYXRpb25zCgpUaGUgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYWRk IEFQUEVORExJTUlUIHRvIHRoZSBJTUFQNCBDYXBhYmlsaXRpZXMKUmVnaXN0cnkuICBbW05vdGUg dG8gUkZDLWVkaXRvcjogcGxlYXNlIHJlbW92ZSB0aGUgZm9sbG93aW5nIGJlZm9yZQpwdWJsaWNh dGlvbjogVGhpcyByZWdpc3RyYXRpb24gc2hvdWxkIHRha2UgcGxhY2UgYXQgdGhlIGZvbGxvd2lu Zwpsb2NhdGlvbjogaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9pbWFwNC1jYXBhYmls aXRpZXNdXQoKOC4gUmVmZXJlbmNlcwoKOC4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgpUaGUgZm9s bG93aW5nIGRvY3VtZW50cyBjb250YWluIGRlZmluaXRpb25zIG9yIHNwZWNpZmljYXRpb25zIHRo YXQKYXJlIG5lY2Vzc2FyeSB0byB1bmRlcnN0YW5kIHRoaXMgZG9jdW1lbnQgcHJvcGVybHkKCltS RkMyMTE5XSAgQnJhZG5lciwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUK ICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBSRkMgMjExOSwgSGFydmFyZCBVbml2ZXJz aXR5LCBNYXJjaAogICAgICAgICAgIDE5OTcuCiAgICAgICAgICAgCltSRkMzNTAxXSAgQ3Jpc3Bp biwgIklOVEVSTkVUIE1FU1NBR0UgQUNDRVNTIFBST1RPQ09MIC0gVkVSU0lPTiA0cmV2MSIsCiAg ICAgICAgICAgVW5pdmVyc2l0eSBvZiBXYXNoaW5ndG9uLCBNYXJjaCAyMDAzCgpbUkZDNTIzNF0g IENyb2NrZXIsIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgKICAgICAgICAgICBT cGVjaWZpY2F0aW9uczogQUJORiIsIFJGQyA1MjM0LCBCcmFuZGVuYnVyZwogICAgICAgICAgIElu dGVybmV0d29ya2luZywgRGVtb24gSW50ZXJuZXQgTHRkLCBKYW51YXJ5IDIwMDgKCltSRkM1MzIy XSAgUC4gUmVzbmljaywgRWQsICJJbnRlcm5ldCBNZXNzYWdlIEZvcm1hdCIsIFJGQyA1MzIyLAog ICAgICAgICAgIFF1YWxjb21tIEluY29ycG9yYXRlZCwgT2N0b2JlciAyMDA4CgpbUkZDMjA4OF0g IEouIE15ZXJzLCBDYXJuZWdpZSBNZWxsb24sICJJTUFQNCBub24tc3luY2hyb25pemluZwogICAg ICAgICAgIGxpdGVyYWxzIiwgIEphbnVhcnkgMTk5NwoJCSAgIApbUkZDNDQ2OV0gIFAuIFJlc25p Y2ssICJJbnRlcm5ldCBNZXNzYWdlIEFjY2VzcyBQcm90b2NvbCAoSU1BUCkKICAgICAgICAgICBD QVRFTkFURSBFeHRlbnNpb24iLCAgQXByaWwgMjAwNgoJCSAgIApbUkZDNTgxOV0gIEEuIE1lbG5p a292LCBULiBTaXJhaW5lbiwgIklNQVA0IEV4dGVuc2lvbiBmb3IgUmV0dXJuaW5nCiAgICAgICAg ICAgU1RBVFVTIEluZm9ybWF0aW9uIGluIEV4dGVuZGVkIExJU1QiLCAgTWFyY2ggMjAxMAoJCSAg IApbUkZDNTI1OF0gIEEuIE1lbG5pa292LCBCLiBMZWliYSwgIkludGVybmV0IE1lc3NhZ2UgQWNj ZXNzIFByb3RvY29sCiAgICAgICAgICAgdmVyc2lvbiA0IC0gTElTVCBDb21tYW5kIEV4dGVuc2lv bnMiLCAgTWFyY2ggMjAxMAoKCgkJICAgCkpheWFudGhlZXNoICYgTmFyZW5kcmEgICAgICAgRXhw aXJlcyBKdWx5LCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgIElNQVAgQVBQRU5ETElNSVQgICAgICAgICAgICAgSmFudWFyeSAyMDE1CgkJ ICAgCjguIDIgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKVGhlIGZvbGxvd2luZyBkb2N1bWVudHMg ZGVzY3JpYmUgcmVsYXRlZCBwcm90b2NvbHM6CgpbUkZDMjA4N10gIE15ZXJzLCBKLiwgIklNQVA0 IFFVT1RBIGV4dGVuc2lvbiIsIFJGQyAyMDg3LAogICAgICAgICAgIEphbnVhcnkgMTk5NwoKW1JG QzczNzddICBCLiBMZWliYSwgQS4gTWVsbmlrb3YsICJJTUFQNCBNdWx0aW1haWxib3ggU0VBUkNI CiAgICAgICAgICAgRXh0ZW5zaW9uIiwgUkZDIDczNzcsIE9jdG9iZXIgMjAxNAoKOS4gQWNrbm93 bGVkZ2VtZW50CgpUQkQKCgoxMC4gQXV0aG9yJ3MgQWRkcmVzcwoKSmF5YW50aGVlc2ggUyBCClNh bXN1bmcgVGVsZWNvbW11bmljYXRpb25zIEFtZXJpY2EsCjY4NSBVUyBIaWdod2F5IDIwMi8yMDYs CkJyaWRnZXdhdGVyLCBOSiAwODgwNy4KVVNBCkVtYWlsOiBqYXlhbnRoZWVzaC5zYkBnbWFpbC5j b20KCk5hcmVuZHJhIFNpbmdoIEJpc2h0ClNhbXN1bmcgVGVsZWNvbW11bmljYXRpb25zIEFtZXJp Y2EsCjY4NSBVUyBIaWdod2F5IDIwMi8yMDYsCkJyaWRnZXdhdGVyLCBOSiAwODgwNy4KVVNBCkVt YWlsOiBuYXJlbmRyYXNpbmdoLmJpc2h0QGdtYWlsLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgkKCQoJ CgkKCgkKCQoJCgkKCQoJCkpheWFudGhlZXNoICYgTmFyZW5kcmEgICAgICAgRXhwaXJlcyBKdWx5 LCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgNl0= --_002_02454F842DD7B449B96715A2AD90C0364F2A5560exMB6telecomsna_--