From nobody Sun Jul 1 00:55:27 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59908129C6A for ; Sun, 1 Jul 2018 00:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=le5KAmsR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OPLWr+rd 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 X5OBzsFZS_fs for ; Sun, 1 Jul 2018 00:55:24 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A37B130EC9 for ; Sun, 1 Jul 2018 00:55:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C784021910; Sun, 1 Jul 2018 03:55:23 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 01 Jul 2018 03:55:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xrwbzk 2AFvN4kpQpgc1qJQEOzZvVqeS1bRun62YfoxQ=; b=le5KAmsRYqnWjYfYvQDX6G aXyPSCqB491kEwcywZc5NnmZcfpYZtqD2HUymeHRJ4kfS0ToYQ8Kob/h8o2NuBBw hKJU7aSVak6rRVYOwyqkD4roMUVfXTkgQaKwDI4QTcDHkORk4sGsqc/pbNE/xCPb Zj+3kC8cusz/A0spRdkHSSpXCa45vMvaL/4jPPjvi5ZnoIlTuqj7P4qpiCT6CwGY 5FjUCbx6n0fpsNWqZJ2t8zUfesu5+yy98wWWFatTAAsKQaZKz5z6WtuhAl/boqc8 e8/oCq8tLv5ZyILGBgFL4Vfok9FSoF1M9Wi6jsxfbUSzSbG3tB+IS/Dzsyn80eKw == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xrwbzk 2AFvN4kpQpgc1qJQEOzZvVqeS1bRun62YfoxQ=; b=OPLWr+rdvZ5gQ2aTLpY0P5 hslK8FDh05zsXaW9UKf67ijCr2jtjgn4xR0xVsHlBmH3MJ/c6zDIfYNwTxLjHGYQ srygGog644yjvlZN13FOtsNZwK2ibXj34//Y/Z/CIO6P4lIkL+cQ0r3k/tZMLM/1 7e4HA28lIEE7NVXVrxmuacF443SDveCNCbWSaclZ7+DFGMiHyO+L74gK7iGpUcEc 9OFEeR2AYvjZfxtlqXWrq3X1v4XtTeVFnIGgO7fHZBXK1bqh0ugI6TO36GxsEaMJ zazIz7XPFNAtFj1QDk/G7oZomklVWNQ8sjSK5FtAl2wWrV47hjJj4jiDL4JLddPA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6DECB621DC; Sun, 1 Jul 2018 03:55:23 -0400 (EDT) Message-Id: <1530431723.3654473.1426157152.04E58508@webmail.messagingengine.com> From: Bron Gondwana To: Timo Sirainen Cc: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153043172336544730" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> <1530365202.3385073.1425646120.01C42B5A@webmail.messagingengine.com> In-Reply-To: Date: Sun, 01 Jul 2018 17:55:23 +1000 Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 07:55:27 -0000 This is a multi-part message in MIME format. --_----------=_153043172336544730 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Yeah, fair enough. I guess I should write up global modseq first and only propose this as part of that or something. I will write it up anyway just as a secondary description of how we're doing it in Cyrus to support the jmap changes. Bron. On Sun, Jul 1, 2018, at 09:11, Timo Sirainen wrote: > On 30 Jun 2018, at 16.26, Bron Gondwana > wrote:>> >> On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote: >>> On 30 Jun 2018, at 7.13, Bron Gondwana >>> wrote:>>>> >>>> I'm working on a doc (and implementation) for an extension to >>>> RFC7162 - CREATEDMODSEQ. It adds said field on both mailboxes and >>>> emails.>>> >>> What's your planned use case(s) for this? I can't really think >>> of any.>> >> So the main use-case I'm working with at the moment is "phone client >> wants to create a notification to user of new mail, but NOT throw up >> a new mail notification if the user just moved an email from Inbox to >> a notified folder in another client". So the phone client needs to >> be able to distinguish "this message has newly arrived in the >> mailstore" vs "this message has just been updated in some way".> > This requires the global modseq space for it to work. Also, an > alternative to this feature might be to just auto-add some $Copied / > $Moved keyword..> >> This piece of data is also being used in JMAP to underly the >> calculation for whether a message (or thread) should be in the added >> or changed result.> > I tried quickly looking at the jmap spec to see what exactly these > meant, but didn't find it. So I guess copying/moving would be better > as "changed" then? Again for the same reason of not showing > notifications of copied/moved mails?> >> And likewise for mailboxes, the createdmodseq on mailboxes is used to >> distingish between "got renamed" and "newly created".> Nice, but again I don't really see how clients would use this. > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153043172336544730 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Yeah, fair enough. I guess I should write up global modseq first and only propose this as part of that or something.

I will write it up anyway just as a secondary description of how we're doing it in Cyrus to support the jmap changes.

Bron.


On Sun, Jul 1, 2018, at 09:11, Timo Sirainen wrote:
On 30 Jun 2018, at 16.26, Bron Gondwana <brong@fastmailteam.com> wrote:

On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote:
On 30 Jun 2018, at 7.13, Bron Gondwana <brong@fastmailteam.com> wrote:

I'm working on a doc (and implementation) for an extension to RFC7162 - CREATEDMODSEQ.  It adds said field on both mailboxes and emails. 

What's your planned use case(s) for this? I can't really think of any.

So the main use-case I'm working with at the moment is "phone client wants to create a notification to user of new mail, but NOT throw up a new mail notification if the user just moved an email from Inbox to a notified folder in another client".  So the phone client needs to be able to distinguish "this message has newly arrived in the mailstore" vs "this message has just been updated in some way".

This requires the global modseq space for it to work. Also, an alternative to this feature might be to just auto-add some $Copied / $Moved keyword..

This piece of data is also being used in JMAP to underly the calculation for whether a message (or thread) should be in the added or changed result.

I tried quickly looking at the jmap spec to see what exactly these meant, but didn't find it. So I guess copying/moving would be better as "changed" then?  Again for the same reason of not showing notifications of copied/moved mails?

And likewise for mailboxes, the createdmodseq on mailboxes is used to distingish between "got renamed" and "newly created".
Nice, but again I don't really see how clients would use this.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--_----------=_153043172336544730-- From nobody Mon Jul 2 20:45:57 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4BB130EFC for ; Mon, 2 Jul 2018 20:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 MSgNaDUtwTd6 for ; Mon, 2 Jul 2018 20:45:53 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 5C145130EF9 for ; Mon, 2 Jul 2018 20:45:52 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w633jj3T169732; Tue, 3 Jul 2018 03:45:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2017-10-26; bh=k+bSjK9/1u9FoQJC5cDubvxKWdMxNwSJz4uU3HBUQXA=; b=E7rCmvJhMs2WhxBG2pbvNAk16y1mw0L0J5gfdH9g202wPH14tj/G+NW9gy602C6ZON1k 4CRD4NHolmaFAbzECgTsk89TyzsG7MenRVgNyB9nmtEw9IA7b1uepD+ZNOUBjkdKD8PQ teK8JHedjWYCsRy5YF3VM90WYAmq9HE9icylffmNedYPSAiHAOJkl1gSJcRwsUvcYcpV dp8itP3Kt1U0tTo16UNH/sfb7i4nuYd0lo3pymzu2hmTZEkmsYsYpLPuyqGmlalEhygm 0uEkYrRU6VBBBHk+t01TC2Wm/VE6skeVaMbcd/aCJCabEtVkH6PLUPgNyVwrvrFQVAF7 3w== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2jx2gpxqub-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Jul 2018 03:45:44 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w633jhWD017629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Jul 2018 03:45:44 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w633jhuZ021730; Tue, 3 Jul 2018 03:45:43 GMT Received: from [10.145.183.26] (/10.145.183.26) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Jul 2018 20:45:43 -0700 From: "Chris Newman" To: "Stuart Brandt" Cc: "Bron Gondwana" , extra@ietf.org Date: Mon, 02 Jul 2018 20:45:39 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <3CF9D7B5-42BE-44F8-92D7-7BDA9A163CC3@oracle.com> In-Reply-To: <5B37DBE7.5070809@aol.com> References: <1527812408.1624623.1392443640.48DE67C7@webmail.messagingengine.com> <5B37DBE7.5070809@aol.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8942 signatures=668704 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=866 adultscore=2 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030043 Archived-At: Subject: Re: [Extra] Bringing REPLACE back X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 03:45:55 -0000 I'm not a fan of adding parallel commands when there's a documented syntax extension model, especially for the APPEND command. I'd suggest a syntax more like this (following RFC 4466 model): A004 APPEND Drafts (\Seen \Draft) UIDREPLACE 2000 {350} ... Also the ABNF is simpler (and you don't have to fix the incompatibility of your ABNF with RFC 4466): capability =/ "REPLACE" append-ext =/ "UIDREPLACE" SP uniqueid If you extend the command rather than adding a parallel command, then interaction with certain extensions (like CATENATE and UIDPLUS) becomes much simpler. Other notes: * the example is inconsistent -- the APPENDUID response should always have a UID higher than the replaced UID. * this needs to document interaction with the OBJECTID extension. * this needs to state whether this is available in AUTHENTICATED state vs. SELECTED state. I think it's slightly simpler if the UIDREPLACE extension is only available in SELECTED state, but I can implement it either way. * I'd also prefer that this only support UIDs and not use message sequence numbers. Having an APPEND-like command that has pipelining sequencing problems like non-UID FETCH seems like it would add unnecessary complexity to the protocol. * your example is inconsistent with the text in section 4.3; however I'm unsure that restriction is really helpful -- it might be better to encourage clients to robustly handle either order. Although I don't plan to implement this in the near term, I'd much prefer it be standardized if the need arises so I support adoption by EXTRA. I think the extension has subtleties that will benefit from standards processing. - Chris On 30 Jun 2018, at 12:37, Stuart Brandt wrote: > An updated draft-brandt-imap-replace-03.txt is now available > From nobody Tue Jul 3 03:34:01 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11963130E29 for ; Tue, 3 Jul 2018 03:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 1A9CNJQXvQu2 for ; Tue, 3 Jul 2018 03:33:57 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id BD7FB130DCE for ; Tue, 3 Jul 2018 03:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1530614036; d=isode.com; s=june2016; i=@isode.com; bh=bQeRiMxNxWL4JamBEq5ujrhOgLLOrg6OStxmJeVKmT0=; 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=Evjp6eeog/F0JAOrel+uniBqM0vPu6+h2kHlz6DZIvr/l03PlqmBnhIjPD3DSBIdDgBw3E Nok2NQGPH8cQUd7XH6/FXYPT51aiOJKrhJtroWlwRkWPqXj+DW7pkWAlRJRTgDUNUulkCL Cmgq6Cm21AHqVBnylnepbrmHWrCr4LY=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 3 Jul 2018 11:33:56 +0100 From: Alexey Melnikov To: extra@ietf.org, Bron Gondwana Message-ID: Date: Tue, 3 Jul 2018 11:33:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: [Extra] AD review of draft-ietf-extra-imap-objectid-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 10:33:59 -0000 Hi all, This document is in a good state, so I've started the IETF LC on it. In the meantime, here are some comments for discussion: Last para of Section 1: This extension also adds an optional thread identifier (THREADID) to messages, which can be used by the server to indicate messages which it has identified to be related. Can you provide any advice here for a server implementation that doesn't implement THREAD extension? 2nd para of Section 5.1: The server SHOULD return the same EMAILID for the same UID triple. As with MAILBOXID above, this is almost a MUST, but allows for the possibility of loss of OBJECTID data in disaster recovery without Did you mean EMAILID above? having to change UIDVALIDITY. Next to the last para in Section 5.2: THREADID is optional, if the server is unable to calculate relationships between messages, Or if THREAD extension is not supported? Maybe call this out explicitly? it MUST return NIL to in all FETCH responses for the THREADID data item, and a SEARCH for THREADID MUST NOT match any messages. In Section 7: fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID NIL ; follows tagged-ext production from [RFC4466] This is not syntactally valid (missing terminating <">). I think it should be: fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID" SP NIL ; follows tagged-ext production from [RFC4466] In Section 11, 2nd and 3rd paras: If a digest is used for ID generation, it must have a collision resistent property, so server implementations are advised to monitor current security research and choose secure digests. This all sounds nice, but is it actually actionable? Any considerations for hash migration? The use of a digest for ID generation may be used as proof that a particular sequence of bytes was seen by the server. I think you might want to expand on what actions should be taken or what conclusions should be done here. I think the reference to RFC 5256 is Normative, as it is required in order to understand threading. Best Regards, Alexey From nobody Tue Jul 3 04:36:47 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3D5130E5C for ; Tue, 3 Jul 2018 04:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com 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 6VMospWgOuHA for ; Tue, 3 Jul 2018 04:36:42 -0700 (PDT) Received: from sonic303-3.consmr.mail.bf2.yahoo.com (sonic303-3.consmr.mail.bf2.yahoo.com [74.6.131.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF8D130E2A for ; Tue, 3 Jul 2018 04:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1530617801; bh=qccnDX+AZC1sH2XftHLOm3XCRlJinvTMXkIWoypQVPo=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=HBK4fHs1ahfb6+b5THX84ykKIMFqnpa82T2AfFUKXb3ZAxg1Z66QjU4njoCHNp87yARE27sys+C9RpJLhngLNzOdWFE2vh031gLPZfhQBMCyCNFdH34XEFT1iQdnN4RRpEsnOgWV0KLHoHg7D0w9/ITL/5ir+fB7+raAzz+t500eEOdxVrXIYw2dt420JsSKxfDf/oZcpQziwjIwewTmTspfE7szR15ifOJJCIlCXYGotPI4npaynxzpzO5CcwBNo6rbrD4M1s+NChxFASB7sJH6sx9EYVX6iYS7+fSSyTdefu/Y8aATfRWUC4w2fE4/uI9O1kEwn1z+nhvRfzHYiQ== X-YMail-OSG: Dc4jJwEVM1k.sJLahJ4NtUoEpePqWMJO9HptF7kNl_FIG1NCZ8K2deOy5342zI5 DlgPzZfckw8f7aECj8FjadHEHnCMTyk8lIBOyEbCi4Wq_MUF.FSSCJq7L9.tw1l.Y2YbsE4HvpW9 D4F8Ui0uq1Y._7G0tqiMl8cG5TqK1fEeFeCPa8yekI8uaIpwsVg2fBj2LC912S7BGN88e1fJKFtx cChsObxzhSGf2bAIwqVe05Xl7DkMtg1SsrceNO.IfET8.stJhNsJHQ1ZJ1S1k6pC.qPkZXqJhnrI JQxR3s_6dZbCJafpnnjpLSl5Gd0qvdrcdmw8AvA4zHMkw3MiiKre3oP4VCRHOokjXuTIm.WN_qqB x0QBAwWPazyFdZ4HcMjOV4T07JsY9QvMyEfatHRhM3PL6MzbCsK_Pgd4mlrqENPZudKrzvmiOCPX eIUYfus1x7JIt7yZVSMzzDYTghBYWlHmPzxbqlTHoHB5ETz7wgftgFX9DuJV1rWepu1a2eDzO3_n mRI2M3KyE1ksg5oefc9r0_bXlynh2tBcx76KO.81nHdACU1jNNRT6oYC1iQhd5g4o8Xl_i555O8H hTqTsr2IsAz4qSFox6zzr12cpCPcU1xQMj9z_uHsJHqYOhgX7zgFQuDImUq7e6WJwm0RiJ6wi2ek 1xJ7wHf7aCIbbgm7H22zINuCyJ9jmTXUGiC1A2_Eh3bnq2NDUN_p0HxCeS8tpCvm_.M7CPvYXKS6 WC5EPH2QgJtaI2Blkm30_AOtvvfDOAsv9H5QuQYhj4M_vvPu2ryK_pwD.FptTVuBSH63qB9F5Qj3 YPaVCawMy1ACePTJp12RrhYRi._HfkFClm.xQ.A8uvXBvULB2JejHhErtw2MC42g9l7XTc6H1NW2 .GhQRk0A6ke3Zh6kx4xtgw_vlNt8NwYMDjNllyENfT8sD1fl4mT9AcJRf6tQgQI0twoH8F7.OCbU dUzNPdImkpDtV Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Tue, 3 Jul 2018 11:36:41 +0000 Received: from pool-70-106-192-253.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.192.253]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 08c537bb42442f6659b59020521dbf7c; Tue, 03 Jul 2018 11:36:39 +0000 (UTC) Message-ID: <5B3B5FB1.6090603@aol.com> Date: Tue, 03 Jul 2018 07:36:17 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Chris Newman CC: Bron Gondwana , extra@ietf.org References: <1527812408.1624623.1392443640.48DE67C7@webmail.messagingengine.com> <5B37DBE7.5070809@aol.com> <3CF9D7B5-42BE-44F8-92D7-7BDA9A163CC3@oracle.com> In-Reply-To: <3CF9D7B5-42BE-44F8-92D7-7BDA9A163CC3@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Bringing REPLACE back X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 11:36:46 -0000 Thanks, Chris. Comments below On 7/2/2018 11:45 PM, Chris Newman wrote: > I'm not a fan of adding parallel commands when there's a documented > syntax extension model, especially for the APPEND command. I'd suggest a > syntax more like this (following RFC 4466 model): > > A004 APPEND Drafts (\Seen \Draft) UIDREPLACE 2000 {350} ... > > Also the ABNF is simpler (and you don't have to fix the incompatibility > of your ABNF with RFC 4466): > capability =/ "REPLACE" > > append-ext =/ "UIDREPLACE" SP uniqueid > > If you extend the command rather than adding a parallel command, then > interaction with certain extensions (like CATENATE and UIDPLUS) becomes > much simpler. Use of REPLACE for the 3 command sequence is consistent with use of MOVE (rfc6851) for a similar 3 command sequence. It also avoids state machine confusion since REPLACE, unlike APPEND, is not valid in authenticated state (see section 3.5). > > Other notes: > * the example is inconsistent -- the APPENDUID response should always > have a UID higher than the replaced UID. I thought I had covered this with 2000 being the replaced UID and 2001 being the new UID. Did I get the syntax wrong? > * this needs to document interaction with the OBJECTID extension. Will do. Since REPLACE is an encapsulation of APPEND/STORE/EXPUNGE and since APPEND is going to inherently involve different message structure/bodyparts, the replacing message should have both a new MAILBOXID and new EMAILID. If client1 replaces message1 with message2, then client2 doesn't actually *have* message2 in its cache, so it will need to FETCH message2 if it wants to populate its cache. It would be good if we could solve this issue of having to reFETCH large attachments that already exist in a client's cache, but it seems like that might require an OBJECTID like extension targeted at bodyparts rather than full messages. > * this needs to state whether this is available in AUTHENTICATED state > vs. SELECTED state. I think it's slightly simpler if the UIDREPLACE > extension is only available in SELECTED state, but I can implement it > either way. Is there something additional needed in section 3.5? > * I'd also prefer that this only support UIDs and not use message > sequence numbers. Having an APPEND-like command that has pipelining > sequencing problems like non-UID FETCH seems like it would add > unnecessary complexity to the protocol. I too would prefer to not deal with sequence numbers, but I didn't want to break new ground in that regard compared to other IMAP commands and extensions. > * your example is inconsistent with the text in section 4.3; however I'm > unsure that restriction is really helpful -- it might be better to > encourage clients to robustly handle either order. Good catch. Thanks. > > Although I don't plan to implement this in the near term, I'd much > prefer it be standardized if the need arises so I support adoption by > EXTRA. I think the extension has subtleties that will benefit from > standards processing. > > - Chris > > On 30 Jun 2018, at 12:37, Stuart Brandt wrote: > >> An updated draft-brandt-imap-replace-03.txt is now available >> From nobody Tue Jul 3 09:03:06 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 924EA13103B; Tue, 3 Jul 2018 09:00:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: extra@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361658.4893.14740448038918527281.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:16 -0700 Archived-At: Subject: [Extra] extra - Requested session has been scheduled for IETF 102 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:25 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. extra Session 1 (2:00 requested) Friday, 20 July 2018, Afternoon Session I 1150-1320 Room Name: Notre Dame size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/extra.ics Request Information: --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dmarc regext dispatch dcrup doh uta Second Priority: oauth saag tls ace dnsop calext People who must be present: Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field Special Requests: One flipchart please --------------------------------------------------------- From nobody Tue Jul 3 09:25:00 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673E2130F6C for ; Tue, 3 Jul 2018 09:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 UkQAMqDa2nvM for ; Tue, 3 Jul 2018 09:24:55 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 44531131123 for ; Tue, 3 Jul 2018 09:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1530634659; d=isode.com; s=june2016; i=@isode.com; bh=XyCADnxmHj6PCP9cIdQP3HzHU3nJa0Zz71zgYxRHOMM=; 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=wutAq5JuQBX7E4K7u6Jt2Jmzu08USQrVCge4ev1TqJN6P2Fs4pS8nuGyD7MD4bKcAHmqkb OeJtLJkozm8WTo0X3+8SBesO930/VLVHXsChHjkVhlAL+QNMsrhlScuoDzxdRsDLwav3jA 55P+bY6gmoXzBk3tDYGFPfUavl7lzoU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 3 Jul 2018 17:17:39 +0100 To: extra@ietf.org References: <153063361658.4893.14740448038918527281.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: Date: Tue, 3 Jul 2018 17:17:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <153063361658.4893.14740448038918527281.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] extra - Requested session has been scheduled for IETF 102 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:24:59 -0000 Note that due to various people being unable to attend EXTRA will be moving to the Thursday DMARC slot (DMARC will cancel their meeting). On 03/07/2018 17:00, "IETF Secretariat" wrote: > Dear Liz Flynn, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > > extra Session 1 (2:00 requested) > Friday, 20 July 2018, Afternoon Session I 1150-1320 > Room Name: Notre Dame size: 50 > --------------------------------------------- > > > iCalendar: https://datatracker.ietf.org/meeting/102/sessions/extra.ics > > Request Information: > > > --------------------------------------------------------- > Working Group Name: Email mailstore and eXtensions To Revise or Amend > Area Name: Applications and Real-Time Area > Session Requester: Liz Flynn > > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 30 > Conflicts to Avoid: > First Priority: jmap dmarc regext dispatch dcrup doh uta > Second Priority: oauth saag tls ace dnsop calext > > > > People who must be present: > Alexey Melnikov > Jiankang Yao > Bron Gondwana > > Resources Requested: > Experimental Room Setup (U-Shape and classroom, subject to availability) > Flipcharts: please specify number in Special Requests field > > Special Requests: > One flipchart please > --------------------------------------------------------- > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Thu Jul 5 00:01:45 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F08130DDF for ; Thu, 5 Jul 2018 00:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WbRAFRpw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FcfNlEyU 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 tFk3q4LuBZyX for ; Thu, 5 Jul 2018 00:01:39 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB027128CF3 for ; Thu, 5 Jul 2018 00:01:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B4C9D1DD for ; Thu, 5 Jul 2018 03:01:37 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 05 Jul 2018 03:01:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3yhjxmmNLX7JdqVkJSiHrwbVFdwXYuhSrNG6c4tzi +c=; b=WbRAFRpwP5UFBFdIyvLEszdUsQIfKmddWQpzpFMocWIgu7V/zfn24qsh6 hCozlyOUXZ2/2ddtHXTCyyjEml4xL0um18S0QN0PQU3g7Teo7I5UwxqiMoNAKohG 7koiy3m2ntslpMO6kPVfF6l8/8nzOh+qeT7FplLXurcYLC9bsDcVT5pghWcXmnTk qdDFZYmyd9k8/sUVttdQHy6Qj4qhfETeCiwC2m/igWvU3yzOJISPt4zjP/0kUIAi Li+RXoM4dhSSNg12vtKK/m89Bn6lb+2hARM52SqJUP/fRT931FzxmTybiV7vtCme tJww0s96Xilv7YLrHZGjMzEEk84Lg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3yhjxmmNLX7JdqVkJSiHrwbVFdwXYuhSrNG6c4tzi +c=; b=FcfNlEyUU5P6Lh8QIunFu2Q9pHHqCbGWKl7fqg3U3UBBtkpU1juN8xlZY zMYmDkV2uqivcYBkM0ORKMYk+c5oWFzJO7FYfoR9PTeeyzdOhgiRuvTBDgnDq33w w3ZFLzGR0v+W8psRX6cWHbWZsZexRiLGNOoIDcBPFqmDbUnzsdbdae/M1xY+3igE 6+aVoqeo7brWhMBc67qbRjzuE1z7OftgTAWOdK3uIi5LRwNksT06iektKCEJIZ+I RXxMO4t6FvWRAdaOJ5lIuPNUA+EqLFYRYNuog6Y6txyCH7GJ/nRfDc0PyGmR8Yb1 5T2GXICFvfJaJEmjMCwQ8Qa1kjzpg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7AB17CA13D; Thu, 5 Jul 2018 03:01:36 -0400 (EDT) Message-Id: <29cf9229-99c7-456b-a538-0075c3e1d0df@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-707-gc22f408-next x-jmap-identity-id: 56629417 In-Reply-To: References: Date: Thu, 05 Jul 2018 03:01:35 -0400 From: Bron Gondwana To: extra@ietf.org Content-Type: multipart/mixed; boundary=03218ca7c59147f5803a66551b986bc0 Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-objectid-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 07:01:43 -0000 --03218ca7c59147f5803a66551b986bc0 Content-Type: multipart/alternative; boundary=e69f72534b944464bc3f0bb2d4ac856d --e69f72534b944464bc3f0bb2d4ac856d Content-Type: multipart/related; boundary=414b76d4e6294c94bf4f3f2ac519531b --414b76d4e6294c94bf4f3f2ac519531b Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018, at 20:34, Alexey Meln= ikov wrote:
Hi all,
This document is in a good state, so I've started the IETF LC= on it.

In the meantime, here are some comments for discuss= ion:

Last para of Section 1:

  &= nbsp; This extension also adds an optional thread identifier (THREADID) = to
    message= s, which can be used by the server to indicate messages which
<= div style=3D"font-family:Arial;">    it has identified to= be related.

Can you provide any advice here for a server= implementation that doesn't
= implement THREAD extension?

Sure thing :)

2nd para o= f Section 5.1:

    The server SHOULD retur= n the same EMAILID for the same UID triple.
    As with MAILBOXID above, this is almos= t a MUST, but allows for the
=     possibility of loss of OBJECTID data in disaster reco= very without

Did you mean EMAILID above?

No, but as the wording is unclear and confusing, I've just d= itched it.

    having to change UIDVALIDITY.

Next to= the last para in Section 5.2:

    THREADI= D is optional, if the server is unable to calculate
    relationships between messages,<= br>

Or if THREAD extension is not supported? Maybe call this = out explicitly?
=
Sure.

In Section 7:

&= nbsp;   fetch-threadid-resp =3D "THREADID" SP "(" objectid ")"= / "THREADID NIL
  =   ; follows tagged-ext production from [RFC4466]

Thi= s is not syntactally valid (missing terminating <">). I think it
should be:

&nbs= p;   fetch-threadid-resp =3D "THREADID" SP "(" objectid ")" / = "THREADID" SP NIL
  = ;  ; follows tagged-ext production from [RFC4466]

Fixed!  Ta for noticing.

<= div style=3D"font-family:Arial;">
In Section 11, 2nd and 3rd paras:

   = If a digest is used for ID generation, it must have a collision
    resistent propert= y, so server implementations are advised to monitor
    current security research and ch= oose secure digests.

This all sounds nice, but is it actu= ally actionable?

Well, no more than anything= is.

Any= considerations for hash migration?

luckily = it's pretty easy :)  But have added some text.


    The use of a digest for ID generation m= ay be used as proof that a
&n= bsp;   particular sequence of bytes was seen by the server.

I think you might want to expand on what actions should be = taken or what
conclusions sho= uld be done here.

Ick... yeah, it's hard to = give general advice.  Digest is handy in a bunch of situations, but= enumerating all possible risks is tricky.


I think the reference to RFC 5256 is Normative, as it is required= in
order to understand threa= ding.

=
Easy peasy!

Thanks Alex= ey,

Version -04 attached.  Sadly the draft submissio= n tool is currently closed in anticipation of IETF102, so I can't submit= it yet.  The commit is in git as well:


Cheers,

Br= on.
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com
=


--414b76d4e6294c94bf4f3f2ac519531b-- --e69f72534b944464bc3f0bb2d4ac856d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2018, at 20:34, Alexey Melnikov wrote: > Hi all, > This document is in a good state, so I've started the IETF LC on it. >=20 > In the meantime, here are some comments for discussion: >=20 > Last para of Section 1: >=20 > =C2=A0=C2=A0=C2=A0 This extension also adds an optional thread identif= ier (THREADID) to > =C2=A0=C2=A0=C2=A0 messages, which can be used by the server to indica= te messages which > =C2=A0=C2=A0=C2=A0 it has identified to be related. >=20 > Can you provide any advice here for a server implementation that doesn= 't > implement THREAD extension? Sure thing :) > 2nd para of Section 5.1: >=20 > =C2=A0=C2=A0=C2=A0 The server SHOULD return the same EMAILID for the s= ame UID triple. > =C2=A0=C2=A0=C2=A0 As with MAILBOXID above, this is almost a MUST, but= allows for the > =C2=A0=C2=A0=C2=A0 possibility of loss of OBJECTID data in disaster re= covery without >=20 > Did you mean EMAILID above? No, but as the wording is unclear and confusing, I've just ditched it. > =C2=A0=C2=A0=C2=A0 having to change UIDVALIDITY. >=20 > Next to the last para in Section 5.2: >=20 > =C2=A0=C2=A0=C2=A0 THREADID is optional, if the server is unable to ca= lculate > =C2=A0=C2=A0=C2=A0 relationships between messages, >=20 > Or if THREAD extension is not supported? Maybe call this out explicitl= y? Sure. > In Section 7: >=20 > =C2=A0=C2=A0=C2=A0 fetch-threadid-resp =3D "THREADID" SP "(" objectid = ")" / "THREADID NIL > =C2=A0=C2=A0=C2=A0 ; follows tagged-ext production from [RFC4466] >=20 > This is not syntactally valid (missing terminating <">). I think it > should be: >=20 > =C2=A0=C2=A0=C2=A0 fetch-threadid-resp =3D "THREADID" SP "(" objectid = ")" / "THREADID" SP NIL > =C2=A0=C2=A0=C2=A0 ; follows tagged-ext production from [RFC4466] Fixed!=C2=A0 Ta for noticing. >=20 > In Section 11, 2nd and 3rd paras: >=20 > =C2=A0=C2=A0=C2=A0 If a digest is used for ID generation, it must have= a collision > =C2=A0=C2=A0=C2=A0 resistent property, so server implementations are a= dvised to monitor > =C2=A0=C2=A0=C2=A0 current security research and choose secure digests= . >=20 > This all sounds nice, but is it actually actionable? Well, no more than anything is. > Any considerations for hash migration? luckily it's pretty easy :)=C2=A0 But have added some text. >=20 > =C2=A0=C2=A0=C2=A0 The use of a digest for ID generation may be used a= s proof that a > =C2=A0=C2=A0=C2=A0 particular sequence of bytes was seen by the server= . >=20 > I think you might want to expand on what actions should be taken or wh= at > conclusions should be done here. Ick... yeah, it's hard to give general advice.=C2=A0 Digest is handy in = a bunch of situations, but enumerating all possible risks is tricky. >=20 > I think the reference to RFC 5256 is Normative, as it is required in > order to understand threading. Easy peasy! Thanks Alexey, Version -04 attached.=C2=A0 Sadly the draft submission tool is currently= closed in anticipation of IETF102, so I can't submit it yet.=C2=A0 The = commit is in git as well: https://github.com/ietfextra/draft-gondwana-imap-uniqueid/commit/a3ea819= 3a0e7bffb21d81fc30a074bf8a1d7ae7a Cheers, Bron. -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --e69f72534b944464bc3f0bb2d4ac856d-- --03218ca7c59147f5803a66551b986bc0 Content-Disposition: attachment;filename="draft-ietf-extra-imap-objectid.txt" Content-Type: text/plain; name="draft-ietf-extra-imap-objectid.txt" Content-Transfer-Encoding: 7BIT EXTRA B. Gondwana, Ed. Internet-Draft FastMail Updates: 3501 (if approved) July 5, 2018 Intended status: Standards Track Expires: January 6, 2019 IMAP Extension for object identifiers draft-ietf-extra-imap-objectid-04 Abstract This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gondwana Expires January 6, 2019 [Page 1] Internet-Draft IMAP ObjectID July 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3 4. MAILBOXID object identifier . . . . . . . . . . . . . . . . . 3 4.1. New response code for CREATE . . . . . . . . . . . . . . 4 4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4 4.3. New attribute for STATUS . . . . . . . . . . . . . . . . 5 5. EMAILID object identifier and THREADID correlator . . . . . . 6 5.1. EMAILID identifier for identical messages . . . . . . . . 6 5.2. THREADID identifer for related messages . . . . . . . . . 6 5.3. New Message Data Items in FETCH and UID FETCH Commands . 7 6. New Filters on SEARCH command . . . . . . . . . . . . . . . . 9 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Implementation considerations . . . . . . . . . . . . . . . . 10 8.1. Assigning object identifiers . . . . . . . . . . . . . . 10 8.2. Interaction with special cases . . . . . . . . . . . . . 11 8.3. Client usage . . . . . . . . . . . . . . . . . . . . . . 11 9. Future considerations . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 12 12.2. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 13 12.3. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 13 12.4. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 13 12.5. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 13 12.6. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 14 12.7. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 14 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. Appendix 1: ideas for implementing object identifiers . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction IMAP stores are often used by many clients. Each client may cache data from the server so that they don't need to re-download information. [RFC3501] defines that a mailbox can be uniquely referenced by its name and UIDVALIDITY, and a message within that mailbox can be uniquely referenced by its mailbox (name + UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and UID is guaranteed to be immutable. Gondwana Expires January 6, 2019 [Page 2] Internet-Draft IMAP ObjectID July 2018 [RFC4315] defines a COPYUID response which allows a client which copies messages to know the mapping between the UIDs in the source and destination mailboxes, and hence update its local cache. If a mailbox is successfully renamed, the client knows that the same messages exist in the destination mailbox name as previously existed in the source mailbox name. The result is that the client which copies (or [RFC6851] moves) messages or renames a mailbox can update its local cache, but any other client connected to the same store can not know with certainty that the messages are identical, and so will re-download everything. This extension adds new properties to a message (EMAILID) and mailbox (MAILBOXID) which allow a client to quickly identify messages or mailboxes which have been renamed by another client. This extension also adds an optional thread identifier (THREADID) to messages, which can be used by the server to indicate messages which it has identified to be related. A server that does not implement threading will return NIL to all requests for THREADID. 2. Conventions Used In This Document In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. 3. CAPABILITY Identification IMAP servers that support this extension MUST include "OBJECTID" in the response list to the CAPABILITY command. 4. MAILBOXID object identifier The MAILBOXID is a server-allocated unique identifer for each mailbox. The server SHOULD return the same MAILBOXID for a mailbox with the same name and UIDVALIDITY. This is almost MUST, but weakened to allow for the possibility of loss of OBJECTID data during disaster recovery while still keeping the name and UIDVALIDITY the same. Gondwana Expires January 6, 2019 [Page 3] Internet-Draft IMAP ObjectID July 2018 The server MUST NOT report the same MAILBOXID for two mailboxes at the same time. The server MUST NOT reuse the same MAILBOXID for a mailbox which does not obey all the invarients that [RFC3501] defines for a mailbox which does not change name or UIDVALIDITY. The server MAY choose to create a MAILBOXID value in a way that does not survive RENAME (e.g. a digest of name + uidvalidity could be used), however the client then loses the major benefit of having an identifier. 4.1. New response code for CREATE This document extends the CREATE command to have the response code MAILBOXID on successful mailbox creation. A server advertising the OBJECTID capability MUST include the MAILBOXID response code in the tagged OK response to all successful CREATE commands. Syntax: "MAILBOXID" SP "(" ")" Response code in tagged OK for successful CREATE command. Example: C: 3 create foo S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Completed C: 4 create bar S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)] Completed C: 5 create foo S: 5 NO Mailbox already exists 4.2. New OK Untagged Response for SELECT and EXAMINE This document adds a new untagged response code to the SELECT and EXAMINE commands. A server advertising the OBJECTID capability MUST return an untagged OK response with the MAILBOXID response code on all successful SELECT and EXAMINE commands. Syntax: "OK" SP "[" "MAILBOXID" SP "(" ")" "]" text Untagged OK response to SELECT or EXAMINE. Example: Gondwana Expires January 6, 2019 [Page 4] Internet-Draft IMAP ObjectID July 2018 C: 27 select "foo" [...] S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok [...] S: 27 OK [READ-WRITE] Completed 4.3. New attribute for STATUS This document adds the MAILBOXID attribute to the STATUS command using the extended syntax defined in [RFC4466]. A server that advertises the OBJECTID capability MUST support the MAILBOXID status attribute. Syntax: "MAILBOXID" The attribute in the STATUS command. Syntax: "MAILBOXID" SP "(" ")" The response item in the STATUS response contains the objectid assigned by the server for this mailbox. Example: C: 6 status foo (mailboxid) S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) S: 6 OK Completed C: 7 status bar (mailboxid) S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) S: 7 OK Completed C: 8 rename foo renamed S: * OK rename foo renamed S: 8 OK Completed C: 9 status renamed (mailboxid) S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) S: 9 OK Completed C: 10 status bar (mailboxid) S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) S: 10 OK Completed When the LIST-STATUS IMAP capability defined in [RFC5819] is also available, the STATUS command can be combined with the LIST command. Example: Gondwana Expires January 6, 2019 [Page 5] Internet-Draft IMAP ObjectID July 2018 C: 11 list "" "*" return (status (mailboxid)) S: * LIST (\HasNoChildren) "." INBOX S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf)) S: * LIST (\HasNoChildren) "." bar S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)) S: * LIST (\HasNoChildren) "." renamed S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)) S: 11 OK Completed (0.001 secs 3 calls) 5. EMAILID object identifier and THREADID correlator This document defines the data items EMAILID and THREADID on messages. 5.1. EMAILID identifier for identical messages The EMAILID data item is an objectid which uniquely identifies the content of a single message. Anything which must remain immutable on a {name, uidvalidity, uid} triple must also be the same between messages with the same EMAILID. The server SHOULD return the same EMAILID for the same UID triple. This is almost a MUST, but allows for the possibility of loss of OBJECTID data in disaster recovery without having to change UIDVALIDITY. The server SHOULD return the same EMAILID for the exact same message content in different folders after a COPY or [RFC6851] MOVE command. The server MAY assign the same EMAILID as an existing message upon APPEND if it detects that the new message has exactly identical content to that existing message. 5.2. THREADID identifer for related messages The THREADID data item is an objectid which uniquely identifies a set of messages which the server believes should be grouped together when presented. THREADID calculation is generally based on some combination of References, In-Reply-To and Subject, but the exact logic is left up to the server implementation. [RFC5256] describes some algorithms that MAY be used, however this specfication does not mandate any particular strategy. The server MUST return the same THREADID for all messages with the same EMAILID. Gondwana Expires January 6, 2019 [Page 6] Internet-Draft IMAP ObjectID July 2018 The server SHOULD return the same THREADID for related messages even if they are in different mailboxes. THREADID is optional, if the server doesn't support THREADID or is unable to calculate relationships between messages, it MUST return NIL to in all FETCH responses for the THREADID data item, and a SEARCH for THREADID MUST NOT match any messages. The server MAY use the same objectid value for both EMAILID and THREADID, for example the THREADID could be the EMAILID of the first message that the server has seen in each thread. 5.3. New Message Data Items in FETCH and UID FETCH Commands This document defines two FETCH items: Syntax: EMAILID The EMAILID message data item causes the server to return EMAILID FETCH response data items. Syntax: THREADID The THREADID message data item causes the server to return THREADID FETCH response data items. And the following responses: Syntax: EMAILID ( ) The EMAILID response data item contains the server-assigned objectid for each message. Syntax: THREADID ( ) The THREADID response data item contains the server-assigned objectid for the set of related messages to which this message belongs. Syntax: THREADID NIL The NIL value to the THREADID response data item is returned when the server mailbox does not support THREADID calculation. Example: Gondwana Expires January 6, 2019 [Page 7] Internet-Draft IMAP ObjectID July 2018 C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733} [...] Subject: Message A Message-ID: [...] S: 5 OK [APPENDUID 1521475658 1] Completed C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793} [...] Subject: Re: Message A Message-ID: References: [...] S: 11 OK [APPENDUID 1521475658 2] Completed C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736} [...] Subject: Message C Message-ID: [...] S: 17 OK [APPENDUID 1521475658 3] Completed C: 22 fetch 1:* (emailid threadid) S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9)) S: * 2 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9)) S: * 3 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5)) S: 22 OK Completed (0.000 sec) C: 23 move 2 foo S: * OK [COPYUID 1521475659 2 1] Completed S: * 2 EXPUNGE S: 23 OK Completed C: 24 fetch 1:* (emailid threadid) S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9)) S: * 2 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5)) S: 24 OK Completed (0.000 sec) C: 25 select "foo" C: 25 select "foo" [...] S: 25 OK [READ-WRITE] Completed C: 26 fetch 1:* (emailid threadid) S: * 1 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9)) S: 26 OK Completed (0.000 sec) Example: (no THREADID support) Gondwana Expires January 6, 2019 [Page 8] Internet-Draft IMAP ObjectID July 2018 C: 26 fetch 1:* (emailid threadid) S: * 1 FETCH (EMAILID (M00000001) THREADID NIL) S: * 2 FETCH (EMAILID (M00000002) THREADID NIL) S: 26 OK Completed (0.000 sec) 6. New Filters on SEARCH command This document defines filters EMAILID and THREADID on the SEARCH command. EMAILID Messages whose EMAILID is exactly the specified objectid. THREADID Messages whose THREADID is exactly the specified objectid. Example: (as if run before the MOVE above when the mailbox had 3 messages) C: 27 search emailid M6d99ac3275bb4e S: * SEARCH 1 S: 27 OK Completed (1 msgs in 0.000 secs) C: 28 search threadid T64b478a75b7ea9 S: * SEARCH 1 2 S: 28 OK Completed (2 msgs in 0.000 secs) 7. Formal syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation. Elements not defined here can be found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and IMAP ABNF extensions [RFC4466] specifications. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper- or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "OBJECTID" fetch-att =/ "EMAILID" / "THREADID" fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged- ext production from [RFC4466] Gondwana Expires January 6, 2019 [Page 9] Internet-Draft IMAP ObjectID July 2018 fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID" NIL ; follows tagged-ext production from [RFC4466] objectid = 1*255(ALPHA / DIGIT / "_" / "-") ; characters in object identifiers are case ; significant resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ; incorporated before the expansion rule of ; atom [SP 1*] ; that appears in [RFC3501] search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid status-att =/ "MAILBOXID" status-att-value =/ "MAILBOXID" SP "(" objectid ")" ; follows tagged- ext production from [RFC4466] 8. Implementation considerations 8.1. Assigning object identifiers All objectid values are allocated by the server. In the interests of reducing the possibilities of encoding mistakes, objectids are restricted to a safe subset of possible byte values, and in order to allow clients to allocate storage, they are restricted in length. An objectid is a string of 1 to 255 characters from the following set of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. These characters are safe to use in almost any context (e.g. filesystems, URIs, IMAP atoms). For maximum safety, servers SHOULD also follow defensive allocation strategies to avoid creating risks where glob completion or data type detection may be present (e.g. on filesystems or in spreadsheets). In particular it is wise to avoid: o ids starting with - o ids starting with digits o ids which contain only digits o ids which differ only by ASCII case (A vs a) o the specific sequence of 3 characters NIL Gondwana Expires January 6, 2019 [Page 10] Internet-Draft IMAP ObjectID July 2018 A good solution to these issues is to prefix every ID with a single alphabetical character. 8.2. Interaction with special cases The case of RENAME INBOX may need special handling for unique ids. It is advisable (though not required) to have MAILBOXID be globally unique, but it is only required to be unique within messages offered to a single client login to a single server hostname. For example, a proxy which aggregates multiple independent servers MUST NOT advertise the OBJECTID capability unless it can guarantee that the backends will not use the same identifiers for different objects. 8.3. Client usage Servers that implement both RFC 6154 and this specification SHOULD optimize their execution of command like UID SEARCH OR EMAILID 1234 EMAILID 4321. Clients can assume that searching the all-mail mailbox using OR/ EMAILID or OR/THREADID is a fast way to find messages again if some other client has moved them out of the mailbox where they were previously seen. Clients that cache data offline SHOULD fetch the EMAILID of all new messages to avoid re-downloading already cached message details. Clients SHOULD fetch the MAILBOXID for any new mailboxes before discarding cache data for any mailbox which is no longer present on the server, so that they can detect renames and avoid re-downloading data. 9. Future considerations This extension is intentionally defined to be compatible with the data model in [I-D.ietf-jmap-mail]. A future extension could be proposed to give a way to SELECT a mailbox by MAILBOXID rather than name. An extension to allow fetching message content directly via EMAILID and message listings by THREADID could be proposed. Gondwana Expires January 6, 2019 [Page 11] Internet-Draft IMAP ObjectID July 2018 10. IANA Considerations IANA is requested to add "OBJECTID" to the "IMAP Capabilities" registry located at . IANA is requested to add "MAILBOXID" to the "IMAP Response Codes" registry located at with a Reference of [[THIS RFC]]. 11. Security Considerations It is strongly advised that servers generate OBJECTIDs which are safe to use as filesystem names, and unlikely to be auto-detected as numbers. See implementation considerations. If a digest is used for ID generation, it must have a collision resistent property, so server implementations are advised to monitor current security research and choose secure digests. As the IDs are generated by the server, it should be possible to migrate to a new hash by just creating new IDs with the new algorithm. This is particularly true if a prefix is used on each ID, which can be changed when the algorithm changes. The use of a digest for ID generation may be used as proof that a particular sequence of bytes was seen by the server, however this is only a risk if IDs are leaked to clients who don't have permission to fetch the data directly. Servers that are expected to handle highly sensitive data should consider using a ID generation mechanism which doesn't derive from a digest. 12. Changes To be removed by the editor before publication 12.1. draft-ietf-extra-imap-objectid-03 o added RFC3501 to Abstract o updated [[THIS RFC]] to not fail idnits o changed jmap-mail to be informative rather than normative o shortened IDs to stop wrapping and outdents in IMAP examples Gondwana Expires January 6, 2019 [Page 12] Internet-Draft IMAP ObjectID July 2018 12.2. draft-ietf-extra-imap-objectid-02 o added "Client usage" section 12.3. draft-ietf-extra-imap-objectid-01 o added "updates" for RFC3501 o fixed domains in thread example o described threading in more detail o added IANA request for Response Code o clarified RFC2119 references o simplified some waffle in wording o added security consideration to choose good digest o added MAILBOXID-UID suggestion for EMAILID generation o updated ABNF normative reference to RFC5234 12.4. draft-ietf-extra-imap-objectid-00 o renamed draft to be objectid rather than uniqueid o renamed UNIQUEID (capability) to OBJECTID o restricted objectid to 64 safe characters o added security considerations and advice about choosing objectid o wrapped all responses in () for RFC4466 compatibility o signifiant rewrite of all sections 12.5. draft-ietf-extra-imap-uniqueid-00 o renamed draft to be an EXTRA document o added example for LIST RETURN STATUS o started work on ABNF o attempted to add response codes for EMAILID and THREADID Gondwana Expires January 6, 2019 [Page 13] Internet-Draft IMAP ObjectID July 2018 12.6. draft-gondwana-imap-uniqueid-01 o renamed UNIQUEID (status item) to MAILBOXID o renamed MSGID to EMAILID o renamed THRID to THREADID o added TODO section 12.7. draft-gondwana-imap-uniqueid-00 o initial upload with names UNIQUEID/MSGID/THRID 13. Acknowledgments The EXTRA working group at IETF. In particular feedback from Arnt Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek. The Gmail X-GM-THRID and X-GM-MSGID implementation as currently defined at . Dovecot X-GUID implementation. 13.1. Appendix 1: ideas for implementing object identifiers Ideas for implementing MAILBOXID: o Digest of (MailboxName/UIDVALIDITY) - not kept when renaming, but is guaranteed unique and doesn't require storage. o [RFC4122] UUID o Server assigned sequence number (guaranteed not to be reused) Ideas for implementing EMAILID: o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying messages, but is guaranteed unique and doesn't require storage. o Concatenation of MAILBOXID-UID - for servers which store MAILBOXID but not EMAILID. o Digest of message content (RFC822 bytes) - expensive unless cached o [RFC4122] UUID Gondwana Expires January 6, 2019 [Page 14] Internet-Draft IMAP ObjectID July 2018 o Server assigned sequence number (guaranteed not to be reused) Ideas for implementing THREADID: o Derive from EMAILID of first seen message in the thread. o [RFC4122] UUID o Server assigned sequence number (guaranteed not to be reused) There is a need to index and look up reference/in-reply-to data at message creation to efficiently find matching messages for threading. Threading may be either across folders, or within each folder only. The server has significant leeway here. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, December 2005, . [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, DOI 10.17487/RFC5256, June 2008, . Gondwana Expires January 6, 2019 [Page 15] Internet-Draft IMAP ObjectID July 2018 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for Returning STATUS Information in Extended LIST", RFC 5819, DOI 10.17487/RFC5819, March 2010, . [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, . 14.2. Informative References [I-D.ietf-jmap-mail] Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-06 (work in progress), July 2018. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . Author's Address Bron Gondwana (editor) FastMail Level 2, 114 William St Melbourne VIC 3000 Australia Email: brong@fastmailteam.com URI: https://www.fastmail.com Gondwana Expires January 6, 2019 [Page 16] --03218ca7c59147f5803a66551b986bc0-- From nobody Thu Jul 5 21:35:47 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BFA130E99 for ; Thu, 5 Jul 2018 21:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JJAuIYhd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VGR++7N+ 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 I7Lhkh5nGTYa for ; Thu, 5 Jul 2018 21:35:43 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09076130E93 for ; Thu, 5 Jul 2018 21:35:42 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.west.internal (Postfix) with ESMTP id D419526B for ; Fri, 6 Jul 2018 00:35:41 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 06 Jul 2018 00:35:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=BLcHPuDluFJpKIEAD SO4TfdHTvOYaTnLX2uXWuubZlg=; b=JJAuIYhdVKYcZv9sMYT3mUSrYWc3p24aj HikA+wp8Ubpw5WRJjAkZ5F8OLD9j3sGVFAd7bSC81Kp9dC/4MuntPypvlqy3GUwJ R3lAFZdh0gd/4bub7EIqPf0pSQZ3X9UvINF7kEKZU2JM6qFWFuWHBdXi2ft+O1Z8 t164m4rLGh8gn7vSBpmT2jTlLNQgZ9FvisHQbxvrgSVYjMntUnSM8z379deeUiuf lvA81idjBY0JCJK688MTWpwwcbpiIO27ThmrqzYRgJIObXWwKBF6J+/UQNh3R7xv +hKCP9JDiXbVACAObXHSV4gavhMKtupYM2PgPu7pc3De049jMv0bQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=BLcHPu DluFJpKIEADSO4TfdHTvOYaTnLX2uXWuubZlg=; b=VGR++7N+I4u4NDsF2RhG6S jc5YK6iuY4U0D8nQ95LD4P+BZMwHZ3hLLDISdQ9Hi3Wq2rTwAjQCxyBQMCTvoU1I nQGHeywf/+Nw0xWmf8ceGk1qnULvczNSDRF+rG3jobAQ5QIV1NyNX9aKrjexfy1Y YkommJN50vXow2oMFv8V8kokCYWxxXUaf0ZTAh3O3kKCBPKk0fQItSNl138ps3MY EFDD9kntL2kc0urFAEmWB4mfmH9XJlfDc171Mnqv0l2qVxeMXTInkz3gl3td5Rlz Srf8/IWxaywJTx2BgtwzdzEvC/ElGxuflkG32Cl3pjLMCY3cW6aO9w6+WaTZDAKQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B86E2E2150; Fri, 6 Jul 2018 00:35:40 -0400 (EDT) Message-Id: <1530851740.808927.1431672800.446E15D1@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15308517408089270" X-Mailer: MessagingEngine.com Webmail Interface - ajax-68b46f9b References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> <1530365202.3385073.1425646120.01C42B5A@webmail.messagingengine.com> <1530431723.3654473.1426157152.04E58508@webmail.messagingengine.com> Date: Fri, 06 Jul 2018 14:35:40 +1000 In-Reply-To: <1530431723.3654473.1426157152.04E58508@webmail.messagingengine.com> Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 04:35:46 -0000 This is a multi-part message in MIME format. --_----------=_15308517408089270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Coming back to this... we did consider early on the idea of a "MODSEQROOT" or "CONDSTOREROOT" in the same way that there's a QUOTAROOT - with all folders under the listed folder having the same global modseq counter and being able to fetch that counter. With this, you only need to keep one state per modseqroot to know if mailboxes or their contents have changed. This would be more flexible than the current Cyrus model of "it's per user", which doesn't handle shared mailboxes particularly well. I've put an item in AOB to discuss this in Montreal if we get that far. Bron. On Sun, Jul 1, 2018, at 17:55, Bron Gondwana wrote: > Yeah, fair enough. I guess I should write up global modseq first and > only propose this as part of that or something.> > I will write it up anyway just as a secondary description of how we're > doing it in Cyrus to support the jmap changes.> > Bron. > > > On Sun, Jul 1, 2018, at 09:11, Timo Sirainen wrote: >> On 30 Jun 2018, at 16.26, Bron Gondwana >> wrote:>>> >>> On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote: >>>> On 30 Jun 2018, at 7.13, Bron Gondwana >>>> wrote:>>>>> >>>>> I'm working on a doc (and implementation) for an extension to >>>>> RFC7162 - CREATEDMODSEQ. It adds said field on both mailboxes and >>>>> emails.>>>> >>>> What's your planned use case(s) for this? I can't really think >>>> of any.>>> >>> So the main use-case I'm working with at the moment is "phone client >>> wants to create a notification to user of new mail, but NOT throw up >>> a new mail notification if the user just moved an email from Inbox >>> to a notified folder in another client". So the phone client needs >>> to be able to distinguish "this message has newly arrived in the >>> mailstore" vs "this message has just been updated in some way".>> >> This requires the global modseq space for it to work. Also, an >> alternative to this feature might be to just auto-add some $Copied / >> $Moved keyword..>> >>> This piece of data is also being used in JMAP to underly the >>> calculation for whether a message (or thread) should be in the added >>> or changed result.>> >> I tried quickly looking at the jmap spec to see what exactly these >> meant, but didn't find it. So I guess copying/moving would be better >> as "changed" then? Again for the same reason of not showing >> notifications of copied/moved mails?>> >>> And likewise for mailboxes, the createdmodseq on mailboxes is used >>> to distingish between "got renamed" and "newly created".>> Nice, but again I don't really see how clients would use this. >> > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15308517408089270 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Coming back to this... we did consider early on the idea of a "MODSEQROOT" or "CONDSTOREROOT" in the same way that there's a QUOTAROOT - with all folders under the listed folder having the same global modseq counter and being able to fetch that counter.  With this, you only need to keep one state per modseqroot to know if mailboxes or their contents have changed.  This would be more flexible than the current Cyrus model of "it's per user", which doesn't handle shared mailboxes particularly well.

I've put an item in AOB to discuss this in Montreal if we get that far.

Bron.


On Sun, Jul 1, 2018, at 17:55, Bron Gondwana wrote:
Yeah, fair enough. I guess I should write up global modseq first and only propose this as part of that or something.

I will write it up anyway just as a secondary description of how we're doing it in Cyrus to support the jmap changes.

Bron.


On Sun, Jul 1, 2018, at 09:11, Timo Sirainen wrote:
On 30 Jun 2018, at 16.26, Bron Gondwana <brong@fastmailteam.com> wrote:

On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote:
On 30 Jun 2018, at 7.13, Bron Gondwana <brong@fastmailteam.com> wrote:

I'm working on a doc (and implementation) for an extension to RFC7162 - CREATEDMODSEQ.  It adds said field on both mailboxes and emails. 

What's your planned use case(s) for this? I can't really think of any.

So the main use-case I'm working with at the moment is "phone client wants to create a notification to user of new mail, but NOT throw up a new mail notification if the user just moved an email from Inbox to a notified folder in another client".  So the phone client needs to be able to distinguish "this message has newly arrived in the mailstore" vs "this message has just been updated in some way".

This requires the global modseq space for it to work. Also, an alternative to this feature might be to just auto-add some $Copied / $Moved keyword..

This piece of data is also being used in JMAP to underly the calculation for whether a message (or thread) should be in the added or changed result.

I tried quickly looking at the jmap spec to see what exactly these meant, but didn't find it. So I guess copying/moving would be better as "changed" then?  Again for the same reason of not showing notifications of copied/moved mails?

And likewise for mailboxes, the createdmodseq on mailboxes is used to distingish between "got renamed" and "newly created".
Nice, but again I don't really see how clients would use this.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

_______________________________________________
Extra mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15308517408089270-- From nobody Thu Jul 5 21:36:49 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE20130E9B for ; Thu, 5 Jul 2018 21:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KuwmX0Xk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K5UvJOpk 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 FkXMkxSX_HAY for ; Thu, 5 Jul 2018 21:36:46 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBE1130DEC for ; Thu, 5 Jul 2018 21:36:46 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.west.internal (Postfix) with ESMTP id 24D7723B for ; Fri, 6 Jul 2018 00:36:46 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 06 Jul 2018 00:36:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=uKtMLqShEJ06Xp1+QzrAtV1WNBLCkOHejMvQoNHlC fI=; b=KuwmX0XkqbGMWKIhN10J0no6RIPUybUSx7mSFSI41bK5h0qickgUN8rco iwd1UEA1yzXTbRlDzBdAqmrVPXSokwk03vU2xMY82I+h1d0GcLynkj4DSEy6Wmpo 5FLfN547XRxcjFP+QPrK1zfx32wUTdjtI7B1v2WMHSt5qS4cS91sJjolNrrLISq5 6Om5CN5KYVCw/iUbljetDEBX0CLYmpcBdpGmhz5lf328usDcB9IG9TXTLHrtInuh drsbbUho5PEnIyc4rIAiaVGcE9xFPrMgYMmmfoYbjGT9eqWBW5E34oBPLQgvNlE2 z0afG3tZgfQKTCr9tc+s6znm7Yz9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=uKtMLqShEJ06Xp1+QzrAtV1WNBLCk OHejMvQoNHlCfI=; b=K5UvJOpkozMSlL5+aH4XVCdWM/kfAR+Ip/8qBTmAoa0Id k5/XkOnIPYZqpa82B/5PWuOHr9EF0VlHPjnxloT4Ep/aMWWlEr3vlfIM6E+Nlip2 3/0kpWVCe9i0RSS78uIHF5KDXlQxjltsKDfiYS0LrBJl4awBCHFBPy2IphXk9S62 lgVYt7580t0Y160RT4LZOchd+IpHAS3DMZBJZ4Gx0y3xkVqbiUju23/hT5HzpSGN HniVLJJlpWeosCSQZH+CJOrAnbVmiQGMIXhU9AMFWMzJJW4yTmldr/qFIGsrv4cC zj/pfdexsstcN/ifjrXgCaq2hM/S36Bg4Ze74KJCQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 690C9E2150; Fri, 6 Jul 2018 00:36:45 -0400 (EDT) Message-Id: <1530851805.808378.1431673456.3BE0A73F@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15308518058083780" X-Mailer: MessagingEngine.com Webmail Interface - ajax-68b46f9b Date: Fri, 06 Jul 2018 14:36:45 +1000 Archived-At: Subject: [Extra] Montreal draft agenda X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 04:36:48 -0000 This is a multi-part message in MIME format. --_----------=_15308518058083780 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" EXTRA: IETF102 Montreal / 2018-07-19 11:00 - 12:00 Intro and Note Well: 5m Proposed new documents: 25m * draft-brandt-imap-replace 5m * draft-slusarz-imap-fetch-snippet 5m * draft-yu-imap-client-id 15m Existing documents: 20m * sieve-fcc 3m * sieve-specialuse 3m * savedate 3m * imap4rev2 10m AOB: 10m * spam handling (informational/advisory doc?) * MODSEQROOT and cross folder modseqs spec? Please let me know if I've missed anything you want to talk about, or if you think the timing is all wrong. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15308518058083780 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
EXTRA: IETF102 Montreal / 2018-07-19 11:00 - 12:00

Intro and Note Well: 5m
Proposed new documents: 25m
  * draft-brandt-imap-replace 5m
  * draft-slusarz-imap-fetch-snippet 5m
  * draft-yu-imap-client-id 15m
Existing documents: 20m
  * sieve-fcc 3m
  * sieve-specialuse 3m
  * savedate 3m
  * imap4rev2 10m
AOB: 10m
  * spam handling (informational/advisory doc?)
  * MODSEQROOT and cross folder modseqs spec?


Please let me know if I've missed anything you want to talk about, or if you think the timing is all wrong.

Thanks,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15308518058083780-- From nobody Fri Jul 6 00:04:24 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95959130DE2 for ; Fri, 6 Jul 2018 00:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 aHonA8Nr10vI for ; Fri, 6 Jul 2018 00:04:20 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C5D130E1A for ; Fri, 6 Jul 2018 00:04:19 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 4D3E5C09B3; Fri, 6 Jul 2018 08:04:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1530860661; bh=ZtvZWKPShfdsKgCbv59r5enWGoAiAttorHozzJ5mLyU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TohDkrQDQ6BeDwgYyv6cyL37tClZo2BxKTSqwxyvqJNYOfSuTwvjVHk43C9CQ+a4z jBY8UEXL8rX1N+/t4rEjOKSlnIZcr15XlU4GiiQqd9pPcWmmfiQKToH8Q8MhWdo8yv tRSUW06TZ3AyO6FziYvfmMhrXfXUBNDoVbec0st8= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1530860660-23986-23983/9/2; Fri, 6 Jul 2018 07:04:20 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Fri, 6 Jul 2018 09:04:17 +0200 Mime-Version: 1.0 Message-Id: <7594dc40-0833-4c4c-8181-f97cd3903e54@gulbrandsen.priv.no> In-Reply-To: <1530851740.808927.1431672800.446E15D1@webmail.messagingengine.com> References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> <1530365202.3385073.1425646120.01C42B5A@webmail.messagingengine.com> <1530431723.3654473.1426157152.04E58508@webmail.messagingengine.com> <1530851740.808927.1431672800.446E15D1@webmail.messagingengine.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 07:04:22 -0000 Wouldn't it be better to say that if the server advertises global modseq to a particular user, then that applies to all mailboxes the user can open? Simple semantics for the client, no little-used or hard-to-test special cases, and covers both of the big use cases. Arnt From nobody Fri Jul 6 00:43:42 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44AE130DDF for ; Fri, 6 Jul 2018 00:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=lB70UuIv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JrJd4VDI 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 sGBeYDrCH0wI for ; Fri, 6 Jul 2018 00:43:29 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14923130FDF for ; Fri, 6 Jul 2018 00:43:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B182C247; Fri, 6 Jul 2018 03:43:16 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Fri, 06 Jul 2018 03:43:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=GGU2xiqIVwDMGU3sU UCkKtpGQTJn8+Ky1zsV+RWnwZw=; b=lB70UuIvjFLb4TSGXRp7aw+aWyh/qOQ/J E3J0IlCOpx4ELL7hxvu4NgVd4Ul/AYNW03HT9ZiTDITOBcVdNC3dE62a0WFybgww pHO7ZP8xASl7Qgly1xCP5mdqBVXU+lgkZQO7RgsRIQaqZ7hek6MrL68FUSJFBuGY meOOeS8jH8D96scXzUW1fTm2Vu1Ou40t3yBiH803c7sfXSotW7hC5gYVV7VIK2Ev KDsZ6FZvUDoU28EThmZ7RKTpcUXZodqjFf2B00BHjo8tbRYfDnHorVn2w6W35P5E aLuH4jnvyv8SKD7Ngkrkd+WXFczqmHjErsRL/ihBMvQFLgj/1ImTA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=GGU2xi qIVwDMGU3sUUCkKtpGQTJn8+Ky1zsV+RWnwZw=; b=JrJd4VDIwmoqJ+NYJxsm6/ kw3JTjpZnL4a1ChzuCspHJwR4YjM3jS9zuKpT9i/UGA0KD8rkbil1mr4K8isPNJi IeF0cKhwM4w/aDU0y4nPX6zrrbebdNXck7xErvUMaFwlGnm1rdbp5AaDLonklIMA cJcpK17ZaTF2PxTLAVmNll9+o0VE+UJLWDyUhJ3UbCRjcKA7wIVR9EnERT58GZWZ vsfzsc3+006sojRNmGV03M6F/h/mejZs5qPl4ji6SLAzhztnhPfspjWwilqD3U56 YY8EkiWCxase4VcqUSha+DtECpcQMcNLsY0zbuA0WXi7Lw2GSCvN6dznCF9+HHaw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0C4D9621DC; Fri, 6 Jul 2018 03:43:16 -0400 (EDT) Message-Id: <1530862995.3530355.1431783280.18145D47@webmail.messagingengine.com> From: Bron Gondwana To: Arnt Gulbrandsen , extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153086299535303550" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> <1530365202.3385073.1425646120.01C42B5A@webmail.messagingengine.com> <1530431723.3654473.1426157152.04E58508@webmail.messagingengine.com> <1530851740.808927.1431672800.446E15D1@webmail.messagingengine.com> <7594dc40-0833-4c4c-8181-f97cd3903e54@gulbrandsen.priv.no> In-Reply-To: <7594dc40-0833-4c4c-8181-f97cd3903e54@gulbrandsen.priv.no> Date: Fri, 06 Jul 2018 17:43:15 +1000 Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 07:43:39 -0000 This is a multi-part message in MIME format. --_----------=_153086299535303550 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" That means you need a global modseq for the entire server. Right now we're doing it per user. Either that or you need to not have shared mailboxes that any user can subscribe to (eg bulletin boards) Bron. On Fri, Jul 6, 2018, at 17:04, Arnt Gulbrandsen wrote: > Wouldn't it be better to say that if the server advertises global > modseq to> a particular user, then that applies to all mailboxes the user > can open?> Simple semantics for the client, no little-used or hard-to-test > special> cases, and covers both of the big use cases. > > Arnt > > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153086299535303550 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
That means you need a global modseq for the entire server. Right now we're doing it per user. Either that or you need to not have shared mailboxes that any user can subscribe to (eg bulletin boards)

Bron.


On Fri, Jul 6, 2018, at 17:04, Arnt Gulbrandsen wrote:
Wouldn't it be better to say that if the server advertises global modseq to
a particular user, then that applies to all mailboxes the user can open?
Simple semantics for the client, no little-used or hard-to-test special
cases, and covers both of the big use cases.

Arnt

_______________________________________________
Extra mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--_----------=_153086299535303550-- From nobody Fri Jul 6 00:58:16 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C8D130DDF for ; Fri, 6 Jul 2018 00:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 8BzONPy7GQV3 for ; Fri, 6 Jul 2018 00:58:12 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC8B128CF3 for ; Fri, 6 Jul 2018 00:58:12 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 4C5DDC09FF; Fri, 6 Jul 2018 08:58:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1530863894; bh=L7juMOp5rzmd/FewMdRz2J0ukovMWvPJ1qUDurwL38I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EdQI+3wTHsb5+F/vl5WrQ+DBJOvD5Qgpaj6L51yjlr0mb6cqc9VQSLkkQJ+h4bmxp fo47qUYFfpoU5ykbrhpn+W39NLOqigQJWhhjom6VcC3UjLgPtNQ+0yuIp3A4aqWEZP sfJiQhYTKlDbp9Mc+Ffwz4jmPxAuML5aNZNhZK2c= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1530863893-23985-23983/9/1; Fri, 6 Jul 2018 07:58:13 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Fri, 6 Jul 2018 09:58:10 +0200 Mime-Version: 1.0 Message-Id: In-Reply-To: <1530862995.3530355.1431783280.18145D47@webmail.messagingengine.com> References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> <1530365202.3385073.1425646120.01C42B5A@webmail.messagingengine.com> <1530431723.3654473.1426157152.04E58508@webmail.messagingengine.com> <1530851740.808927.1431672800.446E15D1@webmail.messagingengine.com> <7594dc40-0833-4c4c-8181-f97cd3903e54@gulbrandsen.priv.no> <1530862995.3530355.1431783280.18145D47@webmail.messagingengine.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 07:58:15 -0000 On Friday 6 July 2018 09:43:15 CEST, Bron Gondwana wrote: > That means you need a global modseq for the entire server. > Right now we're doing it per user. Either that or you need to > not have shared mailboxes that any user can subscribe to (eg > bulletin boards) Is that case really common enough to warrant requiring extra complexity? After all, CONDSTORE already requires clients to support NOMODSEQ. Arnt From nobody Fri Jul 6 03:04:06 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F7B130E7E for ; Fri, 6 Jul 2018 03:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 bDfN1kvUv10J for ; Fri, 6 Jul 2018 03:04:03 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id CDBCF130E2D for ; Fri, 6 Jul 2018 03:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1530871442; d=isode.com; s=june2016; i=@isode.com; bh=BaXNXJtMXT02Ef2ixa+gkMBFAcZI2PIUOFG7EjP3Kuc=; 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=O363OJa5bf0WN0oT1v5A45YisdFgPuN/M+Bm1mxRIdoXvZUH8M4ossJw7U0gl2PzR/BiTd jllX8mAR4xMmvRVZOsHU3B10KRlpI7DbBwvJ09PgJPufFLiFgf50bwCItUQW4qV0VfJxhb Sig7MQuku8nmmqi0vKfL/HU8GUDzGl8=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 6 Jul 2018 11:04:02 +0100 To: Bron Gondwana , extra@ietf.org References: <1530851805.808378.1431673456.3BE0A73F@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: Date: Fri, 6 Jul 2018 11:03:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <1530851805.808378.1431673456.3BE0A73F@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0D4A78AD95C31EC63D54AE33" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Montreal draft agenda X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 10:04:05 -0000 --------------0D4A78AD95C31EC63D54AE33 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 06/07/2018 05:36, Bron Gondwana wrote: > EXTRA: IETF102 Montreal / 2018-07-19 11:00 - 12:00 > > Intro and Note Well: 5m > Proposed new documents: 25m > =C2=A0 * draft-brandt-imap-replace 5m > =C2=A0 * draft-slusarz-imap-fetch-snippet 5m > =C2=A0 * draft-yu-imap-client-id 15m > Existing documents: 20m > =C2=A0 * sieve-fcc 3m > =C2=A0 * sieve-specialuse 3m > =C2=A0 * savedate 3m > =C2=A0 * imap4rev2 10m As a general note, I think existing work takes precedence over new work.=20 So I would like to have the first 2 sections swapped, unless there is a=20 conflict for some people. But otherwise this looks good to me. > AOB: 10m > =C2=A0 * spam handling (informational/advisory doc?) > =C2=A0 * MODSEQROOT and cross folder modseqs spec? > > > Please let me know if I've missed anything you want to talk about, or=20 > if you think the timing is all wrong. --------------0D4A78AD95C31EC63D54AE33 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 06/07/2018 05:36, Bron Gondwana wrote:

EXTRA: IETF102 Montreal / 2018-07-19 11:00 - 12:00

Intro and Note Well: 5m
Proposed new documents: 25m
=C2=A0 * draft-brandt-imap-replace 5= m
=C2=A0 * draft-slusarz-imap-fetch-snippet 5m
=C2=A0 * draft-yu-imap-client-id 15m=
Existing documents: 20m
=C2=A0 * sieve-fcc 3m
=C2=A0 * sieve-specialuse 3m
=C2=A0 * savedate 3m
=C2=A0 * imap4rev2 10m

As a general note, I think existing work takes precedence over new work. So I would like to have the first 2 sections swapped, unless there is a conflict for some people.

But otherwise this looks good to me.

AOB: 10m
=C2=A0 * spam handling (informational/advisory doc?)
=C2=A0 * MODSEQROOT and cross folder modseqs spec?


Please let me know if I've missed anything you want to talk about, or if you think the timing is all wrong.

--------------0D4A78AD95C31EC63D54AE33-- From nobody Fri Jul 6 03:31:02 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC2313104C for ; Fri, 6 Jul 2018 03:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RhVCV0Yt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=guXXOUTe 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 8UXAy-bHgqNg for ; Fri, 6 Jul 2018 03:30:46 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A110E130FB4 for ; Fri, 6 Jul 2018 03:30:46 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B552C26E; Fri, 6 Jul 2018 06:30:45 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Fri, 06 Jul 2018 06:30:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=nnVoB8g6u2PYvdYnm l4kPSYC3tk6kRUnfaMqdH0zO38=; b=RhVCV0YtOnxI1/qAhCozY23j2W6mMNmlt IzofzRHZRXqkLiA2W/xyGhyt1CXGS5IT8PkVrpGRr50t313gKMwYdZYQHBICGqkv dU9NY4iYFFXzE3BsxNSbWHnUG2YI8URZPiRvnaOf9xZcJ1NZ6e9zxd4EBqXplamV uc9LJUN853CP6xzQpyYkhfVt6/NYS9Sa4MCcc5NYM5xEYXgh0TieeZ9XxSAbqzIC Z9kzOEd6lWPqDFRoG4zcPwPyA4gT7TmHz2RtBS51NlRHNNhqfWBv3bLjaX8kxmOh 7leD1ZDxS7a+Fp3coWO7adeY3XAAYW8Shy36Jt8NOtNA70JonElvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=nnVoB8 g6u2PYvdYnml4kPSYC3tk6kRUnfaMqdH0zO38=; b=guXXOUTeSHudM+WrnQSElN ucoavjBTXrEwt1j2TLF0rdrxKmu18WP3czUiCQpmRyd/E57oG48DtVzG6chrGQQ2 fpaOe5ks7IrRBlCaErFTVrd5WxulFHhowntL3ZT+ybvWtWaG6gJzouqR32G4yZbH 73J9uZryCmQ5J+2c/xYUeSvwkRo6kQjlZmUNVkC3UZp1MhPadllgCs6Uj8/o+sd7 a2V87ShhK58KJjqH0LgmNa4yNqs3t6u5KSpYjlX33a70hNYzGKAjLvRqrwIium0K 1uZPkcjqZVtuK4Uij5wDskp92B8KckgfNljvfkV9KASiMymhdE9DX+hub5HyhbxA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 04D92621DC; Fri, 6 Jul 2018 06:30:44 -0400 (EDT) Message-Id: <1530873044.262785.1431924968.2C0C4098@webmail.messagingengine.com> From: Bron Gondwana To: Alexey Melnikov , extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15308730442627852" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c References: <1530851805.808378.1431673456.3BE0A73F@webmail.messagingengine.com> Date: Fri, 06 Jul 2018 20:30:44 +1000 In-Reply-To: Archived-At: Subject: Re: [Extra] Montreal draft agenda X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 10:30:59 -0000 This is a multi-part message in MIME format. --_----------=_15308730442627852 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Yeah fair enough! I'll do that. Bron On Fri, Jul 6, 2018, at 20:03, Alexey Melnikov wrote: > On 06/07/2018 05:36, Bron Gondwana wrote: >> EXTRA: IETF102 Montreal / 2018-07-19 11:00 - 12:00 >> >> Intro and Note Well: 5m >> Proposed new documents: 25m >> * draft-brandt-imap-replace 5m >> * draft-slusarz-imap-fetch-snippet 5m >> * draft-yu-imap-client-id 15m >> Existing documents: 20m >> * sieve-fcc 3m >> * sieve-specialuse 3m >> * savedate 3m >> * imap4rev2 10m > > As a general note, I think existing work takes precedence over new > work. So I would like to have the first 2 sections swapped, unless > there is a conflict for some people.> > But otherwise this looks good to me. > > >> AOB: 10m >> * spam handling (informational/advisory doc?) >> * MODSEQROOT and cross folder modseqs spec? >> >> >> Please let me know if I've missed anything you want to talk about, or >> if you think the timing is all wrong. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15308730442627852 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Yeah fair enough! I'll do that.

Bron


On Fri, Jul 6, 2018, at 20:03, Alexey Melnikov wrote:

On 06/07/2018 05:36, Bron Gondwana wrote:

EXTRA: IETF102 Montreal / 2018-07-19 11:00 - 12:00

Intro and Note Well: 5m
Proposed new documents: 25m
  * draft-brandt-imap-replace 5m
  * draft-slusarz-imap-fetch-snippet 5m
  * draft-yu-imap-client-id 15m
Existing documents: 20m
  * sieve-fcc 3m
  * sieve-specialuse 3m
  * savedate 3m
  * imap4rev2 10m

As a general note, I think existing work takes precedence over new work. So I would like to have the first 2 sections swapped, unless there is a conflict for some people.

But otherwise this looks good to me.


AOB: 10m
  * spam handling (informational/advisory doc?)
  * MODSEQROOT and cross folder modseqs spec?


Please let me know if I've missed anything you want to talk about, or if you think the timing is all wrong.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--_----------=_15308730442627852-- From nobody Sat Jul 14 10:20:13 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B75A8130DD0; Sat, 14 Jul 2018 10:20:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Pete Resnick To: Cc: extra@ietf.org, draft-ietf-extra-imap-objectid.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153158881071.12558.4695633896426601679@ietfa.amsl.com> Date: Sat, 14 Jul 2018 10:20:10 -0700 Archived-At: Subject: [Extra] Genart last call review of draft-ietf-extra-imap-objectid-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 17:20:11 -0000 Reviewer: Pete Resnick Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-extra-imap-objectid-03 Reviewer: Pete Resnick Review Date: 2018-07-14 IETF LC End Date: 2018-07-13 IESG Telechat date: Not scheduled for a telechat Summary: I've got a few concerns about the document, but it is almost ready. I hope these can be addressed easily. (Also, my apologies for being a day late, though hopefully not a dollar short. I also apologize for being a GenART reviewer who happens to know the topic area, but hasn't been following the WG; you would have had an easier time with someone else. ;-) ) Major issues: §4 ¶2 I don't believe this ought to be a SHOULD. While the document explains that this allows for disaster recovery, I don't understand what sort of disaster would allow the server to preserve UIDVALIDITY and name, yet not be able to preserve MAILBOXID. If you're talking about things like re-building a crashed disk, that doesn't justify downgrading the MUST: Even though 5321 says that the server MUST take responsibility for the message after delivering the 200, if lightning strikes immediately after writing the message to disk and scrapes just those sectors, that's not something that an implementer SHOULD anticipate. This sort of softening also has the horrible side-effect (as do many other things in IMAP) of not allowing a client to properly depend on the feature: If a server is permitted, for whatever reasons it believes are really strongly justified, reset MAILBOXIDs, clients will have to keep using name + UIDVALIDITY, even if the capability is advertised. That's bogus. Please either explain the justification for this SHOULD better, or simply change it to a MUST and remove the bit about disaster recovery. §4 ¶5 Why would this be allowed? If you can't preserve MAILBOXID across RENAMEs, there's no point in advertising this capability. §5.1 ¶2 See above on §4 ¶2. Minor issues: §5.1 ¶3&4 I think you need to add an explanation here that there is no way to use MAILBOXID with a STORE command or other similar ones, and there never will be a way (unless you really want to be able to all occurrences of a message across all mailboxes). Maybe this goes in §9. §8.2 ¶2 Why isn't it advisable (or even RECOMMENDED) that *all* object identifiers (not just MAILBOXID) be globally unique? Seems like the recommendation applies to all of them. In the example, it is plausible that an OBJECTID proxy could rewrite identifiers to avoid conflicts (e.g., append "-from-servername" to each identifier). So I think it would be clearer to say: OLD the backends will not use the same identifiers for different objects NEW different objects never use the same identifiers, even if backend system have identifiers that collide §8.3 I'm not clear on the SHOULDs in this section. These seem like perfectly good operational guidance statements, but not interoperability requirements. I say lowercase them. Nits/editorial comments: §1 ¶3 s/If a mailbox is successfully renamed, the client knows/If a mailbox is successfully renamed by a client, that client will know §5 No need for the sentence at the top of this section. Just go right to 5.1. §5.2 ¶5 The sentence is ungrammatical ("to in all") From nobody Sat Jul 14 14:08:15 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC6D130E2A for ; Sat, 14 Jul 2018 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 ytU6XsbEINgX for ; Sat, 14 Jul 2018 14:08:12 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 2F8A0128BAC for ; Sat, 14 Jul 2018 14:08:12 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6EL6cZ9061267; Sat, 14 Jul 2018 21:08:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=tKXy6SEP1XWdxS5SBSlFxwCOPU5+9cYBT6MrCbVGZ3U=; b=zYYHK+xk0mCe9CaEk9nR9NQcuYYTchTdp5+bHczg6WI5hLAJV6VgkD3uSrksakdGecss nykei5hjCD+hFwNYPgZH9Q9OInCBisjKxtypT93iyZxAHNNQjJwdPyfotPCVMdyAr/LL s5OVppSuar+Hfp6OTWtDhOOOZ2p3h3ATLcqDQDIPuNlHYOTkxv9lDTa6Sf6OYomKliqn qzcAXHL9R/441auzZKk7G/dgQr2La+40w1lQzx831E+Kwa/ed3wFI1wSFyYBLid2HpVl /nRScImE7PeFJUXW7C7i2eomJ5/o26wzAGsSxN6RZMUlYBeSVdnP9SFq706Fb6qKsiUy xw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2k7a3jh2uc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 14 Jul 2018 21:08:06 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6EL85rp002295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 14 Jul 2018 21:08:05 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6EL84NI027023; Sat, 14 Jul 2018 21:08:05 GMT Received: from [31.133.156.20] (/31.133.156.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 14 Jul 2018 14:08:04 -0700 From: "Chris Newman" To: "Stuart Brandt" Cc: "Bron Gondwana" , extra@ietf.org Date: Sat, 14 Jul 2018 17:07:19 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <8FC7B9A9-3BFE-4706-B943-66B2E185C00A@oracle.com> In-Reply-To: <5B3B5FB1.6090603@aol.com> References: <1527812408.1624623.1392443640.48DE67C7@webmail.messagingengine.com> <5B37DBE7.5070809@aol.com> <3CF9D7B5-42BE-44F8-92D7-7BDA9A163CC3@oracle.com> <5B3B5FB1.6090603@aol.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8954 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=994 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807140255 Archived-At: Subject: Re: [Extra] Bringing REPLACE back X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 21:08:14 -0000 On 3 Jul 2018, at 7:36, Stuart Brandt wrote: > Thanks, Chris. Comments below > > On 7/2/2018 11:45 PM, Chris Newman wrote: >> I'm not a fan of adding parallel commands when there's a documented >> syntax extension model, especially for the APPEND command. I'd >> suggest a >> syntax more like this (following RFC 4466 model): >> >> A004 APPEND Drafts (\Seen \Draft) UIDREPLACE 2000 {350} ... >> >> Also the ABNF is simpler (and you don't have to fix the >> incompatibility >> of your ABNF with RFC 4466): >> capability =/ "REPLACE" >> >> append-ext =/ "UIDREPLACE" SP uniqueid >> >> If you extend the command rather than adding a parallel command, then >> interaction with certain extensions (like CATENATE and UIDPLUS) >> becomes >> much simpler. > > Use of REPLACE for the 3 command sequence is consistent with use of > MOVE (rfc6851) for a similar 3 command sequence. It also avoids state > machine confusion since REPLACE, unlike APPEND, is not valid in > authenticated state (see section 3.5). Ok. I'm still not a fan of more use of message sequence numbers, but so this isn't a show stopper for me. >> Other notes: >> * the example is inconsistent -- the APPENDUID response should always >> have a UID higher than the replaced UID. > > I thought I had covered this with 2000 being the replaced UID and 2001 > being the new UID. Did I get the syntax wrong? Sorry, you're correct; I got it backwards (just used to "1" being the UID in examples and the long number being the uidvalidity ;-). >> * this needs to document interaction with the OBJECTID extension. > > Will do. Since REPLACE is an encapsulation of APPEND/STORE/EXPUNGE and > since APPEND is going to inherently involve different message > structure/bodyparts, the replacing message should have both a new > MAILBOXID and new EMAILID. If client1 replaces message1 with > message2, then client2 doesn't actually *have* message2 in its cache, > so it will need to FETCH message2 if it wants to populate its cache. > > It would be good if we could solve this issue of having to reFETCH > large attachments that already exist in a client's cache, but it seems > like that might require an OBJECTID like extension targeted at > bodyparts rather than full messages. > >> * this needs to state whether this is available in AUTHENTICATED >> state >> vs. SELECTED state. I think it's slightly simpler if the UIDREPLACE >> extension is only available in SELECTED state, but I can implement it >> either way. > > Is there something additional needed in section 3.5? Sorry, I missed that. >> * I'd also prefer that this only support UIDs and not use message >> sequence numbers. Having an APPEND-like command that has pipelining >> sequencing problems like non-UID FETCH seems like it would add >> unnecessary complexity to the protocol. > > I too would prefer to not deal with sequence numbers, but I didn't > want to break new ground in that regard compared to other IMAP > commands and extensions. If you're stuck with the ["UID" + top-level] command, then I can understand that position. - Chris >> * your example is inconsistent with the text in section 4.3; however >> I'm >> unsure that restriction is really helpful -- it might be better to >> encourage clients to robustly handle either order. > > Good catch. Thanks. > >> >> Although I don't plan to implement this in the near term, I'd much >> prefer it be standardized if the need arises so I support adoption by >> EXTRA. I think the extension has subtleties that will benefit from >> standards processing. >> >> - Chris >> >> On 30 Jun 2018, at 12:37, Stuart Brandt wrote: >> >>> An updated draft-brandt-imap-replace-03.txt is now available >>> From nobody Sun Jul 15 11:56:29 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7C5130E5B for ; Sun, 15 Jul 2018 11:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xXySplnacEnn for ; Sun, 15 Jul 2018 11:56:23 -0700 (PDT) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id C0D58127598 for ; Sun, 15 Jul 2018 11:56:22 -0700 (PDT) Received: (qmail 41342 invoked from network); 15 Jul 2018 18:56:20 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (c2afb4a6-8860-11e8-bd98-5f9215d77e85); Sun, 15 Jul 2018 11:56:20 -0700 To: extra@ietf.org From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Sun, 15 Jul 2018 11:56:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------8CA23D66849E6547B23C06F8" Content-Language: en-GB X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: c2afb4a6-8860-11e8-bd98-5f9215d77e85 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: [Extra] Montreal Agenda, Advance Information regarding draft-yu-imap-client-id X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 18:56:27 -0000 This is a multi-part message in MIME format. --------------8CA23D66849E6547B23C06F8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello Everyone.. Agenda Item: EXTRA: IETF102 Montreal / 2018-07-19 11:00 - 12:00 Agenda Topic: draft-yu-imap-client-id 15m We thank you for your patience as we go through the RFC process, as this is our first draft presentation, and not 100% sure of the 'standard' approaches to gain consensus, and move this forward.. Since the agenda and time allocations were shortened up, our original plans for making a "full presentation" on the draft, and a presenting a fuller background on why we believe this is important, will have to be adjusted, given the amount of time available. After a suggestion by Bron, given the time available.. he suggested I post the information I planned to give in a presentation style ahead of time, so that everyone has time to review, and we can maximize the time allotted for discussion.. With that in mind, I have decided to post links to materials that give you the background, as well as the draft materials on this subject. (Not sure the PPT presentation materials work as well for reading materials, as it would in a presentation, but included for reference as a PDF) Attachment: IETFPresentation.pdf (Slides, and Slides w/notes) Draft Location: https://tools.ietf.org/html/draft-yu-imap-client-id-00 ... Some other related materials/links you might be interested in ... Related: https://tools.ietf.org/html/draft-storey-smtp-client-id-05 Additional: https://blog.linuxmagic.com/2018/05/15/security-vs-privacy-an-argument-for-cid-authentication/ Again, we thank you for your time, and look forward to discussing this proposal, as well as working with this group, and learning what they can share with us to help guide this proposal through the process. -- Michael -- PS, Should any of you wish to have a preliminary discussion prior to the meeting to discuss this in more detail, feel free to ping me.. will be available in Montreal from Tuesday to Thursday. And as well, my CTO Shaun Johnson will be available if you wish to discuss any technical implementation details, our CID Implementation and our early experiences. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. --------------8CA23D66849E6547B23C06F8 Content-Type: application/pdf; name="IETFPresentation.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IETFPresentation.pdf" JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nL1VTY/TQAy951fMGanp2PMZqRopaRMEtxWVOCBOwC5Cu6Bd Dvx9/DFJ00IkTqhSNXGe7fdsj2NbML+aZ2PNzrZoUufaaEIX6PzypXn/ynxvwPDv5aGx/MI8 NQxKcn40ehbfxzkIH/Tt1+b+VXNnrsKnrfDP9bVV99bNXp+emv2bJ29OP8zdbbRNss8Sx/Jx ODce22Cyb7M5fzb7iTDenO8PFsr5WzOem7sbvMtA+TNS/H9zSJ4K6XyeHdAg5br/wB54sFh2 9O/46G2wsbiDTWUHB5vlv5N/z+aeQYPgj/ysrqfiD3a8WNVtoiCwtoAViAI5HIAAxf0STmGA lAqc4ry4h4JhDsJwsHaqj0IRVEL5eH771yrk1hsHf9RgrBoqE0oscpW9l3JUSkJA6fpaBXVW ebHUOBCUSlqXD5JGdDX8cYmrpVXwxMdJo/gyF9RXUmKWNHOJlcyWZIiROo/Z0bzcqFbKeGnA bf8gX2nx0EkNetYgWBgKripDmNXkzKKPC1kNM1Hd6pmam5cINeRpU0lAukhEgu5gVeJQlfRl R2lHK0OiT8zHHmC0g432RO+OdYSZx0AZhfLFNDGnXhiskCyFYiEzlHa4Qw2U1USkN+gieqIL gKsrp3RRkvulnVovhOIdG5YxQ2qNv7ommYqHi4diqc4MQldcV8dD7s1lXKgpcOlS5NJvcuZd lWPb3VKmbkWhNedwtate02mieYBIjaeKMoGAodTVUSkMpc47xipqZAQPBaYqNDF8lBR0H7bY hkQLMwJRvmY776haCqW5Zqi3a13fnohm7jV2Cz2dKul5wCSyuAJz9a+vXAspevo4tN47oE9D mxBCnEc3JSKJ4OdL6Aws6zfK0qOtgtbp9qWG6TPtCyIfeFd0Yur5YaA3x2pIpCTw6EcLNcyk LpF24wmAkEjz64AWiO1pW0pCR6aguN4OtE9mEgwqvGIJkHhW0uZ1FE3Q+bn8/1sTBcA1fiCR bJw4qeqrsbf0Qb6IuzOrT/N+fP0umoefZn9+Cfpd/w3Ct9KOCmVuZHN0cmVhbQplbmRvYmoK CjMgMCBvYmoKNzc1CmVuZG9iagoKNCAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9J bWFnZS9XaWR0aCAxMDMxIC9IZWlnaHQgNjk0IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9y U3BhY2UvRGV2aWNlUkdCL0ZpbHRlci9EQ1REZWNvZGUvTGVuZ3RoIDM2Mzg5Pj4Kc3RyZWFt Cv/Y/+AAEEpGSUYAAQEAAAEAAQAA/9sAQwADAgIDAgIDAwMDBAMDBAUIBQUEBAUKBwcGCAwK DAwLCgsLDQ4SEA0OEQ4LCxAWEBETFBUVFQwPFxgWFBgSFBUU/9sAQwEDBAQFBAUJBQUJFA0L DRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU/8IA EQgCtgQHAwEiAAIRAQMRAf/EABwAAQACAwEBAQAAAAAAAAAAAAADBQQGBwIBCP/EABsBAQAD AQEBAQAAAAAAAAAAAAABAgYDBAUH/9oADAMBAAIQAxAAAAHdtfouffd+F175yN34da88qRPV XKI4v1tyBV2D5x7IrbrLmtXzt15yB359fcgQ6+5AOvuQDr7kA6+5AOvuQDr7kA6+5AOvuQDr 7kA6+5AOvuQfU9fciHXXIh11yIddciHXXIh11yIddciHXXIraJ6O+dD8Pt1TbNj9eL21P21c +lUtRVLUVS1FUtRVLUVS1FUtRVLUVS1FUtRVLUVS1FUtRVLUVS1FUtRVLUVS1FUtRVLYVK2F SthUrYVK2FSthUrYVK2FSthUrYVK2FStvJVsnMKpaivTjhHPug8+0+Xe/H31eWT7j49eljJQ 2db5nj397cfN1BhueDFuGqVvGIGdvnPtzV0G2pflDqePDmjrVUc6b1dTHK3Qso5m6XkRPLHT tC6Urh05AAPu1a5S8D0tPl6Hl6Hl6Hl6Hl76Nzvzfd+6bN8r6nO94zHzPpYzJU6YzJGMyRjM kYzJGMyRjMkYzJGMyRjMkYzJGMyRjMkYzJGMyRjMkYzJGMyRjMkYzJGMyRjMnHR8aVvvWmO0 reiJL65dIE/kiTCFy7pJkOTdfIU30ge+UHVHyYiS0nObbkfX/wASdL7R1fjG1X9P6W+ZSnip 0w/P3P8Af+fajMeh6PJqtbYa9ntV72DXNtmm0SQY+hzXTsLhm8/O9WTiZXv6fjwE8FDeNH/U Xk9n5f3fz3unT8mtp6n24cDtbfdzjmX+gua0viaP0K6lyPO7HpsxWS9ZyPL6fzpBuW8evycV seqazE4d/WdA4d+Wa5jevb4vr6u+Po+Po+Pu6UtpnTuybX8j6+r7DO+X9OBOraBOIE4gTiBO IE4gTiBOIE4gTiBOIE4gTiBOIE4gTiBOIE4gTiBOIE4gTiBOIMOzwpjk3XPz51r6nk5rm4Xr 2+f3sORrnC+86d6qItYSVeX2583my9Az/wBO46/outHvaedbUa9sFNu5terwdINv1vfdT8vT d+Dyfo2J/Ev7B5nzr0c/0wyF419KPzrz7oXPtRmFNcUc1p7bVp8r+iZGf2HsmQ7anm7jxTxe fC0j75/U8fJl4Mn3Pi50Xv3aML9E8K6n4Pb0yk1jXPB76joEuN25eb6guuXT3xjt/E/Rw3y8 1XauXT8+9nyvffjbOY/ed9oz5Ljn1s+Bd04f05bhsep7zW3509TRfX+T9FbALLoH6F+f9DnH VJXw/tRpHPrGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQ RpBHh2H05HNt9d1phYu5YFZx628wKzQXWHs966792eriau5WdLUX3c/Zz3kn6diPwb+sN/yC t0Pp3wwKLC13w9dc79zvE+R6L78ndd2+k9RaBven8NK9pfnHn3QefafLsXK89+EfP+kZeX1f Yera/S/A9P38f/t/gf1KaX9+zfd+ND68/fr/ACM73499efoIjhy/sxh/Zo6289h4+49/0Fw2 vUv5enp83z56J8vRHn79J8vRHl6Hl6RPl63rl01T9GbrcfC+4Hz/AKAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAFZRbgOfx9EcL82td0FJdfXemvA/OPPug8+0+XubXUrL3fPttv0GX4 32+3e+J+q27Pq/P4oZ3irxPd4cyn85Pq88v3x9tPv14+2r6+/ERJ8+er0iiykWw2VHW8L18r f4+j4+j4+j4+j4+j56sP0t5fTpHdPbO/eDj3AAAAAAAAAAV9hrZNkYmcfEmrmyNKyTbGr5Ze +ZvBiyQYZpGq6HUnUnLdyNgaTnmztIkNzaTWHSffKoz9hcZteHHVnLR1Jz2/NjaZkG1tIpDq Tlo71sv543c9uWfTqSr1k3pp+WbK07HhvLRaeXUuvfk7tx4p+USnUnLdsRszR8iJ3BpnuW4N V1eHUsrkccv14qRw/QOg6DqMv4TdB68ubx9Y+8e3IPPYVbcedh+HIp+rJjl33qH29eX++nfY nmTpy0cz+9M+o5l66X6mOaOl/bV5m6b9Oa+emfZjmHjqf2s8o+dY+RblDqviJ5a6h5ieY7Ru vdPJ6sO+gfC+5OgRadAJ0AnQCdAJ0AnQCdAJ0AnQCdAJ0An1bYqIp8rE9mXp2zocsk6emOZT 9GROV5x/kvmRi2J+b67qWIc43WyI+yRImPHzEsbV9xQ5xF0zxK647+hdCOduj4xqmzZyY94s 6JxtC6Mhzhv2TLSd0zdgOGfejfSvy5RhYN2LChlyYYuhdHS5t2Kl30/OeT0KU5xt1hkzH2yr FbZ+JGmKLVejonnEPTfEx0x7HENB3/S9Pme/9Gm85vRxpFLxpBGkEaQRpBGkEaQRpBGkEaQR pBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQRpBGkEaQR pBGkEaQR0l/gQ1SeyxDAku6mWHf41hMWlRd1ETZ6dutbDTLD77PW10OxWikt6y3iaLUOladC r2+uzIc+3isjvHje4MyFJb1lunG1HdtWpOq3y06Vpd41LcSkt6y3icfl/VqSFFBbit92Pi0b NIkhrYTwzX9ioNNmv2IMzpQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAHz78NMBw6g2Ch0+Z/YQzGmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA0sHEKG/odRmP2AMvpwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAANLBxKivaLUZf8AXwy+oAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0sHE6K+otTlv14MtqQAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANLBxWivaPVZb9dDK6kAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADSwcWpLyk1WV/W4yuqA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0sHGKW7pNVl P1qMrqwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANLBx qku6XV5P9ZjKawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAADSwcbprmm1mS/WIyetAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA0sHHKa6ptbkv1eMlrQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAANLBx6muafW5H9WjJa4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAADSwcfp7mn12R/VYyOuAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0sHIKe5qNdkP1SMjrwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANLByKot6jX4/9UDIbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADSwcjqLio2GP/AFMMfsAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANLBySpt6nYY79SDH 7EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADSwcmqbaq 2ON/UQx2yAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0 sHJ6q1qtjjf1CMdsgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAANLByeqtqrZYz9QDG7MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADSwcp8+uv6XM7WM1pgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAANLBVdJprnpyDn1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA0sF3c01yAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAaWC7uaa5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAANLBd3NNcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGlgu7mmuQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADSwXdzTXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABpYLu5prkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA0sF3c01yAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAaWC7uaa5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAANLBd3NNcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGlgu7mmuQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAADSwXdzTXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABpYLu5prkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA0sF3c01yAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAaWC7yAsfIeJQAAAeQxssAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGC HixABilZoBeLSjFfdcVtdWRDX4i7zmFXuItFlUlLZQ6V+7SVkAAAADSwf//EADQQAAECBQMD AwMDBQACAwAAAAAEBQECAwYREhc1ExRgBxY0EBUhICIlJDAxNkAyUDdBR//aAAgBAQABBQJ8 u6qzK9xapuJVI+olY3GrG5FY3IrG5FY3IrG5FY3Hqm49Y3IrG5FY3Hqm5FU3IrG5FY3IrG5F Y3IrG5FY3IrG5FY3IrG5FY3IrG5FY3IrG5FY3IrG5FY3IrG5FY3IrG5FY3IrG5FY3IrG49U3 Hqm49U3Hqm49U3Hqm49U3Hqm49U3Hqm49U3Hqm49U3Hqm49U3Hqm49U3Hqm49US3g5LCg5OM 5BaqO8UneKTvFJ3ik7xSd4pO8UneKTvFJ3ik7xSd4pO8UneKTvFJ3ik7xSd4pO8UneKTvFJ3 ik7xSd4pO8UneKTvFJ3ik7xSd4pO8UneKTvFJ3ik7xSd4pO8UneKTvFJ3ik7xSd4pO8UneKT vFJ3ik7xSd4pO8UneKTvFJ3ik7xSd4pO8UneKTvFJ3ik7xSd4pO8UneKTvFJ3ik7xSd4pO8U kiqvEvblfrg0wOlCJ0Ymk0kKP7qUZ4TV6aSCSMmDSaTSaTSaTSaTSaTSaTSaTSaTSaTSaTSa TSaTSQlMGDBgwYMGDBgwYMGDAhaFbjFDYE8whttAgISQgYMGDBgwYMGDBgwYMGDBgwYMGDBg wYMGDBgwYMGDBgwYMGDBpNJpNJpNJpNJpNJpNJpNJpNJpNJpNJpNJpNJHEIJ1SdWaTSaStDB e3K/rxkhRhNNUR1ZRJCZJJUl0zyRm6f/AKbGRss9e4DdZiBES04SQwYMGDBgwYMGDBgwYMGD BgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwaDQaDQaDQaDQaDQaDQaDQaDQaDQaDQaDQaDQXU6RV iuaq2qGO5qtdVoNAphgvblfrPVlpwmW05T7rRhNQU068PpPPPBuaJ1c1JyUIYSzxljH6Iq8i ZW0LE0aEqBuVxgxpqdOrbKGWjI1UISVGhBXXK2CgmtxrqUJmxRbCeWsqZkremtulUmZ6LSgg jrWtQTtrnCkiitV95P8AqTsXVTVaMyet/ahCM0WmyFi4a7bQtJpMGDBgwYMGDBgwYMGDBgwY MGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDAozLRthyruJpJqrl99MwI/g/zDMCH5I/g9QbnrW0k oqpK6KxLsq3Mpj+0h+SMMEZ5YQvlW/p5k3UinzAn/bIkc4V6dajGrScJ3FFUcFc0tWLYuRK9 MTTEWwwXtyv1dKs9JTBYTTahllj1oR+lodmscl6lLFfWllUTxljL+hjtqZ5b4w/LhbMUDB9Y uimKISUO5U3Tb0lvKPohTRWq7lY4sDhbFvxuBbXpRoVfo3JYLl1zsMjAuebZSoLaoPkJE1Wr Morf2IQjNFmsRUuG63kLUaTSaTSaTSaTSaTSaTSaTSaTSaTSaTSaTSaTSaTSaTSaTSaTSaTS aTSaTSaTSaTSaTSaTSaTSK4f01hz6ypLqkTdZDcr+pUS3E7Nyxhou7lNXte26kazHayidW51 lVe13drnUXK6eq8ajg/orp6fpd6Yz1Wm676aILVTM91rdui7XZyfLxu9lWWmp9Skq1mWXzdl a3WOh6dPStIlZ5p2dJOvlda1ammos7T0Uz8hmtW7KNWmppfReXvyv1eZpYz/AEZdMJBUqlSJ 2qhOrUwqRgQjk/yTU/rYCeCZgcmSNG57rRSVLZt1sTurjSt+2FVa42GdgXs1npYNbbajC4Qt 9ta17lebJRZF7FZdOuhix2wsp2alhXuX1HRQUIPTtFBK13ak7S4UbBbydA92ck+12o2NzlXu 9nosrnc/+ikP7DJai16Ge2ETLDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwY MGDBgwYMGDBgXQ/pLMekbRBHdbauUqv9/ff92vyGGNVTmqWFbtyoETDYlWE7s+ral0u1quk7 MuQfzHq4vtipC+Lvl+yeoThURrPUV+UM3u31LmoULoQSpHt89Zsdv6ot1aZuR+pjFUbmdyoP TffKyg0NX36PqI4Sw0w9U2id0tn0ouKaRRpgaYDlDBe/K/RzVxTSIdFWaZppYq0qVGDW013e siZEkKM7I2y0lM1CpUIRJZs/SeTJCH7nVTFjtODbTcHpicIP1e3bcqPbjGFstiz1M+Q5JZrl tCzGytbyJqqdW4fUaGXv1GninbT00TalzKqhcTe8LIW8k9R0f8rLbTWwIUFZvUWzbn+weo/N 3P8A6KQ/UgblLnXYbDToSEuIYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBg wYMGDBgwYMGBZiCag0NSiZNTYEi2hBoXvM1dnWPC6q2ujYjdW+nSmQ22nqJEDRTi2xakSxdQ alydsQMSNZRQNy9xdmFE9LnW0Gt6mnsVlqJPUBb9vXuVdLdctG0Uq1oiipTJ4+nTBGsmSUkl G5GVM+s/puxRtlZ/93grppbb9KUNVVc+k0jpDBe3K/R0TxUU9EdNOesontz04pqE6ZoopqfZ ySwvm4YJ5LbqTVUX0ljiP0T0oVVHqE40FMWq5ZaFmWE4U0LwxvCNquL2w0N6q+q6V3b7aUN9 JiUtaW5JUaeLZcPqCroqnVC7N10s0toMyKFrK0jZb9oOf25+u5z+4v1yuadSzO6ZuvCg1TM6 JEz6UdxX+qoqnhApbbjturThJU/Tb1jKHMQNqdrof+2qsElWWhaKZKJmaimre2k0ZEdtJESC Nno4y0rRjKpkY6UiJGz00deW2KXaTW3RipRNcjfTkl0y/SanLOS0JJf0KLjjn7hMtXzQ1Qm9 RGhIIr6lu+4J4pm+inuKtLBNXlVUHYvblfpH/LrSkmYKMsJZbZWraCGStRqUnZfWU01sasym 1+P+sv8A4/WMh/j6ZMjTStxc1pKtv2qOS2Liv+mYx/TnBn65/SgblDmot2yU7T4aobUykq2y nqEtqdEltKEpLZdKSvStinLGizJaJCGB2L25X6dGeeLvJ07ftFihSqobfnV0KqVTRqT2zP2l 4M8F0LZlmkQzUKlP6y/iH6P8kZP+W3bTUvszY0pmdP4q7F7cqIqUk0s8CFOWpI3L6DfP74mP es5G+JoDo80XOM0kshAWUZISSQzHP68ZIyEYRh/wSyxmjbVh6iSSWnL/AM6pX28ZZ1kxCVZE 0LDQsNCw0LDQsNCw0LDSsJplkoiWz1alwX9FCs3GcjcZyNxnI3GcjcZyNxnI3GcjcZyNxnI3 GciT1IXyzxfUsrNW9SFs1XcZyNxnI3GcjcZyNxnI3GcjcZyNxnI3GcjcZyLdvudwcLouyS3z cZyNxnI3GcjcZyNxnI3GcjcZyNxnI3GcjcZyNxnItm4ZLgROnqNPBTuM5G4zkbjORuM5G4zk bjORuM5G4zkbjORuM5CX1IVQUONWWvSvblSWaenNI5zQILqESCqhMdaka5Dq0yKqhKTOFCUn dIxM1K00PpD+zGWETpmmJgwYMGDBgwYMGBA3KHNTbloJ2OX/AKXH8LqdQhVOqPdxSss9K80k yv3o09FDeDU5V265m92rdUjVKlQSRy7PkP53BgWMaZFRrMS5OULYXVFv2RZGp9gXwj9iW9wp SVUdbBPD8R/+MZYfjBgb0ffLljDTpp6lvr6U3thzKLGtUJsGDAxQ/nvUjnMGD2vSifZlmqa3 XCRRQtlXWpyW64TkjMsnSVWZZRSYIwPTH/EsDBgb2KRSgizqJpoW44Rp1GBfToTW44yEbbWS JcGCaBR4S9eVwYMGmESNGWJ28DofnoQOlAhTISf8GIROmdOJj9bFbyl+UNDKmZE3/U7Rwrlr EK53BcTX98mUWjHq+3Vtd0TWyopxti3a7Mo7gioJqw3TanR4ly99M6YtuGvUFb+kU14P6OFZ I8IaEtN8pU3OD3SgrdKlBWt6ZPJ+P/zSST8dM6Y2VZEThWdEaemouKhVVJn2hRqpXpNRl0HT OmM0uHv1Chl96Z0xdcNSpJ96RxpTvCes4zL00iOFyoILaboklbl77SVoOmRpnptDBSk/HTOm M65OgpyPyKerUcUySktcKDbNLcCOkpkX0IpumdMnkKPCXpyhJTmqTJbEc1NPbxxNvHE28cTb xxNvHA28cTbxxNvHE28cTbxxNvXE29cTb5wNvnA2+cDb9wNv3A9gOB7AcD2A4HsFwPYK89gr z2EvPYS89hrz2GvPYS6Jt+tNvlxt6vNvnAQ+ntbuUtJOhodWU6sp1ZTqynVlOrKdWU6sp1ZT qynVlOrKdWU6sp1ZTqynVlOrKdWU6sp1ZTqynVlOrKdWU6sp1ZRxTzK6v2uufba59urH26sf bqx9urH26sfbqx9urH22ufa64hRzpli+y1qlw9jLz2MvPYy89jLz2MvPYy89jLz2MvPYy89j LyNiL4n2Ov7QhYq+B7GXkLNXTKPYy89jLz2MvPYy89jLz2MvK9mrk8nsZeILLWpXC6bbUvbl 7GXnsZeexl57GXnsZeexl4ps1clT+xl57GXnsZeRsVeWkx12GMlhuEsPYy8U2auSp/Yy89jL z2MvPYy89jLz2MvPYy89jLz2G4TEksZGe8+ULQt6VvSGDBgwYMGDBgwYMGDBgwYMGDBgwYMG DBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgd1s6BL Vd1DSoWXMjQzSXWlq011ypkM9G8ENaDe60nMwU4fy2B3earY5T3cnRyS3Simmb7gpOKnA6Q/ psDupqoW1Rc9SnXTXVoT0V0imLddtfpTvaem4LHhZBPgd4fxOCrPClTRq3NQlTXunlS+5qE0 W655Vpgd4fxOCf8AbI13TWUSJ7rTKo0bp1U/d7f3ct0UZpCSH75+NvPk00MqIy4MGDBgwYMG DBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDB gwYMGDBgwYMGDBgXIKbgmoslOWelbdGgkpM9KnH2mjmb61vyK6Ta00WqXBTh/LYKzdSUKU1q 0EVJXaiRbPFjpzuGB0h/TYJ6cJ5aFpI6FCdikpUWdqg1NULRoRSr7Y7qlMklmrYHiH8TgjLm FC3pE4ntOgiIsNCYltelCngeIfxOCaXVLFloxZqFu0qK6lblClMnt+mkmU25RUoIS4hLD90/ G3lybFzfnsSfjbx5Ni5vz6fjbx5Ni5vz6fjbw5Ni5vz6fjbw5Jj5vz6fjbv5Jj5rz6fjbv5J j5rz6fjbv5Jj5rz6fjbv5Jj5rz6fjbu5Jj5rz6fjbu5Jk5rz6fjbt5Fk5rz6fjbt5Fk5nz6f jbs5Fk5nz6fjbs5Fk5nz6fjbs5Fk5nz6fjbr5Fl5nz6fjbr5Bl5nz6fjbq5Bl5jz6fjbq5Bl 5jz6fjbq5Bl5jz6fjbq5Bl5jz6fjbp5Bm5jz6fjbp5Bm5jz6fjbo+ezcx59Pxt0fPZuY8+n4 26Pns3MefT8bc/z2bl/Pp+Nuf57Ny/n0/G3P89m5fz6fjbn+ez8v59PxtzfPZ+X8+n425vns /L+fT8bc3zmfl/Pp+NuX5zPy3n0/G3L85n5bz6fjbl+cz8t59PxtyfOZ+W8+n425PnM/LefT 8bcnzmjlvPp+NuT51tIZ1rt59Pxtx/Otxp+1IPPp+NSNPePXn8/GtXx/P5+Navj+fz8a1fH8 /n41q+P5/PxrV8fz+fjWr4/n8/GtXx/P5+Navj+fz8a1fH8/n41q+P5/PxrV8fz+fjWr4/n8 /GtXx/P5+Navj+fz8a1fH8/n41q+P5/PxrV8fz+fjWr4/n8/GtXx/P5+Navj+fz8a1fH8/n4 1q+P5/PxrV8fz+fjWr4/n8/GtXx/P5+Navj+fz8a1fH8/n41q+O4zRkbyaGqWlThRp/2Iw1Q TJpEsnhi1JBcmQoZUFH9CnrdvSb1dROlQrqCJUmqztdFvWSldvcJqU7S5xHNGtr1EVKvTQ1G tbGnUaVvcUKS1RVmb1+mRCu6iRsV0VLhSWVhO0rKNWq3rZ0/aONFbI3KZXD+3Pxv/8QANREA AQMBBAgDBwQDAAAAAAAAAQACAxEEEhRREyExNEFSYHEQIPAwMjNAQlBhBRUigSOQkf/aAAgB AwEBPwGe1SskLQVjJs1jZc1jJM1i5c1i5OJT7RKw0vLFy5rFy5rFy5rFy5rFy5rFy5rFy5rF y5rFy5rFy5rFy5rFy5rFy5rFS5rFS5rFS5rFS5rFS5rFS5rFS5oWmY6gUwWl200TWkbTX7Ja fjO8GxSP9wJ0UjPfb4ODrpNdiBOzwYy/qqhC48VoHIwuFUISRUIRG9dK0Dk9lzVXyXS3b5mM dIaNCjsXGQprGs1NHy7HiRt4Jrr1fY0JFUwtBqUbjx42n4rvCy10LVbDSBybVxoFaGMZGIGj XxK/HhZoxK+hUUFWvvcFHA6QVCbFJeLRqRs7mkV4p0LnSlrQtAQ5oPFYcYm5wQhJcW5LQOa8 NK0bayVGxXidR8jWueaNUViA1yINDdQ+Zs7miMNqrtGkDmRbcL2tyV4ExgFCl+7X+NfMJHNa WjYo5DGahE3jXxtPxXKAN0ov7FZrZZ2RaOaK9TYmtbNto1uQ2/2rQYY/dGtfqH0+MBuRvctM 2+ynHamMut/hQnitRme07CFMLtxo2IkOfIwHWVDEYpAXrTjQ3vq2ItaXucNZU22MrU6SVua4 +MNkdJrdqCZG2MUb83cbkqBUV1o4K6KU80TNI8NVps+h1jYo7MHx6QmnjafjOTTRRfDamSlm xVqalfqH0+UCqjdozWlVJIZBd2BXVdV1XVdV1UTWOeaNUFkbHrdrP2gvcRQlX3XbtdXjafjO To3E1CZb9GwNLDqX7m3kK/c28hVrlNqu0bSiaLopXyhxV4eeGB02zYoomxCjfttpH+ZyZC+T 3QsNNktBPktBNkjZ5jwWFl5Vh5uVYaXlWGm5VhZuVYWblWFm5VhZuVYeflWHn5Vh5uVYablU Fjc41k2IANFB8gdaOvb64+09ev8AvsPx5KrhRE18ZxWchMYGNuj7V69f37DhqWxDyevX9+Qf nyTbwe/QM28Hv0DNvJ79Azbye/QM28nv0DNvJ79Azbye/QM+8nv0DPvJ79Az70e/QM+9Hv0D PvR79Az70e/QM+9Hv0DPvR79Az70e/QNo3s9+gbRvZ79A2jez36BtG9nv0CINPbXZDoFkYZU jj/u+G1N4L6UVxHhmPW1HX67eHD1+Vx8/wD/xAA4EQABAwEDCgMHBAIDAAAAAAABAAIDEQQU URITITE0QVJgcfAFECAiMjNAQlBhFaGx0TCRI4GQ/9oACAECAQE/AYbNE+MOIVzhwVyiwVzi wV0iwV0j3BRwQyiuSR1qrpFgrpFgrpFgrpFgrpFgrpFgrpFgrpFgrpFgrpFgrpFgrpFgrpFg rpFgrpFgrpFgrpFgrpFgrpFgrpFgjZYRpITzZm6hVOc06hT7JZvhNQTpWM94psjH+6UNKaW5 VKI4+TnFu5GYBZ5qzzUZQDQoyjJygs81NflegOB0D1PeyMVcVJbt0YTnufpcfl5YnQvLHawn x5FNOv8AwmRrXBpOkrUjp099/v187N8FvlafilWQVmCcQ0VKszZHzutTnGh0AbkRv8rTIYo6 hST0LKb0+ZsZoU6WMNDyhaGurTcmyhsYc4rPAtcRuV4N3y96MwDQ7FZ5rmFwReaR0OtBoGr0 Oe1gq5S24nRGi4uNT8wNat0Uhnc/JNEDlSNceBNdnWxSP15VEY3NbOSO6pwOZy6f8lP2x6+q SzRSytmcPabqVpszLVHm31/6TGhjQ0bvOzfBap8rNnI1pzXE1BXiPjzbMTFCKuxK8Kdbrccp 0hyV4d7OUOnnO3KkY1Zl2S+u7V/Ke/Kd7dQN1FpbCwjWCoTlZZOsoAtZFJTQFNKJIyGLMHPZ P060HODGNOgb1BqkWlscTqalo857W2PQ3SU+R0hq4/NmWQ6C4rLdiqmlEZXnW5Zbq5VdPqtt pudndPStF4L4t+pNc2TQ8fwrb4ybLaxZWx5VaavOzfCaipPfd1Vu8Lht9C/Woo2wtDGDQrB9 SB9MjM4NdFHCIzlE1PrKc9rBVyntbpPZboH2hsMTHmRrQCd6EMYkzuT7WPnZvhNTXgaCn2Ay PLg8aV+mO4l+mO41ZIRZcqrq1R9o1Q9FFT1z2hkI061LM6Y1d9h/H+SzfBanysj94q8w4rPw YrPw8SvEPEr1FxK8w8SvUPErzDxK9Q8SvUPEr1DxK9QcSvFn4ln4OJXiHiV4h4lPbGtFI9aJ LjU/IDR30/pD2dXp/C7/AJ/v01Xff+l+fR33/tDQt1Fvr51oqaKd6qLfXvXVAU84DSAFPeXu yj9q7/f+kd/nv9A16UakFH8eZrQ0TtOrvsfujTd5Yo/jvR/foh2cdOQYdnHTkGHZh05Bh2Yd OQYdmHTkGHZh05Bh2YdOQYNmHTkGDZh05Bg2UdOQYNlHTkGDZR05Bg2UdOQYNlHTkGDZR05B g2UdOQbPsg6cg2fZB05Bs+yDpyDZ9kHTkEz5ixNxPIL5C+gO7/2+OpHeh76C+kr6kNQPT+EN HfVbl9Xf4W71/wD/xABQEAABAgMCCAgLBQQJBQADAAABAgMABBESIQUTMTNBc5KxIjRCUWHR 0uEQFDJgcXKBkZShsiAjUnB0MGKTwQYVJEBQU4KD8EOis8Lxw+Ly/9oACAEBAAY/Aks4tb1U W7WNppPVHFl/x+6OLL/j90cVX8R3RxRf8fujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4sr 4jujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4qv4jujiq/iO6OK r+I7o4qv4jujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4qv4juj iq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7 o4qv4jujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4qv4jujiq/iO6OKr+I7o4qv4jujiq/i O6OKr+I7o4qv4jujiq/iO6OKr+I7oGKwa8QdOPoN0feMFv0PE/yjl7ccvbjl7ccvbjl7ccvb jl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl 7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7c cvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccvbjl7ccv bjhKWn/VDWpG8/slKqfRzQpLZIKxZNNIhktLWZg5xKhcP8LpLsKc/e0e+AZt+z+411x93LpK vxKvMXCnmDU3CDiHm3qZcWsGn2BDWpG8/sctIFmyu/0UhdKFS00NwhQ6YooCumn+EBSkeLNf idy+6AXE+NOc7mT3RRIoBoHmJ4jKm03X75xH09cNzLLzja0q4QQOTzwlp841lZspdIoRzV8K Ya1I3n7FVGkaYoq0mKtqCvCotGrqRdaHfC/GkJC7RhlLSHLdj7wL/F0RwU2R4WnXGg+hCqls 8qJx9SG5VCEsIzKXfTceeJQhDjPjsysJOMFG0WslOe+JkeJPeMKlraZVbgxiDjKVyc1/viQ+ +dSX1NjHchdoVNLqD3mMIoODJhLyGUrQ047w033qyeiFYxt2jj0swgNqSmxbbrXyb4E6A6pw 8ut1bRBupdk54cdcbTj5UhDbhF3D0q9W8xi0NvtrIeS0hxYJespqlQu0mJlbzTqnG25fgW6U WtBJrdziJ1Uuyp18OpAsMpcPkq/FohLsw0+p7EpfVZdCRe7YpSzE++bavF3F2FBXlJSuzQ8G g9/siYdDKXA1PoNLIvFmtMkIUGkNWUBNEDL0/bxi3w2aWqUrQUrffzX3VhbS7loNk/s6C8wF zH9ka/eHC90AtNWnP81d6v8AD1Ec0PY5VqzSl3gAAPifoFPfGWMsX+DL4ZRcvZLjj14VpTS/ +UImUqq0pFsK6IwmHKWWnKtADkGtN0XxdF8XmJP+pW8YkqOMsoCuamXRlhsuABdOFTnjLBVz CGMYhSXXKXJFR74WitLQpWJZKcJN1Uqxigc0K3VhqRddamHHUJW3MS9bKwdFIlZZ1lQmXHEW XK6PR4UQ1qRvP2E0yWeuPIHs8DitATTwlmYdaBQioYUb3IeRK1EuDUVNa88WlCprURf9iemA spUwmqU08rLFIlMIlZq8b0Uyc32PFLYDH4QgA5a5cuXwNNWgi2oJtHIIabRMY+2m1koR4WWB lcUEx4vbxiLIUlRFKwpq3i0JTaKqQttQopJofCwwVhsOLCbR0QhhL+OtJtZKUiUn21OF52za CiKXgmA040pd1kgLold1BaHsELcV5SjU/saC8wHJs+KM/h5Z6oBYYAXSmMVer/EXPRE16U/z giGZNc0t6h0k38Hmhthh8tKWAkX3X1hE2mdW5fQ1hE0lRbUqz5J6YaWpRUSMpPSYnW1uKWOY q6YGOWt2TcyWjWn/AMhUxbW3JtnyUmleiJDB7ItrS0VBPSf/AOYeRa+/QfEx7f8A9a+6PFnh Y8Zl6gewLHyhp1/D39UyoTQot0tn3iJOWl8MHCuD5hSUGpNBU0yHIRDf9H5OaVJN3WlpNK8G 1u0RJMvYTmJuSdVjKBZSQU0rz335Yam2sKTOLmeCGQsixZSkZa31iURLH+1zIolRvsjSfnCZ p7Dj7c+oWrNVGyeatYl5aedVMPIAJd0lVMsSqHQ21aRaQlQvP4h6dMLddUENoFpSlZAIMx/V qZnxwqWhxaKkpKrq+yMG4QeZxEtVKglKeDceEBCHW1BxChVKhpHhR7Ya1I3n7CAL1AX+Fy8W ycngU6rRo54VNu893p+xd4QtVBjXCf5QqRQLlO0R6DkiYZbGYSmg5qd0BiZf8XboTajxZqcW XzcOFp91IxBVbQRaQrnEDCGFXyyyoVCRzQZmWW5MtJqC3XTD7U064yitGaG83+iGmmFLUlTd r7w10mPH8JPeLS1KgaSOeFhjCCmlpFarPWIlx5SUEqr6BDE2i/FKKFEf86IcmVXF5dkRNo0F dr33ww9Oz5Ut1NqiT/LLBwhgt8utJvUk33QtueeW0slIaCD5RPshDLKlqSUBX3hqYwd/t/Sf 2QWE4iX/AM1f8ueAW28Y9peXl7v8Tc9ETPjTli0RTgk8/NCGGXbbisgsq6ob9n0RJelG8wPW TDdkVolJ+cIaedsuoqCml+WJ1zQRX5wjB0peyg1UvR6YVgmd4PC4B6e+H15UywI9ybO8wrAq Kpln3w6EjJYy/IWhGBptIsNqCEmnpsn5ERND+kCymUbJCAqtKcn2aYwccEJQiUbW3jForQm3 EiqXcVJz9gKXMk0SBoN1/PDDuG/6RsTWLPBQlKwFdFSkARguzktL3CME4QbTaQxwV9FaU3Ql 5czinKcJpQNoHmhmcYzTqbQrDeEFqsuy7oLf7x5olMGyiFy8ikCYnCvlCtyIA5uaHViz/ZTj unp+W6F4EfXbRTGS6t48LfthrUjefCgI8tZhaXOEVX3xW0qNJMUbTYbrwnKXDrMIC2SAE0vN 8FbjdEJykkwvEN2EC6mU+37eCgi5dpC//bfEjhdGbxNo+nRv+UYcZPkOeT6KWeqFNVxbTd7i uaEywQ88+lVMak5D74kvVMSniVFKbs1bHQKUicmp/wC4QQLlcwiWXktPg/8AdEpqh9RiQYau ZvuHQBTf4Jl88hFPf/8AIwzIqNVKWpxFenv3xgWRHBUlSXHKdHfWJd1IzqKe0f8ABDb2GHFO PL/6STGEjg5tbTFhzgOc9mJHXp3w1qhvMYO/2/pP7AMyzSnV9GiEuztJp/8AByE9f+KrJQpw fhQKmKjBaxLglKn1AAJIy6a3G6G1MhKXAlSrYQeDkFPSbV0FaLKpq6y5+Lg1u9kAuJpMJWUJ dWKcIKs3f6iREw6pSZqXl0lagOgViXlA0ptpctjzUXNi4WfTwskB37gqKcYkaMlr0ZBWJzEl tspScfQ0oNN/sMMM4PatOTFqpQnyQnLX3j3w3hCaaSEmoSpfMKmvuBMOzkrikzCzRxweUSpV L/SqBhFuy7MJRYxo0A30hpM5JY/FptJeORPR8hCVTkqh5abrZF/vhuWMgzim1WgLOmJVLv8A R9E/Itp4Ty0/IEZPbDMpgP8Ao/iHrd7yNx6zEhL4TaTNLlmkoqrnoAT8oxKkhTdKUIjGf1e1 Xmpd7skJaZQG205EpFAIfk5tYbbX/wBT8B0GJ5l44zxmziH8lpIrdTRz+DCJcBXaYWkISKk3 QzNkFMuwgptnIVUuHhb9sNakbz4U2PLRfFcnphLIcKibgm3CJqacx9f+ki4D0wEoSlIFws0A EW1qstjTWA0jyuQzzdJiYUolSi8an2D7TaSQmqgLRyCJNiXdQ6hAJ+7VUD/lImGy4BMN1bQm t9Ff8MKxzqWm3EEWlmg54wkwt1GImF1Q6k8HTp9seNv4UbWyk2g2kip+cSk7LzCFUuLdrhX9 ENpl59uRmTnlLpa+cKZRhpx90X2aiz7oZafISWnwFHRliXUw8h4BoXtqtaTCJHCDqWJhsXLU ae2FOTWFkOIpcEkD+ZjCS/GGg8q1ZSVAKNBdd7YaWpVltw2Fe2HVpVabbNhPsjBM0h9tyYaK SWwsFQuv3RLzCcIolylN6FnJEzghmeSVLQq06o0SSRS6JW24mwiYTVdbvKyw2pl1DyQ0L0Kq MphmRmJlMs40B5RpeNMKSDUA5ftJem6y0tzctXVAZlmg0jo0+n/F3m/GplLLhWrFJUAElVan JXSctRBxL77ayQq0kIFCCTUCzTTTJCXLbrigorq4qtTZCa+4Uh1K1urS6QVVI0LUvm51mHJR FbDhBWqyhJNNHBSBohQxj3CVaNbKtOShFKZB/pTCGy8Rg9uypLYVepQbCL+DzDn9giYlS88t l0WQFEfdi/ybunTWHH8a68+scJxylfTcOhI/0iJeWdm5l9lizi0rsXUFNCRougvCYfTaWFqS CmiiFqWmt2gq+QgtsuuhBUV0NDebzo9O0eiKFRV0nw3isXJ+wQy0Kc64HjKkEJRwQrQaxcaE XhXMYcbnHjLzTVzjVgm/ogS8rL2JKXQpRcc8pRyZNEBtIDVTVKGhfXnpAxqEr+RhLqa0Vzw1 7Ya1I3n7DiigFQpRVP3orQhfJI54YXN54jhJOkdPTHjFuyjTU5IcxAAIH3aFG4nph8zVrxq0 bdvnh/WncPsD7F32WWX3DLzSfKWbqndC32ZkzT5FAAbUPzJFkuKKqc39xDEs0XXDzaIS9M0m Zv8A7UejzNJW0LX4hcY8tVOZVDBxE2pjoSm73RnUqJvUpSLzGOQ9iXaUKm26VEErfccUcqtJ jN2z+/f4GvbDWpG8+G5MPJOUU+qEzUymrgvQg8npPTBdeVilHNjm6YLJaUV15IuMWwv+1Zaa PRAWEYubRdky9Bh9KgQoOmo9gi9H9+Cz9zKaXTp9EYmWbsJ0nSr0+azXthrUjefBaN55vBZW AU1yGArFh0jn54zSffGaRtxmk7UWlNBB000wuzpvqNPgt+Sd/wDewAKk6BCZnCYoMqZftdUB KQEpFwA0f3hCAm24vIMl2kxnmP4J7UZ9j+Ce1HGGP4J7ccYY/gntxxhj+Ce3HGGP4J7ccYY/ gntxxhj+Ce3HGGP4J7cZ9j+Ce1GeY/gntQpl4JDqRaBRkUIXKyTSVqaVZW47WldIp/OM1K7C u1GaldhXajNSuwrtRmpXYV2ozUrsK7UZqV2FdqM1K7Cu1GaldhXajNSuwrtRmpXYV2oSVsSy kaQkKB99Y/rOqvFrNrJfzU9NboJZl2EN6ErBUffURmpXYV2ozUrsK7UZqV2FdqM1K7Cu1Gal dhXajNSuwrtRmpXYV2ozUrsK7UZqV2FdqM1K7Cu1CZWdabRjLkLaBF/MYSyhvHTS02gDkSNB Pt0RmpXYV2ozUrsK7UZqV2FdqM1K7Cu1GaldhXajNSuwrtRmpXYV2ozUrsK7UZqV2FdqM1K7 Cu1GaldhXaguWcW83c4jR6RBRIMtlpJzjwJt+y6kZqV2FdqM1K7Cu1GaldhXajNSuwrtRmpX YV2ozUrsK7UZqV2FdqM1K7Cu1GaldhXajNSuwrtQjxmXZUzXhYoEK3xLuINpCxaB5xdDWpG8 +C0hVkx94j2iMtPSIzifbHlo98eUmPLT74ziPfGWvoEfdt+1UWlq/a3ftUsSzZccMB1yj85/ maE+r/epbVub0/YkAtAUmZfDJWpdkIuN/wAowohxTbcrIhsmZDloLtCA741RJcxNC2sKt0rS zSsNMy82FuOgqSLKhWmXKMvRCmpWYDq0i15JFRkqK5R6PsJ1Kt6Ywj+oc+o+FBXOuF9bIdDY l7rxkrWG7cuauKsAAgmvN0Q3LrSlorBUFFYIuyw2gNAqcClIotN4GXdDIxF716BaF91YLOJ4 YTjK202bPParSFNPIsOJyjw/8/zvsMS9qxjVhFqlaRMOyk3414uqy6gt2CL6V6YaSpiinVWE i0PK5jze2B/ZsteWnRl05eiMe2wS3eReKmmWgyn7GD/1Df1CGP06fqV4W2kz1ZtbGPS0WaDJ WlqsKTir0tB48IeSdMYhTFHKFRFtNw5zfdE1dZmGFITijS+vTWHaSxq2opUCQLxzc/sjxkNf dUKvKFac9MsCZWzRogGtRWhyGmXw4R/2/wD2+x42/MlhrGYvgNFynSeaE4kB5tx3EtuJNyzF sMXUUfLTU0y3VjHKY4FgOXKBNk6aQ3WX8tQQBaFxOSvN7YmXnLDeIpaSXE13/YwV+nT9IhrU jeftXRpjTGT+48/7Oy0LDI8t45ExipdGXylnylf3uW9Re9P2MHAhpbLEwHXEPXhSaG6MJmV8 WlW3lsOsNoTRIU3+IAaYThGYXLh9U22+ttsmyEoQU3XXm+JG241ZZemVrsk1o5WlLumG1zCm 3MQ0WW1h5xRIr+E3J9A+wNSremMIfqHPqPhl0S7rqGENIQps5CRlhCi0tTSng661i0J+YvV7 YklWHKMFwcFtCapUOYRKlSXyuXQ42mgFCFVocvTEvMWFKbRLBhQIFclICg48lpLWLFllvnr5 GSkLcl2sS2eTSny8Pt//ADfYl31glLawo0yxM+JIeU5MrClqfoKAGtBSGnUpcCcel5xGLQMn SLz7YlVFLtGphx03DIr2xKOrQ74zKoUhCU0sKrXL7/sYP/UN/UIZ/Tp+pXhbRLANAMJaUsti 3kvv5oWqw9j1yolzks3UjCS1pd8XnE2ailtOSJyXZS6EuqbKLZr5PPBmRLuW8ZaJxaSSKUy6 PZCpdYdmAEqCEOtooCchCso9EFCQpDy20trGLRS797L4cI/7f/t9i9ybl3gqtqWVcscxBhK3 WXW8XN+MIS1SkYOnFJdLgS8ptIpQ1UcsIcsuKmlyLbYF1inPDr7bb1qYeQ66FU4Nk1u54wo0 4HP7SoLQQNIJN/2MFfp0/SIa1I3nwBKRaUdAgLOKYrodUa7oz8rtK7MZ+V2ldmM/K7SuzGfl dpXZjPyu0rsxn5XaV2Yz8rtK7MZ+V2ldmM/K7SuzGfldpXZjPyu0rsxn5XaV2Yz8rtK7MZ+V 2ldmM/K7SuzGfldpXZjPyu0rsxn5XaV2Yz8rtK6oz8rtK6oz0rtK6oz0ttK6oz0ttK6oz0tt K6oz0ttK6oz0ttK6oz0ttK6oz0rtK6ozsttK6oz8vtK6oz8ttK6oz8rtK7MJ8cmGsRpxJJUf eISywgNtJyJH98aUgpFhKga9NOqPLb98eW3748tv3x5bfvjy2/fHlt++PLb98eW3748tv3x5 bfvjy2/fGNWpJTiym70iJp9D0uEuuqWKqNaE15oz0ttK6oz0ttK6oz0ttK6oz0ttK6oz0ttK 6oz0ttK6oz0ttK6oz0ttK6oz0ttK6oz0ttK6oz0ttK6o/qq214x+Kps5y1zRnpbaV1RnpbaV 1QtnGy9pKUr8o6a9HRGeltpXVGeltpXVGeltpXVGeltpXVGeltpXVGeltpXVAUp2XIKkouUd JpzdMZ6W2ldUSr6nZcpadSs0Ua0B9EImGHGUoDQR94TWtT0dMZ6W2ldUZ6W2ldUZ6W2ldUZ6 W2ldUZ6W2ldUZ6W2ldUOvKdlyltJWaKOj2RnpbaV1RnpbaV1RnpbaV1RnpbaV1RN+MLbXjbN MWTor0dMD76W2ldUZ6W2ldUOvKdlyltJWaKOj2RnpbaV1RnpbaV1RnpbaV1RnpbaV1RnpbaV 1RnpbaV1RnpbaV1RnpbaV1RnpbaV1RgtJyhhI/7RDWpG8+BM08msw4KivJHmmlTSQt5xxLSA rJVRpfBbwhi30YovByWbKaAEBVQVH8QOWFhdqqXcSL0pClWbRoVECFONsvuMoaS8txITRKSS OfoMKtlSWm3Cha7NQaN27r4cuXwEqUaFCsgrSqVEf/IOKSu5CFkq/e0enwTGpa3ueCURYSqU UhSn18pAqkV9HCvg+NUxmMdAShSU8FC7NeEofKGR94MaV3kXCyK1PpGSMS2w8DdaKrPB4Nbx Wvyp4Ea5r/yJ8ExMMpC1tJt2VaQMvyjCCW221IQ2PFT/AJi7qj3rTFqclnEmrv3jaRYIQqhp wq5L/fEyGwfuDZKjkJpW73wy/N2VNLli+oIlVskG65JWaL9kGUWFpUDTGGlmtm1ur7oZnJdL SJdwIxbDySXXidAoeDd6fBO6le7wKWciRUwzOnxXxd1GMxNlQUgUqOFW/wBwhCprPFNooRZR TgJJ8pd/lenog2GH1t28WHQE2SoptDTWJRsyrqX3mkOqSCjghX+qpHo8E7qV7vAo8wiVccfl JxLrJddalE0Wxwa38M+jRCEtMuuOKdxNhBQq+zayhVMnTBK5GYtjHKsosHgNqsk+VAlwoqJI TaBTlpWlK2vlEoRKzFZpGMbQbAJTdf5XTkF/gHpjB+qG4Q1qRvMNesIoMnmmWXa0qCCk0KSL wRDi5h52dcW3irT9m5GkAJAESzLT76Fy6itMxUFdTlrUUOXmh4qW48XmksrxprUCvaMMSilP LQ0VqtFXCUVAgkmnTDaJiamJgodDoWsprdouFKQ+Gio410um2efR6PBM6hr6nPAl5yqiG1NW eSQqld0Npl5qaZUgLTjApJUUqNaGo74mlLW8DMWLVFZLPNdp0w1NqedWWjabbNmibqZaV9lf AjXs/wDkT4ClQqDcYkGgp5Qk3C4kqUKqvrwruenuEIxIxq2saUodVRKreWt3TDMpatlKeEvn Okw3LvTc1MMtNlppKygWLqVuSL6c8ONY1T3jDiFPOvKooBP4QlOkXQy5kxVaCg/57vBO6hf0 +ChyQhAm5oyzeblyoWEfKp9pMAy81MsOWbFtJTUpokU8n90QqqnOE+Jg38oJp/KJVtU1MONS 9iwhdjk5OTUezwTuoX9PgI54GDLS8QGg1arwqCBNmYmHnbeM4ZTQmyU6BzH5Q4ca8baXUUJH BDhqaXc8HFTMwho3qZBFlRs0rkr84Zky++mXbaDVgWTbHTVOXpFIpAjB+qG4Q1qRvMYP/UN/ UPP/AAfqhuEN6kbzGD/1Df1Dz/wfqhuEN6kbzGD/ANQ39Q8/8H6obhDeqG8xg/8AUN/UPP8A wfqhuEN6obzGD/1Df1Dz/wAH6obhDeqG8xg/9Q39Q8/8H6obhDeqG8xg/wDUN/UPP/B+qG4Q 3qhvMYP/AFDf1Dz/AMH6obhDeqG8xg/9Q39Q8/8AB+qG4Q3qhvMSH6hv6h5/4P1Q3CG9UN5i Q/UN/UPP/B+qG4Q3qhvMSH6hv6h5/wCD9UNwhvVDeYkP1Df1Dz/wfqhuEN6obzEhr0fUPP8A wfqhuEN6obzEhr0fUPP/AAfqhuEN6obzEhr0fUPP/B+qG4Q3qhvMSGvR9Q8/8H6obhDeqG8x Ia9H1Dz/AMH6obhDeqG8xIa9H1Dz/wAH6obhDeqG8xIa9H1Dz/wfqhuEN6obzEjr0fV5/wCD 9UNwhvVDeYkdej6vP/B+qG4Q3qhvMSOvR9Xn/g/VDcIb1Q3mJHXo+rz/AMH6obhDerG8xI69 H1ef+D9UNwhvVjeYkdej6vP/AAfqhuEN6sbzEjr0fV5/4P1Q3CEasbzEjr0fV5/4P1Q3CEas bzEjr0fV5/4P1Q3CEasbzEjr0fV5/wCD9UNwhGrG8xI69H1ef+D9UNwhGrG8xI69H1ef+D9U NwhGrG8xJa9H1ef+D9UNwhGrG8xJa9H1ef8Ag/VDcIRqxvMSWvR9Xn/g/VDcIRqxvMSWvR9X n/g/VDcIRqxvMSWvRv8AP/B+qG4QjVjeYktejf5/4P1Q3CEasbzElr0b/P8AwfqhuEI1Y3mJ LXI3+f8Ag/VDcIRqxvMMWfJaUHFH0ef+D9UNwhGrG8wAoffucJfV5/4P1Q3CETLg+6ZQKdKq n8gMH6obhCvW/IDB+qG4Qr1vyAwfqhuEK9b8gMH6obhCvW/IDB+qG4Qr1vyAwfqhuEK9b8gM H6obhCvW/IDB+qG4Qr1vyAwfqhuEK9b8gMH6obhCvW/IDB+qG4Qr1vyAwfqhuEK9b8gMH6ob hCvW/IDB+qG4Qr1vyAwfqhuEK9b8gMH6obhCvW/IDB+qG4Qr1vyAwfqhuEK9b8gMH6obhCvW /IDB+qG4Qr1vyAwfqhuEK9b8gMH6obhCvW/IDB+qG4Qr1vyAwfqhuEK9b8gMH6obhCvW/IDB +qG4Qr1vyAwfqhuEK9b8gMH6obhCvWiZUklKg0ogj0eAjn5oSgWiB+JRUfef2JEWUFwjL944 pZ+Z8zVslx1m1y2VlCh7RAbS487+8+6pw/P7Lni9jH04GM8mvTCUuzDku4iptNPW7dee0iHk rmcbMFkIbUpV1aZcnOfkIcYZcKXi1YS4VHLTLWAKYnhoJV4667UA3jhCKNzVldp01tnIfJhw ImcUFGqR4w4qzwCKVPTQwlUq6E0TShcKaKrluHC9BhDb5BfAoVBRVU88Sn32NWhnFuDxhxsF X4qpywtYfLrd4S2ZlxFLk33eg++JlpDtlpuZHDLirVAhPB9HtiWKZmqmm0BQLiqLUDfX0w64 t+mMQ5wA4aIJpZp6KfOAp10uptBVszLl12SzkywpDQbU0pOXHLaUk+kZflHDfL+nGqmHAcn4 MmWJFCZmytACHzbPCF1SOm75w8806hxCyQlt1xVEi6h+RuhTinMY0XLdfGHBZFPJsZP2mD9U Nwj/xAAtEAEAAgECBAYCAgIDAQAAAAABABEhMUFRYXHwEIGRobHxcNEgwTBAUGDhsP/aAAgB AQABPyHDseTWwqqY+2z99keieaa/25+yT9kn7JP2Sfsko1ns2WJ+6T9kn7JP3iftE/ZJ+yT9 kn7JP2Sfsk/ZJ+yT9kn7JP2Sfsk/ZJ+yT9kn7JP2Sfsk/ZJ+yT9kn7JP2SfvE/eJ+8T94n7x P3ifvE/eJ+8T94n7xP3ifvE/eJ+8T94n7xP3ifvE2jQ5pPNkW+yTRKGaPJzvqd9Tvqd9Tvqd 9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9Tvqd9T vqd9Tvqd9TvOd5zvOd5zvOd5zvOd5zvOd5zvOd5zvOd5zvOd5zvOd5zvOd5zvOd5zvOd5zvO d5zvOd5zvOX/ACDNuG5XX8NmpcdNiIaZjXl4GoIUWnEVpQm42nTvQhs9evlA3D0/4oAAAAf/ APpZrpBR82JWMdwt9X6g4gfvnTyminR/xP8A/wD/AP8A/wDSUlJSUlJSUlJSUlJSUlJSUlJS UlJSUlIHUBlV0n21oVMpwlOEpwnvP8JYy7ly4MRrLhAxu6RasGrnBx5xXKQlscC9OpOUimMV 5ov0f9o/yiVBazJobVLpq+IaqP19PrcPlxgKCdM6Z0zpnTOmdM6Z0zpnTOmdM6Z0zpnTOmdM 6Z0zpnTOmdM6Z0zpnTOmdM6Z0zpnTOmdM6Z0zpnTOmdMs8JblLcpblLcpblLcpblLcpblLcp blLcpblLcpblLcpblLcpblLcpblLcpblD7Y5ThoOV/04zyKDqYc/bEr1mJc7RjOPWX5S/KJk 5/wl3PKRbvQnGRxK/uY2Xig/CxGENQ1PKD4WJCM4U0L+TUfAA625XbhwzKNRlRH+iXvkF34l /Y3RTZw/DGGmLu0JiG1fPWE1aABirBulMvDWWfyNwgrcY2ac1wu4mjClgg4PMgLWwakDhqzj Z4xmLjMjsqlE4Fx+hAXOKkVAClzXTSVsdDatKN8A68pdayXsLjGCs8mVOrAd9UwaHvKsvb43 ANWq0zpM9nbJbXKrX2lwtaHUY5Gru0cI6YexLNtUBp2rlCEHAgRqvX411/nUPTw914HZgwhS WIjeT/GYBRoDVg+c7XM+HnAAx7bbyr/j3/8A/wD/AP8A/wDQsmDMXbMQNb/UUGZztR0ta7rv a5YNIvrBGqQb1QMglcZyHrKPCMQqUGUfgDWCmn9ucOmEnSxY+keOspDZk4v9pXUCU1hlHZLU IXWZYvYLN6DsW73IVETRYN0zVSLTqRtcTGCq7lLvZVQDJrVtZrBA1umWLGtGl3ldbBm/O2kc 60Wuo10bu1eNL6n9fx1ubcDWzmFAwaaqO9JfMVQHsH9RpN46rj4fEFXXfGbznYy8fKWOFwpb i9uXLXSVhBYS6Yh7K/hUXULXpV7e8Qe7SNCVl0W1XzD+AHbNiGgksaqXXwBQ6G+tWw7Q12oc LfFSaKvVqKQmwEHl1uIttjtWx7sWgkTsniodTpWauUootyZJSW8Iz6t4KUVepxlFNxfaYDYD CaecrHt1FFsqVKlSpUqVDAKNAassoTNjF0/t6Sue7hebp5f8iAAAAAAABVyHCxN18EIBrKef IgLJ3Mz/AK80ULqItE5Rl0dWzrA2ArQrC8+sew27yyAjRBSGcuxvJ6vPf3EX1MiRw4er6RJw /bq460fWaIXZc8L5OJF6Fu9o++JMXxS27DM556RWjSjiwbFNmpMCVmk29UpowyyzOHuhlgWC mP6QmziC2UzatDWAGKh4AYd3Cr4yrPFWcRn9DHOIhvTQacjq6jzzKUftuAyehtiMB6lQNVmd 49Dii2hhRzhb7X+w4KhuAOtnxNzwqd7y8FY+K9CVeHDxZXODNH34ZFAY4mxELVL8/wCpNczD NkwKZTnLl44CjF3ME9R9ZVtAHMv2JBLIzhqwQHJVZrNW4MXnlDj1w6+RzTERVGrPqaeaGvAr TrwCBaHU+GNh6RM8IgK0ByzpA/8AnQro2DGCXVrTIcwdOWLfSLDbomOQX0Gb93RxEfUJSO8q MP6UecxHnZwMHqr6QAsU/I/9oC0OGq9qDg2QppbHqI0acGVbyKKKrVyji/CFipsHCe4/xM5d Op4Tk+nOY6zufL+n/J//AP8A/wD/AP8A/iLzzOzacqi2h4zKieMuhXUGgz3vyeEbEoWqW2uA blGm2K2SVx1lCEx7wbxISnJdjD0F0cV6QZjMPpba+Go684qm664VP35p8VAKqTqeRDMdK4C8 Yw7ChUFWsiHzPODpigBbKXwKzLS+R2yYjYq1bVrBNJlDDseXWtfeaqvUxYsBwXrX0tHmQi5X 6LAM9SWkIN0cnmaPSUpq5lZz5z4hR+lSiKK1Fq//ACCIACgFBLalJaqhgeq4XM7U3R8O55+F yoWDtjxVjF6pALsGsIsUBudb+YHiNUJR3j1mSK9r0mMholz3A9j41gGpES9Yznl77aRz4ro3 f7lQGMb5nM6+FDZhlHnLmpNY6DnKMMO9V8IPuTs5NfOpupa1118CLVdIMjgc4HPF25eND0Jg vbZB1j2Bra6jXpDgXV2cmU86JQBSm6iAB0krFY8BiexQU3lBsU3gr9KeZgFtnkAhjQOLiz5K 9EU0Qp4pXwwfaMVqdwrWuN1DIwlLrg5eU7zw+BT3EdTf/J2Z1BgcV0DrBd3Cmbp/b0gABQaA f8oAAAAAAAAMEUrPc7EzjtUqzHECmtThmcbGtzf3KNKz5l0QXz81XX6XwY/GiFUwdQDpZUy+ gPxoeNmjowZTCJQk6W7gpfuTYReWi+jRkpwLmbGjQzZaKEFNEeEHppRAS18laXJxiKrqY57o 8lmAc8NBBbOh1gjlzlf2u61zzlMFSpcuRm7gOWqUK8KU1ymPUnpzNmXbV2OELMRxxw27w1cM XK7sEGQqsBQZGyF94GpQh1jXVLcE4R3r90R73wgoMo4HADSDgKxUU6FwsYsq3UtzJT9SvbMn EwCs0gmxRZFLeOVrlOqdU7lyhldSo+ZJQ48SV26FEwRNf69ZlZvsXkW1OrLp3M5dTh5kBV9H EFGemkEddFCvma/8Uk7exy6sYeYmt+JSPgQPbYNZNXlGF3ErlAYYu3W2TQTpfoJbZHCbgZek JyrVRlBTlr5T0JsozFvQ9JlF+qrq6KpvymYTGX1eAxrhX7haVpeDxqEdBr2hRtvhBzXJAOnZ AAMM2QoK+52XwIsjrhHoRXtgaOjTeqgZqTWisM9GnyhhVpjZWGOS2+cZHcgEtjXUyrN4m+RF KzvvKVfHagGmCu7oVF4IoNXDnAX0prtCyC6MQWAgL1KlziA4oFfxy6+RFDyNnN9IdK60yuK1 XrKlSpUqVKlSpUqVKlSpUqVKlSpUqVKlSpUqVKlSpUqVKlSpUqVKlSpUqVKlSpUqVEoCWFen Nl6djpgo9ilrWmB66YVWLBgBqeDWyatSt1dZXbkmsHMDeXrgzMSpwXpSwFU0vLmasRuA2myV TAjjeLi8bAk1p0ZhyG8JmOVnmJ0U5mbHFrUuBEJuWroANaCqwcUU31HTBc60q9liKex5QWvk 0XxLqO7WLnhbbZRP/gQEPLt9A8dP4XsL558XExJHneRNQASAbgvf9c5XNiDZdhls85m5qGR1 Im/Wd6hyMwkBRnE3TkQy4hbjS0+iGKCwDM7nl/CXr9YRS7GRhv6wIQnYvBp+t4HZwgdrs/Up Srw1uD38yzItlwEF3bR1H6V8G05zkQPF3A8HOuZ/4JlcGW3Fu8tVXiHmi8+nPNOG8ZZQIXlR R1mKEa4nSLcGo6xZbx8beMHoZbj4LcEaNfx2vEaBxXYh1OZFLbk3eb7f9NVsLX+khdHJA/E3 5vtintFlubZE4uZQfgQ5Jzmakc4CGb6pfDSAACg0Cdzy/hLGL047RKLqPRGJnrsdh066OcLo 31CPk+Ijwm4G5Ru+lMqSXaY9hBVJUVTkmYQOWTwuCk8L8UNcU0zEr/Us6JxfSd3npCo+ptxW /wD1bueXjLemG6paFOnPvtjNqyGzW8x75pml8WkufO1/rwl/RS/UtL5TT/SWgGdgrRVvpNBt ENAcYjVNCYP8R8EapwWaof6CNnUBasX1SF7ftwgHxo6BwD/YO+g2tKVY06WeadTan/Cy+OnT p06dORn9248z9gbe86I6mds5xQr4SqsEI4a1bONH/GdOnTp06dOnToU051HK2vRl94nmV0fk Ve9Zi6fVV8ZsWZ5H+M6dOnTp06dOnV2DrgbQV143rWM2ZqGTrOOKw0cHJi/8R06dOnTp06dO pTuRXBGw7Jwfak5qqmHACkDRrrd400/xnTp06dOnTp07ZtaAccS2eW/Elk9R7gh8ZdqWi85h 7eKvf3N9d3aaYPVXzPos+8J9amseQGPUN8IYHuOEbpNaGxABRAsi28DxGHjsEVzRDaWlpaWl paWlpaWlpsAXNA4rsS6RGUeSP716af7TgHmTFrK8ZRguiVL4zyY6zWtqAVQBqOKFuZc8C5sD VShizO0WHmi7CwKb6uUwCyqd+SAuxdiV4zFOb4Q5GFXl4vsVTqD+3UeJQWhciBy5NRVv56bS NKO2pC91YBdtd1ujc1ME6XJrgrdgtFkkHsBzuJc1C38S8Xwd4vLx/O8Aaut5jAt3boGWlxLY O82mTPlScZaIrJsfY5TFY0VDqI4ORLy8vGIgLlI6l5bXGTKcYZodoloqOjVWrmY1lfN8Ki1T Ac2Gy8SYy5vQMedxMXUiVWgXKs6plTzlKOEXsHGoiDTFNQtQdlJeLUNTXuXl4jxutoq8KUzL XMiQNaXk1NZk1YKoGlcjVOkV4FHBhU3XlKk45o9EN6+iCpVWrPseUvLxbOvh9F/wPDqAmxJ0 Ylqa4XEZeyaGMJQwewEI5+FQmHxPE/hrNf7VHaejHhv0nBL6S/CVKlSpUqZxDi/c8pimaOev Ff60/wBu3TaWc/wKC5dRA0pHXRj91WQRBAFwvjBuc0xgJsmWQgmFavDHMFL/ALhuBR+B1a6D Uzv4OZL/AAHVonUlI4mtdCVgOjFbkEDR1DOqIOL+AtFYlCcN+M3VMk2HFwe8stp83SDY+ess oZwm4Nbcl3zgnadEZVlpgtzRKQ4TTEYpKQTh9rA7QTArCxMTvuyu8q/PDrlEaOo/IGK4o4Vw /CKuzVs3ErcpKQVeBckFSksPFYqoDN9UUMzyqnUG7zXlzhY2LcCw1dOmlxtcQCq12vF8CFwJ pVzqKszjVxi5YaFH1T1dYA/O3CucbmDGKlIVS4ZgjoSkpBjfER4wA+ZYlAhoQEbSnF49ppTk FF3412uGBKfVA2ze2lRGEcqmwZ7uNQUCtZoAZc9rlJSGV4/cdRm6KAtZuk4I9Av5TJkyYsbv 9Zky5MGTBmTIkyRIkULVevfr379dckKk67Qyuz4ZyWUAyeQGAOsI6tBnWnWnWnWnWnWnWnWn WnWnWnWnWnWnWnWnWnWnWnWnWnWnWnWnWnWnWh3yzXdX5TJ/Y/UP/QfqfeP1PvH6n3j9T7x+ p94/U+8fqfeP1H/0H6in7H6hQkotu1OHKDgr6pIvjz/j+vXr169evXr0qd5xL9xctOWvj3Xp Gu44aZPf9v5vXr169e8ZqEJn1jw+hXp7oK1x4iKFYKh9ljCB/wAuvXr169AmUXUFtfwvXr1M 6ybt5WrdjggBpnhXoEyi6gtr/DevXr169evVIa8tKVsrTwYdQpuO3S84i/8AUgAAAAAAAAAA AAAqGXarA8hd+UtWFbE5ozI2DjjeGsDWDAICXaZwXNd8Ixg31nq9IxIbilEKtVgunOOZQBpE 3bkCl0XuupikBQAUU16Aycz+CaWL2y6ATmqPkZ2lDLcqibkdMWXNExNAhQd4YEHq2lP+FR3Q QWcNXqb/AMAcxlLxTIOHXKucvkCN7dM6VcVvLEk1kSwVhks2pekY1w0Y/ezVL5xIIyKQrjqv kveWocQ4Lu70bN0ajNmT9JWrTfdB4O4t/g1H/VwCa0sgj7wHpZuOcZowTVGMNxuNexaY96QC SL1hM1V61MGWAGka2DUNb14O4t/gSDqjGG4roatHXfqeso1/VbVra0YPzaCBDzGOss3kFPXy ZM4XvLEucooOejU5JVz0F4v0dCcj80CoUCgP+pgAAAAAAAAAAAABVtdllCWyIMU756w0Rr3a to4QcHaVtvZst6OEe8ohu9xq5P6jQOw3HgDNKrQh0p4rCsRsLHFt6wg21Bp2MaAAP4KAVSPd WTsVy+8yjlGM2XR0apxhShFfY3bAHEcIxKORa1Wjpdjl/BRKPjQdyJ1I4VwbhkxUrMHW3mpY 2sqolsSBvPnJzWVLGjFxrzoaouC37RDEFg7NVzpLtWIOvJWqWeY534Ozd3gFgtYRh18hosQL CQOAnoSuaWP5lWjesLu8xqzyo6CumldXON19WhbvPhAyLrN5uOzd3gFHQVE9TmjAAbqrxwrl DZkLeG0NcAow52NijVIJ0voxd6usMKjwHV3KBope0UKRohAGxWG4hmNAqes/gF/j8afM/AL+ m4f/AIir8m4f2wD93Af+8D/2gf8AtA/NoH9sg/N0H/ug/d8H+N4/BrH4MY/hzH6OY/xrH+NY /wAPb+D8AvwPb+D8Av4Pd+D8AvwHd+D8Av8AR3Xg/AL/AEd14PwC/wBHdeD8Av8Ax2ng/AL/ AMdp4PwC/Mdp4PwC/Mdx4PwC/sdx4PwC/Md14PwC/cd14PwC/wDHbeD8Av3HbeD8Av3HbeH8 Av8Ax23h/AL+x23h/AL+h37h/AL8gvY0nwCuvNx+AH5UzLAx9ZHhw8nzf4Af55a46Yz019Pw C/8Acfg/AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/ AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/AL/3H4Pw C/8Acfg/AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/AL/3H4PwC/8Acfg/ AL/3H4IukUKRtk8BZsBTZH1IsIdD5wRXz/wmpdJWGn1ipqcvXTP/AE0joa68zJKIdqk+bf48 6HInAwHESAwZ8MtQDgBRtLqqbILzw3s1dWZiTSCyYhHOu+sDIajUFoGrLlTWbtVa6bHptDyl Ll2EW/QxnEdUPqJVDRTsb5iEQjTmEHy2lhKzOIeM0OvHUl8gQfNBbNbwvmmx9ZVChm08dzhg wAsgY3VoLzV8o8SgDvCoYCzRlUS0wxY4ROuU1eOkwlQFkbNLTTyTFPspViVThXrvpHI83t03 vgtYUQN0IcYgOR2WupGWURooYDMs476f5X//2gAMAwEAAgADAAAAELfFtO9cvc8888888888 9ggggggggTuMMMMMMMMMMMMMMMMMMMJAAAAAAAAAAABDDAPO5Z1JBDRDCihyyyTDDC8ssssu cwwAAAAAAAAAAAAAAAAAAAAAxhSDCABDAAAVuUMPPcY2awd+nD/f4Bt2+hzvPPPRHPPPPPPP PPPPPPPPPPPPPPPPObJj6EqJFEHMPrQML/5xn9/eGjksgN0WgE8jf/8Aa8wwwwwwwwwwwwww wwwwwwwwwwwxCVZcGCCRjTinf4DysbV5yJvXCt/83w+y104j7zzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzxy65wDwJ32dtt4m5I3P7//AP8A/wDX/wA8888888888sQMICcsYw8x80cw w0wwg4+8zwAQz/27wwJdKCLuNT1eqdwtBMFFd/8APPPPPPPPPPPKMAowhNEM8gY9LNIcI+JO EkeUIMOUMsJAHVDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDC1uEXHy7LM96X7HwRr Kx+IQM/PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPLAOv PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPLAPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPAK/PPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPAA/PPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPAHfPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPAKPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPAJvPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPAH/PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPAKfPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPAIPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPA GvPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPAMPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPACvPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPADPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPAFPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPANvPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPPPPPPPPACfPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPADvPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPAN/PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PPPPPPPPADvPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP PAH/ADzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzwDzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzwDzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzwDzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzwDzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwDzxzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzyBzz/wGMOALyGDzzzzzwD/xAAsEQABAgMHBAICAwEAAAAAAAAB ABEhMUFRYZGhwdHwEGBxsSCB4fEwQFCQ/9oACAEDAQE/EGBQBsGy5wNlb5BsgUP6jZcoGyYL wfA5NOwBgDBjMPiKihXKBsuEDZcIGy4QNlwgbLhA2XCBsuEDZcIGy4QNlwgbLhA2XCBsuUDZ coGy5QNlygbLlA2XKBsuUDZFYg+Bsog2vAfBlO/6Aehr/iZhEOo4U+AgDkF7QxkiDROCDEBA xLx/d80wcPvoIhAMcg/jNSQG+7HssbgLMliR7o9OGjoIQIYPkWQMV3/XtwigJEgm2T7IFDgi T1lgn5KL4FkQ+UWIoYyA3Q9gP6xghyWUGECGLRHq7+EGAEArBKMo1b11HG6HFBoalHYVb2hC jEoUBheo9j2BSAoHSmdinaEQYeRHROyApEo6NBOLBrygqQNEYYphe18B9p3QIKhdB8Qt/Tbw QfEB0XLKCuMRGBHlBhCGQE2+0W5Pg2pyo4ubBqUKZYXf2DJN6PY8ZoucQLyGRFi9nM0HKGEc KqAcpWPY9nyMFFNMOB8o5CmepD7kbakdM0HhE50BMvHH8IOCFxHWOUDGfCAURLzoiFJBBmLA D7MUSgkj8iG3QwkHBcWgxvQdgXoB5SvRBEhM3BcvGUkDYGGPin2inCDmYoFAOmwO/wCEM0EY gEwjPyjcgiEC0gXCBBCHCEUIM6t2uFNbb+2AFwGCukx3aKEoGCogb5RZZ04EUvatmU5Y9cwh ESUYcFg9JzBQRN4iiAaTboiOrtNAkKeCB1oQyAAKBeSdavJOtXknWoNLuhMTlMGmD/IAjCBR 0SAZMpTrmE8t7kGBABgOkAkkRdRJ3tsiuXFEIqaMEFNA004KcJwnCcJwitFRTPvJqf5pAmwE 4RRhA8g/qKlH4CJbnI9Gb4iJbnIKclR/gIgEcluMVzVMXZUfq8WTF25Z7Co6Yjq5EqnJ4sgG RoArV7VSoADElfFfkbYiSpXxX5NyJAdSFQ0LSrwmQsFKlDA2A/noRaCMQyEPeob6YjUnyveO Jdn8GGTcwTl3r+90/MPTBPPnJfBgXeuj7oxDHk9yf4CDNTRtgnck2vmGQLF+W8wQgBY6kAzT nJNd31K9AyDOiESet9RQMGA/yRzzTNVhyGuTACj/AHhvkosOcZs7ukCCDyKLOSLT+rtgKug7 x6EtabRGJgbigxCx8t1BE8hqf0g8CbOgZw8q6av6MkIZ+i3FLCg9bBjXpAsOU/KbC8MHjlmg 5AezmWdWQdo9Mk07ByTTsHINOwco07BPAadg5Rp2DlmnYOSadglhNOwSwGnYOQadg5Zp2Dlm nYOWadg5Zp2DlmnYOQadglgNOwcj07ByXTsE5ZmudB9+n7BJiRJz/wBj5f58pFErz7CZh+/Q Vq8+/wAqp45lxyqDx6B2CIc0JfTETHN5x/JGbeNAqBcDh+ARm5f8/wD/xAAsEQEAAQIDBwQC AwEBAAAAAAABEQAhMUFRYXGRocHR8BBggbEg4TBQ8UCQ/9oACAECAQE/EJzamr3qWxzvevEv ekv3e9ede9SESu9/eV6Ym8SIGzE3cHEcEuV5171517151715171517151715171517151715 1715171517151714171417141714171417141714170HZG971a52xY4zWE/yX7en9JyVKLNN QY6Tel4Fd9IxUoTXnEsQxzy1LlAwMbPQySX+xv5ViQ8tY138N1DEk8tYzaGgZlg40qGMeV/q KEsC2NsY360kwzjHzTXhb8F1MKioqKioq2EUzzD2p+U/8wSxXxBm6aa+GA2ZicnR2fwlGJIF xiJjiUKhNeWpt0w1yhUBS5ZbGY0LmLAwTPqOB6As69Cgk5T9UgaAqJEiTYGcZrrvyiAWFIlZ 45Kj7s5dz/tRgXOwsVfIHC0s7NtAROq177Kl/wA5xd+ColJCbkU49p+f8vSeFyQTlNEy7WbX HdUtlldwn4p9Rj+EyoKtHBq4/BU2Zdv/AEYFEpLLwxYM8KheKybELfLCnMiDKAtZhi1QrybK cn6oCBtzruNjHP6/KWXJLBJjT/IXWpkgmbofN+/GKlTgQSq22t31R8FReJryqyXrS9BkgQHC w3bmgb6g6HFll3X8+zEWQhdnXNoYpKsXaVfgqNsUTcH9KRRQCErru4VAUzsmC7jF6JvtYQkA WxxpWJlk35/FF+ywYObXwbiiP3TUoSIGbYbpoEBN7kzKRSJVCvsqISVarVL9MKv7f9YigO1q GGViMctN2ys5tjFBwj8tZ92pZ4/ll/y0xMoY31pBImYM1g30wfhzpe7kuvDM2i6Fy8a0Mk+n JUFwq2bV900aAlzM08+coOoCitpp1rKaMPSBwpIxKjASMymCEzamrVPpNTStTNoCpXqj5p/U Y4MgAu9xaWESIYXjSfXkqGgirogXi1sdIYirArGGye9IgEFLKmhisaS0srDGpKkqSpKkrNTI eYVJbcZH82YaofKwc6/XPDjJUOHnln8GxPmfavOv1evPvs8H8WwOv67lNiWsGPwRFzH77PBr Ek8vH3UkT81mnrFl80qYJfLT9XqGYqRt6rgVCWp20riaUy1sVBOCtipTJRmCtkoDLWz1s9TY mlstOWa2PjWzVPmVnkfunDyv88XHRHgzSWJlDw/Rw30SGwHAQ5Lx/AUjfP33qBNH6D6IrFl8 zcZcabx5iz1/CRCZfrsVhbzLspu+NX7fwlldWeM91WAMo5MnOoPgjlFN0s/UWCkI0eHCOFTx F6HGgsNnIj69dlRSZbv9S5aSTum5vTCrxfHxygbXdfQ+N89DjOyrX80+5eG30uByJ+bMc4oL Avmu20fM5RTCEeg3Fudl+C4ZtQIxi29nkddl4rFv7eht+aYuGEvoUOKLbMZ42jSG5NYmwfDJ P27iKSV1PDL0JJbo5z0/VJnceODxlVh4fTPOI2ZDf1HGeweeewecewTxHX2CeI6+weedfYPP OvsEcZ19gjjOvsHmHX2DzDr7B5x19g886+wTxnX2Dzzr7B5519gjiOvsHmXX2COK6+wRxfX2 CYTBg6vx9x7BDZYQf+x+NY/hj/VWqgMdh1pTJ1Puug69qblv85/WhWbe807u7LKkmehfM+1C QGRHB7C+NZnWThLTjdqcWX20YTzTp+f/xAAsEAEBAAICAgEDAwQDAQEBAAABEQAhMWFBUfBx kaEQgdEgMHCxQGCAwbDx/9oACAEBAAE/EJ3380YSW+eNYfomzRv2XE8r+owgQIECNahF+zN5 4NYs/VCBA/ixI+b/AJCECBAgQIECBAgQIECBAgQIECBAgQP/AMPXr169evXr169evXr169ev WhNP2agD+1wnXcaX61vsOI0+gk/0Z8n8efJ/Hnyfx58n8efJ/Hnyfx58n8efJ/Hnyfx58n8e fJ/Hnyfx58n8efJ/Hnyfx58n8efJ/Hnyfx58n8efJ/Hnyfx58n8efJ/Hnyfx58n8efJ/Hnyf x58n8efJ/Hnyfx58n8efJ/Hnyfx58n8efJ/Hnyfx58n8efJ/Hj4z5Os6/k6zr+TrOv5Os6/k 6zr+TrOv5Os6/k6zr+TrOv5Os6/k6zr+TrOv5Os6/k6zr+TrOv5Os6/k6zr+TrOv5Os6/k6z r+TrOv5Os6/k6zr+TrOv5Os6/k6zr+TrOv5Os6/k6zh7z7o9YaXHAfoFw93EMD6jNwl9YYon p3lSIr05PxwCzbAkpQ8Wl/bLYcJBG28Rmzox5RPiMb0c1Dac6FQDgjU+SzAHi4l8TJ+OT8cn 45Pxyfjk/HJ+OT8cn45Pxyfjk/HJ+OT8cn45Pxyfjk/HJ+OT8cn45PxyfjgF1k+jJ9GT6Mn0 ZPoyfRk+jJ9GT6Mn0ZPoyfRk+jJ9GT6MB8ogvuA+lucYsdAfRg/u+uCKTj2+yiv2HWEoA+BM v1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1l+sv1 l+sv1l+sv1l+sv1l+sv1l+sv1l+sIbN/XOn850/nOn850/nOn850/nOn850/nOn850/nOn85 0/nOn850/nOn850/nOn850/nOn850/nOn850/nOn847gLDAOVfBiwVc3F9VP3z4HPgc+JwtB L/D+huYR/bAcHBGAfrh6OHDoX1ZALQKAfGQxVy097HkeJz1m7d1pxqW2BoedxchYUgp3pyOn SBCXkKG+POrwZJkuQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9GQ9 GQ9GQ9GQ9GQ9GDnWTrJ1k6ydZOsnWTrJ1k6ydZOsnWEEIgBVcJL36Ce+d1YfeQ34oEPRw6/c wDuAgBwAcGXi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi8Xi 8XjkEfX/AI8kkkkkkkkkkiRVjFuhxkXkHSIVxorhlb80JwLKjCkSoHnRxk4fZRo0MNI2mdn3 OQ9v3zW0v8P6G5GDgXZsx5htfoYyUd4gd8jgq9DhCW5En11OOM9DVBySrZY8m5lCmDcgSUF5 IwpIKRdrDC5AShgCyAu4qA95MmgllVWBIQPMClqovqJ/2/U1g+TK2Qjq0PYmEMMidTiVtXYx XODc5w595EqINMZMVcIhQGCdLI4ARTIpkosYm8zqkxm8X5WwNsLgDYE4RRlVvQJxylatOyxU biigUYYuCFFEykXNVTkjomFJPZj93NohhTeB+KtIVNBEEdT2xypM/VgZTI205c4vKmv5S6NH xAc4BQ2+hhaIWOfAleqA1kLAJujtNrdXCsGACqvFgFQr+oZsdiAbst7FVl1hIwIAMjE0lOTT /bA+4Oo8AeXH0N2jptfuicxwW/bij7FJ+3ijwZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9 ZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9ZfWX1l9ZX lpD2GJWZPCTePoxMwByqZc6gPYdcTxGjrzmok6SNOTan1yUQvipvLjB5CQwe+Ppmoc9CZDMe KY/ksrEdtKp9Kxr8LRHb1Q4TSmHXrfQGut/Ykinq7ziqehL9s3CD2mHm4BU2sD91D98lV4Je DhLKMSHYvSutIQK7BoPrE+Q+uvvjWzIg0Lz6wiWhoikQaCpaRpq4FRc22hG/FuDfasbatAS1 Gx3Mcw4iMoktXYJzxFwRMLniUS2QyV1I4Q2bzo/ObEjfHDnj/ocUbbTYaPz/AK6wksPLaJ4O gdTyMx0wOALrkf6eMcAkG7gdPpgg4OhzTt9MEg0REDyHywUGlZBKRTURNleA1i0spQfrFL24 8AJduCf0AIHO7i6RhnOxioNHRwuJTIDOre3J5yZ4nj9I00EKUTIuUEDKGWY+ZoYAVHgtfplZ AAKSNjQ8j9TxWZJmmtccJB/OUM2MA3aZCefBlU3d8IAU5DzwPrA5JFFER+ifqdZk6J0+lvJ9 TCfPxbf3ABvhNewsmMiRERplWrzzhB/TBdsVbxiHhqdNTCBFQDQeg4P7IAJ8wdR4A8uGToFf Sevq3PbHy7JHkV8xu9DjUDI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHr I9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrC8 Kj8ZehspmCJYS/W5PjiWkFRa+rxhaRtBmrYseZSCbDGx1r0ioJMkT2OfDcT7logDZY+kx/Xq EgVXngzXPfNpoXWtaynOKkDwKebfsPLoYrHtG0oFeX0g5Ir1QamkB5RfRlOfC44Um0AhPK4z RK4+T3/T4qOzFy49DsQgEOlAQ5xu5BR5+ygSfUgRLlKIcokAADeSADHRBkiAJGl48ktGHKgc CBbzLm3F2hGJvZSogJUoyJ/5MZihCEVFkrAFQeLIQkiR0QiRDtjVEExhvkEANDSrUTHqoCVD wAYMcCGdE10tGhxui5BYCYGxxzjepcSBVQYonpHIejI9YQ1/Qroa5/XrEwhiF++v5/WEA9lZ EZzKv040KttdB9X8V8YiRTOvUnTJ3PTjnj9+crH9vJiKAR8OIVEfdnH6WpNUkKF54sx5MV4T fZq+jhdpEi8S+kblbaMFmrCgVfsyqPX9AECL4HepzjnzfEibKxFCdd4cZi+5ziPkWJG+MS1G 2WXCNNu0UNwRqlkpROOjwA5eMQZuHXOINNUvO84DsSfpAgWRXgCps8ngALbOvhLh+IrBzMXX 5Ezl4hlTQpwKu4x/xzxt9H0adMIqoEAAEh4Cf2yMzuPaj0EVKjo8RUwnQYEg8kLK3QIVetNq 28vXn7X3f3Bi6EHj9/1Zef8AYrxBXP2WrsnsMKkMBHfPqOgM5XI9ZHrI9ZHrI9ZHrI9ZHrI9 ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZH rI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrI9ZHrAYbQ/GeE8rECsUjn3ibVkPPKMiNpxggeP0rkUCC/5 ce5sRW0v2KvoFwSzYKmkhyB502znJaK8wRH13iuq3lyM5NQfcaslhtSWWYLSrux4A7cNCJsr 9x9ZhVWu0Bi8mHVWZocXQIYPQaZe7FVkrcahKFYr7aSotEpw2ncsqm4cvKWSEgkCKwPxpGFH JZVI1TgR4RI55fzj0LkhFEOKRfJ+d1VRomqE82CI+zcZ2aSE8gLEEKxW3G0i3YgfQK3XnnNJ 7xEicuS+ohBtyABoA8GHQ+ixa+ulfqGagRf00393i14pnW/fPmc0tL+hXGYD1h4ChWSoPew/ fHLJRaGwbby5sHJ+do+laDGwFS8N+1JEgZXshPjhporSUABwxAj5Y0BCKe0JmCnhzb4DjWnk EF0u2IQqsNhjXwEV0LTilBoE55RXmX63HJIYdDQ5MA/XONh5nvEGbQTAnFqUBCruqPO8M3XI RROij+E2xlsnRBPT9/XEuk2WzJe7QvpfEzXR5liVCkfaerjNER1LZ9rBBVgm414RAKVUtKJ3 CcANo00A7VQN7CZJlsolh79GQ3s24/SSfGzmoYOGR++GEp28Ctv0H7uECMFHLr8Jk+jOO0JS DftXl4JFDncCoi89AiQuyw2hdLVIQhtrWtPbxgnp/o/6yGf1Nj5eS3L/AHSDHyDLD9Q59ifs uCmNIAHoMvv7Zff2y+/tl9/bL7+2X39svv7Zff2y+/tl9/bL7+2X39svv7Zff2y+/tl9/bL7 +2X39svv7Zff2y+/tl9/bL7+2X39svv7Zff2y+/tl9/bL7+2X39svv7Zff2y+/tl9/bL7+2X 39svv7Zff2y+/tl9/bL7+2X39svv7Zff2y+/tl9/bL7+2X39svv7Zff2y+/tgmjFsEHZzXoc jOFA0Awan43gmH0TJBBTQm0XVwPGii3RomUNjFoDQe4dME2fCANmqgkQsd2YQyApaGimFW25 TWhZDyLqx25gUfRVUpAiRC4tE9GFLsUEIGooGAWkGiuaBFtsGiw8J25ajsHlXZN6ydILK0PJ o2VEpvKsvITQmwXYiTeGwkWNDCQDluPInDCNZdT8UrVaZt1tywAAbGAjFgDSlLEZGQqLYCZB UJZAUUuBYUkhbo0Zxu4vyCArBHet9YEo0siRQ6RNR1MQJLnE+kx1p1grrEQcAAD0AYUhq6Iq lKJw8innNn6Crdgq4R8l8owVPgAffPAiigA9C1fALigkRDMsRfMcfRflM+Uzz9vrm2Lz3l+8 nwt6VJD3AmUAqhkkDdCKOdoCuMKOAvvYCrZ7eNuEJu+OHADnNA0+zOFSh6sGgF8nbSYzIi4s EJReafseWCrhr8TYwfcu0C4NnBCrlr9r++GvAdHGGbo+v0wcVMYJIEBBR4Fq4kKeOJFYEODu PeFlIHHNK13dcHuMicsMDQgDxK+ZlZsTsJkgUGoO05BVhUIxorLcH+QABmtBgUq0JPuKNxZT b2qtjgRQdS1xaMtgBs0DfIsvPjB8rDj1EOC3iby5/wCzWpUGIzmJ7wsbtNqHBU0ru08YNWdy eTSBfB45xkptjIgEMmveDLSj3WU6Cs4LmIcu4o0w2JZabEBsARU8nvFNekotVpFEU0jAcsZW 2ExW2iC0dLBhqBxiG5WBJahN4WYC+CNKXZrsy/ymsJMGbQaV40pEwk4Ay/vm9u/08dc+vSjZ 6PohuSu6ji0p/dJcvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8 vLy8vLy8vLy8vLwAcZWwoWOdSmlNMjhpjLYyGiconiRFzkA+iAyLZekRe3WlYNksVe9IrRix OeWk6LY5zcKwVTXCPzMYQS9D/sJGApfhN0luW9khEk0pGIFBg8V9SsCciAg7C4EiKKjhkGoF YkW48LiGrgo1kIYVqlWeiuXJdldxmIoHaBo3cGuNHjIejIejJl44Uj98+pTV/tkPRkPRkBU0 b0YEoRB1e1ifuubERe+NHkjSlQHHKxppwJo/OFw9e2jwtVDRB4S7yRDjNIgMWtKrCyTAEpLk UmJUEOG/WC9QN/ZtUqfoBi72MIRRH9x/p9u7X2yKciusimn7k85qTEUzFCuSJrkNlEibINK8 AsitOPIVwjJCuoPEJvZpo7nkgco/AN2Vdz6ePKv5bUJtkDiCEocoosQ5GpUPnX6uLxA+nGDh fGM59TKusF+jmmaPTjorZ7YkDQzmVvu4Ft/fK0XS4jfjbfWSh0BkHapRSq+xRlXQp4oeTBPr j0oQPmEP2xFVV7xFRT6Zzi+rgRBB6uCjpmKvO8WIpPVwqKHTgDRX3crbd+8RVVe85E+hxVat clyPpyPpzYKmXIi7RXaoYekz6zTND4roh5f9MoSNoR9rFfrccmK37ERl6nYio+iXsrH1WAH5 Tkv7BwaAwC63IpT0jUvtxCaX0sFiAeAAPWPgI978PWA2MAIB6P6fbv8AzZRIfNYYdgAhdX4/ uYEokN9UvA0K7XcZDBNoWwinzAnpvMw2uAQYzGnlNyV3zBG28CyXcae1j9HIHhpA8tNo8nip s2M9HtCAcvkb45mGIuVRD9y4N2YYVbSG8GOAf0GfTBoL3m4cennEURHv9BTjWKvLf+CZU/tY du+l4N1XTrnZTQndX4OADX/WfbqM+CkIXj3u9+Ec1GXUohvmCvheY6cI4ckKHqAhtiD54ziA QI8Ci0bhxu88nng8j4r/APzmzmkS3J+2IApzy+vHT/75zahA4HhdInhxhjyPKB7GA+h1gQkq GpJhUVA0NnieXz+2T3lbyIP3/QY4NP0hpqeMH3hEAneC7l05yhPf/ALpBwgwAOVfGVD10TyC jg6b9jeAItEmEAaAPB/yAEPHRfhIAgBUGi4CFZ9bIHB/YuRIkSJEiQ22ymP4FnkOEIXSbais ViowzzqoLqskVNERX+127du3bt27duxo2vlVCC+2XpwScyhckQZtMAeBVgZaKqkkhDcr/a7d u3bt27du3YxGlweR6PQBIKFgKUkQ5YG7UoKXxBz+1bt27du3bt27BXLDwqvICsbmOna2AMK4 9cxKbWJpBSO/23bt27du3bt27T4YraxVpOaAibKHyIIgEF3sR/VvQ4Gjgek85MWeNi96XzXy cv2Gq7mNb58seinoH46ez74Pwnx94OUcyRGjPlzhLxhUQJLZ9T75XBsH1fUZ7H6ZaR14OJaP fvw+cJqaNcOgDaS/TJIgYHZlytJ+nL1+oTX5xU/XlIfZrFO3kxPGcqvrnRnRnRnRnRnRnRnR nRnRnRm7JJMFy7Qe19eUyQUd2ybQa9Xt0X/lLnBEwcY6n3wqZeLEygGlPL0wAIALDgcAUU6B 1kAaAkQSHJh4FKCZlJI7zgO1QkWG439GnBo6RU4OrvOp98HywG4rcJyDTidedePYJe2z0m9P 1J4w8rbwQmlREFTxl24aIgLgIl8iAKHuNnZJHUPl3NWlechKCJL5bAIiiJkTIQJaBarWGm65 xyjgRFBEUiIiIoiJnXlfWBZ86MRtZ1514vIemm5BpeKfXB+Og3gKamURNayzVECCM+6I7E3i Zwj0KqM2EfovhldW449GB5LBHOvOvOvFRNYTz+MKNrOvFojwCTkRyDDPFxGT3Ekud4ml2c5M AlYmHIgkUGktxXLmA2JhAI7IR4tsgC2HilwDSPnF0cFs2oshEII71lJfKiiB0xoB8OdeV9Yh H3/vhK16/wBZ1515a5aAEuCMG9rvWAejGWQDARKQ3zpwiExq5UIugFkZEcg9dNNt1e4LoOmI 4wA0F4lLVajFB/SFbqGgC1tdAtM6868Pp8P9/qXEcZGRnPL9s8yThU/H7YRNFAMnPH3/ANej FVKtnsefrNdnOAgCAhFIPjXjro9GWC3djxbbPd3gCDW5Dux48YT9sdNYuN5BvODr9H4/Spwz EPmd/wBAV497Zgc1KeS2iq2VJzw7PWDVFj4Kw979/Xgy7urxt6OvNJ9TjFPB8cvX8n3xHlf1 ga8LE0OYe84L5KhvDwuMQydLmCCsNt/5dWku/wA4IY+v85ClOkVLlTwEu8v+SpwuAV21tRSJ /UH/ACvStDrnWTb14ltilAoE04RjgxEQTawEUATPqPvhJgVzf3yhtmcLHnD6c68ADIkz2AYe YpyGVFb9qJKBUoGkbcFHfUphzzOUFbZjYO7yQGg6JpuikQfrJmN+FWhAKIXLFe6YwYNVmk79 MMYxK0E2sRoQszrwT1lz0GXDWdedeE86cQagUF15TJKNylVosVODjHkuex5gRWxqGI84LpHY xzQo3Rh6XDkxRFu4Kbg0DZipBVudePqwEGYdPjHaNZ14YayXWZivGjPBg4Aez8bkA8hpxVBD IS1VLJZY6ec5aPpjJbEiAhxdXA6v498mCqHGiuJqa0oBOmiE2yHAAny7wqOsczyhM68A9YZn r/bKu+U/GdedecNLGIzTRGPtszzFUeCTAdCKpyoLGNqhBtTuuzjxsbIEILk5AiEPNMdbypY2 Wmo6TWJFnqyQpgyKkb051515wDhP0Li4f9GA7leB4AyJcNHfcX95/UWLFi3Zda8weWcTGNgM sFlgv0t+DzwH6unLgzeGBwMMCF+sfLkyyFmQv0jR/IBl8PPWVX+2M+Q/qH6b1of0+fGIfqnp yZvGgPa7qvKtV2ud34Z3fhnd+Gd34Z3fhnd+Gd34Z3fhnd+Gd34Z3fhnd+Gd34Z3fhnd+Gd3 4Z3fhnd+Gd34Z3fhnd+Gd34Z3fhnd+Gd34Z3fhnd+GC9YCKoiDrm+pz4BTrzg/sXTp06dOnT oy7WfVQHSmTEEj8+tYHQksHAIIFBS3bzh/aQ4cOHDhw4cOGGyK54H4b/API/2uN4PP0jhILU d5UO1G+vOzuf1YcOHDhwkPhD2+7GhD0MF1iuBfG2WCwQMKVCzZzjw3jZGgTTzWjr2NP6g4cO HDhQbK21IIFgyp9f6MOHCHMiACH21bfFLw8eVZcBno/ThQbK21IIFgyp9f7OHDhw4cOHCZbo C4XZTq7QDOtYbl5TDnD+UHepYvlzfSYhXb/1IAAAAAAAAAAAAAIJzaLRG9xBt0EW5bXbzruy ZOwdwwY0CHxQoOW42MWblFyqBTaIBooluWXyUDIWRNSbyUdd+GmkHg9noK3tdznSJDHiNS3X 6po3jLtvuaCaGFCUJgzQgpJA4bCOCaLwE8gtd9IioabT04PGFkl5TQeriH6Wm/wSRggDQ5vC iaYTHc/DkCRynvxDN5SSsgUxAEt0Q7XngmEJABIcgsc2+/uKtoN7ACmDJiQTFIPSVhYoXiqi Crw6cCAvkBrgk4mQ/R8Hr5mNCz9jA53Vqz631h8GjDr7PQ7MI0BVsFeCqajgq7g8RCi5Y8me FRmuWLHJuoYh+j4mBAjxQueQoEfdQPAXBugWTblXcoOUSJEHWHnlZhSQl9iqSJFnjU4LVRsC ZqIjAuElG6AVow0Rp1SQyX3kPib/AEUC5OYwBonJORhKAgAQD/qf/wD/AP8A/wD/AP8A/wD/ AP8A/lq+VMSeHDxTYlMQbOZW0ADjTsFABe293lMFBGNREOQ9ZJYCB/YHEAYSu5HFMKaAh8JG 0LvGWtzghB8oiFpMMwRE2gIG15/Tqv0Dd6nYYWpdRuRoaQ37qNHjpGYhzVV1toV1FaItSsNV vCpn1PkR3qnb6EzD9EYODxaQiP7ObnQiDnBMGBXZpGNqLwP/AIw2JBvOH16BVdqp3BVQh4wy 75pdqVNCiVZW4ZDkv+BQwakPMIypjog3szDWxZCH6YP+gy8lQKI8jg0bKwJRSwFNa4HvFYeL UEMAqQMxx27CoOm7Ba0q+max1FUrIQq1x2K/Rg/6DqoIacxJiwnJpkdvU7s8xrFHkMrtQ0jl EAXDSM8N6wURTRJiRLHwyEtyqgGLzbwu1MxooeCViQgLswrWHbkG6/7/AEUC5OH/AL9sKfhs /RQLmp/78MaH1P8Af6KDc1D/AN+CS/ooNxwf4A6UG54f8ANKDc8B/gCpQLhhP8AVKBcMJ/gC pQLkhP8AAASgXJAf4AyUG4AT/AGSg3IAf4BCUYB/gGJRYP8AgC5QbnA/9BuKHDxQY2KPA/wC Yo4H/wAAyKOGRQLgRP8AAOqhEP8AwCqoRZVBuBn/AADKo1j/AMAkqFYlQF1ZYeD/AMAyot+V AuNj/ALKj2P/AACSod6VAuJk/wAAwqKY/wAAIqBczH+AUVHM/wDgLFRDYqAY/wDAIaiGDUG5 GH/wEGoVz1AsDF2aHj6gB9V8P+AFAKKEAVXMgKHzHPtl+72/wAoCwdJyEfti77v/AOw6oRqE ahGoRqEahGoRqEahGoRqEahGoRqEahGoRqEahGoRqEahGoRqEahGoRqEahGoRseAMMwhsRKJ +iitGFCTSCPYieMIuNyTsF2l/ssEFJch9BEexuKaeqJ0aNcDOv8Aps6QSA8LAfxh9EAofta+ 0/pKEUNgJ2SIdsHCGyPbhCAt2xoQm1fgu8psdAkxNZzrq2FkF0U3y5yA6SkXxAMsd0HTREYg mK3K5g4TnUMU00bDiCDrrawIcWKCa89JEgAaAVm/C0MXC1W6egoDiOHj5jiL0UIoGlq2ghb7 lCoZpUq0E9inVDKOrwVRrBYd48BLCtVKjWORjVuKNke4cgcilzIIIUqEQoq3ls22sJJX2IBi ttptfbxAwvYtTEdSbA3leMYBUjUF0WMyiIrMKaAQhjLhMrTeCluSLEQpN/3FH//ZCmVuZHN0 cmVhbQplbmRvYmoKCjUgMCBvYmoKPDwvVHlwZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JC b3hbIDM5NyA4IDM5NyA1ODcuMSBdCi9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0Rldmlj ZVJHQi9LIHRydWU+PgovTGVuZ3RoIDgKL0ZpbHRlci9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eJwDAAAAAAEKZW5kc3RyZWFtCmVuZG9iagoKNiAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAu NQo+PgplbmRvYmoKCjggMCBvYmoKPDwvTGVuZ3RoIDkgMCBSL0ZpbHRlci9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nJVXS2/jNhC+61fwvICdmSGpByAIsGS5aG9BDfSw6KntblFsWiQ99O93 HqREy2snRoCE4jw48/GbGQb26P6rXh24HezJNZ3f1y52kddvf1S/fHJ/V+jk5+1rBSJwL5Uo Nbr+5myttt+yE1mY9M/qy6fq2V24b265f01iMPO9z1a/vVRPP74Ed/zHPW+93Qz2Vf2ALMdz FWgfXRv2rTv/7p5OrBPc+UsPOJz/quZz9bzR9y3y+S2x/48ZEACHHrDj32pBzhNbfO5pHHbY QzPsfA8nQvnCGeNA0CMM1MMIMxIEFRyGHe/MvI0jS2UrDtj0UCcPk3prRUHFrPvr+afvhRTr fed801k8wSFI+ndy4HQDG4ScAAVNACc4aiD1EHpbQqcbMPgeg4Z1lGXUXc9L0N2UwChJBpiA hl0w1SRH3WhwHjSnXWSEECXToN/5JFOHKI7qW2Ly6cvkk55rMTKEHVveRyoAX/ljWPmYTRa0 KDIiWAICDWQEaViCnWTp04co0ywqdFrROXD8BJaaB/QeFYVA7YB1e3EVDJskKloJq4aJwTAU R+JpRceON9NjgbC5gdpyMCDndDOakb+PIWCumI9iSF2dTRYMPQ0hU00jkWoJOQIj0GyXPMRM nNlYVBKrpEiX6oZVLcc5Q2UUMZKuNNui572wyaeg4nJLcIKRt6cEXCF/Byuqaf9gbVJssknJ t7Uui7iUUz7Y3UKKm0ttW6MJJIMzpBbDcG5r9Z3iy1wpEHuvXGFpHIKhwq3hm+YEfsgRoS/5 eGKbu8BS4IHwGLDct2kLrMU3GgELpmiQ1xUtmSYY18jXbqAgs0/MfXtMpD6VIF+jSJ6LXQug LRtuCdUxAZYutwTuoEEiHJKre7hhG3lIPoQbtpBNFtz4LMluKc+Ubv39NtgNMdNslXF3shbG 4/KCLJKZFJsZ1HeanUVh19EI7WLCZUqgnd4pTwx1fi18GI2A2WQdnge7+eXcXA9aZEXr5Uzn NC9zvNruSO9xXkkULqZq4gIt46ApawybYgwrY7ota4vyt22rRG93pza+VOVa9PxiOaY2cgPC rhM8EDOAnaJHN9BDIn6GItTr44kgkYkjpl5/IeSUyB5AMNtbSsIjDVxDskZGAnE2su9O1DCV ILMMFWUVmdPJIFX3F98MtpgyzsmW3xIbW1Uj3ZXYfMylGZIdHC3e7HWnppZFLVloovdbW+Mf faLU7dULhQ1iV5KCqVeyoBijsE7aXGj2d16mg1Esi1NzyjO7zdWfOre4o82kSRqJ1gtB1SkW /Db59cOlLh+c4/Iu3o7CdKK/Gs3Prvif4Wn+4Wdm7dd/3dP5DcH+5fgfjxrOhAplbmRzdHJl YW0KZW5kb2JqCgo5IDAgb2JqCjEwMDcKZW5kb2JqCgoxMCAwIG9iago8PC9UeXBlL1hPYmpl Y3QKL1N1YnR5cGUvRm9ybQovQkJveFsgMzk3IDggMzk3IDU4Ny4xIF0KL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGggOAovRmlsdGVyL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp4nAMAAAAAAQplbmRzdHJlYW0KZW5kb2JqCgoxMSAwIG9i ago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjEzIDAgb2JqCjw8L0xlbmd0aCAx NCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniclVdLj9s2EL7rV/AcwN7hDEVJ gCBgLdtFe1vUQA9BT22TIMi22O2hf7/zokR7104MA7Ikcl7ffDMcwTaG/5qXAGEDWwzdQNsc 2qHl+9e/mt8+hL+bGOT3+rkBWQjPjWzq9P5bsHuV/VaUyI2tfmk+fWiewpn67pr6F18GE99S kfrjuXn4+TmF/T/h6VLbVWdfVA/I7e7UJNy2oU/bPpz+DA9H3pPC6dMIcTp9bQ6n5uliP/WR 7ffI+n9MIMM2BeoH9l8FUogg1m6I9O12YJFURDCg2Pg4xjht0gidXDFCP23iCAd5ioeJb9O0 oRH2E1+y7fI9g151OZJtOMJOBVt54F3tCPPEF3It7YQjPLJWBHmmLM+2JPsirCrdSI5pWmzt 7ZX/H2CGZPcxq322Kws0sQudKkFfZ8O9yP9++uU6nm28E82UL7F8XNGDFCnWocyGkQEG4u5u Dd+AHd4AK9GL98lSwIGqMpV3sB3cJUYRPk5U0Mxg4HhOUeA0a3Oty1aJb0mh4+tNsCIyZe+D C7oisgBG6gGlBRhkD/JYsilhHyvvjU0FQfF9N2V/QcRoKhEt4bQgI4zrPPK8JOMt7QinlBxB fGRtRaUx+XBeD4Zt54uaM5Q4jLCdwcm/bs23BsR+3AIWOypt4EeBxdxvL5mI7Brbi4NX8b7i 1DzRSoEOZyNggc7RHDQKOGJcYPTWUJArxeXPB0eeFV0LMAIFpK70xRQGDQ6vBBex5biQqIoO NDpuJJuei8EjS0oP8wQlNDx/UW85SpMgaRJaXkwA2cBJ2SizUN51IiXJ0yTaE1ghRr6iqz0u lrKJ4uym7EFUSs6jSWOcKL3nb3/hr2VCqB/BoFVg8TqwxhyA7Z0dLPJpFi+Z0zKupQysk1tl qhf0KB1i934Xs/aHGqxiR6AdZTkktHyrgqlbHexWBko6/NBh9Rtl4k42t++0gGQsWHqEG/MW WXWRG6yMOfGxfgcruRFfcFKONHUPlSfanTNXXzyw4wsJlWHMqM7TrvTDmque7YNqq6hh8nun b78wLx5MKS0HOI5mcTAyoQKkhpTK7o7zdr4JCw5MrHtgwZpQ4Iei5BDP2D4bZ/TRGG/sgrKy kQJaikfo59VDcdXFJSFcK7IL/gZIjzYDrGYqs1k3ryCUtjFcbCbWf2Yy2ZZu3Vcqt4jsp9iO bnuNRtlfwh/WPKjcUVuFxmKO5aXyb2RnSDxm3pGcAarzt26kTjkpZLNrwHPRvKEZ9kqzrAkC pRb/gb2oiHgW7BJxWklYbbU+WvdlW4W6RffLm7PeOU/em03kkV0hcVc7zzXsUs9AZFzR66T4 bzTLmOUDoR1Kj0Cuf+P2UX3Bqde4sjiHUrxlZE7SrXRilTPWVsncbf1OYffJYZBg2jLIzh5o qxgJhmRwViqq7ckOOFbY+47Z5zv3gc53Doad+/G902W4eyxJb6aSWIhOZbL3mcje+DxaZjhc xy39cHjn80NKs5wvZbI7O3R4agPHshwbZLCW4XldgNn8KAfIOsix6VQyyB8z2U+e73xVRBqY Ygn7lTaEdlZY50BrxJoNpq0Ma6wS/GDjacI7dbYtjF7UMxZlhlvyKMeJOapTmOXcCbKpSLAK kL+RuozZR6QliKdQfdY+HH76lbn++d/wcHqNrX0V/w8CT2AqCmVuZHN0cmVhbQplbmRvYmoK CjE0IDAgb2JqCjEyNDQKZW5kb2JqCgoxNSAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5 cGUvRm9ybQovQkJveFsgMzk3IDggMzk3IDU4Ny4xIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVu Y3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGggOAovRmlsdGVyL0ZsYXRlRGVjb2Rl Cj4+CnN0cmVhbQp4nAMAAAAAAQplbmRzdHJlYW0KZW5kb2JqCgoxNiAwIG9iago8PC9DQSAw LjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjE4IDAgb2JqCjw8L0xlbmd0aCAxOSAwIFIvRmls dGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniclVdLb+M2EL7rV/C8gB3OkCJFwBAQ2XLR3oIa 6GHRU9vdoti0SHro3++8SCn22okRQOFjnt+8aL8F91/34rzb+C26XMI2ub70tH79o/vlk/u7 A8d/r187zxfuuWOiLOtvTtfC+60K4YXe/tl9+dQ9uTfi8zXxL3btlX0bKtdvz93Dj8/RHf5x T+fSrhr7InI8L6dTF3HbuyFuB3f63T0ciSa605edh/H0Vzefuqcz+jAA6R+Q5H+MIbERzJWV ITrwrO0GS/FEHHKqLOiQdXzeAYybuAM/hh30I8adP9DSx3ET7FSWejozrd75/dgrge2PHuU2 KxXMIzDXhr7R7z36LNezr/LoBpLIJcVVDO6bNphGZA1MR5YNfPrr6afrgMRwJxxhOAfjKNrE qyRexLFqV0t88oPQBLURxVx1icj4PiuFL+OmZ9/V76M/qtzJYNiTCOXLzT0BywCAssM8xkv8 IfByYOmQxngDFvCZ3aQvVGSKwIJXYCGTtpEYcFsaMl6QQc+Gk9+R7ZHICzCaCchmo8CXyB/e F/1s6DQE4P9CQiBtBnGE2GfyAm3D3kf7klwQD3GhFGZCxTMqsFMr/MHugzKvFLGMxARpMTcp 3M0yJZzESAoBKJlycByQ0lEdEZ4jnyPoCVtuave6vBkEzLgN9wQB01Cj1oIAj4bVUc01zPJi ysH+r6IxWbrurZo4tRvMmryNFkX6ZCXH+M01J98BivJ7UbTBSnCmiAn3FhzRk6pldqmomhOT 5sV1aKXsMcTaOD9a+Iilsiyl/6jma3VNNRnByk37YRY/tLy5pcXVPkmvsKqXak1W0VTrRrPq jCpQZO+18Wp7mOm6dcDe2ucjH4VA4KBURSgiomk4rtprbU/pHdyARlm5DzegbznDDaWEQXp3 P9bpIL27dT4bFZpVrV2ayZwLhRspnE2WpRl+AODbrvapDuMPu9oDDfELV6HHGpWJM7d5m1be 1mHK8b2VODhfszqgpwSFBEuaQmDoOVEpWWTwXOOleijftd9sERQr9Ay32WXZzml1NnXbDK8D /u0MH1up9LfDAPnuMABeZlwZc29gaiykh/TfzRYt5NJGtrqiw3MpbIuZboLXCh3aC0WZpvYg WLt/PvCD9/Ei19eTX7I7WH5PhvHxnbdNLvS5C7kcK8dZqVoQmy2XTz05HewlpPWlNFyjdnTQ 7JaGRi6v4E8qG2GM+OZNI6iqHsVnKXl79XFJWaOs2cj52AI3y+ranKW8712EsjxxA4rfoSy+ QDal4j1wFzrwFmQA8HuDzFJTtFiXLPPB3gy0DocReVzRdJLXSKhuAr+UDjwNjWlQEX7VjJ/c 6ofDw/zDzwju67/u4fRKc15+d/wPq9HQegplbmRzdHJlYW0KZW5kb2JqCgoxOSAwIG9iagox MDI2CmVuZG9iagoKMjAgMCBvYmoKPDwvVHlwZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JC b3hbIDM5NyA4IDM5NyA1ODcuMSBdCi9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0Rldmlj ZVJHQi9LIHRydWU+PgovTGVuZ3RoIDgKL0ZpbHRlci9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eJwDAAAAAAEKZW5kc3RyZWFtCmVuZG9iagoKMjEgMCBvYmoKPDwvQ0EgMC41CiAgIC9jYSAw LjUKPj4KZW5kb2JqCgoyMyAwIG9iago8PC9MZW5ndGggMjQgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nJVXS4/jNgy++1fovEAyIiVbNmAYmNhO0d4GDdBD0VPb3aLYaTHT Q/9++ZKsJJt0ggCCbYkU+fHjI34P7t/mzXm383t0aQj7zrVDS8/vvzc/fXJ/NeD49/6l8bzh Xhs+lOT5q9Nnkf2alfCD7v7RfP7UvLgz9emW+jfb9iq+D1nq19fm6fvX6Ja/3cultpvGvoke z4+HUxNx37o+7nt3+s09HelMdKfPo4fp9GeznpqXi/OhB7q/R9L/MYGOjQhkyqAC0YHn2+6I DJ6cDbSaCDrkO34e/fMEox+mXSsrjOCnMEKadmH0UdajP0Dws2z4zi9yquVTwU7MU8ty9N3H 4FWbHj8iHcqnPKqw74sK2+o8XRhtQ+3AmXdIS/QjpumX0w+3oWgTrY9B0WIW2aAAsQWLh9iP ZnAENGuKyUFfDmJ3JJBQnhbz+hunaodVbccfrjzXI3CYUIyIdm0X1lsogE/sEzKPDIZBMMAb GFBQ9tEFSJSRGQQvIITBHBXzmBWLesjWHKddV+9BZM+ACYB2kCwm+QD8gfzAEcmFMRxZ5qj6 aHOHtUa/sOP2ifGgdZUYoOnoJ0jetnCm0/k6uTkkXVTFXYyw78jxBzDCviaKYYRTHLK/oZhB riu3kXNmLghQisUxSnqEroBpflb4oTyqW+v2uedFoWM/t4+ccSEfjWUrSABjidtONlI+LrBH jQRbzLHUO+ayqGcGPqC9d+pesSb7fx/wFnJd+yDgMeUIFcA5MyEDJBYoX5bi3gV8sXwwr4eC jAKwCn0lYBoH01piJgCHSr/SXhEhSkPxP8eedSs6dewvRIPPkZGP9GKeBM8WVXljGSCiF/pq V7Mttq0uLnTsXsGkovxo70DfX/UOeJZCzSaipEHwdVeQwpbL2Hmho3Ka61xuLPJCvUIK6LqJ ikopgwQsb5Z+0mnLUV2LHgPKy9UKaLAqy/1LDOiFttysvNlIPICt72nXgWzpUJXk/2E5pP4R jkMKeTooHMeFbg6xMKWEMhnldmEj5JYJmX9CcyV0sAp8r6JabZfCWShqJFaOxzN+Ha/rUip5 lNlnttQZahnFVcSGAjAlFMb7JCULtnb2MZJCaLPI1tW5/xBXYmngNtwYY3YbEZkYWJGU0DYq zPQ01x1etTHzbO6hCcb4tWb6G4srqt+cpGx/yHkNXG1jHhOG+zj5qsJ+DKehyxIFJu1Patlc hhTy8cxMG2fWPBZZ0TOw+C2CYizLeukVRhZ/lsqnbWqbPvk22QeoJqJjNQKBXk91gdP8Pns6 fLTC0RB5NRwzdzAVD4UhFmVzjnihfKqqmBQuY85xKiXujGyd8ohIVVWxrXRaxdu4Rhd6y71W Zp1gaxUrq7iBKkA8myL9JdFSmfjvton46FgNw3X+5ana4mlZFKuom91nCBy++eeiAB3ayxxW 9SUsOQXrXmRMnM+bhWV4CW2VeQXnW8U/cCJF7LcRMWDxmus0mTBn06PF1VvBBK5EsL3krbRN LAMXc+39Eno9Jg3J9+zs2Y63MUGwDAZa/a/hxVV/WZ/W737Ezn35xz2d3rHVf7z/Aa5KVxcK ZW5kc3RyZWFtCmVuZG9iagoKMjQgMCBvYmoKMTE3MwplbmRvYmoKCjI1IDAgb2JqCjw8L1R5 cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WyAzOTcgOCAzOTcgNTg3LjEgXQovR3Jv dXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCA4Ci9G aWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicAwAAAAABCmVuZHN0cmVhbQplbmRvYmoK CjI2IDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoKMjggMCBvYmoKPDwv TGVuZ3RoIDI5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJylWEtv4zYQvutX 8LyAHXJIUyIgCLD1KNpbsAb2UPTUdrcoNi2SPezf77xIUc7aiVEYUGSS8/pm5hs6du/M9+bZ WLOzezBt8vtoDumA7y9/Np8+mH8aZ+jz8qWxtGGeGjrU8vtXI+8s+zUroRfZ/av5/KF5NBv1 7TX1z7ptRXzvs9TvT83Dz0/BTP+ax0ttV519Zj2WXk/nJsD+YLqw78z5D/Ow4Jlgzp9764bz 3818bh4vzvvOof0OUP/7BCI54dGVJALBOEvWbogki8F6fKoIGCAbv/YBhp3rnR18D852w+7Q 29nNw873NtGW9UPobeCFxbbDLuQNecpOx++jd/wtyDnnZdctA/TuyIbGWiAfsJEdcIcBut5O ld5xQH+AjbZWZf3IB04oPVbHXMu2SJGaPaFZ9XiRI5atHobfzr9cB/bQ4vM+YA+QRQqw3pP1 ma1LsJGAnNQDT8HXaEogghsMmhJXocC5kfDmjLOAh0qzKOYuY7ps4JTdVREneWtW0bXi21gU kjfq2GFwSdzDYzdBdB02wX0gOp9FVhBTQYKzq/BtkMSnd9l3LUSBfYuAwjSvQFTwo+RdCfhh FVfFqjUsBYfHtZW0MFs17W9iCG3KHPJeDKEttFMwBMvOgXh+WmOWxIrr2evc9Rp3kL81ji7j mJsPW1pAX34AUy4bX4K3x8G1ihXWmF3Auas4ONtSVMGvVJcYBbiCAuZiHwz4hGIZBiswRLY7 sUPkGHbnwp3gFQboAV87rvJIERCjEXPx26JhMfHhoteWAUbHZc1RypQCBznJZwgVoQNHvLRT rWLKRvaDXRrlMO/vvEqId5Q7rjaxBLq6usjfRbvGp2ZTVirqV0PTG8DbhCP7HuBtXX8CPLI/ 0/WwixlaBUyDG1cf11QogIQdZi5HpPIz4zVp0qzMpaxjKomBk04EaU7og7TjJMHfAyoIfFIw 49BqQuXInBlWHKQwlJ03YCv2tIhFfxt5h40M9yCPnHKJ+xG9ZoxjXVadnUrtkitTXX0cZFrB kZgAP5oyES1weRpE5XQprpwmzQWDuR4tKEg3QIFYoSqo5XrOzSDgyqqE0A5r1m9RqfPx3nHk vHs1jv4fleJMrWdKgFO5C6guJsXq+gNpCNCXuxHfY3Q7D/R6kjGV4pYOeKXnIDyD0uK2OIHD 0YqLt+vQ2nwtfV8dpoiPy0IEi8zKU7amTV+Ko6q79LozmTmqVCtTlBZzUNow0iAfC+lK+W1J V8cZz6tp2+07n43OFlbedUGKWkvftRtNVOjw1gTDIuzuQTHWtacojnqVBL6dSZfJHQSZbuSU n5RPKXQsSVqq2q0mIeUgGmmbxoSCdQ6tnip5Zq3QH/EmJtmNnN0r9OkriBFOWRSv1rGUf4mU NFQ07YIkjZXCSJ21ctdb6Ht75/Uhvr49pCFdkCSNnom8OenFEbQEBcmoM+oyNCqWDYddb4Co Er6eV4siFDX2dQJtuDi7sxKsfsvTsN0yKQPuF77piDdV8+DxqwBbE6Bbf/14ELw6rJ5IOXb6 q4usyZTkWw2oX2WJ332qVpI7ySqBT6s0ftl3iQP09q9qjlI4so2Ic33M+rWTO0KWth3Lox8l rkdT/Zx/mH/66J358s08nF+8lf8G/AdftJPOCmVuZHN0cmVhbQplbmRvYmoKCjI5IDAgb2Jq CjEyMjcKZW5kb2JqCgozMCAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQov QkJveFsgMzk3IDggMzk3IDU4Ny4xIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2 aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGggOAovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVh bQp4nAMAAAAAAQplbmRzdHJlYW0KZW5kb2JqCgozMSAwIG9iago8PC9DQSAwLjUKICAgL2Nh IDAuNQo+PgplbmRvYmoKCjMzIDAgb2JqCjw8L0xlbmd0aCAzNCAwIFIvRmlsdGVyL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCnicrVhNi+NGEL37V+i8YE93daslgRCMbSkktyGGHEJOSXZD2EmY ySF/P/XZ3bLXHhvCgEbu73r1ql613M43/27eGtds3Q6abgi71LRDi+/vv29++tT8tfEN/b1/ 2TjqaF43NKjj96+NvPPcr7YIvUjvH5vPnzYvzWr57tryb9rtZPou2KxfXzdP37/G5vh383K+ 2tXDvvE6jl73p02EXdv0cdc3p9+apwXHxOb0eXR+Ov25mU+bl7Pxofe4fw+4/n0TEh0i4FEG mRAb72i3G1MGh8YGfOoUaID2+Hl07QSjS66btnF0/bT1oxvoCZGeIWC3D+44hdG33Bt17ExP DxM1TdswQphiO0qnDzQ++I46vJPJfjgb7hM1Qy8j4EDNsjnuR88UeAF8/nL64VtmedeRXckZ EAOjAFdQQEN2sQlta75BGBzD4A9sU0dgHOiBGwMeiVvQGuo80sHx10JnwyPTAadtO/pIVnAT GZAIRQWNoZBpsvbMc0GaCLEw6hayied9eXFCrIwNMMVhlCXdnlehDa7gIgwBQF49xhDf2ZTM ENgX3+/dQV0TYZhCn32LTnSLoESujJPwwd/Ph+jJLF2A4FAyzn4WDggXZLD64JmfBxejeEj6 4lS2lY1t2y2jCkzbm4yCPiFRHuAUYPjCOaf8md9dMAso5IQuQp3MrX2ZshC3kIzdmEfSU+kk FJHh0gAIGPJkIesXwjJRMBmfbWvbI6/p1/OV6zRHOnsNBOacrCW8NhIfJBQOMvkWISH2iO1D hIQYqlgVQorbkRj7CVZezWnsINxhorlZaeFkliaYkFvxkdb5rdWRC7bgAkEYpcyvKCssdGAJ UVIir0W7tB/igRj4B/FwrU0pKfwZT6TZs0rg9M4EatladxA4YpVlZUTSWTxSuldjJZQIA3lI BNXAQYnM4AQgwSpNWVQWSxyyAZ9KgJWhITgVhpi3/tZSrSylkXALXt/5EsT3wetTjvsMbxgm pZLkkfo8RyUfKaU3ACxxMRkWTY4qaEKOWWPM5FLcYQAo4JC3rSBjAFa8VqqHGlhQHjLeV4jf 6da3KeoDPBqyHjqbUjREpBHk5PticxVN+dRGT7U7yv8aR284YlBK5yGz7BImgVNCWbfCiOkU K5R4t4C/HqqiCEOyPHSfIAy5nMt6AIl3lew510k+5CxMVVHPmTeNVV7lt0WN8pLXvWkeZBHh lZOQVCoYUQAaI4lcC5D9qspIWshU5U8/mUSodIlolcKjUoDqiJciptsOtqhVV5C15CbsyZci 9x7Y25p7KsOSpVkQFVjT3FnzXj5hcYTCR8ih38wenT8zWqrZ4NDKCuxjdgtWTio8QayNEopH Mf0RSEWcq5pAi0weImZI5ciaXdcZBepS1xLhPyiAuqJMd9U/UN0sFPdnPDVjnGpS9e6YmUtH OdbcYyOHAo7YBPinLtMqOdfWwZcKqFDL3KS+kNIkD80orIpxDwZVRs3Y/K1qKZT7wnCTx5xG t5g602NpdOvbKoP8H2k0qKxbA+xVvfJanBArmcYaP0Kp8WOl4rnSqlSM0yh2iUpb3XVWM1ht sci/4TYPtzHhZfoBIm5bd5kBnsFhYmWJrbNmKXUr4g2XoSm1dLceUsWYhxyHiVT8kHPu0W7K /rzsBimJ1uG+DbbpTG7MZIvVNVRuUTUlEx3gA/na8jeGR3Ds2wsB00uyXBPsiiAlCHAB2o6r awLVhe0q4uo8pGmIy+Q6NiGjbcbVsmKiVcB/xkJM/JvYv1cyaKhARkClUU5VdAn02pAdUWXq 6ppP5TYFV0lfH+LvfbIL4p0OQLurWlRLiGEaznIlKdCRTrTX2hGUiIJmUqk6N48os0pl18PA bqqhlq0lf+1IpSyZpRCuUvLlRw/9ZaLYrRMqg2532P4shHD4NZBb+hgWoS+X8ACm/vKhAIy+ UT4doFnRDeQ/FinJ/CKjwd57q53Vbm/XTakIyqVRG3ppqj5XvTTVR8Kn+bsfQ2q+/NM8nd5D K98Y/wMxJYD8CmVuZHN0cmVhbQplbmRvYmoKCjM0IDAgb2JqCjE1MDUKZW5kb2JqCgozNSAw IG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgMzk3IDggMzk3IDU4 Ny4xIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9M ZW5ndGggOAovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nAMAAAAAAQplbmRzdHJl YW0KZW5kb2JqCgozNiAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjM4 IDAgb2JqCjw8L0xlbmd0aCAzOSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic tZdNb+M2EIbv+hU8L2CHM6RECRAERJZctLegBnooeup+FMWmRdJD/37nixTtrL3OoQigyNKQ HM488w7l9+D+bV6cdzu/R5eGsO9cO7R0//qp+eWD+6sBx3+vXxrPL9xzw0ZJ7r86vZexX/Mk fKNv/2g+f2ie3Nn06dr0L/ba6/B9yKN+f24efnyObvnbPV3OdtXZF5nH8+18aiLuW9fHfe9O H93DkWyiO30ePUynP5v11Dxd2IceaP0eaf77BnTsRCBXBh0QHXhe7caQwdNmA11tCDrkNX4d sYVuiqNfph2M0E5h9HHa0fUwtSMkvgXP7+xxKMY+kTkPCtugZYJhxOST73w/7drRr/yfjFdY xWKb3OO0k7nyU9BrO2HPa4YRD2I8yARi1wXxiK6/nX761j7BJ95o53NkBgkLXgkLBL+PLrRt ThbFxUtc4JGcRPaMLrQFpH36lT0JPr+hhz5tt/J08UfZN+qu5SrD/VFtB/nB00LkvYLElzdL r1BiG3mjUOxsfO0OeyN2Z07gqBPaHJfLUegSLyZ51sDSU9Q5rjjju2uRVggRCd33QQgpDykQ wlFA4pxzyCLHera8HwxNnDKDkIytiqIIGcDMirAMgeNYAcbYygJC+oHw3MAn47vowr4jaN7B F1Jt4wVf6DVLVH3it6XkMmfeygUzUdlQk9ZNJdurRYkCU+WYHIgG7ywGUQxijcEGVl6n48wr WkdzQUk+mtNRTDlceCNcggjGnmL2LkQwhqoeTafUjZlkhBxfLdmywYNKTIXPW5VJZBVrbKJF B03dDDcOIEfXpEdxirJIMjQ3EBUlG1itvkkaew202iON0R1gRy/D+h3CADdtv4swX4K8EdZb KlNObfBFNQpamlcp9mBgmXWlF8bQvInNUU28KfYuV4/gcCaOgGalzKh4yaSreKdKKFSSAHXf VkN5zbWcpybZSpsqVkuabMlLhAlMB4EL/RamkNpco/diSjpUlfX/iCnBCIXFK0IWrVMHThOO 1W96iW/bu3blzmSzbrEbwitTLz/Fl+y+tvNwG2EIw9YZ7kEYQkvHw8smTHleDJSNnp5UsG5/ iwKiGPRTpiAzKLjQn/VGHUqLqpSF0mnPcCJr6BQbDQDWpnnerLoVlDLJ+clAMlJqpZRTqLu0 sH4TUA/5gHgvoEOXR9zZaft8aImjAHyj3+bjnQnmzIBPUsM8hZwSz46Eiqw1ZlltauuOq9Jz E6munNLuI6oDOodf0UQ9QlnS6x+geVWrsCVLHy8Xh66z81asurSVprwsunhxoKPis1afAV5M jhWgJXO1MfLmfKcNv5JuEs65lIto8ff6c5/L7u72HKpCVaxilJNx5N4ml9mUa55Kmzwi6PdE ES6M1m85+HrSME3K6laEpzURzELFq8HbLlx6MV9TJXRrxXP5fAk+5CnMD9FPWf5wLndXyRwG CkakIJZOEFBCQj3f6j2xjMz0RZRF1b6aTM4hm64WK3ZaBFZRUKvIpUvDHoVGmaI+RTy56mP0 Yf3h5wjuyz/u4fQavX7L/gdk5E+ICmVuZHN0cmVhbQplbmRvYmoKCjM5IDAgb2JqCjExNTcK ZW5kb2JqCgo0MCAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsg Mzk3IDggMzk3IDU4Ny4xIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC L0sgdHJ1ZT4+Ci9MZW5ndGggOAovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nAMA AAAAAQplbmRzdHJlYW0KZW5kb2JqCgo0MSAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+ PgplbmRvYmoKCjQzIDAgb2JqCjw8L0xlbmd0aCA0NCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicvVVNj9MwEL3nV/i8UtOZsR0nUmSpHwmCW0UlDogTsIvQFrTLgb/Pm7FT uiu6gguqNPXHm4/3PHaoZfezeXDkVtSKS4NvOxeHiPHj5+bdjfvWsNPf411DuuFOjYKSje9d GZvv/RJEB2X3S3N70xzck/DpWviHuk3FvfWL18dTs359Cm7/3R2eR7ta7IPFIR1uj02QNro+ tL07fnLrGZjgjrcjcT5+baZjc3iG9z0jfy+I/3cOnRbhUcpQHIJj0mwvuAwEsh62uogTzfF+ lD7LSJJXYaR9XvFIQQYa8iqOTNlXE8tOXvmReh2zx3Jd8IahrcYAEnDvk+4stvxXtNkQc6ge yKoetMvRYte8NGHNsBwycltFhqVkibxNLhMB/uH45k/smZLS72jRazCx5IpYiN0G52NcjhBq kakVyITYZ46jlKQ71S/AQBKlY/M9hzLVykStgTDkrVkCJ1XVV98N2QSnASccgGG9yMDzIr2U 2NXLIs7CKouFh3mZvURcv3/hL5fdUvijzg7UYhZWDno6nZWzp64cEE151dVKfaWsZHX9CQ/t OZNSRTMNdrWBFnqQitNZ4NVZ4a014MRTcbbeEe0dqTWVXKULpR6BpXihQ3BfkwvS42ZVyl6M Mm3QiqIFGGUtq07m8xJtyw3RArl2qWFkyNHU2bPIjhLNdsqse1rXYp8V1nLqAh6nNgTPeJra JBy7pdSU9D3q8WZYpd5xXyrl3JmsOAchiE+RunougtwJEmEY6l3a6GSLnV1dSCgcfxOcuIaZ i0vHBAYMpLCwRwcIZJnZEnosxYLbQIjuXISCsl5nABJW+XqHGqXYLw36vykhgFzit+Coi7Mm LfRq7Gv0uL/GTbqEh12IcaWedlaIaGV7LErb7Mz2paOm2kB4Z5NC4nlT+0x+Zzu4i8/Qenr1 NnTu7odbHx9DLF+xXw03lvIKZW5kc3RyZWFtCmVuZG9iagoKNDQgMCBvYmoKNzA5CmVuZG9i agoKNDUgMCBvYmoKPDwvVHlwZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIDM5NyA4 IDM5NyA1ODcuMSBdCi9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9LIHRy dWU+PgovTGVuZ3RoIDgKL0ZpbHRlci9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJwDAAAAAAEK ZW5kc3RyZWFtCmVuZG9iagoKNDYgMCBvYmoKPDwvQ0EgMC41CiAgIC9jYSAwLjUKPj4KZW5k b2JqCgo0OCAwIG9iago8PC9MZW5ndGggNDkgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nNVZTY/bRgy9+1foXMDeIedDEmAIsLxy0N7SGOih6KltEhSbFpse+vfLrxmNLNnb HBsDtizNcMjHx0d64w7Q/LN7bVzj6Cr28YBNF+DQNV9/3/30XfPnDhp+ff20c/QAmy+7vAib F9vAW1/MBH/qs8+7j9+pZXrR/vHKJrA/hOb6W/N0IbN09fHoYLj+sZuuu/c3q2PPfnzLDtf4 g7+79n3z2nQt+RgS0rKAjsx7iIe0DvZVHvdim5e0vBNlZ2h+/bJ7+v5LaJ7/atTqf0Bv6Si4 nkxG1x5idrc9PI4NO8YhujRH+NYWwET2U2gzgEigUFDXjz/zpu7ocMCj8y7wB5nmW+0AR9cN +3B0Pd+WZ6chHd3IV+fB8zZ+/DzQ21Rudnx1GSKb4MfnoTdD4HQZmwLgtbLVTNE9B0jX4PmG LAr8NQ7Iz2QduKEl6/SNncorf7n+sB13R+gmz0lZxT3NvvObnKxBSuRylehKTlQfdLU8EQwk GI0ssVtiJxa/xE4vx0gw7YyJ5+UhQ0bRzAdfFDuxxeErPEFOwYwZpApm8+oeCC2zMQESFCsQ uqXZmywCPYZVWBJLz8icZD2MEoJBxJDlyHOqz+xlVwxcBD251hvyyGlG4PluIKklt1MXSxit BnHSXLCrgb7slTL0PtFBgV3SKHxedVbA9ol9j+K7C3DhZ3CCM1lpAeluYL/PsqUTJtD+O84h 1SNVPiJhnd2DgzqIbgDHyWQGMQHwiDAE9okdTUc07tERQCcxRLwWFUrOcKERHNEPgbkGUjGo RrliiaiSJ2BUH7iZSDw6el+5SblwR/WIzAtFMz/IfzplYofOKEV54TBcpEUYtV7APBg17+Rp UgkR3IFrhu61EiXb5shgLiGK+Z7T6CnxoY8rlynbvdpVIOQs8/PC+XXPFbYnvorIi7AvTp6y 9xqMUPcsMCr2y8I6QEs6Sp8hePD02SLElBnaAZOgTZkEvukZaJXZIHopUpdYATifdCbfSXwn 2cO9SEeQKgoWU2ACeI7XH5XUYuQsN/t5i8Qesq3qzIukUGzJM0kVZRlk+Xk+mojvja6ceT1R doOY83KbCkZsmT8gChiKCbmvbECQMOj9XlkraCnmFvi/BI0Z5BaOPMuRBiY9N2u6IqNoBzBT T2JU9tRQyoqTaJUTIBnQwNJc8CQSRuxDc/v547udDCtt2/G4RkUPcv3S6LUOMS/1RGNfdNXn 3YfVJEZJCthm9fANaKaoHwjQpAmgCjxqe2L58PIFEomb6NqoD2U1y3DU1dQm8l0Chu5SKhIr 4sgIoS16ll0jqbMjsJKdQZBzsQ/F4EkbE3siPeqiPWo0uckHkTTzQWxIV+sk1ILNOPscldnW MWW0LGcyqWdghjtDARcmgf4ldHbrIg2QvtwpipYHNuLvCmga0kZ6qTd2LiFrkelJAnDxHLhO uJmJ93uvoVhS3EidiBHwMtipXRwWeWGD+mANE4fla7BaWtnZIkQ1am64SRdO6gCQhii0Lfv2 BhaefgOssBjJKG+e+BzIEIgbGylxLcrIYcw0It7mPCgcGisYP3pN5h0HpSp8jCsHqVPyuSAw qEdK7FaSgvplFMgMcFBnMjBJd02FZaiTJQWtNNui9GZchDfGXHpbGbVyXHB2UaoEtk4bOfWB N2sMG04TFc5VsZDHxoyHafZrbaExwnNf5ti6kkBvfihz2wLfLBVyvBAyaweIahQ6ltgB5ssk mBDMRXEUfDZGU8NeJAjzEVQ+xjhBMhl9DAm5ZXbjDRlHS50ok8RVJ1GojQ9Zp3jBWiLUYTzp lObXUtTOJNAj/QZF1A2ctVz5onDbdTA3S/yuwrNWEE/BF2nZYMeCbQ8BD4VupnuQ/eEfUVSo j2oUO79mlx6RJbQqNTIHq0pD1K4zWaS+ZnaluVYeBvDEQJHejTiWoLWSwYDOpFBsOA0zb2/g 8aoac+R1D4VcwQBvUAfTWrCyPKk8eq2LJApfPB43yDKZ9MS5m6bcA9SIPCntr6Yh2tSVih4T UOaBtMlAHMtszOEvZGlWdOFE7S23p+VE8BCSsFaf7F+ljxuzyy0L5lFmHhyqQQFnFEbDupos NLP1BotxpYSn5Z7C4jlT8kgbTO4KoILpb/tyHlMqT2Y7D2HDDRGKqsc6fejBmeNzyaZamyad 9uakFiBHVktWZeSpQXvy3dgtK1J9nl7tQnmKTesel6rIKnBCQet2yvPWwEOJS0GaGererDzY mGVux9hxbjA+d+vSGlhK3tA6/rPPN2gd5E6aSeMXMZK4Wje7DH7RFi51IboFlCseL7QVa25W BqUxwLFqDzJH1nUfGBI+rppwiyJD1fzHPPE9SgfEjarXdFQDdKj63KK1GZPmeU43bc8Zq2lN GYOL+tA+o1S3aTknI+UWuxpucpN4yF02kwVir8vn8jQBfetXCfiNaqc5vJYNrAfLs2reTJQ6 fhsMKtWqBg8HS+8osEovFJK8fdE3fBYeonT/QCrqIYR3i4gLwcYFk3M4D3HBdVXzb9TyM2cx GipnKx4VcRSlW2gzO6dy9rh93jalbxqc52Gl0pX3q78pVH9beG2epncfIjSf/m6erl+j0/8H +RcCUKa5CmVuZHN0cmVhbQplbmRvYmoKCjQ5IDAgb2JqCjE5NDUKZW5kb2JqCgo1MCAwIG9i ago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTExMiA0MjAgNzA4IDQy MC4xIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9M ZW5ndGggOAovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nAMAAAAAAQplbmRzdHJl YW0KZW5kb2JqCgo1MSAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjUz IDAgb2JqCjw8L0xlbmd0aCA1NCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic lVrJbiPJEb3zK+o8gNgZmVkbQBTAosiBfWuPAB8GPtnTMxh02+j2wb/vWHOrIilBgESycol4 +eJFRFLuCN3/Dt871zl81c/90XdThOPU/fjt8Pefun8foKOfH78fHD7w3beDDfLdV51AU7/q EvRXnv1x+PKTrIw/OH99oyX8fIzd27+6TzdcFl99OTlY3v48XN8On5vR/Ux2fGSG68Ix3B37 ufveTSPaGAePw6J3uHyA/jhsnf3Oj2dem4aMNNPzzNj989vh01++xe71P52s+g70akPBzbhk 78Zjb+aOx8e++Ylw6N2QPXw2BeaAvg2T7uE7GHH8rye/Li9wcqO7Lf7kYXnxJ7hCv/hwAufW JZ7cFX+BdxHO+BIHwwpu6U84CMaTG3T+hf9OC9C86/KPt7/umgEj2jwMwZxFN47jY8sDgT8M dEJmuz+K9SC7vtKuA/9x8/KCtjl2JC4vQZ+iRydcKRZP12U4yQdoPL70y0uU0ToMePq4vMyI CSEx8eAbg5Aegn3OO+NUf3I9LTLQxGaEre0DmaBTZAjZAHwaah+a3NMqj6GM4YNARmesKYD0 PYLF3r8MAlayKgHs2WMx/0KDAw1mh/0rDfNMD8/48MdwJki9o4nicXDsYAiQwPLImWHWrQWi W0bBJuhBiVFXWra0B24MJz9F2+hzXug1WViuKZxVdhQr6imxs+EJ7N6bEr0beJh3GBz8Ep3u yQbpsYsRwkYxLgeY+n8t/Bc2FiwTZkk4ss8yJ0dAr2QzwhJQNa4IfmATEiUykKgMstylhbUM tycYOkBYPoRhP8/75B3ytspQZmSIOcbVEznwSg8Ut+sSsh6QJ60gpLCGe2F9j5/3Z6YocEmr KoTZo6kwKkhkYTSNNYVviv5DzPsJPsrbfpxoXIu52LsiZspb+Z2kS0VV2JMplUGYFXE9BFag BME1C4eSi3eS2DBPX4YMu7AXPO0Vs8h6p5PKjFCCyrtd8sHIMwuTM20qsYVSNtGKj+Ed3Icp 3U9YKbTwurOcv2SFMrweyvK89OZTfqaCKJDfcD0PxRQ5x2ChLJOH94iuO6syyXPhclimLFU5 Wz7DDZPSR2kZxh1a8ok1gvnCWbQ3BDItJfAEDPFOSFL6k2FUvS3qg0ZEk3InlSniG6SM0MLJ VKOCs5B2r8FVamwipnEXgqgAh4YG2n2cw0ygeTimeiFSOvpCMncH5570uce0BQlnh0Wk8JMh npcgv0DS9KhpSACdCDMRZPFmIgPBPrgsvc7TD4qF+DceTbRnIw/XN6aH9gGoOEBacMj7jo6S AEE6immhJ7BGRlRKnpHMlaji06DzKx2YBeDHFHYfVtY47ykrTurnUki9JffdzE+MUsKX0Ro1 pVkGE/4Je8Zc/pQ1h8pMmU28rutPVaJnQrtcwRaau11wW49V6sJleJk2cj1piXtTTbjj2Ps5 du3fv/184NZsHCdqTt2EzKXX2Jzya2nZvpb9m76RUX8cftn0ndioxOBNooO0kpj/Rs0K4hXZ TWhNLAiTZqRL/gBADpArMv7EX3g2DBDphAdqZiKNu8rnXJLpameNGusQ3AhRttXVpX6jLo7q cgBcNSwjcAUOyQT81OnmUruv2nCA+rDqfp43AXtPnaCXLVZxY0QlWs3x0q7ss5DIn9QYGXMn hMaBYIbBusIEs1RtxEq0PKqb3sgx7HimT1cdi0/QKLVZkEXDY4MtTt91HIfe5FDOcnjZU16C oVZgSqgVXp7ErEA77hwcxdtIHIoZ/rtOP0PQpSY5E9WjE+KjCJ0euZzNHuUuG48Zg3M+WAB1 Ux4be+S3QkwO6ahXq9eYDM7clHYRoff85HVJS6zCnIL2xlR7lO0zyBE0fgN6hhcJQ13xlqyx Yq88hQ3fWfs9XYmQWeEZ7mFqeZsYiQWojwtaZaFjoao7x5JCpKbTg81YjcKQeiDdjmbs5xm+ Z9lO+JUqRUokg2rvqAdbysJUyMIynDbUjE3EJY+EE1v9MZTliLJS+t6k5E4Q6rlGiwOjYXCg m2IyWdkLkEASG0rGXpQ1T5i+JhNLibhqyUh+C0QsGA8p0dN9WyNmIgVqMwWm7qcSkeQYU4LQ nIM3QcMgDwmWUVQL8qE8iRt1lj62uAGJG4nix4Gjw7OU6CGAph4Zr64IYeJERPOaCFQUxAIs LiEf0EYx6RB0j4coYxPQCh4RSsOpIFXwIaBRIZYRjmBqttChCG5JsMx2XfIs15t7mc9OYJLb ozR6EMXN5zU9Ud3meKrjaPlS1B+WT5A6RaBYSWAO3nJ0PEHWeyv7M7J74lunhZyGDY+gqS3x cVDLGnRuQg2LREnZ/J44f6fGyOnb8YvqmFChoEwQbS4v6qJe77hEmWPiRdQ7yeyikAkL0jmn a1zAKPcMVTdYk1An6DVxw6F/DTR3i5D9ukyDjcVd2VwckkKJeQd/qqjdOcRoxCmBtQ1Lhdwk Vav+0haN1vE2GpkkFuMT5PzsNnoKlq2gisey5KXizxcpiLiUI/RBRVDVaVDrflOikflFlTbt 2OE9xEpYdqIaeTC2xSJV2cb+wqRMtvLAHsI3RruYyvDlpsGUPulEryoNH8sUZZwCC7iLdcOR u6AcVk9LHh/DNmyku4eGWFx2Rtm5KjNUhXKNOLXy4jTAQsnsulFqQv1+ayQRBE0lSSWXgB3L 3LcpP8nAXsuoAc9itYDE97ES9nQWUv48pYFPl2ZZ1S8qMrgL8lTFkO4F614H7Oue3IJZvRGz H1Mq8OBDCDJ6QkeB707jusGqT/NiEuQqF7/3sB/iBm3/3zZyWVZJdUPZ1fnNSZNi1cg1qECu hzLacEeaQtI/r5q35np1UwnXJb5l5XQ8uUgBOx6gaq4sTEKmBhFG16jvKBrtfQQuzMPmemVf qJs6OeX+puYRcIIptSbOVEU0LUm1Yi74vERzongRDrs0L5aynS8qz8UFwdQkhExx2c6Ufqcv SBrGY59zFia3uU7RwzfJlq8HLZD0vqS4qOLkcy1TPVj5rq2HzrIUb2qkY+yywdySDeNuQO73 khpHE9d2KnJtDawU3ulRy0OMuZp7lGogtmnSWmWT9PZUMnDLUBWvCp65YlFbNNBWtha1XrSb qzQ8XyKVgVdqYlPAIiIPIL3bCD4rg7NSvUsyIYTtrUNd6sJu0IkL1ncWgnUrClFTyWrBmt3e bWiYxG2v5AvUdRc3dmvD3dtOGXuWr2vje+9u6KuCtorV/5rY6VmfXoTU2mPu63E+LY6bTMAp 6E5PI3fEQe/YlDq5yDHGDEUqyG0yrmRxWPklqwh6lSiv3IeL1dd3XR2jJZt7gLZq4JgduVin 70VGetu0BvcCnJ/ZAYWqyN+0pHxg1i1UAZjFi2II8bEyJebCas+CxMFCCeKmrNlVZyhPmu7k 7hZqj9Cdhu1VgByeFffb1mVNMlGI1l7bkypkElm6A4a9mnJM6s43yKOdwg6fi/4+ES7Hach1 WXWpkxW4uH1K3I+pTioLr1W+tym+Cjmr7kNV4dp/xz3rdRjs0W1anU0dwJ6MWx3IdqZkVdm9 08XXldRuUbRbNJRp9PPmi7jiC7nv3afrz7/0Q/f7f7tPbz/6Xv5V8v/xzRHkCmVuZHN0cmVh bQplbmRvYmoKCjU0IDAgb2JqCjI2OTMKZW5kb2JqCgo1NSAwIG9iago8PC9UeXBlL1hPYmpl Y3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTExMiA0MjAgNzA4IDQyMC4xIF0KL0dyb3VwPDwv Uy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGggOAovRmlsdGVy L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nAMAAAAAAQplbmRzdHJlYW0KZW5kb2JqCgo1NiAw IG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjU4IDAgb2JqCjw8L0xlbmd0 aCA1OSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVtLb+TGEb7rV8zZwGj7 RbIJDAhwpJGR3BwLyCHIKYltBLsJ1jnk76ee3dVNDkcCgoW1I7If1V999VVVz9o9+9N/n76f 3MnBp2EensMpJ/+cT7//4+nPP5z+9eRP+Of3X58cvAinb086KJy+ygSc+lWWwL/53W9Pv/zA K8MfmH99xyXC/JxO738/fXmDZeHTLxfnl/d/Pt3en37qRg8z2vGZGe4Un+PdsT+dvp/yBDam McCwFBwsH/3wPG4P+51ez7Q2DplwZqCZ6fS3b09f/vAtnV7/feot8G6GsYObnge1Y3o+Njpk PODgxmr6oynez2DMOOJPmgLzYdvDKTHAiHEc1bBw8oHm/OXi/XKOFzct5/kS+HNe/MXdlnO6 +Bs9SEu4uNflPF7cuJw9jfY47jxc3Ew/cYiPMuiNXl+XePEDvaUVX+hphKH4aMBHa3C4QRzr NjTKw+MgD3gX2tcnGsc7vuICbM5rMVg2qQb7kd6CHfAkejqmC2CZvIbntNZf3/94AHbKwJPP gZ3GLdQrmciGMmDLedJTGYzoPAQTAAE/rnIoPDZDPwv0ZRytUU7j8dy5LACuQGcK9GYUe0rQ Zix7RH1QfhTzzMI8JMYJH8HPYxhDhgD8HIxh2OFszGhHTBWWEJc4XoqrB+XgLjP4vIDqKLNj VOoSTxQoty5+QACSwsJcNBzr2RphsONtw0pG4tI8TSMqqSs1ogYJP6YAuTYkMjHhYHrnYR1m L1MCwmdC044BByn6LG/dFu5Qgn4WdEUXDE9fjC6Yz+Glsocw1glxJqfwBPIVi0/BvoqQPOBV a+iyA3gE+V1wugsJZbYhm1BO8AAhCfcgGSJNKeoMoDicDqC4wY/k9leMYbCDT4aHRaMy/jY2 b98o2AcaE+EdxuyE5xpkGLgzyCKeDjeJQEQ5XiSqEcWZmDiftqG1aWc1A5GfcOFQHwSd6QTw 5HfszwhxPQLbwAvxEWg2zWATDjAnGg7jp+VzGLfyGQbabFyyEW+N/xsF2wr2xqtEI4tUG+kg wYAEJR2QDHgXnVCTX8cicUZkNb8VGVX+nVUd2BzaZpLch7Schbhja06qwWMIDvFttLoVsWNK p/nTlE7TDqUBF5a0qDS9oo9vyJsbkWCW6BPaMSeLKg647Q7zZbLh1euigQMbDZcikGUsBwHy HmVhkMmz/mBOBgaSNp7UtqB7vDxALfqajD6IGuSveYMaUIooFmv8FDhqQNFZ2LLoGGOCaS8q Y+CDRC/DEIsgiatZRbfwGYkVJmW+RrExYlyMVjE+FTYZzMp0pp3HRomYyVOvDTIHjPW6uzEq Vn0T93E8RStacqZRq8sRn5CRx+4DWfgs6cFlaUfH+TzkwSKvIamm1hNTIIiWMt4jRQzTkD86 4uVo+CsQtfwtmcKMEwkvCYJdOapNqQXTUsG4Qh7TvJVsIbMiylw+EupxAITSTOrMoEYB9a5Q T4mmxBoTGWs1DAk+S1hmyYYU154KIzx8KTJjfQ8YoBLC3yy0dGSYAu52i0enwAlxBACVmbgi sSjJ7Bkc5mAgfUJAScJmeY/TvTN740hYACGmEY/yWJryZ3uuNO3Vr4hPaMpuW7835TgmopKB vVbj2kLNNGzuGzJP0jHouNpZtNlOKlLKOlrTYmn2svia68wLymSl2OWUlUx3MG7aFE5vUc7I 2W9YYjzKaSPq8phLTgPcJP9nqQALdxLk8OC1GMZzhBduiui12ANoJ4oGLFPh10kKbgJAGwPE mKgpLEn8gMFhko1LazdeKdy/OnHP0xDmdOr//tOPT3SbME0Z71MctkT4+euJP/Mtw1d75SC/ 8Kjfnn7eXJUAxVKMys148pEBI5rBUTE/AQsm9Co8CHC6a5xY2ZML8AtmB/59BTQzyIbL4N0r J1ScFQa38ocIC8GbANSXd/4aIm3Dw7N3vGXgvek3zwGWsQaD8aHMHfiVGMPL+Rv857nipJUS 2OS1q0+6K73ljXEAnoR/e4HpbBFNgsfF1noiUPw7HJzwoiT5rGJYEKVlyDCAQ0ylRyN/TuWz a/dDlH37cqXP7sb2qdktrPcXBO9AezpdmkVW2Cf5VEYmhBq68ulifA0/J3VPOQ6+aBFTv/DJ qr9gVqh2PMLQpQ0rPwOSOm4i3oFRb9JahsKGcOGHMJTY6V1sV2XW8pqD4nLd8WSNENlbQKtE Lt5Z8Sm0xRNVPQmliWIill3Jn7HSk1HOICV38KIojlX2Cl4RkoK7aHjhZg653tAHwm9Vd0Lw BFK8V/zxJhrIDOM51yPKlSPW9QWChiw2gHmlt0o7DNZOU1hQ6AWvEfUH/2rCeuQtViQ0emRn 90PSRci5vg/cle2L7IVrY7Ds2EUkix5CXfnTY2X0R0JrZx+VJvTFjHdXSXGip6/SQCbRSNoS jSlkFX4rULo9AIQQ7VtWhzHxkCMIZqUR0V2ZPpaDPER3dBuK8h5pC0AJqGsd0tq5H7OUoYLR I2ss5wQKXdeRtvhV+Z7kSCWCjZBlTWgC9IPQTOOGVdCx24zIwgpYJ+GTiTk4j59RL+Yle7z9 SnhbcbZp0sbUVY0igYuSAXfYZcXpAxyn3FtILbTjsHQvMgncsbIpuRKt1+VjjkBvveHI/yE3 rsYCTWgFIQ6cLCiIVIhnMVKWISH6qTkGcEwE3XBVy5Ch5hiUV96k+tT3OI5V/PYKhaK9jW8f IOmnDesMha0yyTlIsNtq575KREVS/c3VHysVRSsRqBQajNpqFywpT9TLSBcN3AomDYyTKRgJ XJMbbI0HnQxEzQ2abF8HCMhBE5AXvwniYZDljrF14b6SATFsVbBaqelqAUICflnvJo0XI7sb SO4EtmSUvWxMRysGWkqi/qpQWmZyDJGT2brVyGOi+LhRVo8W30P0Qs7bLFuzztBk1q6XMIXR aw3TSq4u2xey+eLnEpgaXqWziPQrrh2plTMdgZRguTElVWM6dVLjk25Mb0pANGnFUjYYZDcl euP7Y4CnqFcHFeBUuyKbQY3kgZLtCvYO67Zr1XosYXNdXaR1QnHJWzlkxohHPJqsJDoO7bTH i4O+9Rp1nUSFa62TWKqPEnEY5v0+l4ywYYQ61EmLRcQGTrB83XYMGqZFdLXI6MRA4+e1Hu9u JilQtprR5uRgml427rhKCSltSANJ7xy6rNcXZhQVcIZSB0pNI/mxGtv3jE2XaJKoXyzzpsWW Eft1MtU8XPATRhVcs0VsGpls4svQTq0jjwRD6a7xOQ6/6PrcYBudrtNjVdAtXDkl6URtOkm/ 11Db0Fryl3K/bThzs0ZtExhq1lXZPEuqaqvOVv60NK1SUHqfQUumVfsE8eoxTH7YEA6OUiN9 I6erMo7yDhTBqYk+qmNfJCxMnVXDgrHvckZJhzsk3uYTppftIQiqj4Bt2FfrctMHmySSbOo3 +esYULfJqqAXfObiJL5u8PjdUVh9XvbE23R7m1BsWg1xl1BRCx06wWM19nnc+D9m+ZpT4dZs idcmBA/fSoTuFtK4vLmAaXqFGY3aaSLbFNhcx/A/NCilz6b/2OkfddNcYvVuWe979Iv4lyBm lZMrUFPPHBLBT/65z3Tm/omCB+8SDM5SrDTNvOnN73WQtegN1dCu8t+pXzQHdtVtre0M8z/g oju3H3RO+pJYJ6rX10qu9AjLYdKv/iqWL2qKXqgqAwUOTcHqRRbSvp7Zr8AqpjXllSmS59ou aScubWbd26NUF93luMSbnmfnekVi0VRpAb8AJoHRog7tOgY1hQ1BD8tOe/W+bfRa2pqUUTuV 0tvatJZMeBZf3crEZqd6v910s1urE38HQklVFt9azLvQyYLkze0NogG/tGgfu3HyIW9I23yl wxrfprb6W7lgtXtHSUTlivgczB1xf8OIndbQP+wyiXbfBcKKyv32VVS89HVDV6GtVbmUmpJi TTt2NcRPYo+5hf7A7Yr38Q6D3dJe05R8wI0mWh9u8GYYu+uQevixtUSuYfsrkbvXHt23NgKG WWtVT5RIOPLEg35wW9vqXSAnDVaTz9zCz/NWcYt+4WpW6vQSRazA3KAJttYhfVlhStSuHmAR 2d6CtfD09w3iENgIvxaOPtzg7JB6zmaHvhEqc5iLdW2+QcMrFWe6xviYkzlts379MqnjU/+d RfedbK04tpTbKWX2LhYfaNTkthI1L0PepdRxuyT5X8vootLE/k1JX28tKt2rMtC/qqqXhuZ7 GituoSdESdaZaqlgL4UZnLX5jlkuj5pvqnO1Ctb3JgzNPxw4+McB309fbj/+PPrTr/85fXn/ fXT8fxr8DxgctHIKZW5kc3RyZWFtCmVuZG9iagoKNTkgMCBvYmoKMzIxNAplbmRvYmoKCjYw IDAgb2JqCjw8L1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WyAtMTEyIDQyMCA3 MDggNDIwLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVl Pj4KL0xlbmd0aCA4Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicAwAAAAABCmVu ZHN0cmVhbQplbmRvYmoKCjYxIDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9i agoKNjMgMCBvYmoKPDwvTGVuZ3RoIDY0IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJydWktv48gRvvtX6LyAPP1ikwQEAqIsLZLbZA3sYZBTkt1FMJNgJof8/dSzu5pNyXZg wCOL/aj+quqrr5rjnv3hv0/fD+7g4NMwD8/hMCX/PB1+/OPp158O/3ryB/z58fuTgwfh8O1J B4XDV5mAU7/KEvgvP/vj6befeGX4gfnrKy4R5ud0eP374dMNloVPv52cX17/+XR9ffq8GT3M aMdHZrhDfI53x34+fD9MI9iYcoBhKThYPvrhOfeH/U6PZ1obh4w4M9DMdPjbt6dPf/qWDi// PvCq70CvNdS7GZYc3Pg8qLnj8+OzhQlxGFyuJ3xrig8edsk5wUFoCsyHLx5OiQOsnwkgmhIO PtCcLyfvl2M8ebcMJz8sYTi5l+WYTy4tAb89wu+EI+Brf3LX5Zjw2RHGXZYsI+SL23KEIYGG jPSZhvvrkuyqMHF3HD+kcT7TdmiQLB4uxQi/4hyxTU3+6+ufH4CVkkbbu8FKOLED60abIlgu L8cZsUlihECR6UAT2uwj2xvIdMZoQBR5zFhHupl+EwD89Q1XZ0R5u5UgYqAI+bgcxzplrlD4 gqQfT2Es7kP8r0tEs9i8/AA3QAxACEPFLUECIG7hHm5DpikRkkZxc5CFiFtwaBAcYULEOKRG QoycjPZdFgIAY/HmRgAkCipwUH+KXjDMCOHROzyKx9BCECYcfMXV4UQcQ6OuK8/KWFoCoPEA jUb3KPNoWCx/l03RKEA3ycrgv6DGZ3K62MsjV7KaxvMg9HeWpxDH4cSjR3QveMhjenAATOQe 9CCFO3x87B/gjfmD/nHJxLX6x5/5+IjgbaG08oOAMrJBjGnk6GIvsT+NuW4Z9bDWBQi554AO OJjn8RbXuuAebkEeMlQwszgI46WB94XtLh7jEfxFY6nGmaJdzrXacz4klGHKH2XfYUpQRzpC OZMNkJJIakEILjJZeMsQmPPCmUliRZlEMpxD6KUSTE15oVxeyZByEpq6SCIyjZkxhXMrE7tz jGHCJ1GDfqg7+q4MzGKCUiKb/BbAOX+UsYccdxgbLE0484gJPyyjnnk1FMwG13JmD2uqFEbs WNlcCxkDpj4pWGycMkvBsGX08gYGadADvRuDFDQuWwz8QBR2pEISi8sLGFldtYvFw4D0gdEI 13vHCQOqrCFNNQFY5HwhTGfE9N7UjLS2fyynlSRWBxXDppIMary4pZUN3oqZPmZTXaUoksc+ C8MHPRb2RFmYl3HWlBEPGIf1uc/qYDaqw0YkQWDi9Sgui1zDrsKGqgnKZFpVdqjibCNfvOzL i0mgbPPIahi2IpqvxB034ZDHCEMB+yjGDsX7PjNYFXppDjDoyS/loAKdEcEQuUm/fqnFCYNH 8LBuM8BB1Y/ZRiB7gfdl9CrRiPhlrKKlcdm0JGhsdd59LIcJUMzTUGBhUIDSldL86FKV6uQY NMefcWdUtWAPmlMDa3CRQyu+kD8nqadwlpHHQfvFy9zkQOh7Hsc7mbLgnschzOmw/fcvPz9R 1zaOE/atbgK9iZ+hb6XP3M19ta2d/MGj/nj6pWtJAYtUO9LIXSaEyI2jA6r0kfuOifw04RM4 1Qs55CaVNMuIeBXtmJET8QusO/wMoYTf3q0YKVnrkPceihM6bq3jMFS8aiV85pGVPaQoK9nV zWJWcKeQENZm3UmsgoGr7HNevJhQvqBuS/6qxsl0n1yEn5G9aGeKSaNsETTKM0oaHnUn9MaM aPtSrAvavCRsaZcc6agE8SqxtFbi0e3bjdE8gMk7OcZasNWD3kS1v9C6pPiMi2XrDkwEksbu gTnxF/tYcqOAPguRDd6aRqbY7TwGRVxGptcSffx7pklkwKS/vBd8dJFH+Md51Ipao32iVaey NkSahmHmzreGOQctuwy6u/Itnw9sMQlh8LRhGdhRfWyBYy7mL0XyvPgmz4A5KDo8tKkaHPLc y5ZnDlIw37g3BIixYDDNsGHY2VCzhp0u8dSZV8MAHVUCkKlgIolSVn/okimoPtoQEOW28M4l XBo2EhfIeRKcXALimE+WYrwDs8Wp1zI385DiIB1QoxyIKQCAacMam8i3GWujsgYL+2UQ77Cv 1iactqjjp014TejLJEqtbD5K+dkQLA67KWFMFJJveSBnlRbVA1HyU5Ojz0dPmeNjJWjWAC3r msCVRIORSGA1auj3kFH9YV2BgFvKuS9yu4HngR2gjqqLgSH+D/ISmDRT2jrDRaZQV5PMmi2+ eiQz/9ho829BPbiO/4vrJDqKbYbXQ6AzNPl7l0LpeC9yY5fbABlrWtT42NIYuV0D2bq9CAMt J0krVdqEZuRAFMfJ5sqDJkZ9zZtOKdgM8lILxQ5h2/dxftwG974aAUxYFgjfRecVoygx5Lly 2rDwEDAjY2QjOpwFyIvERWJILZ1MIiW0mmvcDcreIg55qSssYeDU/MJhOzVHMRcrETzxrYga YZebXMJN1c93sCS1GP2sbVvVL9caGp5uo7bKcI8nlVVKrhmiGYMViVFS3u8JjTV4XdvgSsXq qipvya01o8mcIqyghmRSSoPe46mkAAPY8lWVVa3AOGdRgheTNm7ZcNRO3El1KCe7lGX4cG/F t4sdfbc8N7XZbSq3LyXRhh4BeF7077YQ2aqj81RaVJpZSF6fTUJs1Efla754VPUnoivtaItw NfCERqLsFgI+6EuthXwmhxS7exradot+VQ9aVR85I0DHNW2dsd4lO038QZPbagybBOdGPqfq R7I5bipRbaQ2ul2jUnbwRkabuq7wIFSi+SyB+QbOzYpLbrK7V6SdlmyAtxjFAEHjNRzmh8QU xqDvXwR3XPveq1icMOSOyUC20sVPd8i+dyyuKEVbRUSjNneay1gFqS3mUWavZcXd6Z5yoJBt 34eXBFmlij+SR1rQtKwGmBOMOWvtHUvKsHmjUoPR1O6t3Ej03qUtHrqs0SyG9z29p8U3Km3p p4PkxiG9nhu1f+7r46hKhIbUoCt6x/KOBLjOoRmpaEaj0vbVZQx+jBd91bON/XLJxArXWXbW SrLr+nDa9KYPoQ+p63tbFsGVtjSCN/bbGxq8GmlOayvlbugXyUlCUbWjQb6QRdvglYsMrTIC W6qdszcZI2BHAjsaKby5YaLSpNVKPavSSoYuqgLb/H/PDU9w84aIvhSPFxmctWxqr0f82qjA N7VCrZGSGE5TVh2kruqiXpZeDCqVrKeSMdtyTc5ObL+TIXutf8+hPfmUdg86e272r4/lJ4Hr 59hfVrI6yaQah01TeOVCPnTR2QRySbG3orK/i8kUT03zs7n1IVLt8CQ5lKxZOsgwOUmVartN WGuy1XOUDTl8RNP7cex60r0bYK0Jm2Oy+fRG3+0O9CQKNixSq0llaCyNRU6Q34K5VbEsX+4H p51bwk2ws0M1O+7zfsP1a7mUJQPbve3tAj8xIowcMKQaNg/jOfuOlpWwGrXo+QJAdujpVZrq TWMTSyO53uPW+oY8UzPFBwLgm51WjHMA46oNg3pfuuJHemnb3shJdGmRE1WI1jbL3L+9C8yU +4tErUv2tm97rbe9cRD9VATJWpQt3U3VO8JU2sXV1iSlj6LwbMi0t3YKVqWFKiglZDc1deX/ O2MJoYoFw27lpYKGSfMy4V2iwUfXN5bacMey1JmdVqF4rNSh0vV0U27+KiPbKOnue7o01wut /Xtzq9H663QWcpuXTHdiY42Zbps3rb6WQXOLaTXE/lU+VehpezVya+541q6zuyduH3ly7t55 hP4lRsecRghblu0wiW1U1dpUtPp4D3swooSNKX+bYO5epOyUaRt1n7uXp+Yl6vfDp+vPv+R8 +P0/h0+vP/LA//P1f1e0dosKZW5kc3RyZWFtCmVuZG9iagoKNjQgMCBvYmoKMjg3NgplbmRv YmoKCjY1IDAgb2JqCjw8L1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WyAtMTEy IDQyMCA3MDggNDIwLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0Iv SyB0cnVlPj4KL0xlbmd0aCA4Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicAwAA AAABCmVuZHN0cmVhbQplbmRvYmoKCjY2IDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+ CmVuZG9iagoKNjggMCBvYmoKPDwvTGVuZ3RoIDY5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJydWkuPGzcSvutX9DmAZL6a7AYGDahHUrC5ORkghyCn3XWChb0Lew/795es F4v9kicwIGu6yWLxq6++KnLGXGz3v9PXznQmf+vH/uK6IdjL0H375+nXH7p/n2xX/n3742Ty C9d9OfEg132mCWXqZzJR/sd3f54+/YCW8788f34rJtx4Cd3bP7oPj2w2f/v0Yuz09q/T/e30 cTG6H4sf75lhOn/xu2M/dl+7IWUfQ3R5WHAmm/e2v8T1Zr/C6xFslyGpzHQwM3R//3L68Lcv obv9p0Or34Fe66g1YzbZm3Tp2d10Od6bGwoOvYl1h8+mWGfzKjE5BjDPzw8Op/g+249xzHuA Ka6zDub89mKuZpzsS/449y/WTGf3YtN0zk9CeWIe8H2ezuHFevNafsqj8osIL255ru1hrs8z 3IsMyYbQhDdTbOyjTWensy8vcS2eaVxZCuyaAeb0E1uiNdE9eAm+u9diKdv28cWl6fe3nw5w 620mwPtwCyNHR+MG7itvi589OQ7eWkdu9ey+p/0Dmrjnx3LPChs1q+cQANQ49Tad4x4k5MGc kUe/aGUY7e+7GIVQNuxdxSgUznwqLu5g1EeYYnLCMUbwPWPkR0KgOBfB3RsFMz/OOx3ry0y7 /DiVfdpCBYAy/1x2nGnCgOQI9wUI/5gCgJXQpgwAyzg1I8GPTDL3EiMny7thsjGPSYU9PPZG NMwLJvqMZfwxXDbUVPxOuDKN3BouNwVywnpwqsCAAOTYet7vKzEqP7jmr8EUZH3kjCu7nQYg zECDHXyF3d3rU2Uy1ScUERyH5uCdB2lg5iX9znISF/DriOy57TG2uNZrtYYDajhKslAoLe5E eUeIHEah6PQ7SduPviTzIgolsV2ZqhLK1z1H3gYMUE8BY0ICZvgaEHsvO+iJibCzkRI5Eup+ Yb/BNKdwYMw858chMZZh8YbSC7CEF/RAiF+keCiJFNnIXW1pYVttX3tHI3DrlE2Hetyn/r16 3Ce/ocf2mvfhDKQ2LI+VBapSQRoUMgvi2VJFUZKJSn1YvlBs7yVScx1Bmv+QUijlTKoViDct QGXCJoA2sEp7pfwi847Zh1XRTwMPv4Mtrqc9lT/az0iMhcLxJGNyErw3Y/qwkTHulrXYByL0 Iv4JaYq0DTVzEHgiM/KdxR6na0Wv8i1JguUk+VeRLJq8oUKuKRVaAlNBMzVlSfJLZ3+tJKBZ WiO9ecpxH9/NcR+2eo5+skyrwCIh/Ro3IUw/bqe8gK1TgV7z0Ng0IW3/go0DThyLMdvwl+zB E8kk3Tr6Ws5i04isXEbewtOInoxPoLXxvW1wb7XqM7TBkGOvJH/aj3MkL7mBu1NFiCQaDb7B SmpSfDhjLU1yoaB5BXUNOXcwmGr3eUCZZ0ngWRx0K2fJlyxHzj6V2TC+W2ZDro5um4IugVMq qpQryIG74gCEPC01FRpTotODSp7W1Lbfv01Ws5mGITtbeecWXAKDDtXIlraup08VZZrujRf/ RLqVO63EHgOe69o7iRmS2yBmc86oVKAHnDbMLNpIi82s+wtV4hgCxMf3zVFmGdKtbN+A5VWK pRQ6z5GuRKHslmjsQdmPucTEYVRnC0YlAxDAsChdgFrjIDORf4V69IN+kypo8OFleLZUii/V LxY6W/ZfwGLksjkH2a1PUuaSejeGbvn/zz+e4JYhpaHcs5jhYuH75w6/4+3DZ30VQT/gqD9P v6yuUC59F+oNisdbkd9KCF05XqLnkKIoMjNTZiglD39K5SAVy+gb6Qg1/LFIE/AsA+zR1pXQ OWPWRzaJzx0TYIBPS8bYnSnyg1RcCrSIq645tGkzL+TpwHYT/VT8sdYZ9Joegqeurkm2U7Pl bFivJh7Q1nM4r3XVHP4EuYL7B6dglZkodaXVdkibYolOLTISHQvtgntAQkEb/qCsirI0w0Du N9EonnoRXg6BfVSuJjSAEIH1FgZBDaFEw0O15VxmheVNCm8UpBKUBaT5bSRLvo7DNSX8eU6Q xyUxAxHIP7JnBpo1tOZraGjt+ARwPyYucBXwBs6BENFOzEg4ixjzeHo9C4LDMndkPkIoCcRx qtjugpqatHtdPtvjrth3asy8MS8J5r3lRA9UGPfydwdg0Bs/yJWFAByocAASGK+ZS6c44CmC QdKr4K6JOldZKeMaYOYFV61CbCDkM25lkL8FW2HY5wtuJ0a+pa3yadGFrEZ9K52oT5w+2Zuh 9caZTKTkfE3lNuUsMr7N3fz6Tntdb+862TZSTVQ3tNBWLRy+QwtlIUzchV+U47JhKgXrpFQZ ggn9LE17s9ZFVDDIwJiJU75QbYJnJlMHEceRTUisQMLwxwY2cpXkc5ad4Wrm3iq/0gpLatCv 86YpO7XsMVn8AAofmpKDVymlvXAjFwC5SyirGoGR4jQ1tfkQVL9kMqTNNrE854zcWXHZIILq fTo4DM90RA41A6KZ1+0DpP2si9a9DJStrURuXU10+0Cf2IBF3TRkm3mCFGIdkGVH0ZTXfe+a KneItZVfBlS0t7sMK4hL3lAh2yj1lus7Rcf1qM3FZ5VlpXrVwEkBG9YFTMQ9Lzm1DYZItVkW QIs13ARZrRITNGCu9bu0wU0/JF5w96Il8BBT41darEosE8av1PAvaVnu2gFmPD2kLDWKotuN R5WbUp4GFKWZXeBE2CrspTDgBbvbcD+PpUYUI3QEkstHgmGzwdkJJzKhZjSmlhYqO1IuiLpx x00mG07VkreF7lXzZp18raJzZmwdNhSUcirwq75lkJltDVy29vQ0Zl8eTX/CzD6EPB/I7ZKX nreFn8wLWq4RJZ0+bX9guYIjO7hnBllV6ML7WMmG2SV806nfknAPOaorLWeH0qLOxZ5uCoVJ JEhQhnmWkbJ5iF8f11rJCuy5CazKs8EviFvAzL6vz42ECGBoSuzlN114Q8ZdFrGOAdvpq2p3 vWisFr0ctSHffZC44tms6ZZwV6ppPgQyyG9Xa+5LgwKfQTpJdGNu2le4N0d3Fwfl6jTlFN8a WJXhy3NcBLoclHXn2D1nRAwoQ9oDr7RmXpUtODRdxR1d3HUK2SWPWdeZWbCXALr4NNddWJ0f l8fmsidyQzrSRVMlVxbbHZXdOrc0jNAyWdrTZVldFzSl1ZnpbQti1PlUUFmQckewRKAE8kP4 zLiSSs7p9owa2/aEAzi1MsV0kRQMS9cXJzA+ite2YeNILGk+44EcRCiqMrSgkxxpJA+wIU71 qoIhfp2c4eAqCQgKgk3BQZbrq7ZZKlVs8pXSTHrxJxGxo1/dD64JXZofUY67bHz31I0hoqoi kVXHsoyZVyad4BjdsxsGm9LqbKjPUvpIDinY9Dri5fK0/v57w91LriV8D7zBenJuPau7OKy1 SvZm7plWFwabzeyqPy2iHHXXRSfiQ2pE+/SurJ7v5IQirdVGdvANwY031bYoi5s0u3V3Vu8H 7fHJRosXerbTBg9tb3F0WtmQVTzvECKHcIa4uhnTfqIhkAy9OOkrBA1IsTxx682pwLQ3vbUy HdxWtPfoGwUdExj+0GHWFG4uDvXty4qtOwenkliLVk+JpFimTegicIi4N+vLO1AKf53cC/5F l4OLA7zTc7d6CZOfWHiwpcgNPzFDlWh9XP1yR/2S52v34f7jL8l2f/y3+/D2LRn8S9L/A83q T7AKZW5kc3RyZWFtCmVuZG9iagoKNjkgMCBvYmoKMjc0NwplbmRvYmoKCjcwIDAgb2JqCjw8 L1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WyAtMTEyIDQyMCA3MDggNDIwLjEg XQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0 aCA4Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicAwAAAAABCmVuZHN0cmVhbQpl bmRvYmoKCjcxIDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoKNzMgMCBv YmoKPDwvTGVuZ3RoIDc0IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy1XEuP I7cRvs+v0NnAjPnqh4BBA6MdyUhujhfIIcgpiW0E6wTrHPL3Q7KqyK9IdksT2DCwq1WzSVbV V189SNm82NN/n76ezMnET9N5enGnNdiX9fTrP57+/M3pX0/2lP779acnEx+40y9PMsidvvAL 6dUvPEX6m579/PTjNzRz/C++f/mcpnDnl3D6/PfTt7c4bfz046ux2+d/Pl0/P33fjJ7OaR8f ecOc/IvfHfv96etpXeIew+zisOBMnN7b6WXuhf2aH5/z3GnIkt50+c1w+tsvT9/+4Zdwev/3 iWZ9QHt6o9ac45STWV4m2e7yciybW5MeJjNXCe+9Yp2Nq8yLEwXG9+MXh6/4Kc4/z+coQ37F nazL7/zlNbjNv1qzPbtXZ7dn/2rWzb6a6/YcXu01f3HenqdX403Y3Ku5bc/x8bI9n9MDK09D /jO/+imN8Ja/djzYehpjb2kp+5ZWzSPhVeu354VfmtMz2pedNhdHvG9lML3o0h7T7HnRmR/6 T3nIJQvg4QG9ZZc6cV7JXkQiK9J9Umv/9fMfD+ww2Qioj9khnMXaYAfvo86z9pOS5ijt85wl T0LQ5lDTJIVL9okbjW+EbCpSTNYlSZjtGI3h5MWsV5qdp72ypqp5i8LroDqxggZshrVv8gSe X8AV3BYEC3l+2n184VjB3n4Y6G5N41oFnwvQCQMZUHbOQuaPSdkFtyTLzAYhERrtWK3NbD4U +1wV8v9YjQxCePAN8L0sSj6V5uKX0FktuSntxt/RszUfBrJZIzW2enYm2Tn7Jktz4Y2J6CwL ue974RBWRt54/giKFodAJZPoors0461Swcp6IW16AF5hsrfNFo3md0hbeZJIhckndlUWQpSf QhmrLKSPPyapdlQ2JY6fIt/PRWUmfU4qmzd7zhZdkmMlykzbWJLRiKbmV+c32j+plVwyw2h5 pcH8dYa5EGmmEJuV6DLWHS8ThV2BUTLx+KQqmwlx4tn47ZmZYOVV82Be78q07JOhC4fn9Rzv gjAuc9IXcRVf5cyLnzfZBi2y5JfiVMdWWHwliAetsNgY2Vsr2FtC6soyk6pZWddN9E2bFLPk XSat5I9uNgu/fGUliBWiUzg2UxTrzP4rD1MEstWs02swzEqO/l30m7bnNytYcZvb1a8r7BHX lXnELbJMcbK84WePQMtqlxmzgXJmcGyDKVTyeNAGkxt4QswLCm6y9LRL3nuUaq0QJkWQ9O+c MuTtVzCxhWjCrBE0a54A8Zr+7a1QVFFBY1PWJb2ohmco5B2DZVgacJ6KmMbVxNC8pwKUQ+Ke fPgocU/e/V7E7VXyVB+4C0VYSs0Kh9eczp23YHTCd2uGqFREMfbMuWuJkxi024DCwqUJ+OMN UsLzHaTHsuGjSLd+D+lR5dHQLuZ+AGb6WHmWWZoBPSsauJAT08OWmgjwwtJxoDfIJpXaGhi6 wJTxPubvbEryBld3HQrMCb7kXQsHqRJL2BfvhNZwXj5K6iEXap2aIV6RV2VBpvKt+5S/vVSd c+iqBD/kw5yVtXyR1bGgoBDsihbKeMGAS9E9IlnBoGd0xkWxVIAFlgqXvE+XMVLtxTLkjCC/ h6lE1IETmFUmvWujZf2oK4RlHqU/5+0cFHG790wJl4zlBVOMGQOjqJz14ZqoUBXGfHBuAgOJ maIhYIOfSUq1yJoyWHIezfzkR4CaKxtgqaovW8pe629beMX0R8W7Xc2bCPJZZZHM3rF8mGOG uFAxEDgWXlkz6atEl+nvWAnlIoWY/WJCMoAkY0LN1nBAinky5R4B6u7MyySlLg5vXPDnzDpk xYdSnxShzMsyuXM4tX//6bun3JFZljX1pGJ9YfPnLyf6TJ2aL9i24X/QqJ+ffujaTS/TKcQa kqnBx3gnoEsGKm0GYUHjWAJr0jfRNR07UfnGTmaV+Bhfs6yOeU4OnXghDUpamlIgTg/fiJTp gfyDlr6xSp2wcH6DF+VthOEY/nyLEMvDDW+IV85y0BfvtApt3gp3pBfyIAsv067o+zeKxSwg zfq2lTJ2BqXd1NK2FsGsWtALiV+FoSnD49Lj9C6HOxRsInLj/YQ88Y4zRTKK2LCLNAsKNixp pAcHKO9IdyLVnu5MVV5RM2ozz/zOixlAEJulncZKDcyqSElAMjsnTA56DxN/tzJJLKi8+MYF tmHr5KgKBX6pOYlewcgTr/uIkRUcEdaUzCCcbnV/ol2lurwrN6FB7gHABCkGKwBu3DIBpUQs 1Ullr7id3wEb0VzvStEXGIFOKgjIhC3WKLq8bFPksXOP56jghqPyFMB1yqMBHKyhN8wKG+Wg p3vUVMnjXQV8vwinrqbalNSmmbiHQMvXR7b3ZyOBtNh+wGGMTgp2tui+kaaAna1BdF8Ivqh7 AU18Et8zSTIIPTGerAKvN+RKTZ5CevQV7RPBQJzgdeDJ/7jxvrXLF9w2HNhCQWFX4W1H3TkO +6Vl2r0ofABMNQKwoOxOw9/qkEIJWZLAO09KVl7HNl5zfY8639ED81rm0bfWKn1uAbqDDeWG /zimNR5wqZZlmHjwGVxJEbBjeIrJaW5GdVAAyD6GhFo9QF7kpbMBHmJYP3s5Eate5ivMIVOQ cC/OEHYUKuzUxhnEviAbwihXpoyBLo8ovgHrGXEfnMdRlgG74k1YABFHDch9eJUWxYN5mlRU YR4IwpluJKOH47nUj2hxXiiprkDqPQ7RWcShQcNZKr8uZzJVqQzOYeJoUnV3z18qCxieoA1P HQvwNghXCGwP0uFyoozi41wyPWyBVBjqIAiO+uyULoD1Fc9jIOliYT/EAysoZw3AZ6G+O3GL ozDY2PkKQMD5DmHgZ2nS3E+di3QOhdMKKORjcENE1zkj9mjMkrM6PtuoFVAWrHreiBCBuMG7 L9w91NbA3FKCOwYXkEFBVhuoRnqMQQPsA4SR7B5JdhxSkHIDGWPKbpQ3YpR4I/ZkrZ+rBu6F d+fkPKzgwa85wHc13LW6XZetq0TEKOCi/06F/dp8UlVOKlBCXtoVsZjTkCqvWcU3y/WzRKMm 43PF7cHNdtIFDPmTuGiJVHOjJVoWbFxR07oxVr+1TCzZctx6KqjQIyp1FvYApOy4je0Cn25g HNKFKfceav6HjQvxizduyq9FwpKPuS4vrTkKaW9WFkrHqkNcmAdiVG1uAEcitevMXPMLJtGS V2Ah3rpvNQLfRCkdFacS4WGQ6vNyV1GmcpkmUx5UczMACejjNqhj2SxS2h0Z352n3TbLXsqA WW2XRGGAHITMw4pl0JPYowN0ZCy+VVdIohSuzciW2gtZATldJ+EYSFwTbSg/BcQt+6vtUI6Y 0kLtkm24l1xUajGYC+V08Y69V9e1XAd2uhXJVwwFWlCVVDVRYkyt2GB6K3Uw+qjf8UgEo8IB ZAbQi6t+oPTcBYhBM7hYukdmWdIpZrqpNRDVARF9I+qs3sPJs6rZcaYrzIQcE45K2ru9FTev h72Vew45yPHGykVC6GK4qhgGPrsDA5V/lG05HQtMDQbTwcFxzo3cNHVdRj9tdtWxD6IrIrRr HO0VxJ73NafPDuQ5ajTpgwsmnjC2jsqg759jYBcqf+2XIkksnbqIxiFlW7ihBD1lTXFRiL5N hVllEyf3SbGW4GXypk6vVeVaalDsgaBFJnX0IFo99JNgu+7I3gYYwYadoi6UBcSGh0FmB/jE QWs9QQZPk9MCZk3o8ROd6Nz38Yir69M2t9MdSpGy6aF3be9SKx6eTRnMz7psV7WFRgodsQCA yhQKPzSuawsiCEXRAZCGf/tgpg8wdATFpB6DxLRXI2FV6vvIRa5fKjNdfXft3JhfrqJZLG51 w7ndeAfsFiM6Y7BCUfUstMyv2sHMhFAoAJtJBMKmHkkceNhx55twYEPXKtk9gRYWm7TJdIer bytARgIV8m730Q1rA9Ua6mGjzugOErOR5RC4ypEwnHTF2k6B3sLtAujcz48gUUM473ReNa4O zWvMbkMUzmbak9oqJURbtexvd2o4OJpTp4bsqBOkiqpGfVd7RGcr3cw0SKJfjdvURcHEYQSr gzDbNOfbk4zngqYLD54O8WKIfOjq3R272nXpWhY69UNmyZwmhjloMR1xeW0r0knuUU5pF9/1 21wYhixplT10u4T+9ONeMsQq6znAADIrPddtqIaGijiCBOhVtekjHGakDd0kkyj3DJHe6Xmh OlArFnEQOVNTrL8Gsbeq3J5QnSBA+nF71M6mK4mD286l3Awg/qDXq9sMXaVoy2+XivYqwqgW gJ5CIYzcFhwZFV28FpTd6bhuKe+mIDKB2U9DdhOgGSjyprqh6kASLxRc4RUODYFvXS/FvaDc kUHtyYwqFHDlUY1xyCRh7vpfeD5Ugtjg0ETVYpDS1kJNX53xPZ72T56xFrxPwge1Drqt7ihM g3xc+pzjeCs5gTrCbS84Nac9ozg4yG+uLXv3pDDc5aFxve+KexUopVjFw8YJw2+tgpr2jwed 7Aqq+B7uiw16xd35/vigRYptoRygz46a3KFnd3kPNvMlAayOilhSOBZfr20hU0tfJmajE56a +u7eH2gEPzSyPXf9rGHVMro1pu5s9fUetu2hbNq9RzKqRXY9U98EO4xQphXQXTnFK5qctFEG 10dwNP+QpaWjQfF9aW1jB5grpyLv6CP7TUU5sFJ77vof4Km6X1Wqkr3bqpppseDFWHEUVO4k w+gzKhkeF1GqV71HHaMW+iMsd3b9LZ4d/x1fg+6bsw+xG0usTfjsMO+AAsDApZbKMcpZGpYl 9wkDx5lLfYPdcQKQ4B8TFdOuJBuhBAoj4UHfqrlQlyQKm7VrtVJTBS2gEyDv7sbFHfvWn3NU +4b0iyoly629xs43puTaFmq13DFsQK/uNMshLZS4YGTNie5DSc8wicaaF6gBsDogghG14dRI c1CLMhdA8wt/V4AXtXa76KNcji7DsPr6nFHdWToy+DztXt+ZqJiV1Fmfk/QtdEldvQrP6KC2 M1ib/dwpdifb17oUnPg64z0AYMgvmXBzMQov6PCx9kTuboUUcq0IRVN31IfXRQXnkyxVM7RB YtR1nUdHgw8Whnt5nXTKlKkGv9LYO0GG2jAH/72AQm1ipLz+Xl2T7x/eHVn7qyNVlHpTRIkD 3qfucXcJwG5xhNdyMYHG9oWKI4em+2hdhoF59DskOYQq8a70Z4KvbDJihePEYwynxz2/6Ac8 +vvut17wm6+vp2+v3/2wzKef/nP69vOvy0T/E57/ARI3gBYKZW5kc3RyZWFtCmVuZG9iagoK NzQgMCBvYmoKMzkyOQplbmRvYmoKCjc1IDAgb2JqCjw8L1R5cGUvWE9iamVjdAovU3VidHlw ZS9Gb3JtCi9CQm94WyAtMTEyIDQyMCA3MDggNDIwLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFy ZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCA4Ci9GaWx0ZXIvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCnicAwAAAAABCmVuZHN0cmVhbQplbmRvYmoKCjc2IDAgb2JqCjw8L0NB IDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoKNzggMCBvYmoKPDwvTGVuZ3RoIDc5IDAgUi9G aWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy1W02P5LYRvc+v0NnAzLJISpSAhoBWT7eR 3Bwv4EOQUxLbCHYT7OaQvx/WF1mU1OrpAIGB2WmJn1WvXr2qHrs36P7z8q1zncu/9VP/5rsx wtvYff/7yy8/dP98gQ7/+/7bi8svfPf1RQf57otMwKlfZAn8l9/9/vLrD7xy/i/PXz7jEn56 i93nv3WfbnnZ/NuvJwfz53+8XD+//LQa3U94jmdmuC68hbtjf+q+dWPKZ4yDz8Oid3n5AP3b sL3sN3o90do4JOFMTzNj99evL5/+8DV27//q1icAN+WxvUtvvZ4jvR0f2o94wd4N9eiPpoCH vMuQvFomz88PDqeEPq8/DFO+M03xHXia8+eT62c4uWF+zT8T/Rzn1/7kpvzYx/nVn0KA4N7n 1+EE/exPLuKPPHQ6uev8Gk/g54hP8ywf5hjlJeRpQCuCw2Vwco+DX0MdDeW5m/ODC72c6ADv 5Vwh4YP88y+f/7h7vRjxen2oFol402wRf88i/UBTIPtVLeIyFtAiwKdI7pKP5BIeKuV/IeCB 3ulDnLMxbnRLNyc6Zn4Q8R1eJ9KVQZ5ng4ZsDZr4nm3HC0XZ5Jo/oFGSPEITDrod/0Ajet4p rw59Mz5k6wde2C08hTe6ZyyGTwhPwye4Hfh42rPn3TMYstFeQZzHTp7m6Ni97Gl3KyMYXx8D DQAjLwKhgzd7pwtneDJmGY7XDMcCGXxM50B35fXO6As+Iz2OwQyJ8/ocUzk5JDzGMQIhPo3A bMgdBPId0zzSnfLPgIcXzDDYKhrY9/QOljrxRjhADDMY8+DXYMEnjxcxwKCwQriGGz29iV9H DMrAq9mz8GQ9iwR2sAvxfhe2IQ4gT+WYKgvTmhQXNgpwgAQRTQ7HeO6n+CyeOcOs8UwAESAt gkP1f8OSF+FKRSrPESDhHHnAZBYIu4LpYcOmPfEET7iJs/LjAOzxS3YOY92wJwM64+s16pl4 gWsJDd78oe1SyMnuOdslS5wllZyFwGsGkV/pAoHPzZZjE0UZiD/HmofGOo7tc6mMIHOYIxht GLYli6iBW2MFxjo/oZcDb6hkhPaP5qxC6FHeQcgr6BCmLfGCr2MGOXglOMA7Hxu/f5qI+97h uJXxAwao3D/VA3AGeleSDlDpjm9kmLNCr0m/Yp0rE0CNgKkatnGKF3LpTwW+d0LFy/bQQCND OjQuuRtOLEL4NI9AHvzTIM8Jbwty79DhFHVym0UO1iJOAtOEYZSXXnFbDa2UYI3MV7+YgLgJ 8ajXijWDZi1mDbbsmXLDpc5ha9EiHjBk7puM0lkPQQnyo+msB8AUtkpnfphhEumUszOqR8lO mkoGFAFTq50uAqMkqUweT1VMUc6qKRCx7lWhUQqcFOyBkxGLLc1ZjHWczUFCUy5lsOx3rWKt kVdtvjJ5tmTGUO9Jm1MGHcXBVWDeV2rkhZirrCdFRZxCLnQ2ouLGCVckJJlajHWd1d58SKs2 yCqck4esSnnyVYygXshB4VVxJF7DvFxIvZlsHp2wkpf0r/bF41WZnQ3s79rXF/ZglULraFgk 1U1JVEcFGpldVyQHeQyHYx+koZLHB32Q4k4kZHVRcEO3v1YJRJgbK4RtmUBjBaUGTOIhXpAs Yt2qFURTd2ACCNaoG5/6orjy52Z41aPGM3IbEzwVMatQU0fLmQpQDok79sOzxB37+P8i7mCl iHmhZRCXJoXDd8qgUtQYmWDT5x5jD4hQMpyMtEl7nVDkcriA/Hoz6ml6gPSQnkZ66O8hPZs8 O9pn7WTLjlDZRqDMIjBIgBoa4ApBgLKmJga8snQeGJxlk0ptKxj6KJTxvs/f5EqOBl9PHQvM Gb6lNA9NLpFYfJBaI0xPkzqkPVI3+SrUgq8vT6V7sVSbS+qqBL/Lh1w3rPiCzJFg04OgZGer THksGKASPyO5gcGW0Wul6FTclw1ShQud0xNGqr/kDqQINm0Yrja1q6RM+tBHzj0bCmEa9+TP NE+xIW7/TpSwEJaTlRiDTYxqcijFS5MVqsFKwdUmBtMoqNiQdyqptHlVBqvmaZlf21QFNVdx QKqmL0eiqA23OZ6s/Gny3T3LD1O2+TBOxoxSl+NycIaLi3DmuiQ7motHYmu6L4c97VNaUUkq i0hmirWaQDuCgzoLev4wsgIh2JWDYgP5fqM8V2S9n2K3/vdPP75Q7zilEbvnbszz8fcvHf/O PeUvtsEsH3jU7y8/bxrjb30Xa188cK87w2wkD5KF/Zl+pwaGO2slVZ4kiHJjUYT5yQDchFhy /cDRtUgxxjqKRwJlFXBi5oWXrYuPNCFPg/JukefYQ8Yw8J4NvLibcvmAVCG9KNwkH8Y1h/f1 LdY17W0W5om8wSJ3wCEAbpTuK6sgYw+u+6lUSnwqrxuXu99BaFaC2fy5Mkor88ttaetiSz6y D/UTUFKkZkHywZgN7GfQOexHp3Nlk6Dmzyd2jZ/gvrnJShRFd+woRy9exOVm48CyJ5vUXk2s yAh0qxvUwz0wa5iK+ChmzTeM5m6DwOssDTT8SYf09U5JLyFe0HM7vswgmb1cWYES5Uq+4CiR vcQw7qrw9LIvb0fGgIrqgZnR2ldW831+zXHH4w0qbJxhN0NHisfxTjf5mmV4BM8wlqZyhWeq Vqyxb1wD1vXQIqmcpdpWvAvKDPkdEK8IBuYKbDVYWVAhwQJ71LCn84Sct32xinqYd+V2VqpW GsXd7movJS7kCdAwVKxgeGTDYdBv8aoNi612GBKKJ/d8ZyMCMCUlnQ16xI1xduN06x/GhVIC jvaVBRWUV7ryzfj9zinHddwCx23lBIx0PLSl5hp4EkyPrFtbmNW6eoVUYkHiRhpebRKrWWJk Wsv3UU+kfLpNWjEE7cRkbWpA3KAzmCoLsRbDULYQNLWZb8U7LKlh5S+peWPxm7JTZHIimW4I bsVMh+YMa6gKSeOZeGGMtELaV4tbYkUbPfetKYZf8x998L66SSNhJ6MI/TEZtwhSXyOKRDZC ResGGxxFfM2o1FziW+jSxqlSQK4GHIlDCS4jGtQBY4uchbj/0AO5oAt36KI4nMwOWQdTxdQP WBmQIN3qKdxeiVGy6w6aGpZE9i3wYTOHOSnHFqblbb24Cply5YndfcLGwEuReaNoEsZ8ZLed jeGrHUys5YExH/ieSrOuFI+Idjl0gwtb1sYVMDNdLZFxYVBYmHDg6maMhot0IizpNJy7n6QN cRcpAgxsq/guxrnOUnOSjTWxqlI+S6cK+z35oPgxDFAIZS9u77Z7qIzwudIYP1hGYFqAYLNK VYFuKRl+KIlfvp8UfhGQWPtYpIIKppWOs1pzLQVb2adSYVcJGtOAmIaLhq1eKBPoWDLDCw2Y ODROgjIcPfwAoj557eNUiF7kfr0hxGSxZa+R2hgsmbjwGjQW4YCUK5gs0FBQLbg0oVGNMhfx ulSnNWLnIHCEURu1ebZKG1sMg2QjH6lfI2xfot/yd2txe5BDe/fDhpn/x6LCcDKrj4J1q5kM n3HgXM1dL3NKp+glBeBbX9JDrSFammoxugmcQVxWShU5tmDWnLIATHNptN6gpGneQ9BOwAfk so9OWzbVyrwYlxYDcQCYcn+snFqFXD3/tohcGxZNmhmp4CcUfVNNpW5OjfBf1ddbmdvo6wYs ROMfpp3IhC+GVhb5cCHnfdwUxKaMq+uIcZWFt0aWRA3yVxiFUEonYR7qUvTIb+K+KQqlJtYr XTmLWRlhWy5tRluvtXgwblBclyQJDTOKM4ej7zI4ublpQ7QbttvoHhXOmtGbhyypvfGpLHOx INsrC0fVvMSVziiPA+rfrSZ423AEKaIVkf22dwH7HFPbDqjJitePgAlT2PQf1wL/QT7fF/XS dmmZosa1RiKY+v+8y35tz8Y0JW8bF+nl+Y1DMWNTgYkN2E5uVC2nwtUmN7ljDTQ5U9Hlq2ba 0sirQzektCmjDfmtybQ4V4WBcmLTfHWhOqaQgGv8YOyyyjV8HdvW4bpw/0hjUVh3mGHFSKs6 lYFcSO+g7lDfpKLrmtK0XajUseXOhz4YYMvRbQCvE0o092IeYyAcsRnEYdPTw6+RNADQOOvm bWvc1ScW+PhtX65IkRRbCsmKxcMYLnPYFbzNHRqVWhBPrs41l92Vc3XVQg61UHCntWHaeCAI GQUs7YHafd3W6q9at3FHoX7dcejK4LbV47UKrQygm/yFcLKU8j73sSWqoAW5/NXbph2x0+gz SnAoJbmhoD3CJvG6bm02oFv1KiWtiYuabxVsP+osJb09nitKjBoWZ5tFYCU8oSHgQ5tD3HYC 16kTvzr0bfdkk28Z0IDf80mWb4bORdYuFfgXopWIGLeDuaMPwQLcUIjKqx2fUq/bZPzFtGdY B++pKm2hX2HdVxyMewYtrUr3yki7j8B72tBU0xHl78PuFyA1OisYQ9tfN98GUSoN72Vo4O9e 46a1XTskVpir+Y/A3JJdYXklNoZAJZfHrsO/s9mrdlNTMmgmlyLpgdHHsFN95lBPVspolizf sNlgqyJmEfaT8DRK6kB/rggAvy05/GKnuLndPOLfQoczO5FsaXQ64J/ecM5PsTdnWJp8a3s5 fblC03h9mG6HtKVoK4Xb9pRNqj9tvpw3X9J/6z5df/x5hO63f3efPn8fHf//Xf8FPVnNfQpl bmRzdHJlYW0KZW5kb2JqCgo3OSAwIG9iagozNDgxCmVuZG9iagoKODAgMCBvYmoKPDwvVHlw ZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIC0xMTIgNDIwIDcwOCA0MjAuMSBdCi9H cm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9LIHRydWU+PgovTGVuZ3RoIDgK L0ZpbHRlci9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJwDAAAAAAEKZW5kc3RyZWFtCmVuZG9i agoKODEgMCBvYmoKPDwvQ0EgMC41CiAgIC9jYSAwLjUKPj4KZW5kb2JqCgo4MyAwIG9iago8 PC9MZW5ndGggODQgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nMVaTY/juBG9 +1fovEB7WCRFSoAgwHK7F8ltsg3ksMgpyewimEkwk0P+fsj6IIv6sNu5BAv02hJZLBZfvXpF jzlD95/T9850Jn3qx/5su8HDeeh+/P3055+6f56gy//9+O1k0gvbfTvJINt95Ql56lc2kf9P 734/ffmJLKf/0vzlPZuw49l373/rPr0ls+nTl8nA/P6P0+399Hk1uh+zH8/MMJ07u8Oxn7vv 3RCTjz7YNMxbk8w76M9hu9nv+HpE23lIzDMtzvTdX7+dPv3hm+9e/9WR1Q9Er3UUzJhM9iae e3E3nu/vzQ45Dr0JdYePpoCFtEqIVgKY5qcHd6e4PtkPYUx7wCm2A4tzfp1sD8G8zjBBP9vJ +Pmln8x1DhPE+WWcwMy9PHVp3EuYTHrBw8Hxq2QgTjbSKxPw74BvbvOLz5+BP0L66/Q6xuKI 7AI9BZ9HZPs9LW+vOGWUlXgBF/OD9Pcv73/c3bX3ede9q4HyOQBf8pIHgeoDToF05BIok5CU AwWXHJ8rex94f+B4Z8PkzAymjsh/I42kR695/tv8EvP6MilZcfI0zoPsMk/LcYgYB5/jkHac AxHzELSWP4Zk04FaEc1d+cz4e/Ixj0VXoinR9WIkkkV6EfGv4SOmuKcHtpjYdcvW47HZq6Mj Iew69zR2ndnBLqS4WYYogcuZBdE0MrwyDhHclmNkcYcFnTSCEIgvPR9VxnnJCnA5xn3Fp8ck GDlnyMhtloky52P4BP80PlMAtvi0JvuCJwohx4U/94xEPuPAh8agRCTqgThCzU/7Aj5+jQrC va8flzyMoOF5cLGp8LhelR+/zVb8yutxQrzyiUQy4RCbdwKK6OpH/yy6qCZtmNHkc14qaTF1 ISwcnzqRQEVgITbClWOgENPRO+RCGkB4cgRAsqLwW0D7ghzoBZeemJdMkPkb52hhVgL5uPau GrA52mnmJX9wkyVKvd0Hax/7Z8HaR7cH1gERhjiIBApnNKYUFhC4icLATopONVERaBfaOGKJ x6wBWxAUCkMXaEcNtXKuUXia3MLQP2DkzAC4GNSEsky0aJurgiLMaGEG9ObGwL8P8b5/GuK9 /T9C3F6LWV3jlZIoo4kHLB5n80AvWGkWBzCZI4TZ8los0EfyvyROcTL7y6twHXmQBy48nQfO H4kKRgcigcDGEEznMSgmr+khZRbVGNX8WsILpm0BqzLAYgCptUFpIeqY5kA/FShaek4Tm+Eo WNBjXItzxFYxc63D6N3CWKJj72sFUTrkEfghPA1+cHnc/6QedpSrZW2sYW5VZqgpRMkLW79W uDsCLuvmIjuabFASgsTHXUz6MT6LSY+9zT1uVhq30ZOFpyPX84xah/P089eCCkRVlZyehf9Q xQe9tJWjV6KWiNWT1GzpVlIHtNQukrVAkKpho3wJt8px0rJLycKPaQ4f47OY9NHvYNLnwDiP tZj+LuJbYtFlLrz1htUHJNagBKkIh9Kc4VimN82RwoDSy2z6rJTspSUkxI9zoyp0Hmy7u9fi Lic4g548tbMXqi/ScE3FR0EfczELqXcOJYIUP3MhzktZlVwhOYUlgACDRn1JL95d4Gk35FLa irzmspS4Inl7gSvmo3LMnGNvR9+t//+nn094txDjkG9XzHAG/Py1o8905/BVX0DwFxr1++mX zcXJue98vTdxdBfyK1JyrgPWYYYgdgE/myV5fsHv+NTyU6qtAByShd4aXzMynxIEc6PjKIZJ TAVSWS/YzvocPJBkpr9LOkDxhB9Fruf0DcSHNDebNuk7UOx9XcvatAHgIWFrE2hlNQMfJL9x Sh4lj4Cn5C+25yhIZA5QFkMOeC0dJeDZL4oDAHhGkAQxYotMMeRHi6UTSuWFY4t+L2lPfXsg eZe7k/ykNrBakba5UPgGEviMAt8EZz9qaViPK9Nn5QPD5TJLGUQw0CuLy9+LnEv1aFxFLlk3 CTuu4iQfghht9h91EAV3Jdq0Z0GhhNULkBn8i0IFLSkL6bikZfU04gDwBT505ZUhmJmv2KC5 pH5CmXvVmbW3GoLaNgcnY+9Gcyg9f40mCRgovua0CgooAlKNnZTWRGa0Z0zgpUAjpvNpQtNS BPQ4n1HLjoedczR8MhJ5UNSw4ZRKCnq1HYK6kvU5TDq+KaIqq24GJLCsX/3D2IYgN7Yltsr/ DMq9PJKkobaSwNmgrMk+TqZIvuamOxS6urHhSJc3q6ikdrFEwAk5p01jSi7sqN9i0w1YkRkc /CYkc/o7rDObQGXtHCYN1KGe99sHItqbDWvupJfCZMNHQIwnm15KBm1BI3WF0hTR7NrIcEpQ Izg0FARTrY5Q6h5zqIQEiIvoYPXw2CS5r6cEoEO8LnlEGfYND+d1dkbGkddSnWh9VbxxvceR d2skS/o31QJKcAvCVWnEZwY8o+PYvwK6A5dQszgY5deNqlmSTq2JnnPJ9k1R81L8IJRWQXMQ aXv2FL9QmUyGJDOa8F/oVlGhKm4SbV0XMdu8JBvtmnSgKgC6Zq22kV3TRtsSJkXc7BWpu0ds 3IauSqmuxRHKJpZ1gdRO53BypjhK+MYXQfmqKgwFJ8xkS4aCAgRWOmj4sFWfhdpFUN5QtyXa emuGNdkzYPakMZecPdYnWW/j7FbFjBlMhJN4fi+mNknvYStWjuQY9ccvK7iArLhof+hMSlk6 gkryN5bKosWsQrqhKxk45K5FyXM/VQJM24BytDggM+4ax3QRygZLomOa3I1dtKmh2ZAOt1sJ A5x2gX/6WoUtDb1RTWehb/ZQA+AOhCEYaS4pWdNOep6iqQRwInWXVYlpjkgnYnC7TVi4JMsc p1lKavrGMBHSo7j1YcOLJHHS+XEnquQ+7FdwkcKapNUsUV1hbzR3iTstSy6QpZfSFTol+D2u t95IT165CUudYHI5SgDGhE+pcsuNa+O+6v1aMU/HiIdEVlyBng5SZO24J/it4nFhtkhlR84Z d2DH/LMJfbyu6W7TXPc1z1RNVRLXNCcCpUyLkL4LHes3vdWabjeGF7k4wubeiMRgfpu5xybk MpKTRbftBZv6Inissig9aRV+A8t1X7DpThgHF33CemfrJGy7vaGxzRVuN0sptfnSgaX3g6ib cUN0GN9aPl9LZ7VqdcvuEDGEngNAC0JcAKZ9ftDUYOE4wGuapSUtza8SrY3Qh9Ivu3YFJZl1 eYtVOzZcwd1W8Si0vSeveC+wMLrNrVZTfSVnQKnytqGivC3VSzWEuAVWKR+hMIhxe+NDN5Q7 F077xaVckOBpWAnFpdzQZJnK964brRPL+WxO7EOdvi7yWlsKSkt35KdqZU8fVKw+j6wPaK7k 3YbE1nKvVPUSGxE4DxqTvXsv3rNX48qkDyHDh80dzF6Tvb3JyJECxyy7W/9IlM8q2ZLML+Am 454llCI4zbGtEABMl0YopYDrK2Il0eYwtd1yptXm5tiSRjiU85u7GtAa4vYICs5sb2CabEBN sEPqdC9XaUtEhN8EZl0Ij7o+iz8pYVthhw9kOoEqrvrXq74i4Jt5OQ4DO+m+bswPWseiJuru H8UW/PYuxmE4JGwH/WxbZ9e3MgP92424c5X1kf3vAZZsVqGv8qH2XdeqV3qlEVfrr6K5e6gb VZO92P7I8EjHj3u33PomZZPmRYKsRCIj64iRW+C2t0y7rcgw8ZFRD4nv6gWBIrvPm9+v1O9Y 37tPt59/GUL327+7T+8/hp7+iex/AZgPfXsKZW5kc3RyZWFtCmVuZG9iagoKODQgMCBvYmoK Mjc5MAplbmRvYmoKCjg1IDAgb2JqCjw8L1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9C Qm94WyAtMTEyIDQyMCA3MDggNDIwLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9E ZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCA4Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnicAwAAAAABCmVuZHN0cmVhbQplbmRvYmoKCjg2IDAgb2JqCjw8L0NBIDAuNQogICAv Y2EgMC41Cj4+CmVuZG9iagoKODggMCBvYmoKPDwvTGVuZ3RoIDg5IDAgUi9GaWx0ZXIvRmxh dGVEZWNvZGU+PgpzdHJlYW0KeJzVV0uP4zYMvvtX6LxAMiL1sgHDQJzHor1NN0APRU9tZxfF TIuZHvr3+5GUHY+zSbvHIoAsS3x8/EhKjt+S+7t5dd55zFKXtuzaSNvWvf3W/PjB/dGQk9/b 58Zjg91LMwmxe64KovpcTcjT9r40Tx/MMn7QH89igrttdOdf3cMJZjF76j0N59+b47l5XEmn TnB8i4Z3YRtuyj66V9cWYIyZIRbZw3ygtM3Xwb7qdqe2RaSIJqtmdL+8NA/fvUR3+NOZ1f/A 3nug5DuYTL5s0wS3bO/Hxq3wkHy+RPhvKsQEL7nwRCD0sXBXJSTYz7lDDKrCjlh1fuq5HWLv edhgPAzU+zhsUs+d7+RJftBhwz0lWcA2977VvWCyPqiUH8UGpCAaQpGd1cjVuI0xmYZ6ha39 sCGxTNWfP6q96oQwhh6gSBQ2ufdF5LEt6u9d/Hz+/qssxCgspHAhLgohTxL+DeJSVhVCCUzE eVSWEBe9wjgMTD0XRbwfLLgAXAJ0r5gBtwh+tlXBGupYhcchaNCkJM/LOwknIUGwjYToYmAZ uaOTvavPqlX8SVwxIaOzl/tkhIh2+DYyglbOigzDmoURizQNlKaYspJzmCVsivS2FX4Q2Ign V426dwkQmKgSaWJSLDzHPbTCIa0zINKj1NNREB31/WBpkKnKtjP15vRrKcr3iqpNOCQy2jjP pFhj+Z2qH5EMYh+tk0ZMTkrK1DKSczhVgoSmyN2QyvR2EHjMClXTGyS92AkllBWqLZUcC54x Bgp4FkbKZpwkh5mvpR9cVzPnqfZ/kBGhBnmP3qjNspLrpnEdZaBo1EGw0/WdvIxmKk+V311U DiBClMzWwudpIF9t6R6IEXEiFd9fXOPcCyKL+lJG1aNqk5oLukzJbFU8sIHyi7MJXVcXENUw 6HaLKGWxm2+f/yVpKBKR5aVVcVnJxH61ZhITi9WBdOtOjarOkkqV2GnHeyVSCMWjvcUnc+cS 7qCwahS7CKgWu7bC8i6QvpRricMQ2iqU6h5QzM5Q74m76NbPHz42esuX0sp3jm+RVJnjO0fn dvs/Lz8F6otJfWk+XX3C4IKPXKaWD46sLMJOj2rEM58z0rdyYGU/6hmJc0rYO85T0ImACakT KfZ62Y2q7QtFndaMFrOqK6YFo/XNykmOjJMszM4wEGUwNZpC8QHo9rIevd4sNlKocEbgYLvq JYr2Koqx4vWxapC8yO54K/MlC2G+uyJMsalBwRXUid0OVmTRnFpgthSWtBVTVo0RvJvgKKXy nt6KG4VT4FESFGwnXvhWniyOa0Vv3JNSV6Go7wnb/HEzVlpVsLNhkl7kHae+BX+Ps4CP5TVn zBavOgY5xzWOal/vrcoW6ZFUwEv2/aIOq9Z+vcBT8SiTdXFZLTXzc7DhNm+mHO3zEUUnP1tD KrC+u3C5KHBzPGVNVUmjqF72l5gPF+4r7ruUlnBdhjNKdZQM5VwZU0hTJAumpvI9AmrW3pnq ZOJp7k7rJrnDo90AM8rHqzNrcXa9uofjx08duc9/uYfzW+ftD8o/XGj3rgplbmRzdHJlYW0K ZW5kb2JqCgo4OSAwIG9iagoxMTU5CmVuZG9iagoKOTAgMCBvYmoKPDwvVHlwZS9YT2JqZWN0 Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIC0xMTIgNDIwIDcwOCA0MjAuMSBdCi9Hcm91cDw8L1Mv VHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9LIHRydWU+PgovTGVuZ3RoIDgKL0ZpbHRlci9G bGF0ZURlY29kZQo+PgpzdHJlYW0KeJwDAAAAAAEKZW5kc3RyZWFtCmVuZG9iagoKOTEgMCBv YmoKPDwvQ0EgMC41CiAgIC9jYSAwLjUKPj4KZW5kb2JqCgo5NyAwIG9iago8PC9MZW5ndGgg OTggMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDMwNzAwPj4Kc3RyZWFtCnic7bwJ fBRVtj9+b92q6u7qvdOdkL2yEQIhiQlbAKUTSCAsISYhLA5Kk+6QYJKO6YRVJyxCRFBASFBE yCggomJERxPEHUVEXEaY9xj1OSrK+BuG4fmY0YGk+J97qzvpsPgcdZb3+fzTdPrWrbuc7Z7z Pac6NNQ3epABLUMEOctrXHVr55XlIoTeQQjbyhc0yCP7Vb4G7d/DW6mom1ezcGGmGyEC1+jx edWLK7yH2wSE+HUIpb1f6XG5v652ZyGU9Qu4P6ySdii1GrjeDNeJlTUNi2ojhqfDdQes16/a W+5674lbdiE05H24f2+Na1Hd19xyHqGhc+BarnXVeBpfqp8E18sQGv1ZndfXMAstv4RQvZve r6v31FWc40/C9Z0ICZXQh+FFfwzQFOk1R3hB1Gh1kt5gNJktVluI3REa1i88IjIqOiZWjotP SEzqnzwgZeCg1MFp6RnXZWYNGTps+IjskaNGX3/DGGdO7thxeej/8A8eijrQUXi9ivaibXg3 XFVA923Q08btR6tQI/S8jo/iNdxg6NuNzqEPYWQzOkr28ghPRFnQi9BJgUPncSl6FtbIxnac rRF5xBfyz/LFfAd/mj+GhvM+/hg/h/fhLPKwUCbshnc2eYOzoSMoFnXgT5EPHSBfkyxykB/H m9Cn5BjZi76EXUDfsMd6tBMtBVrs2IuauKVcMfQcFo6hrfDywv1jeDv+EKg7gFeiE+h+wnMT 0HZ8Avg6iv6KVpJSrgnsMourAPoPw1rHYP5W5OORcAJLSOEGQR9QD3vNZb+jyWDhBHudQ02w cynaKXaIdk0C7EIlthu/js+Im1Ab+pD8gtxGPsKr+AR+Dz8BrVclQOag9bD2VjpHrMCLgXf6 WkpX5xbyc/Be9DU/RzMX1n6DcgR7PssVA0cV6CC8F4oW4GkUXkXWAKX0bjQ6ppnIp8N8WEFz B3CNkJcMRfOhtRTtQ/vRYNKK1sNKjF9xuPBXmLmN/wx4Xo/v4f6KjpFxKAVV8GdB1siOUCtC z2tEgSccRqmypZ1LKnC3O2+cIb81M25w6mWXskUjt6OiduNiuePSpaIZfKQws12IaidJ2nY+ KeGza938bHDqpKIZcnt33jj/qnlzxkFfyQxo0ivohv68cewe3bRdSIJ/BXPa5fJK+W7L3Qkj 77Z4Rg4GsaEKpZWvEHaCN9KgCKeBv4jEi1grNHE8Sj90/Mx1yHL8zPEzGSHWOGtSnDWugkdd PhLZ9aXSqjF99029mALnfxxIb7dwAhnwUmeBECEKOknHR0g6EiHpJS4Cc3q9JFo1Wo1g5QWt VsNZCWeA0VZwG7mSwBGRoKf0WoNe0mlV4ek1yGg5/k5Y9nUoffSZzMyw7AxgT2MR/qSxaP1v ofdTbc6M349MGM92fiNyosBJCF42aYCQKMnSDdwNwhApQ5rMTRFyJac0k5vP3SrMk+ZIS7km 7nahSVgmtXItQrQG6TgtQbwoIAGJWMNrkVajQzpekgzIFEEcvEMbbrCYZD5OkEVZI2sTdIlS kl42yabR3EgylM8SMrTDdNn6MYYMUz7KxxM5J58nOIVcMVeTq3Vqnbpx0hSD0+Q0zeDKtDMN RaYKbh5x8XOFOeIczRytW+eW3PqFaAFeyi0iC/kGYbG4WLNQW6ddZGgyNJlWc83kLn6NsEp3 t369aQu/w/SU6abZaHZIlg7TfzhBhxPGvYNH4uwv6K9jyhpFeUN5TRFOXLTxZ+n7wiDBcuEc dVboAMQSt2hHIWiIM5zoEDFhsdlk7TBskTCnRYVGnVafb7d0nck8f4Yp4/yhM1Yb6GP/HAfI GlsTrEP6J8SLDmhkWW/AWZmhvLvj9ttbnujszH2m8dU3uZ3dv+C279j+0s7uZtHevd3j/jPd 93qljG/i5yAzXuscq9FyOisyS1a9hJDZZDUjs9FqMCL6YTKCERmsYEK5Rr3OgvRCM3nRpD9o MRkNkg4sR2vmzXqL5fikdql0Uru29KYZnUiPnCNmTmq3l9L2pVdGzDx0yEqNyXIK2LBmW7Nt 1zYo4U9hmTPjsfOciAStqCPGUCnMaDEmGIcaC6SpUqFxlm6WNF9qNi4zbjLawMZ0ol4w6E16 cxh2cBbeIoRJdr3dEGGKMCejRJzIybwspGgH6JKkRH2iIdk40DTQLFuHo6F4KJfBZwgjpGH6 YYYRxmxTtjnDmoOc2Mk5iZN3Ck7RqXFqc3V50nhjganA7LSWohvxjdw0UsQXCWXiNE2Zdrpu ujRNP80w0zTTXGStwBVcpVRlqjLPsS7VLjItMq9Bd+tW6VcZ1hjXmNaYH9C16FsMW01bzTv1 Ow2Pmx43t1vfs35qvWT1gA0JJjwID83KHDYGM1viNhVuvn1T9eTSrDhl1Ov4Znzz65VvLdk6 YXUpX9i1mVSzgAfxBvFr4fzrUZrTIbbwXAtarm3hn5QErNOQKMQbqP0cP3QIDOjMmfNnLGcz 9scawXpC4hzgU9T3EdLeHcEd7s7mvuu6QTixV8nf2/3F3oCNaqLBz8ejWc7+ok3Xz4zEaI3D 0Bwtk47Ig+EWDbKatVqxyKo1F0X100bkJ9ANu7q6wFSZCxl96vzoQ2cymeE6QzISixLrEjck tsHr5cRPEy8l6sCSme06gu2517AdqmGn5L2y4qmXOusb1+/urF94z+7OzjHti5c8TtbcvuAv n1Mz/9U2aubc9ocffPmR7mZ+zr55c2+nMuLQ0ktf8IOBBwkloYPO5PBYfZjOhB4LEztNVnl1 7IGozoQO67owAwoj/eiZiyVae15/YOOd4+D/rNmUjUOnzneB9N48aznrt2FnbUZ0RkxGbIac EZcRPybZGe2MccY6ZWecM74ouiimKLZILoorii9KrkteFd0c0xzbLDfHrYrfkNyWfC45JjA1 MCkwYU7MnNg58py4upi62Dq5Lm5ZzLLYZfKyuH6zQU4gEnsomMj1eLg1YagJJ8T3HzpkWFbc UCYuzVAmKu6lT59Y7n2gs6NjzMG7njjafRFzj26Z81yp56VZ/3OOy6pYOtd38tmUyd3L91a4 Xn34xVdsTWvT0vYmJ3dRWb0KSl8MPonGpEFOk/gS/zQ6yAlYy6N8raULAgII41TXmQyn3qJz 6op0c3R1OgHMKYvpKuHVDvjh51xsE+1fU/vpXS/+ebSFw1qUz4NkqTVmOI0W8M1FwhyhTjgn iOoisIBo/9sZSouF4lywbQ4095ozB1kx4gWeswoCj60SkZCVQ4RIGqvAi7RTZyWSlt7IRUTT gslynaDTAnajiEAnSHrL8UNqVDt1/EyQExKCA5nqinqCmmygQS3XjM2cWWPWmtEMtADVoXVI p8FaTiQ6PhSHc2V4BldkmIcruUV4AXc7qecXahZpm/Fd3DLD/dwDpJUPgwOuw3E0QpA4ksAd VM5yScrSL7ns39zVfctdJwRTdzjZd2EQblKWM5vdBzY7A2w2BKDNKGdUb3RYJ+GD9g4D2Kld XwhRIt8B4jyfreoFXKw/RDzrdbzi4ECkEBmYyQyFht9k8D4aJJ7s6Bj7dOOrb+H38AFud7dr x46XdnJLL7Y9UVF+juyhuhsOhHwjbAcaRjjDTYLWTB4DHRzUNkt6rQ5AitZiM9H4NPoQ/Mtk x+SMetazIUY9pcYo6mLsoaOwg9oqUJBlxQvxUmXVJN+LL554uLlZ2K68tr67bU3h1h2/4eas xzeoZ/Y24L8J+LejSFTnTEQOrFutvUtwPIaFTgN+oV+nrcOwLirSwWkdWjSJs5nzoqgczhxi Xsdy6vyZUxY4q5bzZ630rKaMia6Lbot+P/pctDAGjcFjuDGOMZFCqiZdm65LlbzIi72c1+GN 1M2+Dah2xMXASRo23AHykpHVgrIykSYN0zPGN3XtNxx7fv7hueXv36qcVw7jlK7PsaaD23XX 1k4Td/Oslw4PGbJvYCoegSUcgscqnxza8uy+7T3xnul0WN94f/Dq8f5UjzLnON6jysRXc4zX jPjgAmnAx1SW5DTsG47GOCPRanwXb1ptvEvqtPKdYeD4IjQ2I5pgz4uwdJ3KPKMKz6KcP2v5 y1k45eZIS+SyyA2RbZECFQwTguqEmHTiqXTiMkPJ6cKHip55881nih4qnLJrdrfyWzwYi9Me 5oc+MWjQF8eOfTFo0N7ERHD0JmzDIxN6dNwIdOlRGJroDBE7bajT0GFb109nM99IbI68fkyl foqAmIQx4UvRUrFJ06Rt0jVJTfqlhiZjk6nJ3GRpsi61tYWfC7cGeUnwismZlD6VSs63+YnH WzY98cSmc9imnD3338qfsZV8evrIkdN/eOvw19uUt5Qzyp9AodmgNzseEYivYizF1+hl5xBC gTRnBWWpQBqwNjgiSZcraTgCyPUprR48DrgbQRKj+BskCL9GYAFCoep36NG4OpwGV1PH8HMZ oW5Gx0kOzq4Jkfpz/TWypj+g6CGaoVIVdzu3VLNYWsat0KyQNnChPNaTEBxJEnAqSQaUMwSP JoBrdR7tfN0C7WLdcnwPacEPEjvFqHHggMBucAKY0RHQzh24CQ9+Q2k6qjQdEk50acl3gE1j uxCPLnzWo59Z4LstKIp6gIhOZLJ3Ctp1pg68hYTB+efGW236vGimpUzqgM5Qk7UcOpvx3JyY ZTFtMYTabMDvcOwcheKAbsCQyMMdHSOfvv3oJXTp6O1Pdx9+9L779uy5775HyXPczX87s8ft wuOwFl7jXIrj6OnTR+ENOvGCPR8Gu0lGp52jjQbOpC+JjQGPpJFKYmNjciV9TCzvADtfw9tX O9b0o3aeBHY+IEbSx0ZqUHGk1qTR2uPzBli6DkGCdQo8RHZ2dsDw/0IN3xZQk+lPoDEN+01z nGSqo5ooKUofZUgDx5GqTzWM0o2SRulHGfQykgFxDpAG6AeGpNvTHQNDB8QMiE2RU+ISk1dL q/WrDauNNmpVHCdKop4YiJGYiJlYSDiJIJEkio/WJaenjEm5JaUpZVnKhpS2lHMp/UB1t/We u1gcgx12EZxp8lDmo0CQ6TgNUxgAp3Bt4Z5Za9bM3Tzm0K5v/3PW69UVb7pWrPM87nz8/t+/ W/EsP2bfgAGlpc6CONPAB9Zsey4h4aWhQ2feOKkoyZzYsmL7EzGq7z0A+cFOkC/V+w3OyIDe O0zr8IvkYDTofDzTfj7VfGamekJPBVTv1Km6/30Mj2cn9TgqOIEcjT2q/2I2gH2dnSOfXvoO unTpnaVPcyNA+4/S957ufaK01+1SDirfweugC/8xoPwAJiUTgT4rynDaRchXrXrSbOrQHdRI IqSM+TaqVxYPIR4cf4cGgGeLQnaEUA+qyrHXfYaRibEFqdseBUoOrApJiyLP2qxHX+reD86z olwQ2H7Xg9+m+ZKILjqTiZVhEMwJ9INwImSqkEyLuRxBLwuiQE8/jzRqTgQpEAqkQ5PaHSw/ QiwnYg7hTOY1nAF23jsBsmSaH6/mlnEbuZ2clm6kA8DhgFgYQSL4/qg/TiEpvKwdCtnMSDKS z9DSnLeAFPD5wgTRqS1DZXgmmckXaStQBa4iVfw8oVKco21EDXgpWco3CkvEVWgVXkPWQE67 WmxFrXgLt5Xcz98vbBH3CI+K7dpXtJ9qL2lvCOS4OOF6NRVRfnGBn9NVSp642MZkVAYiGAoy MuA/OguEaWodYpqkI9NoHWLaD6pDvHyVOoSaWVpLb5rUbqO/QugvvSpIKlk8qd0AA4y029Ir 37+7fIGdlwQulAsV4qWhUgFXIORLTukm7iZhmlQk1XK1QoW0GLSxWGgSmrkHuPuFzdJB7qDw LneYvCdEC5yOiLxekLR6HXwYHFw4CeUjhEhtpM6udxiSUBJO4JJJHJ8kxIvxmiRtsi5RitMn GLLJMH6YNpvWK7gJJJ938rn+zHOcbpw0Tk9rFVSPZVwRf6NQLBZrirQlulLIOsuRG3u4+cTD zxfmi/M1tTqXfp7Ba2pEjXgxdwdZxN8B+m0Sl2iaAIwu1jXplkoL9HcYmrm7hPWmLWgL3sxt Itv4B4X7xfs1D2id6a2GHabdaDfeye0kj/OPC4+Jj2ke1+40PGX6Nfc0eZF/QejQvWw6xL1O 3uHfFhYzm4jE9B9O0OOEso6vvjz51Zcdykcn//ubk2AdrWQ+fV9sI61d88GvpMM5mgjxxAFI pNhpjcxHYdpQs53XakmoJE6OoEgyk2JJizIafIrTpgXAaWk29Xsp9GnTFh06KOD00V9lnlUo sDubCeDkEsCSDQBPLAycwKmmAQ4wJnhDhjjFaMilHQn8xE5F09ne/uQzne3lU/DfOjtphkI+ 6EonH6wvfP6pB4oqy/F+lq+0K99wS0UbMqLhTrN4P9piMmoQsYkoRDJZPqb2ByYmUROb1G5m bWqFgJtYmgj+MAOLnMNuC0vozw0dYhvOLV29YuWqttaWzVtE21fKDadPK6O+/CN+8/ef4kNn VHyBNwG+ICjtefQUhwEyQH5EbTlg4WquhJ3GDH+ytF7YIYgsVzry9tvCiQuDKN0gW+47Vkua 6YwSLNigfUzEzUC+eFDiQjRIoxO0RrN+sp0uzhyTv05j6qnTMBh/yMZw/KnMLkBcmXCRgZ9z OoocbQ4y2y9RiugDUs7ivqMSTVc+APHue1G0U1GuV+X6wuOgc+BPaAf+tOCt05wO1AKYpMWi 5SwSEsKNmShKx9sYfrCqMRgyiDMZ++eEsNwhi2HvuKQ49pmC8abzeCiOVT5Tjiq5eAfej1uV SqVIcQnpFxfifuDcU3HYbmWLskz5pdLK/NJO0KeX6TPWadZQfWow0tv4EC0CfY4+36u3kKxQ m8POaRKG2YYO4XaCylpa21atXCnaziijP/29MvKPX+I3Tp/Gr6nYCGLkLIZdBwB2TQg3ROts q0NCO82ks39CR/JBXaf5xYjo/uFIaxgv2mxyXgoNSn6YdOiUCpSUEzQ7yQa0NHDZwLaBFC0F hccwCxfXE+avx34IZaNBa2gWeXhXy+Zduza37OpQlAuuJ268cXvxr5/N3n/7u11d796+P7uD u/6tjz9+6/DHH/9R+Vz5OjrmmdSBL758U/lcPBITzOORc8v3Uvn4Ln0hJAvn4EQOc0YYf2Xa J7VY8a/QPr4lbCNNDcKNKMNuiaCB3g/EKRT/69mMZ82RsZGcPyVQ9RScMEFKICRXnF5xCSnn sAWjFacr5v/pTuVJZQlejUtW/0mYe+KWm5XDyn8qJ5XDN9/y4YQJoE/IoPGO8UxvzYA9Hwa6 ktEv/RiPi/GDPK4X5GHk+JV9c78WK9+CNidt7MV48ZHhpsGacHv8AMvHhwCAB2O8U4wBy5vW vhjPEgB5ZjC02c/FpqSnTE0hsy+HXnzcldArkeZhE3zv3LLrmYW7l3z+H8onyun5f1629Ez9 kwebty79/G0c9peq3wk73xg+bNmCck9s+KCTz538fUb6+3n5d/2y9vbYfoNfefzNU/0DOeI2 OMcSOuhM0VoBUGisIqAKa6DykauFYEkOoi06UcC8qKUVFb1a47OqMe9UgC8+qJrB0xTDwqoZ t/CcpA3lkrkUYZC2jKvg5ml93EJhBbdGuFe7iWsVtmgf4Ww6QSdyeiJpBpBkfoAwSBykcRoq yRzDGrIK0MI94nrNVrJFs5c8KjyneUPzW8235Bz5lj/HR8y+jQYGKy1i0lTjQCeX9Mfufdyt 57oPd4r2rir8Rff57ie4hO5P4BydA6Zf5xNYvSnKaRJX8rvRSk7AhEf9eupN1CcMBz9OC0zn PoQfReETFHYOaf3zHuZfQtBIZz/wLdTF2CySluOphxljpS6GJdWBNOw8fagCia0j1jHGcYvj KQeLHf6cJCkukwclDwLC8Sblnq1b71FG4LcuYqxcuqi8LaR3v3df8+r7dn/x0Sefd++hz18v 5XL7mf8e7LSjCMxhLoIgksvtQMt5DmGSfoiZHXDQA0MYwoOYyWn3dn+3VzjxtxoVd9OzeBJs nubDCZAPt9hQi2EjzYfDzVkk3GHpx5LJnnwYx/tLE/A7WT117DdJ/ljpxuTjjynVH8OBX6Tc pbypvKE048XCZKVD+VL5SunAE3AEjsQTdio3KduVHcpNeCeeC69dPXXl+cCXgJKcBlpU5nEU GYl4EUigEekUiFCXoSnSLCPLeJ6V7mgh+W3uP7pugZh0Yi+sMQrWWAyYUI/HOvMFq6gReSvh NfRD4EFSxMoBzLPCSMmqkzD90EsAEXVWAIiQU/OY1wKm5vwtgMCGACA0+/Eeg4YQwMSghw4i A9jHD1kDGPBaEPBK1H2/xPNSBO+Q+kvX89dJ0/jpmhlShbQAL+EXaBqke/gV0gP8Dn6L5j5p g7QbP8Y/xe/SPCK1SVES4QXAvPoI4hAcugh9CukvJOkG6mXjSJxNhgtDNPS5VIaxgOQLebqJ eqdxJkXn3EwyXSgTZ2rKtGW6mfoio9e4CDcZH8SbNY/jnZp243vGT42XjOm0fMjRh0vsORPv Vm7Fe08qB5QDJ/EzSv1JnIJT+Dndn3a/ijuUCdxELlS5Da8HPV66ADr4GvSogShlElVFOkkU cgpay/FTXafYecjMwAwUvAjHyAnqgCQKZGgdPmKmMwTpYpEFW7hYDa331ul26HSziQoB4kT+ z91nj3afFU7svXBCGBSwmwTYT4dSnDb/8wj+Sa2A2cMISXVU6pGmjyLM+uBHEQlHyKzuOq6o u/1t+hRiwt7u4XRNN/4UoPdKOGPW59A2jseIt3z8Dns8mkHnurnI7i+5lTshLWT7n/HjDRmN hciMWiRdiw1Qh/RkrFWv5ULCYwVkigoVwqPSdCjKxsepzuE4dQ8qBGHEZQN18WoJU3UNPQ3w EaGQg2tYOEiIw5vwuEceeugR5SAetHnjxs2KnuNPX1h2e8su5dzF7j9wR7o/aV67bhVXodzg rb+tbvcrT6952C4fvf+t39FcG+LcTvD3erXGQjoNZl1nP8c6c0fklnBks43vZxC1EUGZtr/G 8mafGktwUh2UbCdTl0m+DOTV3ff2ZtsjOzu5dH9WzRUH5druPUANpk/T+Yngi6LQdmdyeEQk 6RcFhxaxCGT5lXWzsc2+kUdtHLJIHJaiwixEjKbQ0gGHM5SeSzs7l0Q9i2deeUV9GkRLm0Gu UPgTbo+ysLCLnZnT+DKhTLOEXyIsiGwO1/CID+cj+EghqgEtEBsjfJENUSvQ6vAVESsiV0Tt QXsirXAsksAAhg5Dw2/AwQ9BeKofEeE13Ktdk334nizXlEdX3/LhoiXHZ/wB2/NuClfO7927 dyHeOLJmS8HC1tyx71yX+YfXfrGrLlr5I/N/20AvPuB/AKpzpiFHiLRaF7taDmlzGNt0m8So NnlTwkZxneORlNCoEETs4VH9ZUsUscfqxBQqhtDSgAR06iPQ4xTihrFQcIZBkK9YEmNh5Wns 1LljXLEu2R3Ho9lXgRnqg8HLGSRjNj6ivK/84ebD80vfqnnpcOeufc+1bH/k/pKX6n1HZn6F DfeSpNhDGz75Jinp9esyW9ff2bJ7YZ1vaWL/Z2X5g/23P07Py1rgcy2LOQmQQ4x1JvUzoLZk sS1mcJttY8y65Ecy+hkSB0Y5EqPMuihHZAyJMsdFZjAsC1bInob5eWJXNF8IKr8mBdBR73GJ T4S0ISSoBsit3bBr14YNu3cpu1ZsRJf+61Nl4/L7HlG+/fZb5dudEzauXLFp04qVG7k3tjY3 b31wdfPWMnn/smfef/+ZZfvl+DfXn/zDH06ufxO7GlasaIA3090bZC/2spg83CnhO8EBIYFT 0ypbKSshgF44qpczamSG5CrwHGqD0AbJFU0lsRdCc/cJbhBbc/slG34dKRAPw50Gsh2tFAmP w1E/Gg+Pv6NmEABRSELIuQ93Li9WnlBewU5//lMKtITASXraOVSn1RBJhChIBCvPk1yRRw7C O1p09hbjcj0viMQKPinUJEjh4bx1jF2KMvDs7IPAwXysqoMaTSGMLdvW51G64Ievzhj2yGpJ CBaQgAVOJBpWM7JzoSSMp5WIJK4/SRb7a/pr++vkmGF4GJeP87lKoZFvFBaG3CXepaEVgdjZ zBTDQhJIGh7EkmuZ6rEHKpF7cpbecOzkyxPXLvr4bfwWRl0ru9co97W03McdDN3wS6USN7XO 7V4jnPjtf95zgJvafbZ55cpVVJb7AeekgEysyOkM1XJWPRJaTOt0aLlNGyWNgBQ4x9abAjM1 qaAn058lQkoaG7I+ZEcIobCj5+mWCn/2H933+mv7jiqfAsb5UvlUONHVCJDxHFnb9QvlY+W3 eCBOpFiL5hfrg7BWmw21qVgrygxG7oi87NkD9udeNvCsfR4qrN320EPw76GHLmKd8u3Fi8q3 WCcUKceUd+B9DGBeFh6Cs9oUn7JaaVbAFeHFeAm+x5+zC3vB2yaiCc6Q/ixFN8T1M8ZorYY4 i31yUm89ZDTNzCFsOq06o/UxGxfRjPptEWNtB/VmWhHJVEafzYR0HeJ4cIp+WTFEQ2/QnF3Y G8jZWVVk34v72suT++O/9cnfAzn8AwMGVJbTXB5f6oKYcJrF1s3OAZfXQQEz0GKeltZBnxI5 De8UAGVodAxl2L632rkfSdRkRwucnRvKZXAZQoY2n3NyTsGpvZG7UbhR6+Hu5DZxllAcQWIl WvYcjkcQpwT5IllE6qQdkhGMlbACJfDMn8Tb8YMnu88dhQO8lavo+qY7mzus1o4/gl/74BwD lngeEg16hHueR9MU4yOaXMC4PcArffYsonJnP8HKEY4xnCu0oeVEoBk0EjWWrncOqV8PuALe 0xAAeErD8JQGaQJ4yjaDwyKJELKFCcI80o7aRQ17NuOAXCluD3ml+/MPsdKdJZwou7CcIio/ phJGse94pDrt2hbuSR4tl0QAVMIIHQ58xaOLZUqjaeEmY38R+4YHQHL68IXaAQDz/3r77e54 wFXd2zj3hUH02x6qX/uCd8Pa0ehmZwIfobGutkRHtGnsbZY1Rg54Na7T7IwJi8ISwDfJIsZY unBwdLMEVcIsFINDoLMcOsseCJxnQU45pMY4BvIYNnHYUZ/gRmPaJyS8uy11RuoFnKgcV/58 8+uVs1659cm3337yxl+VUih4n9msnP1//638RZaPXpfx3LZtzyVCugze+LZLX2hSAucYJaMs tMY5LNGc1D+pvzk5MTkX3WeIuS/tnn73JYr3Ge7pb1s3IHHjkOS4yCQdMTpMOqM5zjjIFGk0 X6cfQn2OrpRVl2lRWcUwtEB2E6svA4fXsVjur4BYs/2PmjPPj/aXFM5eZgR9HkSGqo9t4AD2 iZCQB4YE3RM+mF5ePn1aefm07QdeeKjtwAtdW8rK506fXu4m17V1zWqL3X7whR07Og9wGzff uaKlZcXKlqaPX3jho49eOPgR52pZcefmzXcub2362/+Ixo9eePF3Hx088DHLLS99pJSx72Ho kRmNc0bpOQ0yvWTQNAsvooOGpy1aiyBONWKtAeVbWNZ9KtvWG9dZkcqpt1id1iLrHGudVf3C h1304xL1ix+P/Dr/uqrJ7Nsf6377yjbXA+KAr5n9Br7HIaLnnck8rWlA5kfUqgaB++BFMMqF ePoUol/WQAJkC4HvalzbaRRpqdOYi8hAMp4fL8wid5CVBDCfhtPyOpHGuwg+QhiI+uP+XAqf IiSJsnYEAn/MjeZHC8PFCSgP53EFfIEwXoRcTKzgqvgqYQlagBdwi/nFQqO4THs/2iKmwPmM U7/dx03sfvNDfBL/7jfdh4UTF8P4ry8MgliyCYBUO9ggAU/ucQ5KjNGJvBQdwiP76pC7LC1h G8HRREcYdQIvxWBjVAQfJWCC+keEJNGKsoGenRBmWTQJYYgKBK7i5bN/pQ/ij0FXGA17i3VL pCUymZ0EAg9JAHMZg/viXmpIZmzCGhN24OajR994ecSsWdlZK6unPuO6+dV5HZ9OmDUjPVkr ioqCN271rCibOfTm62bW5o89mD3itR2T15SVpQ8Nd4wewuoREJ/ELrCZFDQYzXL2S88PG6Qd aIl0aCMG6lCsqAVG4/tPTusNU4cy6e8uVrwPi4xNeCzRipvR4JcGPm1BW0I1iQfDo+PoF8Iy M2kst5zJhH9qzPLHpuHDhvcU7gMRLKjYLADbtOBMg9X0qOTClRC4pnD7aRjzRzLyt85OCGJq zJoWFZJM41mg1B8IadzXvX41i+Wqi50xGiut3dAiRa6GhjCtIGINF8UP0/jz1i61VEwLCtlB BTZWWIulaawzYxg3QjOBG6+p4io0yziNiKkdRoj5uECcjmeIHlwlLhZX4bvFFrxV3KG3MM9P H5DHsUfyFq71kHKue/4hsK1Y/rMLg/jPLsb6a7QUo0ejbKeMhEjcQiJbtLZfWfc5Wkwbteti OBRlHcJn9QvXW2Iopae6DvXUapXj1KAykqxxQ+OsIh+ozvJhwXVb/nXlOc7WqHzVpjysNOK1 +Ob7sMZb17VWOav8CYdg2617TuCNu7ubSqbhB3ANrsUPTMj/j1vmKO8qHyi/Ud5NovK81KpU sGcZepTrDNFzSNMitKPlBkErZvvDVJ/nGqfUeiyTK3u+YXQai4xzjOuNO4zs+YYl4F+OvH3s iyljVtcKJy5sUr45v7f1Naa/k6C/jyAphdzFaUU6vE1DBM7BozBJdGgNlo+7RjNTTD9O4VOG +lWkBCYHso8b3P3hnu4PucEC3/3hXtrYyw2GNT+DuD8LeJAAmzpySRvPtQnLNahNp40VowiK xXpagmLxDjMuDqngIZNVFcEqwO0/ayZmnps9PM4qDE1idTEFT1QewJ638cSunXt534SOCbRC xmp+ynf+ml80KnYOBHRpxgajwYSNRkOuOcbAioD9AJgaY4yRZgPRhUeyUmBMwCJp0ddyiLnp y9IBllUHlQhDcEJyT3me/ub6FArHYOn8J3EJFrVOiEfRuuEHV5YLL7ynfPJnjsO7sIsWC1nx sEu5F7G/ReGmS7csFW+5xTz6LyhWy/4m492/HF0Q+PsMsJAyzW7wKIATe/9oAyFNjRId/Gcc l/1ZRz5/DFVovkbjBBs6wB9E13NrQfMmdERzFK5Po6VcNnqVvoXFyAJj9pEENJw/g25j4yvQ bfyX6DbxNDoi2KE9CHnh8wCZqK4lrkVlgoTSSSxq536BjnAfoHQxBR2B6510vNCKfPDZzD+M DnD70Tn+QxizHzzjZOTjG9ERWGMU/8WlC/xW6P8CuYU72D4HhDDUCu9t8F7LZaE3gObtwnq4 9xHaD33NwkqUDvO6oP8juN4DmeAR+Nyu2Ypu47IvfUR54cegTZqDKF3oQkfELOTjfnGpVXwW nYRxn9H9QTbxGOHRXDy8irlnyURSTzbwJr6Iv5f/ThgiLBN+IxaJ2zSTNds0x7UVukW6tyVO 6i/VS/ul/9Ln6u81SIYVhocNnxu1xkJjnSnTNN+02bTXzJkLze9aci1PWH5r+cZ6u/UlG7LN sB2wvRtiD8kNedg+zN5gP+UocrwSag+tDG0LfTuMC6v0ay4fDUECUivaFvQA1TTv4ELhk/7t SwS+oUe/9/foGoP93+9vczDuEX+bQP+j/jY95/v9bQEZ0Iv+tghn9Yi/Tat+H/rb9ESd8reN todw4K+lTGhIyHZ/24L0Ib/xt62ID/kEdsS8DgjKCPnM38Yo1GH1tzmkdST72wT60/1tHtp5 /raA+jlu8rdFZHf4/G0tinc0+9t6NNLxmL9tTBrp+MLfNqHKUdH+tgWFjlrlb1uRdtSDY711 i+ur5lU2yAPKU+TMjIwsee5iObeqwddQ73HVpMoFteVpck51tVxMR/nkYo/PU7/A406Trpg6 jE4tdS2ome+tnSfnuiqvMXGcZ76rrFEur3TVzvP4ZFe9R66qlesa51ZXlctub42rqjYwpsRV 68v1em8NugxqlnnqfVXeWjkzLWuI2h00oMJbC7s2ABOVDQ11I9PT3dC/oDHN522sL/dUeOvn edJqPQ35bBilgXLRw7g8wOfxyHM91d6FKWnyD6A4TR5fvbiu0idX1dR56xs8brmi3lsj59R7 FvhJCezBJNSoSih4G0nq3R04c8kqaT1ilgZ/7490pUJ+sC7ly3au8kkuuaHe5fbUuOpvlb0V l68iSUWe+poqHxN/lU+u9NR7YK959a5aYD0VeAe2YBpIDOScKjd4ZVftYrkOFAYTvHMbQGJV IAKXXA5ESzCyodITkFN5ubemDobTAQ2VsDpI2VPrA+nFM5HEp8Bibtnl83nLq1ywn+T2ljfW eGobXA2UnoqqalDSALoimyCXeCsaFoL441MYJfWeunqvu7Hcw5ZxVwFjVXMbGzyUBqnPhFRQ c3l1o5tSsrCqodLb2ADE1FT5N6I71KuihGUbfTCespMq13go1xIzEF9latAeqXTPdG+97POA HmB0FZDqZ/+yrSlxsGwdFXSDpIqObbSwEgzriglUDRWN9bWwoYdNdHtlnzdV9jXOne8pb6A9 lL8KbzUYG2Wo3FvrrqJ8+EZKUiks55rrXeBhHKhWxAjoMYJabwOowaf2Uq3U9VqAek/2Vbqq q6W5Hr/UgAw4Ja4+fHprwS7q5RpvveeqbMsNi+s8FS7YKE0lqu/dGtdiOC0w3V1VUUUNzVXd AKYHDVjU5XYzzlXR0QPqqge6Gqtd9RLdyO3xVc2rZWTMU88qTKIW6iqHRXx0RoAe3+U70SUl 2IAJzFV99QX8cwJ09K4G5NVWL5argsxcouzUe+hf6LKxtOGjgqR6CRwPD9icp55NWuitd/vk +J5zGE/3DtyQ4umxjWciA81M9p+XuR44SXTVRtABlckCb1UPYZ5FDXBiZFddHRwv19xqD72h 8g4r04bUq5RKV4Nc6fLBip7aPjKhVtdr3W65sdbtJ7iXVIkRp3L4fVr1eavpqWZqo0pyydXU e8BZCQysc5Xf6poHjME5rPVK1FT/PqPqsxU4LCDRU11BiZqQJ+dPLSyVS6bml07PKc6TC0rk ouKpZQXj8sbJ8TklcB2fKk8vKJ0wdVqpDCOKcwpLZ8pT8+WcwpnypILCcaly3oyi4rySEmlq sVwwpWhyQR70FRSOnTxtXEHheDkX5hVOLZUnF0wpKIVFS6eyqf6lCvJK6GJT8orHToDLnNyC yQWlM1Ol/ILSQlgTiCuWc+SinOLSgrHTJucUy0XTioumluTBGuNg2cKCwvxi2CVvSh4wAQuN nVo0s7hg/ITSVJhUCp2pUmlxzri8KTnFk1JlWGwqsFwssyFpQCWsIeeV0cklE3ImT5ZzC0pL SovzcqbQsVQ64wunTsmT8qdOKxyXU1owtVDOzQNWcnIn56m0AStjJ+cUTEmVx+VMyRlP2Qls Qoep7PSKQ6ITxucV5hXnTE6VS4ryxhbQBsixoDhvbCkbCbIHSUxm5I6dWliSd+M06IBxgS1S pekT8tgWwEAO/BvLKGPsFwK7dJ3SqcWlPaRMLyjJS5VzigtKqEbyi6cCuVSfU/OZBUwDeVLl FfrppTqifVdaB4yis/0MjsvLmQwLllAyoEPqMxasK29Ruaeugdq2/3CrrpG5UdV3pjKrVZ0A mPD4Wji4ah9rQliCk8WijurdegM2Dcepqutl7gOsGyKR6nrdCzzgAX3UlXjrJS91JgurfOyk Qwis8aoxT/a5qmEzmEVPERsFvtJVDdN8PWT2OVBSIBjW1VfBlIX1VQ3gTGRXI/TWVy3xh+F6 f5hiHMi9HNBdep2DSn+9x1cHUapqgad6cRqMraexjFFSVQtYrcbPOhNfecPIAFRokOexxd3e BgkQXZosSQxx/WTo9EOx7M+DgyQVB8k/BgdJvThI/pE4SLoSB/mdfDlbyReIGVcBqL2ARfop WEkOYCXp3wMrSaoe/mFYSVIP7E/CStLPiJWkXqwk/0isJPXBBT8CK0nXwkryD8dKUhBWCj6+ feASxHNwEj8XXJL8cEn+SXBJ6kMuyxt/bsgk1XrlnwyZpJ8VMkl+yCT/eMgkXQ6Z5B8DmaSr Qib574FMUmlO2ZSJUynZORN+FDqSejn/KehICqAj+aegIykYHck/Ch1JV0VH8k9BR9RY+xyU HuAjXRP4yH8H8JG+H/jIPwD4SAz49MUO/zugaQiMdzLQIKXBR9r3Vq7SF1bdWpVeBR5kUVpd ZV26341dVjlDY5EX1aHFqB5VoXmoEjUgGQ1A5SgFPjNRBryyoDUXRsgoF8Y0IB+865EHuVAN SoXeAlQL49OglYOq4SWj4p61fOzKA58emLMAfrthpPQDdh3Ws2sp7LQA9qL/TU8tjKZ0uGDO 37fjOGjNh3llqBFGlMNYF1vNw2a4GEcyrFILv+tgzFxYtwrGyTDfC7u72L3L1ylhq/iAIi+8 br3G3av3ljEKfbCul+2aCXRmoSF9Rl99hQo2Q+W1wa8JynsDUD4SpcPL7R+/AManwTgvfNYD Nx42t57xnQZreGBOftBqATkEdHGlxuk9KlsP048HpORFC2Es1cbPI2O60ni4sxjGVLKZVXCv jtHdwPRJJVDPZlALoKsuuEwql/PRa0ONfWzoWtzQ/0zoaryrOnNBK1hqV1qzhAb/hJf0g07I z38ur67vXp6r4I7EWg2sh1pZDZP1rdDnBQ38b7RQzorYejVstV7rr2I0VbJ7Hj9f89gutX6t p/r1rmpL3U21MdWeUxldXqb9Wja/zn/C1B28sGqD38aq/FbgYmuokpb8azYwKi63p3I2jtqh unpgBTpapV21ZQ87r6rtxQdZSTzTHJ3rZp8+Rlc5zHH5+ZPYKSgHC61hqzSwOwH5VECr2n+S BvTQ2LsD9SuU/gawX9X66Y69MqE9dezUuGGHcjY7QI2bcdDAbG0u3G1gd9U9pO/ZIdV/msuB ska2iiqThcwGKpnXafBLpob1BXMU4KG+j1Wq1DYyGaYGaYe2a5g+VV1LQR7EB7NTr8FHag+f 6cyDyGxl9Tyoa1f5pdpX+9/PdUByKrV1PRbdwOjqtbpejhYyedT8oB0Cp6GCee1aP4eeoB3d 7DfdI5V9UknMhxHlbD11TEB/1I6r/Z4toKFytrebUVzlp3QkO52lfupcsKKXeYZeHQT7ol4J XOkJamF8g/80+PqMDZyVXokF+4DgeTLj2cUol5hv7mtrqjTUWOL6Hn16WZST/bqvYZ+9/uOH 6KKBRSIaOV1+jtL6SOr75lKZLPbHFnV3KvMKRqPbb0nVzE7re3pUSqlM3UE6D7a6QAR1sYhY xXxGNbuSejhyM0qpvmqDpDGvT1xVdwr4UBezHtV2A3tcLh/f/8pTgErJz0GvhbmYjn44BX33 uVweV6Mt1a/vajav6hreXOrRTj3zsy7mV3rXDfT4eiwycF4ujx4ev5/zMC4COy1kXLnZ/Pir xMP4Hr4vnyHBvUC0jQ+yMvXMTL4svsxl590bRGuj/xwE7GQB3K26isQ8aBGTc63/JNfBS41e LuZRPT0zgvWu0hzoka56UiqZh5fZp89Po4dZ0rXsJODrrua73SwS1DK9B8vralKVgiQXrMMf e1Z9zGsGYnXvaQucJIocqnuwR71/Rt8V65hF3wq/5/k1psZDalVSj1f9R3qqa3M1139GGvzx sKJHUhNQHttnKiqEK7rPVLgqRdMBRxazewXQJwOOK4Y7ZXA1DnrHMb3ksDv0fjw7jdOhTVec iqaxtdQ1iuE3XXsm9NC1ZXZNrybB+EJYi87NQzPYHnmwWglQNhXadO0p0DsZPvP84+iMsdAz Da5pezyiKFTdrxBmlbKzQ+dRWlRKS6G/d9e+VBWwHQOUTYGrYlh/gv9uDqxdwNaj9KcyfETb hX46VckVs9WpjOjKdM2xQNFkdkV7p8FnEYwrYfLMYTyr1BYyHvLhvspLHqNA1YRK0Vj4LIK9 6YjxQFcpkwLdqdQ/MpXpkfIzjs2nu05io1TKpvq1TNu9q6T5ZanSQeVf1rNzCeN/Mrxkxn8p 9JQy3eTA+oF1A7Yznq1A6ZaYNKYx/nKYHKayHXLZOCpFKs/JPRZXHKSVsUxeVG+U8nFspxwm kZKrchJYLVg7V7MOqWeH8Yy/PCapyWx0CcgxD8YX9PSo9ljAeB3rl7W6pmr3qk1MDpLuWMYj 1eyNsGue36ZymOz6ckH1NJ3R38uFqoEc/++xQTLr1X6hX7sBekrZzqVXkcp0dhbz2KgcpuuS njOSz87vFD/l03osrNcHTPPb59QeyvrKN3COAuN+iO9Q1wrs3VeD45g9TfZTWNIjDXWE9D3r qr4rD+JaOctzGnr8dt/IHYwae9FoMO5MDfK1wUhA9cLj2diay8b19qrZkhqzenOdYOx2tQw7 kB2rWD6AenvRh+q71ZwoGPW6GT5XMaCvB5V4GQ709iCThexub0yv89dOvH3yPLqzi8X+1J69 ArGody0VV7oYWqC7+a4izWtHKOmKzLCOxXt1l4Ws3eBHJpS/Rv9Y2r/ksmw4UP+5UgfyVXUQ 4OVqyCFY/vVM33X+XKqKSZjiyTT/uvUokJf1yoRKQK2r1Vym9V7ro6uNRJdXFagM5gVR7may lpBao6N7SsxfBWpc//qq089dl/13qgdJfepBlyOvf1w9SLpqPUj+J9eDpB9UD+qL5MuDaOqt dQRG/rAK6tUqLNK/rK4kX1FXkv7/ulJQXam3wvB/s64k9Ymw/7q6knSVbO3foa4kXbWu1MvR P6euJH1PveCfU1eS0N9bV+p96vRz1pV6z1vfutK1ou+1q0tqfq4iiX+36pKE+laXrl7d+OdU l6Tvka4cJMF/7yqTxGzsSjTzz68ySf/GVSbpsipTb677z6wySf9rlUn+p1WZpL+jyiT/w6pM EpNBGaw6kVGrSjsH7v/zakfSVXX+r6odSVfUjuR/We1IumbtqLcG9I+vHUl/R+3o+9b9x9aO Ap712hHlyoqP9CMqPsFVmp+z4iP9pIrPlTnbj6v4SEEVn++rO/wcFZqGK9Z3ot5Kg8T2oVdp P+E7V+lMLrfCO53R5maoKY3h1zro64vGvv87Z+xvltW/df8lmoWu8tPBLXNeuqiQC3bytyTy XSb5tpX81UT+opDzCvmfJPKNifx3KzmXRP58d47wZ4WcbSV/aiVnLpA/XiD/TyFfjyR/yCWn FfJVJvnyVInwZSs5BQNPlZAvPk8XvrhAPk8nnynk9wr5NJP8l5180ko+VshHNvK7O8jJF8h/ KuS3MPy3d5ATx8cLJ+4gx8eTD38TKXyokN9Ekg8U8r5C3lPIuwo51kreORojvKOQozHk7Uxy RCFvrrIKb0aRN0LJIYW8rpDXFPKqQl5RyMsKeUkhLyrkoEJeUMgBK+lcnSR0KqTj+ReEDoU8 /9xs4fkXyPPL+Od+nSQ8N9t5iTzn5H+dRJ5VyDOtZL9CnlZIu0KeUsg+N3nSRJ54PEl4wk0e 32sTHk8ie23kMSD6sQtkj0IeVchuheyykZ0KeeRhk/BIJnnYRH7lJm0wpK2V7FDI9ocMwnaF PGQg2x4MF7a5yYNbLcKD4WSrhTwgkfsVsqXVKGxRSKuRtMCkllayeZNJ2DyAbDKR+y6QjRte EDYqZMP62cKGF8iGZfz6e5OE9bPJeid/bxK5RyHr1qYJ6xSyNo3cDWzenUPW3KUX1tjJXXrS DB3NbrIaJLU6iayykjsVsnKFVVipkBVWslwhyxTSpBDnpV/ecYfwS4XccQe53U2WljqEpUlk iUIWK2SRiSw0kAUSaVRIwwXiu0DqL5DbLpA6hXgVUquQ6jhyq0LmW3OF+SWkSiGVd5B5cFGh EI9C3AopV8hchbhGkjkXyM0GMlshNylklkJmzpCEmRfIDIlMDw0XpmeSMoVMg52n5ZJSBynB FqGkHym2kxsnhgg3KqRIT6YqpHCKRShUyBQLmayQSXBnkkImFliEiSGkINooFFjIBCMZr5D8 VpLXSsYpZCw3WBh7geS+QHImEadCxijkhuttwg12cv1os3C9jYweZRRGOy+ZySgjGamQbIWM GG4XRlwgw4dZhOF2MmyoXhhmIUP1ZEgMyTKSzOv0QqZCrtOTjHS9kGEk6XqSNlgnpFnIYB1J zSSDBiYJg9xkYIpNGJhEUmxkQHKSMCCHJCeR/kl6ob+ZJOlJokISFBJvJnHAZ5yNyG4Se4HE AAsxbhJtJFEgwSiFRF4gEbkkHC7CFdLPTcJAUmEKCYVJoeHEoRC7QkIUYoMBNoVYgVdrLrHc QcxuYlKI0RAqGBVigNGGUKJXiGQhOoVoYZhWIRo7Ed2Eh5s8WICDQC9RCAfX3GCCLQQpBHdg 96p78KD/Cz/oX03A9/5E/3/9i1tDCmVuZHN0cmVhbQplbmRvYmoKCjk4IDAgb2JqCjE1MTQ2 CmVuZG9iagoKOTkgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9DQUFB QUErRGVqYVZ1U2FucwovRmxhZ3MgNAovRm9udEJCb3hbLTEwMjAgLTQxNSAxNjc5IDExNjZd L0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA5MjgKL0Rlc2NlbnQgLTIzNQovQ2FwSGVpZ2h0IDEx NjYKL1N0ZW1WIDgwCi9Gb250RmlsZTIgOTcgMCBSCj4+CmVuZG9iagoKMTAwIDAgb2JqCjw8 L0xlbmd0aCA1MjkvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZTNjpswFIX3PAXL 6WIEvrZhIkWR8jORsuiPmukDEHAySBNAhCzy9uXc43aqLhJ9gH39nWtMtj3sDl07ZT/Gvj6G KT23XTOGW38f65CewqXtEiNp09ZTvNL/+loNSTbPPT5uU7geunO/XCbZz/nZbRof6dO66U/h S5J9H5swtt0lffq1Pc7Xx/swfIRr6KY0T1artAnnuc7XavhWXUOms54Pzfy4nR7P85TPAW+P IaSi14Yqdd+E21DVYay6S0iWeb5Kl/v9Kgld89+zYsEpp3P9Xo3zUDMPzXNfrmYW5eIFbJXL BdgpSw72ys6DC47fgUuyAb+Qde6CvAWvOVfHbFhf62zJDrzjeL3/Sn4F78l2ZpOT92D6OziY 6I86JvrrePqX8Df0LwVM/7IA079EH0z0L2IGwwyCvpiYQe9v4jgwMzhdmxlEx8QMWpcZHJyE GbwyMxQbMDPYNZgZPLwl7gEyS9wDZWZw6K/EDPAUZvDwEfo7eAr9Bf0S+jv0QuhfKNPfKtPf qif9Lepb+gtyWfoLHCz9Peba6I+9tPS3yGL9Z3/hZJnBo1+WGQR7bpnB6hoxg67NDFbrMoMo xwzonWUGr/VjBvTL7v9ZO+6vYxaHNV18n7CmYxaHeo5ZBHvkYha8x45ZvNHDFk8Vjh2+C3+O c1rfx3E+yvrx0DOM09t24e/3ZegHzNLfb1KNEBIKZW5kc3RyZWFtCmVuZG9iagoKMTAxIDAg b2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NBQUFBQStEZWph VnVTYW5zCi9GaXJzdENoYXIgMAovTGFzdENoYXIgNjkKL1dpZHRoc1s2MDAgOTg4IDYzMyA1 OTEgMzE3IDYzMSA5NzQgNjEyIDI3NyAyNzcgNjg0IDYzMyAzOTIgNjE1IDYzMyA1NDkKNjEx IDg2MiA2MzQgNTIwIDYzNCA0MTEgNTkxIDgxNyA2MjkgMzkwIDI5NCAzNTIgNzcwIDM5MCA2 MzQgNjk4CjYzNCA1NzkgMzM2IDYwMyAzMzYgNzg3IDU1NyA1OTEgNjEwIDU3NSAzNjAgNjg2 IDYzNCA2MzYgNjM2IDYzNgoyNzQgMzE3IDY5NCA3MzEgNjM2IDY4OCA2MTAgMzE3IDYzNiA3 NTEgNjM2IDk1MCAyNzcgNjg0IDUzMCA5NjYKNzQ4IDc3NCAyOTQgODM3IDYzNiA3ODcgXQov Rm9udERlc2NyaXB0b3IgOTkgMCBSCi9Ub1VuaWNvZGUgMTAwIDAgUgo+PgplbmRvYmoKCjEw MiAwIG9iago8PC9MZW5ndGggMTAzIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAy NzU1Mj4+CnN0cmVhbQp4nNS9eXwUx5U4Xq+6e3p6Dk3PKY2umdHontFMo0G3Rmp0MeIUIIQk EJJAN4eEENgCbIQ5bAQ2ik3AGBxIQhxfMQJjjEMcSOK148SOWcfJrtdJYHcdb5yYmG+W+Bsb JH2rekZCYCf7+/y+v39+I6a7jlevXr2qevXeq6phoH9TO9KhIcQgefW61r59nXVlCKG3EALT 6s0Dzk9nP5FEwlcRwraOvs516YEP/owQ8zeEeK5z7WDH6Z890YSQlhRZUtHV3toWlWcKILSy giTkdpGEg+MP8CS+jcSTu9YN3PtifIeKxE8QnLa1vatbH31WPodQ83mS/8i61nv7ZquWMQi1 hEjcub51XXvOX/CHJN6FkFru6904cAhlTiDU9TTN7+tv78td+dMSEv8poe9XJA3IH/3oSFBF 45hhORWvFjRanT7KIBpNZovVFh1jj42LT0h0OF1J7uSU1LT0jEyPN8vnl2ZkB2bm5OblFxQW FQdLSuVZZeUVlej/xx/uLe4tdB+3A1nRoPK848MWIgu6B6GJT2js9nN82f+3VKjDr7PoVXQK nbgj6yF0P3k+f0faRfQT9JwSOooe/gdoX0HPRkIH0RH04N+F60E7CZ6TpP7bnxaSOogeJzWf R98lAyUJAqTWNZHcD9CbX40K/h3eRI+ipwnko+hl8jxKRt5W/Bf0KF6M1uN/YXagB9Be0sbj 0I0OEPgWdBKWo5UkNfxZidpR711Ih9EI+g7aQmbh1IfbMfHfSH/ru4TyvQTPIdSNNkwr8TR8 Tl+Mg9D+AnpJSdsxmcmHmB58DuOxx0jka6iTfFvhfULnw8wsVMEZ4RmE5MqG+qW1SxYvqlm4 YP68uXOqQ7OrKivKy2bJpSXB4qLCgvy83JwZkt+X5U1PS01Jdie5HDEWo2iI0ms1gppXcSyD AXkr3VUtztHUllE21R0KZdG4u5UktE5LaBl1kqSqO2FGnS0KmPNOSJlAdtwFKYch5SlIEJ3F qDjL66x0O0ffrnA7z0PjonoSfrjC3eAcvaaE5ythNlWJ6EnE5SIlnJUxXRXOUWhxVo5Wbe4a rmypIPhOazXl7vJ2TZYXndZoSVBLQqPp7r7TkF4CSgCnVxaexkitp9WOMimVrW2jNYvqKyvi XK6GLG/1aJS7QslC5QrKUVX5KK+gdHZT0tE+52nvpeH950W0qsWja3O3ta6oH2VaSdlhpnJ4 +MFRo2c0w10xmrHlwxjS8vZRr7uictRDsc5dPFXP3NtVwiiXIrqdw39FpDnua5/cmdIaSVGl iH9FNFhF2Ds8XOV2Vg23DLeenxha5XaK7uHTOt1wXyXhMKqpJ6XOT3x/X9xo1f6GUbGlCwoj ja1aPHfUvGh5/ShOqXJ2tZIU8q/U7cqPcxkbJmFq/l42Iowg7CA8dblow/edl9EqEhkdWlQf jjvRqrgzSPZ7GkZxC825NJljXUpzhiZzpoq3uElvzl1SPzzKplS3uSsJj/e1jg6tIuOph3aF WxyN+izO5R42GZ0F/gYF1kmoqm7rdo5yqYQtpNT0AmSk0CLDohKJ+iz8uhZHKkg1mpwFboKG 4ql0V7ZE/m3uiiEInFne0ZAn3PW19aNyBQnIrZE+qjwt+UmJ1hbSRd0VSveN+t19oxZ32VR/ UrIqu5fUK0UixUYt5aOoZXWk1Ki/soLW7KwcbqkIk0BxuRfVv4ICE1dPz3TGvRhAM1FDBQW2 lZNxlVo5XN/WMepoiWsjM63DWR/nGpUbSAc3uOvbG+hAIxzKuEqqcyk1juLy2vq5S9xzFzXW 50cICWdQdGxK5V1o3PVxYTRkyI2qU9TOehzHNBBAkSQ4q0jAXVZMnqN8ipp8RcJwJZUO1bJi Zz3EoUloQsZohrOyvSICR+N3IOXocCoPTWJT0SjBUx6KczW4wp8sLybZzkjFpISaMjU0mcWk EElA0jBBoyRRXsbQMe+sd7e7G9xdzlG5pp62jbJH4XKEGQrPI31Ve0dsGrMIm5CLZE9GKDNH qzxx05k7OluJT0VDd2VXT2Y7h9XuuUuGKXJ3BCEilFePIjqE5XxjnDL76Xx2V7WSSUxmtDKf h0/LMp3LXXTaDrur24bdS+qLFWgiQe6L20LrMqG5MLe2LMtLhFnZaTc8tOi0DA8taax/RSQq 1UO19Wcw4PKWsobTySSv/hUnWSuUVExTaSKNOGmEYlpMImoFPu4VGaEhJZdVEpT46vOAlDT1 ZBqg1edxOE2cTMMkjQ2nyUoa/ZBeiukiPCbyu9LZRvtnW0PXcEsDHePIRjhC/sEouEsId9wl pwGrdKMad3vZqNZdRtNLaXppOF1F03kyMsAGWd4tw2Kl+68xWXSxxIjoqriNW0o0YB75TgPy F5/hWfW17NMq7jfFZxhMgug0Q5M5mnyGVwm3is8ATQ8YXcYUl9FVgZ3jyfD4eBe39IvnKti3 qaKAHiHr85+J9uVC615B6olLcjKvDWmr5BodHNdN6LDOPYTcl9yX3Vfd7CU3GNww5Ab3eQLo NEeH4mOqLtkB2UW7ZL9qv27n1PZYZNdakamGE1HptezSQCn4VzZtuJbtadqwoT9W/E3Ththr MyQPlDCB7ERsNbqNM33YnRSlBANGSxTmIZhYVdtW0rV7fsJLRqm+Su6sTj97FpOlnNmRNz87 Or99f+2YH79Q2VXp9tXeO3fsAe6t8ftdZflpvNImx8R1nMl5kQ1tlZelR0F31GDU3igmXQ/d +kH9Xj2zjwXWKehDa9lt7DH2eZYlMV2o17bdhm06vY0RqwT1AQ4QJ3JOTuZYnhuKAYOqRleq AY1gMNcwNtK40rebAteyoYm2LxC4Fp3tb5ohIU8TeJqaNjRtSIkCd1KO0Z0TyAtYA1a30WIL ZOfm4cyMpfn/et+unHt/+tNAaeyMBLVW/1f87s6//GXn2NIFpWpVuL93jS9jE9j5KBUVooOy 2J0/mI+7Mwcz8Z7kQ8k4+fzEVdnMa0LVjgYHruYbeLyHOcRghqaXknQ0Wz6RBmnFQzPiDVVI FEVJvC6yanG0GEqLoa94pBg7imGiGC4VXy3G8d6aJNFmMMSpc2s4m9JvpaW0abTP+kn7rmVn 065Teq6pqYl+gfSUOyk1zZ3IRDoxLUCCgXC/8pOdaknEgewSzCakNx3pG3jBxwH5nAWM4QVg GIa1y4vbS/uONKW/GlO0ak5xz0JfavXaqrmri2Jw0tbLh5bWt2GnVJQw3sCp0kJFmQKTHCiM nVntt9Z87e0dbcfW5ie1PPPgxuOrPIXrj9O+L5j4hDnHzkV56FV56YBvlw/3WrdbD1iZNTZI yYXMOLDOBA5bMdYmxiXi5Gq3G4XIWJbMeMR8wjxqZswFQ9pqjWxPDGk03tDChOYE7EyAhJaC SwV4qAAK6NjPTMsMlRaAWABmL5dR40TJMJJ8nfRLslOMquFatH1aPKQFrZZyM+Bv2iBei7xM BQVAGbiBxK4F/J5rkSmR7Se8bWpCTUAfk+wlTM1LBMrAHMpgH5MzMzeQbYvmfYw7SUWZG53I MeeK+r7dvfJw/3zT8eiRocLWqjTf4k1Vs4Y65V/+7MVfxn9LkCqW+rYMeOavneVpXDo33wWe efcs8iTI3fMcyxaJabOkGaWZDrMxs7Jj/sGj9++zZBa4DXPmegvSEkSt3e0vqw+PyQuEwfcT a4zKoFw5meEPEeNshMUyW8NeZa+zJHyCxaysF0Msd4xFx8BAxpL/GvhJe/vJXJkhmXMCVoZ8 L/zkJz9h1rzzzq2vv/OOMmeJRYcLiBxiUECOHSTmBIYYvTGUQeS8iIgMduIhIrHR+YnrZym0 GZUSwZL/dlM+4ZqnyQoBgKPfGO+2cFe/cFJa6yY+IfNnAYpCSWhALhp07nXigfhd8XizbY8N D5r2mvAh3VM6zOosOqwV4gSs5eI4UoUFY57MnhEDGJKHpGRIpv1tSXSHriSDfbZDDWpLjUZM jIgA0rama02eDZOzY2XT5AdEpf9yRNdXTocv/rzhzNZZ8Pv7X96U/2ra3LUVlb0LMrzzu0sq +xZk4sTxD8f/WLH/lwewVLX/3f33n1yVlrH65Nb7v7MqPW3VU5Rfw+RRovCrV57JVF1CcJny RUQSuo5YNbrKXefwFY4o25c4fJyDPm6IwwbOweHrHJB0jjYrLikltJCDiXD2Je4yd5UjIEAQ WSmDSTM2eKgIoB8q5vpJEwNESg+f5d76YialQxkTxBJlkE92MmRAjCAsoxo0iq4SQrgRYmRi REcEAmKETo4FikYZBR98QLL3EhxBpS082ijrGb6KjCuRlVhGzSqzzRoTYlm1MCHAVQGuCDAq XBLwcQH6hCEBOwRAAlxXMgQKbqStEoCkcwbWipaQ1pCeIq253Zb+fqOpwO9Z2XR7UJJW7T17 9iznfP75L66yhTdfD4/5ZWQcxZBxFI9S0BrZ1+jucePGxJ5EvJRpJ6tutSDEzZYdCTBCRETa UAqa7TCCUUq7lHY5jUmj1JjJ0FGrOVSTksI5a2wiVxMVHjmEgGvGAj94iCi4ln2HGEB0/tOR kpsXHUVmOjbOLMFUrCZAmg/oQOLB4q7ur9n0sP0bxmDHkbXXb87bNdr20Mu9/u8bRh7MWl1b yML/Xnqgs2BlKCtrebUfEiH28V/uKqo/+u6WmOHnnkyYs32VMu8SSCOLuZ+hOPRNWctozJqA plzD6jV0IelR60KxBhGiRLsIVRyZkibsSPAnUJm4PeFAwvEE3pBQSoKnEi4mXEn4NIEvaiYh HM5jEuS6tlCCnOYNOROkhJYE5pQCxMgJYCBYsLlGR5SPGrvKAHS0ka4g00kZcp4N/WSw+ZXu yaYvuq6ubAKyzpDlNEdhhi3aGmZFAgSs0H328cdtRR2LnJWxxixTeiBB+0vm5VvVzMs7txS1 z/WoVHsZzpZRnNa6k7T5IdLmh0ifOlCJnC5aJSu2Wl06B51E4RmkDF01sqebbSG7ziTyBmU+ lAbe9kS0GWOALvaBO5e9KZKsxkfoCvcsWeGANXsKawps6VqTlFiyLC+WKUmaXVYYHV1UUmAp WV6UwDPf4bj81XsXjb2lyK3xZcynZP2agSrR+3Joy4zhGXgzv4fH7SWwVNeuw42FPYU4lcll cKoJMlwgRNujB6P3RrOqBFvC5oQ9Cazgr5Kzk6Qo2B51JQpHzR5SVSmzfVF0fIjjimcbYkET 65wtz8bvzAY02zl7ZPbobLbmymy4NBsWzoah2SdmY8Ns/2x8efZ1GgJ1hiEpr8YhGmbVWG1C TY4KUlWgImOmNLup6RpVF8g/WBlWF/rpm+oMU6sbUR7IqEa3ZWMTTFvZguCmY5yIyki/Bsg7 LxBF1AqLynyX4MTJTSMdctRLpq1twbaqVGwpWtoX6nysyeNpPdq78RkfJioFfo4y/4p3Rk1n buXqWQ6HvKoit3Nx9viy1NmrimPnLkqae2/dCxlzC92Vw28/+MDlr83vbrWX5KUzgqe4Ou3W P/3n75nXN3yzQ5I6v9m36fiqTF/bNxSnGh03KjcZN0X4x6+gzImrL6q1ISedKBMkkFREpJbe V/W+/3M/PueHDH+Df6+fUfnhKf85/6/9H/nZvX7Y7IcGP6j8Nn+Vn+H9dl3V63pQ6W36XP1H +s/0nFp/MwhvBt8PfhxkLgThSBD2BaE7OBjEy4NQHQRPsCiIPw/Cn4LwfhB+HoRXbwMBAckI FgRxXBCEIPzsT8GbQdwd3Bs8Enwl+GaQI9nzb0OEkdCq8FRF9wWB1DA3uDy4Jsg6gsDSKv4U xKeCF4OY5G8P3pGtDcITExSNPAFXgkDQnKJojgbxdkrMmiBeGISiICQroKS2KaCjFNeBIG4L wtwglFK0YAg6gjgMtDW4L/hc8EKQ7VXKh6vquRCkxDBKHaDUAAQ/acpNWuhT2o6fU1qhLXiQ NpGSypAm3KAFngt+EGRIoTVBmKkUMgSh4AJJvBlkTgRhgBYJt40JV0frInknKTBN3hpkCaLL QcAtwZHgieClIEtql4LgDwKSzUFQJ+XUpIt2FZknZoNfTyVGdnZpeHJAeOw30xkSWYImZ8OG 8Kf/K1On5dyd3XxH9rS5Na1wWFb5V06lKotOAZWmHtd0u+suMRb4CuOMQRb/vLyCFbPcL4Zl G7HHmJj8ua3y1gPxTExxTZu8+J55yWcmofALC3tmxWUtvW/R2MPMkqS55RLPeQuKSHZOwqo1 9Old8bU2asZROE/t/UvGHg7rbcynRBdwoAC13pYmtSfhxuyebFwA1YBzNVUaLLB2dpDdy7Iq 3sZT2ciaq+RMdMD0qQmbcoacsx1EOPXljORgRw5M5MClnKs52G41Ia2/Ri2ilLDqpsisUsXE IesvlVMRMRXmoWK9YSPR3qhA8sHMHGqcEn3bTZRwiEijnAh3mJzs72x5+0fwyNaT2Thi3jxP RBEe+7f4kpbK2euqU1PnrKkqa5EdL3Q1ggVicG7jKo3HnynAt2+a00LFHkGTIuXEQl/fiU7J 1/nUvdSk8XV8e0oH2UjkTjaaRVbp7EEypfGgbq8O43RixGq4WA57YgRjiIu3xuOUlMQq2Sf0 5m/PP5DP5JcPWWZbFRXWGh+yWktnOxhgpPJL5fhEOZQrdjxRUFyL0m0FiwQhNtBsAb/lgAVb LIaaWNEXqEERZlHzhSpNVOdVzJcp+U75lu1X9HAP4R6XlEoleSlMcodPU0aVNWIAWylnyXgj Uj9NEf88EfUWG3zj2ycX7Xx62X/HFy4rmllbkqr6gSa/8+j6t36RWWRIjEoqTw1U+2IYVULl ik3uuh1LM/+p7J7GnGbL84fW7F2QiNmi8pWFcYa08oBRXrPAc+H0uK9mEcv0qdVxeYtyZ9YW OR8sXTWQ08CCMbuxur6FyvPlcBkvxH1E73TJFqK24j4yphG6cBzeAewndiqiRhr46VJvznFZ l8MNuHzihLIWcGSdvkVsIQd+Ry56jIHHMBwR4RCCh8UnRfwwehLhLQnDCU8kMN0J8GQiJIpE B37UDHvM0G+GOnOHGT9qAsZEDBo5mWSJKEZN/oyJDvGIA/Y4oMEBVQ6wO0DlALXDZFQAjSoX qFyprlxXlavDtdm1x/WU65zrdddHrs9cujfoE7ton068/3HoNRfQTLzrziKqv1te5bKRrCpX HcmiGeFk7eEbLrjqgh+73nXhsy444YIHXI+68IALWlxQ5lrswjNd4HQBdplc+EPXDRdWQE+6 zrqwAtnmGnBhBTDZNdOF/zFcHcUJCqCN4oROBfTXlABQYA9RAuCrgSdh5acINCF1lDb/oAu3 uPpcuMJV68JOl+TCrMviwldd1134Ndd7LvyP4fJI4yNgEAGCCAhEEH0pHyMXRVDjYmtcQ64R 1yUX63cBcokuzJOeRs5Eo0FXw8VRQ4DYU+SfskJEhPrd0j4i0Jv/zmIwTeLfma1EPYoqnR+I rAJN+QFTQUHQH+Mn1c6QPM1KInXoUKODhl1UG0tNy6HaWW4pQMCcyESXMHnmAF6RunDVvQuS Cp1mybjwoYBxfMmlDzUORwxmohMSNe/9cNWTvUUs/yDDbN7hYXPGno1rbAwJ2lk1ixNxD5kz u4ls/xOZMyloUK48xECsK9NV6GLsUVWyX3tAiy9q4YD2uHZCy2jThqDqSvKnyRgli8lS8vVk Vp08GraqRtOup+GJNOhLA8XA0pujQ3TVtZmtOmQgi67iuqI+OMVkDaug/bHXAopsB+Ok7J4m zycVUCMURs9cWqr4G28vcrEli3uqGh+oTWMLxxZPLmp4463v3bmoeVeMtON/prKByGvmZ0Re p6FN8qJBEQajYXUKrGbAWeVwqKtOEDtVyCCWohnM7ppYh3O784DzipN1OmNFp7pPPaS+rL5K LEa1qG5RopdIAk9sSGI5OjKgCYWFMXUoiYr/wRi4z78hhiQqLqS7bEdFr2bpch7Nh60TMMfJ 3fNbdhjOCcWdB1u3n+nNTp5V39lfuPyRTln/SlR/9/xOOQ4nNR3bUNK1Vle+bWVB3eG37133 3fuWBqKzl22uiGrsCXQem9KJmT+TtqZQ/3ES0YWp/zilSq5BcBxNkMUrbQgp/XY1jb2UBoY0 GIr0G/UfE/33kh6QXtRL+qv661T/jShQYf1J6cqv9B//ffWF6i1MwT/qx3+kmoSVkrDtX0PW XTd3CJlJT/bJNQ0p3Sk4LB6ZuriOONwQ3R2NWRNsNu4xYupYxlodaNUwyO/l8WZmD4NZDDxa L49YTpAVNWMocT11INs3Gnj3Rs4+5T/6svNI6USsLJRA+s9UQuZiIpi+5EZyz999tqPzzM65 c3ed7Wk/vWvey+kLNoTmDSxMz1jYXz27f6EH/+jn4396bs6cZ8H61q8g+qny8qfGP/7V01d2 5+XvvvLdb/3uwaKiB39H+nEx9ZdxO5AXvSTH1+k79Hv0zFLcjnEj08PgpZ52D16a2Z6JU89P /KvcEGUMWdWg0oA9+Ugy3pv8fjJmKsg643aSHLeWNNlhBb/1uBWPWMHqG0p2pKx3OZ3a9Zc1 QFkQuzE9XUwecKnEjRu1O7W4Uws2LWgpTwJNiklJNQ0I+0gDEe8zncTGAs8MqZmIwn7qKaXO dsVliqb7S5npqhnvNrusLkZhIGYT5PsvbO39Tn951DltemV7qKp/kTeTcCxr3qyc6FE/4xrb GSeNrO5+erMMP+8Z3V41c/mWKmv63CK3p3bLwlnrFnrF+BQL/uzI+KyUHHnTt8Jz4GmEOCfh nRZ1ygnaRll9AB1Hp9AVxCL9kKwHWX9Jf5mMb1ZPx30KYRHPNFIPl8wyPIuba3gY5a/y2MCD mucFjmGRiQ7+QAEV2lQDoR54MgEUbYuOFJfRpeyWuMiXbR1TXbyIv7iIHx7byO0Yex7XfrFd oev8+BewA32AdGjBK4iduPqy1hjSHEaHeEqGjSiM/JBuRIdlXY1uVMeM6E7osI5mRaVmhHTU Z6fjn0ZHtcg/9iH4PYoP1zNGJ1+KlW7TuEsgx50DOwRLgmVr1oz6D57OWTa3zDlr16wPpvii wnRMYa+sezwDDjtAJ5piQqSS6y/qjSE91WniSEK6HogIMIYyna4U8jDFkwchL5HY1i+SFOVN EhMVW5tk6HXJyXHeFZnJaCbC7yHYh44izCJQI98+Hwz4oMgHP/fBWR9offDOc0R794HTBxYf IB/c8MFlH7zmg1EKust30se0+KDWB7ICJ/qA9cHh67T4a74PfcwJCnbQh2t8UOEDiWYn+zDB cpWCvOfDIz7Y5YM+WrrC1+ZjwjWFqwlX8JqPbaHZtT4cRt9JMYbxczVhjBU+xuILY9jlo3hv +NS05A0fs49C0NIDPjZPXvKh0jhaIoyFI42k4PiCD2hhPJcSQMb/TR+cDLdhiIgR2Vfj6/Mx pZQJTh9OjFuB4uV4zMerrIqBIJoI760JzNxkIpCTmXgyBKMDTaWBgIdoJ8oIDFuwTVOahqKy fJXR+hUaSjhzZTgg/kYJZJNZHvQrakj400S/TUS05+bl5qn4KODBDT4mLTXNFp0IygYhhJUR CBi5OowxE2XQOwzjB/eMH1DpDQbeKBJ5j5+9CffwFpOBYUSrRQ19f2WeD/R4A1Ig29Oadktm LhnSs/zROQX5ef7OtFu13I5bfktpWZEoFpeVWJh/VqYPkf9k/LJ/JOM3CkWTlXzJMxgei4aj 4nMi1jCxTCbDcDqrLkXHoEbZYB+S7UD+WfhGunDLakatanZY/JaFlmbLdgtnsLxjmbAwvEUm 49di4c3NAsMTFiuSzrNSmeWUxXSO3zZDFalGp3p4EyGVhF3Zuewfg4PnBsdXXcSL7vv+tpJL J0+O74ad3znKvL/i+KaKsQ+4HcHeJ1v37Bt771FlHr5KHttIOxi0Ra5iGg0I6MnDoIic6DJi WlAfaSsSUdhtz/HoFN36PMGNcgzdAZW5GiVyibvOqZ3cCHkx1J/4Yn4wpLyzJOV9jggMYKjk KgWPIi2UnVEyCMjYCW8bvHqR2xGRTV3M6+BUaHLJZomBIWKW0l0ejJ0kFzOo9O0mwpG3mzbM kMDNBEDzsPU8KXMhvPfBMtxbRN7elGu3Ydiihs081Akdwh7hkMAq0qABdaNBxAxodmkOapgK DYBGo81UA6MWxAGqgCGtWKsd0B7UMvRxVvue9kPtDa1K0gLW0unQzWtCWp6pCu9EXGdZNevQ l+oxfTTrJ/QsGXhKcLueK9DLS+pCLfoh/QlF1HNXqFITjrNh7UaOZFItR+CJWqBh1QYOsdaw Z7k0uoBYAGTm0KEQ3nH1U918Q36AqHn5geZ+Y4ExEFbvIiueC3hlDYCAQCz68Ud3nT0LH/xy vBp+AX9eN76de+tWK9aP+8cOK/yOJnraH4nurcW/lkMHMezB8LD6STUeVMMDqkdVeLMKFKN1 EEGe5h4NjtfAFhbMLDAxcC88BI8DG80/yB/mGZVaAzzLCoLIUfldxAmcwBBuZmgLtJjVWkgN 2o+0n2mZ17RwSPuU9pyW2aUFlTZVW6Xt0O7R0rTXCYSgpnx+KcYR0tJ96+uyVmBAYAoYMrvI yjAkD1z5OLRZD216qNNDhR5y9ZCsB5seWD1QZyl+Vw9Eezyjh136g/qTeubvAb/xmR4+1MOv 9fCaHs7p4SR1uVbp64iOc0j/lP51/a/1H+mFQySAlRX6wsuXQrsoog79Zj1DkKXqc/WYIDpM AzTxKf05Ak2JED6i1cNmWmmtvk3PTK/4y/VuVupk2sJO31SFCq7zNjVhWtRH9O/r8Ve25ddK rcxrFAGlpkrP5nUo9Cj+Y4X+3GBZqEAPSXpQVGt8g/KJKiDMWT0M6UfIQGQG9NCih1qqnMBM PTjJCkyLJpHV+ISe2K+kXI2+T0+hVWSssjwwWK0yIEyGa6A0YIouIANvJVkPPNM8lc1hc3Oa PbryTvl/O8nT9FWeyykoD5kC/cRopdNBWVAUs9Xvz88nNWdHTLnm6SVdArgFOhfodHCN/3b8 gx/DjvGvvQFRoHtz/GuwB34wXoG9OGp8OXxn7MbYu5FzForeG/Y3PioL3TMGZ+BBNzioqhFD RMCexEOJuDquIQ5Xsw0s3gOHAMP0UxZOcOYMZXLmKmQSTZLpuolVm0ZzoDQHvuSCTKlJEE1I Z+X8Nfj/wSkLapWD6KJnLMLqFqPYrCpexQeoPmtivrSrPN6/9dsBzDAMvEDtnrP0sAWr+CZf nXJEVq9VHJE4aexnDatj86UkVvAUh9LYa+MNiXlWu62rcfyT8f9Q/JAdT9078I3VET8kTIzR k9pEhmQyp+Xk30dDYcacDLwlYzjjiQwmR6wU8SZxt/h1kclNqErAuQmQQGe1jeh1BfHV8bgg HuKpkpeLqpCykS8LRB+lIxgrimCAxBQnL4g0FFUdRVZ3kayWUXpbQjwPyJ3uhno32Hi3m7cx hoxMMZMO2Wp/dqg6E2ZmQmomfJ4Jr2d+lIlPZsKhTBjMhNzMqsyOTMaeCTcy4RzN2pV5MBN3 ZG7OxAVKEUsmqDJBnSkaKBUTgqHB0G0YNLAaw+vej7yfeZmTXjjkhUEvdHih1gu53iovtnvh hhc+8sJrXjjnhSNe2OOFAQWkwAsWb7IXq7zws89p0XNeiojtjhQVvHYvJiVf8UKdt8O7x8uQ Eh5aCEiRD73w60ms3/LCQQVxvxfaKDTM9FZ4cdIk7JHPvPBj77tefNYLT3lhlxc2UwrbvLiM goLNm+rFrBf+w/sXL37PC697gbTlUQWyw7vZiydbk0xhgaVtkn8VadUZBZjSd8jLVHhrvTh3 st7uzyhOeG+yccyAdxfNriLNYZIpiM2Lb9AmfOTFB70nvZi0oVtpQAXNzfXiqWY+RTDgvUoT oYXSkEyqYvJPel/zvue94WWHFLbO9YIUYetNpdgJhTVbwxxp8zJxXriuMO/nlFW7vAe9Z71s qZcIMq/oxWqezth0YniV8TCThyQe+PgMxmBwp+uMoSwyppS3DcDmZqKsiuJLlFH6IrMQVjY1 f3mrZmVTJPVLzrev8Mvd5Zu7U+bdgfdLKnN4G+e2/246uCefCuKg3+/f0K94EQMRp94GT/iv if6jfxtcbsYHRJFWtGrGTb16EG2Lzs0rgTzznRH20D9/T21UawRBozarz1we/+czL/NRPK9W C2pR9dqPXuVFElareQN/cRR/P64m1evP8qYudozNYQvHXNHlzpS01GSHbMX/NWaPLUtIcpNY eSy+QvUQH9HdzhK9j4f3yFwT4E3hfeFzgbkgQLXQIAwKewW2iKpndgF/JsAR4U0B7wvHq4Vu gX3jfeFjAf9cgHMCZJAC3aTAEYGLE0AlgF3IUHAcEZ4hWPmPCWL8gQDPCHBIgAICi7MEAK0A h9cIW4V9wnPCBeFPwk2BrxVIqkcoonTcFPBJAYqEuQSESRZgn3CUgP2cpHPbBcALhWYBSwIY BOh8R7gi4FEapqkHBPa6AMeFUwJNZ/sEaBZAVs6hOIRSAtArHCcZnwo8EiDvUwGG5CZhRLgs ML0C1AjgV86xXBbglAAjAvQK2wUsCk5BFmoENnz05SJF2EIKnRDYUgGcChk8w7FR0IhlzEf1 8Sf4UZ5x8kM8Vqx8Q3R8iHdiMg/YZo4BxeDIJnr1W3RoQGyMOH/sw+zmOwy4qSE6NcxWNk1u XYZjk+N+2mAOgxJVndoqOS4rvvzD8Xh2D/v7m3Hs749FfIU80UE/J+uHiJfLeYqoPwKgLAd7 0CGECw1zDPgJA1Dpu9fA5DCVDP46MQs6mXuYBxmyFpDFg6UyuoQECK8EbBBFj7hVxKxoCT8q xFpxl3hQfE18T1R/IMLtOBcnAiuCWmSwIua1eDnGmVhrijMpj7mm5aZ9pqOmn5s+MKknTPCa 6T0TPmGCXaaDJtxiggpTrQk7TcCaLCb8xtXbADSBZlJA1WSAZqriaCZ8QEHhKMUEyykeCKcf /lKt4RdD4O6u7+qX6Zmslu2cTgCFUv+9GsPp4Wrl1eGKVXnTSVCVmuAf1HkHTXdn4hoT+E1A tSDMGzAZmGFNESKj5045+VVK4t0q4zTQyHibJggjKuGk+4DUsKEpLOpc7ulbFu2/Gr/n0p95 s8WoUpktVvVnF4mMkm2lFaVWa2lZqQ3/eMrW57qIXDKiRPSuXPKMHoYtT1ietTAHE2BTwu4E /AKCJ4kZjfYjPAc1oh7EMCcA+uEBeJSoxqsBZKCHEFOA2LHnJ/rkZcbqPnFIHBGZWrFNxGUi YLcYEIl2I9pNjVotQkbJKBtbjCPGE0aVUXaOOE84Gfs0x6CIm/32Znuv/YCdtdtRTPOUY5D6 DJrCnvFr2U3+pkCBnyQp9iHldHhTpznCdsWT4IJJL4LiugNFdaTOBKI17h9/dLz6Ij587yv3 l6XVPrAcRv7mrb133ngRvL343vkpuHrsZW5HXtehleUPrF0gjn2T+UReWeoY+1tGaNWUn4/9 GuGdgLpfQZh6AmJCGKvUVAAV8rqQWq0FrhGpRJWsYnhqYrPNnwIYoBR6YTsch1PwDlwBtRrk 6MQQAIeaiVC70znSpLTVSCwCmkQFjcuqNMkKnYzp1p8vMh+zvx+78Y2xf+J2HKP+hYlPuEHu EEpD35MX0uPfeJN+tx5vTdmXgntSYVvy/mTckww98bCUh0YGMhN6EvCeaMiM7onGnNqqxsoh YW55TWxLLD4VezEWO2PBEAuxSaJyJpHXh0Qxw5kBC93gdqNmB4sMogFLBtnQZxgyXDJcNqgM Bk2z1Ty5X0Of0ESbQALUrztlzoc33pQ3TNPnwxs4yal0ByA3OZDN0nO/TMy9r9wnV+64sGnx g+vqXMdS+w5f3Pzc+MT36pafAnTy38E3+yVLRcde9ouag5e3b//l47WeBWtmLVj4UFvBup+A 7vh3QHOhffR7xdnLqzLJuGfJuF9M12NkAZP8iw68Ge/BTId5s3mPmemGQdgLTLdl0LLXwmxU 7VThdhVs4/ZzuIeDLWgY4QJEPS3MJmY3g3OZOqaDYRpZCLGUrbN5MGMGLMiqSlHlqBiVCj5S fabCsVwmV8gxAgcfc59zWMXp9WwsykSFiBEQfIw+J3SJvJOX6EoGPG+zMilkOWBUDHzEfMZg 5hR7kcVsjW3UhiVbi23Edsl23cb5if6Gmy1mMzHG9bed6E0F/kDYyiIThQgVenRvAw2EpQcJ KOEC8i/SIdOtSsZFlSWBeiGjGJ5xsQe+OXb/t17Hpe/j3LEXxASbAXBUdILhLDbAsfE26t9i cfri8iyO81UsTh+fEZEt7YTHOmRHbXLVMzGwNQaej4a4aE90UfTWaPYZEeLISlZE1jJ2qwGO MDCIATXKftKQuCE5Diy3Z4+ZzA1Ls8oU2T0is6KJGI3KptgU1eG9Izq9WVt40yg81bn2nvM3 vzb2v+Ddb4P59d5Liw/+Yuv4/4LC3leHF+B3Rsf/+6UmbseiZ8ZvnT3w8weCN0+HHnmPykZl H4Gs2zokogZlJ0HWEBNNpHsJ+v9pM8E0tZmgPxZl4J9Gx5QNBUp7ZEshMEb3Zu/YVDDmBKy3 NxZ+8s6xyZ2Fd/AxemA8LHP8hKccypfTqYcOU7npJJKzhR1iT7DXWTVLZKni1mR4BAzTjBSe KSzzU7ci9Ui6rE9fxD/ldtyMi+gonURunCByIwu9Ij+wxwM9HihLWZyCuRhrzNIYpi4a6szA maympSZmi25Yhxt03Trcw0APhuqUhhSckwBb9fv0WNaARpO8wiG7XGi744ADO/xDTn+Lf8jP WJefQhcRdXQaSI2u5utJkJTExTZnmMVmTtLKWjyivarFWi3HTt0eoEeFm6iPuEnp8LeaSDxW vBa+c9IUkSCRjzksLpQdX2a6gyAvh+hmxohQ6Ww4DarvPfDaSJv7XGx11976oVe3Bcse+NH2 Jfs31CWML8dL/du/8YM1Z8Y/O92A31DEhq9u6/zcmUuLXWHRcmRpfFZe/PiJ8VhpWVkqlS7h tbSV8PBfIvuma+U5y1MgNgWEFFjsAqsLeBfUxoE1DpZHgz0aOozQpQO0XDZYwJIx5MwYysCJ y09pLmqwUwMGjUODNfZmA+tu5syTO6ZNXzXow+Nexd4hMW1f2jPl/qX57Pit77ww/sUL9SvO APfM08CdXvGTWdt/sPX+H24vnbX91a27Lm4tIi0e/8ulrtsis+MH4599e/vlgzWTba878h7p vaaJT9i/kbaWov+Q1x8qgYoSeKoI9uTCrhlwOB2ecYHWFefyuI662IaEZxLwPiPs4+EQBuWm wa5CaMmFbitsNkJmY0YGmfOjZjDPGhIa1bJoJivnzEbkEB2yg+EdZtFsC91rfsj8uJkpMsNM qsf6SdI9Mx+ceXgmUzgTzDM5f3NvJjRkwlzFq5GZzEY1twiwWIAKYkVRDob3V+mziV5GUbxM yqnmqfNckVPoit4wfVhFtiOcydP3WNN8XE7kcPr00RadyLF/qxz54ND45+P/lv5KVOHqRzuW PtJRUNr/jZaie9a1VKUvGnmtf+f3h+ZH/yAqp27rklW7F7lL1z5SM2vH5s55HtjdcGhd8PwL KXmNs5ITipvLKuvyU216h6dw0ZqqtgMrMjMWD9a4AjW58e7iRf7SRbnJJgPJrO1X5jCZyqyB yAYNWik7nfSOgCCo1+MRFlg/HAAMwKoYeqkE81jxYceKtlAFV8u1ccSWYkQSY8lipYYBFBO+ xBbw+ANhLkWT+UjPXSgTL0BmE5eTQsXIMegc/zHMfwqWHWGL//PZ39+MOXLH3rAZvfYK0hDJ mabzhJRjjMhJQhmoAFUjRismuEJauvFJveM4QwtA90hJouJrzCEZTyinGFIBzCsQNWsOisxV olMiURJlsU+8JF4WVaJsBdl6yXrZetXKhjf1oowhDb8isiXFq0FJTPCEjCAwWpkEtEhN5CJp If1O7TT7qUIdUEZBcxPdlPN4gLpEXHB7Jy41zQfUI0kU6ih6vuLZ3+EvGAazz7OjM6SM5e5b 9USuhmbMyFydxRwL76kR+Ur6RkfmSzr6pjx/EwubYnfH4i3isIjbU6AuBTJcDa5uF9Pthng3 2K2wKW53HFbFQVrCelktp2aGZDUcUIM6c8i03jyQuisVm1PpRhb1KF6SHYmpIaROfcQEK0xr TdtMjMYUa8Im/cYYHlLDvVlA9DAylE0F9CYKWf794QNCnlh6EySiLUfuYAVySrg7DzEq6rOK d1k7A4996/jQwuSK5sLc5jl+/rxQNvDtNd0nNxQHlvZt2bauLgZf2b7pxa9t2/ZQXfHyEkdi cUORcd6e9sLsVSMrZw8NrO1s7+guOBLmyQIiQ+yEJ0XoX+Wvb2GGGbwJ78Z4U+HuQrwpsDuA N/l3+8P665aU4RS83LjGiGMzwKqGzb49Psz7oDoNUtfn2mdQcwGn2dPsGrNz/YwZ9CCG2W8+ bmZGiFgJDmnXfxo+gJFrH4iNFR9OhRWpa1O3pTKa1NhUnOre6OXFjTu0sES7WrtRy1iI3j7t WAY9lxHmnf9agXI44/atFaPinm8ir2sbpmTHbc32zuMZuZSrHsgJC5FUd5JqGnsxb01kWHvp 4Isbd744UCh8X+2Zs3bOQ0crOwcDHasC65cX7d55z2O6l7Q1W7/RsPnZtYGkUO+CpfcvzoDd rY93581as7famL+iLHnPrgXNOaZj1ryV1Rt2bumNahpenlXU/tD8krV1JSIrFNX3IcSgBsL7 WML7DBREi9BFedem9N3peJNrtwsrZt+m+N3xeFPM7hi8JXo4Gm8xD5vxFh1sUQ+r8RZ+mMe3 +2tpZXslXjq3fS5unNUzC89cb81c7zAkOxZaweqwOjSkMwwljhLsKPGXHC9hRkqgZMlQiB6J 0SQbyjcVFMz3b4rl52+KnAxSuEzYfPsEm5GymKqq4jUxsvLdYTvcvjVIRXJeDr0uGBbNk2y9 e8fg7usVbGzBpnPbtr10T4F/YXtuUVOpq6DvqXUbn+nNdZU2BYNd87y/iytpq569qjTeVthR s7Qzz+iOr9hYt7C30ums6l+0uK8iAfY2Hl5fUrLucMP8e5flCGxUybKeojk7VxcUrt41p7Bn WVDHanKW3Yvn5dSXut2l9TmZ9SGfL1Q/9u1Ac3VW1pzWmbPWzM/MnL9OmRsCQvweIj997DK5 etALm4ywFe/DuBrDgG6XDleRvkgcTsTViQ2J3YnMJsduB57tWObodDCPZMHyrDVZW7OYHSK0 iQMiXioCOMMHT67KEySwE8EmBBWoFrUhJhfB/ijYEgVzo5ZHrYmimw+6UGxUZlRhFCNEwcdR nxNG6VP0OXpGFdmBjNLbYhMzEwsTGSERPk78nHDakeLIcTAqB3zk+IwofYl8LGRCITACwMfw OWArSkE5iFEh+Ah9hoian7Y1DQZsu2zYxqel0Y2N2KzMrMIshlFnwR+y/paFsz7wwTs+uOCD Uz446oMDPtjqg14fLPfBQh/ghb4DvlM+xifb40NOn+TDBh8IPk6E34t/FfE58XXx1yLDiGpD vuFew0OGxw3nDSqdQZYn7Kkhwz3SYelfJCZXqpLqJCZaSpOwSoI8qVO6R/qu9LL0hvRf0v+W 1KkS8FK0hN98g0D/l8TcKz0uPS2dl9huCdKlfKleYuwUBP4gwfsSPC39VMJHJBiWoF7qknA1 RQlqKUbC/yXBTyX4bjiWLoWkhyTuyBthuIcUrFw1xQmCZJfwv0p/kPDPJXhCelb6vsTsk0C6 tG17qECCTAlIjRoJPpfgj0qlP5PgvAR7pSPSM5RAIKQVSnOkRonJkCBWAp0EXWMSfCLBbyV4 SwJ54lUJnpPgmAQE7zYJ1kiwQoK5EhRL4JEgXgKtBLck+JMEv5GAUPGDSXj0sATbJVgnQbME 8yXwS6USTpDAIAGp4VOlhnckIPhPSfCkBAco7H0SXq5AF0mQJUGcBHoJ8m9KcE2CDyR4W4IL EnxPgqMSEPRbFfRzpeUSLlDIsSvkfK6Q81uFnDD5Tyrk36eQ36SQH5SAFnBIxByWtkvHpYvS FWlCUiHC9Aq+lsd8YhZjYNJkg22rbR8ZeE4hKmSDqLAe0GQM0I0P6rdrvn3N5Mvni7+8jzHl 0Wv+avAv31Lx3LnvcVc9k05C5aJmc/hWGVFCppEUoEemI1sgTYTwiDX/5UBkR5U6xzx3Ef33 d0YYZWeEIRFqO5kD3H99eENr1+h0ep02RvvZh+Otb4wZHVq91iDyUQaD6q8v/1VlMETxogHE mATD528w21O7/HkFhXlSR+qtHdyOWztKt80onFlZHl9SnBfNrLv1WHReUUl8eVVl1+BMZvvk /b/r7AKUhHLRd+R7lvrb/bjR0+PBBc5qJ84VqogyC3bFL8OqOBu3mdvDsYKtSnZrt0dficbR +UNZsw0MaBhnvpyP38kHlO/MH8kfzWdrruTDpXxYmA9D+SfysSHfn48v51+nIVDb4oyiNr1G JSZkT135oPdj7r7UN+2iTKQ3OXpNxqQYAJGbe4p+qJzhckcxcNcSAx/+4tI/vVneuShoVy7r fQ9zyjY1ji1d3Alixtw1ZZWrgglxwdYq+msAFrCRv1iIj/FX+e3B3DTGOLLnZi68HJtvj08I zJ0RjUs2n2jJCHR/c/3aE12BlNZnqA068YvxZZE7xdEQkA/zMToxxKertSGGrbLqiKFqFa1O q2xleas1xj5ih9Lw71jgD+zyu78KXbZfteMD9ERXjR0b7A7FDzth50bsJ5QfumAXUnA4UWo/ Zb9of8fOfmqHUfsl+2U7U2pfSKAZpx0OKFkMgesl2ZdpHQfsmPpzj5NiBJud6qy1CxeHrtiB Yh61M347LU/LBO1yTn6ozz5EqBu1s5QIPGEHu+xODRF6CQEkRrNprVftnMMONoNYI8RN3ni+ Fr7ATSZZPz1WRMf+ZE9O+tmVTUQaoDd7yCQL+EWqBiOPh96JNkZ+4iEn8hMExsDes9bcplDS rHh9sj51RrwmfF26saRnQRbL7cOsxVPuY79D9arJs3M25EI+dFReezTmuRj8mBN2O+GxLNiU tTsLb0keTn4imeG0Vm2KllFhG07FzHMmOG6CNaatpn0mxhSvb4yWyUIdHU1tY0eSPwmfSoIk aSg+47ZLzJTevD0e4uMz4pp5JmPSN0ZatIGqqStv366mrmOiRZH2Tqn6U2fspnzjiWTIpkYc ZuZpbvI/1j7yg66x1zDadH6o3FXeXr50Z71v/M/HDo5fhFm1AyHnohkrdtSMH4ON1VsbsuHh NYebvdyOtNodjUVdS4MGTWHjPbisf9V4mStYN/bD8pXF8eNsTHFbWMfh5hNeiehP8ktzohqj eqKYSnYp284y+w1QaGg09Bi2GNidDOQw9Nr5JoYdQLsQFojCArAVQAXwP2kZgoBjDZmGQgPR KwzwB8PfDNgwk5iR2EmMSFEESWwRR4gVeV3kxC+5W/FFei7PVGPCkqnFNGK6ZLpu4vwmMGBm UACBbivSk6K3fax+5SpLWDpP87Le4a2h+zRwe98ZAkzU62M/ehP2GBJ1UXpdlC7BCLveJELT mdXgzkhLyXATJePqpO9vXDlvPf8lnuEZpFHOVfPakEaj54TbXj+nHtTN2zngOIFtJsyJuADD Q+OOLQWiWFOHIN1TCH+fZrNuPcpk3/oFc5jbcWy8+Ilx6zFad7div9IzoRVy1hbtsBZ3EyNp vUqFanQg6pw6rNM203vkTkJCCxpCHEK6Ab2Ki5ncet1APXpUuafcAJUGW90zY3GeK8fF6nrO DM3+Qc1DZ9vHtMy32U+/Nf6r8X8e/9HZZ6ASCsD3mGIvcqh64obqPe5hZEbRyINK0RL0nqzd bNljwYO2vTaceX7iD3KUWhdKiSEPJ33EkqQXydsYeespiIkEeJrL0Ict2kLPAV+Xa6PFaGu0 FaXlntWcQWfpAQqnl0Fe2YvD4Rpvi7fPe9V73av2ymcTzsw5a0iDT9Mm0nCarNGH0haeSzpf eS6GtTFW04xzhvNF5xTP3Y1r9LjTDer33dBP3oQL/WM3IoZjfr4xYFSu+Uc+cKcxQ5cXIAMm JTJLJ9O/tLrcFVe9F1g2UFa2cekMqW5TBXln3yw6yjzx5M0rcn/djOylA2XlA0tnzKjbzH5h 85SmZ8peW7SnNCOt1Btz87otsyTdM4umyJmpJd4YOHPfc91ZWV3P3b/7hc6MjM4Xxsjw1GV0 PL/z/ufX+Hw9z2/f+XxHxq2U1TsXOF0Ldq5qHlqYlLRwCG9b9QBNeKC1+QGa8ABd52vJOEoj dmcKsTz3yhWbkncn403u3W7cGNsTixut0Bi1JWo4imnUb9EP65lC1RwVFsj4Hs24lIEzDqWm muOq4lEVMjvNsnnEPGrmzHQSRKd6Q2azq1lzQIM1acdS58VBXEyzi6V7UE3+sdebjIrf45pf MS83BMKOvsnfnKEsV/HuEj7s9ZiyyomlbmXTUkoWLl5YmgancFrJgpr5xSnERivffzLqvLZ8 8MUt/We2ymMHfsKqZ69dWl5cWLEkr7KrprSgoKq+qGhFqXP/Fl3t1/tm5XcevPnkm2/evjdR qszjJ+TO5wCeBBhWP6HGw0CdXUwHhp38Yzxu4+FJ9D2E16CtaB9iGhDUaeCoBpLpod4e9Rdq rNbQIxFYOdSL6M/u6Hk8bSOV1wBmWTXHINY0eXoxvC4ov+OQHyjwNxUENhgjxwoj9nSEK9OP 2bKLx94+f/Ei/u6/jz2Nyd/+sQ+5HWMl+Mdjx279Z7hNM8jid44tRAJo5QVPEu2GGKvQgLsx fpT/Fo8H+F08ruLr+A6eSaenkfFWFVHkLKpk1UnVWdV7qg9VPK/iGS0UwXJgNCCn5YVANlpC oJxKTl/RFrqkhbNaOKGFg1oY0sKAFlq0UKsFWQsztRXaNu0uLasAO6sXh5xasGiBMKU0nHNS y7LaZAVMAXoxUBJSgE2OtNBVLWCkdWprtH1alleS9aIlpGJqWAPwNfSocvg6u0c5+ekJKxGe 23q7x+/xKGqE8pNYzVMCP5AD9FQIuKwz8NfHHmPyx3rwhb1M6r69t/5tn8K37eP1+BtEX7Oh MjnrQT08KEC9BeoxGGOijCGOPkSVKKqGVFil/QuV8E6iZYhxRLzSXwJquvZWU362chJA2QCJ /ILE5AW/7ZmN+1tfWLm33uOp37vyhdb9jZnYsm/8j7/p7v7tn8b37Rv/hIR+88ex/QotOkKL R6ElJOsf0sNDAiyzwDJCCxWflBzyPqtQRAWm6FAdIFShvxwgQ09E9FYnpWhsOkUweYJz8qoa 9nwFSeL+MUrSbz6hJP3pt5Sk8X3hcZVF5koGmStqvES2JPKg44HotIaQkQOGA5GeyP+DPEES ODYKgzqK71Y/o8YqtU2dq65Ss1FqFTSm4jp8CDOb8UcYF+BqjFUYRHxE84zmTQ1D5pSgKdBg u6ZBs1fzuYZVaeBnn2vgI5pu17xCYNjXNdCgGSTwTK4GMgj0K5qPNaxWA0cI4OuaX2vwGQ2c 1MAhDTyggQENmagdGlxGp+pMDTZpgNXADQXla5r3NPgpzTkNflQDuzSwWQOrNFCrAcU1Tma2 TQH+C5nilzVXNfg1DZzQjGrwQQ30aaCNzAsNWDQULVn9oftDzQ0NvqyRz5Haz2pe0zBDmhEN JgTUaFo0uEIDTorOosGk9quR2kdpfW2aAc1BzUkNJ2lkpV5EcwmykXCBZE2FplZDbxHwBVcp pSdJUaaPZtLKKQJOqfySBs5qIFKKZuzScO9pPtTgCwpHSAksUVoMGr8GI6aImctsped01Wz4 VFbAVEDsV5h+VOZL52S+bEY333HC8O7bwVOnt8JnCMl7rOAX5J3tgRhx/kd0cDavDB8zJiJO OTvNCD8c+4934Xvw3Ls4NHYeh5iCsVZ8PLyv1xXxUyejfHRKlvZbYYtt2IYb+G5euSa4hWFq cRvGte4294CbqU1qSxpIYnISKxPx7mzIpnMliygIu2IhJTYntjJ2UyxriwVrr8WC1sv+lOMp eCQFUgqH/AnrRY2TLGBUAMUkpoY0CZmbnM6ZMRvt1iNWbDXwMyPXJwNNyjqWraxpd/6GEm0X mnLlTyoTt29TTl2HtYajX7pbaS/a+Gzv1vNbgpUPXNgcur9zQfTz8VsXzbm3NmvGmY0tx3qD LyeHeqpmtC0KpM/tKZvVGUqFt3tOb5+98jTAyR9A/A9bEsvX1ziWL6ra9+7+5c0lm77bV715 SVbCrJ55Cx5sK8xauoXydC5zHjdHzgY0yIVGp9YYYunDItOH/ZCepwFed0hzeIhuGDsQVqPo w/rjcafisCb6mB4h/TMqC0MWtg+zqflG9Npr9H7VtWvZHhL1UBEEOZOWecDqmhaGwxpzgmVL 1oz6sb9oLImWwazsBub8ozPrwrvtP7kdupvWNa8gceLqi4Q05TcH9SRgO6w/FCMcRodUyslD kqIiy5NB69BitVbRTmJImrk0BmImiY/hONMz2pg7iG8KeH6jDNKxa6Jy29ADtw8GBLhpYdys MVOaZ9T/ePylqcMC7PWcSaK/lnObfOU318H4p/de9gnNhuK/Ikf4975/MfxbmPxNauo14PcQ yU9/DBxHEkkuXzK+AJVP/a71FHzkU4k/QRXsRvQILkAO8t7FIlRAwhfIF5F4HbyBhmmcvPeS +DISTsDPoodoniryVtKfRcvpgRwS3k3ey8ib5tWQ72LuDfQ0KXee4iRlnubqlPir8CDqIrDD 5BtN6+bemBhj/xP5WPrj96QMCT9N3l0Enp3EQeCeVhWgTvJtJelNJH5Mgd2IOsl3Afk28A8j IUz7xC9oXeQr0DdJ6+YTUDV51ypxhGYQureTr47Es0h6FwnPJX/040WH0N/gIC7DffhxRs3M Y9YzP2C97FPsDe7H/AA/rn5W/VPNKs2vtfO039dJul/oY/WN+sao7xsSDV2GPaLT+LypzNJm XWUbjV4Q/XiMN+Z39hL7Q/azsXWxb8UdivtNfFv8nxOeT9zmvOF6PKk+6c/uPe7XklXJf0jp SXkvtS/1XBpKL0v/JKMs41uRnqsiujeHwhJNRH5EzEXmG9wlok3QHo+Huqn+bZnqa0AGEoNI KR71RsIMikWbI2GWwIxEwhyxD49HwioS/l4kzKMt6EIkrEYWyImEBRQF1ZGwltCwbOp/CPDB xkhYj3rhm5FwFCrBIqkdWIHELuEFkTCgRCYqEsYoivFGwgyayRRGwiyBWR8Jcyie2R8Jq0j4 6UiYRzeY1yJhNUpnz0fCAopnr0bCWpTP3oqEdWgFNzMS1qPfcSORcBTaplpf3ts32N/d2TXg TF+d4cyWpDzn4vY2Z6h1wOusXr/a55y1dq1TAdjo7G/f2N6/ub3N55xXXVa5eFZt9cIFzu6N zlbnQH9rW/u61v41zt6OO8vP617V3t860N273rmkdf3Gxe2dm9a29s/auLp9fVt7vzPLeRfA XdG69v6NNDzDJ+X5Arcz7wL9H4gglHd2bxxo7yeJ3eudS31LfM6a1oH29QPO1vVtztqpggs7 OrpXtyuJq9v7B1oJcO9AF6GzZ1N/98a27tW0to2+KfLLe/v7eiMUDbRvbnfObx0YaN/Yu75r YKCv0O+/5557fK0R4NUE1re6d53/H+UNDPa1t7Vv7O5cTxru6xpYt3YeIWj9RkL4JqVGQs10 llX1ricdszYM43VubG93UvQbCf6O9jZCWl9/b0/76gFfb3+n/57uNd3+ML7u9Z3+22golkg9 /3eliRzuRX1oEPWjbtSJutAAsQTS0WpiRztRNpLIXx4JLUbtqI28Q6iVQHhJqBqtJ1A+EpqF 1pI/5zQMG5VYO3m3k/dmpSyFnEdKlaFKgm0WkRrVaCFaQFK7FfhW8h0g0K0Eth2tI+9+tIak 9aKOf1j/PFJ+lVIPzekm8OtJ7hISW0/w0nKdaBOhj+KbRVJWk5T1Sh39BC5LoeofYfjHuXVK zsap9BmEIsoxHwp8Zcl/jPX/jhNhnncqWAYU3GHIbgX3UgKxRIGqUUpSLgwota1XoGq/osaF pMYOUp7y7DbkagX3AImHMfeScFeEnz2E1/0KBW1Kucm2bSQ1f5n7dOz1k9HXexePKHWblTrn K+kDyliieV1KrA8VkpXGj+5R/nwE5k7MqyN4fUpoHYH8f1tugMyMPoWP7UovdxLYcI/7FJz/ p5iriWkiiMJ9O0D9OQxixKrB4SBK3MRKCcYDpBsOIwaTtsImUAzloBISpU1mObeJYjgAW5LK BRO4FiEdIKQ1UagevcCFm9qKel418URIfbstCRg9u8m8+fbNzNv3vnmTzM5hHmNm3akwNOrk u83Q2KEYy9z8K8u4U5dXzKMjduyZtWt77IH3ouL/Q+c7ZdZiKKPI+wOH7WuOdtiJcQTncATR Yf/sGRuu6P705sCXo/H8z2+Tyj7yCu56/vKsHNc2wG3fUO7IeajSpiG/D5l9cO3DicAeNO7B r2Az+8mb2Q9+lX3nKotYcUuhVsCKWKaVsapPfvt6kX3Z5YzugrbL69nnImdbxULRKhKt2HqD F7mHfewo6J86iF4Aon8gJUZ32I7iCO295wLfegdv8u3sbfAye73RzEqvIJiL5RI54lwelqvz cZb1ZwPZaDaenc9msu7Y6sKqXCV0FZLrINeBrsMxuuZfs9ZIQialImVebkvizfgzysKyXFby y9vLinfJv6TMv4T84vaiEkibacWbjqY306V01Yu5Syw4B9FZ2JyFWd7AnqfOsnjKTJVS5PqM NqMkZiBmJkwlaULe3DaVwGRkMjpJnvESmx+Hp09amCH8TGAE0dF2Nsrb2Hnw6OdaPbq7leg1 GPMQtkWw3OMtbCDcxcJYn/bV6dXISZWP6FEClPiJYoVKIUULtd3kWqipmW9pvUG4zRtZF9q8 hSXDocAtriQ41PvO6KeA6rU+qivg0sEFjFE/jdA4raLUSwM0Sk1aoCXq9qPOogS3iol6qIYc JFd6e1S1O+cu3e2W7uCAhAnZ1GNLLRSWNRPSpYcH+vDvcbp/fGrK1dnQLX09fXKoob9b3keg 2SCBoLZhpd7V2W8IY6x8Vl4GLkNVhbCRff9C5SQdHASqwGbsJgyBL8aYS6jCACFwIRuoFzCI WAhbLQBHYBFq2TxaQMODaACFUTYtBPYXOF54BjGvfwMn22ztCmVuZHN0cmVhbQplbmRvYmoK CjEwMyAwIG9iagoxODc2MAplbmRvYmoKCjEwNCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnROYW1lL0RBQUFBQStMaWJlcmF0aW9uU2FucwovRmxhZ3MgNAovRm9udEJCb3hb LTIwMyAtMzAzIDEwNDkgOTEwXS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgOTA1Ci9EZXNjZW50 IC0yMTEKL0NhcEhlaWdodCA5MTAKL1N0ZW1WIDgwCi9Gb250RmlsZTIgMTAyIDAgUgo+Pgpl bmRvYmoKCjEwNSAwIG9iago8PC9MZW5ndGggNTIzL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nF2UTY+bMBCG7/wKjtvDCjxjYCNFkbLJRsqhH2q2P4CAkyI1gAh7yL8v77xuK/WQ 6MEej5+xGbLdcX/suzn7Ng3NKczppevbKdyHj6kJ6Tlcuz5xkrZdM8cn+29u9Zhky9rT4z6H 27G/DOt1kn1f5u7z9Eiftu1wDp+S7OvUhqnrr+nTj91peT59jOOvcAv9nObJZpO24bLk+VyP X+pbyGzV87Fdprv58bws+Rfw/hhDKvbsqNIMbbiPdROmur+GZJ3nm3R9OGyS0Lf/zZUrLjlf mp/1tIS6JTTPy5fNwmJcebCSc7AnK7gw1i24NJYDuGIe4xfyDrxizBt4y/EV+JVcgHfkErzn XgJ+43gFPpD3C7ucDE8X/R2Y/mIx0R97ueiPvRz9S9Ti6F/CzdFfUa+jv1o8/T3Ox9FfUJej v1g8/b3tS//CxunvzYH+glok+r+C6V8hv9C/RO0S/S2e/gXqFfpXOCuhf2Hx9Pc2Tn+PGiX6 43yE/t7y0F/NIfqjLqG/t32jP+5U6F8gp9JfkVPp73GGSn+Fj9JfLZ7+ihqV/gXyK/0ryxPf H7xXGv0tD/0L1KXRH/ei0d/y0F9snP4KZ43+qFHpXyG/p7/Ax9NfcEee/oVx9Me+Hv6SO5yP L8h7a67YRWgzfAf+tG/afEzT0rr2sbCeRbd2ffj7PRmHEavs9xtmWw0ACmVuZHN0cmVhbQpl bmRvYmoKCjEwNiAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9u dC9EQUFBQUErTGliZXJhdGlvblNhbnMKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciA2OQovV2lk dGhzWzM2NSA1NTYgMjc3IDU1NiA1MDAgMjc3IDI3NyA1NTYgMjIyIDI3NyAyMjIgNTU2IDI3 NyAzMzMgNTU2IDgzMwo1NTYgNTU2IDMzMyA1MDAgNTU2IDUwMCA1NTYgNTU2IDU1NiA3MjIg Mjc3IDI3NyA4MzMgNjY2IDI3NyAxOTAKNTAwIDUwMCA1NTYgNzIyIDYxMCA1MDAgNzIyIDYx MCA3MjIgNjY2IDcyMiAyNzcgNTU2IDc3NyA3NzcgNjY2CjU1NiA3MjIgNTU2IDU1NiA1NTYg OTQzIDU1NiAyMjIgNjY2IDY2NiA2NjYgNTU2IDg4OSA1NTYgNjY2IDUwMAozMzMgMzMzIDY2 NiA1NTYgMzMzIDMzMyBdCi9Gb250RGVzY3JpcHRvciAxMDQgMCBSCi9Ub1VuaWNvZGUgMTA1 IDAgUgo+PgplbmRvYmoKCjEwNyAwIG9iago8PC9MZW5ndGggMTA4IDAgUi9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoMSA1ODI4Pj4Kc3RyZWFtCnic5VdtbFvVGX7Pvf5q08ZOKVGQS328 25RkTuy0AZp2oXES20malDgfZnbKWt/YN7FLYlv2TUo7qmZIQOXS0cFWYFRim7QNbUi9btmU Th0NGtM0aQz2Yz8YBCKNfzRr161oAtrsPcfXaRJakMak/dhNfO/zPu/nec859rlqdkKBNTAF Inhj43JmPSGA1x8AyLrYpEoX2rwU8RyAUDmSGR2vaXznbwDivwDMxtGxgyO/+fNPawHKmE84 ocjxlianB+UwyvcmkOi8ftCM8gmUNyXG1Yd9cNGA8isoW8bSMbkO6hCWncebaVx+OKOaDjP9 6yjTlDyu7FZ++F2UP0Dznkw6p8Zh0wLA+gamz2SVzNWhZy0oB7E+FTkCvHwcERATl//PL+Nx uB06jfeBFTL8vuwSX4Y72HPh4vL79Z6Fj/+bVViKj+fgJ/AKHIe34Ru6IgBBSMIEMkuv1+BP yLIrCEPwM8jfIuzLMI36ol0UnoLnb2EXhGfhLPxuWZYgjMM3sZZfwNtkC/wel0oarhALfAt+ i1GvILf7ZqGEcryNcDiyhH0HXhCOwS4B1ylWgRrBI9jgdThF9mJkFcd5fHHEzZ8J+gQcxvsA JGASMb+M9336F1i18A8c1WHYBY9CK4wt8ThPXhRX4/wNwovY09c45ykpzZ3ifuGXgnDtGRS+ A6P4kQmOXTgutoLPWEFw93n9kXBocKC/L9h7/+6e7l1dnR0Bv6+9rdXbsvO+5q/t2N607d57 tjR43PV1NXdtrt4kfcXpqFpfYbOWry1bvcpiNhkNokCgzi8FolTbHNUMm6XOznomSzIS8hIi qlGkAsttNBrlZnS5pRctR1ZYeouW3kVLYqPN0FxfR/0S1d7wSXSaDPWFER/3SRGqzXO8m2PD Zi6sRcHpRA/qr0r4qEai1K8FJhN5f9SH8Qplq9uldmV1fR0UVpchLEOk1UiZAqnZSTgQavw7 CgJY1rK0mljtl+NasC/s99mdzkh9XZdWLvm4Ctp5SM3Urpl5SJpkpcMxWqibyT85bYPhqGtN XIrLD4Y1UUbfvOjP55/QKlxareTTag99UIUjV7Q6yefXXCxqd/9inu4bKYlmrLZJNH8VcDjS /MXljKwzpmrbVWAwgO3N5wMSDeSjeXl6YWpYojYpX1izJp/xY4chGEav6YVfHbNrgScjmi2a IDv0wQb6u7Xb+vaENaE6QBMyMvjfIjmb7M6KSMkmeCs1YCOwHdhTp5MN/Ni0F4ZR0Kb6wkWZ wrD9DHg9rogmRJlmpqS5PcQ0UyXNontUwtnsHgjnNUN1V1zyY4+PydrUMK6n/WwqJJtW/pHd KeXXVdDtngi3pVhVVzxJNeNmbAt6LXXAlcJc8jYulH9UfMzbMcHminV0u4RhWBy/5I/q/5OJ KgxA6+u0Tldx6gfDmteHwCvrc+QvNHjQQ47iFCV9fPo0j5TR1ktti/PJyvInB8LcRXfT1rdr EI3pXprH72OZqT8f9RVLYLGkvvA5aFyYK9xN7Wcb4W6I+JhxZTuuq83+fDg+ojmi9jjutBEa tjs1bwQnOCKFlQhbaNih2jlM5+QZNaF9MNw9IHX3DYWb9EKKChbOUO1fEUYK24thcMlplmoL DQt2MYKGNiRoAIHU1ox3zVxtwY8NG85ZtlTbmmmY2KFkjWVotdSv+HQ7Ji8LamTLqb2zFM3E RIzT3ml3RpzFq75OQDXVE6OHhTW1s6QSq/GbADkBw3CK9bKKrXkalhQpIiWo5g2G2dhYe3iX 9WbwnutzNbhMWtIsbBM4UV0SWDO1gMu+tLlaB5cXxc4V6q6SmuYtUvdAngWX9ICAlXdpwJaw t6nCznc/289SQMZNjDua7+d8wetleznBtm1e6ornpYFwM7fGb5DD9kMs1zroJt2DbfV1+GXW VpDI0b6ClxwdGAqfs+GR6uhg+IxAhPZoW6SwCXXhcxR/KzgrMJaRTKBMYJH6UbBwe/s5L8AU 1xo4weXYNAHOWUocgdi0UORsJU5AzlDkvJxjF85SVQJ7jN/ffhpn8/NIJJGPRtgah0rsCP4T jUg7sTvSzgIRTGu01ZLSppVJbYxvYXxLkTcx3owrg1SS+rpDeZtfulpVz3+6wYe3uDGEJ2Az uAsEPM1nzAbL/NaCyfhu8xlRQAgFkdFGRp8xm1Z92nyGML6xwllR7axw+gR6fRN57nrCGPr4 5z7DG1A8eZKKD5+59ug9+6zNV8FRPAP9MT+77EzKM7MDkqATqDU7r/vh64smK8+wgnARfLp5 8fhM+DhKMQSw4VkAz0WGMtN2HBVjN5AHFuNEF2MStIzqWMDRZ3Qsgh0O6NiANk/r2Ajl8CMd m/AsqenYDIfggo4tsJ5s1/EqKCe7dVyGNexZPJ27SSn+WkiTH+u4HHYK6zE7MaxCaUbo1zEB Kq7TsQDl4lYdi3Cv6NWxAW0mdWyEDeJJHZtgo3hGx2b4p/iWji1QY3hdx6tgg+GijsugyWjR 8Rp40FiKvxbeM57ScTk8YjrUns4czCZHEyqtidXSrQ0N22i/EqedslpHu1IxN20dG6PcIEez Sk7JTipxN+3pavP3tw529d5Pkzk8FqlZOa6My9mHaHpkuX9PcljJymoynaIDSjY50q+MTozJ 2dZcTEnFlSytpystVsoPKNkcE7a4G7a5G29oVxp/QSFY/WgypypZJJMpGnIPuGlQVpWUSuVU nA4uOvaOjCRjCidjSlaV0TitJrDU/RPZZC6ejLFsOffiCNrT2UxaL0lVJhW6W1ZVJZdOJVQ1 s8PjOXDggFvWjWNo646lxz2fp1MPZpS4kkuOpnDk7oQ6PtaDBaVyWPgEz4jVLO1aIJ3CyRkr 2tTRnKJQFj6H8UeUOJaWyab3KzHVnc6Oeg4kH0p6ivGSqVHPjTAsip7ny3lDO6RxDx6ELL79 jOLbgAoUaiAGtfjcCg34tw1RPygQx2cnyGhRh6gLUmjlRsTeEsbweSNCjksKPhV8TnJfZtmD Xm3gx2itMIi4F+5HNsntZfyoaC2jrYLvSTLih5BL45vN5+XvQf9hnodpkmifQu0AZ5LoyzxH 8W1vjEdsxVwxZFI8SxYt63ldnx/ji/QPcJRb1GzBuljf3NB4U98vivzlOlLs/SiPovLYRcsk jx1CiwFuFeSerBcqz5biVoM3ydiLGUfQn3XuhmWMx1ZRLkZOI07oXd2PHc/yCuLcrzS2HGb+ 7BywNZjFVZhe0SVW3STPuZvzKl9TTJfgUgZ24K+OB3832J8bbZZHjulx3RyNo+V/6qfiDsnw Pip8nkfRtjjnbh5zHNdXj96hFF/3rEMTS8ZY7M2t1lqAP4s7Z2xZHDaz7Ml8S9Xn9PpHeJ5i 1zJ4T2PfFd5tN2dH+RiTOIdJREvrYzM2qnMrqynVsnw8/8vcYvEQseDEjDe5CquirxIz/mK3 8PsFYvBGyNw18uY1Qq+RI5+Q4Cdk6sqJK8LfL9c6Tl++cFnovbTv0ulLYsMlYr1ELDBvmw/O R+cz8z+YN622XiRr4ENS8de5Jsf7jbOh9xrfDcEsaQ7OTs1qs+L0wox3aNZSFpglYuhdsdJh m6EzDTOZmamZt2bmZi7PWKZePfGq8OvzHof1vOO84Djbe/bIWTH6ErG+5HhJCL4QfUE4cYpY TzlOeU6J33/e7Xi+Y6Pj2ZN3OeZOXj4psPD3nFxbEdj3PXLk6aeeFjKPTz1+4nFx6rETjwmn Jy9MCrlgrSOdcjlSHV913NFYFTI3iiGTuOBgnr7h6ppAdJ/XsQ+N9gw1OIY6ah23Na4LGbFY AxpaRYfYIvaKafEp8YJotvQHNzr68DMXvBwUrL2OXk8vjnDOK3c7MdCuzK6pXWJXoNbR2dHk sHY4Ojwdb3a833Gpw7Svg7yI/4HTgQsB0Ruo9QS8gY3OwIZOe6iy8faQrdEaEgiESCOEPNYF q2C17rMesYpWaAFhqpIYyTQ5URgccLm6p80L+KZvCe7RyFGteoDdvX1DmumoBqGhPeECId+O PHb8OLTd2a1tHQhr0Tsj3VocgZeBKQS2OwuV0BbJ5VQXu4jLhXAC7+CaQGpvrkiCq6QGV47k cpDLERfTcYgM5FyMZgzzIei5NwfsxrQubsVQLle199/GcCR/CmVuZHN0cmVhbQplbmRvYmoK CjEwOCAwIG9iagozMDgzCmVuZG9iagoKMTA5IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvQkFBQUFBK0xpYmVyYXRpb25TZXJpZgovRmxhZ3MgNAovRm9udEJCb3hb LTE3NiAtMzAzIDEwMDUgOTgxXS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgODkxCi9EZXNjZW50 IC0yMTYKL0NhcEhlaWdodCA5ODEKL1N0ZW1WIDgwCi9Gb250RmlsZTIgMTA3IDAgUgo+Pgpl bmRvYmoKCjExMCAwIG9iago8PC9MZW5ndGggMjIxL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nF2QQU/EIBCF7/yKOe4eNtCemyZmzSY96BqrP4DCtJLYgUzpof/eKVZNPEDyeO+D N+hr99hRyPqFo+sxwxjIMy5xZYcw4BRIVTX44PKhyu5mm5QWtt+WjHNHY2wapV/FWzJvcHrw ccCz0nf2yIEmOL1fe9H9mtInzkgZjGpb8DjKPU82PdsZdaEunRc75O0iyF/gbUsIddHVdxUX PS7JOmRLE6rGmBaa261VSP6fdxDD6D4sS7KSpDG1KdnjdKf2sX7agFuZpUmZvVTYHw+Ev9+T Ytqpsr4AfVltdQplbmRzdHJlYW0KZW5kb2JqCgoxMTEgMCBvYmoKPDwvVHlwZS9Gb250L1N1 YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQkFBQUFBK0xpYmVyYXRpb25TZXJpZgovRmlyc3RD aGFyIDAKL0xhc3RDaGFyIDEKL1dpZHRoc1szNjUgMjUwIF0KL0ZvbnREZXNjcmlwdG9yIDEw OSAwIFIKL1RvVW5pY29kZSAxMTAgMCBSCj4+CmVuZG9iagoKMTEyIDAgb2JqCjw8L0xlbmd0 aCAxMTMgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDI2MDA+PgpzdHJlYW0KeJzl VutvFFUUP3dmH6Wv7WOhrQv0DgNtcWf7hAKxwKbtQrcFuu62OKubyHQ7tCX7aLrbCiYEiIq4 CSQmBkFJaEFjiIHcrsbwQRMNYvxgjRpSjC/8QMIHxEQTE3zQeu50Sivpf+DOztzf+d1zzu+e Mzt3Nj0yqkM+HAURvNG4NuwkRACALwBISXQsTSMrTlkR/4xcYP/wQPxGTfYOgFCPpz4QO7T/ o7vHrwNYzqDP5kFd63ecuI9z1q/Qv3kQiRcePGUHsOWgvXYwnj6YRyrz0FbQzo8lo9rnEEFo 24yXnLh2cFgRVxG0vWjThBbXT3957C7a+wDEg8PJVNoJB2YBln3L54dH9OFy9++X0b6Pdi2e BA/+yUdo47YA//vPa/AqvAKXwQ8XIAx1sAEUaIR98CTI0A6tIMEncB2+hmvwFhyH03AM3oRx YPAOeOEIvEjOQYU4bd1uvQTPWIsZKAxKu9jjAZV1joUZyNvLmc2tbg0b3OEwvcFIaW25hxGF fsfy3R4mKF1B1SeHJQ8TlaFyyrwBVWLesIdZFB4qydLz6o+uqbAL/dQHrnthlywxq1tlO8bC xkQ4jPmsSkHkaQ+zKZNryAlUpyciERcDTGNXJtcalPchlaOUFNMtdR62TKGHucinmIYycZ1f psxS1ckgoGb0jEY52OySpLArY1jBOYsL5s6trshVJGHGPIV+Y5STr9A6ZndHVEp3yju0A1Sl /X1zKbhfAVdGaZqhOzM7NDlDM7IhJ/PkzIueWB8nmFfnBsYUGkpbp8slyUWnM9gGDPLjanrN tUmGm0OR6bQpLlO1K+SSGAmrGSzIL2dkmvFnZI0HzIXwwcOK+G0owXUX8wI4KHmkgAwfZO3A vsWV8NBSBYvIvMzb1tkvZ+yMBtQW18c441TeAy/xtraSrqtFEAXjyp17VX4NqnIfrl5udeFA 5FbsvDeoZoFCW7Q1SyjBgdEoq9BXzmstVxiy2Be8ePivVsDfJgj91l7cmexQO0mgriVrtzju NU7arD+0ZEUBIUyKnLZyOmu3Vf/TkiWcbyqWitdJxVK7QGfWkjMzg9bev95tt0wB3yFu4f50 xDIOBbAOssi4mX1qfiSssI5ZplneFH4nHcQN9Q0Sra4q2tQs0bIVRXab6Jn57fz4+HniIAUX L1y4ODEurB6fmJh4cHtigq+bzN6ZPSa+YamAKoDlVdVE2LihqbGseVMlIWWbVpTZ7DZ7qdNe ZpPXiAQv1VUbN+QVksMnawqdlWtcSVLuLa+sbO4Trry/vchRU3tp5nvpie0kVyh3CCXkqFhl tZUW/E08FRWOlQPPCZ/NvL7e7XSThplNTU2FqwuN/W//2bPJiz+lnnW0/AGVOcYmMPXn2xPz GwJfofUIdhb3XJjfIDHOvvfBkUX7BnlkHxGFX6DdFoFb4s1ZfAfgLhKBc4aXCNVmHgFtAVbw YHE+vhCuPMyVfZiXQC5axIyyw4cmFpG/ZmIL4ikTW/F+3TSxDfnb6EksyzBRP/xqYgJOIWhi AQqF/SYWkU+b2IL4hImt8JhwzsQ25D+oia6njfX1W2hoNEF3D0VHkqlDqbQeT1F/Ilqb29Ph C/poe7cvRPd091Cf6g/10LmYhgbaORob0hN0j9anp3MDQV+brx0dWzzbFiJCvW1tPl/7Qkx3 bGhsSB+hHVosluRR/t0+I6Qn6A/s8tE5wnRvoru19OCQlkL3VEqPxbVEontYT4QOxfuSsaA+ MBrTRhaIBbRXH0kNJRO0ob6xtnmBhhp8dNfjU9kI9XhsQRSCUUjguBuGcG4EkpCCQ3imQYc4 jhTfIgmcqcU70AMd4IMgnhSf1W4cQ4j2IOrB0Qcq+oYMvFinAQ8KnagTQw3dUNsDGvQhTmPW gJGxDc92M2MLeGDbkhoh6EVP7su9l9LpNlTGDKURtDtQKYZH8qGWH2v1LVLpMbgA7DLYxR7/ zd5kdEnDPIOYXTN602GMKdSKYbc0rC2BKxg2qgxhH+NYZRLngsgMGB3QcFVLeSzF7TVqSKFa 0uhaA66jEe9E85LeovmsD4BzqT8FV8nsS4ychC6WE1AnCTkVntzB33asCF/kziCCo+FV+FaK qGHmdAP8CxBfCIQKZW5kc3RyZWFtCmVuZG9iagoKMTEzIDAgb2JqCjE1ODAKZW5kb2JqCgox MTQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9FQUFBQUErT3BlblN5 bWJvbAovRmxhZ3MgNAovRm9udEJCb3hbLTE3OSAtMzEyIDEwODIgOTE2XS9JdGFsaWNBbmds ZSAwCi9Bc2NlbnQgNzk5Ci9EZXNjZW50IC0yMDAKL0NhcEhlaWdodCA5MTYKL1N0ZW1WIDgw Ci9Gb250RmlsZTIgMTEyIDAgUgo+PgplbmRvYmoKCjExNSAwIG9iago8PC9MZW5ndGggMjMx L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2QQWvEIBCF7/6KOe4eFhOh7CUESspC Dt2Wpv0BRiep0KhMzCH/vqO7baEHxcd73/Ac2fVPvXdJvlIwAyaYnLeEa9jIIIw4Oy9qBdaZ dFflNouOQjI77GvCpfdTaBoh39hbE+1weLRhxKOQL2SRnJ/h8NENrIctxi9c0CeoRNuCxYnn POt41QvKQp16y7ZL+4mRv8D7HhFU0fWtigkW16gNkvYziqaqWmgul1agt/88dSPGyXxq4mTN SfXQcbapVH6f63Ph7ok8IX/xpxmYjYhblT2UOrmI8/i7qhhipsr5BjAtb/UKZW5kc3RyZWFt CmVuZG9iagoKMTE2IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VG b250L0VBQUFBQStPcGVuU3ltYm9sCi9GaXJzdENoYXIgMAovTGFzdENoYXIgMgovV2lkdGhz WzM2NSA3OTQgNDc5IF0KL0ZvbnREZXNjcmlwdG9yIDExNCAwIFIKL1RvVW5pY29kZSAxMTUg MCBSCj4+CmVuZG9iagoKMTE3IDAgb2JqCjw8L0YxIDExMSAwIFIvRjIgMTAxIDAgUi9GMyAx MDYgMCBSL0Y0IDExNiAwIFIKPj4KZW5kb2JqCgoxMTggMCBvYmoKPDwvRm9udCAxMTcgMCBS Ci9YT2JqZWN0PDwvSW00IDQgMCBSL1RyMTAgMTAgMCBSL1RyMTUgMTUgMCBSL1RyMjAgMjAg MCBSL1RyMjUgMjUgMCBSL1RyMzAgMzAgMCBSL1RyMzUgMzUgMCBSL1RyNDAgNDAgMCBSCi9U cjQ1IDQ1IDAgUi9UcjUgNSAwIFIvVHI1MCA1MCAwIFIvVHI1NSA1NSAwIFIvVHI2MCA2MCAw IFIvVHI2NSA2NSAwIFIvVHI3MCA3MCAwIFIvVHI3NSA3NSAwIFIKL1RyODAgODAgMCBSL1Ry ODUgODUgMCBSL1RyOTAgOTAgMCBSPj4KL0V4dEdTdGF0ZTw8L0VHUzExIDExIDAgUi9FR1Mx NiAxNiAwIFIvRUdTMjEgMjEgMCBSL0VHUzI2IDI2IDAgUi9FR1MzMSAzMSAwIFIvRUdTMzYg MzYgMCBSL0VHUzQxIDQxIDAgUi9FR1M0NiA0NiAwIFIKL0VHUzUxIDUxIDAgUi9FR1M1NiA1 NiAwIFIvRUdTNiA2IDAgUi9FR1M2MSA2MSAwIFIvRUdTNjYgNjYgMCBSL0VHUzcxIDcxIDAg Ui9FR1M3NiA3NiAwIFIvRUdTODEgODEgMCBSCi9FR1M4NiA4NiAwIFIvRUdTOTEgOTEgMCBS Pj4KL1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUkvSW1hZ2VCXQo+PgplbmRvYmoK CjEgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCA5NiAwIFIvUmVzb3VyY2VzIDExOCAwIFIv TWVkaWFCb3hbMCAwIDc5NCA1OTVdL0Fubm90c1sKOTIgMCBSIDk0IDAgUiBdCi9Hcm91cDw8 L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyIDAgUj4+ CmVuZG9iagoKNyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDk2IDAgUi9SZXNvdXJjZXMg MTE4IDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgOCAwIFI+PgplbmRvYmoKCjEyIDAgb2Jq Cjw8L1R5cGUvUGFnZS9QYXJlbnQgOTYgMCBSL1Jlc291cmNlcyAxMTggMCBSL01lZGlhQm94 WzAgMCA3OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRy dWU+Pi9Db250ZW50cyAxMyAwIFI+PgplbmRvYmoKCjE3IDAgb2JqCjw8L1R5cGUvUGFnZS9Q YXJlbnQgOTYgMCBSL1Jlc291cmNlcyAxMTggMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1XS9H cm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAx OCAwIFI+PgplbmRvYmoKCjIyIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgOTYgMCBSL1Jl c291cmNlcyAxMTggMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNw YXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyMyAwIFI+PgplbmRvYmoK CjI3IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgOTYgMCBSL1Jlc291cmNlcyAxMTggMCBS L01lZGlhQm94WzAgMCA3OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0Rldmlj ZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyOCAwIFI+PgplbmRvYmoKCjMyIDAgb2JqCjw8L1R5 cGUvUGFnZS9QYXJlbnQgOTYgMCBSL1Jlc291cmNlcyAxMTggMCBSL01lZGlhQm94WzAgMCA3 OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9D b250ZW50cyAzMyAwIFI+PgplbmRvYmoKCjM3IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQg OTYgMCBSL1Jlc291cmNlcyAxMTggMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1XS9Hcm91cDw8 L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAzOCAwIFI+ PgplbmRvYmoKCjQyIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgOTYgMCBSL1Jlc291cmNl cyAxMTggMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1XS9Bbm5vdHNbCjkzIDAgUiA5NSAwIFIg XQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVu dHMgNDMgMCBSPj4KZW5kb2JqCgo0NyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDk2IDAg Ui9SZXNvdXJjZXMgMTE4IDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1Ry YW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgNDggMCBSPj4KZW5k b2JqCgo1MiAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDk2IDAgUi9SZXNvdXJjZXMgMTE4 IDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9E ZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgNTMgMCBSPj4KZW5kb2JqCgo1NyAwIG9iago8 PC9UeXBlL1BhZ2UvUGFyZW50IDk2IDAgUi9SZXNvdXJjZXMgMTE4IDAgUi9NZWRpYUJveFsw IDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVl Pj4vQ29udGVudHMgNTggMCBSPj4KZW5kb2JqCgo2MiAwIG9iago8PC9UeXBlL1BhZ2UvUGFy ZW50IDk2IDAgUi9SZXNvdXJjZXMgMTE4IDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3Jv dXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgNjMg MCBSPj4KZW5kb2JqCgo2NyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDk2IDAgUi9SZXNv dXJjZXMgMTE4IDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFy ZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgNjggMCBSPj4KZW5kb2JqCgo3 MiAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDk2IDAgUi9SZXNvdXJjZXMgMTE4IDAgUi9N ZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VS R0IvSSB0cnVlPj4vQ29udGVudHMgNzMgMCBSPj4KZW5kb2JqCgo3NyAwIG9iago8PC9UeXBl L1BhZ2UvUGFyZW50IDk2IDAgUi9SZXNvdXJjZXMgMTE4IDAgUi9NZWRpYUJveFswIDAgNTk1 IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29u dGVudHMgNzggMCBSPj4KZW5kb2JqCgo4MiAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDk2 IDAgUi9SZXNvdXJjZXMgMTE4IDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgODMgMCBSPj4K ZW5kb2JqCgo4NyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDk2IDAgUi9SZXNvdXJjZXMg MTE4IDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgODggMCBSPj4KZW5kb2JqCgoxMTkgMCBv YmoKPDwvQ291bnQgMTgvRmlyc3QgMTIwIDAgUi9MYXN0IDEzNyAwIFIKPj4KZW5kb2JqCgox MjAgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIw MDAzMT4KL0Rlc3RbMSAwIFIvWFlaIDAgNTk1IDBdL1BhcmVudCAxMTkgMCBSL05leHQgMTIx IDAgUj4+CmVuZG9iagoKMTIxIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZD MDA2OTAwNjQwMDY1MDAyMDAwMzI+Ci9EZXN0WzcgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQg MTE5IDAgUi9QcmV2IDEyMCAwIFIvTmV4dCAxMjIgMCBSPj4KZW5kb2JqCgoxMjIgMCBvYmoK PDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMz4KL0Rl c3RbMTIgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMTE5IDAgUi9QcmV2IDEyMSAwIFIvTmV4 dCAxMjMgMCBSPj4KZW5kb2JqCgoxMjMgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1 MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzND4KL0Rlc3RbMTcgMCBSL1hZWiAwIDU5NSAwXS9Q YXJlbnQgMTE5IDAgUi9QcmV2IDEyMiAwIFIvTmV4dCAxMjQgMCBSPj4KZW5kb2JqCgoxMjQg MCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAz NT4KL0Rlc3RbMjIgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMTE5IDAgUi9QcmV2IDEyMyAw IFIvTmV4dCAxMjUgMCBSPj4KZW5kb2JqCgoxMjUgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxG RUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzNj4KL0Rlc3RbMjcgMCBSL1hZWiAwIDU5 NSAwXS9QYXJlbnQgMTE5IDAgUi9QcmV2IDEyNCAwIFIvTmV4dCAxMjYgMCBSPj4KZW5kb2Jq CgoxMjYgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUw MDIwMDAzNz4KL0Rlc3RbMzIgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMTE5IDAgUi9QcmV2 IDEyNSAwIFIvTmV4dCAxMjcgMCBSPj4KZW5kb2JqCgoxMjcgMCBvYmoKPDwvQ291bnQgMC9U aXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzOD4KL0Rlc3RbMzcgMCBSL1hZ WiAwIDU5NSAwXS9QYXJlbnQgMTE5IDAgUi9QcmV2IDEyNiAwIFIvTmV4dCAxMjggMCBSPj4K ZW5kb2JqCgoxMjggMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2 NDAwNjUwMDIwMDAzOT4KL0Rlc3RbNDIgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMTE5IDAg Ui9QcmV2IDEyNyAwIFIvTmV4dCAxMjkgMCBSPj4KZW5kb2JqCgoxMjkgMCBvYmoKPDwvQ291 bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMT4KL0Rlc3RbMSAw IFIvWFlaIDAgNTk1IDBdL1BhcmVudCAxMTkgMCBSL1ByZXYgMTI4IDAgUi9OZXh0IDEzMCAw IFI+PgplbmRvYmoKCjEzMCAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAw NjkwMDY0MDA2NTAwMjAwMDMyPgovRGVzdFs3IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDEx OSAwIFIvUHJldiAxMjkgMCBSL05leHQgMTMxIDAgUj4+CmVuZG9iagoKMTMxIDAgb2JqCjw8 L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzM+Ci9EZXN0 WzEyIDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDExOSAwIFIvUHJldiAxMzAgMCBSL05leHQg MTMyIDAgUj4+CmVuZG9iagoKMTMyIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMw MDZDMDA2OTAwNjQwMDY1MDAyMDAwMzQ+Ci9EZXN0WzE3IDAgUi9YWVogMCA1OTUgMF0vUGFy ZW50IDExOSAwIFIvUHJldiAxMzEgMCBSL05leHQgMTMzIDAgUj4+CmVuZG9iagoKMTMzIDAg b2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzU+ Ci9EZXN0WzIyIDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDExOSAwIFIvUHJldiAxMzIgMCBS L05leHQgMTM0IDAgUj4+CmVuZG9iagoKMTM0IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVG RjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzY+Ci9EZXN0WzI3IDAgUi9YWVogMCA1OTUg MF0vUGFyZW50IDExOSAwIFIvUHJldiAxMzMgMCBSL05leHQgMTM1IDAgUj4+CmVuZG9iagoK MTM1IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAy MDAwMzc+Ci9EZXN0WzMyIDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDExOSAwIFIvUHJldiAx MzQgMCBSL05leHQgMTM2IDAgUj4+CmVuZG9iagoKMTM2IDAgb2JqCjw8L0NvdW50IDAvVGl0 bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzg+Ci9EZXN0WzM3IDAgUi9YWVog MCA1OTUgMF0vUGFyZW50IDExOSAwIFIvUHJldiAxMzUgMCBSL05leHQgMTM3IDAgUj4+CmVu ZG9iagoKMTM3IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQw MDY1MDAyMDAwMzk+Ci9EZXN0WzQyIDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDExOSAwIFIv UHJldiAxMzYgMCBSPj4KZW5kb2JqCgo5NiAwIG9iago8PC9UeXBlL1BhZ2VzCi9SZXNvdXJj ZXMgMTE4IDAgUgovTWVkaWFCb3hbIDAgMCA3OTQgODQyIF0KL0tpZHNbIDEgMCBSIDcgMCBS IDEyIDAgUiAxNyAwIFIgMjIgMCBSIDI3IDAgUiAzMiAwIFIgMzcgMCBSIDQyIDAgUiA0NyAw IFIgNTIgMCBSIDU3IDAgUiA2MiAwIFIgNjcgMCBSIDcyIDAgUiA3NyAwIFIKODIgMCBSIDg3 IDAgUiBdCi9Db3VudCAxOD4+CmVuZG9iagoKOTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzE3Ny43IDIxMC42IDU3MyAyMjcuNF0vQTw8 L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQteXUtaW1hcC1jbGllbnQtaWQtMDApPj4KPj4KZW5kb2JqCgo5MyAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMTc3LjcgNzQuNiA1NzMg OTEuNF0vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQteXUtaW1hcC1jbGllbnQtaWQtMDApPj4KPj4KZW5kb2JqCgo5NCAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMTc3Ljcg MjEwLjYgNTczIDIyNy40XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15dS1pbWFwLWNsaWVudC1pZC0wMCk+Pgo+PgplbmRv YmoKCjk1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFsxNzcuNyA3NC42IDU3MyA5MS40XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15dS1pbWFwLWNsaWVudC1pZC0wMCk+ Pgo+PgplbmRvYmoKCjEzOCAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMgOTYgMCBSCi9P cGVuQWN0aW9uWzEgMCBSIC9YWVogbnVsbCBudWxsIDBdCi9PdXRsaW5lcyAxMTkgMCBSCj4+ CmVuZG9iagoKMTM5IDAgb2JqCjw8L0F1dGhvcjxGRUZGMDA0RDAwNjkwMDYzMDA2ODAwNjEw MDY1MDA2QzAwMjAwMDUwMDA2NTAwNjQwMDY0MDA2NTAwNkQwMDZGMDA3MjAwNzM+Ci9DcmVh dG9yPEZFRkYwMDQ5MDA2RDAwNzAwMDcyMDA2NTAwNzMwMDczPgovUHJvZHVjZXI8RkVGRjAw NEMwMDY5MDA2MjAwNzIwMDY1MDA0RjAwNjYwMDY2MDA2OTAwNjMwMDY1MDAyMDAwMzQwMDJF MDAzMj4KL0NyZWF0aW9uRGF0ZShEOjIwMTgwNzE1MTEyOTE1LTA3JzAwJyk+PgplbmRvYmoK CnhyZWYKMCAxNDAKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMTIwMzEzIDAwMDAwIG4gCjAw MDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAwMDg2NSAwMDAwMCBuIAowMDAwMDAwODg1IDAwMDAw IG4gCjAwMDAwMzc0MzUgMDAwMDAgbiAKMDAwMDAzNzYxMSAwMDAwMCBuIAowMDAwMTIwNDgz IDAwMDAwIG4gCjAwMDAwMzc2NTEgMDAwMDAgbiAKMDAwMDAzODcyOSAwMDAwMCBuIAowMDAw MDM4NzUwIDAwMDAwIG4gCjAwMDAwMzg5MjcgMDAwMDAgbiAKMDAwMDEyMDYyOCAwMDAwMCBu IAowMDAwMDM4OTY4IDAwMDAwIG4gCjAwMDAwNDAyODUgMDAwMDAgbiAKMDAwMDA0MDMwNyAw MDAwMCBuIAowMDAwMDQwNDg0IDAwMDAwIG4gCjAwMDAxMjA3NzUgMDAwMDAgbiAKMDAwMDA0 MDUyNSAwMDAwMCBuIAowMDAwMDQxNjI0IDAwMDAwIG4gCjAwMDAwNDE2NDYgMDAwMDAgbiAK MDAwMDA0MTgyMyAwMDAwMCBuIAowMDAwMTIwOTIyIDAwMDAwIG4gCjAwMDAwNDE4NjQgMDAw MDAgbiAKMDAwMDA0MzExMCAwMDAwMCBuIAowMDAwMDQzMTMyIDAwMDAwIG4gCjAwMDAwNDMz MDkgMDAwMDAgbiAKMDAwMDEyMTA2OSAwMDAwMCBuIAowMDAwMDQzMzUwIDAwMDAwIG4gCjAw MDAwNDQ2NTAgMDAwMDAgbiAKMDAwMDA0NDY3MiAwMDAwMCBuIAowMDAwMDQ0ODQ5IDAwMDAw IG4gCjAwMDAxMjEyMTYgMDAwMDAgbiAKMDAwMDA0NDg5MCAwMDAwMCBuIAowMDAwMDQ2NDY4 IDAwMDAwIG4gCjAwMDAwNDY0OTAgMDAwMDAgbiAKMDAwMDA0NjY2NyAwMDAwMCBuIAowMDAw MTIxMzYzIDAwMDAwIG4gCjAwMDAwNDY3MDggMDAwMDAgbiAKMDAwMDA0NzkzOCAwMDAwMCBu IAowMDAwMDQ3OTYwIDAwMDAwIG4gCjAwMDAwNDgxMzcgMDAwMDAgbiAKMDAwMDEyMTUxMCAw MDAwMCBuIAowMDAwMDQ4MTc4IDAwMDAwIG4gCjAwMDAwNDg5NjAgMDAwMDAgbiAKMDAwMDA0 ODk4MSAwMDAwMCBuIAowMDAwMDQ5MTU4IDAwMDAwIG4gCjAwMDAxMjE2ODIgMDAwMDAgbiAK MDAwMDA0OTE5OSAwMDAwMCBuIAowMDAwMDUxMjE3IDAwMDAwIG4gCjAwMDAwNTEyMzkgMDAw MDAgbiAKMDAwMDA1MTQxOSAwMDAwMCBuIAowMDAwMTIxODI5IDAwMDAwIG4gCjAwMDAwNTE0 NjAgMDAwMDAgbiAKMDAwMDA1NDIyNiAwMDAwMCBuIAowMDAwMDU0MjQ4IDAwMDAwIG4gCjAw MDAwNTQ0MjggMDAwMDAgbiAKMDAwMDEyMTk3NiAwMDAwMCBuIAowMDAwMDU0NDY5IDAwMDAw IG4gCjAwMDAwNTc3NTYgMDAwMDAgbiAKMDAwMDA1Nzc3OCAwMDAwMCBuIAowMDAwMDU3OTU4 IDAwMDAwIG4gCjAwMDAxMjIxMjMgMDAwMDAgbiAKMDAwMDA1Nzk5OSAwMDAwMCBuIAowMDAw MDYwOTQ4IDAwMDAwIG4gCjAwMDAwNjA5NzAgMDAwMDAgbiAKMDAwMDA2MTE1MCAwMDAwMCBu IAowMDAwMTIyMjcwIDAwMDAwIG4gCjAwMDAwNjExOTEgMDAwMDAgbiAKMDAwMDA2NDAxMSAw MDAwMCBuIAowMDAwMDY0MDMzIDAwMDAwIG4gCjAwMDAwNjQyMTMgMDAwMDAgbiAKMDAwMDEy MjQxNyAwMDAwMCBuIAowMDAwMDY0MjU0IDAwMDAwIG4gCjAwMDAwNjgyNTYgMDAwMDAgbiAK MDAwMDA2ODI3OCAwMDAwMCBuIAowMDAwMDY4NDU4IDAwMDAwIG4gCjAwMDAxMjI1NjQgMDAw MDAgbiAKMDAwMDA2ODQ5OSAwMDAwMCBuIAowMDAwMDcyMDUzIDAwMDAwIG4gCjAwMDAwNzIw NzUgMDAwMDAgbiAKMDAwMDA3MjI1NSAwMDAwMCBuIAowMDAwMTIyNzExIDAwMDAwIG4gCjAw MDAwNzIyOTYgMDAwMDAgbiAKMDAwMDA3NTE1OSAwMDAwMCBuIAowMDAwMDc1MTgxIDAwMDAw IG4gCjAwMDAwNzUzNjEgMDAwMDAgbiAKMDAwMDEyMjg1OCAwMDAwMCBuIAowMDAwMDc1NDAy IDAwMDAwIG4gCjAwMDAwNzY2MzQgMDAwMDAgbiAKMDAwMDA3NjY1NiAwMDAwMCBuIAowMDAw MDc2ODM2IDAwMDAwIG4gCjAwMDAxMjU3MzkgMDAwMDAgbiAKMDAwMDEyNTkxMiAwMDAwMCBu IAowMDAwMTI2MDgzIDAwMDAwIG4gCjAwMDAxMjYyNTYgMDAwMDAgbiAKMDAwMDEyNTUxOSAw MDAwMCBuIAowMDAwMDc2ODc3IDAwMDAwIG4gCjAwMDAwOTIxMTAgMDAwMDAgbiAKMDAwMDA5 MjEzMyAwMDAwMCBuIAowMDAwMDkyMzI4IDAwMDAwIG4gCjAwMDAwOTI5MjggMDAwMDAgbiAK MDAwMDA5MzM2NCAwMDAwMCBuIAowMDAwMTEyMjEzIDAwMDAwIG4gCjAwMDAxMTIyMzcgMDAw MDAgbiAKMDAwMDExMjQzNSAwMDAwMCBuIAowMDAwMTEzMDI5IDAwMDAwIG4gCjAwMDAxMTM0 NzAgMDAwMDAgbiAKMDAwMDExNjY0MSAwMDAwMCBuIAowMDAwMTE2NjY0IDAwMDAwIG4gCjAw MDAxMTY4NjMgMDAwMDAgbiAKMDAwMDExNzE1NSAwMDAwMCBuIAowMDAwMTE3MzI0IDAwMDAw IG4gCjAwMDAxMTg5OTIgMDAwMDAgbiAKMDAwMDExOTAxNSAwMDAwMCBuIAowMDAwMTE5MjA5 IDAwMDAwIG4gCjAwMDAxMTk1MTEgMDAwMDAgbiAKMDAwMDExOTY3OSAwMDAwMCBuIAowMDAw MTE5NzQ3IDAwMDAwIG4gCjAwMDAxMjMwMDUgMDAwMDAgbiAKMDAwMDEyMzA2NSAwMDAwMCBu IAowMDAwMTIzMTg5IDAwMDAwIG4gCjAwMDAxMjMzMjYgMDAwMDAgbiAKMDAwMDEyMzQ2NCAw MDAwMCBuIAowMDAwMTIzNjAyIDAwMDAwIG4gCjAwMDAxMjM3NDAgMDAwMDAgbiAKMDAwMDEy Mzg3OCAwMDAwMCBuIAowMDAwMTI0MDE2IDAwMDAwIG4gCjAwMDAxMjQxNTQgMDAwMDAgbiAK MDAwMDEyNDI5MiAwMDAwMCBuIAowMDAwMTI0NDI5IDAwMDAwIG4gCjAwMDAxMjQ1NjYgMDAw MDAgbiAKMDAwMDEyNDcwNCAwMDAwMCBuIAowMDAwMTI0ODQyIDAwMDAwIG4gCjAwMDAxMjQ5 ODAgMDAwMDAgbiAKMDAwMDEyNTExOCAwMDAwMCBuIAowMDAwMTI1MjU2IDAwMDAwIG4gCjAw MDAxMjUzOTQgMDAwMDAgbiAKMDAwMDEyNjQyNyAwMDAwMCBuIAowMDAwMTI2NTMxIDAwMDAw IG4gCnRyYWlsZXIKPDwvU2l6ZSAxNDAvUm9vdCAxMzggMCBSCi9JbmZvIDEzOSAwIFIKL0lE IFsgPDk3NDVEQ0JEQTFDNTc2M0JERjYxRjlENjc1RDEyMUYyPgo8OTc0NURDQkRBMUM1NzYz QkRGNjFGOUQ2NzVEMTIxRjI+IF0KL0RvY0NoZWNrc3VtIC8xQUVBRTVCNzZDNDVCNTIyNjMx RDM2ODZEMUUxRDJEMQo+PgpzdGFydHhyZWYKMTI2NzkzCiUlRU9GCg== --------------8CA23D66849E6547B23C06F8-- From nobody Mon Jul 16 11:27:31 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D14130F00; Mon, 16 Jul 2018 11:27:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153176564279.21862.10070844589948558816@ietfa.amsl.com> Date: Mon, 16 Jul 2018 11:27:22 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:27:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Author : Alexey Melnikov Filename : draft-ietf-extra-imap4rev2-01.txt Pages : 125 Date : 2018-07-16 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 17 13:01:38 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50043130F13; Tue, 17 Jul 2018 13:01:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153185769025.12797.5778960372167615650@ietfa.amsl.com> Date: Tue, 17 Jul 2018 13:01:30 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-objectid-04.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:01:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP Extension for object identifiers Author : Bron Gondwana Filename : draft-ietf-extra-imap-objectid-04.txt Pages : 17 Date : 2018-07-17 Abstract: This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-objectid-04 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-objectid-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-objectid-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 17 13:10:27 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584C8130F00 for ; Tue, 17 Jul 2018 13:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=sHt8Xv/t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sSIYd4Yd 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 lVHQHQhOgFVE for ; Tue, 17 Jul 2018 13:10:15 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D71313107B for ; Tue, 17 Jul 2018 13:10:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 6C8DB30E; Tue, 17 Jul 2018 16:09:59 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 17 Jul 2018 16:09:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=mTdWvXH7kHdas+jVLg0oVt+kRPAyp XKdfbv2ZcgMiXA=; b=sHt8Xv/t8nm8wkI6cCkxwEi7EKzUhLvUKHGxCWk2OXhxP EFQgSCGD+A3DThCa16VD5q+J1ErQbCdbS2J3rxowHKqVUIEj/cumYIEOrlZHB244 pYQz0hrLHyZiZWPOmMRhizM23+X7YYH/KvG/Dq52BC3NGPyEau6KbDtNxWLjDKXF igfdqh4gU4jx89mKkTY4PecWP0JLwayUQURUJXrwHWv/tMLJf4atL60kP+Kl3ibx X2e9kYKhPEm6frpRQc41xPzHBgyTjakzId8y3YFSrMmhh58j4ohge8LrbgoRgOd7 0OrNCY6dJ5VoovBy1Bty6k8qPizEGyh49NXl0DI3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=mTdWvXH7kHdas+jVLg0oVt+kRPAyp XKdfbv2ZcgMiXA=; b=sSIYd4YdkU2V6Qb4sSa5tK4MzuKUOnkJ2pnYzZIOi3Uyt 5Qna6UFMkZynZw4SOaCQziCpyf6583Eh23CCRvRz9ot2jVWe7mJTvINmlEAOzsSU CBf/qx8wx4EYsFPfe497/QM7PQ3dFxhJf92DimCao4XRClR+HrMzcDFjt1SbAB1D 3a2WH8wYuYNUEU+QX+ky9BMh3leQkVFvg5L3f7zkdzDjHFVkcZ+J+8FDGbNgxEeb fQWIqS2nFrkJ4MD4Lr4l7QQauhpRF7UAum9iDaWx2ZV8jsvn6xoR3qkdfUAzh3Ap eFvcxmReKk2919mqPydAru9QlEDMyrjtGjwQXk68A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B763C9E111; Tue, 17 Jul 2018 16:09:58 -0400 (EDT) Message-Id: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org Cc: Pete Resnick , Chris Lonvick , Alexey Melnikov MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153185819825106713" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Wed, 18 Jul 2018 06:09:58 +1000 Archived-At: Subject: [Extra] new version of objectid draft uploaded X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:10:26 -0000 This is a multi-part message in MIME format. --_----------=_153185819825106713 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, I've just uploaded draft-ietf-extra-imap-objectid-04, based on multiple reviews. Thanks to: Alexey (AD) Pete (GenArt) Chris (SecDir) Here's the set of changes: * described NIL THREADID in more detail (ad review) * made RFC5256 a normative reference (ad review) * fixed ABNF missing quote (ad review) * documented hash upgrade process (ad review) * referenced RFC3501 for INBOX rename (ad review) * referenced RFC3501 security considerations (secdir review) * turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability (genart review)* remove suggested algorithms which are no longer legitimate (genart review)* updated proxy advice to suggest rewriting ids (genart review) * fixed minor gramatical issues (genart review) * required that EMAILID and THREADID are not identical (own decision) ==== Of particular interest is that EMAILID and THREADID now MUST be different (just prefix them if they may otherwise clash!) and a whole lot of SHOULD turned into MUST. Everyone who's going to implement this already has stable storage for their IDs, and it means clients can really rely on these IDs. I would appreciate any further reviews! Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153185819825106713 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

I've just uploaded draft-ietf-extra-imap-objectid-04, based on multiple reviews.  Thanks to:

Alexey (AD)
Pete (GenArt)
Chris (SecDir)

Here's the set of changes:

* described NIL THREADID in more detail (ad review)
* made RFC5256 a normative reference (ad review)
* fixed ABNF missing quote (ad review)
* documented hash upgrade process (ad review)
* referenced RFC3501 for INBOX rename (ad review)
* referenced RFC3501 security considerations (secdir review)
* turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability (genart review)
* remove suggested algorithms which are no longer legitimate (genart review)
* updated proxy advice to suggest rewriting ids (genart review)
* fixed minor gramatical issues (genart review)
* required that EMAILID and THREADID are not identical (own decision)

====

Of particular interest is that EMAILID and THREADID now MUST be different (just prefix them if they may otherwise clash!) and a whole lot of SHOULD turned into MUST.  Everyone who's going to implement this already has stable storage for their IDs, and it means clients can really rely on these IDs.

I would appreciate any further reviews!

Thanks,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153185819825106713-- From nobody Tue Jul 17 13:41:57 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA390130DE2 for ; Tue, 17 Jul 2018 13:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 N7-kU1IJ2qqH for ; Tue, 17 Jul 2018 13:41:53 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2B5130DEB for ; Tue, 17 Jul 2018 13:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1531860112; x=1563396112; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jWr+2J/2kkpcc9pFxDFQ2csnvKE3No1L/23t3UNahgU=; b=aZHmU00W8T6s100WyWCAet8EaAfsH1KNz8YdDS+GmGqpspeQfY3297BO Ppz4uXUaSLRhAlE8DH+hI9D/ZlQJouVpWmfzdA7OgXCdNucBBW+G9FWQw GuhU3TaQ6grIApqc/YxmqeUMtjHDvO4V927F24Z88sjamKiHSos7uq0MZ c=; X-IronPort-AV: E=Sophos;i="5.51,366,1526367600"; d="scan'208,217";a="350149767" Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by wolverine01.qualcomm.com with ESMTP; 17 Jul 2018 13:41:52 -0700 Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 17 Jul 2018 13:41:52 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Jul 2018 13:41:52 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1365.000; Tue, 17 Jul 2018 13:41:52 -0700 From: Pete Resnick To: Bron Gondwana CC: "extra@ietf.org" , Chris Lonvick , Alexey Melnikov Thread-Topic: new version of objectid draft uploaded Thread-Index: AQHUHgoocqEEVLjLeUCNTamJwKI0AqSUVnAA Date: Tue, 17 Jul 2018 20:41:51 +0000 Message-ID: References: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> In-Reply-To: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: MailMate (1.11.3r5509) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: multipart/alternative; boundary="_000_DA6BCCB860F74AF48E6A374D0E8576C1qtiqualcommcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Extra] new version of objectid draft uploaded X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:41:56 -0000 --_000_DA6BCCB860F74AF48E6A374D0E8576C1qtiqualcommcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2h5IGlzIGl0IGEgU0hPVUxEIE5PVCBpbnN0ZWFkIG9mIGEgTVVTVCBOT1QgaW4gwqc0wrY1Pw0K DQpObyBjaGFuZ2VzIHRvIDguMyBTSE9VTERzIHRvIHNob3VsZHM/DQoNCnByDQoNCk9uIDE3IEp1 bCAyMDE4LCBhdCAxNjowOSwgQnJvbiBHb25kd2FuYSB3cm90ZToNCg0KSGkgQWxsLA0KDQpJJ3Zl IGp1c3QgdXBsb2FkZWQgZHJhZnQtaWV0Zi1leHRyYS1pbWFwLW9iamVjdGlkLTA0LCBiYXNlZCBv biBtdWx0aXBsZSByZXZpZXdzLiAgVGhhbmtzIHRvOg0KDQpBbGV4ZXkgKEFEKQ0KUGV0ZSAoR2Vu QXJ0KQ0KQ2hyaXMgKFNlY0RpcikNCg0KSGVyZSdzIHRoZSBzZXQgb2YgY2hhbmdlczoNCg0KKiBk ZXNjcmliZWQgTklMIFRIUkVBRElEIGluIG1vcmUgZGV0YWlsIChhZCByZXZpZXcpDQoqIG1hZGUg UkZDNTI1NiBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgKGFkIHJldmlldykNCiogZml4ZWQgQUJORiBt aXNzaW5nIHF1b3RlIChhZCByZXZpZXcpDQoqIGRvY3VtZW50ZWQgaGFzaCB1cGdyYWRlIHByb2Nl c3MgKGFkIHJldmlldykNCiogcmVmZXJlbmNlZCBSRkMzNTAxIGZvciBJTkJPWCByZW5hbWUgKGFk IHJldmlldykNCiogcmVmZXJlbmNlZCBSRkMzNTAxIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIChz ZWNkaXIgcmV2aWV3KQ0KKiB0dXJuZWQgbWVhbHktbW91dGhlZCAiU0hPVUxEcyIgaW4gdG8gIk1V U1RzIiBvbiBpbW11dGFiaWxpdHkgKGdlbmFydCByZXZpZXcpDQoqIHJlbW92ZSBzdWdnZXN0ZWQg YWxnb3JpdGhtcyB3aGljaCBhcmUgbm8gbG9uZ2VyIGxlZ2l0aW1hdGUgKGdlbmFydCByZXZpZXcp DQoqIHVwZGF0ZWQgcHJveHkgYWR2aWNlIHRvIHN1Z2dlc3QgcmV3cml0aW5nIGlkcyAoZ2VuYXJ0 IHJldmlldykNCiogZml4ZWQgbWlub3IgZ3JhbWF0aWNhbCBpc3N1ZXMgKGdlbmFydCByZXZpZXcp DQoqIHJlcXVpcmVkIHRoYXQgRU1BSUxJRCBhbmQgVEhSRUFESUQgYXJlIG5vdCBpZGVudGljYWwg KG93biBkZWNpc2lvbikNCg0KPT09PQ0KDQpPZiBwYXJ0aWN1bGFyIGludGVyZXN0IGlzIHRoYXQg RU1BSUxJRCBhbmQgVEhSRUFESUQgbm93IE1VU1QgYmUgZGlmZmVyZW50IChqdXN0IHByZWZpeCB0 aGVtIGlmIHRoZXkgbWF5IG90aGVyd2lzZSBjbGFzaCEpIGFuZCBhIHdob2xlIGxvdCBvZiBTSE9V TEQgdHVybmVkIGludG8gTVVTVC4gIEV2ZXJ5b25lIHdobydzIGdvaW5nIHRvIGltcGxlbWVudCB0 aGlzIGFscmVhZHkgaGFzIHN0YWJsZSBzdG9yYWdlIGZvciB0aGVpciBJRHMsIGFuZCBpdCBtZWFu cyBjbGllbnRzIGNhbiByZWFsbHkgcmVseSBvbiB0aGVzZSBJRHMuDQoNCkkgd291bGQgYXBwcmVj aWF0ZSBhbnkgZnVydGhlciByZXZpZXdzIQ0KDQpUaGFua3MsDQoNCkJyb24uDQoNCi0tDQogIEJy b24gR29uZHdhbmEsIENFTywgRmFzdE1haWwgUHR5IEx0ZA0KICBicm9uZ0BmYXN0bWFpbHRlYW0u Y29tDQoNCg0K --_000_DA6BCCB860F74AF48E6A374D0E8576C1qtiqualcommcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9IndoaXRlLXNwYWNl Om5vcm1hbCI+DQo8cCBkaXI9ImF1dG8iPldoeSBpcyBpdCBhIFNIT1VMRCBOT1QgaW5zdGVhZCBv ZiBhIE1VU1QgTk9UIGluIMKnNMK2NT88L3A+DQo8cCBkaXI9ImF1dG8iPk5vIGNoYW5nZXMgdG8g OC4zIFNIT1VMRHMgdG8gc2hvdWxkcz88L3A+DQo8cCBkaXI9ImF1dG8iPnByPC9wPg0KPHAgZGly PSJhdXRvIj5PbiAxNyBKdWwgMjAxOCwgYXQgMTY6MDksIEJyb24gR29uZHdhbmEgd3JvdGU6PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6MnB4IHNvbGlkICM3Nzc7 IGNvbG9yOiM3Nzc7IG1hcmdpbjowIDAgNXB4OyBwYWRkaW5nLWxlZnQ6NXB4Ij4NCjxkaXYgaWQ9 IkQzOEY5MzNDLUVCODQtNDcyRC04NTlELUMxRDE4NkUzRDI2QiI+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpBcmlhbDsiPkhpIEFsbCw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OkFyaWFsOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsi PkkndmUganVzdCB1cGxvYWRlZCBkcmFmdC1pZXRmLWV4dHJhLWltYXAtb2JqZWN0aWQtMDQsIGJh c2VkIG9uIG11bHRpcGxlIHJldmlld3MuJm5ic3A7IFRoYW5rcyB0bzo8YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpBcmlhbDsiPkFsZXhleSAoQUQpPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpBcmlhbDsiPlBldGUgKEdlbkFydCk8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkFyaWFsOyI+Q2hyaXMgKFNlY0Rpcik8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkFyaWFsOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpBcmlhbDsiPkhlcmUncyB0aGUgc2V0IG9mIGNoYW5nZXM6PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6QXJpYWw7Ij4qIGRlc2NyaWJlZCBOSUwgVEhSRUFESUQgaW4gbW9yZSBkZXRhaWwg KGFkIHJldmlldyk8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsOyI+ KiBtYWRlIFJGQzUyNTYgYSBub3JtYXRpdmUgcmVmZXJlbmNlIChhZCByZXZpZXcpPGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiPiogZml4ZWQgQUJORiBtaXNzaW5n IHF1b3RlIChhZCByZXZpZXcpPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpB cmlhbDsiPiogZG9jdW1lbnRlZCBoYXNoIHVwZ3JhZGUgcHJvY2VzcyAoYWQgcmV2aWV3KTxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Ij4qIHJlZmVyZW5jZWQgUkZD MzUwMSBmb3IgSU5CT1ggcmVuYW1lIChhZCByZXZpZXcpPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpBcmlhbDsiPiogcmVmZXJlbmNlZCBSRkMzNTAxIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIChzZWNkaXIgcmV2aWV3KTxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6QXJpYWw7Ij4qIHR1cm5lZCBtZWFseS1tb3V0aGVkICZxdW90O1NIT1VMRHMmcXVvdDsg aW4gdG8gJnF1b3Q7TVVTVHMmcXVvdDsgb24gaW1tdXRhYmlsaXR5IChnZW5hcnQgcmV2aWV3KTxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Ij4qIHJlbW92ZSBzdWdn ZXN0ZWQgYWxnb3JpdGhtcyB3aGljaCBhcmUgbm8gbG9uZ2VyIGxlZ2l0aW1hdGUgKGdlbmFydCBy ZXZpZXcpPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiPiogdXBk YXRlZCBwcm94eSBhZHZpY2UgdG8gc3VnZ2VzdCByZXdyaXRpbmcgaWRzIChnZW5hcnQgcmV2aWV3 KTxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Ij4qIGZpeGVkIG1p bm9yIGdyYW1hdGljYWwgaXNzdWVzIChnZW5hcnQgcmV2aWV3KTxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Ij4qIHJlcXVpcmVkIHRoYXQgRU1BSUxJRCBhbmQgVEhS RUFESUQgYXJlIG5vdCBpZGVudGljYWwgKG93biBkZWNpc2lvbik8YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpBcmlhbDsiPj09PT08YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkFyaWFsOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiPk9m IHBhcnRpY3VsYXIgaW50ZXJlc3QgaXMgdGhhdCBFTUFJTElEIGFuZCBUSFJFQURJRCBub3cgTVVT VCBiZSBkaWZmZXJlbnQgKGp1c3QgcHJlZml4IHRoZW0gaWYgdGhleSBtYXkgb3RoZXJ3aXNlIGNs YXNoISkgYW5kIGEgd2hvbGUgbG90IG9mIFNIT1VMRCB0dXJuZWQgaW50byBNVVNULiZuYnNwOyBF dmVyeW9uZSB3aG8ncyBnb2luZyB0byBpbXBsZW1lbnQgdGhpcyBhbHJlYWR5IGhhcyBzdGFibGUN CiBzdG9yYWdlIGZvciB0aGVpciBJRHMsIGFuZCBpdCBtZWFucyBjbGllbnRzIGNhbiByZWFsbHkg cmVseSBvbiB0aGVzZSBJRHMuPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpB cmlhbDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Ij5JIHdv dWxkIGFwcHJlY2lhdGUgYW55IGZ1cnRoZXIgcmV2aWV3cyE8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkFyaWFsOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpBcmlhbDsiPlRoYW5rcyw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkFyaWFsOyI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Ij5Ccm9uLjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Ij48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0i c2lnNTY2Mjk0MTciPg0KPGRpdj4tLTxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgQnJvbiBHb25k d2FuYSwgQ0VPLCBGYXN0TWFpbCBQdHkgTHRkPGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyBicm9u Z0BmYXN0bWFpbHRlYW0uY29tPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFjZTpub3JtYWwiPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlci1sZWZ0OjJweCBzb2xpZCAjNzc3OyBjb2xvcjojNzc3OyBtYXJnaW46 MCAwIDVweDsgcGFkZGluZy1sZWZ0OjVweCI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DA6BCCB860F74AF48E6A374D0E8576C1qtiqualcommcom_-- From nobody Tue Jul 17 13:53:07 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C60130DE2 for ; Tue, 17 Jul 2018 13:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=AhVua0tE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V5HsVb82 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 BgdigEet-q2q for ; Tue, 17 Jul 2018 13:52:57 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC6D130E46 for ; Tue, 17 Jul 2018 13:52:14 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 2019C2CE; Tue, 17 Jul 2018 16:52:14 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Tue, 17 Jul 2018 16:52:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7Tlw6m 1P11Qd48QUF+mMcm8KU+yeVDm23+8yRGR2wzw=; b=AhVua0tEzQEZBKfc4E0w2Z R35WPyg9VXhMDlgspQeCv9a03i1uZiBaD5MPHMJ4x7MWtnCYUNDk+LQ9iEH7HO5G ipJNFgInZnrGwOCDsVsn6javkNgXU6M7+GaqSkQX1v0gI06EXDV8495cssPH+nli 1a5mASKAcpDR0A+qrj05qSUdoy2h7FLOOWuex37Wy3YpUwGvMWyG6bIxz3iTykuJ 6wUY0h5FOcf7k07PlN9h1KnEcx4OzwfXjD7iRwoZAQ2mlpRqE0nEbbcolhZl+sqX fwFRS4ErbQWdjJD+Mk7TDdA2TEOEvBRnsDCm4vkGzzOL05FeKstKN6Gaq7aCL7Rg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7Tlw6m 1P11Qd48QUF+mMcm8KU+yeVDm23+8yRGR2wzw=; b=V5HsVb82qyM0bIXQHqjGK3 rh+GftDP7l2J5FLdC5VKkputYWZN2BDNMBs/yR4a7cvfaW8CNaejnfY8Uy+H4VsQ 6KK4czg1y9KBEN1w96GRAX57FwKBRx2pEonx/Ny5ZDiu7/d9sK92WTvQsFQYx/mj akmVwEeQNZNtyr6jpQjzux7B7wgL93TOzbwZwkCdQSWo00oQAbuiiZfiqeWvroio RyRWy+unnyYcVF5xL22zVLBUxxS0F0YoaFqfBdr8FCDAYRfSLMRfdkJ6oK3iVb3K zrLOjDWFwB6+m0YAwta1jrwTDKuppDTkqeINDsbKaUlCX8U7sdCAJC7BMjsdCeHA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5CC7D94138; Tue, 17 Jul 2018 16:52:13 -0400 (EDT) Message-Id: <1531860733.2742618.1444077184.40DAEE90@webmail.messagingengine.com> From: Bron Gondwana To: Pete Resnick Cc: extra@ietf.org, Chris Lonvick , Alexey Melnikov MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153186073327426180" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Wed, 18 Jul 2018 06:52:13 +1000 In-Reply-To: References: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> Archived-At: Subject: Re: [Extra] new version of objectid draft uploaded X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:53:02 -0000 This is a multi-part message in MIME format. --_----------=_153186073327426180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, Jul 18, 2018, at 06:41, Pete Resnick wrote: > Why is it a SHOULD NOT instead of a MUST NOT in =C2=A74=C2=B65? Because if you have EMAILIDs, it's still one zillion times better, because you can just fetch those and notice that the content is already cached. > No changes to 8.3 SHOULDs to shoulds? Damn - missed it. I'll do a -05. Also I'll clarify that THREADID MUST NOT change (from Timo's review and issues/32) > pr > On 17 Jul 2018, at 16:09, Bron Gondwana wrote: >> Hi All, >>=20 >> I've just uploaded draft-ietf-extra-imap-objectid-04, based on >> multiple reviews. Thanks to:>>=20 >> Alexey (AD) >> Pete (GenArt) >> Chris (SecDir) >>=20 >> Here's the set of changes: >>=20 >> * described NIL THREADID in more detail (ad review) >> * made RFC5256 a normative reference (ad review) >> * fixed ABNF missing quote (ad review) >> * documented hash upgrade process (ad review) >> * referenced RFC3501 for INBOX rename (ad review) >> * referenced RFC3501 security considerations (secdir review) >> * turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability >> (genart review)>> * remove suggested algorithms which are no longer le= gitimate (genart >> review)>> * updated proxy advice to suggest rewriting ids (genart revi= ew) >> * fixed minor gramatical issues (genart review) >> * required that EMAILID and THREADID are not identical (own decision)>>= =20 >> =3D=3D=3D=3D >>=20 >> Of particular interest is that EMAILID and THREADID now MUST be >> different (just prefix them if they may otherwise clash!) and a whole >> lot of SHOULD turned into MUST. Everyone who's going to implement >> this already has stable storage for their IDs, and it means clients >> can really rely on these IDs.>>=20 >> I would appreciate any further reviews! >>=20 >> Thanks, >>=20 >> Bron. >>=20 >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >>=20 -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153186073327426180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Wed, Jul 18, 2018, at 06:41, Pet= e Resnick wrote:

Why is it a SHOULD NOT instead of a MUST NOT in= =C2=A74=C2=B65?


Because if you have EMAILIDs, it's still = one zillion times better, because you can just fetch those and notice that = the content is already cached.

No changes to 8.3 SHOULDs to shoulds?


Damn - missed it.  I'll do a -05.&nb= sp; Also I'll clarify that THREADID MUST NOT change (from Timo's review and= issues/32)

pr

On 17 Jul 2018, at 16:09, Bron Gon= dwana wrote:

Hi All,

I've just uploaded draft-ietf-extra-imap-= objectid-04, based on multiple reviews.  Thanks to:

Alexey (AD)
Pete (GenArt)
Chris (SecDir)

Here's the set of changes:

* described NIL THREADID in more detail (= ad review)
* made RFC5256 a normative reference (ad = review)
* fixed ABNF missing quote (ad review)
* documented hash upgrade process (ad rev= iew)
* referenced RFC3501 for INBOX rename (ad= review)
* referenced RFC3501 security considerati= ons (secdir review)
* turned mealy-mouthed "SHOULDs" in to "M= USTs" on immutability (genart review)
* remove suggested algorithms which are n= o longer legitimate (genart review)
* updated proxy advice to suggest rewriti= ng ids (genart review)
* fixed minor gramatical issues (genart r= eview)
* required that EMAILID and THREADID are = not identical (own decision)

=3D=3D=3D=3D

Of particular interest is that EMAILID an= d THREADID now MUST be different (just prefix them if they may otherwise cl= ash!) and a whole lot of SHOULD turned into MUST.  Everyone who's goin= g to implement this already has stable storage for their IDs, and it means clients can really rely on these IDs.<= br>

I would appreciate any further reviews!

Thanks,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com




--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153186073327426180-- From nobody Tue Jul 17 13:55:38 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D184130DEB; Tue, 17 Jul 2018 13:55:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153186093339.12695.8080736404581738651@ietfa.amsl.com> Date: Tue, 17 Jul 2018 13:55:33 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-objectid-05.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:55:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP Extension for object identifiers Author : Bron Gondwana Filename : draft-ietf-extra-imap-objectid-05.txt Pages : 17 Date : 2018-07-17 Abstract: This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-objectid-05 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-objectid-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-objectid-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 17 14:02:45 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF54130E62 for ; Tue, 17 Jul 2018 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 EPALyKIhoFj0 for ; Tue, 17 Jul 2018 14:02:37 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E17C131056 for ; Tue, 17 Jul 2018 14:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1531861353; x=1563397353; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1DzL9LLpx1TXeEaJDNUMiw1UqbIxLd7Qj8gqqy8fg5o=; b=gnLXQh5VCSg99UAKgxZQkI08bZAuS7tuMsWU2992+4lHocvd135+DPuG HKX74WJVH69AWSv5cVFTmRcu15bM2SOFRxFiW5jzt/pdM6QLLampUtNSP cKaBaOLVHhtSYsNiyRQRNegMjZ8kmG2E7kXm01ETZZELzs6a/kgZr3yxA E=; X-IronPort-AV: E=Sophos;i="5.51,367,1526367600"; d="scan'208";a="350151117" Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by wolverine01.qualcomm.com with ESMTP; 17 Jul 2018 14:02:33 -0700 X-IronPort-AV: E=McAfee;i="5900,7806,8957"; a="119357768" Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 17 Jul 2018 14:02:32 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Jul 2018 14:02:32 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1365.000; Tue, 17 Jul 2018 14:02:32 -0700 From: Pete Resnick To: Bron Gondwana CC: "extra@ietf.org" , Chris Lonvick , Alexey Melnikov Thread-Topic: new version of objectid draft uploaded Thread-Index: AQHUHgoocqEEVLjLeUCNTamJwKI0AqSUVnAAgAAC54CAAALhgA== Date: Tue, 17 Jul 2018 21:02:32 +0000 Message-ID: <06700E16-5B8D-44C6-A557-003CF50EFFC8@qti.qualcomm.com> References: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> <1531860733.2742618.1444077184.40DAEE90@webmail.messagingengine.com> In-Reply-To: <1531860733.2742618.1444077184.40DAEE90@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: MailMate (1.11.3r5509) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="utf-8" Content-ID: <54627ABD1DCD2E4AAFBBF2FA2A78C134@qualcomm.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Extra] new version of objectid draft uploaded X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:02:42 -0000 T24gMTcgSnVsIDIwMTgsIGF0IDE2OjUyLCBCcm9uIEdvbmR3YW5hIHdyb3RlOg0KDQo+IE9uIFdl ZCwgSnVsIDE4LCAyMDE4LCBhdCAwNjo0MSwgUGV0ZSBSZXNuaWNrIHdyb3RlOg0KPj4gV2h5IGlz IGl0IGEgU0hPVUxEIE5PVCBpbnN0ZWFkIG9mIGEgTVVTVCBOT1QgaW4gwqc0wrY1Pw0KPg0KPiBC ZWNhdXNlIGlmIHlvdSBoYXZlIEVNQUlMSURzLCBpdCdzIHN0aWxsIG9uZSB6aWxsaW9uIHRpbWVz IGJldHRlciwNCj4gYmVjYXVzZSB5b3UgY2FuIGp1c3QgZmV0Y2ggdGhvc2UgYW5kIG5vdGljZSB0 aGF0IHRoZSBjb250ZW50IGlzDQo+IGFscmVhZHkgY2FjaGVkLg0KDQpNZWguIFRoYXQgc2VlbXMg dG8gcHVzaCBmb3IgdHdvIHNlcGFyYXRlIGNhcGFiaWxpdGllcy4gT3RoZXJ3aXNlIGl0IA0KbWVh bnMgSSBjYW7igJl0IHJlYWxseSB0cnVzdCB0aGF0IE1BSUxCT1hJRCB3b3JrcywgZXZlbiBpZiBP QkpFQ1RJRCBpcyANCmFkdmVydGlzZWQuDQoNCnBy From nobody Tue Jul 17 14:04:49 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609B8130FC8 for ; Tue, 17 Jul 2018 14:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WoJ75wEi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QCxaEla0 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 xxlSaWBJj-u7 for ; Tue, 17 Jul 2018 14:04:40 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D38F13102C for ; Tue, 17 Jul 2018 14:04:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9C88B31D for ; Tue, 17 Jul 2018 17:04:37 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Tue, 17 Jul 2018 17:04:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=luSbeekXQ8mhMM3sB yBULPWcxZeu5CogIhZNDVDVdn0=; b=WoJ75wEiFGd817nve9WuAm6bUsLc3OWjv yE7tyXRoME1KzCSa5YT9ef/fLM/mdUmp6dCo3t5PunW53GQj6kQBjBKBDMZwXR1T JbpD9X5fXy6jl85Hyif0o1zmDshZa0rwRC/HH5cn/orNTi6yfM0ysqlAycXlBBmf bTqeRKnJoq773beQawQAy7IWuRLuPjwOFVYS8qEgqjambUZbXzmmW2Entj/ztg7l 92DNG9Fw44hqDMBwimBIR9YJuS5jeYjiBLeCW4+9bzxk8LL3nxl+uc33+wdAPxkj 7TRA+P1WFl/xnomDIMdGMrShFTBj+F5XhEb6JLh52di2lveQqmWKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=luSbee kXQ8mhMM3sByBULPWcxZeu5CogIhZNDVDVdn0=; b=QCxaEla08K8y8eSzSRtpVE U7YEOGm6zRJQDDhNqsAHLcKo4BEJsPd4dYtbrHzrp8ox3uubTSSgX7FDhijanjTT 8bDIK1U86rGEnfDp161MloSoPCX0u1vWdCeL5bcYRpAkqrNVN8XVogX3vb6fpgge O3lGHou899K1MfSBdBQjkwv9ziwQSaH2giOf8d9/xHfKUyq+xxruqnyx7jvoEsVN /2IqcSYGbm2a6ybcKjNjCrJqk77wtzlXFxMJT5JnIixTbBAA8F99o3/Sb6tgtUol 486R+SemJmizBdJdd2HK0lzppYoTktJhMdN7EsLNuSMahyUI/OpCBDNvCQwTYOsg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F050B94138; Tue, 17 Jul 2018 17:04:36 -0400 (EDT) Message-Id: <1531861476.2745784.1444096120.5A62CA76@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153186147627457840" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa References: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> <1531860733.2742618.1444077184.40DAEE90@webmail.messagingengine.com> <06700E16-5B8D-44C6-A557-003CF50EFFC8@qti.qualcomm.com> Date: Wed, 18 Jul 2018 07:04:36 +1000 In-Reply-To: <06700E16-5B8D-44C6-A557-003CF50EFFC8@qti.qualcomm.com> Archived-At: Subject: Re: [Extra] new version of objectid draft uploaded X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:04:48 -0000 This is a multi-part message in MIME format. --_----------=_153186147627457840 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, Jul 18, 2018, at 07:02, Pete Resnick wrote: > On 17 Jul 2018, at 16:52, Bron Gondwana wrote: >=20 >> On Wed, Jul 18, 2018, at 06:41, Pete Resnick wrote: >>> Why is it a SHOULD NOT instead of a MUST NOT in =C2=A74=C2=B65? >>=20 >> Because if you have EMAILIDs, it's still one zillion times better, >> because you can just fetch those and notice that the content is >> already cached. >=20 > Meh. That seems to push for two separate capabilities. Otherwise it > means I can=E2=80=99t really trust that MAILBOXID works, even if OBJECTID= is > advertised. Thanks last-minute-guy :p I'm happy to change it to a MUST if there's no objection from anybody else. My server keeps MAILBOXID just fine on rename. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153186147627457840 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Wed, Jul 18, 2018, at 07:02, Pet= e Resnick wrote:
On 17 Jul 2018, at 16:52, Bron Gondwana wrot= e:

On Wed, Jul 18, 2018, at 06:41, Pete Resnick wrote:
Why is it a SHOULD NOT instead of a MUST NOT in =C2=A74=C2= =B65?

Because if you have EMAILIDs, it's still one zillion times better,
=
because you can just fetch those and notice that the content is
already cached.

Meh. That seems to push for two separate capabilities. Otherwise it
means I can=E2=80=99t really trust that MAILBOXID works, even if OBJEC= TID is
advertised.

Thanks last-minute-guy :p

I'm happy to change it to a MUST if there= 's no objection from anybody else.  My server keeps MAILBOXID just fin= e on rename.

Bron.

--
  Bron Gondwana, CEO,= FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153186147627457840-- From nobody Tue Jul 17 14:32:27 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450C4130E03 for ; Tue, 17 Jul 2018 14:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=T3HxueuY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FvspoJMw 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 YdfJFGyb1Hjj for ; Tue, 17 Jul 2018 14:32:24 -0700 (PDT) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D05129C6B for ; Tue, 17 Jul 2018 14:32:24 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id 69607286; Tue, 17 Jul 2018 17:32:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 17 Jul 2018 17:32:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=91GVpIHc+C5o4XhiUIro7vW9/QYVziLANYt+g/VWOjg=; b=T3HxueuY ccis8fGfaN1poyHuZaA00ahY3TW9SNfzSZWSBwgoCLLBlL6ecsRazBxbM7SMsWIk 52IPlJprM69zz7lVWBmMo+/5G1siBwvHTaYA1ZOTQeB9E8SBIxxWl2gi9CiCek60 ZsGEzVMc/VjjndtZP6RALYNcibbO8NFlidwh8pM84DOcOjPiJDTZJt/Mkf1isBEK DhKBH5/1hj5hKKWA5Eygy+0NURR0J7CJI59Lp/5c36E83jq5rVGaABzfmzkLRHWJ vbDRWWSeXpTHu0MPghp9NI7xvTxn34Id/pw/ldvtKyCMidGoN4PlqJ00xS5rF1jM c0lJ78O57070pw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=91GVpIHc+C5o4XhiUIro7vW9/QYVz iLANYt+g/VWOjg=; b=FvspoJMweSBr0bTbGMletwHrUnS4Kbe7bKJ+cN7HyXVdQ n2EXFninMvSz7p91Bk6d8xjHX7YCOpft4wOgjMHDGvDKETwz8W7Nb0eDoJPoSxSA X4Ft7a8REh2mZ5NzP6EmwBYALB6NGF7uLYl0atrLBZn0hyg0hjgtPvTc0wmlixrn YoDKorY5LJoUUEB8ossPCnM/DuCpg7uqJB5iU+BtearEo4R70BuM1NSCS9AJEqG/ LBSvO4E6gPGiw9vVyjuGugZ4DhqMTiuUFRGmXK+FNn62grjwCvXeYr6yhpixBr0z dEFwOSYwAeUVmvkLggK4M9g2cx8J5nFfREeO0bexg== X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (dhcp-853d.meeting.ietf.org [31.133.133.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 995BD10255; Tue, 17 Jul 2018 17:32:20 -0400 (EDT) From: Ken Murchison To: Ned Freed Cc: Bron Gondwana , extra@ietf.org References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> <01QTIJ66FRSK000051@mauve.mrochek.com> <90322c67-3f2b-6322-12c0-6870e2a8b2ac@fastmail.com> <01QTJR8Q97NK000051@mauve.mrochek.com> Organization: FastMail US LLC Message-ID: Date: Tue, 17 Jul 2018 17:32:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------1850B585D6AB668C539E19A4" Content-Language: en-US Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:32:26 -0000 This is a multi-part message in MIME format. --------------1850B585D6AB668C539E19A4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ned, Poking you on this so I have a better idea what you're looking for and we can update the WG on our status on Thu morning. On 06/15/2018 06:45 PM, Ken Murchison wrote: > Hi Nedx > > > On 06/10/2018 07:01 PM, Ned Freed wrote: >> >>> On 06/09/2018 08:49 PM, Ned Freed wrote: >>> > Section 3.3. I suggest that for now this be made specific to the >>> mailto: >>> > method. If someone wants to write some requirements for tel: and >>> xmpp: that's >>> > fine too. > > Do you have suggestions as to how you would like to see the existing > text modified? > -- Ken Murchison Cyrus Development Team FastMail US LLC --------------1850B585D6AB668C539E19A4 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------1850B585D6AB668C539E19A4-- From nobody Tue Jul 17 14:39:24 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD04F130E2C for ; Tue, 17 Jul 2018 14:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=xPR14le/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FgRfDQ0N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-S4VkE88xd4 for ; Tue, 17 Jul 2018 14:39:18 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4028D129C6B for ; Tue, 17 Jul 2018 14:39:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id C48BE300 for ; Tue, 17 Jul 2018 17:39:17 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Tue, 17 Jul 2018 17:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=2y3GljV6LyWqIQXlG fVneCAdALf6TsN5M/PoqOjJXh0=; b=xPR14le/KAILc7LtRDahaSPQGkZ/WoTux Hi72CW1MQXH2IX8wUwXDpQN5wlFsOoibYzbAbUJfG4My25B5E6jt9hgJkL7/9O3s jfy4My5wSMOfJn3DfPCGuhxFWIGzrvsVhqn81lGlUI7OZ8q2GY+iVDIV35MrBy7k V1NgCIfCAri0y57+Lw++EOmBe789q74sH1REPRgnvUmR7qbJL9KLA7T4xs5ZKwlI 7CK1sDZYZkEJZ93R3oxIOfLFAKO8QLXwqeRA8NwsbTF987td6A010ljSRPRbQfV6 V19ep91XbbGql3/MRJq2iK2uMHZlPHFkllYg5+tRzMiM90TdT58Nw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=2y3Glj V6LyWqIQXlGfVneCAdALf6TsN5M/PoqOjJXh0=; b=FgRfDQ0NQigTI21h5HSgjW mSuZAXLKYmjIsTCJlLNWwO1xBPRQ1dA36nf27wHzcRyby9+SXTpMGyh66Z8zfabe OE6TaxKvzz1znF4e/QXKsgL9LCd4wTcO9epuOHfSUzR2GuMnSrYqORsjFmNPq3Kl rQwzPIEECE69Ft569h4PA3H8fkbChZcUG2xmUeiD3OcFE7VCjwe+SKuIcfiPCqJk 0qrNQ3Hn5HYlYZCzqPJluDA5wk8Id5ePYWOZ6bxc8w7sTRkF5TvPJ3fAs//7X3D7 HwummatOm9kQNODEOppmTBaycbrL5mQQTFsUJLP+UXRvLhVPhq2eLN1iXlkLGVNQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DBFBD94138; Tue, 17 Jul 2018 17:39:16 -0400 (EDT) Message-Id: <1531863556.2753802.1444123408.6D6E6340@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153186355627538020" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> Date: Wed, 18 Jul 2018 07:39:16 +1000 In-Reply-To: <01QTO3THVZ5I00AI1F@mauve.mrochek.com> Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:39:22 -0000 This is a multi-part message in MIME format. --_----------=_153186355627538020 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi all, sorry about dropping the ball on following up on this. I'm just putting together the slides for Thursday now. On Thu, Jun 14, 2018, at 01:40, Ned Freed wrote: >>> This, incidentially, is one of those places where providing the >>> actual IMAP>>> commands will be especially valuable: Pointing out that you should >>> use the>>> NAMESPACE extension and if it isn't present, fallback to LIST "" >>> would be very>>> helpful. > >> Here's my initial attempt at addressing this point (separate >> branch in>> Github): > >> https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/035a1af6137a383089c8d54cd733238dc2dfebda> >> This adds an IMAP example for specialuse_exists. > >> What do you think? > > The first step seems fine: > > C: A01 NAMESPACE > S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" > "/"))> S: A01 OK NAMESPACE command completed > > In the next step: > > Subsequently, when no particular mailbox is of interest (i.e., the> "specialuse_exists" test has no mailbox argument), the client > lists> all mailboxes with special-use flags in the two returned personal> namespaces: > > C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN (SPECIAL- > USE)> S: * LIST (\Drafts) "/" INBOX/Drafts > S: * LIST (\Trash) "/" INBOX/Trash > S: * LIST (\Sent) "/" INBOX/Sent > S: * LIST (\Archive) "/" Archive/Default > > It should be noted that this depends on extended list being available.> > The final step is: > > C: A03 SELECT Archive/Default > S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) > S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \Draft \*)] > Flags permitted.> S: * 11211 EXISTS > S: * 3 RECENT > S: * OK [UIDVALIDITY 1526903163] UIDs valid > S: * OK [UIDNEXT 11278] Predicted next UID > S: A03 OK [READ-WRITE] SELECT command completed > > There are several issues here. > > First, if you're going to use SELECT it's probably worth noting > that since> inclusion of [READ-WRITE] for writable mailboxes is a SHOULD in RFC > 3501 while> inclusion of [READ-ONLY] for non-writable is a MUST, a writability > check really> needs to based on the absence of [READ-ONLY]. (RFC 5490 3.1.a appears > incorrect> to me in this regard - should I file an errata?) > > However, I think use of SELECT for this purpose is problematic: It's > potentially expensive and worse, may cause undesireable state > changes. Why> not use the MYRIGHTS command to obtain the access rights (and check > for "p" or> "i") without having to select the mailbox? > > And as a bonus, if it's available you could use the just-standardized> LIST-MYRIGHTS extension to piggyback getting the rights while getting > the list> of special-use mailboxes. > > More generally, this is why documenting the things necessary to > implement the> necessary semantics of an extension is helpful - there may be > optimizations and> concerns that should be called out lest implementors miss them. > > It also helps clarify overall implementation difficulty. And > while this> extension may be easy to implement in the Sieve-in-IMAP case, from the> perspective of an MTA/MDA implementation, even if all of the steps > can be done> efficiently, there's still the question of IMAP server > availability and the> handling of temporary errors. > > All of which is roundabout way of saying I now think that we > may want a> capability for specialuse_exists that's separate from > "special-use"/:specialuse. Or better still, since we already have the > "mailbox"> capability for "mailbox access stuff", I think we should require the > presence> of both "mailbox" and "special-use" capabilities in order to use > specialuse_exists. Stephan, are you happy to revise based on Ned's feedback above? > I also reviewed the rest of the revised draft, and it's looking > good. My one> remaining concern is with the handling of multiple mailboxes > having the> same special-use flag assigned. The draft currently says: > > More than one mailbox in the user's personal namespace can have a > particular special-use flag assigned. In case of such > ambiguity, the> mailbox that is chosen for delivery is implementation-defined. > However, while the set of mailboxes to which the involved special- > use> flags are assigned remains unchanged, implementations MUST ensure > that the mailbox choice is made consistently, so that the same > mailbox is used every time. Conversely, the chosen mailbox MAY > change once the special-use flag assignments that are relevant for > the mailbox choice are changed (usually by user interaction). > > I don't see a way I can reasonably implement this MUST via IMAP > unless the> IMAP server always returns the list of special-use mailboxes in the > same order.> Sure, I can cache the user/special-use-attribute/actual-mailbox- > list tuple> somewhere, but caches can always be lost. And mailbox metadata is (a)> Potentially much too expensive and (b) Subject to the > vagarities of user> actions. > > I'm not happy about it, but I think this needs to become a SHOULD. I can live with SHOULD for cases where there are multiple mailboxes with the same special-use. > Another possibility is to use the default mailbox name as a means of > disambiguating multiple mailboxes with the same special-use attribute:> If the default mailbox is one of these deliver to it preferentially, > otherwise the behavior is implementation-defined. Not perfect, but it> provides a bit more consistent behavior that's easily achievable. > > Aside from these issues, this draft looks good to go to me. Thanks for the great feedback! Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153186355627538020 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi all, sorry about dropping the ball on following up on this.  I'm just putting together the slides for Thursday now.

On Thu, Jun 14, 2018, at 01:40, Ned Freed wrote:
This, incidentially, is one of those places where providing the actual IMAP
commands will be especially valuable: Pointing out that you should use the
NAMESPACE extension and if it isn't present, fallback to LIST "" would be very
helpful.

Here's my initial attempt at addressing this point (separate branch in
Github):


This adds an IMAP example for specialuse_exists.

What do you think?

The first step seems fine:

  C: A01 NAMESPACE
  S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/"))
  S: A01 OK NAMESPACE command completed

In the next step:

    Subsequently, when no particular mailbox is of interest (i.e., the
    "specialuse_exists" test has no mailbox argument), the client lists
    all mailboxes with special-use flags in the two returned personal
    namespaces:

    C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN (SPECIAL-USE)
    S: * LIST (\Drafts) "/" INBOX/Drafts
    S: * LIST (\Trash) "/" INBOX/Trash
    S: * LIST (\Sent) "/" INBOX/Sent
    S: * LIST (\Archive) "/" Archive/Default

It should be noted that this depends on extended list being available.

The final step is:

    C: A03 SELECT Archive/Default
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
    S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \Draft \*)] Flags permitted.
    S: * 11211 EXISTS
    S: * 3 RECENT
    S: * OK [UIDVALIDITY 1526903163] UIDs valid
    S: * OK [UIDNEXT 11278] Predicted next UID
    S: A03 OK [READ-WRITE] SELECT command completed

There are several issues here.

First, if you're going to use SELECT it's probably worth noting that since
inclusion of [READ-WRITE] for writable mailboxes is a SHOULD in RFC 3501 while
inclusion of [READ-ONLY] for non-writable is a MUST, a writability check really
needs to based on the absence of [READ-ONLY]. (RFC 5490 3.1.a appears incorrect
to me in this regard - should I file an errata?)

However, I think use of SELECT for this purpose is problematic: It's
potentially expensive and worse, may cause undesireable state changes. Why
not use the MYRIGHTS command to obtain the access rights (and check for "p" or
"i") without having to select the mailbox?

And as a bonus, if it's available you could use the just-standardized
LIST-MYRIGHTS extension to piggyback getting the rights while getting the list
of special-use mailboxes.

More generally, this is why documenting the things necessary to implement the
necessary semantics of an extension is helpful - there may be optimizations and
concerns that should be called out lest implementors miss them.

It also helps clarify overall implementation difficulty. And while this
extension may be easy to implement in the Sieve-in-IMAP case, from the
perspective of an MTA/MDA implementation, even if all of the steps can be done
efficiently, there's still the question of IMAP server availability and the
handling of temporary errors.

All of which is roundabout way of saying I now think that we may want a
capability for specialuse_exists that's separate from
"special-use"/:specialuse. Or better still, since we already have the "mailbox"
capability for "mailbox access stuff", I think we should require the presence
of both "mailbox" and "special-use" capabilities in order to use
specialuse_exists.

Stephan, are you happy to revise based on Ned's feedback above?

I also reviewed the rest of the revised draft, and it's looking good. My one
remaining concern is with the handling of multiple mailboxes having the
same special-use flag assigned. The draft currently says:

  More than one mailbox in the user's personal namespace can have a
  particular special-use flag assigned.  In case of such ambiguity, the
  mailbox that is chosen for delivery is implementation-defined.
  However, while the set of mailboxes to which the involved special-use
  flags are assigned remains unchanged, implementations MUST ensure
  that the mailbox choice is made consistently, so that the same
  mailbox is used every time.  Conversely, the chosen mailbox MAY
  change once the special-use flag assignments that are relevant for
  the mailbox choice are changed (usually by user interaction).

I don't see a way I can reasonably implement this MUST via IMAP unless the
IMAP server always returns the list of special-use mailboxes in the same order.
Sure, I can cache the user/special-use-attribute/actual-mailbox-list tuple
somewhere, but caches can always be lost. And mailbox metadata is (a)
Potentially much too expensive and (b) Subject to the vagarities of user
actions.

I'm not happy about it, but I think this needs to become a SHOULD.

I can live with SHOULD for cases where there are multiple mailboxes with the same special-use.

Another possibility is to use the default mailbox name as a means of
disambiguating multiple mailboxes with the same special-use attribute:
If the default mailbox is one of these deliver to it preferentially,
otherwise the behavior is implementation-defined. Not perfect, but it
provides a bit more consistent behavior that's easily achievable.

Aside from these issues, this draft looks good to go to me.

Thanks for the great feedback!

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153186355627538020-- From nobody Tue Jul 17 15:11:08 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704A1131073 for ; Tue, 17 Jul 2018 15:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=TIGvyOBI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CewSXnG2 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 nn7xZrTfsZZT for ; Tue, 17 Jul 2018 15:10:50 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438D3131090 for ; Tue, 17 Jul 2018 15:10:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7EC3A2D6 for ; Tue, 17 Jul 2018 18:10:47 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Tue, 17 Jul 2018 18:10:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=KJZpNlfyQrrOleA02RGLLmRz7WoNOWE2ooBGNi0yT Zg=; b=TIGvyOBIZB/8Lecs9hsOt8dfZoZizvf6Q2cft4LNhSRCjJpmrU7vAUAYE oCJazIqixQoN5HMxnNiC5ddey5OvrVezYgdq8xJFEWWd8amrjJhX0fdhREdXY0qj ksyo3KaOBkniyF0S4s6Jdu1/YPrLtHdnMDFWS1iGJJDABWBNTo1rEZdrGEdN2+oY kzgBi5DefUqH5y/9dVKgXffqKC9JHw2gL5r29R3q7bwlc+kdZX5+4iFKvXJWoLeS 2V8oDdvHbJuqsrg644PHinP8HMqI2axLcdg7hwcAaPTDtIBuD4VSOKiujBQa6asT s+vxLFonGypkTsZcLgqkppaMYhokg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=KJZpNlfyQrrOleA02RGLLmRz7WoNO WE2ooBGNi0yTZg=; b=CewSXnG2Ed2+B8ctPKX+JbMsYrtbNpi4O1kXsDgzZLQVQ W+RTekhuxiRE9rqG4RmHnJodFL32smgfzEUVPLoh0AdRW0r8q5eFsJAG0Vk3yIgN i+cNvlQPImHfq0kWBuMZqWIF8VYQwLH5qnPFEKUBQ6Rv4mTZr7yZ4bDv2p5pcdl+ 17Eqwle3i7oFOB7GPY2OkuOTY5jzh5usd90AGFxlaSuhqFaxS8NwMufAj+oq+Bs8 IEtrf4jyGUbzFT26EQ6qDqJIjGUIB67BLyt6XZZcap1dwVzVVl2lIHTbN1SjvgLA gSNtK9SDz+YZy9/u4Z1nH8VoC7H+1w0T1CpzdE73w== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E58E694138; Tue, 17 Jul 2018 18:10:46 -0400 (EDT) Message-Id: <1531865446.2762151.1444155472.5D64A97B@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153186544627621511" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Wed, 18 Jul 2018 08:10:46 +1000 Archived-At: Subject: [Extra] Slides uploaded X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 22:11:00 -0000 This is a multi-part message in MIME format. --_----------=_153186544627621511 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, I've uploaded the agenda/chair slides as well as slides for IMAP4rev2, Snippet and Client ID from their respective authors - so you have a chance to come in to Thursday's meeting slightly prepared for once :) (I think I uploaded 30 min before the meeting last time!) Please do provide any pre-meeting feedback that you can - we only have an hour due to my mixup with scheduling the meeting, so time is going to be tight! Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153186544627621511 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

I've uploaded the agenda/chair slides as well as slides for IMAP4rev2, Snippet and Client ID from their respective authors - so you have a chance to come in to Thursday's meeting slightly prepared for once :)  (I think I uploaded 30 min before the meeting last time!)

Please do provide any pre-meeting feedback that you can - we only have an hour due to my mixup with scheduling the meeting, so time is going to be tight!

Thanks,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153186544627621511-- From nobody Wed Jul 18 09:48:53 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9D1130EDE for ; Wed, 18 Jul 2018 09:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 M0RsoUIV2MnX for ; Wed, 18 Jul 2018 09:48:45 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 661EF13123A for ; Wed, 18 Jul 2018 09:48:45 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6IGi2U5018830 for ; Wed, 18 Jul 2018 16:48:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : mime-version : content-type; s=corp-2018-07-02; bh=sjITx3ReJYnH+5teg7qLF54j6GN+AbyiVntkDauX1oY=; b=nNraNr7wYe+IW4n8nxqeZrdrMXWC+QmyPaRFoWAoEjfsaCEGNR6zS5DL4hmbjvMyx06d GCqKfv43gx6U4WauMtFec6w97dlfM7ZrV0J040whmXXxcuejO1Z9kgipt0CJZ9it36yu 24f0iSTaHv3JLf8oMHhjPb0+TbVfJm5iaiOt2C6f9EytMZcm30QkC4HmvJwjz0/Hlufj ke9Ty6Wf0UYrXROghMNhfTZ9zVpo0PmcEb7FQ+vlWIcVW4C1gDaqYr0kn4OsYdU6BxSB yg8GhFWBHBDBtOCsFlv1agXAJhfdvJGApgWUIqvtL3EIJipvaf0ujxXz2IFsuJxJXbKX WA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2k9ykc2gbn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 18 Jul 2018 16:48:44 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6IGmhZ8009168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 18 Jul 2018 16:48:44 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6IGmhCV013513 for ; Wed, 18 Jul 2018 16:48:43 GMT Received: from [31.133.140.238] (/31.133.140.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Jul 2018 16:48:43 +0000 From: "Chris Newman" To: extra@ietf.org Date: Wed, 18 Jul 2018 12:48:41 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <9DF2BF4C-217D-4E3D-947A-743BD7778863@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8958 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=927 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180185 Archived-At: Subject: [Extra] IMAP4rev2 and EAI (RFC 6532, 6855) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:48:51 -0000 I'd like IMAP4rev2 to be EAI-safe. Summary of significant technical changes: 1. Clients MUST be able to tolerate RFC 6532 messages in the message store if they ENABLE IMAP4rev2. This is a big ask in some ways (although it depends on client design), but I think it's important and not unreasonable. 2. Servers with a RFC 6532-compatible message store MUST accept RFC 6532 messages via append. I implemented this already. The extra syntax in RFC 6855 section 4 is useless, I'd recommend dropping that syntax (but I would not object if it's included since I can simply treat the 'UTF8' append label as a no-op in my implementation). My implementation scans the header for 8-bit. If it sees any, it checks if it's valid UTF-8 in the header field value. If it's valid the header is allowed and a flag will be set in the store to indicate an EAI message. This took me a few days to implement (including nearly complete code coverage with unit tests). 3. quoted-strings can contain UTF-8 (but SHOULD NOT contain 8-bit that is not valid UTF-8). I found this straightforward to implement both on the server and my test client. I would not expect this to be problematic in other contexts. 4. LIST responses should be UTF-8 instead of MUTF-7. A tricky part here is dealing with RFC 5198. RFC 6855 forbids mailbox names that violate RFC 5198. However, I'm aware of at least one widely deployed client that attempts to create MUTF-7 mailbox names that violate RFC 5198. This creates interoperability problems. I think the RFC 5198 text in RFC 6855 is not sufficient to get interoperability in the real world. I think we should require servers to perform NFC normalization on mailbox names. I don't have implementation experience with UTF-8 mailbox listings yet; if someone else does input would be welcome. 5. Clients SHOULD USE UTF-8 mailbox names in all mailbox commands, and servers MUST accept that. I've implemented code to convert between these formats, it's some effort but not terribly difficult. Again, the RFC 5198 issues should be addressed. The tricky case is when a client does: "CREATE <5198-incompliant-mbox-name>". The server should either reject the name or normalize the name (and I'd prefer this be a MUST). I think mandatory server normalization is more likely to work in practice, but could still cause issues. Unfortunately 5198 didn't exist when RFC 3501 was written so we got this wrong in the IMAP base spec. I've written code to normalize MUTF-7 using ICU; I did not find that code difficult. Many client environments also have simple normalization APIs, such as CFStringNormalize(cfMutable, kCFStringNormalizationFormC). If WG accepts this proposal, I'm willing to do an editing pass on IMAP4rev2 to integrate this (although no objections if Alexey wants to do it instead). - Chris From nobody Wed Jul 18 11:05:51 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F27B130E33 for ; Wed, 18 Jul 2018 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 4zwkG8jDMTts for ; Wed, 18 Jul 2018 11:05:48 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4F962130EC2 for ; Wed, 18 Jul 2018 11:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1531937146; d=isode.com; s=june2016; i=@isode.com; bh=ONWGfgX6Ol5ectnY7xeUjCL4jrXSJWQBcCIXu+mp2io=; 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=TZMH++/bBCbfFVR6G5TjvJXwILRoARkb1jFqvuV2+wUDj8vWJi/jsH63hnrUyoOjKygFJd M/WV49YXOJpHMFDjbXYaSgZlAumcB6FB7WovgPHpEnNNomaALYP0vU7uyS7bL1JEFkIEYy OAUBz9ao+hhWSZEqLY3Nv5Euq0QZNKk=; Received: from [31.133.133.50] (dhcp-8532.meeting.ietf.org [31.133.133.50]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 18 Jul 2018 19:05:46 +0100 From: Alexey Melnikov To: Chris Newman , extra@ietf.org References: <9DF2BF4C-217D-4E3D-947A-743BD7778863@oracle.com> Openpgp: preference=signencrypt Message-ID: <81501da6-556c-bb5c-efce-496a9af86b22@isode.com> Date: Wed, 18 Jul 2018 19:05:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: <9DF2BF4C-217D-4E3D-947A-743BD7778863@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Extra] IMAP4rev2 and EAI (RFC 6532, 6855) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 18:05:50 -0000 Hi Chris, On 18/07/2018 17:48, Chris Newman wrote: > If WG accepts this proposal, I'm willing to do an editing pass on > IMAP4rev2 to integrate this (although no objections if Alexey wants to > do it instead). How about you do a pass over the document (you can download the latest XML from datatracker) and the WG can have a look at the result? I think all of these changes look fine, but I personally would like to have a look at their cumulative effect. Best Regards, Alexey From nobody Wed Jul 18 13:58:40 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84021271FF for ; Wed, 18 Jul 2018 13:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YYh6n6mz-qHF for ; Wed, 18 Jul 2018 13:58:35 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 967C7130EBE for ; Wed, 18 Jul 2018 13:58:34 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 58F702B3CCE; Wed, 18 Jul 2018 23:58:28 +0300 (EEST) To: Ned Freed Cc: extra@ietf.org, Bron Gondwana References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> From: Stephan Bosch Message-ID: <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> Date: Wed, 18 Jul 2018 22:58:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <01QTO3THVZ5I00AI1F@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:58:38 -0000 Hi Ned, Op 13/06/2018 om 17:40 schreef Ned Freed: >> > This, incidentially, is one of those places where providing the >> actual IMAP >> > commands will be especially valuable: Pointing out that you should >> use the >> > NAMESPACE extension and if it isn't present, fallback to LIST "" >> would be very >> > helpful. > >> Here's my initial attempt at addressing this point (separate branch in >> Github): > >> https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/035a1af6137a383089c8d54cd733238dc2dfebda >> > >> This adds an IMAP example for specialuse_exists. > >> What do you think? > > The first step seems fine: > >   C: A01 NAMESPACE >   S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/")) >   S: A01 OK NAMESPACE command completed > > In the next step: > >    Subsequently, when no particular mailbox is of interest (i.e., the >    "specialuse_exists" test has no mailbox argument), the client lists >    all mailboxes with special-use flags in the two returned personal >    namespaces: > >    C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN > (SPECIAL-USE) >    S: * LIST (\Drafts) "/" INBOX/Drafts >    S: * LIST (\Trash) "/" INBOX/Trash >    S: * LIST (\Sent) "/" INBOX/Sent >    S: * LIST (\Archive) "/" Archive/Default > > It should be noted that this depends on extended list being available. True. I thought LIST-EXTENDED is pretty much required for SPECIAL-USE, but the specification doesn't actually mention anything like that. Is there another way to obtain information on which mailboxes have a particular special-use flag assigned? > The final step is: > >    C: A03 SELECT Archive/Default >    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) >    S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \Draft \*)] Flags > permitted. >    S: * 11211 EXISTS >    S: * 3 RECENT >    S: * OK [UIDVALIDITY 1526903163] UIDs valid >    S: * OK [UIDNEXT 11278] Predicted next UID >    S: A03 OK [READ-WRITE] SELECT command completed > > There are several issues here. > > First, if you're going to use SELECT it's probably worth noting that > since > inclusion of [READ-WRITE] for writable mailboxes is a SHOULD in RFC > 3501 while > inclusion of [READ-ONLY] for non-writable is a MUST, a writability > check really > needs to based on the absence of [READ-ONLY]. (RFC 5490 3.1.a appears > incorrect > to me in this regard - should I file an errata?) Agreed. > However, I think use of SELECT for this purpose is problematic: It's > potentially expensive and worse, may cause undesireable state changes. > Why > not use the MYRIGHTS command to obtain the access rights (and check > for "p" or > "i") without having to select the mailbox? Sure, if the ACL capability is available. I can mention that. If it is not available, there is really no alternative to using SELECT, right? > And as a bonus, if it's available you could use the just-standardized > LIST-MYRIGHTS extension to piggyback getting the rights while getting > the list > of special-use mailboxes. Sure. > More generally, this is why documenting the things necessary to > implement the > necessary semantics of an extension is helpful - there may be > optimizations and > concerns that should be called out lest implementors miss them. > > It also helps clarify overall implementation difficulty. And while this > extension may be easy to implement in the Sieve-in-IMAP case, from the > perspective of an MTA/MDA implementation, even if all of the steps can > be done > efficiently, there's still the question of IMAP server availability > and the > handling of temporary errors. > Yeah. > All of which is roundabout way of saying I now think that we may want a > capability for specialuse_exists that's separate from > "special-use"/:specialuse. Or better still, since we already have the > "mailbox" > capability for "mailbox access stuff", I think we should require the > presence > of both "mailbox" and "special-use" capabilities in order to use > specialuse_exists. Can you clarify this point? I don't see how this leads to requiring the mailbox extension. > I also reviewed the rest of the revised draft, and it's looking good. > My one > remaining concern is with the handling of multiple mailboxes having the > same special-use flag assigned. The draft currently says: > >   More than one mailbox in the user's personal namespace can have a >   particular special-use flag assigned.  In case of such ambiguity, the >   mailbox that is chosen for delivery is implementation-defined. >   However, while the set of mailboxes to which the involved special-use >   flags are assigned remains unchanged, implementations MUST ensure >   that the mailbox choice is made consistently, so that the same >   mailbox is used every time.  Conversely, the chosen mailbox MAY >   change once the special-use flag assignments that are relevant for >   the mailbox choice are changed (usually by user interaction). > > I don't see a way I can reasonably implement this MUST via IMAP unless > the IMAP server always returns the list of special-use mailboxes in > the same order. > Sure, I can cache the user/special-use-attribute/actual-mailbox-list > tuple > somewhere, but caches can always be lost. And mailbox metadata is (a) > Potentially much too expensive and (b) Subject to the vagarities of user > actions. > > I'm not happy about it, but I think this needs to become a SHOULD. Ok. I am not too attached to the MUST anyway. > Another possibility is to use the default mailbox name as a means of > disambiguating multiple mailboxes with the same special-use attribute: > If the default mailbox is one of these deliver to it preferentially, > otherwise the behavior is implementation-defined. Not perfect, but it > provides a bit more consistent behavior that's easily achievable. > Sounds like a good idea. I'll give this a closer look for the next revision. > Aside from these issues, this draft looks good to go to me. I still need to make an IMAP example for "fileinto :specialuse". I should be able to work on this next week. Regards, STepham. From nobody Thu Jul 19 07:10:14 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0416131091 for ; Thu, 19 Jul 2018 07:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 PdOTmNBBuY_L for ; Thu, 19 Jul 2018 07:10:00 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 7DA95130F0D for ; Thu, 19 Jul 2018 07:10:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV1PSHGBBK004LSF@mauve.mrochek.com> for extra@ietf.org; Thu, 19 Jul 2018 07:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532009096; bh=+wC98VyK9NUAhNujPcIARVr9Ac4jxBC7a/yrlVY+ykk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=bMicz3wLp4kPYL3W5CboxPPLXoT6157cdFpoDni0gPUJh+za298gHLXl8EN8PlxQ0 bY03xWmzCnjp1cVHjQI51Psv2X5K/aS1QC4y9WGDwo3oNSywqS3khYaN0JkoXxnNkg YpnCvLTjZyv0J4kfivhBYrtdM97qd3mBpSW9hzWs= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUCIBNY1B4000051@mauve.mrochek.com>; Thu, 19 Jul 2018 07:04:54 -0700 (PDT) Cc: Ned Freed , extra@ietf.org, Bron Gondwana Message-id: <01QV1PSEOL14000051@mauve.mrochek.com> Date: Thu, 19 Jul 2018 06:40:25 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 18 Jul 2018 22:58:09 +0200" <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> To: Stephan Bosch Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:10:12 -0000 > > In the next step: > > > >    Subsequently, when no particular mailbox is of interest (i.e., the > >    "specialuse_exists" test has no mailbox argument), the client lists > >    all mailboxes with special-use flags in the two returned personal > >    namespaces: > > > >    C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN > > (SPECIAL-USE) > >    S: * LIST (\Drafts) "/" INBOX/Drafts > >    S: * LIST (\Trash) "/" INBOX/Trash > >    S: * LIST (\Sent) "/" INBOX/Sent > >    S: * LIST (\Archive) "/" Archive/Default > > > > It should be noted that this depends on extended list being available. > True. I thought LIST-EXTENDED is pretty much required for SPECIAL-USE, > but the specification doesn't actually mention anything like that. Is > there another way to obtain information on which mailboxes have a > particular special-use flag assigned? Yes, according to RFC 6154 section 2 special use attributes MAY appear in non-extended LIST responses. There's an example of this in section 5.1. However, the fact that this is a MAY makes it effectively useless since you can't tell the difference between a case where there are no special use attributes assigned and one where the server has simply elected not to include these attributes in its responses. And it's expected that the overwhelming majority of mailboxes won't have any special use assigned. In fact I'd go so far to say that this is a design error. It's one thing to want to support existing implementations of special use attributes, it's another to be so permissive that a compliant implementation - one that supports SPECIAL-USE but not LIST-EXTENDED - can have no way to determine what the special use mailboxes are actually present. All that said, all I was asking for here was a note saying this depended on LIST-EXTENDED. Nothing more. (Personally, I don't intend to even bother to check if it's supported.) > > However, I think use of SELECT for this purpose is problematic: It's > > potentially expensive and worse, may cause undesireable state changes. > > Why > > not use the MYRIGHTS command to obtain the access rights (and check > > for "p" or > > "i") without having to select the mailbox? > Sure, if the ACL capability is available. I can mention that. If it is > not available, there is really no alternative to using SELECT, right? Not as far as I know. But again, the problem is that SELECTing a mailbox on behalf of a user can change its state, with all that implies. I'd rather have my implementation fail if ACL isn't present than have a sieve operation cause a state change. > > All of which is roundabout way of saying I now think that we may want a > > capability for specialuse_exists that's separate from > > "special-use"/:specialuse. Or better still, since we already have the > > "mailbox" > > capability for "mailbox access stuff", I think we should require the > > presence > > of both "mailbox" and "special-use" capabilities in order to use > > specialuse_exists. > Can you clarify this point? I don't see how this leads to requiring the > mailbox extension. It doesn't unless we want it to, and I think we want it to. We have this collection of stuff collected under the mailbox extension that lets sieve peek at the state of the mailbox. And here we have an extension that consists of two parts: One extending fileinto and the other adding to things you can peek at. >From an MTA implementation perspective, these are very distinct things, and the latter shares a ton of code with the mailbox extension. It therefore makes sense to me to separate the two and link it to the mailbox extension. It's really no different than the way SPECIAL-USE and LIST-EXTENDED interact on the IMAP side of things: Both have to be present for the RETURN (SPECIAL-USE) stuff to work. Ned From nobody Thu Jul 19 07:15:01 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52C213108F for ; Thu, 19 Jul 2018 07:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RNfTu9EC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=amqI1SCv 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 gh8LTmRUV-d6 for ; Thu, 19 Jul 2018 07:14:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE3F130EB0 for ; Thu, 19 Jul 2018 07:14:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D713221C51; Thu, 19 Jul 2018 10:14:47 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 10:14:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Lf/nL/ W3KLeIPb+58y7u7PvH+zbyeOkJz0xYfG0qKi0=; b=RNfTu9EC3VLKu7YS0E5c4I NfwYIDs8LNzSuj5z2MTj7WjRk21dYyHCq7mKvtmWr/XmlOKbTBaigKRAtHVRTDLZ W0BI6Die0u2JMHigvy6S99tN1sq5taAec+46alSYdqeGiH6IT2OGwTu3NBuk+E2g k0NZyWIILuNqL5EaFps2uDTgE3FyDgEpovkOvtHHKTtguZwbc9Hp+6G84tDAqvf6 uDydA/Wwj6iNBaqQZ61q8IT/IpI6iCZSY2xmzCd86DUDOcf8Jw2nYet3S4pCeJcF H6Q6kXVqwYmXNQ7n7WoRAq1aLNJiAXlulbO+G2ab+GNo3JzybKQcgXdKvX76htmQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Lf/nL/ W3KLeIPb+58y7u7PvH+zbyeOkJz0xYfG0qKi0=; b=amqI1SCvr8fe0oTBG8Mge0 beO8MPivHj8NQ5fB42UeolL8Bk9vCweSgJBXEOFGA2m13jB5e704/jJuv48y5QBi ErHZAZHROkl4kzj3dmu2YVwbEtgaE1OKCqCyaJU/qfSSr4q99eHpQ94+uXQ+1uMi ci+puDID/QbgCmGkrfuTo5IM4wuTPyCjI8ZfioN6Opt9XhZ5TW8Db5T06YltAyGD Z6kM726NV3J6oz0RkD3l91IHtC8a5ToCbBWV6/Q29RNDh3dYYEYMF0uOxrNCnaOv gV83el9+f1nd5JnuDxLh103eUEtj+/runJiNuV9ma/mbfhfHYHiiIkYsKRBpOucA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 65D7E940DA; Thu, 19 Jul 2018 10:14:47 -0400 (EDT) Message-Id: <1532009687.619593.1446153224.1D941F59@webmail.messagingengine.com> From: Bron Gondwana To: Ned Freed , Stephan Bosch Cc: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15320096876195931" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> <01QV1PSEOL14000051@mauve.mrochek.com> In-Reply-To: <01QV1PSEOL14000051@mauve.mrochek.com> Date: Fri, 20 Jul 2018 00:14:47 +1000 Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:15:00 -0000 This is a multi-part message in MIME format. --_----------=_15320096876195931 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, Jul 19, 2018, at 23:40, Ned Freed wrote: >>> In the next step: >>> >>> Subsequently, when no particular mailbox is of interest (i.e., >>> the>>> "specialuse_exists" test has no mailbox argument), the client >>> lists>>> all mailboxes with special-use flags in the two returned personal>>> namespaces: >>> >>> C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN >>> (SPECIAL-USE) >>> S: * LIST (\Drafts) "/" INBOX/Drafts >>> S: * LIST (\Trash) "/" INBOX/Trash >>> S: * LIST (\Sent) "/" INBOX/Sent >>> S: * LIST (\Archive) "/" Archive/Default >>> >>> It should be noted that this depends on extended list being >>> available.> >> True. I thought LIST-EXTENDED is pretty much required for SPECIAL- >> USE,>> but the specification doesn't actually mention anything like that. Is>> there another way to obtain information on which mailboxes have a >> particular special-use flag assigned? > > Yes, according to RFC 6154 section 2 special use attributes MAY > appear in> non-extended LIST responses. There's an example of this in > section 5.1.> > However, the fact that this is a MAY makes it effectively useless > since you> can't tell the difference between a case where there are no > special use> attributes assigned and one where the server has simply elected not > to include> these attributes in its responses. And it's expected that the > overwhelming> majority of mailboxes won't have any special use assigned. MAY fricking shmay. There are clients out there which flat out expect that you return the SPECIAL-USE for an unadorned LIST, and customers report your server as buggy if it doesn't do what their client expects. > In fact I'd go so far to say that this is a design error. It's > one thing> to want to support existing implementations of special use > attributes, it's> another to be so permissive that a compliant implementation - one that> supports SPECIAL-USE but not LIST-EXTENDED - can have no way to > determine> what the special use mailboxes are actually present. I'm sure that RFC3501bis (IMAP4rev2) will fix this. > All that said, all I was asking for here was a note saying this > depended on> LIST-EXTENDED. Nothing more. (Personally, I don't intend to even > bother to> check if it's supported.) That seems very reasonable. >>> However, I think use of SELECT for this purpose is problematic: It's>>> potentially expensive and worse, may cause undesireable state >>> changes.>>> Why >>> not use the MYRIGHTS command to obtain the access rights (and check>>> for "p" or >>> "i") without having to select the mailbox? > >> Sure, if the ACL capability is available. I can mention that. >> If it is>> not available, there is really no alternative to using SELECT, right?> > Not as far as I know. But again, the problem is that SELECTing > a mailbox> on behalf of a user can change its state, with all that implies. > I'd rather> have my implementation fail if ACL isn't present than have a sieve > operation> cause a state change. Thanks \Recent. But at least EXAMINE rather than SELECT should also mean no change made (in theory). >>> All of which is roundabout way of saying I now think that we may >>> want a>>> capability for specialuse_exists that's separate from >>> "special-use"/:specialuse. Or better still, since we already >>> have the>>> "mailbox" >>> capability for "mailbox access stuff", I think we should require the>>> presence >>> of both "mailbox" and "special-use" capabilities in order to use >>> specialuse_exists. > >> Can you clarify this point? I don't see how this leads to >> requiring the>> mailbox extension. > > It doesn't unless we want it to, and I think we want it to. We > have this> collection of stuff collected under the mailbox extension that lets > sieve peek> at the state of the mailbox. And here we have an extension that > consists of two> parts: One extending fileinto and the other adding to things you can > peek at.> > From an MTA implementation perspective, these are very distinct > things, and> the latter shares a ton of code with the mailbox extension. It > therefore> makes sense to me to separate the two and link it to the mailbox > extension.> > It's really no different than the way SPECIAL-USE and LIST-EXTENDED > interact on the IMAP side of things: Both have to be present for the > RETURN (SPECIAL-USE) stuff to work. > > Ned -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15320096876195931 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, Jul 19, 2018, at 23:40, Ned Freed wrote:
In the next step:

   Subsequently, when no particular mailbox is of interest (i.e., the
   "specialuse_exists" test has no mailbox argument), the client lists
   all mailboxes with special-use flags in the two returned personal
   namespaces:

   C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN
(SPECIAL-USE)
   S: * LIST (\Drafts) "/" INBOX/Drafts
   S: * LIST (\Trash) "/" INBOX/Trash
   S: * LIST (\Sent) "/" INBOX/Sent
   S: * LIST (\Archive) "/" Archive/Default

It should be noted that this depends on extended list being available.

True. I thought LIST-EXTENDED is pretty much required for SPECIAL-USE,
but the specification doesn't actually mention anything like that. Is
there another way to obtain information on which mailboxes have a
particular special-use flag assigned?

Yes, according to RFC 6154 section 2 special use attributes MAY appear in
non-extended LIST responses. There's an example of this in section 5.1.

However, the fact that this is a MAY makes it effectively useless since you
can't tell the difference between a case where there are no special use
attributes assigned and one where the server has simply elected not to include
these attributes in its responses. And it's expected that the overwhelming
majority of mailboxes won't have any special use assigned.

MAY fricking shmay.  There are clients out there which flat out expect that you return the SPECIAL-USE for an unadorned LIST, and customers report your server as buggy if it doesn't do what their client expects.

In fact I'd go so far to say that this is a design error. It's one thing
to want to support existing implementations of special use attributes, it's
another to be so permissive that a compliant implementation - one that
supports SPECIAL-USE but not LIST-EXTENDED - can have no way to determine
what the special use mailboxes are actually present.

I'm sure that RFC3501bis (IMAP4rev2) will fix this.

All that said, all I was asking for here was a note saying this depended on
LIST-EXTENDED. Nothing more. (Personally, I don't intend to even bother to
check if it's supported.)

That seems very reasonable.

However, I think use of SELECT for this purpose is problematic: It's
potentially expensive and worse, may cause undesireable state changes.
Why
not use the MYRIGHTS command to obtain the access rights (and check
for "p" or
"i") without having to select the mailbox?

Sure, if the ACL capability is available. I can mention that. If it is
not available, there is really no alternative to using SELECT, right?

Not as far as I know. But again, the problem is that SELECTing a mailbox
on behalf of a user can change its state, with all that implies. I'd rather
have my implementation fail if ACL isn't present than have a sieve operation
cause a state change.

Thanks \Recent.  But at least EXAMINE rather than SELECT should also mean no change made (in theory).

All of which is roundabout way of saying I now think that we may want a
capability for specialuse_exists that's separate from
"special-use"/:specialuse. Or better still, since we already have the
"mailbox"
capability for "mailbox access stuff", I think we should require the
presence
of both "mailbox" and "special-use" capabilities in order to use
specialuse_exists.

Can you clarify this point? I don't see how this leads to requiring the
mailbox extension.

It doesn't unless we want it to, and I think we want it to. We have this
collection of stuff collected under the mailbox extension that lets sieve peek
at the state of the mailbox. And here we have an extension that consists of two
parts: One extending fileinto and the other adding to things you can peek at.

From an MTA implementation perspective, these are very distinct things, and
the latter shares a ton of code with the mailbox extension. It therefore
makes sense to me to separate the two and link it to the mailbox extension.

It's really no different than the way SPECIAL-USE and LIST-EXTENDED
interact on the IMAP side of things: Both have to be present for the
RETURN (SPECIAL-USE) stuff to work.

Ned

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15320096876195931-- From nobody Thu Jul 19 07:37:13 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460541310E8 for ; Thu, 19 Jul 2018 07:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UlXf0o_vQOJC for ; Thu, 19 Jul 2018 07:36:50 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 811851310F2 for ; Thu, 19 Jul 2018 07:36:50 -0700 (PDT) Received: from [192.168.1.109] (unknown [217.119.239.130]) by mail.dovecot.fi (Postfix) with ESMTPSA id D9C6828D0E2; Thu, 19 Jul 2018 17:30:23 +0300 (EEST) To: Bron Gondwana , Ned Freed Cc: extra@ietf.org References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> <01QV1PSEOL14000051@mauve.mrochek.com> <1532009687.619593.1446153224.1D941F59@webmail.messagingengine.com> From: Stephan Bosch Message-ID: Date: Thu, 19 Jul 2018 16:30:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1532009687.619593.1446153224.1D941F59@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:37:08 -0000 Op 19-7-2018 om 16:14 schreef Bron Gondwana: > On Thu, Jul 19, 2018, at 23:40, Ned Freed wrote: >> >> However, I think use of SELECT for this purpose is >> problematic: It's >> potentially expensive and worse, may cause undesireable state >> changes. >> Why >> not use the MYRIGHTS command to obtain the access rights (and >> check >> for "p" or >> "i") without having to select the mailbox? >> >> >> Sure, if the ACL capability is available. I can mention that. If >> it is >> not available, there is really no alternative to using SELECT, right? >> >> >> Not as far as I know. But again, the problem is that SELECTing a mailbox >> on behalf of a user can change its state, with all that implies. I'd >> rather >> have my implementation fail if ACL isn't present than have a sieve >> operation >> cause a state change. > > Thanks \Recent.  But at least EXAMINE rather than SELECT should also > mean no change made (in theory). > The EXAMINE command will not provide information on the read-only status of the mailbox though: RFC 3501, Section 6.3.2: The text of the tagged OK response to the EXAMINE command MUST begin with the "[READ-ONLY]" response code. Regards, -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kenttä Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Thu Jul 19 07:38:44 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B9B1310F8 for ; Thu, 19 Jul 2018 07:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=uPqfNE8k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pFzckOvo 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 QgVdaG6ygrGS for ; Thu, 19 Jul 2018 07:38:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC17513105F for ; Thu, 19 Jul 2018 07:38:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 39F9121ADA; Thu, 19 Jul 2018 10:38:27 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 10:38:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=CgCZ/3 71YAnkt3tmIQq93J3GlRavOWneQyFVpKAsPnA=; b=uPqfNE8kIkG/k+YmWzd5Bb cpP2XgCsY7li1imnp88GElTSB6cjeHU3VSpPjn97ihAz/Mh9tZDr3CGtAVGiXtgB hXyRDxd7etSi0qD8RVhUbifuvP+StFSQXAUOOJy6iHRRYOkJN+PX5t2p0lwphxA/ Ff2G7Y2/fh7yYTusYUBMtBvGT0/twe1bInIckBC+NM99kuMC59T7NxhZ65NQ6Iwz A1INaARU9x/wyVBXaK/4IZC9ZDHxBDTdPHYbFDV01HWixagzdqEmraAf5WnaQPOq SBrIg79P3wj7ifbQk23tazJwIyNk9HBLigsPyVWY/Za1pqycT4cFSGkurxeRvDUg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=CgCZ/3 71YAnkt3tmIQq93J3GlRavOWneQyFVpKAsPnA=; b=pFzckOvofX0BvobRMsyKOJ w3K2KUCVXAbAhZppy/+jyd+RexUW+SShp+ZgEsScuADcG/glSej60MlWzrlOddbu DO3rX3wAAJH2NWYiRzZAe0F7cbUe1HOFKiB7xMQa5gr7pPDtBpNwQmqVW/GOwRBf NQJTYGlmFYG80a79zi3q2Ht5PJVKcrj9XrtROgCdR/UkDkb0Acgm9NRp4XezIT3B 7hB8bZGA32wncaKRWiGs0RBuEiW+d5xz08f4QMiFWaVXw2wnq01x8NtOwPrFyBhK c65OmHAdBbdsu8hOk2ZsnRVoXa3vQayXCnsKhuKAXya3vqUAIjDYdHN1nbVvaXiQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C5190940DA; Thu, 19 Jul 2018 10:38:26 -0400 (EDT) Message-Id: <1532011106.627372.1446184024.23C7528C@webmail.messagingengine.com> From: Bron Gondwana To: Stephan Bosch , Ned Freed Cc: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15320111066273720" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 Date: Fri, 20 Jul 2018 00:38:26 +1000 In-Reply-To: References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> <01QV1PSEOL14000051@mauve.mrochek.com> <1532009687.619593.1446153224.1D941F59@webmail.messagingengine.com> Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:38:41 -0000 This is a multi-part message in MIME format. --_----------=_15320111066273720 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, Jul 20, 2018, at 00:30, Stephan Bosch wrote: > > > Op 19-7-2018 om 16:14 schreef Bron Gondwana: >> On Thu, Jul 19, 2018, at 23:40, Ned Freed wrote: >>> >>> However, I think use of SELECT for this purpose is >>> problematic: It's >>> potentially expensive and worse, may cause undesireable state>>> changes. >>> Why >>> not use the MYRIGHTS command to obtain the access rights (and>>> check >>> for "p" or >>> "i") without having to select the mailbox? >>> >>> >>> Sure, if the ACL capability is available. I can mention that. If >>> it is >>> not available, there is really no alternative to using SELECT, >>> right?>>> >>> >>> Not as far as I know. But again, the problem is that SELECTing a >>> mailbox>>> on behalf of a user can change its state, with all that implies. I'd>>> rather >>> have my implementation fail if ACL isn't present than have a sieve >>> operation >>> cause a state change. >> >> Thanks \Recent. But at least EXAMINE rather than SELECT should also>> mean no change made (in theory). >> > > The EXAMINE command will not provide information on the read- > only status> of the mailbox though: > > RFC 3501, Section 6.3.2: > > The text of the tagged OK response to the EXAMINE command MUST begin > with the "[READ-ONLY]" response code. Oh yeah, good point. Right! So MYRIGHTS seems the right way then :) (it's certainly what we're doing the moral equivalent of inside our code) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15320111066273720 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, Jul 20, 2018, at 00:30, Stephan Bosch wrote:


Op 19-7-2018 om 16:14 schreef Bron Gondwana:
On Thu, Jul 19, 2018, at 23:40, Ned Freed wrote:

      However, I think use of SELECT for this purpose is
      problematic: It's
      potentially expensive and worse, may cause undesireable state
      changes.
      Why
      not use the MYRIGHTS command to obtain the access rights (and
      check
      for "p" or
      "i") without having to select the mailbox?


  Sure, if the ACL capability is available. I can mention that. If
  it is
  not available, there is really no alternative to using SELECT, right?


Not as far as I know. But again, the problem is that SELECTing a mailbox
on behalf of a user can change its state, with all that implies. I'd
rather
have my implementation fail if ACL isn't present than have a sieve
operation
cause a state change.

Thanks \Recent.  But at least EXAMINE rather than SELECT should also
mean no change made (in theory).


The EXAMINE command will not provide information on the read-only status
of the mailbox though:

RFC 3501, Section 6.3.2:

The text of the tagged OK response to the EXAMINE command MUST begin with the "[READ-ONLY]" response code.

Oh yeah, good point.  Right!  So MYRIGHTS seems the right way then :)  (it's certainly what we're doing the moral equivalent of inside our code)

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15320111066273720-- From nobody Thu Jul 19 07:59:45 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F49130E7C for ; Thu, 19 Jul 2018 07:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 1Mkl7gPhELCE for ; Thu, 19 Jul 2018 07:59:41 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 D1D20130E02 for ; Thu, 19 Jul 2018 07:59:41 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV1RK99VDS005IOG@mauve.mrochek.com> for extra@ietf.org; Thu, 19 Jul 2018 07:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532012134; bh=nmZ4k+U6k/fS0sUiDMDWnOcYZ0xWXDF8iTVGEdxbEZI=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Yz13oPXnj99rqdWu1dJ49olEFmKzUxQf25Zkysd9O311DwqRSxIyzEmtSlYl2UJML dMc9TUn5xl3sVbb0rZzoVrY+Dy9jKtmeClUilRLNr1Cupu15inL0j48K8rYwSLhcZl x8pTKI6K0IEiiKq6jm1fy2uN0F6ur8NBRj6h7RAc= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUCIBNY1B4000051@mauve.mrochek.com>; Thu, 19 Jul 2018 07:55:31 -0700 (PDT) Cc: Ned Freed , Bron Gondwana , extra@ietf.org Message-id: <01QV1RK6PYPO000051@mauve.mrochek.com> Date: Thu, 19 Jul 2018 07:32:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 15 Jun 2018 18:45:20 -0400" References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> <01QTIJ66FRSK000051@mauve.mrochek.com> <90322c67-3f2b-6322-12c0-6870e2a8b2ac@fastmail.com> <01QTJR8Q97NK000051@mauve.mrochek.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:59:43 -0000 > Hi Nedx > On 06/10/2018 07:01 PM, Ned Freed wrote: > > > >> On 06/09/2018 08:49 PM, Ned Freed wrote: > >> > Section 3.3. I suggest that for now this be made specific to the > >> mailto: > >> > method. If someone wants to write some requirements for tel: and > >> xmpp: that's > >> > fine too. > Do you have suggestions as to how you would like to see the existing > text modified? On further reflection, since xmpp is only mentioned as an example an tel not at all, I think this is OK. I'm still a little uncomfortable with mentioning xmpp here since it might be interpreted as saying this specification provides everything you need to implement :fcc for xmpp - and I'm fairly sure it falls short of this - but the value of the example seems to outweigh that. That said, and given the lack of specificity of the specification in regards to existing notification methods, I think it should be permissible to only implement :fcc for a subset of the notification methods an implementation is able to generate. So how about adding: An implementation MAY only support :fcc in conjunction with a subset of the notification methods it supports. An error errors if :fcc is combined with a notification method that doesn't support it. And this in turn brings up another idea - how about adding a "fcc" notify_method_capability (RFC 5435 section 5) that can be used to determine if a given notification method supports :fcc? (With possible values "yes" and "no", of course). Ned From nobody Thu Jul 19 09:09:34 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EA8130E63 for ; Thu, 19 Jul 2018 09:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 YLseIgXkutS8 for ; Thu, 19 Jul 2018 09:09:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 1BFCB130E52 for ; Thu, 19 Jul 2018 09:09:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV1TYLKSUO007KBZ@mauve.mrochek.com> for extra@ietf.org; Thu, 19 Jul 2018 09:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532016264; bh=vItpCu5xFaAx9H5mZrbUB75Ugqd/DaklmvNXZgd/IL4=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=GMVoSUe9dc8/aQiUQ/SsolbFkoJuUIX8ZknLFRVr8Sxp1+LDD6hMty78xyw3EmuxK x6ydoSID19etdz/t3wVKGiNmMJ1QY/8d47G57I1yidVBmmr87oMBvWf/pcqUW//jY6 f/tFApqilqBYtDSBiEIPH54oFtsxiWjDrKrCvvbk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUCIBNY1B4000051@mauve.mrochek.com>; Thu, 19 Jul 2018 09:04:21 -0700 (PDT) Cc: Ned Freed , Stephan Bosch , extra@ietf.org Message-id: <01QV1TYIJU38000051@mauve.mrochek.com> Date: Thu, 19 Jul 2018 09:00:45 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 20 Jul 2018 00:14:47 +1000" <1532009687.619593.1446153224.1D941F59@webmail.messagingengine.com> References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> <01QV1PSEOL14000051@mauve.mrochek.com> <1532009687.619593.1446153224.1D941F59@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Subject: [Extra] SPECIAL-USE MAY appear in LIST responses (was: Re: I-D Action: draft-ietf-extra-sieve-special-use-01.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 16:09:32 -0000 > > Yes, according to RFC 6154 section 2 special use attributes MAY > > appear in> non-extended LIST responses. There's an example of this in > > section 5.1.> > > However, the fact that this is a MAY makes it effectively useless > > since you> can't tell the difference between a case where there are no > > special use> attributes assigned and one where the server has simply elected not > > to include> these attributes in its responses. And it's expected that the > > overwhelming> majority of mailboxes won't have any special use assigned. > MAY fricking shmay. :) > There are clients out there which flat out expect > that you return the SPECIAL-USE for an unadorned LIST, and customers > report your server as buggy if it doesn't do what their client expects. Well, if that's the case, we have a problem independent of this Sieve extension. Do we need to at least file an errata on this? > > In fact I'd go so far to say that this is a design error. It's > > one thing> to want to support existing implementations of special use > > attributes, it's> another to be so permissive that a compliant implementation - one that> supports SPECIAL-USE but not LIST-EXTENDED - can have no way to > > determine> what the special use mailboxes are actually present. > I'm sure that RFC3501bis (IMAP4rev2) will fix this. Which creates a dependency on yet another IMAP extension. Not sure if this is sufficient. Ned From nobody Thu Jul 19 12:24:48 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBFE130F5C for ; Thu, 19 Jul 2018 12:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JCFPOnpA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RvpH/eqA 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 nO446AVy10GO for ; Thu, 19 Jul 2018 12:24:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889C5131109 for ; Thu, 19 Jul 2018 12:24:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E092421EDD for ; Thu, 19 Jul 2018 15:24:35 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 15:24:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=EhjevAvIXvT4CLp6oDgCwm6BBw1JeYcwWCopkLE5p 6M=; b=JCFPOnpAHlCyfMzD0CE1j3YeiEPWCiB8C+EE3GcgtTlrpe6XwuCRNh0Uk VWUb0vhOo0S81yuxvSVAmgUKPMkEyhdySnxAYBD9A6NLC1DE3O4dEybsqX9UC6kw jB2cS1pGYpoI7BgxK+89q5/2cmScvscXqHC8/2cQDXqPgw2g61q30inGO/SIOuHR ngCboKw8Xv+XN3iXLG8UlcVv8O+B7ZufsHa8Xc+tpeuVXmqicb/B/ADgmsmItELM 02vyJREk5LB6EGiEHyU44evO8YrCMR5k3xSaAKQJKmMbhP7bkI8ISwM2MKLHUx95 k1e2F9dIsb88LmXtMeUUOU7nQsRJg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=EhjevAvIXvT4CLp6oDgCwm6BBw1Je YcwWCopkLE5p6M=; b=RvpH/eqAKrm7SNmoYBH4S64bWdGFX3N7a61Ji3BrjCpqH 4DcNIMxj14/O4w16hxj2XJ0FBvMEjWDYZqEWdWgk0A2k5zkfmLZb/d14v6QYy/CC IN5I73W6zbVqSOldD+obBYfcRYSBfrRWQSjVw9l6BMdUBJ4mAJS7+fqfAnMD0CNr /Svhldr01WNDqT+QswiV68iouT5yM6zkPZQTBmjLb6DrQOChXZQvMvV4tTCa9sLM 5M9ssYJrpWd2RRRTPMYkrNuaWtVo85uGbCqbWqSRg3DwAdRxZQ+ity1Z5gqNIx9q eU8oEEV5OS17URwaC6kkDJyW9Fn2xFh21VyN2YOAw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 90715940DA; Thu, 19 Jul 2018 15:24:35 -0400 (EDT) Message-Id: <1532028275.706418.1446506824.1F4B9B58@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15320282757064181" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 Date: Fri, 20 Jul 2018 05:24:35 +1000 Archived-At: Subject: [Extra] Minutes from IETF102 meeting X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:24:47 -0000 This is a multi-part message in MIME format. --_----------=_15320282757064181 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" EXTRA session minutes - IETF102 Montreal - 19-Jul-2018 11:00-12:00 Agenda bash - no changes suggested EXISTING DOCUMENTS: =================== sieve-fcc: Ken Murchison * There are some nits from Ned on the mailing list * Suggested approach - test for fcc support for each notify type * NEXT STEPS: Poll list for WGLC after next draft sieve-specialuse: Stephan Bosch * Only outstanding work is updating IMAP-equivalent examples * NEXT STEPS: Poll list for WGLC after next draft savedate: Stephan Bosch * Only delayed because I dropped the ball * NEXT STEPS: Working group last call objectid: Bron Gondwana * Thanks to Pete Resnick's GENART review, making it much more MUSTy * General opinion in the room - unless somebody said "this will be hard for me to implement" keep everything in. * Suggestion: make thinks strict in base spec and if people need a more relaxed thing, they can propose a spec for that. * NEXT STEPS: Poll mailing list for any issues with going to all MUST. imap4rev2: Alexey Melnikov * Barry Leiba is joining as co-author and will document the elimination of non-extended responses for LIST, SEARCH, et al. * General support for making EAI/8bit be in scope - the world is moving towards that, and this is IMAP for the future, not just the now. * Need to reach out on the mailing list for people who expect this will be a problem for them! * Some discussion of use of VANISHED rather than EXPUNGED responses, and UID in unsolicited FETCH responses. General approach, more towards keying on UID rather than MSGNO. * Some things like LIST-MYRIGHTS and full CONDSTORE/QRESYNC may not be included in the "required" part of the spec, but will add a section for "recommended other extensions for servers to support". * BINARY - binary FETCH is easier than binary APPEND so maybe should just mandate FETCH as a happy middle ground. * NEXT STEPS: keep working on the list, with special focus on EAI and BINARY. PROPOSED DOCUMENTS: =================== replace: Stuart Brandt * Has already been debated on the list, and everyone is fine with it. * NEXT STEPS: call for adoption (or objections to same) on the mailing list with an eye to immediate last call. snippet: Michael Slusarz ( thanks Michael for persisting through technical difficulties to present remotely ) * Already implemented and working in Dovecot * Interest in providing things like transcriptions of attached voice messages (instead of using metadata or conversion) * Question about non-text (e.g. image) snippets - for commercial mail particularly if we define a way to extract them, they will add them to their messages! * Definitely an appetite in the room for the work * NEXT STEPS: call for adoption (or objections to same) on the mailing list with an eye to ongoing discussion about exactly how and what it should be client-id: Michael Peddemors * Proposal is a new IMAP command before authentication used to provide a token that is unique to the particular piece of client software, allowing some level of protection against password reuse (2.5 factor auth) * Was generally agreed that the identified underlying issue (knowing that the same client is connecting) is worth examining. * Would also need to be added to SUBMIT, POP3, LDAP, CalDAV, CardDAV, etc. There's already an existing draft for SUBMIT. * The name CID is confusing because it has another meaning in MIME - definitely recommend renaming the command. * Strong suggestion that SASL might be the right place for this rather than per-protocol commands. * If this belongs in SASL, then it's not in scope for EXTRA and a different home should be found for the work. * NEXT STEPS: keep discussing on extra list for now while trying to work out the correct home. There is not consensus for adopting this work in its current form. OTHER BUSINESS: =============== spam/phishing reporting: Bron Gondwana * Might be interest in a standard way to say "Block Sender/Whitelist Sender"* No concrete proposal for anything right now * NEXT STEPS: interested parties (if any) to keep talking on the list and come back if there's a proposal. createdmodseq/globalmodseq: Bron Gondwana * There's interest in keeping on talking about what this looks like * NEXT STEPS: intereseted parties to keep talking on the list and see if the discussion reaches a proposal. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15320282757064181 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
EXTRA session minutes - IETF102 Montreal - 19-Jul-2018 11:00-12:00

Agenda bash - no changes suggested

EXISTING DOCUMENTS:
===================

sieve-fcc: Ken Murchison
* There are some nits from Ned on the mailing list
* Suggested approach - test for fcc support for each notify type
* NEXT STEPS: Poll list for WGLC after next draft

sieve-specialuse: Stephan Bosch
* Only outstanding work is updating IMAP-equivalent examples
* NEXT STEPS: Poll list for WGLC after next draft

savedate: Stephan Bosch
* Only delayed because I dropped the ball
* NEXT STEPS: Working group last call

objectid: Bron Gondwana
* Thanks to Pete Resnick's GENART review, making it much more MUSTy
* General opinion in the room - unless somebody said "this will be hard
  for me to implement" keep everything in.
* Suggestion: make thinks strict in base spec and if people need a more
  relaxed thing, they can propose a spec for that.
* NEXT STEPS: Poll mailing list for any issues with going to all MUST.

imap4rev2: Alexey Melnikov
* Barry Leiba is joining as co-author and will document the elimination
  of non-extended responses for LIST, SEARCH, et al.
* General support for making EAI/8bit be in scope - the world is moving
  towards that, and this is IMAP for the future, not just the now.
* Need to reach out on the mailing list for people who expect this will
  be a problem for them!
* Some discussion of use of VANISHED rather than EXPUNGED responses, and
  UID in unsolicited FETCH responses.  General approach, more towards
  keying on UID rather than MSGNO.
* Some things like LIST-MYRIGHTS and full CONDSTORE/QRESYNC may not be
  included in the "required" part of the spec, but will add a section
  for "recommended other extensions for servers to support".
* BINARY - binary FETCH is easier than binary APPEND so maybe should just
  mandate FETCH as a happy middle ground.
* NEXT STEPS: keep working on the list, with special focus on EAI and
  BINARY.

PROPOSED DOCUMENTS:
===================

replace: Stuart Brandt
* Has already been debated on the list, and everyone is fine with it.
* NEXT STEPS: call for adoption (or objections to same) on the mailing list
  with an eye to immediate last call.

snippet: Michael Slusarz
( thanks Michael for persisting through technical difficulties to
   present remotely )
* Already implemented and working in Dovecot
* Interest in providing things like transcriptions of attached voice
  messages (instead of using metadata or conversion)
* Question about non-text (e.g. image) snippets - for commercial mail
  particularly if we define a way to extract them, they will add them
  to their messages!
* Definitely an appetite in the room for the work
* NEXT STEPS: call for adoption (or objections to same) on the mailing list
  with an eye to ongoing discussion about exactly how and what it should be

client-id: Michael Peddemors
* Proposal is a new IMAP command before authentication used to provide a
  token that is unique to the particular piece of client software, allowing
  some level of protection against password reuse (2.5 factor auth)
* Was generally agreed that the identified underlying issue (knowing that
  the same client is connecting) is worth examining.
* Would also need to be added to SUBMIT, POP3, LDAP, CalDAV, CardDAV, etc.
  There's already an existing draft for SUBMIT.
* The name CID is confusing because it has another meaning in MIME -
  definitely recommend renaming the command.
* Strong suggestion that SASL might be the right place for this rather
  than per-protocol commands.
* If this belongs in SASL, then it's not in scope for EXTRA and a different
  home should be found for the work.
* NEXT STEPS: keep discussing on extra list for now while trying to work
  out the correct home.  There is not consensus for adopting this work in
  its current form.

OTHER BUSINESS:
===============

spam/phishing reporting: Bron Gondwana
* Might be interest in a standard way to say "Block Sender/Whitelist Sender"
* No concrete proposal for anything right now
* NEXT STEPS: interested parties (if any) to keep talking on the list and
  come back if there's a proposal.

createdmodseq/globalmodseq: Bron Gondwana
* There's interest in keeping on talking about what this looks like
* NEXT STEPS: intereseted parties to keep talking on the list and see if
  the discussion reaches a proposal.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15320282757064181-- From nobody Thu Jul 19 12:45:26 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94B130E0A for ; Thu, 19 Jul 2018 12:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=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 YdVpK0Sd4Dyg for ; Thu, 19 Jul 2018 12:45:21 -0700 (PDT) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0565E130DC9 for ; Thu, 19 Jul 2018 12:45:21 -0700 (PDT) Received: by mail-it0-f45.google.com with SMTP id w16-v6so11530179ita.0 for ; Thu, 19 Jul 2018 12:45:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TKVrFUK9umIzRR83oJgQkUQGaoG0+G7w1FHWzSwJ0qk=; b=BKFn1rZk97uYz99SBFXmkd3ZPc4AWfthwzx8uyea0qocr9VGW1s/1Gi6JfNpNFNXCQ nVzaK6rVEefrXPFrNXJ8SSqquaTV9fMuVdja5+FT59MbBpoX++F9Ne/yFqalshCyV41f eO2d+lVvsam2kaD7yPBwoxR0Bh+bAaZfGjVm+IJItbD29wlHwj5ClJqeRPIJUCbfiGmh Xs/erXO0Gz3kt1QnB3DmZ73BWz9M9jLGm3ry13ROB/vJFi/TAW7bJ2kAJK0REHGZO4UW zDw4ieWV0y0SHu0l4UyhUoyuPlcq3JFUXSFv8pBkO/pz0JvGIHIMo2TgxZLl2hjPL6Cj 9dzQ== X-Gm-Message-State: AOUpUlE+Syxy0lnw74blDGwzylpFQhTtJmx9mwNp/5iBHSVJQ68lYqsH /OGiOiVuDVGi2KS4RecN+18Qn4ALNuVtwI/jCjXSmeIR X-Google-Smtp-Source: AAOMgpcu+Hqocl1LMFfDuniEnuViWd8aI/0UCGn/790Ugmt3f1TO09M/QWH73+kVPFbyQ7r4IjEXpnJj/uuIBCeGjxs= X-Received: by 2002:a02:9b54:: with SMTP id g20-v6mr11032170jal.33.1532029519848; Thu, 19 Jul 2018 12:45:19 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Thu, 19 Jul 2018 15:45:08 -0400 Message-ID: To: "extra@ietf.org" Content-Type: multipart/alternative; boundary="00000000000050e9f605715f6b2b" Archived-At: Subject: [Extra] My travel bag... X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:45:23 -0000 --00000000000050e9f605715f6b2b Content-Type: text/plain; charset="UTF-8" Thanks to the several of you who made sure I was reunited with my bag that I forgot in the meeting room! Barry -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ --00000000000050e9f605715f6b2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to the several of you who made sure I was reunited= with my bag that I forgot in the meeting room!

=
Barry

--
Ba= rry
--
Barry Leiba =C2=A0(barryleiba@computer.org)
http://internetmessagingtechno= logy.org/
--00000000000050e9f605715f6b2b-- From nobody Thu Jul 19 13:44:18 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB683130F16 for ; Thu, 19 Jul 2018 13:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=waAKf7F8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qLNBSDBE 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 lNXsEbqw_daz for ; Thu, 19 Jul 2018 13:44:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911AD130E2A for ; Thu, 19 Jul 2018 13:44:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CF51321DE0 for ; Thu, 19 Jul 2018 16:44:12 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 16:44:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=VDn9XitxZtkD/VJgWBdYYojH9zLfaydMcJWBy9/k1 0c=; b=waAKf7F8xqNNQGoaIdFEjO4FaR6WgVjW1BI+SmvT9b2+aDnInvLpql+vQ iZ4E2Ch0wy/Oo+stcI735I0gRN5pGp9JBJJs4y8ffX9FVXy7Qh6WM/SZl6blwiKW DIg0O6qAtmAZJpkh5nWDxCLjs7nl5vfKB4rwT6I0FZqYNEQ002Z0mafR9MtnwM32 NJB9Nu84fuogxhI7Qpz9FI5zllUZL2Nx+Ek5m+z6rGeqezh+I9KIpa8LkTd6pKLA 4cMlFEJg83QoiVLWpzEG1uoCZ/TNcfBz/nvaZ17Wan81ZKkSlYIZU0+ujfLwjkmA HVMQTt4pfZr9M8kiqdA6As3H56dig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=VDn9XitxZtkD/VJgWBdYYojH9zLfa ydMcJWBy9/k10c=; b=qLNBSDBEjz6sI7zk7IuzftjNr8wt6U8wxKU58mDXJu5HW xF1g20IxnTJcSDo7vZCjJDDpjT9EnJz/meuJYFQu0HdVhwWsbhfZOwvPVBjJEdxI zoM3+aWfahUbKumRDMWA3nyinvyn/jSlawagXsREoIaM8PeuNcfmXwMIIq1rPQ6E RAT5iiH4xOVhvG3cha1X7uXRG55hHJ461uS5uuOLy18z1J1u19OTBJqaZLbrQ9Zu D/46z36WjbM8qv7kh+oyEUkDs3IeLbm9IaX84ac1MMKdS2qXlN0OnuEtMznCgOxF PRk118xwVAM9F6nq4MAKPHgrN92uEQVAXt+tv6WQQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8633694133; Thu, 19 Jul 2018 16:44:12 -0400 (EDT) Message-Id: <1532033052.1784926.1446569704.08FEE52C@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153203305217849260" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 Date: Fri, 20 Jul 2018 06:44:12 +1000 Archived-At: Subject: [Extra] Working Group Last Call! savedate X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:44:17 -0000 This is a multi-part message in MIME format. --_----------=_153203305217849260 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, This was entirely on me - we had already agreed to go to working group last call after Stephan uploaded version 01. Since we already had agreement, I'm switching it to last call right now: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/01/ So here we go! Working group last call. I will be the shepherd for this spec. It will be in last call for 3 weeks, so until August 10th. Please review it again and provide feedback. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153203305217849260 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

This was entirely on me - we had already agreed to go to working group last call after Stephan uploaded version 01.  Since we already had agreement, I'm switching it to last call right now:

https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/01/

So here we go!  Working group last call.  I will be the shepherd for this spec.  It will be in last call for 3 weeks, so until August 10th.  Please review it again and provide feedback.

Cheers,

Bron.



--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153203305217849260-- From nobody Thu Jul 19 14:01:58 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B53130F78; Thu, 19 Jul 2018 14:01:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153203411582.10449.15303673020739673540@ietfa.amsl.com> Date: Thu, 19 Jul 2018 14:01:55 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-objectid-06.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:01:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP Extension for object identifiers Author : Bron Gondwana Filename : draft-ietf-extra-imap-objectid-06.txt Pages : 17 Date : 2018-07-19 Abstract: This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-objectid-06 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-objectid-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-objectid-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 19 14:08:53 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F1C130F59 for ; Thu, 19 Jul 2018 14:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Nq2g70Jk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KhX9fiUn 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 lPzL0Il6rVOz for ; Thu, 19 Jul 2018 14:08:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B194A124BE5 for ; Thu, 19 Jul 2018 14:08:47 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0CE2221ACE for ; Thu, 19 Jul 2018 17:08:47 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 17:08:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=FuR9gtXIVoiH3+wJbHZ1xrrKuc9jKz10o77wi0DPp 4M=; b=Nq2g70JkTOLvYgizJq8P9ErQh/Oiv3KKgKyClWxDu0S7kk+qoIVxua6Zs 8aD5+j7yWnbJT9q8U++MCJjx5ojcN2+Lrzgqr8jCVXth3yCEXva9jcvxd+qOzaX+ kGn8W5Ma7QXLT3r0qyxliH4/k/XuxEXfTPwizFKGeFw7J++IPx1PiQuyAsGFW8ju S8kg/1vty7UcfCizM86zZ6+4KHbLybF80+r1ZLtEo22Owr0zvoaIfBhQf8a6l5FL re28AAdiUhqSXuEsIT7Oo16R/6GbkESXd7/2v69PFP2v/QKCzdrdNmoo+aFFpuuc xYEd7tFliHD4PPMnlkGCSFJQCJHeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=FuR9gtXIVoiH3+wJbHZ1xrrKuc9jK z10o77wi0DPp4M=; b=KhX9fiUnoLGAlOGXP1R3ByNtYFdv1/4s+tLQCoVSCp5G0 PtXVD4ADNKXNZ/jm80vt1hKhOdX64WsSUSIR8SBXzeflhvdwkqcvQCUDFFDtrEkT CNWgD0bXmwHDQ/lomjwo2sK9QFUYVdGiJSwj4pMkRqnlF1MGV1Se+RNxJKHRfEis pTnd9ke0bTRSgz0SfXvtzpne5h29a+VcN5VBpSEiSzHiQFxW9BGC2BgJnddZf3eO nx3WVaprCGhD2BM0V+rDga+gN+0Z65qMJiY1Ad32ZYshUgZrMypyfITIjLNodAF+ pGMWFCf+099JE5k9CxBWeiLOl5hRea2MUlyGMJ+9A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9153E940DA; Thu, 19 Jul 2018 17:08:46 -0400 (EDT) Message-Id: <1532034526.1792463.1446606328.14CB8B22@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153203452617924633" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 Date: Fri, 20 Jul 2018 07:08:46 +1000 Archived-At: Subject: [Extra] Call for adoption and directly to WGLC - draft-brandt-imap-replace X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:08:51 -0000 This is a multi-part message in MIME format. --_----------=_153203452617924633 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" The draft is here: https://datatracker.ietf.org/doc/draft-brandt-imap-replace/ There's already been a bunch of discussion on the list, and the document appears to be in good shape. I'd like to kill two birds with one stone, so I'm asking if there are any objections to either of: a) adopting this document into this working group b) taking version -02 to working group last call I'll give two weeks for this. If there are no objections given, I intend to adopt the document and then immediately make a working group last call, which will be an additional period of 3 weeks. If you're happy to adopt, but think there's more discussion required - please do say, happy to do that too. Kind regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153203452617924633 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
The draft is here:


There's already been a bunch of discussion on the list, and the document appears to be in good shape.  I'd like to kill two birds with one stone, so I'm asking if there are any objections to either of:

a) adopting this document into this working group
b) taking version -02 to working group last call

I'll give two weeks for this.  If there are no objections given, I intend to adopt the document and then immediately make a working group last call, which will be an additional period of 3 weeks.

If you're happy to adopt, but think there's more discussion required - please do say, happy to do that too.

Kind regards,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153203452617924633-- From nobody Thu Jul 19 14:13:06 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24151130F67 for ; Thu, 19 Jul 2018 14:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=DtFXv6MA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E2+TRTsM 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 NOKCw_xOfFUD for ; Thu, 19 Jul 2018 14:13:03 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD841130F59 for ; Thu, 19 Jul 2018 14:13:02 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4B5B221949 for ; Thu, 19 Jul 2018 17:13:02 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 17:13:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=sYcgeRrrQbMr6gfPdaGMI/EpAo2EH78oL9Jf1d0d7 +k=; b=DtFXv6MAXWJdF8kprDcM2nahg+RPsYYYZxqmFJoYUqw+oBlfiPWwqfqMg Nw+RMo4J3iB5UH8Ze7RzED84fRkdXiCfSF4o2Jjnt38hziyuEW1wD2Ri+RcZ96v8 5lZt12Ray+XQcHFUufh/UdIhbm+ChxcCzFggbAubgMp/TxEI6V9EsWAZjrO/QqAF hUf14PEi/ih/vc1CsVaXxQVeORsFiAQJ8K/5/vX9At3mwEvU8izMBw809GC03rpg uZ/K+r8FyG/vvj499BZ02qtLujguwuj7++E/hkyue4UjaAtwJzYPmu3H46fxR4Gx hyh3xPST7HorkcNQt+/qjpLH4my/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=sYcgeRrrQbMr6gfPdaGMI/EpAo2EH 78oL9Jf1d0d7+k=; b=E2+TRTsMwb5kvZUfMMcXLAapqI4jIK9HfzZJuwJPByUiL /miwoORz4RmEr/Sbprf3wMnrnppJ64Wd/sYZDK09fYKvzhVSs/qwWlLZJw/HTOe/ Z3aX8A/yI1GISLkNLppQDCUThgmlUj95o9WkpQVwiNyAT9mx7g15XIUpBWX/NzQs T7juJ95gPkAa4iZ+xpuyK3qhOX73Y9GBJAGayUk/2dUmeoqgYJe20x2ts37hRV41 UdC36QfXz0adEUkaywmugMbIxAaIidRnmB++BIQmawubBhaAot9Ye2n7WJTeTEE7 sEfp4c/01bwWtoZirNuMdOndJxJF0rKV2HeRSc1Vw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E56BE940DA; Thu, 19 Jul 2018 17:13:01 -0400 (EDT) Message-Id: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153203478117936670" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 Date: Fri, 20 Jul 2018 07:13:01 +1000 Archived-At: Subject: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:13:05 -0000 This is a multi-part message in MIME format. --_----------=_153203478117936670 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, As discussed in today's meeting, this is a formal call for adoption for: https://datatracker.ietf.org/doc/draft-slusarz-imap-fetch-snippet/ It was clear in the room that this isn't the final form of the document, so this is a call to adopt the document into the group for ongoing work. Please let the group know if you have any objection to taking on this document. I will give two weeks for this, so please file any objections by August 3rd. Kind regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153203478117936670 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

As discussed in today's meeting, this is a formal call for adoption for:


It was clear in the room that this isn't the final form of the document, so this is a call to adopt the document into the group for ongoing work.  Please let the group know if you have any objection to taking on this document.

I will give two weeks for this, so please file any objections by August 3rd.

Kind regards,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153203478117936670-- From nobody Thu Jul 19 14:27:23 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDD9130ECB for ; Thu, 19 Jul 2018 14:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=MtEhxFE1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n0rnB/iq 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 Ilwnl5WeJIzZ for ; Thu, 19 Jul 2018 14:27:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE87130EA5 for ; Thu, 19 Jul 2018 14:27:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C21CC21BBC for ; Thu, 19 Jul 2018 17:27:19 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 17:27:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=w6YuNdjQEf/jeeStsSFt+vLHzGkREXJgOSIwuwwY3 Us=; b=MtEhxFE19azOfimakCfxHfYJda3wvCgTR2E36BEDjT/UmNB4TBP39cI22 dOGxnLNGIbT5BcAEDDIXQng9YRNcfDnaJelRP3P5FzntdyLmzBoHX6dStJP7r8w5 MFrQS6dHUSi+RhOSIp/vUP9SpsW+bBJ46Tr3TsoHAoXyx16Vi/iEgZupwFu4hHnF oLxw0Z7rp+VZ6nYcyk5ChcLsOgaGuyPtqCRqx2hcPpTrgMKcaBR1sl2SZJZf1SUG 4fxNYs7meinKcYGrrNoEKUb3Eu0M72Sj7aVOxlCZjXARE1zpz5OHTkqI2fRy7Syh ohqFDw32FCDWrMt0V4nAvY8dtRnjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=w6YuNdjQEf/jeeStsSFt+vLHzGkRE XJgOSIwuwwY3Us=; b=n0rnB/iqBtXe717GbNNyvd+sgJDlfMwbQOV8Z+BwOa1A6 /MKbrDod30ZE0flgXwgYaw4cRPU+HN+FeKvzcp/v0W7mgb+ZJqItmiN5fU4IKJtD 9lWs+6vmRTF+GqJaIFYBrgSqYrqJzGOu/BEHDN1O68dVjf+GvDqw+bzf4Xy0gq60 HrRDEQlhdRvFSM30UwSHY5H7IGStfD5xNMhERbSy8kXLKE2iOoTWB98zq5RqiH+7 OjaB91TYuvSGs3jO2dl78FcigaAftz5MsCKl1f7Dt6CDDLPIukH70wc/W1HW7zWv VSNwpG2rYvw1LopKlY+C2R+IlPkIvISaLWQHt3Khg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 602FE940DA; Thu, 19 Jul 2018 17:27:19 -0400 (EDT) Message-Id: <1532035639.1797314.1446624328.7ED28DB9@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153203563917973142" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 Date: Fri, 20 Jul 2018 07:27:19 +1000 Archived-At: Subject: [Extra] Request for feedback - OBJECTID X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:27:22 -0000 This is a multi-part message in MIME format. --_----------=_153203563917973142 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, Thanks to Pete's very comprehensive GENART feedback, the OBJECTID spec has changed significantly this week. Basically all the SHOULDs have become MUST. This means that any server supporting OBJECTID will have to have persistent storage for both EMAILID and MAILBOXID which survives rename and copy/move. I'm quite happy with that - my server handles it fine, but if this would be a problem with your server, now is the time to speak up. If there are problems, we can consider multiple CAPABILITY strings, or something else - but if everyone is fine with everything being MUST, we can go ahead with something simple and much more robust/trustable for clients. I'll ask Alexey to hold off on progressing the spec any further until August 3rd (2 weeks) to allow time for feedback here. Thanks heaps! Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153203563917973142 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

Thanks to Pete's very comprehensive GENART feedback, the OBJECTID spec has changed significantly this week.  Basically all the SHOULDs have become MUST.

This means that any server supporting OBJECTID will have to have persistent storage for both EMAILID and MAILBOXID which survives rename and copy/move.

I'm quite happy with that - my server handles it fine, but if this would be a problem with your server, now is the time to speak up.  If there are problems, we can consider multiple CAPABILITY strings, or something else - but if everyone is fine with everything being MUST, we can go ahead with something simple and much more robust/trustable for clients.

I'll ask Alexey to hold off on progressing the spec any further until August 3rd (2 weeks) to allow time for feedback here.

Thanks heaps!

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153203563917973142-- From nobody Thu Jul 19 14:45:29 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4770130DEB for ; Thu, 19 Jul 2018 14:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=A3H+LBC5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=koUXvHv/ 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 GC2zWAVoeqhJ for ; Thu, 19 Jul 2018 14:45:19 -0700 (PDT) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DED12F18C for ; Thu, 19 Jul 2018 14:45:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id DA8E7105A for ; Thu, 19 Jul 2018 17:45:17 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 17:45:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=1bSm3AxLPVGMd0HK8 BGlVqJLWsVi4elW5SKgUlMshcU=; b=A3H+LBC5t8++O7C8nKD3d5qjY3wXMJ8Bl b5T9Y3am37crMl+O9svVO+PQVu962KEPNHLvz73xGlBHz/0pFEx0zYzAbjO6q9/B 9hN7c9tukW54ZNrxN3vXV3ku3CsWAvRXq0jgXfmf0nqDxI+RSuz3eCscik95sXDy qshvLHjPJToeHRDulgDH2DmNBEWrK/6wYGwzcY4mCL+lpr3LdyRHpRZo8aF5n4Hn LxkUAb3qgHTXgABYbjqeFBRIM1qAhaf9es31C0LU7A1y6mkvResmYsi9bw2yfTpk b63GbtZpK3pzX6ZgqWkUoqt+CDl1hUPjCYCLo8PBH/w4L0qj9ykrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=1bSm3A xLPVGMd0HK8BGlVqJLWsVi4elW5SKgUlMshcU=; b=koUXvHv/VS/fugTStAcTGV qbFa9mCPAB/86Slpm2k+JR3dnBRY7c6M6l2A5/y3GIHfrbb+WG4CndKOzjSyrx8K narNKrm1QZrqDrzi7uUDWlLhyKrVXgrhuBxBQY8nFPdu9LN55E3DPRUVatlzURIm 1UyjcIKQVs6wj3FoPzNHM9aOsqmqnomq3DHjGE1DqepgKCIG89Qnid3+kkRxq+/q VyiNRSJHSjC4Saejqrd528BD8qHXytuivT0C1NFrch9X2uIWPFrxKTH9HBawPjZU Ilp8QEE+x7uiX8WEN0F9oiT7tJbLvXeNNFUTjyJFBXEy9ua/lCT0x7JLZDIxRjFQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8EC5594133; Thu, 19 Jul 2018 17:45:17 -0400 (EDT) Message-Id: <1532036717.1802047.1446640400.770FA0FF@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153203671718020470" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> <01QV1PSEOL14000051@mauve.mrochek.com> <1532009687.619593.1446153224.1D941F59@webmail.messagingengine.com> <01QV1TYIJU38000051@mauve.mrochek.com> In-Reply-To: <01QV1TYIJU38000051@mauve.mrochek.com> Date: Fri, 20 Jul 2018 07:45:17 +1000 Archived-At: Subject: Re: [Extra] SPECIAL-USE MAY appear in LIST responses (was: Re: I-D Action: draft-ietf-extra-sieve-special-use-01.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:45:26 -0000 This is a multi-part message in MIME format. --_----------=_153203671718020470 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, Jul 20, 2018, at 02:00, Ned Freed wrote: >>> Yes, according to RFC 6154 section 2 special use attributes MAY >>> appear in> non-extended LIST responses. There's an example of >>> this in>>> section 5.1.> > >>> However, the fact that this is a MAY makes it effectively useless >>> since you> can't tell the difference between a case where there >>> are no>>> special use> attributes assigned and one where the server has simply >>> elected not>>> to include> these attributes in its responses. And it's expected >>> that the>>> overwhelming> majority of mailboxes won't have any special use >>> overwhelming> assigned.> >> MAY fricking shmay. > > :) > >> There are clients out there which flat out expect >> that you return the SPECIAL-USE for an unadorned LIST, and customers>> report your server as buggy if it doesn't do what their client >> expects.> > Well, if that's the case, we have a problem independent of this Sieve> extension. Do we need to at least file an errata on this? Errata submitted, suggesting s/MAY/SHOULD/ in section 2. >>> In fact I'd go so far to say that this is a design error. It's >>> one thing> to want to support existing implementations of >>> special use>>> attributes, it's> another to be so permissive that a compliant >>> implementation - one that> supports SPECIAL-USE but not LIST- >>> EXTENDED - can have no way to>>> determine> what the special use mailboxes are actually present. > >> I'm sure that RFC3501bis (IMAP4rev2) will fix this. > > Which creates a dependency on yet another IMAP extension. Not sure if> this is sufficient. IMAP4rev2 is already planning to remove all the non-extended responses to things. Adding special-use and requiring that it be present in all responses is totally reasonable within the scope of the other changes. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153203671718020470 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, Jul 20, 2018, at 02:00, Ned Freed wrote:
Yes, according to RFC 6154 section 2 special use attributes MAY
appear in> non-extended LIST responses. There's an example of this in
section 5.1.>

However, the fact that this is a MAY makes it effectively useless
since you> can't tell the difference between a case where there are no
special use> attributes assigned and one where the server has simply elected not
to include> these attributes in its responses. And it's expected that the
overwhelming> majority of mailboxes won't have any special use assigned.

MAY fricking shmay.

:)

There are clients out there which flat out expect
that you return the SPECIAL-USE for an unadorned LIST, and customers
report your server as buggy if it doesn't do what their client expects.

Well, if that's the case, we have a problem independent of this Sieve
extension. Do we need to at least file an errata on this?

Errata submitted, suggesting s/MAY/SHOULD/ in section 2.

In fact I'd go so far to say that this is a design error. It's
one thing> to want to support existing implementations of special use
attributes, it's> another to be so permissive that a compliant implementation - one that> supports SPECIAL-USE but not LIST-EXTENDED - can have no way to
determine> what the special use mailboxes are actually present.

I'm sure that RFC3501bis (IMAP4rev2) will fix this.

Which creates a dependency on yet another IMAP extension. Not sure if
this is sufficient.

IMAP4rev2 is already planning to remove all the non-extended responses to things.  Adding special-use and requiring that it be present in all responses is totally reasonable within the scope of the other changes.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153203671718020470-- From nobody Thu Jul 19 15:48:01 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5C130E59 for ; Thu, 19 Jul 2018 15:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 KEqVoBnkuhZ8 for ; Thu, 19 Jul 2018 15:47:56 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 9C0BF130DD2 for ; Thu, 19 Jul 2018 15:47:56 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6JMi8ar039349; Thu, 19 Jul 2018 22:47:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=/p4rZKF4TxpEx+ZTQyjUBM+48bnhiLw4Z60nQ1LEw0w=; b=eCzBFIylxvOtxUcUcTfJFHBsl++wThEEN5Kh+CQeRlJkuCpzF3n2TLoF//DOzZjNfnl7 iXLaqdCh56Ic2ba7LG8fgZmJH1gfqfhYUPeCWAN67M4UW0j3uXMKYB5k4+zUuNz26rIB FqzAh77LFyuJ4pIF3AqX0FKLcmBlv2gmFMXpZMvTgmITwQRfdbfjAxpMAxwQKla2DPSc rHyH0WaPamNi6Gth3ozLQbfmXjPVdKLnoVheIG9Ab+zBnFJH3iWanQfdB5yqydCa7CLd U6BXabwlPw1PiZIDTuE48hVZUQBdXJSiGYBPOURBZpPy1LxliNnGvRDgP9IR+Ltl5tAH Vw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2k9ykc94m2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Jul 2018 22:47:48 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6JMlmeO004981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Jul 2018 22:47:48 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6JMlhZ0009650; Thu, 19 Jul 2018 22:47:44 GMT Received: from [31.133.140.238] (/31.133.140.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jul 2018 15:47:43 -0700 From: "Chris Newman" To: "Ned Freed" Cc: "Stephan Bosch" , extra@ietf.org, "Bron Gondwana" Date: Thu, 19 Jul 2018 18:47:41 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: <01QV1PSEOL14000051@mauve.mrochek.com> References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> <01QV1PSEOL14000051@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8959 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190237 Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:48:00 -0000 On 19 Jul 2018, at 9:40, Ned Freed wrote: >> > In the next step: >> > >> > =C2=A0=C2=A0 Subsequently, when no particular mailbox is of interest= (i.e., = >> the >> > =C2=A0=C2=A0 "specialuse_exists" test has no mailbox argument), the = client = >> lists >> > =C2=A0=C2=A0 all mailboxes with special-use flags in the two returne= d = >> personal >> > =C2=A0=C2=A0 namespaces: >> > >> > =C2=A0=C2=A0 C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RE= TURN >> > (SPECIAL-USE) >> > =C2=A0=C2=A0 S: * LIST (\Drafts) "/" INBOX/Drafts >> > =C2=A0=C2=A0 S: * LIST (\Trash) "/" INBOX/Trash >> > =C2=A0=C2=A0 S: * LIST (\Sent) "/" INBOX/Sent >> > =C2=A0=C2=A0 S: * LIST (\Archive) "/" Archive/Default >> > >> > It should be noted that this depends on extended list being = >> available. > >> True. I thought LIST-EXTENDED is pretty much required for = >> SPECIAL-USE, >> but the specification doesn't actually mention anything like that. Is >> there another way to obtain information on which mailboxes have a >> particular special-use flag assigned? > > Yes, according to RFC 6154 section 2 special use attributes MAY appear = > in > non-extended LIST responses. There's an example of this in section = > 5.1. > > However, the fact that this is a MAY makes it effectively useless = > since you > can't tell the difference between a case where there are no special = > use > attributes assigned and one where the server has simply elected not to = > include > these attributes in its responses. And it's expected that the = > overwhelming > majority of mailboxes won't have any special use assigned. > > In fact I'd go so far to say that this is a design error. It's one = > thing > to want to support existing implementations of special use attributes, = > it's > another to be so permissive that a compliant implementation - one that > supports SPECIAL-USE but not LIST-EXTENDED - can have no way to = > determine > what the special use mailboxes are actually present. I believe that's an incorrect interpretation of the spec. RFC 6154 = states: ... If the client specifies the "SPECIAL-USE" selection option, the LIST command MUST return only those mailboxes that have a special-use attribute set. If the client specifies the = "SPECIAL-USE" return option, the LIST command MUST return the new special-use attributes on those mailboxes that have them set. ... This spec applies to all servers that advertise SPECIAL-USE. Those two = MUST clauses do not have an exception for servers that do not advertise = LIST-EXTENDED. The example in section 5.2 supports this interpretation, = since it does not include LIST-EXTENDED in the capabilities response. Contrast that with section 4: If a server supports this extension and the METADATA extension [RFC5464], it SHOULD tie the special-use attributes for a mailbox to its metadata entry "/private/specialuse". where there's an explicit exception to the SHOULD for servers that do = not implement METADATA due to the "if" clause. If I recall correctly, the difference in normative language between = these two sections was deliberate. - Chris > All that said, all I was asking for here was a note saying this = > depended on > LIST-EXTENDED. Nothing more. (Personally, I don't intend to even = > bother to > check if it's supported.) > >> > However, I think use of SELECT for this purpose is problematic: = >> It's >> > potentially expensive and worse, may cause undesireable state = >> changes. >> > Why >> > not use the MYRIGHTS command to obtain the access rights (and check >> > for "p" or >> > "i") without having to select the mailbox? > >> Sure, if the ACL capability is available. I can mention that. If it = >> is >> not available, there is really no alternative to using SELECT, right? > > Not as far as I know. But again, the problem is that SELECTing a = > mailbox > on behalf of a user can change its state, with all that implies. I'd = > rather > have my implementation fail if ACL isn't present than have a sieve = > operation > cause a state change. >> > All of which is roundabout way of saying I now think that we may = >> want a >> > capability for specialuse_exists that's separate from >> > "special-use"/:specialuse. Or better still, since we already have = >> the >> > "mailbox" >> > capability for "mailbox access stuff", I think we should require = >> the >> > presence >> > of both "mailbox" and "special-use" capabilities in order to use >> > specialuse_exists. > >> Can you clarify this point? I don't see how this leads to requiring = >> the >> mailbox extension. > > It doesn't unless we want it to, and I think we want it to. We have = > this > collection of stuff collected under the mailbox extension that lets = > sieve peek > at the state of the mailbox. And here we have an extension that = > consists of two > parts: One extending fileinto and the other adding to things you can = > peek at. > >> From an MTA implementation perspective, these are very distinct = >> things, and > the latter shares a ton of code with the mailbox extension. It = > therefore > makes sense to me to separate the two and link it to the mailbox = > extension. > > It's really no different than the way SPECIAL-USE and LIST-EXTENDED > interact on the IMAP side of things: Both have to be present for the > RETURN (SPECIAL-USE) stuff to work. > > Ned > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DfqjptcmWVzu3wax= uhECJKbXvzfSuBPDLN9t7KQMtjW8&s=3DG51gQpE9MxifdONliqnLO9agM4akhpX0R2j_SbJQ= vi8&e=3D From nobody Thu Jul 19 16:14:42 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14257130E03 for ; Thu, 19 Jul 2018 16:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 0eFCCX0mgoSH for ; Thu, 19 Jul 2018 16:14:38 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 44999130E62 for ; Thu, 19 Jul 2018 16:14:37 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6JNDn73082766; Thu, 19 Jul 2018 23:14:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=IvgJd7mxDRt6NqfO9TaSoS05S4SV+4ZrYO5ovpRXTrI=; b=QrJUpc/f8qocKnNeOw/+lVOf9aOJG9Ko9b3+0PY/9LdgA0xxZTEaT5WcEtwXlAk/i5Tv Sq+Yc2Ptx119RvWKDMxc4CTaCXipyfPO25DEXaJqy6fMSgSiEdFHmb3S/KIQfY8RwoE6 mBqio+fxPsjChIUQTSXbBn5YUBKSXS055lXUYoJkyXLxDInpWINEZqTkjaETWD/EJeRF 5gd8ID3nUSYPIzx/w1SCD5+dFejhi4lEGtdBsVipa/vmt+oNG0RRh3g3z4zLvw4LoEpL tsuxW2/8cJ6i+71sOVdWMZmN1gVo2TrwsE68kYwsMNi9UYxmlI5BX58GNWdPOmzOoN7Z mA== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2k7a3tckv3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Jul 2018 23:14:33 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6JNEXZr002674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Jul 2018 23:14:33 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6JNEWx0017257; Thu, 19 Jul 2018 23:14:33 GMT Received: from [31.133.140.238] (/31.133.140.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jul 2018 16:14:32 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org Date: Thu, 19 Jul 2018 19:14:30 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> In-Reply-To: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8959 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=932 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190242 Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:14:41 -0000 I've reviewed this document. We have implemented the FUZZY algorithm in both a client and server (under an XSNIPPET capability). I support adoption of this document by the WG. We have not implemented the LAZY= modifier. I reviewed our code and believe the LAZY= modifier has a logical server-side implementation that is reasonable. At this time, I do not see a use case for the LAZY= modifier in our client. Has there been client implementer interest in the LAZY= modifier? I don't personally object to the LAZY= modifier, but the bar for acceptance of a feature in a specification should preferably an implementation or active implementer interest. - Chris On 19 Jul 2018, at 17:13, Bron Gondwana wrote: > Hi All, > > As discussed in today's meeting, this is a formal call for adoption > for: > https://datatracker.ietf.org/doc/draft-slusarz-imap-fetch-snippet/ > > It was clear in the room that this isn't the final form of the > document, so this is a call to adopt the document into the group for > ongoing work. Please let the group know if you have any objection to > taking on this document. > I will give two weeks for this, so please file any objections by > August 3rd. > Kind regards, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com From nobody Thu Jul 19 16:15:38 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49501130E60 for ; Thu, 19 Jul 2018 16:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 7aNonDut5I7V for ; Thu, 19 Jul 2018 16:15:34 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 DAF03130E34 for ; Thu, 19 Jul 2018 16:15:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV28UU05CW007H01@mauve.mrochek.com> for extra@ietf.org; Thu, 19 Jul 2018 16:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532041828; bh=+lA7Xhh+qvuaIggSg7+R3hpLVSayP3YJPslwVzOjRV8=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=U9XpzJXRdDWEcepAiOPc7paiPW+06xB9WPXjsdWDieglWABrjvNnUTJU5oATfUjV3 zMBp9WY4l6MDa4GcXWLcLgQnDkcUjO+uzZ4X26QdnUsFMgEyEMMQKDmnsGukXLXBoY UDZ5y/2Jkx9PZocSY5vuCdtUX3UoXU7vGGMpxJUU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUCIBNY1B4000051@mauve.mrochek.com>; Thu, 19 Jul 2018 16:10:25 -0700 (PDT) Cc: Ned Freed , Stephan Bosch , extra@ietf.org, Bron Gondwana Message-id: <01QV28UQXAS4000051@mauve.mrochek.com> Date: Thu, 19 Jul 2018 15:55:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Jul 2018 18:47:41 -0400" References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> <01QV1PSEOL14000051@mauve.mrochek.com> To: Chris Newman Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:15:37 -0000 > I believe that's an incorrect interpretation of the spec. RFC 6154 > states: > ... If the client specifies the "SPECIAL-USE" selection option, > the LIST command MUST return only those mailboxes that have a > special-use attribute set. If the client specifies the > "SPECIAL-USE" > return option, the LIST command MUST return the new special-use > attributes on those mailboxes that have them set. ... See the beginning of the paragraph you neglected to quote. It's quite clear that this is in the context of LIST-EXTENDED, not unextended LIST. This is reiterated in the ABNF. > This spec applies to all servers that advertise SPECIAL-USE. Those two > MUST clauses do not have an exception for servers that do not advertise > LIST-EXTENDED. The example in section 5.2 supports this interpretation, > since it does not include LIST-EXTENDED in the capabilities response. So what you're saying is that despite the fact that the section in question is specifically about using extended list - unextended list is covered in section 5.1 - the lack of the list-extended list in the example capabilities is sufficient reason to believe that the presence of the special-use cability magically enables the RETURN clause component of the special use extension and nothing else? If this is indeed how this is supposed to be interpreted it needs to be clarified with an errata, because your reading is frankly pretty tortuous. Ned From nobody Thu Jul 19 16:26:52 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A402D130E34 for ; Thu, 19 Jul 2018 16:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 uIeiKhtsEeTJ for ; Thu, 19 Jul 2018 16:26:48 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 7FCDD130DD2 for ; Thu, 19 Jul 2018 16:26:48 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6JNNVFb060054; Thu, 19 Jul 2018 23:26:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=WZzVnVkAqrI8GyNAacFNTqIGL0GmlwyXV7HXjR7wGmk=; b=YnEFPU52sWUvrvKGMMefzn+DW32rsaiH62S0oQyoznDwqb1CEeckWVWGMUMzY09Yx7zM 2hE3uZ5xqv6S3QVv4lalw5Fzm5ude57XsTa4JCMGBTStd88YZJFx8vmwwn9BPCMSnJ+q M7Q0Xm8PdOOvPkcfcbNa/A4GA0YEbPKHQSTeQj4S0+Uf5h3grSfNdGFd58Cjs/QKtiQy UZpk/P03/zR+GnTOPybcvG4dV/X/dPhRVe/xeg2l/DmlBrkebV2YsLjo5n6pglfhUPUa QYGq7KDGc2v2wyrB8aia1l3nm0azoEF8tBaKYCx3LC1jHtfjJt+mq6Y5mx4Lw38nn2ku tg== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2k9yjx96bd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Jul 2018 23:26:41 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6JNQe2b003015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Jul 2018 23:26:41 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6JNQesB013083; Thu, 19 Jul 2018 23:26:40 GMT Received: from [31.133.140.238] (/31.133.140.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jul 2018 16:26:40 -0700 From: "Chris Newman" To: "Ned Freed" Cc: extra@ietf.org, "Bron Gondwana" , "Stephan Bosch" Date: Thu, 19 Jul 2018 19:26:39 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <34620C41-2199-4F95-A286-17C81CF2744D@oracle.com> In-Reply-To: <01QV28UQXAS4000051@mauve.mrochek.com> References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> <01QTO3THVZ5I00AI1F@mauve.mrochek.com> <53350c64-d021-7f17-86b8-f1b118791cf5@dovecot.fi> <01QV1PSEOL14000051@mauve.mrochek.com> <01QV28UQXAS4000051@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8959 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190244 Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:26:51 -0000 On 19 Jul 2018, at 18:55, Ned Freed wrote: >> I believe that's an incorrect interpretation of the spec. RFC 6154 >> states: > >> ... If the client specifies the "SPECIAL-USE" selection option, >> the LIST command MUST return only those mailboxes that have a >> special-use attribute set. If the client specifies the >> "SPECIAL-USE" >> return option, the LIST command MUST return the new special-use >> attributes on those mailboxes that have them set. ... > > See the beginning of the paragraph you neglected to quote. It's quite > clear > that this is in the context of LIST-EXTENDED, not unextended LIST. > This is > reiterated in the ABNF. > >> This spec applies to all servers that advertise SPECIAL-USE. Those >> two >> MUST clauses do not have an exception for servers that do not >> advertise >> LIST-EXTENDED. The example in section 5.2 supports this >> interpretation, >> since it does not include LIST-EXTENDED in the capabilities response. > > So what you're saying is that despite the fact that the section in > question is > specifically about using extended list - unextended list is covered in > section > 5.1 - the lack of the list-extended list in the example capabilities > is > sufficient reason to believe that the presence of the special-use > cability > magically enables the RETURN clause component of the special use > extension and > nothing else? My reading matches our implementation. It would not surprise me if it matches most (perhaps all) implementations. Our implementation implements LIST-EXTENDED except for the multiple-list-pattern feature. As a result, we can not advertise the LIST-EXTENDED extension. Implementing the multiple-list-pattern feature would require at least two solid weeks of development effort for our implementation; I have no plans to do that work. We interpret and implement the STATUS-in-LIST extension the same way (RFC 5819). That one is a bit more straightforward since advertising that capability would be meaningless by itself absent this interpretation. > If this is indeed how this is supposed to be interpreted it needs to > be > clarified with an errata, because your reading is frankly pretty > tortuous. Since the specification does not match reality around the MAY/SHOULD issue, it needs a revision. Errata is not a good way to handle something like this. - Chris From nobody Thu Jul 19 20:55:58 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8B4130E78 for ; Thu, 19 Jul 2018 20:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jNzkpllg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vtSM07eY 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 hcYbuUeM_UqA for ; Thu, 19 Jul 2018 20:55:53 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A515D1277D2 for ; Thu, 19 Jul 2018 20:55:53 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C967521B7F for ; Thu, 19 Jul 2018 23:55:52 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 23:55:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=9YbEx5WIvTO+ZfMeD/ms3u/w7Fy/Aw1oTEglj5pft GA=; b=jNzkpllg4crXtyBUV/ui7HbWlSCJK5BDuRQNcj8/38Htmi3YTz9KXeFdg if3ew/NKhZrZxGoyijY5VZMWP1va0Oi+F8tx3CBd3T0U7IJ1BVevLhuOTMT3CFi4 UdTmYiNVO9hlosDppikVWi0SIHysmxYvYI95C+/3GckMuzXPCnvKBhTfBhXbZyn1 yqX3Oxf0i87MRULirtYFw/K53VHQGYnxqpnhg4L+gTTUeDPV2ijq/gmly7HIwIwi RsJLW0pKIAtX7ztXmLyEJQsLHn8iFTMMfAhdUrsyc4ovyymZUruwR+SxMJ/o0LsU VtTcStPi8tAWSfo/iBAESzdjagjVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=9YbEx5WIvTO+ZfMeD/ms3u/w7Fy/A w1oTEglj5pftGA=; b=vtSM07eYQ8UFXilOTP4dOveEgYnvdyTMw6IgkGtrf0jah 7O/LWFDSeAOt4Yy9fQqZ+/+Kn5RmYssHDr3WYxdEcDn0DVFL3Hu6LzAMMIIqOSqY vXVPeI+/5zadfTRF2YcCagJ/a74dQOHHWE9HEJ1he4fH/+B9D4C6F++DKvQFhegF rW2b2cyg4ZLuaRBZMkXxhWp49YPfwTeQ33PSgSqzBUMxJzM+W9cfT90jGf+vpybN FccaDynf+P0lMoYmUcity/julxd3YXtSbKhmBgPI6V933KExh6vC0xbjE3lstUis zKa1NmcWlT9PXrIzor2HJwazoKhF5ru1kdHrzGLEQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7026B940DA; Thu, 19 Jul 2018 23:55:52 -0400 (EDT) Message-Id: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153205895218860160" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Fri, 20 Jul 2018 13:55:52 +1000 Archived-At: Subject: [Extra] client-id next steps - let's find them a home X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 03:55:57 -0000 This is a multi-part message in MIME format. --_----------=_153205895218860160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" We discussed draft-yu-imap-client-id in today's meeting, and while we came to the conclusion that it wasn't a document for the working group to adopt, the problem it's trying to solve is something which the IETF could help with. Ned's comment in jabber that didn't make it into the discussion was something like, it's a cookie, just one the client creates. That's pretty much it. It's basically there are an input to the calculation that every server has to make on every connection "how much do I believe that this login is from who it says it's from", or at a more meta level "how trustworthy is this connection and much do I want to obey its requests". At the most trivial level, that's what authentication is - the username and password (or whatever) gives the server sufficient trust in the other end of the connection that it allows access to (and maybe modification of a subset of resources, correlated by the username used). A general cookie-like "this is a device I have communicated with before" as an additional input to the server's decision making would be welcomed by services who see stolen passwords as a common fraud problem, so there would definitely be appetite for this kind of work. The open question really is "is this work better suited to a different group and potentially a different area", and if so "can we help the authors find that area". Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153205895218860160 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
We discussed draft-yu-imap-client-id in today's meeting, and while we came to the conclusion that it wasn't a document for the working group to adopt, the problem it's trying to solve is something which the IETF could help with.

Ned's comment in jabber that didn't make it into the discussion was something like, it's a cookie, just one the client creates.  That's pretty much it.  It's basically there are an input to the calculation that every server has to make on every connection "how much do I believe that this login is from who it says it's from", or at a more meta level "how trustworthy is this connection and much do I want to obey its requests".

At the most trivial level, that's what authentication is - the username and password (or whatever) gives the server sufficient trust in the other end of the connection that it allows access to (and maybe modification of a subset of resources, correlated by the username used).

A general cookie-like "this is a device I have communicated with before" as an additional input to the server's decision making would be welcomed by services who see stolen passwords as a common fraud problem, so there would definitely be appetite for this kind of work.

The open question really is "is this work better suited to a different group and potentially a different area", and if so "can we help the authors find that area".

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153205895218860160-- From nobody Fri Jul 20 07:01:57 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860C5131183 for ; Fri, 20 Jul 2018 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 dBV6LFYL6567 for ; Fri, 20 Jul 2018 07:01:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 7301B131168 for ; Fri, 20 Jul 2018 07:01:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV33SNDPN40116TK@mauve.mrochek.com> for extra@ietf.org; Fri, 20 Jul 2018 06:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532095003; bh=YzSxXXmFHRdij5Gugxm28TSNTP28ZXgtNWale1PRIvw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=j+Nk20YqIJDdSdNofMUNK5xmXEGIvK7Mtnsb41fORoBG8F0szOsh2HGehlzyzD4fI Dr1FlP0VO9o4Q8DTtDb7IsOq3eDsesysAL3v6+cblwBHNEA/Kg4xFTac/Zdsm6mBqX SFRIyv/BVllH2wArhm9Dto5dxX96MD+XNWFVfUV0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUCIBNY1B4000051@mauve.mrochek.com>; Fri, 20 Jul 2018 06:56:41 -0700 (PDT) Cc: extra@ietf.org Message-id: <01QV33SLJJQA000051@mauve.mrochek.com> Date: Fri, 20 Jul 2018 06:28:54 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 20 Jul 2018 13:55:52 +1000" <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Subject: Re: [Extra] client-id next steps - let's find them a home X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:01:55 -0000 > We discussed draft-yu-imap-client-id in today's meeting, and while we > came to the conclusion that it wasn't a document for the working group > to adopt, the problem it's trying to solve is something which the IETF > could help with. > Ned's comment in jabber that didn't make it into the discussion was > something like, it's a cookie, just one the client creates. Or alternately, one the client is given. > That's > pretty much it. It's basically there are an input to the calculation > that every server has to make on every connection "how much do I believe > that this login is from who it says it's from", or at a more meta level > "how trustworthy is this connection and much do I want to obey its > requests". Right. But given these semantics, one of the things the security folks are bound to ask is, "Why aren't you using client certificates for this?" More specificially, a client certificate could be included in the TLS exchange and then used for this purpose. It could be self-generated and self-signed, it could be acquired through the use of ACME or some other protocol - lots of possibilities there, including the abiity to revoke it. Of course this would mandate the use of TLS, but I doubt any proposal for something like this would pass security review without mandatory protection of the clientid. (I'm going to use the term clientid instead of cid because, as Barry noted, cid already has a common menaing in the email world, and this isn't it.) I will also note that nothing prevents the clientid exchange from occurring in SASL without restricting the subsequent SASL exchange in any way. The simplest way to do it woud be to have it be a sort of prefix to the actual SASL method: Define a CLIENTID method where the client starts the exchange by sending the . If the server like the clientid it would respond with a list of SASL mechanisms that are now allowed, the client would pick one and proceed to use it just as if it was starting the SASL exchange at that point. More sophisticated approaches are possible that don't increase the number of round trips in most cases. For example, the client could include a prospective subsequent SASL method and any initial parameter along with the clientid. The server would then either proceed with the subsequent SASL method, reject the subsequent SASL method and propose a alternative, or reject the exchange outright. It's also possible to include facilities to obtain the initial from the server, update the , and so on. The advantage of doing it this way is that the security stuff stays at the security layer and you don't have to add an extension and a new command to every protocol where you need this. And like it or not, the number of email protocols where you're going to need this is not going to be less than two: It's just not acceptable to extend IMAP in this way but not SUBMIT. The impact on JMAP also needs to be considered. > At the most trivial level, that's what authentication is - the username > and password (or whatever) gives the server sufficient trust in the > other end of the connection that it allows access to (and maybe > modification of a subset of resources, correlated by the username used). > A general cookie-like "this is a device I have communicated with before" > as an additional input to the server's decision making would be welcomed > by services who see stolen passwords as a common fraud problem, so there > would definitely be appetite for this kind of work. Agreed. That said, the potential for use and abuse beyond this scenario is very real - we have way too many fully worked examples in the web world where attempts to do clever stuff based on the supposed client type have led to all kinds of breakage. (I trust I don't need to provide any examples here.) This is actually another reason why pushing this down into security layer is a good idea: It makes it clear what it's supposed to be used for, > The open question really is "is this work better suited to a different > group and potentially a different area", and if so "can we help the > authors find that area". This is a security protocol. That doesn't mean it needs to be done in the security area, but it will reqiure substantive input from there. Ned From nobody Fri Jul 20 07:06:42 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FA3130DD8 for ; Fri, 20 Jul 2018 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 fdiQ-P-wW-cx for ; Fri, 20 Jul 2018 07:06:38 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 8D434129619 for ; Fri, 20 Jul 2018 07:06:38 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6KE4kcu079205; Fri, 20 Jul 2018 14:06:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=hWjsn8WmhHCigkVCSq8LJf+OTFp6mUCm0GDCGB7/XXY=; b=qkvHnKPSEpcq3FJJjvzhN6Gh9wk0hNw9B/CfoRMMJay+L1NNDHeTxvuCG8ivaNfQBND9 ZXfrgZpSMfZ3AJG6LsKFU8xpmN8b3I4vOEAZheuMTxQzge4ZO2BTNw4vs16wcBl1HMcH XzdEePtnsNrkwH6ePtS1NasDKlo4pj9byoV4Cpnx/c/iyZcXYQiBDB0BgINQw4pz+SLA ld+SEbeo5Y3n75NfMM6cvMRJ6iGb7XpJVPF248W4vNMAFKTP2HeNHEbeCvqWaOMWRBKQ oqdhtPmFSVNYu3OqOBGUJvAPD47FqYyHVkqR2+CqLuXI5jteDnHTNJtZD6OfwSAauhbW 4w== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2k9ykcbf74-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jul 2018 14:06:34 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6KE6XF9010694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jul 2018 14:06:33 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6KE6XYe028769; Fri, 20 Jul 2018 14:06:33 GMT Received: from [31.133.140.238] (/31.133.140.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Jul 2018 07:06:33 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org Date: Fri, 20 Jul 2018 10:06:31 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <924CDC5C-31FA-401D-92A3-1CA1B25A4838@oracle.com> In-Reply-To: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8959 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807200160 Archived-At: Subject: Re: [Extra] client-id next steps - let's find them a home X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:06:40 -0000 On 19 Jul 2018, at 23:55, Bron Gondwana wrote: > We discussed draft-yu-imap-client-id in today's meeting, and while we > came to the conclusion that it wasn't a document for the working group > to adopt, the problem it's trying to solve is something which the IETF > could help with. In my experience, the IETF is bad at solving generalized problems directly, but is better if it looks at a specific application of a potentially general problem and worries about generalizing it later. We have a specific email (IMAP/SMTP/etc.) use case that has market demand for a potentially generalizable problem. I think this WG is a good home for discussion of this work until such time as we've specifically determined there is another WG that wants to adopt this and is more appropriate. We do not have to adopt a document in order for technical discussion to be useful and make forward progress. I suggest as a WG we dig deeper into three issues with the proposal: * What are the technical/deployment pros & cons of a separate command model verses a SASL-integrated model? I'm considering authoring a counter-proposal SASL-based document so we can contrast two specific proposals. I'm _very_ interested in specifics of the claimed differences in ease of deployment -- that's an important topic for a standards community to understand. * Can/should we specify more semantics about what the client-id (or particular flavors of client-id) look like so interoperability between servers & clients from different vendors is more feasible based on a specification? * Can we get more precise about the privacy implications and are there mitigations for those implications (this may tie into the previous question)? I think a solution to the underlying problem is likely to deploy one way or another. We saw what happened with DMARC when the IETF was excluded and issues with interoperability were ignored. My opinion is we should try to help develop a better proposal and not pass the buck. If we decide a SASL-integrated model has rough-consensus after considering technical/deployment pros & cons, then we need to work with the Kitten WG to agree on which of the two WGs will carry this forward. If people feel there's a need to have a WG document in order to do work, then I would support adoption by this WG of a requirements & problem-analysis document for email client-id. I personally think a less formal discussion on this list would be a more efficient use of our time. - Chris > Ned's comment in jabber that didn't make it into the discussion was > something like, it's a cookie, just one the client creates. That's > pretty much it. It's basically there are an input to the calculation > that every server has to make on every connection "how much do I > believe > that this login is from who it says it's from", or at a more meta > level > "how trustworthy is this connection and much do I want to obey its > requests". > At the most trivial level, that's what authentication is - the > username > and password (or whatever) gives the server sufficient trust in the > other end of the connection that it allows access to (and maybe > modification of a subset of resources, correlated by the username > used). > A general cookie-like "this is a device I have communicated with > before" > as an additional input to the server's decision making would be > welcomed > by services who see stolen passwords as a common fraud problem, so > there > would definitely be appetite for this kind of work. > The open question really is "is this work better suited to a different > group and potentially a different area", and if so "can we help the > authors find that area". > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com From nobody Fri Jul 20 11:01:39 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA854131246 for ; Fri, 20 Jul 2018 11:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com 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 Qs2V98UOs1vI for ; Fri, 20 Jul 2018 11:01:28 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C14D131211 for ; Fri, 20 Jul 2018 11:01:28 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 112916A273; Fri, 20 Jul 2018 20:01:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1532109686; bh=ZZGbbT5oOThbNpFc7jpmgZm+HSQZll3RrWFaJ/S1g0Y=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=1XRs3Yn0IYFcfKeN4lnQTh9QWia96rXyB0W2FEIfoQForyDxFxj0lD7zBogq4FX7i hw3mLwvvwoV+rcHYC5mKIMUdVSm1TKZnCYvq6d2dB1BLowTQt2AEHXksUrPhi/swf/ a4SbjrfQ7tATA+tcXJS0UQ1ovPsXNJl39tpjoGrZ5V++rWIpoMM5tghVnefO3oG5Yh eWrqkegzTokovQSuBe3eixUASQHed49Anr6aTgyP2CDLOx/66eN1WjVYYlrp91qJXC zq3H2WVYdGnX24wlPYLt3UcCUoUdVofk+Zr7Ydy3h2fPgityaEZl4xDc1eFkpwQg+5 wPJB6NtutblpQ== Received: from null (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id D306F3C0481; Fri, 20 Jul 2018 20:01:25 +0200 (CEST) Date: Fri, 20 Jul 2018 12:01:25 -0600 (MDT) From: Michael Slusarz To: Chris Newman , Bron Gondwana Cc: extra@ietf.org Message-ID: <851290660.3102.1532109685791@appsuite.open-xchange.com> In-Reply-To: <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:01:38 -0000 Chris, Thanks for the input. Great news to hear about the implementation. See below. > On July 19, 2018 at 5:14 PM Chris Newman wrote: > > > I've reviewed this document. We have implemented the FUZZY algorithm in > both a client and server (under an XSNIPPET capability). I support > adoption of this document by the WG. > > We have not implemented the LAZY= modifier. I reviewed our code and > believe the LAZY= modifier has a logical server-side implementation that > is reasonable. At this time, I do not see a use case for the LAZY= > modifier in our client. Has there been client implementer interest in > the LAZY= modifier? I don't personally object to the LAZY= modifier, but > the bar for acceptance of a feature in a specification should preferably > an implementation or active implementer interest. The LAZY modifier was the final element added to the Snippet draft, and it was added specifically due to feedback from our internal *client* development team when implementing the base FETCH SNIPPET part. The client in this case is a (heavily-modified) JavaMail library running in our middleware serving our webmail and mobile UIs. The ask from the client team was for LAZY modifier, since without it the mailbox listing was blocked from an end-user UX perspective. I don't know if this blocking behavior could be worked around by altering the code/IMAP commands sent -- I have a feeling with JavaMail that this is not the easiest ask -- but the LAZY modifier was a solution that worked for them and was easily implementable in both client and server side code. Obviously, it is up for discussion whether LAZY is generally useful to the community and/or the semantics of its optimal behavior, but it was added for a specific need and has been implemented in publicly released code. So this is not the case of a speculative API addition to solve a problem that might potentially occur, if that is the concern. michael p.s. Someone brought up the idea of LAZY FETCH results being sent as untagged FETCH responses at some point after the FETCH command was completed. I dropped off the call at that point so didn't hear the reactions to that suggestion, but I disagree with that behavior because 1) it behaves differently than any other explicit FETCH request, where the data is immediately returned before the command is complete, and 2) this behavior is not desirable in a more disconnected mode of access that our client is implementing. From nobody Fri Jul 20 11:46:26 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A170B130DF1 for ; Fri, 20 Jul 2018 11:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Pmh0qHRW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SupJcgJn 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 RQC6HKSCLBnO for ; Fri, 20 Jul 2018 11:46:21 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B26B130DCE for ; Fri, 20 Jul 2018 11:46:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A205521ADD for ; Fri, 20 Jul 2018 14:46:20 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Fri, 20 Jul 2018 14:46:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=pM31tuyMqO40HxVaL sEts4FjIIVnAoCxFzJFOBeYHMU=; b=Pmh0qHRWPTwYypbIA9dCNh4U3l3ujbCFM aBH0UCXTWMZNJDYmwW2mv6OzVwaM2YNQ9dGGTN5tcMCv1bDxRpGFx0q6Yjow/pIH hoVzSVY1gxCbrYJSxzZW/N3BVPXNGrAhPWKJtdajpnNLZu+F/j8dN2Y1pMDZ4wlg JzQlPMLmI0DXrmB+R24zN7NJR9ShkBFM6eaoF2g8EIgqRlTZ5u6yMsvGdrWQUfWf MNBicIMU7o1BWJBlTIa8rLIVqmJh90pdk2HsM0sdT9/CWGrjJOxnqzGWRTokvkAY udBz6aGzG2g8BiSXwqjBn1pq6QUg9pgpAzy9wES8+2nPKX1zY9dTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=pM31tu yMqO40HxVaLsEts4FjIIVnAoCxFzJFOBeYHMU=; b=SupJcgJnXaXKb9BlM8QS31 6UQSfK/Lk7VaPV057VVRXo2aFBqu6ucNGiOZEQRENIqSpXCPBv53s8WFvcsBiOYr GNcyZy4LfrJ6GjK7SFV8G3qEfv4D8K89QMZSIKSEjB8SJOXQtwCCyijAq9jkYvEY TbTPQI0kzKaFDfYP2b6/iOWqAtvixY8PX1RQf8bBL4FyZN3XSlMvLCCChyJkW6Nz ikMsNd3VXmVbGECTk0Y+VmsG4PRP/HCwdhCO1nP19KqhxGF0id5dUTq5HhZGuxMX VHgldlM+qVshKbdClY4tysyI9Xsph0Fd8mlcOtrc5MZB9rSG/Vo1gtuvRZXkVe4w == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3A25B94250; Fri, 20 Jul 2018 14:46:20 -0400 (EDT) Message-Id: <1532112380.4163630.1447645088.2ED758B0@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153211238041636304" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Sat, 21 Jul 2018 04:46:20 +1000 References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> <851290660.3102.1532109685791@appsuite.open-xchange.com> In-Reply-To: <851290660.3102.1532109685791@appsuite.open-xchange.com> Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:46:25 -0000 This is a multi-part message in MIME format. --_----------=_153211238041636304 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, Jul 21, 2018, at 04:01, Michael Slusarz wrote: > The LAZY modifier was the final element added to the Snippet draft, > and it was added specifically due to feedback from our internal > **client** development team when implementing the base FETCH > SNIPPET part.> > The client in this case is a (heavily-modified) JavaMail library > running in our middleware serving our webmail and mobile UIs. The ask > from the client team was for LAZY modifier, since without it the > mailbox listing was blocked from an end-user UX perspective.> > I don't know if this blocking behavior could be worked around by > altering the code/IMAP commands sent -- I have a feeling with JavaMail > that this is not the easiest ask -- but the LAZY modifier was a > solution that worked for them and was easily implementable in both > client and server side code.> > Obviously, it is up for discussion whether LAZY is generally useful to > the community and/or the semantics of its optimal behavior, but it was > added for a specific need and has been implemented in publicly > released code. So this is not the case of a speculative API addition > to solve a problem that might potentially occur, if that is the > concern. Because we always generate snippets (we call them preview) on delivery in our server, we probably wouldn't need LAZY, but we could also trivially implement it. It seems a reasonable thing to add "I'd like snippets, but only if it's not too much work". > michael > > p.s. Someone brought up the idea of LAZY FETCH results being sent as > untagged FETCH responses at some point after the FETCH command > was completed. I dropped off the call at that point so didn't > hear the reactions to that suggestion, but I disagree with that > behavior because 1) it behaves differently than any other > explicit FETCH request, where the data is immediately returned > before the command is complete, and 2) this behavior is not > desirable in a more disconnected mode of access that our client > is implementing. Yeah, the room came to the same conclusion "cute idea, but unlikely to be useful in the real world". Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153211238041636304 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, Jul 21, 2018, at 04:01, Michael Slusarz wrote:
The LAZY modifier was the final element added to the Snippet draft, and it was added specifically due to feedback from our internal *client* development team when implementing the base FETCH SNIPPET part.

The client in this case is a (heavily-modified) JavaMail library running in our middleware serving our webmail and mobile UIs.  The ask from the client team was for LAZY modifier, since without it the mailbox listing was blocked from an end-user UX perspective. 

I don't know if this blocking behavior could be worked around by altering the code/IMAP commands sent -- I have a feeling with JavaMail that this is not the easiest ask -- but the LAZY modifier was a solution that worked for them and was easily implementable in both client and server side code.

Obviously, it is up for discussion whether LAZY is generally useful to the community and/or the semantics of its optimal behavior, but it was added for a specific need and has been implemented in publicly released code. So this is not the case of a speculative API addition to solve a problem that might potentially occur, if that is the concern.

Because we always generate snippets (we call them preview) on delivery in our server, we probably wouldn't need LAZY, but we could also trivially implement it.

It seems a reasonable thing to add "I'd like snippets, but only if it's not too much work".

michael

p.s. Someone brought up the idea of LAZY FETCH results being sent as untagged FETCH responses at some point after the FETCH command was completed.  I dropped off the call at that point so didn't hear the reactions to that suggestion, but I disagree with that behavior because 1) it behaves differently than any other explicit FETCH request, where the data is immediately returned before the command is complete, and 2) this behavior is not desirable in a more disconnected mode of access that our client is implementing.

Yeah, the room came to the same conclusion "cute idea, but unlikely to be useful in the real world".

Bron.
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153211238041636304-- From nobody Fri Jul 20 12:28:44 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1182130E5D for ; Fri, 20 Jul 2018 12:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 lQJO_nEd-wdb for ; Fri, 20 Jul 2018 12:28:40 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 6292E130DFC for ; Fri, 20 Jul 2018 12:28:40 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6KJSZZS151073; Fri, 20 Jul 2018 19:28:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=govNV8i/7g664G9tLbesI4ghU6q3kfRBIbH4i/1ysLU=; b=e0vlYcSibiq38WiYWZgDiVS+6kLEB3yVhaJlwjzCqgrmn6uV5bQ40nUs1zFYgGGfX8mH eB+w8I/azMoPRh/kOwSyi0pvJzTKzyS1kooEHFwE8NHFMvyYNyvtmq73fKfhQUor6Adt 78qTUpGjH8/Z/w7GFENqqPt5sP3iIx0vwrqottJAe1fAD6CfxeUOhWk05DBvNfmDSZus 27V3xDpInFr0H4ytObk9u3IkWxq2ypllinybony75GK/zQZCX6dt5pRDP2UptYXF48zL upFC0fiQkmOH0hKc0yHYzDWNXksA9ibRkKirBwLV+bETgjXfJ7TH3joD61oJ13s4GfVk OQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2k9yjgvfy5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jul 2018 19:28:36 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6KJSYil017110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jul 2018 19:28:35 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6KJSY7V011187; Fri, 20 Jul 2018 19:28:34 GMT Received: from [10.39.242.90] (/10.39.242.90) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Jul 2018 12:28:33 -0700 From: "Chris Newman" To: "Michael Slusarz" Cc: "Bron Gondwana" , extra@ietf.org Date: Fri, 20 Jul 2018 15:28:30 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: <851290660.3102.1532109685791@appsuite.open-xchange.com> References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> <851290660.3102.1532109685791@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8960 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807200215 Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 19:28:43 -0000 On 20 Jul 2018, at 14:01, Michael Slusarz wrote: > Chris, > > Thanks for the input. Great news to hear about the implementation. > > See below. > >> On July 19, 2018 at 5:14 PM Chris Newman >> wrote: >> >> >> I've reviewed this document. We have implemented the FUZZY algorithm >> in >> both a client and server (under an XSNIPPET capability). I support >> adoption of this document by the WG. >> >> We have not implemented the LAZY= modifier. I reviewed our code and >> believe the LAZY= modifier has a logical server-side implementation >> that >> is reasonable. At this time, I do not see a use case for the LAZY= >> modifier in our client. Has there been client implementer interest in >> the LAZY= modifier? I don't personally object to the LAZY= modifier, >> but >> the bar for acceptance of a feature in a specification should >> preferably >> an implementation or active implementer interest. > > The LAZY modifier was the final element added to the Snippet draft, > and it was added specifically due to feedback from our internal > *client* development team when implementing the base FETCH SNIPPET > part. > > The client in this case is a (heavily-modified) JavaMail library > running in our middleware serving our webmail and mobile UIs. The ask > from the client team was for LAZY modifier, since without it the > mailbox listing was blocked from an end-user UX perspective. > > I don't know if this blocking behavior could be worked around by > altering the code/IMAP commands sent -- I have a feeling with JavaMail > that this is not the easiest ask -- but the LAZY modifier was a > solution that worked for them and was easily implementable in both > client and server side code. Sounds good. Thanks for sharing the implementation experience! > Obviously, it is up for discussion whether LAZY is generally useful to > the community and/or the semantics of its optimal behavior, but it was > added for a specific need and has been implemented in publicly > released code. So this is not the case of a speculative API addition > to solve a problem that might potentially occur, if that is the > concern. Since I want SNIPPET standardized, I wanted to prompt for implementation experience that will remove barriers to standardization. I expected a response like this, but getting it on record now makes advancement easier. > p.s. Someone brought up the idea of LAZY FETCH results being sent as > untagged FETCH responses at some point after the FETCH command was > completed. I dropped off the call at that point so didn't hear the > reactions to that suggestion, but I disagree with that behavior > because 1) it behaves differently than any other explicit FETCH > request, where the data is immediately returned before the command is > complete, and 2) this behavior is not desirable in a more disconnected > mode of access that our client is implementing. I objected to the proposed untagged/deferred LAZY FETCH at the mike on the grounds that the server doesn't have enough information about what specific information the client wants to know. Unless we extended IMAP to with some sort of client state/interest mechanism, the server doesn't have enough information to share the right subset of data in the right order. - Chris From nobody Fri Jul 20 16:12:23 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48DE127148 for ; Fri, 20 Jul 2018 16:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 iZv1WNtK6U-L for ; Fri, 20 Jul 2018 16:12:18 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 659E6130E14 for ; Fri, 20 Jul 2018 16:12:18 -0700 (PDT) Received: from [192.168.8.102] (unknown [85.76.18.187]) by tss.iki.fi (Postfix) with ESMTPSA id DFDEA2B3CCA for ; Fri, 20 Jul 2018 23:12:16 +0000 (UTC) From: Timo Sirainen Content-Type: multipart/alternative; boundary="Apple-Mail=_453EB693-14E8-4461-A792-DA38D2108C93" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sat, 21 Jul 2018 02:13:10 +0300 References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> To: extra@ietf.org In-Reply-To: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> Message-Id: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Extra] client-id next steps - let's find them a home X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 23:12:22 -0000 --Apple-Mail=_453EB693-14E8-4461-A792-DA38D2108C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Well, originally I thought this wouldn't be the right place to discuss = it, but since people are talking about it, here's what I sent to Deion = Yu privately: I just read through this draft. I think it would be much simpler to = implement if it used the existing ID command instead. For example: a ID ("client-id-type" "uuid" "client-id-token" = "23bf83be-aad7-46aa-9e0f-39191ccf402f") Or alternatively: a ID ("client-id-uuid" "23bf83be-aad7-46aa-9e0f-39191ccf402f") It wouldn't require any new capabilities either. Client could simply = send this command if it sees ID capability advertised. The servers can = then either do something with it or ignore it. > On 20 Jul 2018, at 6.55, Bron Gondwana wrote: >=20 > We discussed draft-yu-imap-client-id in today's meeting, and while we = came to the conclusion that it wasn't a document for the working group = to adopt, the problem it's trying to solve is something which the IETF = could help with. >=20 > Ned's comment in jabber that didn't make it into the discussion was = something like, it's a cookie, just one the client creates. That's = pretty much it. It's basically there are an input to the calculation = that every server has to make on every connection "how much do I believe = that this login is from who it says it's from", or at a more meta level = "how trustworthy is this connection and much do I want to obey its = requests". >=20 > At the most trivial level, that's what authentication is - the = username and password (or whatever) gives the server sufficient trust in = the other end of the connection that it allows access to (and maybe = modification of a subset of resources, correlated by the username used). >=20 > A general cookie-like "this is a device I have communicated with = before" as an additional input to the server's decision making would be = welcomed by services who see stolen passwords as a common fraud problem, = so there would definitely be appetite for this kind of work. >=20 > The open question really is "is this work better suited to a different = group and potentially a different area", and if so "can we help the = authors find that area". >=20 > Bron. >=20 > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com >=20 >=20 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra = --Apple-Mail=_453EB693-14E8-4461-A792-DA38D2108C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Well,= originally I thought this wouldn't be the right place to discuss it, = but since people are talking about it, here's what I sent to Deion = Yu privately:

I just = read through this draft. I think it would be much simpler to implement = if it used the existing ID command instead. For example:
a ID ("client-id-type" "uuid" "client-id-token" = "23bf83be-aad7-46aa-9e0f-39191ccf402f")

Or = alternatively:

a ID ("client-id-uuid" = "23bf83be-aad7-46aa-9e0f-39191ccf402f")

It = wouldn't require any new capabilities either. Client could simply send = this command if it sees ID capability advertised. The servers can then = either do something with it or ignore it.

On 20 = Jul 2018, at 6.55, Bron Gondwana <brong@fastmailteam.com> wrote:

We discussed = draft-yu-imap-client-id in today's meeting, and while we came to the = conclusion that it wasn't a document for the working group to adopt, the = problem it's trying to solve is something which the IETF could help = with.

Ned's comment in = jabber that didn't make it into the discussion was something like, it's = a cookie, just one the client creates.  That's pretty much = it.  It's basically there are an input to the calculation that = every server has to make on every connection "how much do I believe that = this login is from who it says it's from", or at a more meta level "how = trustworthy is this connection and much do I want to obey its = requests".

At the most = trivial level, that's what authentication is - the username and password = (or whatever) gives the server sufficient trust in the other end of the = connection that it allows access to (and maybe modification of a subset = of resources, correlated by the username used).

A general cookie-like "this is a device I have = communicated with before" as an additional input to the server's = decision making would be welcomed by services who see stolen passwords = as a common fraud problem, so there would definitely be appetite for = this kind of work.

The open question = really is "is this work better suited to a different group and = potentially a different area", and if so "can we help the authors find = that area".

Bron.

--
 = Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


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

= --Apple-Mail=_453EB693-14E8-4461-A792-DA38D2108C93-- From nobody Fri Jul 20 17:25:00 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5E7130E42 for ; Fri, 20 Jul 2018 17:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ShW_3rQCWQLM for ; Fri, 20 Jul 2018 17:24:54 -0700 (PDT) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 82ED5130E34 for ; Fri, 20 Jul 2018 17:24:54 -0700 (PDT) Received: (qmail 16318 invoked from network); 21 Jul 2018 00:24:51 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (7b7c1fdc-8c7c-11e8-ba10-2f83949a29ab); Fri, 20 Jul 2018 17:24:51 -0700 To: extra@ietf.org References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Fri, 20 Jul 2018 17:24:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 7b7c1fdc-8c7c-11e8-ba10-2f83949a29ab X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 00:24:58 -0000 Well first of all, don't you love coming back to the office with all the back log after a week.. And I am preparing a fuller response to the results of IETF discussion, and I apologize I have not completed it yet today. And I do want to say, that my presentation might have got off on the wrong foot, (eg presented a little too much 'fluff' in front of the group), please allow that it was my naivete on the process and the late scheduling changes, that led me to concentrate on the motivation and need for this capability, rather than the 'process' involved for acceptance in to the working groups mandate. And while we agreed that not enough consensus was arrived at to formally include this in the working group, we did agree that the discussion should take place on the mailing list to enable arguments and opinions that can lead to a consensus, and I will create a new separate thread on those arguments, and hope to help others understand why, while having cross purposes for security related issues that may cross service boundaries, based on that it is an IMAP syntax proposal, should at least be discussed, if not included. However, we did get some constructive ideas, and the 'id' idea is one of those, and I intended to thread this topic separately. Since the thread is started, I have changed the subject.. (And yes, while this might support an argument that CID 'might' belong in the working group, see other thread for conversations on that topic) Timo, and others incidental to this list mention this concept (RFC2971) We did examine this, however RFC 2971 makes EXPLICIT arguments that this information provided by ID is NOT to be used for any form of 'flow control' .. "Implementations MUST NOT make operational changes based on the data sent as part of the ID command or response. The ID command is for human consumption only, and is not to be used in improving the performance of clients or servers." As we did not know how best to conciliate those cross purposes, so we chose an alternative so that we could explicitly allow for actions based on the information provided. Also, the existing RFC does not address the issue of presenting that information across a non-secure layer. * Open to suggestions on how to address those conflicts * Open to discussions on the cross purposes of these two concepts * Open to discuss whether 'similar' concept extensions should be discussed in this group. * Should RFC 2971 be revamped to allow for conceptually presenting information that can be used for decision making, or are they for distinct enough purposes that they should be considered as separate need cases. Thanks for the feedback Timo.. Welcome other comments on this topic only in this thread. On 18-07-20 04:13 PM, Timo Sirainen wrote: > Well, originally I thought this wouldn't be the right place to discuss > it, but since people are talking about it, here's what I sent to Deion > Yu privately: > > I just read through this draft. I think it would be much simpler to > implement if it used the existing ID command instead. For example: > > a ID ("client-id-type" "uuid" "client-id-token" > "23bf83be-aad7-46aa-9e0f-39191ccf402f") > > Or alternatively: > > a ID ("client-id-uuid" "23bf83be-aad7-46aa-9e0f-39191ccf402f") > > It wouldn't require any new capabilities either. Client could simply > send this command if it sees ID capability advertised. The servers can > then either do something with it or ignore it. > >> On 20 Jul 2018, at 6.55, Bron Gondwana > > wrote: >> >> We discussed draft-yu-imap-client-id in today's meeting, and while we >> came to the conclusion that it wasn't a document for the working group >> to adopt, the problem it's trying to solve is something which the IETF >> could help with. >> >> Ned's comment in jabber that didn't make it into the discussion was >> something like, it's a cookie, just one the client creates.  That's >> pretty much it.  It's basically there are an input to the calculation >> that every server has to make on every connection "how much do I >> believe that this login is from who it says it's from", or at a more >> meta level "how trustworthy is this connection and much do I want to >> obey its requests". >> >> At the most trivial level, that's what authentication is - the >> username and password (or whatever) gives the server sufficient trust >> in the other end of the connection that it allows access to (and maybe >> modification of a subset of resources, correlated by the username used). >> >> A general cookie-like "this is a device I have communicated with >> before" as an additional input to the server's decision making would >> be welcomed by services who see stolen passwords as a common fraud >> problem, so there would definitely be appetite for this kind of work. >> >> The open question really is "is this work better suited to a different >> group and potentially a different area", and if so "can we help the >> authors find that area". >> >> Bron. >> >> -- >>   Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Sat Jul 21 06:39:55 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E52129C6A for ; Sat, 21 Jul 2018 06:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=dA5cPM63; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JdVYtJZd 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 lWExh-tvx821 for ; Sat, 21 Jul 2018 06:39:50 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88711124C04 for ; Sat, 21 Jul 2018 06:39:50 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id CEB2E285 for ; Sat, 21 Jul 2018 09:39:49 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Sat, 21 Jul 2018 09:39:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=lKUQO3k78GHjK6VVK n3SRGeBKe0nCH1/v1wnnbeb2B0=; b=dA5cPM63uNLk1ynavYy4KKP5oQiHJzMhZ SBk5mI3rarWzJ9ElVpfcl+yBt3MUUFdCO9/sZntiznmUxDrXfaflW8G3+g8w7jUu mDU+qtq7s9OmzTTTXYQTMDm/rbDxpxNWHvL5SIooFqNadUSOP8gDiIWlmWcerD35 L5cs0Y+x6a4nswCTPkCU1yW7YmeIWE+a0YeIsvV07id2Dyy5ILx4NhpjPqM9U6FM fI8axZG0ZhmomUKZ3JOsJsBwlx0T7vAjzrtTGvxDXR49suOm0jGdJzeNWDRa+8d5 oWS93cSEOBwu3f7bBFTh6tL2awFLk6cxkHdwVUm8uUncilk9s2UXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=lKUQO3 k78GHjK6VVKn3SRGeBKe0nCH1/v1wnnbeb2B0=; b=JdVYtJZdFYx2ovPLKttxC1 O3z1/J+9jChOTYT1eTjzWxh7j3d7Eh5qzIUjZk+NyuUFWPpPM3n1QMgHQd4uBxgs yJWjWro/C3U1taDsMe8HT5UGN6GBPXTYvX44zSRhwjstC8f8w7I5JJaX/tmAfdRp J1WqtY4yov6g8HkgEIeGKTzoJRrdSs+nmznQrwjrrLk4s57j06CLyzqzb4ZJpNy6 J5rEJfnfqib5mSPOhlWu3JK73Rb+yhH4A8Ym8lMm7DG8BxIeaFt3KUAigWd0SKnE rskLEJJKHKFu43BNbFLmdeps54GhfqD9ALXpZmGDP3M519wTRueqP3n/rLvx8yvA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 093B4412A; Sat, 21 Jul 2018 09:39:49 -0400 (EDT) Message-Id: <1532180388.4179223.1448244760.02EE5BE3@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153218038841792230" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> In-Reply-To: Date: Sat, 21 Jul 2018 23:39:48 +1000 Archived-At: Subject: Re: [Extra] client-id next steps - let's find them a home X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 13:39:54 -0000 This is a multi-part message in MIME format. --_----------=_153218038841792230 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I also suggested that too Michael the first time we talked. Apparently the issue was with use before/after authentication. Certainly in FastMail's case, ID before auth would be in nginx rather than Cyrus, so we don't even advertise it until after auth because we want to log it on the backend. Bron. On Sat, Jul 21, 2018, at 09:13, Timo Sirainen wrote: > Well, originally I thought this wouldn't be the right place to discuss > it, but since people are talking about it, here's what I sent to Deion > Yu privately:> > I just read through this draft. I think it would be much simpler to > implement if it used the existing ID command instead. For example:> > a ID ("client-id-type" "uuid" "client-id-token" "23bf83be-aad7-46aa-9e0f- > 39191ccf402f")> > Or alternatively: > > a ID ("client-id-uuid" "23bf83be-aad7-46aa-9e0f-39191ccf402f") > > It wouldn't require any new capabilities either. Client could simply > send this command if it sees ID capability advertised. The servers can > then either do something with it or ignore it.> >> On 20 Jul 2018, at 6.55, Bron Gondwana >> wrote:>> >> We discussed draft-yu-imap-client-id in today's meeting, and while we >> came to the conclusion that it wasn't a document for the working >> group to adopt, the problem it's trying to solve is something which >> the IETF could help with.>> >> Ned's comment in jabber that didn't make it into the discussion was >> something like, it's a cookie, just one the client creates. That's >> pretty much it. It's basically there are an input to the calculation >> that every server has to make on every connection "how much do I >> believe that this login is from who it says it's from", or at a more >> meta level "how trustworthy is this connection and much do I want to >> obey its requests".>> >> At the most trivial level, that's what authentication is - the >> username and password (or whatever) gives the server sufficient trust >> in the other end of the connection that it allows access to (and >> maybe modification of a subset of resources, correlated by the >> username used).>> >> A general cookie-like "this is a device I have communicated with >> before" as an additional input to the server's decision making would >> be welcomed by services who see stolen passwords as a common fraud >> problem, so there would definitely be appetite for this kind of work.>> >> The open question really is "is this work better suited to a >> different group and potentially a different area", and if so "can we >> help the authors find that area".>> >> Bron. >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153218038841792230 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I also suggested that too Michael the first time we talked. Apparently the issue was with use before/after authentication.

Certainly in FastMail's case, ID before auth would be in nginx rather than Cyrus, so we don't even advertise it until after auth because we want to log it on the backend.

Bron.


On Sat, Jul 21, 2018, at 09:13, Timo Sirainen wrote:
Well, originally I thought this wouldn't be the right place to discuss it, but since people are talking about it, here's what I sent to Deion Yu privately:

I just read through this draft. I think it would be much simpler to implement if it used the existing ID command instead. For example:

a ID ("client-id-type" "uuid" "client-id-token" "23bf83be-aad7-46aa-9e0f-39191ccf402f")

Or alternatively:

a ID ("client-id-uuid" "23bf83be-aad7-46aa-9e0f-39191ccf402f")

It wouldn't require any new capabilities either. Client could simply send this command if it sees ID capability advertised. The servers can then either do something with it or ignore it.

On 20 Jul 2018, at 6.55, Bron Gondwana <brong@fastmailteam.com> wrote:

We discussed draft-yu-imap-client-id in today's meeting, and while we came to the conclusion that it wasn't a document for the working group to adopt, the problem it's trying to solve is something which the IETF could help with.

Ned's comment in jabber that didn't make it into the discussion was something like, it's a cookie, just one the client creates.  That's pretty much it.  It's basically there are an input to the calculation that every server has to make on every connection "how much do I believe that this login is from who it says it's from", or at a more meta level "how trustworthy is this connection and much do I want to obey its requests".

At the most trivial level, that's what authentication is - the username and password (or whatever) gives the server sufficient trust in the other end of the connection that it allows access to (and maybe modification of a subset of resources, correlated by the username used).

A general cookie-like "this is a device I have communicated with before" as an additional input to the server's decision making would be welcomed by services who see stolen passwords as a common fraud problem, so there would definitely be appetite for this kind of work.

The open question really is "is this work better suited to a different group and potentially a different area", and if so "can we help the authors find that area".

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd


_______________________________________________
Extra mailing list
_______________________________________________
Extra mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--_----------=_153218038841792230-- From nobody Sat Jul 21 07:15:06 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CAD130E07 for ; Sat, 21 Jul 2018 07:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=cNrA1+wc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EIkDEJnJ 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 CP8WQuqCtdcE for ; Sat, 21 Jul 2018 07:14:49 -0700 (PDT) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88102130EFC for ; Sat, 21 Jul 2018 07:14:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 4B93A2B6 for ; Sat, 21 Jul 2018 10:14:48 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 21 Jul 2018 10:14:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=DYY5SdPwb+4TA/SQ9 WwZbK5eA1FQDCJmNL3UB/iVgmM=; b=cNrA1+wcKRJI6/kFd9Pbqr9bz+ZIMxEri urVcRFRyUMrs7xi675WX72Bns1jLbeomOO294rD2/A2aQ1uuyxa/Wpao3Eha2xMN oPNngOQUxWKXMadPzZt+nyd6Na7qeWxCosEs26c70Kokt6uXLOKXv/KiSWxmX5ri XHNDTGIWNQeTP6+sHE2QZ5vcMJfeWDAFQP3mDYhTxRluXVYHnd0WNxKPB6wDs3Us 4NkoGOu5FC7+g5L2H/4AYf8vCu9nuOS3F3c+DPNHnlOPvmTd9zdcrdW8sJJFnUkx rjf8AoHFLrVpWwHXhMWFMcUUd16k/0SEg/uHzez9ffjxWy5pwXIog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=DYY5Sd Pwb+4TA/SQ9WwZbK5eA1FQDCJmNL3UB/iVgmM=; b=EIkDEJnJVQDDRdZDYrd9PP EOjJuN7a9l9de8owxj4pywdowMOQqPdZZepg8Rjtoh+wb4x+i/w8vZ8GSCqqiegn 8QKTF63NzMukVJN4xXI3HS71GpSIxhgeG/ZYJjk/WEZzHw9SPwCIh+SJVhgdwo5w zgtGQBDxniw6/E+zDrHUXVqEa8sunMVsa6LD3tMjL3hQt2rmi9CFMY3Q/scqS3Zz pNZwePttZxTFoezBjfKGQBQrx9IxIul0H8U3/Mvg2ab0fWYtr6pg63xFYqX2Ud07 nVE822EPX5aJAt7qJlF5KLX3PGM7nd5vuGm7aCXm2tfaM6f6d/gAtF2lVEWX5CGw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6CC3E621DC; Sat, 21 Jul 2018 10:14:47 -0400 (EDT) Message-Id: <1532182487.3800048.1448253600.58F382B9@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153218248738000480" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> In-Reply-To: Date: Sun, 22 Jul 2018 00:14:47 +1000 Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 14:15:00 -0000 This is a multi-part message in MIME format. --_----------=_153218248738000480 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, Jul 21, 2018, at 10:24, Michael Peddemors wrote: > And I do want to say, that my presentation might have got off on the > wrong foot, (eg presented a little too much 'fluff' in front of the > group), please allow that it was my naivete on the process and > the late> scheduling changes, that led me to concentrate on the motivation and > need for this capability, rather than the 'process' involved for > acceptance in to the working groups mandate. This group is very technical, and most of the people who spoke up are people who will have to implement this in a server or client, and maintain the infrastructure it's going into, some of which is quite different from the infrastructure of the systems you use or have worked on. This group of people understands issues pretty quickly, so we jumped directly to the process of not only deploying this in the first place, but maintaining it and the impact on the rest of the ecosystem. > And while we agreed that not enough consensus was arrived at to > formally> include this in the working group, we did agree that the discussion > should take place on the mailing list to enable arguments and opinions> that can lead to a consensus, and I will create a new separate > thread on> those arguments, and hope to help others understand why, while having> cross purposes for security related issues that may cross service > boundaries, based on that it is an IMAP syntax proposal, should > at least> be discussed, if not included. I would caution against getting caught up on the "something needs to be done", "this is something", "therefore we must do this". I felt there was a fair degree of "this is a real issue that could do with being solved" in the room, but it doesn't necessarily flow that it must be solved at the IMAP syntax level. > However, we did get some constructive ideas, and the 'id' idea > is one of> those, and I intended to thread this topic separately. > > Since the thread is started, I have changed the subject.. > > (And yes, while this might support an argument that CID 'might'> belong in the working group, see other thread for conversations on > that> topic) > > Timo, and others incidental to this list mention this concept > (RFC2971)> > We did examine this, however RFC 2971 makes EXPLICIT arguments > that this> information provided by ID is NOT to be used for any form of 'flow > control' .. > > "Implementations MUST NOT make operational changes based on the data > sent as part of the ID command or response. The ID command is for> human consumption only, and is not to be used in improving the > performance of clients or servers." Of course if we were to update RFC2971, that would be something that could be considered. We can change anything that's within charter and passes expert review from the rest of the IETF. And let's be honest, not everybody obeys that "MUST NOT" anyway... https://github.com/cyrusimap/cyrus-imapd/commit/b61e07ed212ae20eb1f8f57de7cee6e7f1c2c839 It was a choice between search being unusable on iOS and search being quite nice on iOS, but not strictly standards compliant, while not making search non-standard for every other IMAP user. > * Open to suggestions on how to address those conflicts > * Open to discussions on the cross purposes of these two concepts > * Open to discuss whether 'similar' concept extensions should be > discussed in this group. > * Should RFC 2971 be revamped to allow for conceptually presenting > information that can be used for decision making, or are they for > distinct enough purposes that they should be considered as > separate need> cases. I do agree that there are downsides to extending ID rather than having a new command. CLIENTID would be very simple for me to implement in Cyrus, and I expect it would be relatively easy to implement in Nginx as a value passed through to the authentication engine as well. That's not nothing. We may also need to discuss how ISPs which still don't enforce TLS because they are afraid of support calls and losing customers are going to handle deploying this extension. The justification that we need this because ISPs are still allowing plain text passwords seems to conflict with the idea that those customers who can't be migrated to TLS are going to upgrade to clients which support any new standard we propose. So if we're doing this just to help those ISPs, it might end up being a futile exercise. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153218248738000480 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, Jul 21, 2018, at 10:24, Michael Peddemors wrote:
And I do want to say, that my presentation might have got off on the
wrong foot, (eg presented a little too much 'fluff' in front of the
group), please allow that it was my naivete on the process and the late
scheduling changes, that led me to concentrate on the motivation and
need for this capability, rather than the 'process' involved for
acceptance in to the working groups mandate.

This group is very technical, and most of the people who spoke up are people who will have to implement this in a server or client, and maintain the infrastructure it's going into, some of which is quite different from the infrastructure of the systems you use or have worked on.  This group of people understands issues pretty quickly, so we jumped directly to the process of not only deploying this in the first place, but maintaining it and the impact on the rest of the ecosystem.

And while we agreed that not enough consensus was arrived at to formally
include this in the working group, we did agree that the discussion
should take place on the mailing list to enable arguments and opinions
that can lead to a consensus, and I will create a new separate thread on
those arguments, and hope to help others understand why, while having
cross purposes for security related issues that may cross service
boundaries, based on that it is an IMAP syntax proposal, should at least
be discussed, if not included.

I would caution against getting caught up on the "something needs to be done", "this is something", "therefore we must do this".  I felt there was a fair degree of "this is a real issue that could do with being solved" in the room, but it doesn't necessarily flow that it must be solved at the IMAP syntax level.

However, we did get some constructive ideas, and the 'id' idea is one of
those, and I intended to thread this topic separately.

Since the thread is started, I have changed the subject..

(And yes, while this might support an argument that CID <sic> 'might'
belong in the working group, see other thread for conversations on that
topic)

Timo, and others incidental to this list mention this concept (RFC2971)

We did examine this, however RFC 2971 makes EXPLICIT arguments that this
information provided by ID is NOT to be used for any form of 'flow
control' ..

"Implementations MUST NOT make operational changes based on the data
    sent as part of the ID command or response.  The ID command is for
    human consumption only, and is not to be used in improving the
    performance of clients or servers."

Of course if we were to update RFC2971, that would be something that could be considered.  We can change anything that's within charter and passes expert review from the rest of the IETF.

And let's be honest, not everybody obeys that "MUST NOT" anyway...


It was a choice between search being unusable on iOS and search being quite nice on iOS, but not strictly standards compliant, while not making search non-standard for every other IMAP user.

* Open to suggestions on how to address those conflicts
* Open to discussions on the cross purposes of these two concepts
* Open to discuss whether 'similar' concept extensions should be
discussed in this group.
* Should RFC 2971 be revamped to allow for conceptually presenting
information that can be used for decision making, or are they for
distinct enough purposes that they should be considered as separate need
cases.

I do agree that there are downsides to extending ID rather than having a new command.  CLIENTID would be very simple for me to implement in Cyrus, and I expect it would be relatively easy to implement in Nginx as a value passed through to the authentication engine as well.  That's not nothing.

We may also need to discuss how ISPs which still don't enforce TLS because they are afraid of support calls and losing customers are going to handle deploying this extension.  The justification that we need this because ISPs are still allowing plain text passwords seems to conflict with the idea that those customers who can't be migrated to TLS are going to upgrade to clients which support any new standard we propose.  So if we're doing this just to help those ISPs, it might end up being a futile exercise.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153218248738000480-- From nobody Sat Jul 21 08:33:25 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84309130DEA for ; Sat, 21 Jul 2018 08:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UTnSLTFj; dkim=pass (1536-bit key) header.d=taugh.com header.b=DHKOxYj8 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 1lx0PR9nH-7a for ; Sat, 21 Jul 2018 08:33:15 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 1A617130DE9 for ; Sat, 21 Jul 2018 08:33:14 -0700 (PDT) Received: (qmail 61295 invoked from network); 21 Jul 2018 15:33:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ef6d.5b535239.k1807; bh=ANLEFWo03hJ7zmyl3jameUK87B/bCBk2vB552rkgjMw=; b=UTnSLTFjPljfk9NJfsReh/AuEvaLY5ZHCBwBhs404tObpq9+FgnCkQOnoMM8j8ywiWfYNgBEZJL9NIhqQI4iFcr3/vnGBR3mu73S7txrbgEm6HDsm2Tx3xN3IgjGC+osghkBV0OWDgFtoYZZ4/6XyWXaSS8XDzxmdKRgQxKN43l9UMjVfBfDkMmhWItarA8TC+943gH55MPVOhSkdZOZVBRIIyqIdu4dihUX67H9uR0T6TzZv3fnScz0BYdaL4a+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ef6d.5b535239.k1807; bh=ANLEFWo03hJ7zmyl3jameUK87B/bCBk2vB552rkgjMw=; b=DHKOxYj8G46Nv5TwE8S17LtUucbEZyodZooQrL+JLaJfU4wHWv/a3wzuGZWGRlh2sHcBNJKOiXWnnvOYCgE1oXV4wYIorF8lthoesWzV+V15zQKSyROyV386BgMG62XH9kgxE++g9hb4W8Ur+yUhyCzyL6soRy/N52EAwoXrslpCmfaMtQY3tuSaFN+kp9QImoKuUSSL1lSAOS/h1TnZZ1XF83haFGhOZF2X/mvD7XczINoPxA2wawvfYWhOdbua Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 21 Jul 2018 15:33:13 -0000 Received: by ary.qy (Postfix, from userid 501) id 44F5C200288316; Sat, 21 Jul 2018 11:33:12 -0400 (EDT) Date: 21 Jul 2018 11:33:12 -0400 Message-Id: <20180721153313.44F5C200288316@ary.qy> From: "John Levine" To: extra@ietf.org Cc: ned.freed@mrochek.com In-Reply-To: <01QV33SLJJQA000051@mauve.mrochek.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Extra] client-id next steps - let's find them a home X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 15:33:22 -0000 In article <01QV33SLJJQA000051@mauve.mrochek.com> you write: >More specificially, a client certificate could be included in the TLS exchange >and then used for this purpose. It could be self-generated and self-signed, >it could be acquired through the use of ACME or some other protocol - lots >of possibilities there, including the abiity to revoke it. This is a very good point. Clients could start sending self-signed client certs in the TLS handshalke today with no protocol changes at all. Hmmn. There is the usual crudware problems since I would guess there is too much code that would barf on that, either fail because it's not expecting a cert, or never debugged "this cert isn't signed by a CA I trust therefore it is bad." I have seen code that uses client certs signed by a private CA for submit authorization. That doesn't necessarily conflict except that if I have two MUAs I might put the same cert on both of them so the server can't tell them apart. That's probably not a problem until it is, e.g., one MUA is the phone I just lost. Yes, I realize that the proper approach is to generate separate requests on each device and sign them separately. R's, John From nobody Mon Jul 23 11:27:43 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7DF1277C8 for ; Mon, 23 Jul 2018 11:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Lui4VQlFMHMD for ; Mon, 23 Jul 2018 11:27:38 -0700 (PDT) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id DECB6130DC5 for ; Mon, 23 Jul 2018 11:27:37 -0700 (PDT) Received: (qmail 3831 invoked from network); 23 Jul 2018 18:27:35 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (11c1b0b2-8ea6-11e8-a9fc-a75291780354); Mon, 23 Jul 2018 11:27:35 -0700 To: extra@ietf.org From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> Date: Mon, 23 Jul 2018 11:27:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 11c1b0b2-8ea6-11e8-a9fc-a75291780354 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: [Extra] CLIENT ID - Next Steps - General Discussion Overview X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 18:27:41 -0000 Thanks once again for allowing us to present at the IMAP EXTRA group, and now that everyone is back home, it is a good time to reflect on the discussions surrounding CID (Client ID) in IMAP, as we concluded that there was not yet enough consensus around this, and we agreed to open up dialogue/discussion on the list, so that we can argue for, and hopefully gain consensus on that it should be part of this groups' mandate. And I have to thank everyone for all the comments, and appreciate your patience as we go through this process, and the 'mentor' comments from Alexey, Bron, John and others.. It helped us better understand separating the 'process' from the ideal of the CID proposal. It seemed that the group understood the later, without the need for me to 'champion' the idea as much. I think everyone in the group understood, and with everyone looking at or implementing methods to allow traditional services to have the capability of at least alerting users to when unexpected/new access to a service is detected, we should consider that if everyone 'sees the value of this capability', or 'is already trying to do this', that creating a 'standard' for this is good for everyone, and the IETF is the correct venue for setting the standards, whether it is this working group or another. (Albeit, we will argue that this group is currently the right place for this based on that the 'syntax' for IMAP is separate from all other services, and other arguments) However, there were several items brought up that should be discussed as separate issues and threads, so I propose that some of these get discussed separate to the arguments on the correct 'home' for CID. Some points brought up: * CID Naming, several persons pointed out that this can become confusing as IMAP uses that type of name for other purposes. I will start a separate thread on this topic, as it should be open for discussion. * Security Notes, it was brought up that we left the idea of what CID Types and Tokens as open ended, and available to email client developers to have the flexibility to make decisions on what should be a token. It was suggested we add more information to the security section, eg reminding developers to consider that Cid identifiers might be created in a way that they are unique to a hostname and/or service. And while this isn't really part of the core draft, it does behoove us to have conversation on this topic, and I will pass this on to the author, but probably best to allow discussion on this topic. * Discussion on whether the purpose of CID can be served via the ID command (RFC2971), and a separate thread has been started on that topic. (Thanks Timo) * It was questioned, is the proper place for this in a SASL mechanism, vs in the protocol itself, and while our development work and research show that the advantages for a 'device identifier' to be part of the protocol/syntax rather than a SASL, and our assertion this will help in the adoption curve in the industry, it was one of the strongest points of contention, with the arguments for SASL, was one SASL can apply to many services, and thus if that argument holds, then maybe the SASL or a security group would be better for this. We intend to argue against this, but the topic alone is key to discussions, so it requires a separate thread to discuss this. * Outside of the meeting, mention was whether there is a reasoning that some form of general working group be considered that applies to all the standard email protocols, eg SMTP (Submission Only), IMAP/IMAP-SSL and POP/POP-SSL etc, however that is for others way beyond me to argue and I prefer to leave it out of this discussion. * While it might seem like 'lobbying', it might be worth assessing who considers the concept worth pursuing/implementing as well as having others who are trying to solve the problem in other ways, to have a general discussion on what they are doing, or which methods that they prefer, as this might aid in validating that the need has enough people working on this that it does indeed need to be standardized. But would like the opinions of others with more IETF experience to determine if that conversation should be pursued here. As pointed out we have had conversations with other IMAP implementors that have voiced opinions that they could see themselves implementing this. * Some conversation was help that the CID 'TYPE' might need to be defined, and whether CID 'TYPE' should be become 'registered' types, if indeed standardization is the goal, and while the suggestion is appreciated, sounds like putting the cart in front of the horse, and whether it would be better to let IMAP client developers have more freedom. I think this can be left until later in the discussions. In summary, the first four (4) bullet points, would be better discussed separately, and I will be following up in separate threads to the list. As pointed out, we strongly believe that CID goes beyond the mandate of SASL mechanisms, but it is obvious that is the fundamental point of contention that needs to be resolved and argued, as our perceived importance of it being outside of SASL has at least not yet clearly been communicated so others can argue the merits of this, so I expect it to be the most discussed bullet point, but we of course can continue our own movement forward by addressing the other points in the mean time, including draft updates, and our own implementations. Once again, we thank all for their comments and their support, as we work through this process. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Mon Jul 23 11:33:09 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C160130E42 for ; Mon, 23 Jul 2018 11:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 S8LDAebx3Gkh for ; Mon, 23 Jul 2018 11:33:05 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 7145E130DC5 for ; Mon, 23 Jul 2018 11:33:05 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6NIOC8m188411; Mon, 23 Jul 2018 18:33:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=w6P/uyuqezoa74imD8I4wSyriIWtkY+qhhs20ghDqQ4=; b=Etb+QLTQ/mj67SJ8D93E02w1a3efkIwlawaEVuqGCa6LWPhd3oqtUBYcerOq8ehyOf2V dz/DWbBd6KKcJ1eDr9WuWMR9jJg/hz9o0zEgRBGup8CVT1vpTTFCNYFPJFiF0cA6fSWj LOwvBqpXOCcpG86zM9IndhLQuACSLes3w0oOzOkAL3b4yH+G+nwHyEpZprFtzmWKC7iM ohadJWmIqK8tlSHoJRZnzCt4A003qM2a1zf6XL0GmdWlrOCKPQWG//pwMCbOLEZFAu6s rWdYT3nZt95TOCI1GP96Zv3C4mA6F/5ya1aOMDOsERztlVxrtgRr3ZLkyrAsgVsjYvHn xg== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2kbv8swtx0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jul 2018 18:33:04 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6NIX3hC030920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jul 2018 18:33:03 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6NIX1Rf003471; Mon, 23 Jul 2018 18:33:01 GMT Received: from [10.145.183.90] (/10.145.183.90) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2018 11:33:00 -0700 From: "Chris Newman" To: "Michael Peddemors" Cc: extra@ietf.org Date: Mon, 23 Jul 2018 13:59:09 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8963 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807230204 Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 18:33:08 -0000 On 20 Jul 2018, at 20:24, Michael Peddemors wrote: > Well first of all, don't you love coming back to the office with all = > the back log after a week.. And I am preparing a fuller response to = > the results of IETF discussion, and I apologize I have not completed = > it yet today. > > And I do want to say, that my presentation might have got off on the = > wrong foot, (eg presented a little too much 'fluff' in front of the = > group), please allow that it was my naivete on the process and the = > late scheduling changes, that led me to concentrate on the motivation = > and need for this capability, rather than the 'process' involved for = > acceptance in to the working groups mandate. > > And while we agreed that not enough consensus was arrived at to = > formally include this in the working group, we did agree that the = > discussion should take place on the mailing list to enable arguments = > and opinions that can lead to a consensus, and I will create a new = > separate thread on those arguments, and hope to help others understand = > why, while having cross purposes for security related issues that may = > cross service boundaries, based on that it is an IMAP syntax proposal, = > should at least be discussed, if not included. > > However, we did get some constructive ideas, and the 'id' idea is one = > of those, and I intended to thread this topic separately. > > Since the thread is started, I have changed the subject.. > > (And yes, while this might support an argument that CID 'might' = > belong in the working group, see other thread for conversations on = > that topic) > > Timo, and others incidental to this list mention this concept = > (RFC2971) > > We did examine this, however RFC 2971 makes EXPLICIT arguments that = > this information provided by ID is NOT to be used for any form of = > 'flow control' .. > > "Implementations MUST NOT make operational changes based on the data > sent as part of the ID command or response. The ID command is for > human consumption only, and is not to be used in improving the > performance of clients or servers." > > As we did not know how best to conciliate those cross purposes, so we = > chose an alternative so that we could explicitly allow for actions = > based on the information provided. There are valid concerns about not using client ID data in a way that = reduces rather than increases interoperability, but the current text in = RFC 2971 takes too heavy a hand. > Also, the existing RFC does not address the issue of presenting that = > information across a non-secure layer. At the time 2971 was written, TLS was expensive. Now we're in a = situation where the cost of TLS is low compared to the potential = reputation/privacy risks of not using TLS. I would support revising IMAP = ID to explicitly disallow use of the command on a non-TLS channel (in = case there are compatibility issues, I'd suggest: SHOULD NOT send / = SHOULD NOT advertise unless TLS negotiated first). On the flip side, I still prefer having a client-id solution that uses = the same syntax and semantics across multiple protocols rather than a = bunch of protocol-specific client-id solutions. - Chris > * Open to suggestions on how to address those conflicts > * Open to discussions on the cross purposes of these two concepts > * Open to discuss whether 'similar' concept extensions should be = > discussed in this group. > * Should RFC 2971 be revamped to allow for conceptually presenting = > information that can be used for decision making, or are they for = > distinct enough purposes that they should be considered as separate = > need cases. > > Thanks for the feedback Timo.. > > Welcome other comments on this topic only in this thread. > > > On 18-07-20 04:13 PM, Timo Sirainen wrote: >> Well, originally I thought this wouldn't be the right place to = >> discuss it, but since people are talking about it, here's what I sent = >> to=C2=A0Deion Yu privately: >> >> I just read through this draft. I think it would be much simpler to = >> implement if it used the existing ID command instead. For example: >> >> a ID ("client-id-type" "uuid" "client-id-token" = >> "23bf83be-aad7-46aa-9e0f-39191ccf402f") >> >> Or alternatively: >> >> a ID ("client-id-uuid" "23bf83be-aad7-46aa-9e0f-39191ccf402f") >> >> It wouldn't require any new capabilities either. Client could simply = >> send this command if it sees ID capability advertised. The servers = >> can then either=C2=A0do something with it or ignore it. >> >>> On 20 Jul 2018, at 6.55, Bron Gondwana >> > wrote: >>> >>> We discussed draft-yu-imap-client-id in today's meeting, and while = >>> we came to the conclusion that it wasn't a document for the working = >>> group to adopt, the problem it's trying to solve is something which = >>> the IETF could help with. >>> >>> Ned's comment in jabber that didn't make it into the discussion was = >>> something like, it's a cookie, just one the client creates.=C2=A0 Tha= t's = >>> pretty much it.=C2=A0 It's basically there are an input to the = >>> calculation that every server has to make on every connection "how = >>> much do I believe that this login is from who it says it's from", or = >>> at a more meta level "how trustworthy is this connection and much do = >>> I want to obey its requests". >>> >>> At the most trivial level, that's what authentication is - the = >>> username and password (or whatever) gives the server sufficient = >>> trust in the other end of the connection that it allows access to = >>> (and maybe modification of a subset of resources, correlated by the = >>> username used). >>> >>> A general cookie-like "this is a device I have communicated with = >>> before" as an additional input to the server's decision making would = >>> be welcomed by services who see stolen passwords as a common fraud = >>> problem, so there would definitely be appetite for this kind of = >>> work. >>> >>> The open question really is "is this work better suited to a = >>> different group and potentially a different area", and if so "can we = >>> help the authors find that area". >>> >>> Bron. >>> >>> -- >>> =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd >>> brong@fastmailteam.com >>> >>> >>> _______________________________________________ >>> Extra mailing list >>> Extra@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_extra&d=3DDwIF-g&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DzhA2jiVBT1LOq= IdrBzaD9nMZGHkzYaAUmR3ZC1aa64s&s=3DYN3qhDuB0d0fb0EX2hQldEeZLuL1WmHO1Y5wiw= Dgna0&e=3D >> >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_extra&d=3DDwIF-g&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DzhA2jiVBT1LOqI= drBzaD9nMZGHkzYaAUmR3ZC1aa64s&s=3DYN3qhDuB0d0fb0EX2hQldEeZLuL1WmHO1Y5wiwD= gna0&e=3D >> > > > > -- = > "Catch the Magic of Linux..." > -----------------------------------------------------------------------= - > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at = > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.linuxmagic.co= m&d=3DDwIF-g&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5K= fkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DzhA2jiVBT1LOqIdrBzaD9nMZGHkzYaAUm= R3ZC1aa64s&s=3DelczaDywCQFgqdljiyuhNG8UEh_GhuoW8O6uZHyx4NM&e=3D = > @linuxmagic > A Wizard IT Company - For More Info = > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.wizard.ca&d=3D= DwIF-g&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3rx= t1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DzhA2jiVBT1LOqIdrBzaD9nMZGHkzYaAUmR3ZC1a= a64s&s=3DjhObT8NWMpYCzCgqsKd5MEoWkWc0jKa3keqUZ-TZ_f0&e=3D > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices = > Ltd. > -----------------------------------------------------------------------= - > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and = > intended > solely for the use of the individual or entity to which they are = > addressed. > Please note that any views or opinions presented in this email are = > solely > those of the author and are not intended to represent those of the = > company. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwIF-g&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DzhA2jiVBT1LOqId= rBzaD9nMZGHkzYaAUmR3ZC1aa64s&s=3DYN3qhDuB0d0fb0EX2hQldEeZLuL1WmHO1Y5wiwDg= na0&e=3D From nobody Mon Jul 23 11:33:15 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F99130E7A for ; Mon, 23 Jul 2018 11:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 dKKyBSRYQ3GB for ; Mon, 23 Jul 2018 11:33:07 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 71B4F130E0D for ; Mon, 23 Jul 2018 11:33:07 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6NIOHYS187913; Mon, 23 Jul 2018 18:33:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=eQTuNbB7mU9U1b+asM62qTmLsvL3f+9/jIrjwyBpIkg=; b=DK1tg5jfq5nuVehlJ9fTPtt7erJ6iPhFaI4G2qdh5gTcIJ8AkupF9EtT9p2BSJN6ApSs mb3X1kEckqb0yBGmcvi5pwpVQnDiAtvh8ys5XRfOzvXBNx1Fmi7tseswlQxjJ3wHstv0 PYJc2EzfGdfn9J6BMSlw6D4SOQqmywGwpjulHNzNAMAYTRzncMWOLPo3JtFT/O1dNnCG mI7AHMK4IU32X3usqVxmlVM0vmzNWIlr4l1BkN25ZfI7bX4uXDfScNrqYAPcdKasM9LG DdyWe7zhKs0TqBCkm5vX+qL0e8S0xIBq0324d26oGaazkT9YpAc4xIIP3Zv3vjGUxXOA cA== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2kbwfpns0p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jul 2018 18:33:03 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6NIX27q005822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jul 2018 18:33:03 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6NIX2gu022109; Mon, 23 Jul 2018 18:33:02 GMT Received: from [10.145.183.90] (/10.145.183.90) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2018 11:33:01 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org Date: Mon, 23 Jul 2018 13:38:18 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: <1532180388.4179223.1448244760.02EE5BE3@webmail.messagingengine.com> References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> <1532180388.4179223.1448244760.02EE5BE3@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_13B73BD4-865F-48E4-8BD9-5B63249CE71B_=" Embedded-HTML: [{"HTML":[1925, 10741], "plain":[534, 3556], "uuid":"DA15731A-4718-4A0B-B345-38415DF3B393"}] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8963 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807230204 Archived-At: Subject: Re: [Extra] client-id next steps - let's find them a home X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 18:33:10 -0000 --=_MailMate_13B73BD4-865F-48E4-8BD9-5B63249CE71B_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable According to RFC 2971 section 3.1: "This command is valid in any state." Our server-side proxy already implements the ID command and replays it = (so it can be logged on the backend). The only barrier to using RFC 2971 (IMAP ID) protocol for the client-id = function are some "MUST NOT" statements that would have to be revised. = That's a better option than creating yet-another command that a = server-side proxy has to replay to the backend and adding yet another = round-trip. - Chris On 21 Jul 2018, at 9:39, Bron Gondwana wrote: > I also suggested that too Michael the first time we talked. Apparently > the issue was with use before/after authentication. > Certainly in FastMail's case, ID before auth would be in nginx rather > than Cyrus, so we don't even advertise it until after auth because we > want to log it on the backend. > Bron. > > > On Sat, Jul 21, 2018, at 09:13, Timo Sirainen wrote: >> Well, originally I thought this wouldn't be the right place to = >> discuss >> it, but since people are talking about it, here's what I sent to = >> Deion >> Yu privately:> >> I just read through this draft. I think it would be much simpler to >> implement if it used the existing ID command instead. For example:> >> a ID ("client-id-type" "uuid" "client-id-token" = >> "23bf83be-aad7-46aa-9e0f- >> 39191ccf402f")> >> Or alternatively: >> >> a ID ("client-id-uuid" "23bf83be-aad7-46aa-9e0f-39191ccf402f") >> >> It wouldn't require any new capabilities either. Client could simply >> send this command if it sees ID capability advertised. The servers = >> can >> then either do something with it or ignore it.> >>> On 20 Jul 2018, at 6.55, Bron Gondwana >>> wrote:>> >>> We discussed draft-yu-imap-client-id in today's meeting, and while = >>> we >>> came to the conclusion that it wasn't a document for the working >>> group to adopt, the problem it's trying to solve is something which >>> the IETF could help with.>> >>> Ned's comment in jabber that didn't make it into the discussion was >>> something like, it's a cookie, just one the client creates. That's >>> pretty much it. It's basically there are an input to the = >>> calculation >>> that every server has to make on every connection "how much do I >>> believe that this login is from who it says it's from", or at a more >>> meta level "how trustworthy is this connection and much do I want to >>> obey its requests".>> >>> At the most trivial level, that's what authentication is - the >>> username and password (or whatever) gives the server sufficient = >>> trust >>> in the other end of the connection that it allows access to (and >>> maybe modification of a subset of resources, correlated by the >>> username used).>> >>> A general cookie-like "this is a device I have communicated with >>> before" as an additional input to the server's decision making would >>> be welcomed by services who see stolen passwords as a common fraud >>> problem, so there would definitely be appetite for this kind of = >>> work.>> >>> The open question really is "is this work better suited to a >>> different group and potentially a different area", and if so "can we >>> help the authors find that area".>> >>> Bron. >>> >>> -- >>> Bron Gondwana, CEO, FastMail Pty Ltd >>> brong@fastmailteam.com >>> >>> >>> _______________________________________________ >>> Extra mailing list >>> Extra@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_extra&d=3DDwICaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DaxQ7rAtEYy7Oh= WHYKLDGlWzoKTgnGMydGUGDpd_Sz5A&s=3DIb5ngMIgWVP4VHtE1ebxRsGIIGy8lljdbjKbMF= RAA2I&e=3D >> _________________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_extra&d=3DDwICaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DaxQ7rAtEYy7OhW= HYKLDGlWzoKTgnGMydGUGDpd_Sz5A&s=3DIb5ngMIgWVP4VHtE1ebxRsGIIGy8lljdbjKbMFR= AA2I&e=3D > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DaxQ7rAtEYy7OhWH= YKLDGlWzoKTgnGMydGUGDpd_Sz5A&s=3DIb5ngMIgWVP4VHtE1ebxRsGIIGy8lljdbjKbMFRA= A2I&e=3D --=_MailMate_13B73BD4-865F-48E4-8BD9-5B63249CE71B_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

According to RFC 2971 section 3.= 1: "This command is valid in any state."

Our server-side proxy already implements the ID command a= nd replays it (so it can be logged on the backend).

The only barrier to using RFC 2971 (IMAP ID) protocol for= the client-id function are some "MUST NOT" statements that wou= ld have to be revised. That's a better option than creating yet-anoth= er command that a server-side proxy has to replay to the backend and addi= ng yet another round-trip.

- Chris

On 21 Jul 2018, at 9:39, Bron Gondwana wrote:

I also suggested that too Michael the f= irst time we talked. Apparently the issue was with use before/after authe= ntication.

Certainly in FastMail's case, ID before= auth would be in nginx rather than Cyrus, so we don't even advertise it = until after auth because we want to log it on the backend.

Bron.


On Sat, Jul 21, 2018, at 09:13, Timo Sirainen wrote:
Well, origina= lly I thought this wouldn't be the right place to discuss it, but since p= eople are talking about it, here's what I sent to Deion Yu privately= :

I just read through this draft. I = think it would be much simpler to implement if it used the existing ID co= mmand instead. For example:

a ID ("client-id-type" "uuid" "client-i= d-token" "23bf83be-aad7-46aa-9e0f-39191ccf402f")

Or alternatively:

a ID ("client-id-uuid" "23bf83be-aad7-4= 6aa-9e0f-39191ccf402f")

It wouldn't require any new capabilitie= s either. Client could simply send this command if it sees ID capability = advertised. The servers can then either do something with it or igno= re it.

On 20 Jul 2018, at 6.55, Bron Gondwana <= ;brong@fastmailteam.com>= wrote:

We discussed draft-yu-= imap-client-id in today's meeting, and while we came to the conclusion th= at it wasn't a document for the working group to adopt, the problem it's = trying to solve is something which the IETF could help with.

Ned's comment in jabber tha= t didn't make it into the discussion was something like, it's a cookie, j= ust one the client creates.  That's pretty much it.  It's basic= ally there are an input to the calculation that every server has to make = on every connection "how much do I believe that this login is from who it= says it's from", or at a more meta level "how trustworthy is this connec= tion and much do I want to obey its requests".

At the most trivial level, = that's what authentication is - the username and password (or whatever) g= ives the server sufficient trust in the other end of the connection that = it allows access to (and maybe modification of a subset of resources, cor= related by the username used).

A general cookie-like "this= is a device I have communicated with before" as an additional input to t= he server's decision making would be welcomed by services who see stolen = passwords as a common fraud problem, so there would definitely be appetit= e for this kind of work.

The open question really is= "is this work better suited to a different group and potentially a diffe= rent area", and if so "can we help the authors find that area".
=

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd


_____________= __________________________________
Extra mailing= list
_______________________________________________
Extra mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
<= /div>
  brong@fastmailteam.com

________________________________= _______________
Extra mailing list
Extra@ietf.org
https://urldefense.proofpoint.= com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_extra&d=3DDwIC= Ag&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfk= r3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DaxQ7rAtEYy7OhWHYKLDGlWzoKTgnGMy= dGUGDpd_Sz5A&s=3DIb5ngMIgWVP4VHtE1ebxRsGIIGy8lljdbjKbMFRAA2I&e=3D=

--=_MailMate_13B73BD4-865F-48E4-8BD9-5B63249CE71B_=-- From nobody Mon Jul 23 12:09:39 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B44C130E42 for ; Mon, 23 Jul 2018 12:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xA8B1x9sxxC9 for ; Mon, 23 Jul 2018 12:09:36 -0700 (PDT) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 371E2130E36 for ; Mon, 23 Jul 2018 12:09:36 -0700 (PDT) Received: (qmail 14854 invoked from network); 23 Jul 2018 19:09:33 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (eeb53e44-8eab-11e8-ac10-4bdb1a8b6f76); Mon, 23 Jul 2018 12:09:33 -0700 To: extra@ietf.org From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Mon, 23 Jul 2018 12:09:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.x X-MagicMail-UUID: eeb53e44-8eab-11e8-ac10-4bdb1a8b6f76 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: [Extra] CLIENT ID - Next Steps - Feedback on CID naming convention X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 19:09:38 -0000 While not having received consensus on CID as an IMAP verb, it was good to hear the feedback on the naming convention, as their was concern that it might be confused with other 'client id' nomenclature in other RFC's and/or with the 'cid' as used in IMAP eg, the content id, and we are fully willing to consider a different naming convention as a standard. This thread is to receive input from the working group and community as to a naming convention that is less contentious. Note: Arguments for naming convention should be held ON the assumption, this will make it to being an IMAP VERB, which hasn't been decided yet, admittingly. While it can be argued that IMAP verbs and IMAP tags are two completely separate sets of identifiers, less confusion is always a good thing. We had considered other names to better reflect the idea of a 'device identifier' or a 'client identifier' before as well, but CID as an abbrevation for 'CLIENT ID' seemed logical. We had considered: ACID - Accepted Client Identifier, Authentication Control ID (But ACID was ruled out, just becuase we thought it would not be taken seriously, however open to comments on that) DID - Device Identifier (Possible Confusion as well) Some other things that come to mind.. PDID - Personal Device Identifier DCID - Device Class Identifier PDID seems to reflect the conceptual idea of a 'personal device' which can be linked to the person who is the owner of the resource that is being accessed.. but it can also be argued that it may be confusing with the ID verb .. I do like it in essence though. Feedback welcome.... -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Mon Jul 23 15:52:13 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C82130E2E for ; Mon, 23 Jul 2018 15:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 A6-MDPOm66ZT for ; Mon, 23 Jul 2018 15:52:10 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 C1F13130E26 for ; Mon, 23 Jul 2018 15:52:10 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV7T74B28W0002BI@mauve.mrochek.com> for extra@ietf.org; Mon, 23 Jul 2018 15:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532386022; bh=8prWhqLnP6RGq8L8O+44D2OaJUJEkuErJWCPLFCQbFU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=rjhIhghLUG1RYOkg1j/C38uFox5pdGQh7eXqMFzoyE+RyG9KcS4QKTEsOtDRuKO/g dZk/A2O4hRbM0y5WxfLQ3rUSIKHavaq5h48BUNYALjaLr7guKc9eN1KEPoA23WAZxS sC6Htlg9UuT6muw8Ut3eYLcTGkknHSggwF+jgIsg= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV7GRS9SI800004G@mauve.mrochek.com>; Mon, 23 Jul 2018 15:46:52 -0700 (PDT) Cc: extra@ietf.org, ned.freed@mrochek.com Message-id: <01QV7T6X9OJ800004G@mauve.mrochek.com> Date: Mon, 23 Jul 2018 15:29:27 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 21 Jul 2018 11:33:12 -0400" <20180721153313.44F5C200288316@ary.qy> References: <01QV33SLJJQA000051@mauve.mrochek.com> <20180721153313.44F5C200288316@ary.qy> To: John Levine Archived-At: Subject: Re: [Extra] client-id next steps - let's find them a home X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 22:52:13 -0000 > In article <01QV33SLJJQA000051@mauve.mrochek.com> you write: > >More specificially, a client certificate could be included in the TLS exchange > >and then used for this purpose. It could be self-generated and self-signed, > >it could be acquired through the use of ACME or some other protocol - lots > >of possibilities there, including the abiity to revoke it. > This is a very good point. Clients could start sending self-signed > client certs in the TLS handshalke today with no protocol changes at > all. Hmmn. Keep in mind that the way client certificates work is that the server has to request them with a Certificate Request message. The client then responds with a Client Certificate message, which can be empty if the client has no certificates to offer. It's then up to the server if it want to proceed in the case where the client provides no certificates. (This is for TLS 1.2. Other versions may differ but I really don't care about trying to support any of this on old versions of TLS.) > There is the usual crudware problems since I would guess there is too > much code that would barf on that, either fail because it's not > expecting a cert, or never debugged "this cert isn't signed by a CA I > trust therefore it is bad." Any mail server that supports AUTH EXTERNAL binding to a client certificate is already doing this dance. And I'm dubious that servers that support this option turn off the client certificate request when AUTH EXTERNAL is not enabled. Additionally, I suspect that the code paths for this are reasonably well debugged in the more popular SSL/TLS libraries most people use. To put this another way, while there may be implementation issues, I don't expect the changes necessary for a server to request such a certificate to break existing clients. Of course this doesn't address the issue of getting clients deployed that suport this, especially if part of this include a mechanism for automatically loading clients with certifictes. > I have seen code that uses client certs signed by a private CA for > submit authorization. Sure. > That doesn't necessarily conflict except that > if I have two MUAs I might put the same cert on both of them so the > server can't tell them apart. I can't speak to other servers, but the way ours maps certificates to user identities is very flexible: It can require effectively an exact match with a certificate stored in LDAP or it can just key off of some identity field in the certificate. What we don't support is using a certificate to enable a subsequent authentication step. The certificate either performs the authentication step implicitly (which is then bound to the session by AUTH EXTERNAL) or it is ignored. > That's probably not a problem until it > is, e.g., one MUA is the phone I just lost. Yes, I realize that the > proper approach is to generate separate requests on each device and > sign them separately. Which IMO needs to be automated. Of course there are multiple ways to do it: The simplest being for the client to just generate a self-signed cert, send it, and have the server cache it the first time. Lots of options here, and lots of tradeoffs. Ned From nobody Mon Jul 23 15:53:53 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09282130E2E for ; Mon, 23 Jul 2018 15:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 N0AKO7EhaK_N for ; Mon, 23 Jul 2018 15:53:49 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 6EFC9126CB6 for ; Mon, 23 Jul 2018 15:53:49 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6NMrcms017247; Mon, 23 Jul 2018 22:53:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=f47+AnDeV1P7MmkVUAbLQg+Z4aiRFu3dFdodK1b6UvY=; b=GViZQ0U0w6BGNTqT8pjZcaPNB1aLH3dg4gFOG0yRso2HhefG6YcdLRFrgnZBNr95iWrN mbIVxKetP7xqs8Ti1EECXm9h9atILUeAfa5IgihsoUiHyS8LBT94YpZ1Ne9oIXU2DPxA zHvZmqQzAnOPAiR9M1eLPTJ7Fyalfk4Y68DbbBeMk+oLrszzyI76sY3d5AlS8xrLLFu6 r0t56RVbsukCWWCw2oI1AxwMDw52DLcqX81qiWe39P2pezQ+GnpgFzPgMS0EoxJgHUaP 4p/82c6xgSSW+Vx9Ca1r1VMC0Nvx2zve/wnVauqZ/11cghlUzgjGsC8xU31q7PdBnNfH yQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2kbvsnphyp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jul 2018 22:53:48 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6NMrlcV019303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jul 2018 22:53:48 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6NMrlat023473; Mon, 23 Jul 2018 22:53:47 GMT Received: from [10.145.183.90] (/10.145.183.90) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2018 15:53:46 -0700 From: "Chris Newman" To: "Michael Peddemors" Cc: extra@ietf.org Date: Mon, 23 Jul 2018 15:53:45 -0700 X-Mailer: MailMate (1.11.3r5509) Message-ID: <79A4C4F2-E4BA-4B4C-B8E0-295B7216EC9C@oracle.com> In-Reply-To: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> References: <1dc71d96-c3be-4ae3-7644-13f7accecace@linuxmagic.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8963 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807230250 Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - General Discussion Overview X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 22:53:52 -0000 On 23 Jul 2018, at 11:27, Michael Peddemors wrote: > Thanks once again for allowing us to present at the IMAP EXTRA group, > and now that everyone is back home, it is a good time to reflect on > the > discussions surrounding CID (Client ID) in IMAP, as we concluded that > there was not yet enough consensus around this, and we agreed to open > up dialogue/discussion on the list, so that we can argue for, and > hopefully gain consensus on that it should be part of this groups' > mandate. > > And I have to thank everyone for all the comments, and appreciate your > patience as we go through this process, and the 'mentor' comments from > Alexey, Bron, John and others.. It helped us better understand > separating the 'process' from the ideal of the CID proposal. > > It seemed that the group understood the later, without the need for me > to 'champion' the idea as much. I think everyone in the group > understood, and with everyone looking at or implementing methods to > allow traditional services to have the capability of at least alerting > users to when unexpected/new access to a service is detected, we > should > consider that if everyone 'sees the value of this capability', or 'is > already trying to do this', that creating a 'standard' for this is > good for everyone, and the IETF is the correct venue for setting the > standards, whether it is this working group or another. (Albeit, we > will > argue that this group is currently the right place for this based on > that the 'syntax' for IMAP is separate from all other services, and > other arguments) > > However, there were several items brought up that should be discussed > as separate issues and threads, so I propose that some of these get > discussed separate to the arguments on the correct 'home' for CID. > > Some points brought up: > > * CID Naming, several persons pointed out that this can become > confusing > as IMAP uses that type of name for other purposes. I will start a > separate thread on this topic, as it should be open for discussion. The naming conflict is with the "cid:" URL scheme defined in RFC 2392. This acronym has been in use in the mail community for over 20 years with the specific expansion "content-ID". So just don't abbreviate "client id" as "CID" to avoid confusion. > * Security Notes, it was brought up that we left the idea of what > CID Types and Tokens as open ended, and available to email client > developers to have the flexibility to make decisions on what should > be > a token. It was suggested we add more information to the security > section, eg reminding developers to consider that Cid identifiers > might be created in a way that they are unique to a hostname and/or > service. And while this isn't really part of the core draft, it > does > behoove us to have conversation on this topic, and I will pass this > on > to the author, but probably best to allow discussion on this topic. Standards exist to promote interoperability when software comes from different vendors. So the semantics of a client ID have to be specified in sufficient detail so both the client software and the server software knows what to do with it. Flexibility is fine up to a point, but "client from vendor A provides a tag+string" and "server from vendor B does something arbitrary with tag+string" is not acceptable to achieve interoperability. The semantics must be nailed down to the point where there is at least a mandatory-to-implement model that will interoperate. > * Discussion on whether the purpose of CID can be served via the ID > command (RFC2971), and a separate thread has been started on that > topic. (Thanks Timo) > > * It was questioned, is the proper place for this in a SASL mechanism, > vs in the protocol itself, and while our development work and > research > show that the advantages for a 'device identifier' to be part of the > protocol/syntax rather than a SASL, and our assertion this will help > in the adoption curve in the industry, it was one of the strongest > points of contention, with the arguments for SASL, was one SASL can > apply to many services, and thus if that argument holds, then maybe > the SASL or a security group would be better for this. We intend to > argue against this, but the topic alone is key to discussions, so it > requires a separate thread to discuss this. We have a case where client-id facilities (device-specific token, a subset of the client-id problem) were deployed in production using custom SASL mechanisms on our server and custom changes to a client. So I assert this is a proof-of-concept that SASL is deployable for client-id, that it can solve the problem for multiple protocols with one specification and shared code (Submission & IMAP), that it comes with an extensible capability model for interoperability, and does not break interoperability with unmodified clients. Furthermore, no custom changes were required to our server to support this since we have a SASL abstraction API we support. That means our customers could deploy a SASL-based mechanism without requiring a server upgrade, thus significantly simplifying deployment. We do not have an API for IMAP commands and have no intention of providing one, so our customers will not be able to deploy client ID unless it is SASL or there is an IETF rough consensus around a non-SASL client-id model for submission+imap(+pop+managesieve+jmap+etc). I consider it unfortunate this use case involved proprietary SASL mechanisms so I'd support a standardized mechanism, but we have running code showing a SASL approach is deployable and backwards compatible. I'm aware of another deployed use of client-id like facilities for push notifications. > * Outside of the meeting, mention was whether there is a reasoning > that > some form of general working group be considered that applies to all > the standard email protocols, eg SMTP (Submission Only), > IMAP/IMAP-SSL > and POP/POP-SSL etc, however that is for others way beyond me to > argue > and I prefer to leave it out of this discussion. This proposal presently covers submission+submissions services and imap+imaps services. We need to consider the architectural implications of multi-protocol support. But I don't see a reason to move this discussion to a different forum at this time. > * While it might seem like 'lobbying', it might be worth assessing who > considers the concept worth pursuing/implementing as well as having > others who are trying to solve the problem in other ways, to have a > general discussion on what they are doing, or which methods that > they > prefer, as this might aid in validating that the need has enough > people working on this that it does indeed need to be standardized. > But would like the opinions of others with more IETF experience to > determine if that conversation should be pursued here. As pointed > out > we have had conversations with other IMAP implementors that have > voiced opinions that they could see themselves implementing this. I support IETF work to address this problem in a fashion that promotes interoperability. > * Some conversation was help that the CID 'TYPE' might need to be > defined, and whether CID 'TYPE' should be become 'registered' types, > if indeed standardization is the goal, and while the suggestion is > appreciated, sounds like putting the cart in front of the horse, and > whether it would be better to let IMAP client developers have more > freedom. I think this can be left until later in the discussions. Since this group tends to be very applied (as in shipping code), I think you'd do better if you at least provided more concrete examples of how to use client id in an interoperable fashion. SASL is a great example -- there are a small number of deployed standard mechanisms (PLAIN, EXTERNAL, GSSAPI/Kerberos to a lesser extent) but proprietary/custom mechanisms are allowed. - Chris > In summary, the first four (4) bullet points, would be better > discussed > separately, and I will be following up in separate threads to the > list. > As pointed out, we strongly believe that CID goes beyond the mandate > of > SASL mechanisms, but it is obvious that is the fundamental point of > contention that needs to be resolved and argued, as our perceived > importance of it being outside of SASL has at least not yet clearly > been > communicated so others can argue the merits of this, so I expect it to > be the most discussed bullet point, but we of course can continue our > own movement forward by addressing the other points in the mean time, > including draft updates, and our own implementations. > > Once again, we thank all for their comments and their support, as we > work through this process. From nobody Mon Jul 23 17:44:44 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F19130E91 for ; Mon, 23 Jul 2018 17:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=bFj+aVMJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qMFrTm2u 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 qE6dYzAFdA_b for ; Mon, 23 Jul 2018 17:44:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B46130E71 for ; Mon, 23 Jul 2018 17:44:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 534EA21D72 for ; Mon, 23 Jul 2018 20:44:38 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 23 Jul 2018 20:44:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=H3+LJ1XMrh8ml+0ie JQGYAd/71gAlUL0Zl37FXhVtIE=; b=bFj+aVMJVBRNFNsP+9v0xe4ScHb+C2d/4 bNueXyV+0dRaQVR3aJLMK53VF17Kl6J8gBmVyCNt9D4wa+w16JMce2U1jvPbitD6 PcI7NyfjSFSsBF7MSjYF2fIksUHmDiIjJpTA0srRHstBMqS9yUzofpUXk3To/6lF 41o2mwnPPchaC6k83kDezQIvZ5iPXbZf/mxlv9pbfyeUHNjvxy6vzRUnxex/bZ3j I6qsF4XU06y7qQ4IBC3GhAPAt+z6z9oHlgRuImxvoAJanGfxJJ4XENU+WZIRysQN MMRu9jcZ7+KhJ7v1GHpyiB9UUPF/jG3NWHRAF/mb8GSt4gq9bw2QQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=H3+LJ1 XMrh8ml+0ieJQGYAd/71gAlUL0Zl37FXhVtIE=; b=qMFrTm2uNvhcr6twNDnwAI Z2ytuOxg+h5Jod4yh5Q0IITb1PeR+lS/jDoSK473E3ZQ/Gjh9vd0itYLrrENwpAx wDrL6feeLyHtdaiSFtmlxMksZd4Z7OjK0ZmqCAIFPofvMaTIp96bULaT6RPV0yjF i9BR3bwy/lyTMDNjo/abSWPKYh2a13/W2wj+F7oFm1rbpS7pfvvyVzxWkS/SY7QI +LguVvnL1Xku02HAnJ6CTrT6W+paSYvoigFe0HEWurR1g1CdQEolgpJtldsdSY+m t63572GGaOAR6ix9pa8aI9k6hq0MHgwRyarVS3V3gomV+ThitoQw2rWxcI3ulvZw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E85059E100; Mon, 23 Jul 2018 20:44:37 -0400 (EDT) Message-Id: <1532393077.1764466.1450591112.1A4B4AD7@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153239307717644662" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Tue, 24 Jul 2018 10:44:37 +1000 References: In-Reply-To: Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - Feedback on CID naming convention X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 00:44:42 -0000 This is a multi-part message in MIME format. --_----------=_153239307717644662 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, Jul 24, 2018, at 05:09, Michael Peddemors wrote: > While not having received consensus on CID as an IMAP verb, it > was good> to hear the feedback on the naming convention, as their was > concern that> it might be confused with other 'client id' nomenclature in > other RFC's> and/or with the 'cid' as used in IMAP eg, the content id, and we are > fully willing to consider a different naming convention as a standard.> > This thread is to receive input from the working group and > community as> to a naming convention that is less contentious. > > Note: Arguments for naming convention should be held ON the > assumption,> this will make it to being an IMAP VERB, which hasn't been > decided> yet, admittingly. > > While it can be argued that IMAP verbs and IMAP tags are two > completely> separate sets of identifiers, less confusion is always a good thing. > > We had considered other names to better reflect the idea of a 'device> identifier' or a 'client identifier' before as well, but CID as an > abbrevation for 'CLIENT ID' seemed logical. > > We had considered: > > ACID - Accepted Client Identifier, Authentication Control ID > (But ACID was ruled out, just becuase we thought it would not > be> taken seriously, however open to comments on that) > DID - Device Identifier (Possible Confusion as well) > > Some other things that come to mind.. > > PDID - Personal Device Identifier > DCID - Device Class Identifier > > PDID seems to reflect the conceptual idea of a 'personal device' which> can be linked to the person who is the owner of the resource that is > being accessed.. but it can also be argued that it may be > confusing with> the ID verb .. I do like it in essence though. > > Feedback welcome.... There's no law which requires it to be 4 characters or shorter. I vote for "CLIENTID" - it's clear and non-clashing. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153239307717644662 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, Jul 24, 2018, at 05:09, Michael Peddemors wrote:
While not having received consensus on CID as an IMAP verb, it was good
to hear the feedback on the naming convention, as their was concern that
it might be confused with other 'client id' nomenclature in other RFC's
and/or with the 'cid' as used in IMAP eg, the content id, and we are
fully willing to consider a different naming convention as a standard.

This thread is to receive input from the working group and community as
to a naming convention that is less contentious.

Note: Arguments for naming convention should be held ON the assumption,
      this will make it to being an IMAP VERB, which hasn't been decided
      yet, admittingly.

While it can be argued that IMAP verbs and IMAP tags are two completely
separate sets of identifiers, less confusion is always a good thing.

We had considered other names to better reflect the idea of a 'device
identifier' or a 'client identifier' before as well, but CID as an
abbrevation for 'CLIENT ID' seemed logical.

We had considered:

ACID - Accepted Client Identifier, Authentication Control ID
        (But ACID was ruled out, just becuase we thought it would not be
        taken seriously, however open to comments on that)
DID - Device Identifier (Possible Confusion as well)

Some other things that come to mind..

PDID - Personal Device Identifier
DCID - Device Class Identifier

PDID seems to reflect the conceptual idea of a 'personal device' which
can be linked to the person who is the owner of the resource that is
being accessed.. but it can also be argued that it may be confusing with
the ID verb .. I do like it in essence though.

Feedback welcome....

There's no law which requires it to be 4 characters or shorter.  I vote for "CLIENTID" - it's clear and non-clashing.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153239307717644662-- From nobody Tue Jul 24 03:19:05 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81A130F16 for ; Tue, 24 Jul 2018 03:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 2nbyP72d8zEN for ; Tue, 24 Jul 2018 03:19:02 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id D3364130DDF for ; Tue, 24 Jul 2018 03:19:01 -0700 (PDT) Received: from [192.168.10.104] (unknown [88.114.32.157]) by tss.iki.fi (Postfix) with ESMTPSA id BFBC22B3CF6 for ; Tue, 24 Jul 2018 10:19:00 +0000 (UTC) From: Timo Sirainen Content-Type: multipart/alternative; boundary="Apple-Mail=_DAF25804-BBE4-42A1-A931-846705E722C7" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 24 Jul 2018 13:18:58 +0300 References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> To: extra@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 10:19:05 -0000 --Apple-Mail=_DAF25804-BBE4-42A1-A931-846705E722C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Jul 2018, at 20.59, Chris Newman wrote: >=20 >> Also, the existing RFC does not address the issue of presenting that = information across a non-secure layer. >=20 > At the time 2971 was written, TLS was expensive. Now we're in a = situation where the cost of TLS is low compared to the potential = reputation/privacy risks of not using TLS. I would support revising IMAP = ID to explicitly disallow use of the command on a non-TLS channel (in = case there are compatibility issues, I'd suggest: SHOULD NOT send / = SHOULD NOT advertise unless TLS negotiated first). Unfortunately capabilities can't really change after STARTTLS, since the = tagged OK reply is done before the TLS handshake. Anyway this brings to my mind: What if the client-id was sent as a TLS = extension instead? It would then work with all protocols, regardless of = what authentication is used. Of course, might be more difficult to get = all the TLS libraries to be updated.. --Apple-Mail=_DAF25804-BBE4-42A1-A931-846705E722C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 23 Jul 2018, at 20.59, Chris Newman <chris.newman@oracle.com> wrote:

Also, = the existing RFC does not address the issue of presenting that = information across a non-secure layer.

At the time 2971 was written, = TLS was expensive. Now we're in a situation where the cost of TLS is low = compared to the potential reputation/privacy risks of not using TLS. I = would support revising IMAP ID to explicitly disallow use of the command = on a non-TLS channel (in case there are compatibility issues, I'd = suggest: SHOULD NOT send / SHOULD NOT advertise unless TLS negotiated = first).

Unfortunately capabilities can't really change after = STARTTLS, since the tagged OK reply is done before the TLS = handshake.

Anyway this brings to my mind: What if the client-id was sent = as a TLS extension instead? It would then work with all protocols, = regardless of what authentication is used. Of course, might be more = difficult to get all the TLS libraries to be updated..

= --Apple-Mail=_DAF25804-BBE4-42A1-A931-846705E722C7-- From nobody Tue Jul 24 07:17:47 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF019130DD5 for ; Tue, 24 Jul 2018 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 Qju0OqpLBOtV for ; Tue, 24 Jul 2018 07:17:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 29F92130E8B for ; Tue, 24 Jul 2018 07:17:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV8PI0TPVK0006UF@mauve.mrochek.com> for extra@ietf.org; Tue, 24 Jul 2018 07:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532441557; bh=p8aeA518lDydaGj2z55vyC1BN0kmKeZAyTjYAOT/L90=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=W9tt4CrIzy1jRl69M14QVscHXJg2t+jCPw5WHq0uU5UXzDUxz6266XX19nILFvEKA QjQ4s1wHkMqEf8GJ6giQaXL4I9sqYbVpUwiAFqsHSUA8V/sdMh+VRJwVS/Dl1LQg8n AdVAdo1EGCTZboTbITE9wdtEnAXw6jUDQS7LWm2g= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV7GRS9SI800004G@mauve.mrochek.com>; Tue, 24 Jul 2018 07:11:59 -0700 (PDT) Cc: extra@ietf.org Message-id: <01QV8PHY6O6I00004G@mauve.mrochek.com> Date: Tue, 24 Jul 2018 06:59:10 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Jul 2018 13:18:58 +0300" References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> To: Timo Sirainen Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 14:17:45 -0000 > On 23 Jul 2018, at 20.59, Chris Newman wrote: > > > >> Also, the existing RFC does not address the issue of presenting that information across a non-secure layer. > > > > At the time 2971 was written, TLS was expensive. Now we're in a situation > > where the cost of TLS is low compared to the potential reputation/privacy > > risks of not using TLS. I would support revising IMAP ID to explicitly > > disallow use of the command on a non-TLS channel (in case there are > > compatibility issues, I'd suggest: SHOULD NOT send /SHOULD NOT advertise > > unless TLS negotiated first). > Unfortunately capabilities can't really change after STARTTLS, since the > tagged OK reply is done before the TLS handshake. RFC 2595 section 2.1 says: Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. Am I missing something here? > Anyway this brings to my mind: What if the client-id was sent as a TLS > extension instead? It would then work with all protocols, regardless of what > authentication is used. Of course, might be more difficult to get all the TLS > libraries to be updated.. I think you're going to have a great deal of difficulty explaining why you need a new extension when (a) A client certificate seems to have all the necessary properties and (b) If for some reason client certificates cannot be used, the existing client authz extension probably can be. More generally, while it is fine in theory to want to define new mechanisms to do stuff, suc proposals need to be accompanied by substantive technical analysus as to why existing capabilities are insufficient to the task. Ned From nobody Tue Jul 24 07:26:03 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DEE130E8C for ; Tue, 24 Jul 2018 07:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=BccepVWR; dkim=pass (1536-bit key) header.d=taugh.com header.b=Lqmmh5Jf 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 SDxbK6p-NkGN for ; Tue, 24 Jul 2018 07:25:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6FEB6130DD5 for ; Tue, 24 Jul 2018 07:25:59 -0700 (PDT) Received: (qmail 81822 invoked from network); 24 Jul 2018 14:25:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13f9b.5b5736f5.k1807; bh=kB9rVWR9/C3e1AxPKrDVMWmCd0dbxFtiP9JNTSemZYo=; b=BccepVWRJq+XDBDRnVtZIT6zIRAL6td86Qs1AHcVZMjLknf8RvYW/j52LA7XPxitj3yz73FKefHRNAmtCBZvdgI9V8ZhH5y6WEbRu5BhpRiVI6VHI0awYlyFKgxV7+aDy5+c7XybtO+H0eogXdolNLc6XveGIocIg0egGjteeDUmblzzFJZIFxsJ7WUlTy634IwUip5EMX4wMtUPkJqaEn1koG9dlEL143FV77wJwXaLA3gIS1L+JD2lZU5gwC/Q DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13f9b.5b5736f5.k1807; bh=kB9rVWR9/C3e1AxPKrDVMWmCd0dbxFtiP9JNTSemZYo=; b=Lqmmh5Jfp8KkmyvcNksqigINdk9/hWpTlrd+s8sdCxjplGsJkOIBo6jP+rwWB9lQlPaaYEMKh9AxMnxVfDOmov0hQbq6EPp/Hnt5acdf0S8F0JeaOptWWc118fFcWJAckUAnkJ/I0/cbV2pwharLtWLnrVYukkbmB6DOe84m6j2mRsL2Zs0pWAshwh5l9BgH7vPqa5rm6Jcrz6Z1eQQYN3JXNPE1tyRSTntaKbu7T5T9Y8CaqwoKXi6iAuHT3huH Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 24 Jul 2018 14:25:57 -0000 Received: by ary.qy (Postfix, from userid 501) id E9D5B2002CE70F; Tue, 24 Jul 2018 10:25:56 -0400 (EDT) Date: 24 Jul 2018 10:25:56 -0400 Message-Id: <20180724142556.E9D5B2002CE70F@ary.qy> From: "John Levine" To: extra@ietf.org Cc: tss@iki.fi In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 14:26:01 -0000 In article you write: >Anyway this brings to my mind: What if the client-id was sent as a TLS extension instead? It would then >work with all protocols, regardless of what authentication is used. Of course, might be more difficult to >get all the TLS libraries to be updated.. How about if the client-id were sent in a self-signed client certificate? No changes needed to the libraries, just as Ned noted, the server needs to set a flag in the SSL setup asking the client to send it. It could use the cert's serial number as the client-id. R's, John From nobody Tue Jul 24 07:39:02 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C30130E0E for ; Tue, 24 Jul 2018 07:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 31xzaqAAFjKD for ; Tue, 24 Jul 2018 07:38:58 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id BA24C128BAC for ; Tue, 24 Jul 2018 07:38:58 -0700 (PDT) Received: from [192.168.10.104] (unknown [88.114.32.157]) by tss.iki.fi (Postfix) with ESMTPSA id D9D032B3CF6; Tue, 24 Jul 2018 14:38:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Timo Sirainen In-Reply-To: <01QV8PHY6O6I00004G@mauve.mrochek.com> Date: Tue, 24 Jul 2018 17:38:56 +0300 Cc: extra@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <284E95A0-D511-4267-AEDE-5381AF4C5DFE@iki.fi> References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> <01QV8PHY6O6I00004G@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 14:39:01 -0000 On 24 Jul 2018, at 16.59, Ned Freed wrote: >=20 >> On 23 Jul 2018, at 20.59, Chris Newman = wrote: > > > >>> Also, the existing RFC does not address the issue of presenting that > information across a non-secure layer. > >=20 >=20 >>> At the time 2971 was written, TLS was expensive. Now we're in a = situation >>> where the cost of TLS is low compared to the potential = reputation/privacy >>> risks of not using TLS. I would support revising IMAP ID to = explicitly >>> disallow use of the command on a non-TLS channel (in case there are >>> compatibility issues, I'd suggest: SHOULD NOT send /SHOULD NOT = advertise >>> unless TLS negotiated first). >=20 >> Unfortunately capabilities can't really change after STARTTLS, since = the >> tagged OK reply is done before the TLS handshake. >=20 > RFC 2595 section 2.1 says: >=20 > Once TLS has been started, the client MUST discard cached > information about server capabilities and SHOULD re-issue the > CAPABILITY command. This is necessary to protect against > man-in-the-middle attacks which alter the capabilities list prior > to STARTTLS. The server MAY advertise different capabilities > after STARTTLS. >=20 > Am I missing something here? Oh right, I was mainly thinking from server's point of view that it = can't push new capabilities unless client requests it. I wonder if all = clients actually do that. From nobody Tue Jul 24 07:42:48 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712A6130DC1 for ; Tue, 24 Jul 2018 07:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 TcbcqS6QzyjK for ; Tue, 24 Jul 2018 07:42:43 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4D8128BAC for ; Tue, 24 Jul 2018 07:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1532443362; d=isode.com; s=june2016; i=@isode.com; bh=LP8142d8c/9iUk+Q9UOBvHQhWZjfNfAyxW2PvP/t8Ec=; 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=Brqo9MJh4Z8zX9oZi7bzCZEwp89OdBf/ByRhhW9O0iXoz+klrOxURkeEhWN4R+WZlxkgoM 3ToMd+IVfeawV3MtGC8iPGcNwkxjYJDRlA4Y6vKEMQhs6WPZWN53x0crDqWaD/R078TCy1 /ZGw/xrfHUx8PKAyqcjlhn5V/6S9tIU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 24 Jul 2018 15:42:42 +0100 To: Timo Sirainen , Ned Freed Cc: extra@ietf.org References: <1532058952.1886016.1446876976.42C7FF3D@webmail.messagingengine.com> <01QV8PHY6O6I00004G@mauve.mrochek.com> <284E95A0-D511-4267-AEDE-5381AF4C5DFE@iki.fi> From: Alexey Melnikov Message-ID: Date: Tue, 24 Jul 2018 15:42:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <284E95A0-D511-4267-AEDE-5381AF4C5DFE@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 14:42:46 -0000 On 24/07/2018 15:38, Timo Sirainen wrote: > On 24 Jul 2018, at 16.59, Ned Freed wrote: > >>> On 23 Jul 2018, at 20.59, Chris Newman wrote: > > > >>>> Also, the existing RFC does not address the issue of presenting that >>>> information across a non-secure layer. >>>> >>>> At the time 2971 was written, TLS was expensive. Now we're in a situation >>>> where the cost of TLS is low compared to the potential reputation/privacy >>>> risks of not using TLS. I would support revising IMAP ID to explicitly >>>> disallow use of the command on a non-TLS channel (in case there are >>>> compatibility issues, I'd suggest: SHOULD NOT send /SHOULD NOT advertise >>>> unless TLS negotiated first). >>> Unfortunately capabilities can't really change after STARTTLS, since the >>> tagged OK reply is done before the TLS handshake. >> RFC 2595 section 2.1 says: >> >> Once TLS has been started, the client MUST discard cached >> information about server capabilities and SHOULD re-issue the >> CAPABILITY command. This is necessary to protect against >> man-in-the-middle attacks which alter the capabilities list prior >> to STARTTLS. The server MAY advertise different capabilities >> after STARTTLS. >> >> Am I missing something here? > Oh right, I was mainly thinking from server's point of view that it can't push new capabilities unless client requests it. I wonder if all clients actually do that. They should, as otherwise the might be unable to authenticate. (Some servers only advertise some SASL mechanisms after STARTTLS.) From nobody Tue Jul 24 07:47:47 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138C1130F03 for ; Tue, 24 Jul 2018 07:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 lXDvKgm34rlD for ; Tue, 24 Jul 2018 07:47:44 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id CE1B8130EFC for ; Tue, 24 Jul 2018 07:47:43 -0700 (PDT) Received: from [192.168.10.104] (unknown [88.114.32.157]) by tss.iki.fi (Postfix) with ESMTPSA id 195722B3CF6; Tue, 24 Jul 2018 14:47:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Timo Sirainen In-Reply-To: <20180724142556.E9D5B2002CE70F@ary.qy> Date: Tue, 24 Jul 2018 17:47:41 +0300 Cc: extra@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> References: <20180724142556.E9D5B2002CE70F@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 14:47:45 -0000 On 24 Jul 2018, at 17.25, John Levine wrote: >=20 > In article you write: >> Anyway this brings to my mind: What if the client-id was sent as a = TLS extension instead? It would then >> work with all protocols, regardless of what authentication is used. = Of course, might be more difficult to >> get all the TLS libraries to be updated.. >=20 > How about if the client-id were sent in a self-signed client > certificate? No changes needed to the libraries, just as Ned noted, > the server needs to set a flag in the SSL setup asking the client to > send it. >=20 > It could use the cert's serial number as the client-id. Some installations are using CA signed client certificates for = authentication, which would prevent the client from adding client-id = field to the cert. I guess this could still work for installations that = aren't using such client certs, but seems a bit bad to exclude this kind = of an additional security feature from installations that have gone = through all the trouble of increasing their security by using client = certs. From nobody Tue Jul 24 08:14:16 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C08E131120 for ; Tue, 24 Jul 2018 08:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0eoYVPCGbYj9 for ; Tue, 24 Jul 2018 08:14:11 -0700 (PDT) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id C0471130ECE for ; Tue, 24 Jul 2018 08:14:11 -0700 (PDT) Received: (qmail 28652 invoked from network); 24 Jul 2018 15:14:09 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (365d699e-8f54-11e8-8ece-a7f32e26fa36); Tue, 24 Jul 2018 08:14:09 -0700 To: extra@ietf.org References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <7e9f30fc-c19c-d651-990c-116190da070b@linuxmagic.com> Date: Tue, 24 Jul 2018 08:14:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 365d699e-8f54-11e8-8ece-a7f32e26fa36 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 15:14:14 -0000 On 18-07-24 07:47 AM, Timo Sirainen wrote: > On 24 Jul 2018, at 17.25, John Levine wrote: >> >> In article you write: >>> Anyway this brings to my mind: What if the client-id was sent as a TLS extension instead? It would then >>> work with all protocols, regardless of what authentication is used. Of course, might be more difficult to >>> get all the TLS libraries to be updated.. >> >> How about if the client-id were sent in a self-signed client >> certificate? No changes needed to the libraries, just as Ned noted, >> the server needs to set a flag in the SSL setup asking the client to >> send it. >> >> It could use the cert's serial number as the client-id. > > Some installations are using CA signed client certificates for authentication, which would prevent the client from adding client-id field to the cert. I guess this could still work for installations that aren't using such client certs, but seems a bit bad to exclude this kind of an additional security feature from installations that have gone through all the trouble of increasing their security by using client certs. > Which appears to suggest that using a VERB would have more universal appeal, and might be simpler to implement/adopt than using the TLS client-id field. Albeit an interesting concept .. Implementation of the 'CID' VERB could still pass the client-field in as a token and TYPE for the client-id, should an IMAP client developer chose to use this for their implementation. Servers COULD validate the string passed in as a TLSCLIENTID 'TYPE' against the actual information presented in a TLS extension should they choose to. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Tue Jul 24 09:09:53 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD09130F3B for ; Tue, 24 Jul 2018 09:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UBay0B6K; dkim=pass (1536-bit key) header.d=taugh.com header.b=X5p//6yU 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 PowlMb_064jn for ; Tue, 24 Jul 2018 09:09:49 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 1ED61131156 for ; Tue, 24 Jul 2018 09:09:48 -0700 (PDT) Received: (qmail 14229 invoked from network); 24 Jul 2018 16:09:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3790.5b574f4b.k1807; bh=916QTJyTz852OHXAClxS3Ht8oBnq/Wnd7q5txEdH+1A=; b=UBay0B6KFZzw8ePzta/N6ncUlEfdw1s1rlIyRYm4st7btSehOcfjeIw7oiLdkYKpw954yQQcIDHmB6ekK3tPAAoGktBMbzmf5goEnmp5s+ha3/dEtC02K22kWEytT/yz0lrI0fR2Roj0WyanDEd+8TuEz1sQzAJ0ExMDHFJ8DFrApNGrIUBjoA9H4g4buvRKj/WYHapGvAo551wS14L3ChZtWt5H42WQjyxyforf4EWfpxLbsOPsjF0EYBzEb0dS DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3790.5b574f4b.k1807; bh=916QTJyTz852OHXAClxS3Ht8oBnq/Wnd7q5txEdH+1A=; b=X5p//6yUY8mWGPTV5TN0NjF5Z6KqvMrZoJj+p67vZ2z3NeCVXoFAKjA3mTLIuQO980gS2En0bn4DS0aCwq8nofk/6Q00fm/TrYK9svVcUhP3YafPkJH7HVRxn5MsrnjziLjbGxquOcA95Khtjm0ctqg9bYwINAiVj8EcH8/ONVpL7HGTfq2D/M75selJADqEZ9yjdSH6B/KBgBUjeO3hukieLDN12Pp2t0ctxghllgpsc7ss3aBSxQPT0N5adlMH Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 24 Jul 2018 16:09:47 -0000 Date: 24 Jul 2018 12:09:47 -0400 Message-ID: From: "John R Levine" To: "Timo Sirainen" Cc: extra@ietf.org In-Reply-To: <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 16:09:52 -0000 On Tue, 24 Jul 2018, Timo Sirainen wrote: >> How about if the client-id were sent in a self-signed client >> certificate? No changes needed to the libraries, just as Ned noted, >> the server needs to set a flag in the SSL setup asking the client to >> send it. >> >> It could use the cert's serial number as the client-id. > > Some installations are using CA signed client certificates for > authentication, which would prevent the client from adding client-id > field to the cert. I guess this could still work for installations that > aren't using such client certs, but seems a bit bad to exclude this kind > of an additional security feature from installations that have gone > through all the trouble of increasing their security by using client > certs. Hey, I have an idea. It could use the cert's serial number as the client-id. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 24 09:11:03 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080A2130F3B for ; Tue, 24 Jul 2018 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 bDfh1XAApzyc for ; Tue, 24 Jul 2018 09:10:51 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 F180713118E for ; Tue, 24 Jul 2018 09:10:50 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV8TG3CEVK0006HG@mauve.mrochek.com> for extra@ietf.org; Tue, 24 Jul 2018 09:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532448344; bh=WlAM9R+ktoRFJsN6F7OP9q+zND7aAFZ+De7DUdMF3fQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=FK2fiVSe8H6ug3vCM2uXEW5qr+5yPqLbbPtb/5CXRwoPlOKRAUF1aRHNSdnDzUc4t MGTtDkH5vU8MC4qcrxBqYEeKI93WuNreSx/A6f5Noh6ClF25NtJo8XnNzk0kzyN3Yx AxGer/LlX4HQEnG+uOqTlaqwiFrT7V1KsSMEfIME= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV7GRS9SI800004G@mauve.mrochek.com>; Tue, 24 Jul 2018 09:04:58 -0700 (PDT) Cc: John Levine , extra@ietf.org Message-id: <01QV8TG0OR9A00004G@mauve.mrochek.com> Date: Tue, 24 Jul 2018 08:53:42 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Jul 2018 17:47:41 +0300" <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> To: Timo Sirainen Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 16:11:01 -0000 > On 24 Jul 2018, at 17.25, John Levine wrote: > > > > In article you write: > >> Anyway this brings to my mind: What if the client-id was sent as a TLS extension instead? It would then > >> work with all protocols, regardless of what authentication is used. Of course, might be more difficult to > >> get all the TLS libraries to be updated.. > > > > How about if the client-id were sent in a self-signed client > > certificate? No changes needed to the libraries, just as Ned noted, > > the server needs to set a flag in the SSL setup asking the client to > > send it. > > > > It could use the cert's serial number as the client-id. > Some installations are using CA signed client certificates for > authentication, which would prevent the client from adding client-id field to > the cert. Actually, it can be one in at least two ways - the client-id could be added to some field in the existing certificate, or the client certificate message could simply include both certificates. > I guess this could still work for installations that aren't using such client > certs, but seems a bit bad to exclude this kind of an additional security > feature from installations that have gone through all the trouble of increasing > their security by using client certs. As I explained previously, the mapping of client certificates to a user identity has to be done regardless, nothing prevents a many-to-1 mapping from being implemented, and at least some implementations already support it. Ned From nobody Tue Jul 24 09:29:12 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9ACF130EE7 for ; Tue, 24 Jul 2018 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 cSIK1Fftk92Z for ; Tue, 24 Jul 2018 09:29:08 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFFF128CF3 for ; Tue, 24 Jul 2018 09:29:08 -0700 (PDT) Received: from [192.168.10.104] (unknown [88.114.32.157]) by tss.iki.fi (Postfix) with ESMTPSA id 40FD52B3CF6; Tue, 24 Jul 2018 16:29:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Timo Sirainen In-Reply-To: Date: Tue, 24 Jul 2018 19:29:05 +0300 Cc: extra@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04FECC03-274C-4932-86CA-A994F7A4BD9D@iki.fi> References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> To: John R Levine X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 16:29:11 -0000 On 24 Jul 2018, at 19.09, John R Levine wrote: >=20 > On Tue, 24 Jul 2018, Timo Sirainen wrote: >>> How about if the client-id were sent in a self-signed client >>> certificate? No changes needed to the libraries, just as Ned noted, >>> the server needs to set a flag in the SSL setup asking the client to >>> send it. >>>=20 >>> It could use the cert's serial number as the client-id. >>=20 >> Some installations are using CA signed client certificates for = authentication, which would prevent the client from adding client-id = field to the cert. I guess this could still work for installations that = aren't using such client certs, but seems a bit bad to exclude this kind = of an additional security feature from installations that have gone = through all the trouble of increasing their security by using client = certs. >=20 > Hey, I have an idea. It could use the cert's serial number as the = client-id. I don't think it's really a client-id anymore if the user can simply = copy their client certificate to another device. Which is what I'd = expect to happen much more often than the user requesting a new = certificate whenever they change a phone/laptop/etc. From nobody Tue Jul 24 09:45:39 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0779130EA4 for ; Tue, 24 Jul 2018 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=JdQtnIJb; dkim=pass (1536-bit key) header.d=taugh.com header.b=YjXoYHdU 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 xeXtoJND79sU for ; Tue, 24 Jul 2018 09:45:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2F3DD130EF1 for ; Tue, 24 Jul 2018 09:45:31 -0700 (PDT) Received: (qmail 27691 invoked from network); 24 Jul 2018 16:45:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6c28.5b5757a7.k1807; bh=0TNGmrGQjU41OnNhWQydmAcA+5cd0FrVFbGF9L3heL0=; b=JdQtnIJbZX3Cni9RiD7gdOmqRRqZvgYrr0WwphFZMz2fiEqsaCQ1lXU8mgN2KHMN6eRan3AwIj/yHH/ib8VD9aHv1XmWicwc2r36cDq+B7uBleIajIccQVrKkf2PkBNCM4DgHDhxUru1Zr8kjb9En7F/KrA7r1z06/XEbVe9m30E1dBpwZ/Vm9jB+i1TRFHhl/e0na867Zg2yt8IMzIaUEBdtJ084gBfal8WqS/U2VnNIGJKvUN/s61QDSR5vjqu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6c28.5b5757a7.k1807; bh=0TNGmrGQjU41OnNhWQydmAcA+5cd0FrVFbGF9L3heL0=; b=YjXoYHdUkiZt6Ju/IdvJ37ZqMC+mlRMdk6q4CrhdJGLTO7DeDJPkhW5S5bp6+X5hJokV0Nn+tm+L2whlKqfunUvIIw4w3mpa+hx5vX3tLeloO9vbJZbMmopNIi4JDO+nIp292YjDaTsaBYZrVVfJMBOX5PARkwWd6GNM5XdRcuS6K5ODkFaFBZi2ldwGfXk6LeJriD4QmnApN6g0w5s25l9AxDKHf0eIa7GSZmawP5N3cVAWSb/+DIVSqAtZnZdf Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 24 Jul 2018 16:45:26 -0000 Date: 24 Jul 2018 12:45:26 -0400 Message-ID: From: "John R Levine" To: "Timo Sirainen" Cc: extra@ietf.org In-Reply-To: <04FECC03-274C-4932-86CA-A994F7A4BD9D@iki.fi> References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> <04FECC03-274C-4932-86CA-A994F7A4BD9D@iki.fi> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 16:45:38 -0000 On Tue, 24 Jul 2018, Timo Sirainen wrote: >> Hey, I have an idea. It could use the cert's serial number as the client-id. > > I don't think it's really a client-id anymore if the user can simply copy their client certificate to another device. Which is what I'd expect to happen much more often than the user requesting a new certificate whenever they change a phone/laptop/etc. How are you going to forbid that? I can make my software send any cert or ID I want. I'm sure I'm not the only person here who's extracted session cookies from a browser so I can use a site from wget. Keeping in mind the threat model here, I think that having the ID say that this client is under the same control as a client you've talked to before is good enough. Regfards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 24 10:03:22 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC5130F50 for ; Tue, 24 Jul 2018 10:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 G32RSYPNttaF for ; Tue, 24 Jul 2018 10:03:19 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 786E013115F for ; Tue, 24 Jul 2018 10:03:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV8VA1J0Y8000734@mauve.mrochek.com> for extra@ietf.org; Tue, 24 Jul 2018 09:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532451492; bh=oApE9oSabUMlY5AGSiwwfm1YUVi/UGi0NGj4bK2CEhU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=AfW0SdjoSVsM8tqdf8GBC1etx9QMldBvnxDyWUvX1zAju6GY2xosAM+cvOTVXkhE0 tUX4CTLnVRLQ1OIOYzZ83cTK1OXjGgnfjJKezvfliZF6M1ckiQ7YfQNGsolD091QKK N3WB0PlExrt9wEPNHxZJ/unHsuVvnnDfSRHAKlsM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV8U8B3HJK00004G@mauve.mrochek.com>; Tue, 24 Jul 2018 09:57:22 -0700 (PDT) Cc: Timo Sirainen , extra@ietf.org Message-id: <01QV8V9YUDSG00004G@mauve.mrochek.com> Date: Tue, 24 Jul 2018 09:50:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Jul 2018 12:45:26 -0400" References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> <04FECC03-274C-4932-86CA-A994F7A4BD9D@iki.fi> To: John R Levine Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:03:21 -0000 > On Tue, 24 Jul 2018, Timo Sirainen wrote: > >> Hey, I have an idea. It could use the cert's serial number as the client-id. > > > > I don't think it's really a client-id anymore if the user can simply copy > their client certificate to another device. Which is what I'd expect to happen > much more often than the user requesting a new certificate whenever they change > a phone/laptop/etc. This is one of the reasons why the process of setting this up has to be automated and done in the background, regardless of what the underlying technology is. As I explained previously, the simplest way to do this with certs is for the client to autogenerate a self-signed certificate on an as-needed basis. > How are you going to forbid that? I can make my software send any cert or > ID I want. I'm sure I'm not the only person here who's extracted session > cookies from a browser so I can use a site from wget. True, but there are less geeky examples. Once web sites started banning browers on the basis of the ID they send it didn't take long for a crop of browser extensions to appear to let you set the id to whatever value you like. The fact that people use such things despite the fact that web servers actually do serve up content in a browser-specific way, making these extensions more trouble than they are worth, should say something about how well enforcement in cases where there's no comparable downside is likely to work. > Keeping in mind the threat model here, I think that having the ID say that > this client is under the same control as a client you've talked to before > is good enough. It's also all you can expect. Ned From nobody Tue Jul 24 10:11:22 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97024131189 for ; Tue, 24 Jul 2018 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 CTCE55WmSJnd for ; Tue, 24 Jul 2018 10:11:10 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 AA5C81311A1 for ; Tue, 24 Jul 2018 10:11:10 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV8VJQQHRK0007CB@mauve.mrochek.com> for extra@ietf.org; Tue, 24 Jul 2018 10:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532451964; bh=AXWwpVOnzb2xiS1hMAHOyDw6IADA2xIukw8lxiFWdOE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Ilj3yhg/dYT5+KMzGtY5MPpuWU5O4PX8IGYpiA0wsQUVfMXomhC2Mlwv+7FfKBG5x Nv64/XVOzcGr1mLCeu7jKFxYCiJdAgMv+BobamuJfd6FnYiJ8xZtm+9ZHIGW5+dU8j 1IuWqEnDKVO8X/1cmzeNrH3JcQPP7KSXIaShCMIk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV8U8B3HJK00004G@mauve.mrochek.com>; Tue, 24 Jul 2018 10:05:02 -0700 (PDT) Cc: extra@ietf.org Message-id: <01QV8VJHX74Q00004G@mauve.mrochek.com> Date: Tue, 24 Jul 2018 09:58:30 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Jul 2018 08:14:08 -0700" <7e9f30fc-c19c-d651-990c-116190da070b@linuxmagic.com> References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> <7e9f30fc-c19c-d651-990c-116190da070b@linuxmagic.com> To: Michael Peddemors Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:11:20 -0000 > On 18-07-24 07:47 AM, Timo Sirainen wrote: > > On 24 Jul 2018, at 17.25, John Levine wrote: > >> > >> In article you write: > >>> Anyway this brings to my mind: What if the client-id was sent as a TLS extension instead? It would then > >>> work with all protocols, regardless of what authentication is used. Of course, might be more difficult to > >>> get all the TLS libraries to be updated.. > >> > >> How about if the client-id were sent in a self-signed client > >> certificate? No changes needed to the libraries, just as Ned noted, > >> the server needs to set a flag in the SSL setup asking the client to > >> send it. > >> > >> It could use the cert's serial number as the client-id. > > > > Some installations are using CA signed client certificates for > > authentication, which would prevent the client from adding client-id field to > > the cert. I guess this could still work for installations that aren't using > > such client certs, but seems a bit bad to exclude this kind of an additional > > security feature from installations that have gone through all the trouble of > > increasing their security by using client certs. I've already explained that this is not the case. > Which appears to suggest that using a VERB would have more universal > appeal, and might be simpler to implement/adopt than using the TLS > client-id field. Albeit an interesting concept .. It's VERBs plural, not VERB. SUBMIT at an absolute minimum. In our case there would be five new VERBs needed - IMAP4/POP3/SUBMIT/Managesieve/MTQP. All separate code. All requiring testing. And that's not even looking at the client side of things. In contrast, either a SASL level or TLS level solution can be done in common code. > Implementation of the 'CID' VERB could still pass the client-field in as > a token and TYPE for the client-id, should an IMAP client developer > chose to use this for their implementation. Servers COULD validate the > string passed in as a TLSCLIENTID 'TYPE' against the actual information > presented in a TLS extension should they choose to. Absent a cogent technical argument explaining why it's OK to ignore SUBMIT, to say nothing of the other email protocols, let's please stop claiming this can be an IMAP-only thing. Ned From nobody Tue Jul 24 11:23:39 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0544E1311BB; Tue, 24 Jul 2018 11:23:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-extra-imap-objectid@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153245661200.22504.660825322965029216.idtracker@ietfa.amsl.com> Date: Tue, 24 Jul 2018 11:23:32 -0700 Archived-At: Subject: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-imap-objectid-06=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:23:37 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-extra-imap-objectid-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd write-up says "7. There have been no IPR disclosures for this spec." which does not really answer point 7... From nobody Tue Jul 24 12:51:58 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AF7130E36 for ; Tue, 24 Jul 2018 12:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 SWqeZUkf-jUy for ; Tue, 24 Jul 2018 12:51:55 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id E4F921277C8 for ; Tue, 24 Jul 2018 12:51:54 -0700 (PDT) Received: from [192.168.10.104] (unknown [88.114.32.157]) by tss.iki.fi (Postfix) with ESMTPSA id 23A7E2B3CF6; Tue, 24 Jul 2018 19:51:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Timo Sirainen In-Reply-To: <01QV8V9YUDSG00004G@mauve.mrochek.com> Date: Tue, 24 Jul 2018 22:51:50 +0300 Cc: John R Levine , extra@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <257343B7-61F8-462F-A9EF-2C28C2B45102@iki.fi> References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> <04FECC03-274C-4932-86CA-A994F7A4BD9D@iki.fi> <01QV8V9YUDSG00004G@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 19:51:57 -0000 On 24 Jul 2018, at 19.50, Ned Freed wrote: >=20 >> On Tue, 24 Jul 2018, Timo Sirainen wrote: >> >> Hey, I have an idea. It could use the cert's serial number as the = client-id. >> > >=20 >> > I don't think it's really a client-id anymore if the user can = simply copy >> their client certificate to another device. Which is what I'd expect = to happen >> much more often than the user requesting a new certificate whenever = they change >> a phone/laptop/etc. >=20 > This is one of the reasons why the process of setting this up has to = be > automated and done in the background, regardless of what the = underlying > technology is. As I explained previously, the simplest way to do this = with > certs is for the client to autogenerate a self-signed certificate on = an > as-needed basis.=20 Sure, for self-signed certificates I agree this can be done easily and = in various nice automated ways. I just don't see this same method = working well for installations that require CA-signed certificates from = clients. >> How are you going to forbid that? I can make my software send any = cert or >> ID I want. I'm sure I'm not the only person here who's extracted = session >> cookies from a browser so I can use a site from wget. Sure, but that's not a problem.. I suppose we should first define more = precisely the purpose of this client-id feature. I'm assuming that the = main use case it's intended to help with is: - user keeps logging in with user=3Dfoo password=3Dbar client-id=3D1234 = -> ok - user's password gets leaked to attackers (because the user uses the = same password in many random web sites) - attacker attempts to login as user=3Dfoo password=3Dbar = client-id=3D3456 -> server will reject the login, maybe requiring = further validation via some web page The client-id should be such that it's not normally getting leaked along = with the password. That also makes certificate serial numbers quite bad = for this purpose, because they're easily guessed. So as for CA-signed certs, the "client-id" would have to be determined = at the time the certificate is created/signed. Doing this and = transferring the certs to the client is already quite a lot of trouble. = So when a lazy user gets a new phone, they'll just copy the old certs to = the new phone and give the old phone away. Now both the old and the new = phone has the same old valid user + password + client-id combination, so = this client-id feature doesn't bring any benefits. Compared to if the = client-id was sent some other way, the old and the new phone would have = different client-ids, which could allow server to see that the user is = using multiple clients, potentially blocking the old client-id or asking = user to verify whether it's really intentional. The user could of course = always fake the client-id with some special software to keep using the = old client-id, but what's the point? Its purpose is to make the user's = security better. From nobody Tue Jul 24 13:20:37 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61986130E02 for ; Tue, 24 Jul 2018 13:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=oUgsy+2l; dkim=pass (1536-bit key) header.d=taugh.com header.b=U9ID9QDt 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 uxfyjde56iba for ; Tue, 24 Jul 2018 13:20:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 0DFDE130DE4 for ; Tue, 24 Jul 2018 13:20:32 -0700 (PDT) Received: (qmail 27138 invoked from network); 24 Jul 2018 20:20:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=69fe.5b578a0f.k1807; bh=RfZHDhgkBBdxZotJxpyNhJMbRI0yWqBtiRPHMiAvyUM=; b=oUgsy+2liCoQRglVceTgjO5Y5DimVDZsm8t0AY/Olt2Q1NmextbcF5bfp3xu0Y3N4OUe78/p98ZEAyS7jVHPeiHXuwqDYHkhi80BY2THqzRIlZBzxnNiQ6HWpMmYbNHCzHM6quAZbk/pCn5TycoI/aiYHH5/kftH5KLeuJ1UIYlLsRxdo+oraYmks5vgzC1KBDS5j0T2V99jRlYpvYomo9O8qm+RmZzltLcCJr/8RxLDgIKNl4Mudg3aIs9TGf0j DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=69fe.5b578a0f.k1807; bh=RfZHDhgkBBdxZotJxpyNhJMbRI0yWqBtiRPHMiAvyUM=; b=U9ID9QDtCA0fCj2kEMdTF+9fPpZHqeU1OJqEsidLAJrajCGWwHibyNbWWQpk0PozzBFaTTWVQRLDHMDbr/6tqGCAP/hFS+Q+R0COqHompNaTdMBmLSwzBOZKSFW05s7mcO00jCAJBCI6OnHO+eiSqD9+YEN4JaZ/1ypzI/hxII/YH0JVFtfFOZnDujsY60zX65GCbPpPUHadpwAz054tvgppMFjb2jZ3a5OGXfaKNv/HjG3JBYmZqHWdBQwZAtGw Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 24 Jul 2018 20:20:31 -0000 Date: 24 Jul 2018 16:20:30 -0400 Message-ID: From: "John R Levine" To: "Timo Sirainen" Cc: "Ned Freed" , extra@ietf.org In-Reply-To: <257343B7-61F8-462F-A9EF-2C28C2B45102@iki.fi> References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> <04FECC03-274C-4932-86CA-A994F7A4BD9D@iki.fi> <01QV8V9YUDSG00004G@mauve.mrochek.com> <257343B7-61F8-462F-A9EF-2C28C2B45102@iki.fi> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:20:36 -0000 I agree none of this is perfect, but I would prefer not to make the perfect the enemy of the better than we have now. On Tue, 24 Jul 2018, Timo Sirainen wrote: > Sure, for self-signed certificates I agree this can be done easily and > in various nice automated ways. I just don't see this same method > working well for installations that require CA-signed certificates from > clients. True, but that is a self-inflicted wound. This isn't likely to require a signed cert anywhere that doesn't already require it for other reasons. > - attacker attempts to login as user=foo password=bar client-id=3456 -> server will reject the login, maybe requiring further validation via some web page Sounds right. > So as for CA-signed certs, the "client-id" would have to be determined > at the time the certificate is created/signed. Doing this and > transferring the certs to the client is already quite a lot of trouble. > So when a lazy user gets a new phone, they'll just copy the old certs < to the new phone and give the old phone away. Anyone who gives his phone away without wiping it is already in deeper trouble than we can fix. > The client-id should be such that it's not normally getting leaked along > with the password. That also makes certificate serial numbers quite bad > for this purpose, because they're easily guessed. It's all software. No matter what form the client-id takes, sufficiently clever malware can steal it. Stealing a cert might be marginally harder than stealing a string out of a table, certainly no easier. One minor advantage of putting the client ID in a cert is that pretty much solves the problem of credentials being sent in the clear. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 24 15:29:56 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA74F130F97 for ; Tue, 24 Jul 2018 15:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3SWx8SViKK41 for ; Tue, 24 Jul 2018 15:29:51 -0700 (PDT) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 88F78130E11 for ; Tue, 24 Jul 2018 15:29:51 -0700 (PDT) Received: (qmail 13240 invoked from network); 24 Jul 2018 22:29:50 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (13acce0c-8f91-11e8-9aea-dbb9ab00c314); Tue, 24 Jul 2018 15:29:50 -0700 To: extra@ietf.org References: <1532393077.1764466.1450591112.1A4B4AD7@webmail.messagingengine.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <1f668ec8-fd5f-5fac-ef8b-0359a6073188@linuxmagic.com> Date: Tue, 24 Jul 2018 15:29:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1532393077.1764466.1450591112.1A4B4AD7@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 13acce0c-8f91-11e8-9aea-dbb9ab00c314 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] CLIENT ID - Next Steps - Feedback on CID naming convention X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 22:29:54 -0000 On 18-07-23 05:44 PM, Bron Gondwana wrote: > On Tue, Jul 24, 2018, at 05:09, Michael Peddemors wrote: >> While not having received consensus on CID as an IMAP verb, it was good >> to hear the feedback on the naming convention, as their was concern that >> it might be confused with other 'client id' nomenclature in other RFC's >> and/or with the 'cid' as used in IMAP eg, the content id, and we are >> fully willing to consider a different naming convention as a standard. >> >> This thread is to receive input from the working group and community as >> to a naming convention that is less contentious. >> >> Note: Arguments for naming convention should be held ON the assumption, >>       this will make it to being an IMAP VERB, which hasn't been decided >>       yet, admittingly. >> >> While it can be argued that IMAP verbs and IMAP tags are two completely >> separate sets of identifiers, less confusion is always a good thing. >> >> We had considered other names to better reflect the idea of a 'device >> identifier' or a 'client identifier' before as well, but CID as an >> abbrevation for 'CLIENT ID' seemed logical. >> >> We had considered: >> >> ACID - Accepted Client Identifier, Authentication Control ID >>         (But ACID was ruled out, just becuase we thought it would not be >>         taken seriously, however open to comments on that) >> DID - Device Identifier (Possible Confusion as well) >> >> Some other things that come to mind.. >> >> PDID - Personal Device Identifier >> DCID - Device Class Identifier >> >> PDID seems to reflect the conceptual idea of a 'personal device' which >> can be linked to the person who is the owner of the resource that is >> being accessed.. but it can also be argued that it may be confusing with >> the ID verb .. I do like it in essence though. >> >> Feedback welcome.... > > There's no law which requires it to be 4 characters or shorter.  I vote > for "CLIENTID" - it's clear and non-clashing. > > Bron. Any other feedback? Our developers are working on another round of releases, and would be interesting to get more feedback, while Bron's suggestion is clear, others might think it clashes with other concepts of CLIENTID.. An acronym might make for more distinct nomenclature.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Wed Jul 25 08:30:09 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335171271FF for ; Wed, 25 Jul 2018 08:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YPjMHhZzC5te for ; Wed, 25 Jul 2018 08:30:04 -0700 (PDT) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4B12D7F8 for ; Wed, 25 Jul 2018 08:30:04 -0700 (PDT) Received: (qmail 11911 invoked from network); 25 Jul 2018 15:30:00 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (974ef436-901f-11e8-a306-db0eacda30ab); Wed, 25 Jul 2018 08:30:00 -0700 To: extra@ietf.org References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> <851290660.3102.1532109685791@appsuite.open-xchange.com> <1532112380.4163630.1447645088.2ED758B0@webmail.messagingengine.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Wed, 25 Jul 2018 08:29:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1532112380.4163630.1447645088.2ED758B0@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 974ef436-901f-11e8-a306-db0eacda30ab X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:30:08 -0000 +1 on supporting the concept of retrieving a 'SNIPPET', however I also do not see that 'LAZY' is beneficial, and I think that by separating that out of this proposal, might help to bring about a quicker 'consensus'.. I do however believe that the working group might assist in adding some more context to the proposal, eg defining exactly what a 'snippet' is, or whether to support 'types' of snippets. It seems that in the draft, it strongly hints that the 'snippet' should be the first few lines of the first text part. The idea of 'fuzzy' is such that the server decides what the text is should return, but I think it would be helpful to include further information on standardized algorithms.. Just tossing ideas out.. Eg, do we return 'No Plain Text Part, HTML Only' as a snippet? Should HTML parts be parsed to return some context? Should a standardized 'snippet' be returned, if the message only includes one part, say an image, an .ics, a document? Maybe even just a couple of 'algorithm' conventions might help to increase it's value and acceptance.. We notice that it is recommended that the 'snippet-alg-ext' be registered, but maybe 'snippet-alg' and 'snippet-alg-ext' might converge.. eg all should be registered algorithms? Eg, in the sense that the FLUFFY means, 'give me what the server thinks is a snippet', versus.. 'PLAINTEXT', meaning ask the server ONLY for the plain text parts.. And of course, letting my mind wander conceptually, is the 'snippet' really an array of items, that might include 'FIRST_200_CHARS_FIRST_PART_TEXT'? Any chance what we are looking for is really a retrieval of 'META' data for messages, in a method that should be standardized and one of the pieces is the 'FIRST_200_CHARS_FIRST_PART_TEXT' I 100% agree that everyone who has been involved in doing any client design, understands the benefit of getting the 'meta data', in this case the 'snippet', rather than parsing the message at the client end to develop a 'snippet'.. and that it would be good to standardize the retrieval mechanism.. I would put myself in the camp of, 'I would not object' but maybe we can reach the submitters objective, in a more encompassing way? I believe that client developers will have an 'expectation' of what the 'FUZZY' would generate, and would not like to deal with support issues if a servers idea of what to return, is different than what they expect. I also think that expecting IMAP implementations to support 'many' types of specific 'algorithms' may be un-realistic, so everyone will just not specify the algorithm, as they would prefer to receive something than nothing.. OR, is this really 'please return me meta data of message' known as 'SNIPPET', which is strictly defined as 'FIRST_200_CHARS_PLAIN_TEXT_DATA' Now of course, 'meta' would be confusing, given RFC 5464, but conceptually you might get what I am suggesting.. standard algorithms to return very specific forms of meta data.. one being the first 200 characters of the plain text part, another could be returning the attachment names, another could be summary information.. I suggest that clients are going to want to see a very specific set of data returned, and should know what the returned 'snippet' is, without depending on the servers idea of what to return.. Make any sense? Worried that this might end up being, get me snippet using algorithm one, and if I get no result, try algorithm two, etc .. And then, are we faced with having to include supported algorithms in the capability advertisement? Maybe if the capability is advertised as '' where support of 'NAME>' means that a defined list of meta data be supported, where the first iteration requires the ability to return 'SNIPPET' as defined as 'FIRST_200_CHARS_PLAIN_TEXT_DATA', and in the future additional 'meta' definitions can be added .. C: E1 CAPABILITY S: * CAPABILITY IMAP4rev1 MSGMETA=SNIPPET SEARCHRES On 18-07-20 11:46 AM, Bron Gondwana wrote: > On Sat, Jul 21, 2018, at 04:01, Michael Slusarz wrote: >> The LAZY modifier was the final element added to the Snippet draft, >> and it was added specifically due to feedback from our internal >> **client** development team when implementing the base FETCH SNIPPET part. >> >> The client in this case is a (heavily-modified) JavaMail library >> running in our middleware serving our webmail and mobile UIs.  The ask >> from the client team was for LAZY modifier, since without it the >> mailbox listing was blocked from an end-user UX perspective. >> >> I don't know if this blocking behavior could be worked around by >> altering the code/IMAP commands sent -- I have a feeling with JavaMail >> that this is not the easiest ask -- but the LAZY modifier was a >> solution that worked for them and was easily implementable in both >> client and server side code. >> >> Obviously, it is up for discussion whether LAZY is generally useful to >> the community and/or the semantics of its optimal behavior, but it was >> added for a specific need and has been implemented in publicly >> released code. So this is not the case of a speculative API addition >> to solve a problem that might potentially occur, if that is the concern. > > Because we always generate snippets (we call them preview) on delivery > in our server, we probably wouldn't need LAZY, but we could also > trivially implement it. > > It seems a reasonable thing to add "I'd like snippets, but only if it's > not too much work". > >> michael >> >> p.s. Someone brought up the idea of LAZY FETCH results being sent as >> untagged FETCH responses at some point after the FETCH command was >> completed.  I dropped off the call at that point so didn't hear the >> reactions to that suggestion, but I disagree with that behavior >> because 1) it behaves differently than any other explicit FETCH >> request, where the data is immediately returned before the command is >> complete, and 2) this behavior is not desirable in a more disconnected >> mode of access that our client is implementing. > > Yeah, the room came to the same conclusion "cute idea, but unlikely to > be useful in the real world". > > Bron. > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Wed Jul 25 10:45:29 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FB4130EA9 for ; Wed, 25 Jul 2018 10:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 oFDEMp1E_Rrn for ; Wed, 25 Jul 2018 10:45:24 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 478E7130EA0 for ; Wed, 25 Jul 2018 10:45:24 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6PHi5Pm117971; Wed, 25 Jul 2018 17:45:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=e3+Ja0pFu+N9L0yZaiGC+UVdX7B3AGSUnGS0B00i7Qg=; b=yMpRAs8DzGXPzvKq8FLc+5U0EHU+LuRaSJ49Kv7M+MotzEQ5hatZetSt9pjt8idruTUt LOLxm89yENt2i3Jg5zJd5rzqXOlzystmseMG3Ggbh3DcobBXIlTzpLWBKv6I27PELgv7 cHFe4ebdCJwjBfKSqGwazWJPrvkiZMhxkNS7BPDgfCrgDBKg4mBsk7xgHlhOg1cjM7pT jsMDeWhWW2UKqKjLWy0RCH05RqngDNevXh3IqtTNrEr5s7K1L1rvCTQgOakoPC4yqING Q6r1TnyaAD/umcGgjrqCy9m/TiLUhsNfiaUNZUOBL1KEFnZ0JJmr+QHmjyNZMA9juNyb jQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2kbvsnxhbf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Jul 2018 17:45:22 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6PHjLeu024099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Jul 2018 17:45:22 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6PHjLmY006440; Wed, 25 Jul 2018 17:45:21 GMT Received: from [10.145.183.90] (/10.145.183.90) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jul 2018 10:45:21 -0700 From: "Chris Newman" To: "Michael Peddemors" Cc: extra@ietf.org Date: Wed, 25 Jul 2018 10:45:14 -0700 X-Mailer: MailMate (1.11.3r5509) Message-ID: <5106F4F7-E7A4-4A63-B166-9A0CC30C9E7D@oracle.com> In-Reply-To: References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> <851290660.3102.1532109685791@appsuite.open-xchange.com> <1532112380.4163630.1447645088.2ED758B0@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8964 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807250188 Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:45:29 -0000 There was some previous discussion on SNIPPET. It turns out to be quite = difficult to specify a precise algorithm. Should it be the first text = part? What if the first text part is a text/vcard or = text/tab-separated-values or text/vnd.ascii-art? What about = multipart/alternative? It gets complicated quickly. In the past when we've tried to get too precise with this sort of = algorithm, we ended up with an algorithm that many in the community = decided wasn't "good enough". The THREAD=3DREFERENCES algorithm in RFC = 5256 is an example of that. For servers that operate at large scale, SNIPPET has to be extracted and = cached to maximize performance. Having multiple algorithms is not = desirable as it creates either performance problems or a growing cache = size that has specialized content for different clients. FUZZY leaves this as a "quality of implementation" issue. If servers = generate lousy SNIPPETS, clients will go back to the pre-SNIPPET model = which consumes more server resources so server implementations have = incentive to improve the FUZZY algorithm to maximize deployment = efficiency. The incentives are right for FUZZY SNIPPET to get better = over time in an agile fashion, so I think it's important we don't = over-specify. - Chris On 25 Jul 2018, at 8:29, Michael Peddemors wrote: > +1 on supporting the concept of retrieving a 'SNIPPET', however I also = > do not see that 'LAZY' is beneficial, and I think that by separating = > that out of this proposal, might help to bring about a quicker = > 'consensus'.. > > I do however believe that the working group might assist in adding = > some more context to the proposal, eg defining exactly what a = > 'snippet' is, or whether to support 'types' of snippets. > > It seems that in the draft, it strongly hints that the 'snippet' = > should be the first few lines of the first text part. The idea of = > 'fuzzy' is such that the server decides what the text is should = > return, but I think it would be helpful to include further information = > on standardized algorithms.. > > Just tossing ideas out.. > > Eg, do we return 'No Plain Text Part, HTML Only' as a snippet? > Should HTML parts be parsed to return some context? > Should a standardized 'snippet' be returned, if the message only = > includes one part, say an image, an .ics, a document? > > Maybe even just a couple of 'algorithm' conventions might help to = > increase it's value and acceptance.. > > We notice that it is recommended that the 'snippet-alg-ext' be = > registered, but maybe 'snippet-alg' and 'snippet-alg-ext' might = > converge.. eg all should be registered algorithms? > > Eg, in the sense that the FLUFFY means, 'give me what the server = > thinks is a snippet', versus.. 'PLAINTEXT', meaning ask the server = > ONLY for the plain text parts.. > > And of course, letting my mind wander conceptually, is the 'snippet' = > really an array of items, that might include = > 'FIRST_200_CHARS_FIRST_PART_TEXT'? > > Any chance what we are looking for is really a retrieval of 'META' = > data for messages, in a method that should be standardized and one of = > the pieces is the 'FIRST_200_CHARS_FIRST_PART_TEXT' > > I 100% agree that everyone who has been involved in doing any client = > design, understands the benefit of getting the 'meta data', in this = > case the 'snippet', rather than parsing the message at the client end = > to develop a 'snippet'.. and that it would be good to standardize the = > retrieval mechanism.. > > I would put myself in the camp of, 'I would not object' but maybe we = > can reach the submitters objective, in a more encompassing way? > > I believe that client developers will have an 'expectation' of what = > the 'FUZZY' would generate, and would not like to deal with support = > issues if a servers idea of what to return, is different than what = > they expect. > > I also think that expecting IMAP implementations to support 'many' = > types of specific 'algorithms' may be un-realistic, so everyone will = > just not specify the algorithm, as they would prefer to receive = > something than nothing.. > > OR, is this really 'please return me meta data of message' known as = > 'SNIPPET', which is strictly defined as = > 'FIRST_200_CHARS_PLAIN_TEXT_DATA' > > Now of course, 'meta' would be confusing, given RFC 5464, but = > conceptually you might get what I am suggesting.. standard algorithms = > to return very specific forms of meta data.. one being the first 200 = > characters of the plain text part, another could be returning the = > attachment names, another could be summary information.. > > I suggest that clients are going to want to see a very specific set of = > data returned, and should know what the returned 'snippet' is, without = > depending on the servers idea of what to return.. > > Make any sense? > > Worried that this might end up being, get me snippet using algorithm = > one, and if I get no result, try algorithm two, etc .. And then, are = > we faced with having to include supported algorithms in the capability = > advertisement? > > Maybe if the capability is advertised as '' where support of = > 'NAME>' means that a defined list of meta data be supported, where the = > first iteration requires the ability to return 'SNIPPET' as defined as = > 'FIRST_200_CHARS_PLAIN_TEXT_DATA', and in the future additional 'meta' = > definitions can be added .. > > C: E1 CAPABILITY > S: * CAPABILITY IMAP4rev1 MSGMETA=3DSNIPPET SEARCHRES > > > > > > On 18-07-20 11:46 AM, Bron Gondwana wrote: >> On Sat, Jul 21, 2018, at 04:01, Michael Slusarz wrote: >>> The LAZY modifier was the final element added to the Snippet draft, = >>> and it was added specifically due to feedback from our internal = >>> **client** development team when implementing the base FETCH SNIPPET = >>> part. >>> >>> The client in this case is a (heavily-modified) JavaMail library = >>> running in our middleware serving our webmail and mobile UIs.=C2=A0 T= he = >>> ask from the client team was for LAZY modifier, since without it the = >>> mailbox listing was blocked from an end-user UX perspective. >>> >>> I don't know if this blocking behavior could be worked around by = >>> altering the code/IMAP commands sent -- I have a feeling with = >>> JavaMail that this is not the easiest ask -- but the LAZY modifier = >>> was a solution that worked for them and was easily implementable in = >>> both client and server side code. >>> >>> Obviously, it is up for discussion whether LAZY is generally useful = >>> to the community and/or the semantics of its optimal behavior, but = >>> it was added for a specific need and has been implemented in = >>> publicly released code. So this is not the case of a speculative API = >>> addition to solve a problem that might potentially occur, if that is = >>> the concern. >> >> Because we always generate snippets (we call them preview) on = >> delivery in our server, we probably wouldn't need LAZY, but we could = >> also trivially implement it. >> >> It seems a reasonable thing to add "I'd like snippets, but only if = >> it's not too much work". >> >>> michael >>> >>> p.s. Someone brought up the idea of LAZY FETCH results being sent as = >>> untagged FETCH responses at some point after the FETCH command was = >>> completed.=C2=A0 I dropped off the call at that point so didn't hear = the = >>> reactions to that suggestion, but I disagree with that behavior = >>> because 1) it behaves differently than any other explicit FETCH = >>> request, where the data is immediately returned before the command = >>> is complete, and 2) this behavior is not desirable in a more = >>> disconnected mode of access that our client is implementing. >> >> Yeah, the room came to the same conclusion "cute idea, but unlikely = >> to be useful in the real world". >> >> Bron. >> -- >> =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd >> =C2=A0 brong@fastmailteam.com >> >> >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_extra&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DxWlYsjQlERK2oz= 4FpxCSba1t3D035GeMWvncBW3LLl8&s=3Dh99Wzu74nqwqvPyYUaXRmExGLppz1oUvQR_XVan= Fols&e=3D >> > > > > -- = > "Catch the Magic of Linux..." > -----------------------------------------------------------------------= - > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at = > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.linuxmagic.co= m&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5K= fkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DxWlYsjQlERK2oz4FpxCSba1t3D035GeMW= vncBW3LLl8&s=3DCOb_ODe6Sw6kk_bnHVCsjdbHFxz-9_3NwBTalzWBDRo&e=3D = > @linuxmagic > A Wizard IT Company - For More Info = > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.wizard.ca&d=3D= DwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3rx= t1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DxWlYsjQlERK2oz4FpxCSba1t3D035GeMWvncBW3= LLl8&s=3DOFwh9Pjy5gLrc87gawbIdSwPqOOEQGHEQZCobBLJMp8&e=3D > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices = > Ltd. > -----------------------------------------------------------------------= - > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and = > intended > solely for the use of the individual or entity to which they are = > addressed. > Please note that any views or opinions presented in this email are = > solely > those of the author and are not intended to represent those of the = > company. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DxWlYsjQlERK2oz4= FpxCSba1t3D035GeMWvncBW3LLl8&s=3Dh99Wzu74nqwqvPyYUaXRmExGLppz1oUvQR_XVanF= ols&e=3D From nobody Thu Jul 26 08:15:57 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EAD130E06 for ; Thu, 26 Jul 2018 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 JL-BX6YgUb6Y for ; Thu, 26 Jul 2018 08:15:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 C01C2130DD6 for ; Thu, 26 Jul 2018 08:15:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVBK5IYDOG00065W@mauve.mrochek.com> for extra@ietf.org; Thu, 26 Jul 2018 08:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532617849; bh=7dwNnmcabL/nBBB63raESiTklJF/mcAFaKKDzA/VXS8=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=FWEGVlOXp07bExrdlmOPjxqlfkZnt/OCO9iNgp7XcL1gzH2LlPzKw9vcnS0oKmqEp mOEd0NvZEh/KXj7AFZbr5a/x8HhvcisTr21Segf+8+kc73iWXoOL0bQBl/xy8qctGW wy+0xyq1tLLmMZYs3hB32JK2ksd9qpQx0NvOXmlQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVAGSPT5EO0002TJ@mauve.mrochek.com>; Thu, 26 Jul 2018 08:10:45 -0700 (PDT) Cc: Michael Peddemors , extra@ietf.org Message-id: <01QVBK5H9F760002TJ@mauve.mrochek.com> Date: Thu, 26 Jul 2018 08:04:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 25 Jul 2018 10:45:14 -0700" <5106F4F7-E7A4-4A63-B166-9A0CC30C9E7D@oracle.com> References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> <851290660.3102.1532109685791@appsuite.open-xchange.com> <1532112380.4163630.1447645088.2ED758B0@webmail.messagingengine.com> <5106F4F7-E7A4-4A63-B166-9A0CC30C9E7D@oracle.com> To: Chris Newman Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 15:15:55 -0000 > There was some previous discussion on SNIPPET. It turns out to be quite > difficult to specify a precise algorithm. Should it be the first text > part? What if the first text part is a text/vcard or > text/tab-separated-values or text/vnd.ascii-art? What about > multipart/alternative? It gets complicated quickly. This is similar in some respects to the algorithm for header/footer insertion. Having implemented this, I can say that this is just the tip of the iceberg - you also need to deal with things like multipart/alternative nested inside of multipart/related, and vice versa. * So far I've managed to deal with it algorithmically, but if things continue down the current path it's going to require an extensible template scheme and pattern matching to do properly. Ned * This is actual observed traffic; nothing theoretical about it. From nobody Thu Jul 26 13:01:30 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E284E130EE2 for ; Thu, 26 Jul 2018 13:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 MuoIqTS9eiNo for ; Thu, 26 Jul 2018 13:01:25 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 AD5F2130EDD for ; Thu, 26 Jul 2018 13:01:25 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVBU4JSBV40006YQ@mauve.mrochek.com> for extra@ietf.org; Thu, 26 Jul 2018 12:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532634982; bh=JjIoiEo2OX48elSpzhXMehjkjYwqtagxoTtdRxOVB1k=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Cbfz2wDZQE6qObsD05wbbSaClY9n1D3p0GbuFN/JKJECLOEIGa3+YGcOAreMK3HVB WoqlVwZmR8DYH+QaHj4AkqgnzIpHTMeSBgwqkW5jWiJtQW6kwEE/8rQmX+B8ELy+EF Tl7ggAEM4WF67H/0//QDDoRzIq8U8zrgldRv2b7A= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QVAGSPT5EO0002TJ@mauve.mrochek.com>; Thu, 26 Jul 2018 12:56:17 -0700 (PDT) Cc: Ned Freed , John R Levine , extra@ietf.org Message-id: <01QVBU4HERSM0002TJ@mauve.mrochek.com> Date: Thu, 26 Jul 2018 12:17:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Jul 2018 22:51:50 +0300" <257343B7-61F8-462F-A9EF-2C28C2B45102@iki.fi> References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> <04FECC03-274C-4932-86CA-A994F7A4BD9D@iki.fi> <01QV8V9YUDSG00004G@mauve.mrochek.com> <257343B7-61F8-462F-A9EF-2C28C2B45102@iki.fi> To: Timo Sirainen Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 20:01:28 -0000 > On 24 Jul 2018, at 19.50, Ned Freed wrote: > > > >> On Tue, 24 Jul 2018, Timo Sirainen wrote: > >> >> Hey, I have an idea. It could use the cert's serial number as the client-id. > >> > > > > >> > I don't think it's really a client-id anymore if the user can simply copy > >> their client certificate to another device. Which is what I'd expect to happen > >> much more often than the user requesting a new certificate whenever they change > >> a phone/laptop/etc. > > > > This is one of the reasons why the process of setting this up has to be > > automated and done in the background, regardless of what the underlying > > technology is. As I explained previously, the simplest way to do this with > > certs is for the client to autogenerate a self-signed certificate on an > > as-needed basis. > Sure, for self-signed certificates I agree this can be done easily and in > various nice automated ways. I just don't see this same method working well for > installations that require CA-signed certificates from clients. You'll have to be much more specific as to what the issues are going to be. I'll note that nothing prevents an implementation from handling a CA-signed certificate as a self-signed one, and only using the CA-signed aspect for other purposes. > >> How are you going to forbid that? I can make my software send any cert or > >> ID I want. I'm sure I'm not the only person here who's extracted session > >> cookies from a browser so I can use a site from wget. > Sure, but that's not a problem.. I suppose we should first define more > precisely the purpose of this client-id feature. I'm assuming that the main use > case it's intended to help with is: > - user keeps logging in with user=foo password=bar client-id=1234 -> ok > - user's password gets leaked to attackers (because the user uses the same > password in many random web sites) > - attacker attempts to login as user=foo password=bar client-id=3456 -> > server will reject the login, maybe requiring further validation via some web > page I'm assuming more or less the same thing. > The client-id should be such that it's not normally getting leaked along with > the password. That also makes certificate serial numbers quite bad for this > purpose, because they're easily guessed. The first rule of using self-signed certificates is that in order to validate them you have to store and compare the entire certificate or its cryptographic equivalent, e.g., a hash. This is because by definition anyone can take the same certificate content, sign it themselves, send you that instead, and in the case of TLS use the private key they just generated to generate the client verification message. The fact that the verification is done with a signature means it's Mostly Harmless for the entire certificate to leak. Or, to put this another way, for the use-case you describe, the equivalent to the client-id is the entire certificate including the signature, not the serial number. Having said that, there are other use cases for client-id, such as communicating the type of client, that could be accomplished by putting some kind of additional identifier in the certificate, possibly in the serial number field - although since this is an integer it doesn't seem like the most friendly way to do it. But regardless of the field involved, I'm opposed to doing this sort of thing, for three reasons. I've already explained my main objection in previous messages: I think having client type information as part of this is an invitation to bad behavior. The second is that the client certificate is exposed in the clear in TLS 1.2. As such, I think putting information about the client in the certificate is a bad idea. (This is fixed in TLS 1.3, but that's a dependency we don't need.) The third is that unlike the use-case you describe, these other use-cases seem to be much more protocol-specific. And in the case of IMAP, we already have an extension to send a client-id for these purposes. > So as for CA-signed certs, the "client-id" would have to be determined at the > time the certificate is created/signed. Doing this and transferring the certs > to the client is already quite a lot of trouble. With all due respect, this statement indicates that you're seriously out of date in regards to getting certs signed. ACME has completely changed the landscape in this regard. > So when a lazy user gets a new phone, they'll just copy the old certs to the > new phone and give the old phone away. First, most users wouldn't have a clue as to how to do this. Second, this assumes there's a way to get the certificates and private keys out of the phone, and there's no reason to allow that. Third, there should be no need to do this since, again, the process should be automatic, irrespective of whether it's a self-signed or CA-signed cert. > Now both the old and the new phone has the same old valid user + password + > client-id combination, so this client-id feature doesn't bring any benefits. This would require a massive implementation botch along multiple axes. Not likely. Ned From nobody Thu Jul 26 15:39:32 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1370D13124E for ; Thu, 26 Jul 2018 15:39:31 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 F3ome8dxPgn5 for ; Thu, 26 Jul 2018 15:39:28 -0700 (PDT) Received: from mail.cityemail.com (mail-ob2.cityemail.com [104.128.152.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD481277C8 for ; Thu, 26 Jul 2018 15:39:28 -0700 (PDT) Received: (qmail 24773 invoked from network); 26 Jul 2018 22:39:27 -0000 Received: from localhost (HELO localhost) (michael@wizard.ca@127.0.0.1) by fe2.cityemail.com with (DHE-RSA-AES256-SHA encrypted) SMTP (c08ebb78-9124-11e8-a205-00188b456935); Thu, 26 Jul 2018 15:39:27 -0700 Date: Thu, 26 Jul 2018 15:39:27 -0700 To: extra@ietf.org From: Michael Message-ID: X-Mailer: Wizard PHP Mail Library 1.0 User-Agent: MagicMail-Email/0.1 X-Originating-IP: 104.128.144.8 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-MagicMail-OS: MagicMail 3.0-Devel X-MagicMail-UUID: c08ebb78-9124-11e8-a205-00188b456935 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 127.0.0.1 X-MagicMail-RegexMatch: 2 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 22:39:31 -0000 Yes, while a 'nifty' concept as pointed out when Timo first brought this up.. (And Ned's arguments back up) We have to think in terms of incremental adoption. And consider especially the client end; there are lot more client softwares that need updating than server implementations. Many 'client' softwares simply are abstracted from the TLS layer, this would be a lot harder to implement for them, and make adoption a harder sell.. And to expect 'users' to do this would be unrealistic. Consider standard clients over SSL, they simply use the OS to open the socket.. How would the opportunity present itself Also consider shared environments.. Also consider other 'secured channels' .. Sorry Timo, I think another approach will have to be considered... Back to considering expanding ID or using CLIENTID ;) (Of course, an email client can still decide to use CLIENTID PRIVCERT if that suits their purpose of what a client id should be) On Thu, 26 Jul 2018 12:17:24 -0700 (PDT) Ned Freed wrote: >> On 24 Jul 2018, at 19.50, Ned Freed wrote: >> > >> >> On Tue, 24 Jul 2018, Timo Sirainen wrote: >> >> >> Hey, I have an idea. It could use the cert's serial number as the client-id. >> >> > >> > >> >> > I don't think it's really a client-id anymore if the user can simply copy >> >> their client certificate to another device. Which is what I'd expect to happen >> >> much more often than the user requesting a new certificate whenever they change >> >> a phone/laptop/etc. >> > >> > This is one of the reasons why the process of setting this up has to be >> > automated and done in the background, regardless of what the underlying >> > technology is. As I explained previously, the simplest way to do this with >> > certs is for the client to autogenerate a self-signed certificate on an >> > as-needed basis. > >> Sure, for self-signed certificates I agree this can be done easily and in >> various nice automated ways. I just don't see this same method working well for >> installations that require CA-signed certificates from clients. > > You'll have to be much more specific as to what the issues are going to be. > I'll note that nothing prevents an implementation from handling a CA-signed > certificate as a self-signed one, and only using the CA-signed aspect for > other purposes. > >> >> How are you going to forbid that? I can make my software send any cert or >> >> ID I want. I'm sure I'm not the only person here who's extracted session >> >> cookies from a browser so I can use a site from wget. > >> Sure, but that's not a problem.. I suppose we should first define more >> precisely the purpose of this client-id feature. I'm assuming that the main use >> case it's intended to help with is: > >> - user keeps logging in with user=foo password=bar client-id=1234 -> ok > >> - user's password gets leaked to attackers (because the user uses the same >> password in many random web sites) > >> - attacker attempts to login as user=foo password=bar client-id=3456 -> >> server will reject the login, maybe requiring further validation via some web >> page > > I'm assuming more or less the same thing. > >> The client-id should be such that it's not normally getting leaked along with >> the password. That also makes certificate serial numbers quite bad for this >> purpose, because they're easily guessed. > > The first rule of using self-signed certificates is that in order to validate > them you have to store and compare the entire certificate or its cryptographic > equivalent, e.g., a hash. This is because by definition anyone can take the > same certificate content, sign it themselves, send you that instead, and in the > case of TLS use the private key they just generated to generate the client > verification message. > > The fact that the verification is done with a signature means it's Mostly > Harmless for the entire certificate to leak. > > Or, to put this another way, for the use-case you describe, the equivalent to > the client-id is the entire certificate including the signature, not the > serial number. > > Having said that, there are other use cases for client-id, such as > communicating the type of client, that could be accomplished by putting some > kind of additional identifier in the certificate, possibly in the serial number > field - although since this is an integer it doesn't seem like the most > friendly way to do it. > > But regardless of the field involved, I'm opposed to doing this sort of thing, > for three reasons. I've already explained my main objection in previous > messages: I think having client type information as part of this is an > invitation to bad behavior. > > The second is that the client certificate is exposed in the clear in TLS 1.2. > As such, I think putting information about the client in the certificate is > a bad idea. (This is fixed in TLS 1.3, but that's a dependency we don't need.) > > The third is that unlike the use-case you describe, these other use-cases > seem to be much more protocol-specific. And in the case of IMAP, we already > have an extension to send a client-id for these purposes. > >> So as for CA-signed certs, the "client-id" would have to be determined at the >> time the certificate is created/signed. Doing this and transferring the certs >> to the client is already quite a lot of trouble. > > With all due respect, this statement indicates that you're seriously out of > date in regards to getting certs signed. ACME has completely changed the > landscape in this regard. > >> So when a lazy user gets a new phone, they'll just copy the old certs to the >> new phone and give the old phone away. > > First, most users wouldn't have a clue as to how to do this. Second, this > assumes there's a way to get the certificates and private keys out of the > phone, and there's no reason to allow that. Third, there should be no need to > do this since, again, the process should be automatic, irrespective of whether > it's a self-signed or CA-signed cert. > >> Now both the old and the new phone has the same old valid user + password + >> client-id combination, so this client-id feature doesn't bring any benefits. > > This would require a massive implementation botch along multiple axes. Not > likely. > > Ned > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada From nobody Thu Jul 26 16:22:47 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90A8131263 for ; Thu, 26 Jul 2018 16:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com 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 Y34PxhF3Zo_Q for ; Thu, 26 Jul 2018 16:22:43 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B78131262 for ; Thu, 26 Jul 2018 16:22:43 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 2A6B26A29C; Fri, 27 Jul 2018 01:22:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1532647361; bh=P6ea8Hy/afmvJquGri4aKZ2tfhe932T+6ampherWi7g=; h=Date:From:To:In-Reply-To:References:Subject:From; b=TLtuyWy5DG1HHBrt6jjA3oFMW0EfvuhbJ0IfSKoAfNorb8knl6TniKFZrtHgKkvp+ 5J/FRxSqaJZCAIFtCOwk7k/kQ1GTNQQ3tbxRp4RI2nsJxIEgUJ9hN8I4mKGMrKvyDi u65IjE+dq1DpeOekY9tLtG5L6/gEsew79XUFsmnSnOrYirFGJH4lOG5f4wSOUS9xR5 2O0JoosoOQM6GOwulHNBO0OoQtAIYFBG7wmb5UF0fElruB1XyLK03972P7EaenESgK kHPbmx7nzrIdJhwhcXx11sEET/20tw3CSuGKkyYNx7w7LEssExNU2P3jT15sssWRQC HRputDPbgqBTQ== Received: from null (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 1D7E23C06F3; Fri, 27 Jul 2018 01:22:41 +0200 (CEST) Date: Thu, 26 Jul 2018 17:22:40 -0600 (MDT) From: Michael Slusarz To: Michael Peddemors , extra@ietf.org Message-ID: <1279893638.8651.1532647361056@appsuite.open-xchange.com> In-Reply-To: References: <1532034781.1793667.1446611920.5FAB04E6@webmail.messagingengine.com> <5FB10FD1-538A-4931-B7FE-5A68AECCDFD5@oracle.com> <851290660.3102.1532109685791@appsuite.open-xchange.com> <1532112380.4163630.1447645088.2ED758B0@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev11 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Call for adoption - draft-slusarz-imap-fetch-snippet X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 23:22:45 -0000 > On July 25, 2018 at 9:29 AM Michael Peddemors wrote: > > +1 on supporting the concept of retrieving a 'SNIPPET', however I also > do not see that 'LAZY' is beneficial, and I think that by separating > that out of this proposal, might help to bring about a quicker > 'consensus'.. LAZY, as it currently exists in the draft, is essentially optional. Clients don't need to use it. Servers that don't want to implement it can always return a NIL response to requests with the LAZY modifier. (Clients using SNIPPET will always need to fallback to the non-LAZY method on a LAZY miss.) The only overhead is having to parse the modifier and add the code to always return NIL. For our purposes, I believe adding full LAZY support required something like 50-100 lines of code. > I do however believe that the working group might assist in adding some > more context to the proposal, eg defining exactly what a 'snippet' is, > or whether to support 'types' of snippets. Chris summarized my thoughts on FUZZY, so I will defer to his message as my response. michael From nobody Thu Jul 26 16:47:02 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD4C131272 for ; Thu, 26 Jul 2018 16:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 p4VxeqYJS02z for ; Thu, 26 Jul 2018 16:46:58 -0700 (PDT) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5D131271 for ; Thu, 26 Jul 2018 16:46:58 -0700 (PDT) Received: (qmail 45157 invoked from network); 26 Jul 2018 23:46:55 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (2daabe7e-912e-11e8-ade2-1b90845b9384); Thu, 26 Jul 2018 16:46:55 -0700 To: extra@ietf.org References: <20180724142556.E9D5B2002CE70F@ary.qy> <2FEE0D1A-6D1A-4B0E-8F99-1E641EC2FA62@iki.fi> <7e9f30fc-c19c-d651-990c-116190da070b@linuxmagic.com> <01QV8VJHX74Q00004G@mauve.mrochek.com> <1a9df124-accb-cf9a-f5e7-c758b4dfda57@linuxmagic.com> <01QVBORCSYRA0002TJ@mauve.mrochek.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Thu, 26 Jul 2018 16:46:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <01QVBORCSYRA0002TJ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 2daabe7e-912e-11e8-ade2-1b90845b9384 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] client-id next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 23:47:01 -0000 On 18-07-26 10:13 AM, Ned Freed wrote: >> AS well, this >> working group currently is IMAP centric. > > Which is one of the reasons why the conclusion at the IETF meeting was > that no > work on this will be done in this WG. Rather, this is simply a useful > place to > have a discussion about possible solutions in this space. I might point out, that the conclusion was to discuss whether it SHOULD be discussed in this WG, and that discussion is still to reach a conclusion about whether it should be herein.. .... > >> IMHO the VERB method allows for a greater flexibility, but again.. that >> should be discussed on a different thread. > > That's a technical claim. Care to back it up with some analysis? > >                 Ned Yes, correct.. and that is probably what we should focus on.. * The RFC2971 (ID) is an excellent example for something that 'could' be useful across protocols, and yet was considered within the IMAP group singly * The proposed CID (Let's start calling it CLIENTID, based on previous feedback, pending a consensus for a VERB name) is very easy to implement, both in the client side and server side, and is useful for other 'value propositions'. While using it in 'collateral' information for authentication is ONE of the uses we envision for it, the CLIENTID information can also be valuable in other ways, for instance.. * those of us doing 'abuse' detection.. Based on CLIENTID being presented, and how it is presented, could be helpful additional information. * Specialized IMAP servers with custom implementations for a specific customer set, might be able to reject connections based on whether the CLIENTID TYPE presented is the TYPE of client they permit/support * Administrators, Domain Users, or end customers can specify advanced rule decisions, based on CLIENTID.. eg only allow connections from the TYPE of IMAP clients I use.. * Enforcement of specific SASL's for a given class of devices (Also good for testing, eg if CLIENTID TYPE = 'X-TEST', use a different SASL mechanism, or PLAIN TEXT only allowed for certain CLIENTID TYPES. Or to let the IMAP mechanism have conditional support based on a unique CLIENTID token.. in a shared IMAP environment. * Standardized alerting tools based on CLIENTID TYPE or TOKEN * Different Logging Mechanism's based on a CLIENTID TYPE or TOKEN * IMAP concurrency based on CLIENTID token * IMAP timeouts based on CLIENTID TYPE * Statistical analysis based on CLIENTID TYPE or TOKEN * Ability for IMAP for custom/legacy SASL or authentication layers that it is difficult to update/upgrade who might only return True/False answers * Permission choices based on CLIENTID to use certain 3rd party authentication methods in custom/proprietary IMAP scenarios * Requires updates to less SASL implementations * Authentication offloading/load balancing scenarios * Easier for IMAP client vendors to implement, vs modifying existing SASL implementations * Easier to implement standardized error conditions, vs different SASL mechanisms responsible for error conditions. * Easier for IMAP clients to recognize and respond to error conditions * Reduce load on authentication systems * Allow IMAP clients to alter behavior based on CLIENTID SUPPORTED advertisement in the IMAP handshake Sorry, but I can go on for quite a while about the possibilities of CLIENTID as a standard in IMAP, and it doesnt' take long when evaluating the various IMAP server implementations in the wild.. Let alone the IMAP clients, that to gain the same value presented in a SASL alone, to see how incremental adoption will be easier as part of the IMAP protocol itself.. And of course, in many implementations the IMAP service itself may have access to different resources that the internal or remote SASL processors may not have access to.. in order to compare the CLIENTID information to other mechanisms not related to authentication. And finally, the more distinct we keep the CLIENTID mechanism, from any authentication mechanism, the less likely that a compromise of one mechanism or the other, will result in a complete compromise of information needed to access IMAP resources.. How about we start with these ideas, and see if a discussion of these helps confirm that the best place to implement, is as an IMAP verb. * -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Thu Jul 26 23:54:51 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4847C130E73 for ; Thu, 26 Jul 2018 23:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=A0OtIDN3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LY1bcn92 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 7RR7r6-g9boe for ; Thu, 26 Jul 2018 23:54:47 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F5E130E21 for ; Thu, 26 Jul 2018 23:54:47 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 89F4E670 for ; Fri, 27 Jul 2018 02:54:46 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Fri, 27 Jul 2018 02:54:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=KXqWhabkRAw3YVhuyhVhq3S4NGpmdv1b22khy6yxl 08=; b=A0OtIDN3HsBsIdjeblr4tJxLfpPr5FDn1P3/zRjQd9N1AlcenRvE2MTkq /z4NZeFsBfNZfXRQdWkYHAyRhCe0dltex4etlCLeoBlsp0amMmpQ1zMnm0uepXO2 MZd5C7FZ8wgR/ZkWRP0NnuyEWpUqOSvK9+ywoOFtijX9QhPQgvrvYWiiYaTzKDHn F1jMh/Y52MptrALmISzvovrVhDGjpa5ZdfvJM2TRwvSU7hIGGLVnAOJODrwUYKHX xFLds/t50xVDCPe7oT6VgeSUTBzR//l+U/OUzrqI8pJk1y5h8qrL825E4aYEQGLt ZZIrXswWfttZqZwI8znhACytxyfjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=KXqWhabkRAw3YVhuyhVhq3S4NGpmdv1b22khy6yxl 08=; b=LY1bcn92nGSov27Pe13AJ6+h1UAcVSfO4Tgm09uyntMu1INA3YKBVW8N3 D6bgr4Ky2ix94XEet/Dqug9mwHNIZmC4V8VTb4Ua2Gnb/ijeI8k/kRZytjKXr2Re bjHHSUrB6ytVfjLO7KWxOv8lGB2rWGFjPPrSJthU1Q69wnq7PXaWpitTABF7u7z8 gfahZTj7ktRF1n/h169hUuqv/7qxEU9/nEhWKWfRnF9c2jrMYdnPGpn78aK+zSY1 AZW1AYel+AToYs4i2rxip4ok61FvT6dAS4+wEOyvGUGDcMi6ZzoF0qFP5hoBUKpv Vuk3VlZOiGr2tIoMQMcrinllbDdLQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C1BEDEF1B; Fri, 27 Jul 2018 02:54:45 -0400 (EDT) Message-Id: <5f4f8fcc-a501-48c8-8c84-d7dc14ccb8c8@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-98-gf10fe59-fmnext-20180727v1 x-jmap-identity-id: 56629417 In-Reply-To: <1532035639.1797314.1446624328.7ED28DB9@webmail.messagingengine.com> References: <1532035639.1797314.1446624328.7ED28DB9@webmail.messagingengine.com> Date: Fri, 27 Jul 2018 02:54:44 -0400 From: Bron Gondwana To: extra@ietf.org Content-Type: multipart/alternative; boundary=09b0ef64e394470296f678cbe687979c Archived-At: Subject: Re: [Extra] Request for feedback - OBJECTID X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 06:54:50 -0000 --09b0ef64e394470296f678cbe687979c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Anybody? If I don't get feedback to the contrary, I'll be asking Alexey to push a= head in a week with the all-new very-MUSTy objectid-06. Cheers, Bron. On Fri, Jul 20, 2018, at 07:27, Bron Gondwana wrote: > Hi All, >=20 > Thanks to Pete's very comprehensive GENART feedback, the OBJECTID spec= has changed significantly this week.=C2=A0 Basically all the SHOULDs ha= ve become MUST. >=20 > This means that any server supporting OBJECTID will have to have persi= stent storage for both EMAILID and MAILBOXID which survives rename and c= opy/move. >=20 > I'm quite happy with that - my server handles it fine, but if this wou= ld be a problem with your server, now is the time to speak up.=C2=A0 If = there are problems, we can consider multiple CAPABILITY strings, or some= thing else - but if everyone is fine with everything being MUST, we can = go ahead with something simple and much more robust/trustable for client= s. >=20 > I'll ask Alexey to hold off on progressing the spec any further until = August 3rd (2 weeks) to allow time for feedback here. >=20 > Thanks heaps! >=20 > Cheers, >=20 > Bron. >=20 > -- > =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd > =C2=A0 brong@fastmailteam.com >=20 >=20 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra >=20 -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --09b0ef64e394470296f678cbe687979c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Anybody?
<= br>
If I don't get feedback to th= e contrary, I'll be asking Alexey to push ahead in a week with the all-n= ew very-MUSTy objectid-06.
Cheers,

Bron.

On Fri, Jul 20, 2018, at 0= 7:27, Bron Gondwana wrote:
Hi All,

Th= anks to Pete's very comprehensive GENART feedback, the OBJECTID spec has= changed significantly this week.  Basically all the SHOULDs have b= ecome MUST.

This means that any server supporting OBJECTI= D will have to have persistent storage for both EMAILID and MAILBOXID wh= ich survives rename and copy/move.

I'm quite happy with t= hat - my server handles it fine, but if this would be a problem with you= r server, now is the time to speak up.  If there are problems, we c= an consider multiple CAPABILITY strings, or something else - but if ever= yone is fine with everything being MUST, we can go ahead with something = simple and much more robust/trustable for clients.

I'll as= k Alexey to hold off on progressing the spec any further until August 3r= d (2 weeks) to allow time for feedback here.

Thanks heaps= !

Cheers,

Bron.

--
  Bron Gon= dwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


_______________________________________________
Ex= tra mailing list
Extra@ietf.org
https://www.= ietf.org/mailman/listinfo/extra


--
  Bron Gondw= ana, CEO, FastMail Pty Ltd
  bron= g@fastmailteam.com


--09b0ef64e394470296f678cbe687979c-- From nobody Fri Jul 27 09:36:50 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7716A130F8E for ; Fri, 27 Jul 2018 09:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=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 PxsYdQB_5Gdm for ; Fri, 27 Jul 2018 09:36:45 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) by ietfa.amsl.com (Postfix) with ESMTP id CADB4130DE9 for ; Fri, 27 Jul 2018 09:36:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id F0AA062B2F02; Fri, 27 Jul 2018 11:36:41 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL4aDj8d2N-R; Fri, 27 Jul 2018 11:36:38 -0500 (CDT) Received: from [172.16.1.76] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 4B85B62B2EF9; Fri, 27 Jul 2018 11:36:35 -0500 (CDT) From: "Pete Resnick" To: "Bron Gondwana" Cc: extra@ietf.org Date: Fri, 27 Jul 2018 11:36:34 -0500 X-Mailer: MailMate (1.11.3r5509) Message-ID: <94206AB0-805B-4EC3-986B-26AEE9A6723F@episteme.net> In-Reply-To: <5f4f8fcc-a501-48c8-8c84-d7dc14ccb8c8@sloti22d1t06> References: <1532035639.1797314.1446624328.7ED28DB9@webmail.messagingengine.com> <5f4f8fcc-a501-48c8-8c84-d7dc14ccb8c8@sloti22d1t06> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_5A4B095C-590C-4EAE-930D-5A171197E260_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[586, 2822], "plain":[207, 1393], "uuid":"D99BA60C-DE35-42BA-A7E6-40BD3277BFDB"}] Archived-At: Subject: Re: [Extra] Request for feedback - OBJECTID X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 16:36:48 -0000 --=_MailMate_5A4B095C-590C-4EAE-930D-5A171197E260_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Just confirming: I got the notice that I should do the re-review for GenART by Tuesday for the August 2 telechat. Shall I go ahead with that now on -06? pr On 27 Jul 2018, at 1:54, Bron Gondwana wrote: > Anybody? > > If I don't get feedback to the contrary, I'll be asking Alexey to push > ahead in a week with the all-new very-MUSTy objectid-06. > > Cheers, > > Bron. > > On Fri, Jul 20, 2018, at 07:27, Bron Gondwana wrote: >> Hi All, >> >> Thanks to Pete's very comprehensive GENART feedback, the OBJECTID >> spec has changed significantly this week.  Basically all the SHOULDs >> have become MUST. >> >> This means that any server supporting OBJECTID will have to have >> persistent storage for both EMAILID and MAILBOXID which survives >> rename and copy/move. >> >> I'm quite happy with that - my server handles it fine, but if this >> would be a problem with your server, now is the time to speak up.  >> If there are problems, we can consider multiple CAPABILITY strings, >> or something else - but if everyone is fine with everything being >> MUST, we can go ahead with something simple and much more >> robust/trustable for clients. >> >> I'll ask Alexey to hold off on progressing the spec any further until >> August 3rd (2 weeks) to allow time for feedback here. >> >> Thanks heaps! >> >> Cheers, >> >> Bron. >> >> -- >>   Bron Gondwana, CEO, FastMail Pty Ltd >>   brong@fastmailteam.com >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >> > > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com --=_MailMate_5A4B095C-590C-4EAE-930D-5A171197E260_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Just confirming: I got the notice that I should do the re-= review for GenART by Tuesday for the August 2 telechat. Shall I go ahead = with that now on -06?

pr

On 27 Jul 2018, at 1:54, Bron Gondwana wrote:

Anybody?

If I don't get fee= dback to the contrary, I'll be asking Alexey to push ahead in a week with= the all-new very-MUSTy objectid-06.

Cheers,

Bron.

On Fri, Jul 20, 2018= , at 07:27, Bron Gondwana wrote:
Hi All,

Thanks to Pete's very comprehensive GENART feedback, the OBJECTID spec h= as changed significantly this week.=C2=A0 Basically all the SHOULDs have = become MUST.

This means that any server supporting OBJECTID= will have to have persistent storage for both EMAILID and MAILBOXID whic= h survives rename and copy/move.

I'm quite happy with that = - my server handles it fine, but if this would be a problem with your ser= ver, now is the time to speak up.=C2=A0 If there are problems, we can con= sider multiple CAPABILITY strings, or something else - but if everyone is= fine with everything being MUST, we can go ahead with something simple a= nd much more robust/trustable for clients.

I'll ask Alexey = to hold off on progressing the spec any further until August 3rd (2 weeks= ) to allow time for feedback here.

Thanks heaps!
<= div style=3D"font-family:Arial;">
Cheers,

Bron.

--
=C2=A0 Bron Gondwana, CEO, FastM= ail Pty Ltd
=C2=A0 brong@fastmailteam.com

___________= ____________________________________
Extra mailing list
=
Extra@ietf.org
https://www.ietf.org/mailman/list= info/extra


--
=C2=A0 B= ron Gondwana, CEO, FastMail Pty Ltd
=C2=A0 brong@fastmailte= am.com

--=_MailMate_5A4B095C-590C-4EAE-930D-5A171197E260_=-- From nobody Fri Jul 27 09:44:33 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28294130F15 for ; Fri, 27 Jul 2018 09:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 uE3HUPm5fm-s for ; Fri, 27 Jul 2018 09:44:28 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 58494130E09 for ; Fri, 27 Jul 2018 09:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1532709867; d=isode.com; s=june2016; i=@isode.com; bh=eEpH9VEPJY3sdz9mYamwoTvS5KgmvIQqiD+5uWNY5Z8=; 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=Mg/Vph6vNJGDQzx4CNAVXIq7alxqwqoQR4AD99GljMXvBW3NCyvwFOunN7taq2YrWhLUj0 jVxhBYWctN1Fq0GXY2UzixAtZme0BMGEs1IXxn5eR0iuOHNeJBfj1/HxIj5q9JMGJT+kTU t4CS3gQmBdPfw1do93VH9ZiLO4twKTw=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 27 Jul 2018 17:44:27 +0100 To: Pete Resnick , Bron Gondwana Cc: extra@ietf.org References: <1532035639.1797314.1446624328.7ED28DB9@webmail.messagingengine.com> <5f4f8fcc-a501-48c8-8c84-d7dc14ccb8c8@sloti22d1t06> <94206AB0-805B-4EC3-986B-26AEE9A6723F@episteme.net> From: Alexey Melnikov Message-ID: <3dffddc3-e97d-8bd3-79a7-9fa7e893be84@isode.com> Date: Fri, 27 Jul 2018 17:43:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <94206AB0-805B-4EC3-986B-26AEE9A6723F@episteme.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5E849C49F929BADC2215EB18" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Request for feedback - OBJECTID X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 16:44:31 -0000 --------------5E849C49F929BADC2215EB18 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 27/07/2018 17:36, Pete Resnick wrote: > Just confirming: I got the notice that I should do the re-review for=20 > GenART by Tuesday for the August 2 telechat. Shall I go ahead with=20 > that now on -06? > Yes, please! > > pr > > On 27 Jul 2018, at 1:54, Bron Gondwana wrote: > > Anybody? > > If I don't get feedback to the contrary, I'll be asking Alexey to > push ahead in a week with the all-new very-MUSTy objectid-06. > > Cheers, > > Bron. > > On Fri, Jul 20, 2018, at 07:27, Bron Gondwana wrote: >> Hi All, >> >> Thanks to Pete's very comprehensive GENART feedback, the OBJECTID >> spec has changed significantly this week.=C2=A0 Basically all the >> SHOULDs have become MUST. >> >> This means that any server supporting OBJECTID will have to have >> persistent storage for both EMAILID and MAILBOXID which survives >> rename and copy/move. >> >> I'm quite happy with that - my server handles it fine, but if >> this would be a problem with your server, now is the time to >> speak up. If there are problems, we can consider multiple >> CAPABILITY strings, or something else - but if everyone is fine >> with everything being MUST, we can go ahead with something simple >> and much more robust/trustable for clients. >> >> I'll ask Alexey to hold off on progressing the spec any further >> until August 3rd (2 weeks) to allow time for feedback here. >> >> Thanks heaps! >> >> Cheers, >> >> Bron. >> >> -- >> =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd >> =C2=A0 brong@fastmailteam.com >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >> > > -- > =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd > =C2=A0 brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra --------------5E849C49F929BADC2215EB18 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 27/07/2018 17:36, Pete Resnick wrote:

Just confirming: I got the notice that I should do the re-review for GenART by Tuesday for the August 2 telechat. Shall I go ahead with that now on -06?

Yes, please!

pr

On 27 Jul 2018, at 1:54, Bron Gondwana wrote:

Anybody?

If I don't get feedback to the contrary, I'll be asking Alexey to push ahead in a week with the all-new very-MUSTy objectid-06.

Cheers,

Bron.

On Fri, Jul 20, 2018, at 07:27, Bron Gondwana wrote:
Hi All,

Thanks to Pete's very comprehensive GENART feedback, the OBJECTID spec has changed significantly this week.=C2=A0 Basically all the SHOULDs have become MUST.

This means that any server supporting OBJECTID will have to have persistent storage for both EMAILID and MAILBOXID which survives rename and copy/move.

I'm quite happy with that - my server handles it fine, but if this would be a problem with your server, now is the time to speak up.=C2=A0 If there are problems, we can consider multiple CAPABILITY strings, or something else - but if everyone is fine with everything being MUST, we can go ahead with something simple and much more robust/trustable for clients.

I'll ask Alexey to hold off on progressing the spec any further until August 3rd (2 weeks) to allow time for feedback here.

Thanks heaps!

Cheers,

Bron.

--
=C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd


_______________________________________________
Extra mailing list


 



_______________________________________________
Extra mailing list
Extra@i=
etf.org
https://www.ietf.org/mailman/listinfo/extra

--------------5E849C49F929BADC2215EB18-- From nobody Fri Jul 27 10:57:08 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E5131054; Fri, 27 Jul 2018 10:57:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Pete Resnick To: Cc: extra@ietf.org, draft-ietf-extra-imap-objectid.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153271422661.32667.3834516374113335159@ietfa.amsl.com> Date: Fri, 27 Jul 2018 10:57:06 -0700 Archived-At: Subject: [Extra] Genart telechat review of draft-ietf-extra-imap-objectid-06 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:57:07 -0000 Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-extra-imap-objectid-06 Reviewer: Pete Resnick Review Date: 2018-07-27 IETF LC End Date: 2018-07-13 IESG Telechat date: 2018-08-02 Summary: Ready with Nits Major issues: None Minor issues: None Nits/editorial comments: Thanks for the changes responding to my review. Good work. §5.2, ¶6: OLD THREADID is optional, if the server doesn't support THREADID or is NEW THREADID is OPTIONAL; if the server doesn't support THREADID or is §5.2 ¶7: Not clear to me why the THREADID and EMAILID can't be the same. I assume given the MUST it's going to be some sort of interoperability problem, but it does seem odd. But don't change it on my account. §8.2 ¶2: s/backend object collide/backend object identifiers From nobody Fri Jul 27 19:44:10 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70115130F24 for ; Fri, 27 Jul 2018 19:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BTXej+8I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cOpxwoN1 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 i7qq5S4buDau for ; Fri, 27 Jul 2018 19:44:05 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B9012F1A5 for ; Fri, 27 Jul 2018 19:44:05 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 528F05D7 for ; Fri, 27 Jul 2018 22:44:05 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Fri, 27 Jul 2018 22:44:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=zRHHFjkBvlWb8G5PFydjrid6Zjr+KJH1mVX2S1hXf uw=; b=BTXej+8I4oifU5+FcYz41shPFtU6pV/UNk/m5uLZFYQj5Lf3D6QzDQWZp LZJR6r54miejIBbgFOH8JN2CIyiV9xjq3KhstC0Sn2B7CdcMirjyFH7Cm6XrK03g Ez6bf3aRxZnlPdlczK8U3cv/UFxbvxn31PG2Lj+SCDfri1CaiUw01tbzttvvnGiG jLTfdbIiN0Cw1NeLA6upcwXJaz+7E0m8lw+GKnd7kh3wcyl5o212BZ4gmUBPkWXG hC5I0J6x8izFPfMmLw5dBKvScSqGVZcGzf7+sHF0ZjHNDreQsLm+k+MFMxHFLe7q IBte9A5JFvMB5JAB/f6/nc/eJ6cpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=zRHHFjkBvlWb8G5PFydjrid6Zjr+K JH1mVX2S1hXfuw=; b=cOpxwoN1vbNTyaU+yDirHVmHchTZmJFkcti3//nuinBtq ljVFSc1WuVYPHQeg+bQwbBuK06w6hR6VxLq51TpVqQI4jUQTKdjFxtoIUP1+ctWC 8VEeqs4hg4VE2O8xcKcuAX9YyB8Xq8gOSAqdPcnNbIosASfdeY5w0kGbE7yElLj5 55b7YZfKsubKGm0DhxnBJN5bu/lTgC/IpqRv8eQFYEy8bFzA/HuQLaoTwYQfe2xJ Hy/3Nku1Q7XIzyXLmjdKrHgymFALhU2orWhUWqBc9R24AZz8/Y5HEBd0Z9JGq2Hh JAjOrngEVnCCXPrFOZMdSw9kX0MQ8nY8GucLy1GnQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9916B621BF; Fri, 27 Jul 2018 22:44:04 -0400 (EDT) Message-Id: <1532745844.210143.1455494624.0DC74B06@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15327458442101432" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Sat, 28 Jul 2018 12:44:04 +1000 Archived-At: Subject: Re: [Extra] Genart telechat review of draft-ietf-extra-imap-objectid-06 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 02:44:08 -0000 This is a multi-part message in MIME format. --_----------=_15327458442101432 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, Jul 28, 2018, at 03:57, Pete Resnick wrote: > Not clear to me why the THREADID and EMAILID can't be the same. I > assume given> the MUST it's going to be some sort of interoperability problem, > but it does> seem odd. But don't change it on my account. Since if they are allowed to be the same, they're likely to be the same in most cases of single emails, having them be the same will encourage cargo-cult developers to assume that they're always the same. We even added an XOR against some constant value to our server so that the EMAILID and THREADID look completely different to clients - despite the fact that we generate the THREADID from the first EMAILID, because our own devs were tempted to get lazy and guess the THREADID. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15327458442101432 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, Jul 28, 2018, at 03:57, Pete Resnick wrote:
Not clear to me why the THREADID and EMAILID can't be the same. I assume given
the MUST it's going to be some sort of interoperability problem, but it does
seem odd. But don't change it on my account.

Since if they are allowed to be the same, they're likely to be the same in most cases of single emails, having them be the same will encourage cargo-cult developers to assume that they're always the same.

We even added an XOR against some constant value to our server so that the EMAILID and THREADID look completely different to clients - despite the fact that we generate the THREADID from the first EMAILID, because our own devs were tempted to get lazy and guess the THREADID.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15327458442101432-- From nobody Mon Jul 30 09:52:20 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B20130E69; Mon, 30 Jul 2018 09:52:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-extra-imap-objectid@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153296953086.765.16314337927744340162.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2018 09:52:10 -0700 Archived-At: Subject: [Extra] Warren Kumari's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 16:52:11 -0000 Warren Kumari has entered the following ballot position for draft-ietf-extra-imap-objectid-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this - I'm really not an IMAP person, but the document seems to me to be useful and clear. I do have a question - this is either for my education or something that needs fixing / clarification :-) Section 4. MAILBOXID object identifier "The server SHOULD NOT change MAILBOXID when renaming a folder, as this loses the main benefit of having a unique identifier." All of the above things in this section talk about keeping the MAILBOXID the same when doing things to the *mailbox*, this one instead talks about *folder*; what is the difference between mailbox and folder? I did spend some time looking and found: "IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders." (RFC3501) - this didn't enlighten me much :-) Are the terms interchangeable here? If so, I'd suggest sticking with one term. (Again, I'm not an IMAP person, this may all be obvious to those schooled in the art ) Section 4.1. New response code for CREATE Syntax: "MAILBOXID" SP "(" ")" Again, this may be obvious to IMAP people, but you may want to mention ABNF somewhere before this section (it is down in Section 7) Tiny nit: 10. IANA Considerations For the second you say "with a Reference of [[THIS RFC]]." but not for the first - may be worth making them the same (hey, I did say 'twas a nit!) From nobody Mon Jul 30 09:59:41 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A82130E76; Mon, 30 Jul 2018 09:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 GPVazPJB5XAy; Mon, 30 Jul 2018 09:59:23 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7E53B13111A; Mon, 30 Jul 2018 09:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1532969959; d=isode.com; s=june2016; i=@isode.com; bh=vhPWkhMNo21pxxyur/cTXZuZ1orkyWIGoezfOQ0itrk=; 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=IpC2ydTy5qUduH2hoaaXPhr5BS00g9r71FnhMEBTIMEjCCDPC3AnjgPGOOtA/AC35vI56g YbbLL2R7VlyNHtxHVfTgTK2Qes3Or26yxznrKh9FtUjZ0y9uIUOH9a7O0gGhC3e1HMGVbZ +1Qe+8JztzCOE1hLdHUaEk1sR2/FtpM=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 30 Jul 2018 17:59:19 +0100 To: Warren Kumari , The IESG Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-imap-objectid@ietf.org, extra-chairs@ietf.org References: <153296953086.765.16314337927744340162.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: Date: Mon, 30 Jul 2018 17:59:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <153296953086.765.16314337927744340162.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] Warren Kumari's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 16:59:25 -0000 Hi Warren, On 30/07/2018 17:52, Warren Kumari wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for writing this - I'm really not an IMAP person, but the document > seems to me to be useful and clear. > > I do have a question - this is either for my education or something that needs > fixing / clarification :-) Section 4. MAILBOXID object identifier "The server > SHOULD NOT change MAILBOXID when renaming a folder, as this loses the main > benefit of having a unique identifier." All of the above things in this section > talk about keeping the MAILBOXID the same when doing things to the *mailbox*, > this one instead talks about *folder*; what is the difference between mailbox > and folder? I did spend some time looking and found: "IMAP4rev1 permits > manipulation of mailboxes (remote message folders) in a way that is > functionally equivalent to local folders." (RFC3501) - this didn't enlighten me > much :-) Are the terms interchangeable here? If so, I'd suggest sticking with > one term. (Again, I'm not an IMAP person, this may all be obvious to those > schooled in the art ) Folder and mailbox mean the same thing. RFC 3501 was using "mailbox". Users like to talk about "folders". I wish we can just make everybody use the same term, but that is not going to work ;-). I agree that consistent terminology would be good. From nobody Mon Jul 30 11:01:07 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B780D1313A5 for ; Mon, 30 Jul 2018 11:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 cHyxCKkTf1QZ for ; Mon, 30 Jul 2018 11:01:02 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CF01311D8 for ; Mon, 30 Jul 2018 10:56:40 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id o18-v6so330899wmc.0 for ; Mon, 30 Jul 2018 10:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qxwdufvlk3WmVjZcfwpmMBHtZ6etEG5HN2r2zLVv98c=; b=fL7qvdQqlp0up7kh0djNj9muiFkf9h6WQ0l+/r4Oc/nQITgZOIS7f/jSOCNgFlgmzx g3MPV8SE3Y6VVbHZ2pq6ZWDMvrvYb3NfF/kSmfnxIkUdJEoYmoEj9BwSfT9jCeHAxGWN 9q3Fl+uXT1WA9B2QTVwTQT1rqRlqbYJCXkh0UlvMl2r4pOGiOtjAeq29lS6Uq66EWLPq 2g5fvLrsdBVNv1fMU/cRldQ2f2oZmoaZW/uRRE/03PYfAH3biC9iMPhvs5Mb7MeXICYw c+zNyoAptAos73jfjFFn2vTp+A7rujxGOLIfn6x+3jVajdwo5rFUba4pbB9i7FDEuPCt ddkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qxwdufvlk3WmVjZcfwpmMBHtZ6etEG5HN2r2zLVv98c=; b=hZU/0E3kTS5wfElDOApnflAFpRxZ4OjGpg0/TK5vbm7wQlLk7rrC9E577eX908+3r7 RAFiHyk1a4kPS6kopX/B0mVm8kLaP+L6GIGkZEA2QlQaV9mAUGDyS02ZGMi3gy/Ppn/g wfG5JuoNdWDzR1XeN+WUiJd5hWo9km94U38eaL8OJnG9fcJEFvy9dt61Aas6DiFp/z/p LqLDJL9nb6xnE1oQkOuEDzCZQR5gLm+4eO6x5SKF5z07XebKvgsc1y48BJWOe/pPsDDp MCWqhZoADsCXYWLOGZxy4PTZOOI4wb4myVPGMuP8yk4sWf8SJazT1lBRDrbCI9nBlI7P uxNw== X-Gm-Message-State: AOUpUlG3wfuGTY0rep6L1FGVcl9HGq3hEnii6UCPnkN/Ok2G4HPqTdVr 21187O2AQZTUshUgU9p3B4IqZt3RfQFc54JEbpSIBw== X-Google-Smtp-Source: AAOMgpcLm+ZurjSiPTZ/OZ/jcqBpmux8Iwiq2L+ZuAjdX1hspuI67HOQ/wDLHppYkNOFBRn0TwLIGbZBTn4lZnBnadI= X-Received: by 2002:a1c:5b09:: with SMTP id p9-v6mr239230wmb.0.1532973398630; Mon, 30 Jul 2018 10:56:38 -0700 (PDT) MIME-Version: 1.0 References: <153296953086.765.16314337927744340162.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Mon, 30 Jul 2018 13:56:02 -0400 Message-ID: To: Alexey Melnikov Cc: The IESG , extra@ietf.org, yaojk , draft-ietf-extra-imap-objectid@ietf.org, extra-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] Warren Kumari's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 18:01:06 -0000 On Mon, Jul 30, 2018 at 12:59 PM Alexey Melnikov wrote: > > Hi Warren, > > On 30/07/2018 17:52, Warren Kumari wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for writing this - I'm really not an IMAP person, but the document > > seems to me to be useful and clear. > > > > I do have a question - this is either for my education or something that needs > > fixing / clarification :-) Section 4. MAILBOXID object identifier "The server > > SHOULD NOT change MAILBOXID when renaming a folder, as this loses the main > > benefit of having a unique identifier." All of the above things in this section > > talk about keeping the MAILBOXID the same when doing things to the *mailbox*, > > this one instead talks about *folder*; what is the difference between mailbox > > and folder? I did spend some time looking and found: "IMAP4rev1 permits > > manipulation of mailboxes (remote message folders) in a way that is > > functionally equivalent to local folders." (RFC3501) - this didn't enlighten me > > much :-) Are the terms interchangeable here? If so, I'd suggest sticking with > > one term. (Again, I'm not an IMAP person, this may all be obvious to those > > schooled in the art ) > Folder and mailbox mean the same thing. Excellent, thank you - see, I learnt something :-) > RFC 3501 was using "mailbox". > Users like to talk about "folders". I wish we can just make everybody > use the same term, but that is not going to work ;-). > I agree that consistent terminology would be good. Indeed. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Jul 30 14:18:45 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F57130E72; Mon, 30 Jul 2018 14:18:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-extra-imap-objectid@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153298552294.7786.11921391317659280671.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2018 14:18:42 -0700 Archived-At: Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 21:18:43 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-imap-objectid-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is pretty exciting to see; I hope that all of this, specifically THREADID, gains traction! Please use the RFC 8174 boilerplate instead of a custom variant. Section 4 nit: s/invarients/invariants/ Section 5.3 Is this valid ABNF without quotes around the literals, SP, and whatnot? Section 7 The comment lines seem to have been wrapped badly for some of these stanzas. Section 11 If a digest is used for ID generation, it must have a collision resistent property, so server implementations are advised to monitor current security research and choose secure digests. As the IDs are generated by the server, it will be possible to migrate to a new hash by just creating new IDs with the new algorithm. [...] Perhaps reword to "by just using the new algorithm when creating new IDs"; the current wording could be misread to imply that the server should even regenerate new IDs for existing messages (which is forbidden). I guess we don't really need to discuss the case of a malicious server that reuses IDs or returns incomplete search results, in this context. But if we did, there are several things that could be said. Section 13.1 Server-assigned sequence numbers can have some operational challenges with respect to power outages, crashes, restore from backup, and the like, and ensuring that the number is in fact globally unique. I guess for this case it's less catastrophic than it is for, e.g., leaf reuse in hash-based signatures (RFC 8391), so maybe the risk does not need to be called out. From nobody Tue Jul 31 06:08:45 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86A8128B14; Tue, 31 Jul 2018 06:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=QG0OIpUN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GsEzEyP7 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 uw7wHByT_5C6; Tue, 31 Jul 2018 06:07:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49B01252B7; Tue, 31 Jul 2018 06:07:44 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C4EAC21785; Tue, 31 Jul 2018 09:07:40 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 31 Jul 2018 09:07:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=7O6HKyLuKkfniSjt6oEH/dmX0iMkc ZrWW0yrHj1CMTk=; b=QG0OIpUNryfxVEqQbhw3Pw6RXbd0A5trhEd4bPcBtOJmo 0hiYUyfU48dSfUJ4IDJc2xBzd9bamhVUXAPJftYrO8CKOM196QXjm9wIKAl1fpoN oiXxVILaxJ+2V3C0j4wNHtxU8MWnIlvzduDhc0kkL7FmGmHRbZ1YR57rnPjygXS4 OKdhVrCJ4P5pKKjbZO6oEURKejmH4RYmTel0+zimhztHYBuhlbthNW/F6tDlYrQU 8cpiIaXSzikazJG79f8dl5yRjJZFNi27t+wf+ks6gWonHgljtREvGGFY0046GE9G 4HviG5Uoia+bZjqxrf79FGpNNdF7O3YTkyTSULX0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=7O6HKyLuKkfniSjt6oEH/dmX0iMkc ZrWW0yrHj1CMTk=; b=GsEzEyP7QhgLZWW+3fg+kuwrb74t6fUtZgmCBWcbcYFr8 J3j/yYrdSEkEa4AQMmBrvlaf0zoctWSxjxDlk6IquuLw8VixT8om9RGaDcBfrbKO bn9PIPZjH/pl3dBacbS/8DkAkrJwIabx5BplIAQ4uIQYTuu+HKtwL2L7R+2toCgd JNVSjkdEKnMm4LGLXfhVVY88p4d+IZ2KrG4wFfCzyAOA8mxOrzfS3CiC7/v9NSFl jF96YMU4UyEy0lCGLLPjMXW4gsvvUVBVjplWPeDV/xnLmHkgjTr9CDTvuxEDyw7y 6iWmkFLx4CNFBS3pr7Fw1C8W8zat3AouSUv4SYX+w== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BE25D621BF; Tue, 31 Jul 2018 09:07:39 -0400 (EDT) Message-Id: <1533042459.2413708.1458654120.7C8F2F3E@webmail.messagingengine.com> From: Bron Gondwana To: Warren Kumari , Alexey Melnikov Cc: The IESG , extra@ietf.org, yaojk , draft-ietf-extra-imap-objectid@ietf.org, extra-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153304245924137080" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Tue, 31 Jul 2018 23:07:39 +1000 Archived-At: Subject: Re: [Extra] Warren Kumari's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 13:07:47 -0000 This is a multi-part message in MIME format. --_----------=_153304245924137080 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, Jul 31, 2018, at 03:56, Warren Kumari wrote: > On Mon, Jul 30, 2018 at 12:59 PM Alexey Melnikov > wrote: >> >> Hi Warren, >> >> On 30/07/2018 17:52, Warren Kumari wrote: >>> ---------------------------------------------------------------- >>> ------>>> COMMENT: >>> ---------------------------------------------------------------- >>> ------>>> >>> Thank you for writing this - I'm really not an IMAP person, but the >>> document>>> seems to me to be useful and clear. >>> >>> I do have a question - this is either for my education or something >>> that needs>>> fixing / clarification :-) Section 4. MAILBOXID object identifier >>> "The server>>> SHOULD NOT change MAILBOXID when renaming a folder, as this loses >>> the main>>> benefit of having a unique identifier." All of the above things in >>> this section>>> talk about keeping the MAILBOXID the same when doing things to the >>> **mailbox**,>>> this one instead talks about **folder**; what is the difference >>> between mailbox>>> and folder? I did spend some time looking and found: "IMAP4rev1 >>> permits>>> manipulation of mailboxes (remote message folders) in a way that is>>> functionally equivalent to local folders." (RFC3501) - this didn't >>> enlighten me>>> much :-) Are the terms interchangeable here? If so, I'd suggest >>> sticking with>>> one term. (Again, I'm not an IMAP person, this may all be obvious >>> to those>>> schooled in the art ) >> Folder and mailbox mean the same thing. > > Excellent, thank you - see, I learnt something :-) > >> RFC 3501 was using "mailbox". >> Users like to talk about "folders". I wish we can just make everybody>> use the same term, but that is not going to work ;-). >> I agree that consistent terminology would be good. > > Indeed. > W Thanks for your review. I've removed folder and changed it to mailbox since the objectid is called MAILBOXID so clearly mailbox is the correct term :) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153304245924137080 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, Jul 31, 2018, at 03:56, Warren Kumari wrote:
On Mon, Jul 30, 2018 at 12:59 PM Alexey Melnikov

Hi Warren,

On 30/07/2018 17:52, Warren Kumari wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for writing this - I'm really not an IMAP person, but the document
seems to me to be useful and clear.

I do have a question - this is either for my education or something that needs
fixing / clarification :-) Section 4.  MAILBOXID object identifier "The server
SHOULD NOT change MAILBOXID when renaming a folder, as this loses the main
benefit of having a unique identifier." All of the above things in this section
talk about keeping the MAILBOXID the same when doing things to the *mailbox*,
this one instead talks about *folder*; what is the difference between mailbox
and folder? I did spend some time looking and found: "IMAP4rev1 permits
manipulation of mailboxes (remote message folders) in a way that is
functionally equivalent to local folders." (RFC3501) - this didn't enlighten me
much :-) Are the terms interchangeable here? If so, I'd suggest sticking with
one term. (Again, I'm not an IMAP person, this may all be obvious to those
schooled in the art )
Folder and mailbox mean the same thing.

Excellent, thank you - see, I learnt something :-)

RFC 3501 was using "mailbox".
Users like to talk about "folders". I wish we can just make everybody
use the same term, but that is not going to work ;-).
I agree that consistent terminology would be good.

Indeed.
W

Thanks for your review.  I've removed folder and changed it to mailbox since the objectid is called MAILBOXID so clearly mailbox is the correct term :)

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153304245924137080-- From nobody Tue Jul 31 06:28:43 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B505C130DDD for ; Tue, 31 Jul 2018 06:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=lDsDS+AL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=swpO278P 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 K9ETos8fBkkf for ; Tue, 31 Jul 2018 06:28:40 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1580C130DC2 for ; Tue, 31 Jul 2018 06:28:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 76E3021F6F for ; Tue, 31 Jul 2018 09:28:39 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 31 Jul 2018 09:28:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=j1tolF18uwt9BwIV8 weuAA77sYAaeQTP5j/Mtki7KqU=; b=lDsDS+ALKWuOHJZTtnObq1biU/qG0HXcJ ykk0i6e4aWDDwTRTAt1qPpbYtkFLKylFA/TFTgpPIB+7xCDGZyOUw86KKkzclUuV q3+BZYmVVROi8J3R+cs2Jwdn29h4x74FGTTXTYmkWd/BZJa8eGVkWIawj2Fl4fEn opDGDI/MYVOUiF+ItY40uQ1BIBrAISQ9RPkcTL7seWzOPbvgyPkYAYbyBO/3Xoiw 56njCMQ7J8hKTXieBrxVRHquH6mRvWmDXZF7fJQ12Hpkmy+maPcrCtUR3Zgrp6PJ 3IvItWDswu1yNxDqXArthm3LHPv/g7/zHSq5U+K6J7qDrGEO174uQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=j1tolF 18uwt9BwIV8weuAA77sYAaeQTP5j/Mtki7KqU=; b=swpO278Py0jrWDFJEDBtGa kdTZXUWOkk/ZAYqo/OzEkU9Qv6HddLYaMthco6FAxt1vA88CuhZO3xb2T4sOw/Ji Qe72TYXXRQqt+kObsacBM3NSTSB5791W+hFdZFoCF6JgBSYt70FpB0BgZr8tOlln CyTCbvTxV5Lyd3d9/AZ8pdCWi5tp365dh7CjYquEettj5ayVL760ZiYlKw/LBDN0 aQeHvXtvUtV08QNfAXJv7l9VKkN5gDLfp3HYJr5FASR4AjU7oBfaqz/39LdfSFno bL0xw/h32iIukgSWD/UrMv3frg2XsRSwMwNrGh7Epe5w8hf8rEfH5tuJ83jwjxOw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2F94D621BF; Tue, 31 Jul 2018 09:28:39 -0400 (EDT) Message-Id: <1533043719.2418979.1458678424.42636FEA@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153304371924189791" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e References: <153298552294.7786.11921391317659280671.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2018 23:28:39 +1000 In-Reply-To: <153298552294.7786.11921391317659280671.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 13:28:42 -0000 This is a multi-part message in MIME format. --_----------=_153304371924189791 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, Jul 31, 2018, at 07:18, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-extra-imap-objectid-06: No Objection > > When responding, please keep the subject line intact and reply to all> email addresses included in the To and CC lines. (Feel free to > cut this> introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ > > > > ----------------------------------------------------------------------> COMMENT: > ----------------------------------------------------------------------> > This is pretty exciting to see; I hope that all of this, specifically> THREADID, gains traction! Thanks :) > Please use the RFC 8174 boilerplate instead of a custom variant. Sure thing - done. > Section 4 > > nit: s/invarients/invariants/ Ta! Fixed. > Section 5.3 > > Is this valid ABNF without quotes around the literals, SP, and > whatnot? Now that's a really good point - it's kinda sloppy how it is now. On the other hand, it is spelled out clearly in the ABNF later. I'll defer to Alexey on whether it's worth going back and changing that. > Section 7 > > The comment lines seem to have been wrapped badly for some of these > stanzas. It looked beautiful in the Markdown! I've surrounded it with ``` and now it's formatting a code block which looks much better in both text and html. I'm sure the editors will make it look even more lovely by the time they've finished with it :) > Section 11 > > If a digest is used for ID generation, it must have a collision > resistent property, so server implementations are advised to monitor> current security research and choose secure digests. As the IDs are> generated by the server, it will be possible to migrate to a > new hash> by just creating new IDs with the new algorithm. [...] > > Perhaps reword to "by just using the new algorithm when creating > new IDs";> the current wording could be misread to imply that the server > should even> regenerate new IDs for existing messages (which is forbidden). I'll pay that. That's more clear. > I guess we don't really need to discuss the case of a malicious > server that> reuses IDs or returns incomplete search results, in this > context. But if> we did, there are several things that could be said. No, we really don't. A server which lies about IDs could also return different data every time for the same message. Clients always need to be somewhat defensive against rubbish on the wire. > Section 13.1 > > Server-assigned sequence numbers can have some operational > challenges with> respect to power outages, crashes, restore from backup, and the > like, and> ensuring that the number is in fact globally unique. I guess for > this case> it's less catastrophic than it is for, e.g., leaf reuse in hash-based> signatures (RFC 8391), so maybe the risk does not need to be > called out. Yeah, we discussed it in group and decided everyone already knows that to some extent for any server-set ids. Unless my AD requests a change, I'd leave this as is. Thanks again - really comprehensive and good review. I've updated the draft with the feedback I've received over the past couple of days, and I'll ask about whether the "Syntax" examples should be updated to ABNF or stay more like the bytes on the wire. Cheers, Bron -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153304371924189791 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, Jul 31, 2018, at 07:18, Benjamin Kaduk wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-imap-objectid-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is pretty exciting to see; I hope that all of this, specifically
THREADID, gains traction!

Thanks :)

Please use the RFC 8174 boilerplate instead of a custom variant.

Sure thing - done.

Section 4

nit: s/invarients/invariants/

Ta!  Fixed.

Section 5.3

Is this valid ABNF without quotes around the literals, SP, and whatnot?

Now that's a really good point - it's kinda sloppy how it is now.  On the other hand, it is spelled out clearly in the ABNF later.  I'll defer to Alexey on whether it's worth going back and changing that.

Section 7

The comment lines seem to have been wrapped badly for some of these
stanzas.

It looked beautiful in the Markdown!  I've surrounded it with ``` and now it's formatting a code block which looks much better in both text and html.  I'm sure the editors will make it look even more lovely by the time they've finished with it :)

Section 11

  If a digest is used for ID generation, it must have a collision
  resistent property, so server implementations are advised to monitor
  current security research and choose secure digests.  As the IDs are
  generated by the server, it will be possible to migrate to a new hash
  by just creating new IDs with the new algorithm. [...]

Perhaps reword to "by just using the new algorithm when creating new IDs";
the current wording could be misread to imply that the server should even
regenerate new IDs for existing messages (which is forbidden).

I'll pay that.  That's more clear.

I guess we don't really need to discuss the case of a malicious server that
reuses IDs or returns incomplete search results, in this context.  But if
we did, there are several things that could be said.

No, we really don't.  A server which lies about IDs could also return different data every time for the same message.  Clients always need to be somewhat defensive against rubbish on the wire.

Section 13.1

Server-assigned sequence numbers can have some operational challenges with
respect to power outages, crashes, restore from backup, and the like, and
ensuring that the number is in fact globally unique.  I guess for this case
it's less catastrophic than it is for, e.g., leaf reuse in hash-based
signatures (RFC 8391), so maybe the risk does not need to be called out.

Yeah, we discussed it in group and decided everyone already knows that to some extent for any server-set ids.  Unless my AD requests a change, I'd leave this as is.

Thanks again - really comprehensive and good review.  I've updated the draft with the feedback I've received over the past couple of days, and I'll ask about whether the "Syntax" examples should be updated to ABNF or stay more like the bytes on the wire.

Cheers,

Bron

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153304371924189791-- From nobody Tue Jul 31 06:29:23 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3EF130DC2; Tue, 31 Jul 2018 06:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ppHG5Sr7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S/lc8axG 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 6QFTPyMjgAbu; Tue, 31 Jul 2018 06:29:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF744127148; Tue, 31 Jul 2018 06:29:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3C31621AD2; Tue, 31 Jul 2018 09:29:00 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 31 Jul 2018 09:29:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gmspyA +D/YzQBPWVOc38szhRwukcchUvwpBgSH53flI=; b=ppHG5Sr7tOBwlapWIAvq3Z GsQj0jUeGxdMyDzhteGfaFsfzkfHWALfdB9ylm7quEYh/y9BKNY1TjwhRhu+f9T5 Gdn2zL1VE/bbBwpvH3+xi1TaYK/JvDP7HxrWd4SrFddIWCpeXv1hpdeNSL1cOvc9 w6fBYsyQz/qOCVzm+PjHP4S3rPDu9lzSuP9pz9AkpKH0Ru8PsmM10o2uNBnFcA3r YfjsPjnnu0zwp6bTty+59HNnjISVKY0yhidd41N9qUR6GWHfxM4T1rbWRemN8Tb0 crCokOEshBnTpCL8VtH0VzGacy925Uw/G/EAVri9T/H6te2gJY5IpvkBUlM1oAlw == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gmspyA +D/YzQBPWVOc38szhRwukcchUvwpBgSH53flI=; b=S/lc8axGZvtdiWluBfvOa7 xMogE2HgbkJIlSbQlVbUNAEnSjOZvU7qxL7n34ppC+uPrzY3ZET9+Lha5dXZpOYm TMVADjoO4tf0mp/6xK5pS/jNX4GiJloj5UyBfcuddA3jc2p2BbQhUumFZJYmkx86 7VPvE+2lxL+vrQnDgAlrHuZNmLYCAKuZrSIRFnzTUZn3yzZ2EHI4YD7QFB5YqoKQ PAei9CetC9CYnP+S0VOhSBGSehgYPbOFj026Sacd7Rs5SteTmmavyJnNCb74Af9J iyKxExED9i92dgociJ9zife5sm6RsZ6ZXPb6VTPjtdM1HMfJwvnBdvU0E56WC/fg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C2FC9621BF; Tue, 31 Jul 2018 09:28:59 -0400 (EDT) Message-Id: <1533043739.2419021.1458678840.405F3734@webmail.messagingengine.com> From: Bron Gondwana To: Warren Kumari , Alexey Melnikov Cc: The IESG , extra@ietf.org, yaojk , draft-ietf-extra-imap-objectid@ietf.org, extra-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153304373924190211" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e In-Reply-To: Date: Tue, 31 Jul 2018 23:28:59 +1000 References: <153296953086.765.16314337927744340162.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] Warren Kumari's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 13:29:03 -0000 This is a multi-part message in MIME format. --_----------=_153304373924190211 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, Jul 31, 2018, at 03:56, Warren Kumari wrote: > On Mon, Jul 30, 2018 at 12:59 PM Alexey Melnikov > wrote: >> >> Hi Warren, >> >> On 30/07/2018 17:52, Warren Kumari wrote: >>> ---------------------------------------------------------------- >>> ------>>> COMMENT: >>> ---------------------------------------------------------------- >>> ------>>> >>> Thank you for writing this - I'm really not an IMAP person, but the >>> document>>> seems to me to be useful and clear. >>> >>> I do have a question - this is either for my education or something >>> that needs>>> fixing / clarification :-) Section 4. MAILBOXID object identifier >>> "The server>>> SHOULD NOT change MAILBOXID when renaming a folder, as this loses >>> the main>>> benefit of having a unique identifier." All of the above things in >>> this section>>> talk about keeping the MAILBOXID the same when doing things to the >>> **mailbox**,>>> this one instead talks about **folder**; what is the difference >>> between mailbox>>> and folder? I did spend some time looking and found: "IMAP4rev1 >>> permits>>> manipulation of mailboxes (remote message folders) in a way that is>>> functionally equivalent to local folders." (RFC3501) - this didn't >>> enlighten me>>> much :-) Are the terms interchangeable here? If so, I'd suggest >>> sticking with>>> one term. (Again, I'm not an IMAP person, this may all be obvious >>> to those>>> schooled in the art ) >> Folder and mailbox mean the same thing. > > Excellent, thank you - see, I learnt something :-) > >> RFC 3501 was using "mailbox". >> Users like to talk about "folders". I wish we can just make everybody>> use the same term, but that is not going to work ;-). >> I agree that consistent terminology would be good. > > Indeed. > W Thanks for your review. I've removed folder and changed it to mailbox since the objectid is called MAILBOXID so clearly mailbox is the correct term :) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153304373924190211 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, Jul 31, 2018, at 03:56, Warren Kumari wrote:
On Mon, Jul 30, 2018 at 12:59 PM Alexey Melnikov

Hi Warren,

On 30/07/2018 17:52, Warren Kumari wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for writing this - I'm really not an IMAP person, but the document
seems to me to be useful and clear.

I do have a question - this is either for my education or something that needs
fixing / clarification :-) Section 4.  MAILBOXID object identifier "The server
SHOULD NOT change MAILBOXID when renaming a folder, as this loses the main
benefit of having a unique identifier." All of the above things in this section
talk about keeping the MAILBOXID the same when doing things to the *mailbox*,
this one instead talks about *folder*; what is the difference between mailbox
and folder? I did spend some time looking and found: "IMAP4rev1 permits
manipulation of mailboxes (remote message folders) in a way that is
functionally equivalent to local folders." (RFC3501) - this didn't enlighten me
much :-) Are the terms interchangeable here? If so, I'd suggest sticking with
one term. (Again, I'm not an IMAP person, this may all be obvious to those
schooled in the art )
Folder and mailbox mean the same thing.

Excellent, thank you - see, I learnt something :-)

RFC 3501 was using "mailbox".
Users like to talk about "folders". I wish we can just make everybody
use the same term, but that is not going to work ;-).
I agree that consistent terminology would be good.

Indeed.
W

Thanks for your review.  I've removed folder and changed it to mailbox since the objectid is called MAILBOXID so clearly mailbox is the correct term :)

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153304373924190211-- From nobody Tue Jul 31 06:32:38 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5B9127148; Tue, 31 Jul 2018 06:32:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153304395665.5520.6339181744022522819@ietfa.amsl.com> Date: Tue, 31 Jul 2018 06:32:36 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-objectid-07.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 13:32:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP Extension for object identifiers Author : Bron Gondwana Filename : draft-ietf-extra-imap-objectid-07.txt Pages : 18 Date : 2018-07-31 Abstract: This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-objectid-07 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-objectid-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-objectid-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 31 07:12:02 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827C9130DC1 for ; Tue, 31 Jul 2018 07:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 7y0SaJf32ph4 for ; Tue, 31 Jul 2018 07:12:00 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 623B212872C for ; Tue, 31 Jul 2018 07:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1533046319; d=isode.com; s=june2016; i=@isode.com; bh=yjwBGRXHZsLAtYUIQVA3ok73rWawSloNm3MNKQ+2XrQ=; 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=c9hy/DbgXu365z7aHWoSfL7VoAKys2u+ltnaFztpAl4YVljyDmOlKQY2FhuP7wu6tMJZG1 4MA/zY4mUETu53QbnXdgJfg8JM7CLhVicy5xZtydHsFHi36a7ndH4okfAOnsf2bG0wwZiR 7WdjXKyn7A31ioCGWtuAVCu58kpeWvg=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 31 Jul 2018 15:11:59 +0100 To: Bron Gondwana , extra@ietf.org References: <153298552294.7786.11921391317659280671.idtracker@ietfa.amsl.com> <1533043719.2418979.1458678424.42636FEA@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <58cb8749-5447-dc7f-b8cb-f5e959077543@isode.com> Date: Tue, 31 Jul 2018 15:11:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <1533043719.2418979.1458678424.42636FEA@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6FEBAC889427C64B4478191D" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-objectid-06: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 14:12:01 -0000 --------------6FEBAC889427C64B4478191D Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi, On 31/07/2018 14:28, Bron Gondwana wrote: > On Tue, Jul 31, 2018, at 07:18, Benjamin Kaduk wrote: > =C2=A0[snip] >> Section 5.3 >> >> Is this valid ABNF without quotes around the literals, SP, and whatnot? > > Now that's a really good point - it's kinda sloppy how it is now.=C2=A0 On= =20 > the other hand, it is spelled out clearly in the ABNF later.=C2=A0 I'll=20 > defer to Alexey on whether it's worth going back and changing that. I was tripped by this as well. I would prefer either to use ABNF here or=20 make it clear that this is a pseudo-syntax. > Section 13.1 >> >> Server-assigned sequence numbers can have some operational challenges=20 >> with >> respect to power outages, crashes, restore from backup, and the like, and >> ensuring that the number is in fact globally unique.=C2=A0 I guess for=20 >> this case >> it's less catastrophic than it is for, e.g., leaf reuse in hash-based >> signatures (RFC 8391), so maybe the risk does not need to be called out. > > Yeah, we discussed it in group and decided everyone already knows that=20 > to some extent for any server-set ids.=C2=A0 Unless my AD requests a=20 > change, I'd leave this as is. I think no change is fine. --------------6FEBAC889427C64B4478191D Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi,


On 31/07/2018 14:28, Bron Gondwana wrote:
On Tue, Jul 31, 2018, at 07:18, Benjamin Kaduk wrote:

=C2=A0[snip]
Section 5.3

Is this valid ABNF without quotes around the literals, SP, and whatnot?

Now that's a really good point - it's kinda sloppy how it is now.=C2=A0 On the other hand, it is spelled out clearly in the ABNF later.=C2=A0 I'll defer to Alexey on whether it's worth going back and changing that.
I was tripped by this as well. I would prefer either to use ABNF here or make it clear that this is a pseudo-syntax.


Section 13.1

Server-assigned sequence numbers can have some operational challenges with
respect to power outages, crashes, restore from backup, and the like, and
ensuring that the number is in fact globally unique.=C2=A0 I guess for this case
it's less catastrophic than it is for, e.g., leaf reuse in hash-based
signatures (RFC 8391), so maybe the risk does not need to be called out.

Yeah, we discussed it in group and decided everyone already knows that to some extent for any server-set ids.=C2=A0 Unless my AD requests a change, I'd leave this as is.

I think no change is fine.

--------------6FEBAC889427C64B4478191D-- From nobody Tue Jul 31 11:10:40 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47634130E5B; Tue, 31 Jul 2018 11:10:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-extra-imap-objectid@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153306063928.3243.5362552823157836437.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2018 11:10:39 -0700 Archived-At: Subject: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap-objectid-07: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 18:10:39 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-extra-imap-objectid-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.2: "The THREADID data item is an objectid which uniquely identifies a set of messages which the server believes should be grouped together when presented. ... The server SHOULD return the same THREADID for related messages even if they are in different mailboxes." "related" seems like a broader characterization than "messages which the server believes should be grouped together when presented," but I'm assuming they are meant to be equivalent. I think it would help to clarify this in the second sentence, i.e., that messages that would appear threaded if they were in the same mailbox SHOULD return the same THREADID even if they are in different mailboxes. Section 8.1: s/from the following set of 64 codepoints. a-z, A-Z, 0-9, '_', '-'./from the following set of 64 codepoints: a-z, A-Z, 0-9, '_', '-'./ From nobody Tue Jul 31 11:12:19 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485FC130DF7; Tue, 31 Jul 2018 11:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=JJBF4thG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oWkz0YN+ 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 9EGFzlKFXOPm; Tue, 31 Jul 2018 11:12:15 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC82130E5B; Tue, 31 Jul 2018 11:12:15 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 15C5221E07; Tue, 31 Jul 2018 14:12:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 31 Jul 2018 14:12:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=BraDUbIzTgLoQkvU+ZcMpdMscUN9h SWQYZQPQyg2G94=; b=JJBF4thG2MUNGMbzAeU6r6IdJibtLIy65ZDU3LUo0FBZ7 tX8Tiv/PYhh6fpeaC4+4vDmOsnQ+htJQAGtmjMr1W3waxyY+lf+nQbApCAv8kKil 1vRjzv5/f+f+ECZuY4pP/WQNSQWXce4XLgSWTBhDtIM8kyLq0JAvHiWwWl3120SD Bhls7mkpSz7OyDj/VZUgFDGxpN5HeHgZciF5C9tE/zNU4+jCUyii54nK0aDpSw/t Nq1vyYKgqQZSUUq4ggTMBtGCQ+gkilYcebdCzZBAVU8EBiPNzXRMHs+saH5XcMbb RHaj/NU0NT02QlaL9oqV18sz16Sz+cBqBmMaY7xow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=BraDUb IzTgLoQkvU+ZcMpdMscUN9hSWQYZQPQyg2G94=; b=oWkz0YN+mAtccJE/1qQwTD mBWsk1iU0Q9P3VW8muaX2SiS1QiFXNHh8n5uPRkezYXg1sQ5j1F6DlVPHiDua1i/ 4nJs6dC/VvapHPWkcxS3H9/mQKCLP8r+29hDjRvw9vv1S4Yh3FoNbRrKijSfRLPj SmdxF21k/nTSUeKIgu6QEhSrk45Qu080Miv1LSmJqxfonoFr1VDa81aBqok8Ogoe KTz/oNgTsyQgYBV4oOh0MAFOPEpcxSx3e8qRNOIIxV7Z/7c5mqMAO0TmxNK3QYGG sX0z7FwKW9ol5GYQHyCWhD4O4nsYk8niOpnkkAmIrHHgVnAoIhR2Z5IoMcVhsRqg == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 9283AE48A7; Tue, 31 Jul 2018 14:12:13 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <153271422661.32667.3834516374113335159@ietfa.amsl.com> Date: Tue, 31 Jul 2018 14:12:12 -0400 Cc: General Area Review Team , extra@ietf.org, draft-ietf-extra-imap-objectid.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19117817-630B-40F7-883C-B26A27E8BA4D@cooperw.in> References: <153271422661.32667.3834516374113335159@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Extra] [Gen-art] Genart telechat review of draft-ietf-extra-imap-objectid-06 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 18:12:17 -0000 Pete, thanks for your reviews. Bron, thanks for addressing Pete=E2=80=99s = comments. I have entered a No Objection ballot. Alissa > On Jul 27, 2018, at 1:57 PM, Pete Resnick = wrote: >=20 > Reviewer: Pete Resnick > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-extra-imap-objectid-06 > Reviewer: Pete Resnick > Review Date: 2018-07-27 > IETF LC End Date: 2018-07-13 > IESG Telechat date: 2018-08-02 >=20 > Summary: Ready with Nits >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: >=20 > Thanks for the changes responding to my review. Good work. >=20 > =C2=A75.2, =C2=B66: >=20 > OLD > THREADID is optional, if the server doesn't support THREADID or is > NEW > THREADID is OPTIONAL; if the server doesn't support THREADID or is >=20 > =C2=A75.2 =C2=B67: >=20 > Not clear to me why the THREADID and EMAILID can't be the same. I = assume given > the MUST it's going to be some sort of interoperability problem, but = it does > seem odd. But don't change it on my account. >=20 > =C2=A78.2 =C2=B62: >=20 > s/backend object collide/backend object identifiers >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jul 31 15:50:47 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FCF130E90; Tue, 31 Jul 2018 15:50:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-imap-objectid@ietf.org, Jiankang Yao , extra-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153307744579.3110.9297337364956440515.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2018 15:50:45 -0700 Archived-At: Subject: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-objectid-07: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 22:50:46 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-extra-imap-objectid-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D7116 IMPORTANT S 11. > If a digest is used for ID generation, it must have a collision > resistent property, so server implementations are advised to monitor > current security research and choose secure digests. > > The use of a digest for ID generation may be used as proof that a > particular sequence of bytes was seen by the server. I don't understand this text. How does the client know whether a digest was sued. COMMENTS S 7. > IMAP ABNF extensions [RFC4466] specifications. > > Except as noted otherwise, all alphabetic characters are case- > insensitive. The use of upper- or lowercase characters to define > token strings is for editorial clarity only. Implementations MUST > accept these strings in a case-insensitive fashion. For clarity: IDs are not case insensitive, right? Because otherwise the text below about differing in case doesn't make sense. S 8.1. > > o ids which contain only digits > > o ids which differ only by ASCII case (A vs a) > > o the specific sequence of 3 characters NIL Nit. Do you want to quote "NIL"? From nobody Tue Jul 31 17:34:14 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AE9130EAE; Tue, 31 Jul 2018 17:34:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-extra-imap-objectid@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153308364661.3302.4161596749471465333.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2018 17:34:06 -0700 Archived-At: Subject: [Extra] Adam Roach's Yes on draft-ietf-extra-imap-objectid-07: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.27 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 00:34:07 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-imap-objectid-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work that went into defining this mechanism -- it seems like a very useful optimization. I have a few minor comments. --------------------------------------------------------------------------- §7: > resp-text-code =/ "MAILBOXID" SP "(" objectid ")" > ; incorporated before the expansion rule of > ; atom [SP 1*<any TEXT-CHAR except "]">] > ; that appears in [@!RFC3501] The "<" and ">" in the preceding text should be replaced with literal less-than and greater-than symbols. --------------------------------------------------------------------------- §8.1: > An objectid is a string of 1 to 255 characters from the following set > of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. It would probably be helpful for implementors if this section indicated that these are the same characters used by the "base64url" encoding defined in RFC 4648. Doing so will let implementors know that they can use existing implementations of base64url to convert the output of a hash function into a syntactically valid objectid. --------------------------------------------------------------------------- §11: > The use of a digest for ID generation may be used as proof that a > particular sequence of bytes was seen by the server, however this is > only a risk if IDs are leaked to clients who don't have permission to > fetch the data directly. Servers that are expected to handle highly > sensitive data should consider using a ID generation mechanism which > doesn't derive from a digest. Couldn't this be addressed with a per-user salt value rather than a non-digest identifier?