From nobody Thu Nov 1 07:11: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 3BB17124D68 for ; Thu, 1 Nov 2018 07:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 zI5wdf-53c-7 for ; Thu, 1 Nov 2018 07:11:11 -0700 (PDT) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 5853512785F for ; Thu, 1 Nov 2018 07:11:10 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QZ257ULIMO000CW6@mauve.mrochek.com> for extra@ietf.org; Tue, 30 Oct 2018 16:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1540941634; bh=AjnCzC4j76PnuE8ooHNjtqUCLG0Bp4r5oF6guHd59W0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=KcgVS6vN8NzHsV1gaJ1c8w5YI6tcMk2XrSacTuctBkQjwlBw2xMFr72Hc9wBj8Ioi SZrs2oNPHqtE6LU2TM9AZ3Hb0L59+nnNZ3aeCfPaiPJrLHbCht9PEet9xpcbpuzppZ JqSGkOGpevfvumcZfzX0brHEfW8IrTAmkUoNjU/A= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QYZWQSAX6O00008A@mauve.mrochek.com>; Tue, 30 Oct 2018 16:20:23 -0700 (PDT) Cc: Stephan Bosch , extra@ietf.org, Ned Freed Message-id: <01QZ257P6DGE00008A@mauve.mrochek.com> Date: Tue, 30 Oct 2018 16:11:25 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 30 Oct 2018 20:15:00 +0000" <6b72363d-6f00-3ef7-2398-05690926b6f5@isode.com> References: <6b72363d-6f00-3ef7-2398-05690926b6f5@isode.com> To: Alexey Melnikov Archived-At: Subject: Re: [Extra] Comments on draft-ietf-extra-sieve-special-use-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 14:11:12 -0000 > Hi Stephan, > On 29/10/2018 12:06, Stephan Bosch wrote: > > Hi Alexey, > > > > > > Op 28-10-2018 om 16:07 schreef Alexey Melnikov: > >> Hi all, > >> I've just tried to implement this Sieve extension and I have a couple of > >> comments: > >> > >> 3.  Test "specialuse_exists" > >> > >>     Usage:  specialuse_exists [] > >>                               > >> > >> This defines an optional argument. According to the base Sieve RFC 5228, > >> optional arguments must be tagged: > >> > >>    2.6.1.  Positional Arguments > >> > >>     Positional arguments are given to a command that discerns their > >>     meaning based on their order.  When a command takes positional > >>     arguments, all positional arguments must be supplied and must be in > >>     the order prescribed. > >> > >>   and > >> > >>    2.6.3.  Optional Arguments > >> > >>     Optional arguments are exactly like tagged arguments except that they > >>     may be left out, in which case a default value is implied.  Because > >>     optional arguments tend to result in shorter scripts, they have been > >>     used far more than tagged arguments. > >> > >> So I don't think you can have "mailbox" being positional without a tag! > > > > Then what about the entirety of the "imap4flags" extension? > Guilty as charged :-). I entirely forgot about that and the reason why I > haven't noticed is because my implementation doesn't support "variables" > extension, so variable name parameter to addflag/removeflag/setflag is > never allowed. > Any other opinions (Ned?). I just want to make sure that if we violating > some kind of architectural principle specified in the base Sieve script, > than we decide to do this deliberately. (Or maybe we just agree that > there is no architectural principle to begin with.) There was some principle in play, I think - Sieve copies this aspect from Common LISP, and if memory serves, &optional in Common LISP makes all subsequent parameter optional, so you can do something like: (defun fu (a b &optional c d) ... but there is nothing like: (defun bar (a (&optional b) c) ... But it looks like we've already crossed this bridge with imap4flags, and nobody has complained. So let's note it and move on. > > Lots of > > tag-less optional arguments can be found there. I am not against having > > some ":mailbox" tag here, but the current syntax does make things more > > concise. > > > >> 4.  ":specialuse" Argument to "fileinto" Command > >> > >>     Usage:  fileinto [:specialuse ] > >>                      > >> > >> Can I suggest that all special-use-flag strings should not include the > >> leading "\" character? It requires escaping in Sieve, so people might > >> make mistakes when writing scripts. > > > > I have no strong opinion about that. Disadvantage of doing that is that > > it can be confusing for people with IMAP experience and it becomes > > inconsistent with imap4flags. > Yes, that is true. At the same time in JMAP we can do remove leading "\" > character from flag names as well. > So yes, I am not fully decided on this issue. Anybody else wants to comment? I'm not fond of having multiple forms for things, so I'd prefer to keep the "\". It's not a strong preference, however. Ned From nobody Thu Nov 1 12:01: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 D67261294D0 for ; Thu, 1 Nov 2018 12:01:45 -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 gWHY3SwG0oiH for ; Thu, 1 Nov 2018 12:01:42 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id B6A1D130E03 for ; Thu, 1 Nov 2018 12:01:32 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 0B5662B3C8A; Thu, 1 Nov 2018 21:01:23 +0200 (EET) To: Ned Freed , Alexey Melnikov Cc: extra@ietf.org References: <6b72363d-6f00-3ef7-2398-05690926b6f5@isode.com> <01QZ257P6DGE00008A@mauve.mrochek.com> From: Stephan Bosch Message-ID: <97c31e0c-6af7-0f03-73f8-24f853e662bf@dovecot.fi> Date: Thu, 1 Nov 2018 20:01:12 +0100 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: <01QZ257P6DGE00008A@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] Comments on draft-ietf-extra-sieve-special-use-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 19:01:51 -0000 Hi Ned, BTW, can you review the IMAP examples in this specification? Regards, Stephan. Op 31/10/2018 om 00:11 schreef Ned Freed: >> Hi Stephan, >> On 29/10/2018 12:06, Stephan Bosch wrote: >>> Hi Alexey, >>> >>> >>> Op 28-10-2018 om 16:07 schreef Alexey Melnikov: >>>> Hi all, >>>> I've just tried to implement this Sieve extension and I have a couple of >>>> comments: >>>> >>>> 3.  Test "specialuse_exists" >>>> >>>>     Usage:  specialuse_exists [] >>>>                               >>>> >>>> This defines an optional argument. According to the base Sieve RFC 5228, >>>> optional arguments must be tagged: >>>> >>>>    2.6.1.  Positional Arguments >>>> >>>>     Positional arguments are given to a command that discerns their >>>>     meaning based on their order.  When a command takes positional >>>>     arguments, all positional arguments must be supplied and must be in >>>>     the order prescribed. >>>> >>>>   and >>>> >>>>    2.6.3.  Optional Arguments >>>> >>>>     Optional arguments are exactly like tagged arguments except that they >>>>     may be left out, in which case a default value is implied.  Because >>>>     optional arguments tend to result in shorter scripts, they have been >>>>     used far more than tagged arguments. >>>> >>>> So I don't think you can have "mailbox" being positional without a tag! >>> Then what about the entirety of the "imap4flags" extension? >> Guilty as charged :-). I entirely forgot about that and the reason why I >> haven't noticed is because my implementation doesn't support "variables" >> extension, so variable name parameter to addflag/removeflag/setflag is >> never allowed. >> Any other opinions (Ned?). I just want to make sure that if we violating >> some kind of architectural principle specified in the base Sieve script, >> than we decide to do this deliberately. (Or maybe we just agree that >> there is no architectural principle to begin with.) > There was some principle in play, I think - Sieve copies this aspect from > Common LISP, and if memory serves, &optional in Common LISP makes all > subsequent parameter optional, so you can do something like: > > (defun fu (a b &optional c d) ... > > but there is nothing like: > > (defun bar (a (&optional b) c) ... > > But it looks like we've already crossed this bridge with imap4flags, and > nobody has complained. So let's note it and move on. > >>> Lots of >>> tag-less optional arguments can be found there. I am not against having >>> some ":mailbox" tag here, but the current syntax does make things more >>> concise. >>> >>>> 4.  ":specialuse" Argument to "fileinto" Command >>>> >>>>     Usage:  fileinto [:specialuse ] >>>>                      >>>> >>>> Can I suggest that all special-use-flag strings should not include the >>>> leading "\" character? It requires escaping in Sieve, so people might >>>> make mistakes when writing scripts. >>> I have no strong opinion about that. Disadvantage of doing that is that >>> it can be confusing for people with IMAP experience and it becomes >>> inconsistent with imap4flags. >> Yes, that is true. At the same time in JMAP we can do remove leading "\" >> character from flag names as well. >> So yes, I am not fully decided on this issue. Anybody else wants to comment? > I'm not fond of having multiple forms for things, so I'd prefer to keep > the "\". It's not a strong preference, however. > > Ned > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Fri Nov 2 14:34: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 536AA130DFC for ; Fri, 2 Nov 2018 14:34:30 -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 tYwy8y0hgrdh for ; Fri, 2 Nov 2018 14:34:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (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 BB82012EB11 for ; Fri, 2 Nov 2018 14:34:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QZ68820TDC0012O1@mauve.mrochek.com> for extra@ietf.org; Fri, 2 Nov 2018 14:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1541194164; bh=uuorSpmgVc6o7z2iMpPveuxXNnS4FNpic3w8hpyNiTQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=oG9DM83SvzwwgGwL5O2gIIqoNrVJguE9RfDoE9Wg+mG8KL67UCc1ZfXyoK1Sh8I6j goZyYaXBWbYwrqcFVkkns0ZpxYh1T9NHnGTLJPgFCXBwnPlorptq+bU5s1r9oVT7gi BCAYcYOpJr8WoN2B39Fc2Yab8GLeAZv5B9mxRB9w= 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 <01QZ4Y76JY0000008A@mauve.mrochek.com>; Fri, 2 Nov 2018 14:29:18 -0700 (PDT) Cc: ned.freed@mrochek.com, alexey.melnikov@isode.com, extra@ietf.org, stephan.bosch@dovecot.fi Message-id: <01QZ687ZXFXK00008A@mauve.mrochek.com> Date: Fri, 02 Nov 2018 14:28:36 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 01 Nov 2018 10:10:26 -0700" References: <6b72363d-6f00-3ef7-2398-05690926b6f5@isode.com> <01QZ257P6DGE00008A@mauve.mrochek.com> To: Tim Showalter Archived-At: Subject: Re: [Extra] Comments on draft-ietf-extra-sieve-special-use-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 02 Nov 2018 21:34:30 -0000 > On Thu, Nov 1, 2018 at 7:11 AM Ned Freed wrote: > > > Any other opinions (Ned?). I just want to make sure that if we violating > > > some kind of architectural principle specified in the base Sieve script, > > > than we decide to do this deliberately. (Or maybe we just agree that > > > there is no architectural principle to begin with.) > > > > There was some principle in play, I think - Sieve copies this aspect from > > Common LISP, and if memory serves, &optional in Common LISP makes all > > subsequent parameter optional, so you can do something like: [...] > This was exactly the idea. > We could probably change a MUST to a SHOULD somewhere for compatibility to > legitimize this, but this does make argument parsing a little less regular > than it otherwise might be. (A similar argument is why you have to have > header :contains ["To"] "whatever", instead of header ["To"] :contains > :whatever"; one ancient version of the spec allowed any ordering.) A future change to a SHOULD sounds like a good idea to me. Ned From nobody Mon Nov 5 08:30: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 213EB130EE5 for ; Mon, 5 Nov 2018 08:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 7r3yaIuhpYuY for ; Mon, 5 Nov 2018 08:30:22 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 0F108130F56 for ; Mon, 5 Nov 2018 08:30:21 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id DDFC86A266 for ; Mon, 5 Nov 2018 17:30:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1541435419; bh=Nwx9UsQ20Tn/LBb95Dd6RU/tbtSaJZmmjnfNGUFIY5E=; h=Date:From:To:Subject:From; b=5K8OrpHBkzn5kCdglRelXL9jCv2UFagN8cS9VmhlDrlobEljnfLHvIJLFs2g+5Ddo 5rNURjy0IQWC7vlD1Cdjtug4Y7tD5qS0V5ZLAqKgJiESYo8DNHalqRqidnDQ1PGMSh +1TeYdAWHcjxwN9yKoMzQDByRRqPMPY3nkpqL9879tu6fvn7JJAGxU45m+tTDMy8ch PI4dI/YShBfzHAaZ5FcksPJwCtosQCYLukZoEyudmtqqRsPHUT/MoynD66Ekhk9KWZ BIac84IrE20cuU+/RbBMmy93F5gIKdSFSXnqT1AXnV4aYuo+xdKkMtK3eOXxJgIKtk +hM0FCqIxIn1Q== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 D72613C0024 for ; Mon, 5 Nov 2018 17:30:19 +0100 (CET) Date: Mon, 5 Nov 2018 09:30:19 -0700 (MST) From: Michael Slusarz To: extra@ietf.org Message-ID: <222011778.12006.1541435419815@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev19 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 16:30:29 -0000 I've submitted an update to the (formerly snippet, now) preview draft incor= porating feedback received from this list and other implementers. =C2=A0 Main change is the name - this is now "PREVIEW" instead of "SNIPPET".=C2=A0= Also, increased recommended preview size to 200 characters (previously: 10= 0). =C2=A0 Will not be able to remotely join IETF 103 meeting as I am traveling, but w= anted to make sure this draft was updated before then. michael From nobody Mon Nov 5 18:44:28 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 7C206130E1C for ; Mon, 5 Nov 2018 18:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=LsPBceuj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GdShTo+k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQVyKHCRUB91 for ; Mon, 5 Nov 2018 18:44:25 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9139130DD2 for ; Mon, 5 Nov 2018 18:44:24 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E33D822C78 for ; Mon, 5 Nov 2018 21:44:23 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 05 Nov 2018 21:44:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=+jKTEqRjrfQssaR6Qe+l2L9dFA4f Hz1CKcQXTul60KY=; b=LsPBceujrHiQ8uE/TO/2Hf6HeU1S9hDaIDN17uA5+uaM O8wqI4J/4kjTvS5cqpkEcbthk9tTEWEqimc5/NDcRJEiLlCBG3khOnvxWXovKswi fo1OUzZdPK4XM0Tv68PiGzwr3PlI198piUTf8C+LU3XrAnGUyYITbz5sc42LLTR/ 1YJWnC/ja4w2ofVdnSvHhIfHR3DBcqbfvv7WAk1I1g8qZNbgBZTkt7r6BAMZ44Hx gCiPl9iCzvHybJ1in9uHrQTlxouWNVXHZAOV3r1h2WQWV0P/krirkVs2VvNiqEso +EcPYwCPoXbjkv99hvhgbgVpBwnyfIc+TXySg15KZA== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+jKTEqRjrfQssaR6Q e+l2L9dFA4fHz1CKcQXTul60KY=; b=GdShTo+kPNhzLtKnbjS4BmpcPCtlXFY1b Ac+XcT/OOoNKMVCIQLAH+8TEsc0HW+6o8JohApx1QZ6fDtAMFLzzMoOv4lSQBinZ 73mP2pfH97feHx71XGOtQwHoLWVWp9K+TkCBxgL6Kwi896E95aomMJhRLXRvK+FT nCCfkavzD00kZ+Czsf2YQ2arHoPdZIr+kgSK4Pf7m5HJnomLwyQXn2Rd7P9E6aSk YE4aYzP8wTStAg+5/6pYPhNSPXYNKne4qWJKFdk/1v+FfihItwR9UfYBfv8B3p2u WVgOEUT5q9GBEbnJa1XdDF+Te0M6zlaELymApdQ+NL265a/phJB0A== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7808B20207; Mon, 5 Nov 2018 21:44:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <6da0e5dc-4ac0-41ca-8494-e1b01d2a1bb8@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: <222011778.12006.1541435419815@appsuite.open-xchange.com> References: <222011778.12006.1541435419815@appsuite.open-xchange.com> Date: Mon, 05 Nov 2018 21:44:23 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=31c0a6353b694b4b905760734c4108c6 Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 02:44:26 -0000 --31c0a6353b694b4b905760734c4108c6 Content-Type: text/plain Thanks for submitting this! I'll make sure it gets discussed in the meeting. I'm just putting together the agenda this morning. Cheers, Bron. On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: > I've submitted an update to the (formerly snippet, now) preview draft incorporating feedback received from this list and other implementers. > > Main change is the name - this is now "PREVIEW" instead of "SNIPPET". Also, increased recommended preview size to 200 characters (previously: 100). > > Will not be able to remotely join IETF 103 meeting as I am traveling, but wanted to make sure this draft was updated before then. > > michael > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --31c0a6353b694b4b905760734c4108c6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks for submitting this!  I'll make sure it gets d= iscussed in the meeting.  I'm just putting together the agenda this= morning.

Cheers,

Bron.

On Tue, Nov 6, 2018, at 03:30, Michael Slus= arz wrote:
I've submitted an update to the (formerly= snippet, now) preview draft incorporating feedback received from this l= ist and other implementers.
&= nbsp;
Main change is the name= - this is now "PREVIEW" instead of "SNIPPET".  Also, increased rec= ommended preview size to 200 characters (previously: 100).
 
Will not be able to remotely join IETF 103 meeting as I am trave= ling, but wanted to make sure this draft was updated before then.

michael

________________________________________= _______
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra


--
  Bron Gondwana, C= EO, FastMail Pty Ltd
  brong@fast= mailteam.com


--31c0a6353b694b4b905760734c4108c6-- From nobody Tue Nov 6 00:37: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 9861C1277C8 for ; Tue, 6 Nov 2018 00:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=hNyuWRsy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vCk3a2jC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCS6cSwETYEi for ; Tue, 6 Nov 2018 00:37:06 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74187130DCB for ; Tue, 6 Nov 2018 00:37:06 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DE1CC2251D for ; Tue, 6 Nov 2018 03:37:04 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 06 Nov 2018 03:37:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=GmcUKuEQNfqyMSTC0YRmOYs/Zf9xFNmAhvDE7HW ehn8=; b=hNyuWRsyO4kFaBGvAsWpndxPnXgTTWHa4Ngzhy+9a3AK38t7oO/GE1B IEg3mfDdIiKG+ntuuoJIYThaG0ZHRBHxiWFJVNJDImzWPk7xTwYoSkcCJGNL3KW1 4gGiPHym+Z7BtkLU5VuSyIqf3LngSv2okSJfbVF3LMm9w2U0tWflXaWhbnC/ouJI Dl66DTUe06pnj7apXohcI2UtrTCPScRx9f/3kQLaGXJLmCTMiGJ/s6QuzHWAZt99 xhSvz9MRUfTULnOeBBDYMj0rbXfb73iqpyPrLwgyj9yN5rx3gghbhLfy5Nhlqys/ trFmK/KSVuqdnXFws/8jFAYjVur7o1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=GmcUKuEQNfqyMSTC0YRmOYs/Zf9xFNmAhvDE7HWehn8=; b=vCk3a2jC 1nW5N60JPAE56FtDyZI3QdolhHe+Uj2qB6K0MisEmzJG060bHJaRMQg9rOwgR7MI YgCz3FymlQL92+9KbGOY2egTEzQpSFye6JXe8P2u+KNaQ5+FLNPTdxdlranL75PL 7w34cXd9F+rVvQ1wkbvhxBKP+R+xxAOTjyzFOImvJgUYB0yvycqm6p/2wRnPmKHb rL13v6u363w/DU1egURGsTKf4Y3AMaMUjx/hRiFYJxADuR6BsJliheLXaborrSPC VoWyt3c8MMLoXVyicygDTiteLxMdupeiMLztRqC4WyfDJGpmq92Rc42BVvH0hlOs 7KTAvmrSOBZMtw== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 631F120207; Tue, 6 Nov 2018 03:37:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <4d491c4f-aa9c-48c4-a014-78dc1f3050f4@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Tue, 06 Nov 2018 03:37:01 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=7ff276c1e1e84d84a7b4ecfeb0e0213a Archived-At: Subject: [Extra] Agenda for IETF103 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 08:37:07 -0000 --7ff276c1e1e84d84a7b4ecfeb0e0213a Content-Type: text/plain Apologies for being so slow with this! I've been traveling and didn't get organised. I'm proposing the following: EXTRA WG AGENDA - 8-Nov-2018: 1:50pm We have 2 hours, and I expect we won't need all of it! I've created a 1 hour schedule. Intro and Note Well: 5m Existing documents: 45m * imap4rev2 30m * snippet/preview 10m * sieve-special-use: 5m AOB: 10m If you have anything else you want us to talk about, let me or Jiankang know! We don't currently have any proposed new work after imap4rev2 unless someone feels like reviving 64bit. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --7ff276c1e1e84d84a7b4ecfeb0e0213a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Apologies for being so slow with this! I've been traveling= and didn't get organised.  I'm proposing the following:
<= div style=3D"font-family:Arial;">
EXTRA WG AGENDA - 8-Nov-2018: 1:50pm

We have 2 hours= , and I expect we won't need all of it!  I've created a 1 hour sche= dule.

Intro and Note Well: 5m
Existing documents: 45m
  * imap4rev2 30m
  * snippet/preview 10m
  * sieve-special-use: 5m
AOB: 10m

If you have anything else you want us to = talk about, let me or Jiankang know!  We don't currently have any p= roposed new work after imap4rev2 unless someone feels like reviving 64bi= t.

Cheers,
Bron.

--
&n= bsp; Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

=

--7ff276c1e1e84d84a7b4ecfeb0e0213a-- From nobody Tue Nov 6 02:06:15 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 5A245130DF6; Tue, 6 Nov 2018 02:06:08 -0800 (PST) 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.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <154149876834.30762.9357967968598951445@ietfa.amsl.com> Date: Tue, 06 Nov 2018 02:06:08 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-preview-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 10:06:08 -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 : IMAP4 Extension: Message Preview Generation Author : Michael Slusarz Filename : draft-ietf-extra-imap-fetch-preview-00.txt Pages : 11 Date : 2018-11-05 Abstract: This document specifies an IMAP protocol extension which allows a client to request that a server provide an abbreviated representation of a message that can be used by a client to provide a useful contextual preview of the message contents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-00 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-preview-00 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 Nov 6 09:00: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 39261130E81 for ; Tue, 6 Nov 2018 08:59:58 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 x4B-kf5m4BeO for ; Tue, 6 Nov 2018 08:59:55 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id F2C94130E29 for ; Tue, 6 Nov 2018 08:59:53 -0800 (PST) Received: from healthyao-PC (unknown [159.226.7.2]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJdq2EyOFb7NYAAA--.427S2; Wed, 07 Nov 2018 00:59:49 +0800 (CST) Date: Wed, 7 Nov 2018 00:59:50 +0800 From: "Jiankang Yao" To: extra Reply-To: yaojk References: <153616200699.19753.13957702160049989504@ietfa.amsl.com>, <2018092709114637832442@cnnic.cn>, <20181016092756197991174@cnnic.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20181107005850627671176@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart755524010325_=----" X-CM-TRANSID: AQAAf0BJdq2EyOFb7NYAAA--.427S2 X-Coremail-Antispam: 1UD129KBjvdXoW7XrW7WF4xKryDXF1xZFWDJwb_yoW3Krc_ua 9xtw48t393W3WUJF48tF4Fgr93A3yag3yUZr1fJwsaq34qq398Xrs2gFnxX34rJr4DG398 GrnFqrZrJ39FqjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbTkYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIE14v26r4j6F4UM28EF7xvwVC2z2 80aVCY1x0267AKxVW8JVW8Jr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAY jxAxZF0Ex2IqxwCY02Avz4vE14v_JwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbV WUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF 67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42 IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1l IxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2 IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jshLnUUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: [Extra] Summary of WGLC for draft-ietf-extra-sieve-special-use-03.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 16:59:59 -0000 This is a multi-part message in MIME format. ------=_001_NextPart755524010325_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQogICBUaGlzIGRyYWZ0IGhhcyBmaW5pc2hlZCB0aGUgV0dMQy4gQWxleGV5 IGdhdmUgc29tZSBjb21tZW50cyBpbiAgDQogICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2V4dHJhL2N1cnJlbnQvbXNnMDA2MDkuaHRtbCANCiAgIFRoZSBXRyBhbHNvIGhh ZCBzb21lIGRpc2N1c3Npb24gYmFzZWQgb24gdGhlc2UgY29tbWVudHMuIFRoZSBhdXRob3IgaG9w ZXMgdGhlIFdHIGV4cGVydHMgdG8gaGVscCB0byBmdXJ0aGVybHkgcmV2aWV3IHRoZSBJTUFQIGV4 YW1wbGVzIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4NCiAgIElmIHlvdSBoYXZlIGFueSBtb3JlIGNv bW1lbnRzIHRvIHRoaXMgZHJhZnQsIHBscyBraW5kbHkgc2VuZCBpdCB0byB0aGUgbGlzdCBvciBl eHByZXNzIGl0IGluIFRodXJzZGF5IEVYVFJBIG1lZXRpbmcuDQogICBBZnRlciB0aGlzIElFVEYg bWVldGluZywgdGhlIGF1dGhvciBjYW4gdXBkYXRlIGEgbmV3IHZlcnNpb24gdG8gYWRkcmVzcyBh bGwgaXNzdWVzIHJhaXNlZC4NCiAgIA0KVGhhbmtzLg0KDQoNCg0KDQpKaWFua2FuZyBZYW8NCg0K t6K8/sjLo7ogSmlhbmthbmcgWWFvDQq3osvNyrG85KO6IDIwMTgtMTAtMTYgMDk6MjgNCsrVvP7I y6O6IGV4dHJhDQrW98zio7ogUmU6IFtFeHRyYV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1leHRy YS1zaWV2ZS1zcGVjaWFsLXVzZS0wMy50eHQNCkRlYXIgYWxsLA0KDQogICBUaGUgV0dMQyBmb3Ig dGhpcyBkcmFmdCB3aWxsIGV4cGlyZSBzb29uLCBwbHMga2luZGx5IGhlbHAgdG8gdGFrZSBhIGxv b2sgYXQgaXQgaWYgeW91IGhhdmUgbm90IGRvbmUgaXQuDQoNCg0KICBUaGFua3MuDQoNCg0KDQoN CkppYW5rYW5nIFlhbw== ------=_001_NextPart755524010325_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello all,
 
   This draft has finished the WGLC. Alexey = gave=20 some comments in 
   https://www.ietf.org/mail-archive/web/extra/current/msg00609.html=20
   The WG also had some discussion based on these comments.= The=20 author hopes the WG experts to help to furtherly review the IMAP examples = in=20 this specification.
   If you have any more comments to this draft, pls kindly = send=20 it to the list or express it in Thursday EXTRA meeting.
   After this IETF meeting, the author can update a new ver= sion=20 to address all issues raised.
  
Thanks.
 
Jiankang Yao
 
=B7=A2=BC=FE=C8=CB=A3=BA Jiankang Yao
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2018-10-16 09:28
=CA=D5=BC=FE=C8=CB=A3=BA extra
=D6=F7=CC=E2=A3=BA Re: [Extra] I-D Action:=20 draft-ietf-extra-sieve-special-use-03.txt
Dear all,
 
   The WGLC for this draft will expire soon, pls kindly hel= p to=20 take a look at it if you have not done it.
 
 
  Thanks.
 
Jiankang Yao
------=_001_NextPart755524010325_=------ From nobody Tue Nov 6 22:36:26 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 52B8B130EC7 for ; Tue, 6 Nov 2018 22:36:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154157257833.30936.1331608654008189609.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2018 22:36:18 -0800 From: IETF Secretariat Archived-At: Subject: [Extra] Milestones changed for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 06:36:24 -0000 Changed milestone "Submit "Sieve Email Filtering: Delivering to Special-Use Mailboxes" to IESG as a Proposed Standard", resolved as "Done". Changed milestone "Submit "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST" to IESG as a Proposed Standard", resolved as "Done". Changed milestone "Submit "64bit body part and message sizes in IMAP4" to IESG as a Proposed Standard", resolved as "Shelved". URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Wed Nov 7 23:51:32 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 71348124408; Wed, 7 Nov 2018 23:51:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-savedate@ietf.org, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154166347742.26260.1210087608874578137.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2018 23:51:17 -0800 Archived-At: Subject: [Extra] Protocol Action: 'Internet Message Access Protocol (IMAP) - SAVEDATE Extension' to Proposed Standard (draft-ietf-extra-imap-savedate-01.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 07:51:17 -0000 The IESG has approved the following document: - 'Internet Message Access Protocol (IMAP) - SAVEDATE Extension' (draft-ietf-extra-imap-savedate-01.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ Technical Summary This spec extends IMAP with an additional data point on each email in a mailbox which records the time at which the email was added to the mailbox. Working Group Summary The only topic of debate was how to deal with mailboxes which don't support storing the savedate. Various ideas were debated, and a conclusion was found which everybody was happy with. Document Quality This specification has been implemented in multiple servers and is very easy to follow. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Alexey Melnikov From nobody Thu Nov 8 02:08: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 D6CBA130F4D for ; Thu, 8 Nov 2018 02:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=zPjgIwgX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OcBKEGsF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAPe2bD5d-0z for ; Thu, 8 Nov 2018 02:07:55 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9745123FFD for ; Thu, 8 Nov 2018 02:07:54 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 24EE722078 for ; Thu, 8 Nov 2018 05:07:54 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 05:07:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=8pAipgRUfOg+/G6HdWeXoKYfaO10QECFuQMA0iD W4Ro=; b=zPjgIwgXXvEeVr6BRk1cWu6YTHjg2Xvz8MXs91jBYNai0N7TVJlHWu5 +OAskVozrnQLO/Tg7lcBlmTM5qPNNVT06aHpQS4ktyvjvQx870/dmIwd4LUzZO0Y 3uvB68oyFNJAVYYj8BJ7TnyE9NsHnGbW6RKfHF/8g7At733LfTfEYUzmRYDUS9yK OiNv0/cVdM0YE80FAM5Nbc8n7KR/Q1p2d5ItZ8U/vyxsmgNHGHkg8UUVDk671Zdx CCAlKaBq3Buhag0jIdJ2BUXS2wnl1LLjc/+/AIAYLENSabzNrf69CFa67Oyk5rtq athU1kTQymBfnn8QfgfRrd5p3BUhBFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=8pAipgRUfOg+/G6HdWeXoKYfaO10QECFuQMA0iDW4Ro=; b=OcBKEGsF fDROT7Rz945CAcQNnrHEcOO3MU4f1tXOmvkVF8zU7rz8h033bJMBdBlPMXZx62j6 doB9FdvEnPtBfDrYlgeKjVlQPbKkWrOGw7naQvhmEEiBlrrpWXqhIcM0iN24YCc5 ZzPwtLQKnlmE4SB0B/ulyjPuDuNrqvfrUUiOM/amIJZBUzxUWkecUMWtWljDKa5s 0PNFnqeFZCHWz4LoBzcOxM0Ca0ezQa7oqOAHb1Ex3ou1Fal2aFMbo1dJMKSRrAAk V1HWB+U25CtFNY59nvS0XaaASv4hhiRqm3I05jDNK0a9eNH13i48kJ4Wda4w12+F F2Ct5wE6Bm8MEA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9AFF92030B; Thu, 8 Nov 2018 05:07:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <1aa6f0bb-72bc-4758-ac1f-404552d623de@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 05:07:52 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=3ae80d11b1524d07b18872873ad252a7 Archived-At: Subject: [Extra] Minutes of today's session uploaded X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 10:07:59 -0000 --3ae80d11b1524d07b18872873ad252a7 Content-Type: text/plain And attached inline. As always, any corrections or clarifications, please post them here! Thanks, Bron. --- EXTRA MINUTES - IETF103 BANGKOK - 8 NOV 2018 Existing docs --- savedate: * comments needed in response to IESG tracker * don't believe anything else is required ACTION: Alexey will progress sieve-fcc: * ABNF suggests that tagged params have other parameters still, wordsmithing required * Alexey has suggested a change ACTION: Bron to talk with Ken about fixing wording sieve-special-use: * ready to progress ACTION: Jiankang to submit for publication imap4rev2: * needs more examples, particularly around BODYSTRUCTURE * also clearer wording for these difficult parts * needs examples for bodypart.MIME and bodypart.HEADER * suggestion to look at unofficial IMAP wiki for useful words * Q: is it legit to require only UTF8? Not for search, which needs to be able to match charset of data, but everything else is UTF8 only in imap4rev2 * open issues - all to be asked on the mailing list! ACTION: Bron to start 1 thread per open issue on the list ACTION: Bron to email other IMAP-related lists asking for input from client and server implementations about these issues TIMELINE: expect to be done by March (submit for publication pre-Prague) preview: * debate over 200 vs 255 * good to align with JMAP so servers can store one value * other than this issue, take to working group last call ACTION: Bron to email list with 200 vs 255 question. 64bit: * 53 bits is plenty * Nobody is clamouring for this or needs it * The couple of places (STATUS=SIZE and quota) will handle 64 bit separately ACTION: leave it dead Group next steps: --- * General support for keeping a group around to deal with email stuff, so we will keep operating while there's work trickling in * Document for sieve and EAI -> Stephan will have a go at it * QUOTA-BIS - Alexey has a start - happy to give to another editor * SMTP-related work: - options - recharter this group or spin up a new one - replace RFC532[12] with new version which include errata an replace 82[12] as "INTERNET STANDARD" docs. - MIME specs as well? - new WG vs recharter should go to the list. - in theory only a couple of months' work, but could easily go into the weeds and fail as the last couple of attempts have. ACTION: Bron to email list regarding sieve-EAI proposal ACTION: Bron to email list with request for author for QUOTA-BIS ACTION: Bron to email list regarding recharter vs new SMTP group Discussion of "scaring off new people" --- * CLIENTID proposal at Montreal led to potential contributors not engaging. * Were we too abrasive and dismissive? Hard to be sure. There was broad agreement in the group that the work itself was worthwhile, but this group wasn't at the right level of the stack. * Followup discussion was unproductive, felt like talking past each other. * Bron: could have set expectations better - presentation felt more like a sales pitch than a technical presentation. * IETF level - would help to have more orientation, like "shower before you get in the pool" - so people know what to expect. * Newcomer vs "Tourist" - expectation that there's lots of work to do and that someone coming to the IETF has to contribute as well as get what they want - it's a collaborative process, not a rubber stamp. * Pete: would help if we volunteer to guide people, up-front comms. - only helps if they're willing to learn about us though! * In a perfect world we may have been able to salvage something from the Montreal experience, but generally we're happy that we're a fairly welcoming group. We'll be thoughtful about how we handle new people going forward, and keep track of what's going on in the rest of the IETF. ACTION: nothing concrete, keep being thoughtful BIMI --- BIMI is organisational logo per message based on email authentication complience. Should we talk about BIMI? * more likely it belongs in DMARC than here. * would be good to discuss the work within the IETF and make sure we're handling security considerations wisely. * Governments are pushing DMARC, which is useful in their sphere of influence. BIMI helps push adoption by commercial interests. ACTION: no action taken, will keep talking Should we merge with other email related groups? --- * UTA is working on TLS1.3 recommendations and deprecating TLS1.1, so not really. * suggestion to try to put EXTRA and JMAP together on the schedule for future meetings, since much the same people come to both. ACTION: Bron to request co-location in Prague requests for EXTRA and JMAP. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --3ae80d11b1524d07b18872873ad252a7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
And attached inline.  As always, any corrections or c= larifications, please post them here!

Thanks,

Bron.

---

= EXTRA MINUTES - IETF103 BANGKOK - 8 NOV 2018

Existing doc= s
---

savedate= :
* comments needed in respon= se to IESG tracker
* don't be= lieve anything else is required

ACTION: Alexey will progr= ess

sieve-fcc:
* ABNF suggests that tagged params have other parameters still,
  wordsmithing required
* Alexey has suggested a change
<= /div>

ACTION: Bron to talk with Ken about fixing wording
<= div style=3D"font-family:Arial;">
sieve-special-use:
* rea= dy to progress

ACTION: Jiankang to submit for publication=

imap4rev2:
* = needs more examples, particularly around BODYSTRUCTURE
* also clearer wording for these difficult par= ts
* needs examples for bodyp= art.MIME and bodypart.HEADER
= * suggestion to look at unofficial IMAP wiki for useful words
<= div style=3D"font-family:Arial;">* Q: is it legit to require only UTF8?&= nbsp; Not for search, which needs
  to be able to match charset of data, but everything else is = UTF8
  only in imap4rev2=
* open issues - all to be as= ked on the mailing list!

=
ACTION: Bron to start 1 thread p= er open issue on the list
ACTION: Bron to email other IMA= P-related lists asking for input from
        client and server im= plementations about these issues

TIMELINE: expect to be d= one by March (submit for publication pre-Prague)

preview:=
* debate over 200 vs 255
=
* good to align with JMAP so ser= vers can store one value
* ot= her than this issue, take to working group last call

ACTI= ON: Bron to email list with 200 vs 255 question.

64bit:
* 53 bits is plenty
<= div style=3D"font-family:Arial;">* Nobody is clamouring for this or need= s it
* The couple of places (= STATUS=3DSIZE and quota) will handle 64 bit separately

AC= TION: leave it dead


Group next steps:
---<= br>

* General support for keeping a group around to deal with= email stuff,
  so we wi= ll keep operating while there's work trickling in
* Document for sieve and EAI -> Stephan will hav= e a go at it
* QUOTA-BIS - Al= exey has a start - happy to give to another editor
* SMTP-related work:
  - options - recharter this group or spin up a new on= e
  - replace RFC532[12]= with new version which include errata an
    replace 82[12] as "INTERNET STANDARD" do= cs.
  - MIME specs as we= ll?
  - new WG vs rechar= ter should go to the list.
&n= bsp; - in theory only a couple of months' work, but could easily go into=
    the weeds= and fail as the last couple of attempts have.

ACTION: Br= on to email list regarding sieve-EAI proposal

ACTION: Bro= n to email list with request for author for QUOTA-BIS

ACT= ION: Bron to email list regarding recharter vs new SMTP group
<= div style=3D"font-family:Arial;">
Discussion of "scaring off new people"
---

=
* CLIENTID proposal at Montreal led to= potential contributors
 = ; not engaging.
* Were we too= abrasive and dismissive?  Hard to be sure.  There
  was broad agreement in the group = that the work itself was
&nbs= p; worthwhile, but this group wasn't at the right level of the
=
  stack.
* Followup discussion was unproductive, felt like tal= king past
  each other.<= br>
* Bron: could have set expect= ations better - presentation felt
  more like a sales pitch than a technical presentation.
* IETF level - would help to have = more orientation, like "shower
  before you get in the pool" - so people know what to expect.
* Newcomer vs "Tourist" - expec= tation that there's lots of work
  to do and that someone coming to the IETF has to contribute a= s
  well as get what the= y want - it's a collaborative process, not
  a rubber stamp.
* Pete: would help if we volunteer to guide people, up-front com= ms.
  - only helps if th= ey're willing to learn about us though!
* In a perfect world we may have been able to salvage somethi= ng
  from the Montreal e= xperience, but generally we're happy that
  we're a fairly welcoming group.  We'll be thoug= htful about how
  we han= dle new people going forward, and keep track of what's going
  on in the rest of the IETF.

ACTION: nothing concrete, keep being thoughtful

BIMI
---

BIMI= is organisational logo per message based on email authentication
complience.

Should w= e talk about BIMI?
* more lik= ely it belongs in DMARC than here.
* would be good to discuss the work within the IETF and make sure<= br>
  we're handling securit= y considerations wisely.
* Go= vernments are pushing DMARC, which is useful in their sphere of
  influence.  BIMI helps pu= sh adoption by commercial interests.

ACTION: no action ta= ken, will keep talking

Should we merge with other email r= elated groups?
---
<= div style=3D"font-family:Arial;">
* UTA is working on TLS1.3 recommendations and deprecating TLS1.1, = so not
  really.
* suggestion to try to put EXTRA and= JMAP together on the schedule
  for future meetings, since much the same people come to both.

ACTION: Bron to request co-location in Prague requests for= EXTRA and JMAP.


--
  Bron Gond= wana, CEO, FastMail Pty Ltd
  bro= ng@fastmailteam.com


--3ae80d11b1524d07b18872873ad252a7-- From nobody Thu Nov 8 03:25: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 6AB41123FFD for ; Thu, 8 Nov 2018 03:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=x8UBbkpp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jv3SjTrN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS1E6QrF8bgn for ; Thu, 8 Nov 2018 03:25:36 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85D9130E6A for ; Thu, 8 Nov 2018 03:25:36 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DC94C21F0A for ; Thu, 8 Nov 2018 06:25:35 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:25:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=2S7giSFnay5LcX4GuwGMRBDkU1UV74dhohrD8ub 3BRY=; b=x8UBbkppwULO0QNjOZ1MZ6fGPDDpHXYHIY6nZIlRw3XlX9FA6idsKjC RLXeKQHqLMehwCYlGjmof7Frflv7IyTMr9UpQrvgZwhtGYn3yCvblNJV+yxtyQYf qEueIjFxRvJ1nbSRyG+aTgbGjEfkoRRm7OvBIeZ2KS77r8SIMe/BLetWRKkfowAh sUCHJzaRlFIopePNkmh26054+9N2Ut/Y92WKNme+A+4b6WGL/wHzQhOBw/gNKuY9 e+Jll3ACti1JCcdeaCZ7djwMValMlouBjbclMMay+lkLSyaTwGgrxmmOxle6WjQz m4RNEJ8IIOniyWrvwcYFtqeNt+avXLA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=2S7giSFnay5LcX4GuwGMRBDkU1UV74dhohrD8ub3BRY=; b=Jv3SjTrN +DlubU5o8A/fG1BDsY09CnuYYcf9cPywOMy9wF+LCZ7STrLAi31KTEA+mr+zPb+9 sdX9xtkc+ntbVNHErHuOeQjlqt5Apon9kIVd/3Ir9SRD+t6+ws13ymT+lRI7n/hg Rv2WigDsmNKzq3NnFZYp0es1LIFYdLJFCGFmP7/TYr3DXfmdml/JKu9BI8rO++1L YtDt773LsUkwVIhN5P5msP79RoqQkyfjlUEyE2VXWSsDNW5i5bsow1AzNaZFxEim HuwOXUKAsoTB+OBb/8euP/lTdNJMKtqg/fi8mG0ILzXntmpt1QdvCfwkuKudqaol CXihGyC5k8Td0Q== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8113C2030B; Thu, 8 Nov 2018 06:25:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 06:25:33 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=005b4403f13a41e482b7ed47d4e31305 Archived-At: Subject: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:25:38 -0000 --005b4403f13a41e482b7ed47d4e31305 Content-Type: text/plain This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. In favour - it's quite useful, and has fairly wide server support (including Gmail and Exchange), and at least Thunderbird as a client uses it. Against - Oracle haven't implemented it. Arguments for and against in response to this please. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --005b4403f13a41e482b7ed47d4e31305 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This is one of the open issues from imap4rev2 - which exte= nsions should be part of the mandatory baseline.

In favou= r - it's quite useful, and has fairly wide server support (including Gma= il and Exchange), and at least Thunderbird as a client uses it.

Against - Oracle haven't implemented it.

Arguments= for and against in response to this please.

Cheers,
<= /div>

Bron.

--
  Bron Gondwana, CEO, F= astMail Pty Ltd
  brong@fastmailt= eam.com


--005b4403f13a41e482b7ed47d4e31305-- From nobody Thu Nov 8 03:28: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 E047F130FEC for ; Thu, 8 Nov 2018 03:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=Zrg2dxGb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QbJpy6cN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne5HUlzE_ioc for ; Thu, 8 Nov 2018 03:28:25 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C019130FF1 for ; Thu, 8 Nov 2018 03:28:25 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9939C21F31 for ; Thu, 8 Nov 2018 06:28:24 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:28:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=XZRpBGVtevumA3C24VpmHhM4Ta69Au0Yda29Vgy zOUY=; b=Zrg2dxGbqLkjOSmvbJs3dm5MEkB7bU5JNliHhUU2Awf7fFKiopqnRSK KLaYSSzyEro8Upj/1ThqGDIk7wOF0DxPsJBiawGIEdHgxL/cl4Zm+YLQeCtnQL4P qV51zXshfwADFyrY8jDAEdsS8uIgOeoKKC/yOWcgTkU/M0TBuhMVUrNCmLkHdE/S wg7rM22n4pmTZ7mvfCO8Cqr3Aee3Dkus7rX7OwEKGJ3jSrk/PgxZFSXzESrPVtqB kRJaiWe/KxNZwvYhbpvuVUnUbSupD0fnoENa3GMa9K92P0j4nUYLRXoAK+AFsFZ4 xcKG1DdIoxGuMJ8bH08O+zNvFvLwpsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=XZRpBGVtevumA3C24VpmHhM4Ta69Au0Yda29VgyzOUY=; b=QbJpy6cN OZeTGg1wCLfrtXW+9wWeWg3etjqRqR0hE4JsnBa6fAFN4EZ2d0VzshR1ielXk2e6 e5Y2ihYjfejR7p4bEFrrlOlq5jVqK0S5MxBCrWu9Glfr/gbKoGlY5vGPkL0Ktdp7 NRD0xhE0E8FA9XybprgFaqrEgGfl9nI/3dRfPDp9NBPtbAEf3Ko2ank/0QDRKx+H fN2R+vNLkg1zCN11CTKqJj0xh9OzOtl5vrxWvPqGhAPzHtv9+sU/12UUvwnqzzde vJOa2CJzOuDo0B9yr90xjuYWNxmfyGDyENaDOqx8TdKD+6dEGYm5vCw/ufV6RpBo OSG/JKY59anoRA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4B8F12030B; Thu, 8 Nov 2018 06:28:24 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 06:27:56 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=afcdd1f5aa9d4ddd8dcd18e46a64d899 Archived-At: Subject: [Extra] imap4rev2: RFC5182 SEARCHRES X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:28:31 -0000 --afcdd1f5aa9d4ddd8dcd18e46a64d899 Content-Type: text/plain This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. In favour - it's useful to compose actions. Against - it's not widely implemented or used. Arguments for and against in response to this please. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --afcdd1f5aa9d4ddd8dcd18e46a64d899 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This is one of the open issues from imap4rev2 - which= extensions should be part of the mandatory baseline.

In = favour - it's useful to compose actions.

Against - it's n= ot widely implemented or used.

Arguments for and against = in response to this please.
<= br>
Cheers,

Bron.

--<= br>
  Bron Gondwana, CEO, FastMail Pt= y Ltd
  brong@fastmailteam.com


--afcdd1f5aa9d4ddd8dcd18e46a64d899-- From nobody Thu Nov 8 03:30: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 E04CB126BED for ; Thu, 8 Nov 2018 03:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=CX/RAars; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xcRe2cZA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFU0cAhyivZn for ; Thu, 8 Nov 2018 03:30:41 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFEB123FFD for ; Thu, 8 Nov 2018 03:30:40 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ECA6921F30 for ; Thu, 8 Nov 2018 06:30:39 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:30:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=+q9d91ZvoW2G40qz/bnqjEZvvWQsA8xlmNtsbYW DQUU=; b=CX/RAarsaQuVFWDNRsoKatIQfN+rmMHfmNBSHLgByU4+s6Qzw92zfgx jCzYcNMuJJ5cq3ZSt01zy9lROuyLqSnBiUWZaVMtf7wn83Z7wzoE2wyC4vRwajGX C65y2BAmg2lkFHEz1UqDVrruCR+MPUlBHYOx4G9SENoXVGBBLpFIWy05pycXG/c+ 9gKKmuPob974SR6OZDKo8VujXt/0ID6scgHvF1kcBgItetWpS6Y4RQTUcSE5IqrH 1NZk8MLZhYCW8H0EBT4/MbvH64eO48tb+awMnla0z4bJURCyDM7uY99iYp3fiMIN +/uZfck6A6ljdYQu9ihFl0mArmhBq/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=+q9d91ZvoW2G40qz/bnqjEZvvWQsA8xlmNtsbYWDQUU=; b=xcRe2cZA uo7+UGtPI9p75mUR+rMc9jySLv5ezOFSK4T6APC0dK8CmS4fTHJGiHqATC+gwx01 v7/52nuDX7/4RBtHJxJKf2NG/em2VjsBaJ9H+wXMUIm8sJFxEsCn73cWHNV1Zrvf i2t5B1YaoGXq3iDpxPQVPOIUrS0btG3cWnu04O6KPzHTtJ9h0tB+kuCCbdJpFPdG pzSDrW/XK1UwfD6GzatBFt/i68NBL3lkdsvnRwBcfte+u45y0vXlqIRa4pnIcZey CG4IXxF93JNgSQfN/VDp+ClbLPWW3Z4GTUWHBu6v0Couk0ZwTx8NYs+53AeaElt/ G3+mmRlm2NQ5iQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7CF562030B; Thu, 8 Nov 2018 06:30:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <8fcce54e-4d33-4f2b-92b2-0a5ec8bfec5b@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 06:30:39 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=8201d0a5890249769687a30e37f461e2 Archived-At: Subject: [Extra] imap4rev2: STATUS DELETED X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:30:42 -0000 --8201d0a5890249769687a30e37f461e2 Content-Type: text/plain This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. This was a discussion about a way to easily see if there are messages with \Deleted in a mailbox, maybe to see how much quota can be freed up. General agreement in the room was "IMAP4rev2 is for a baseline of existing standards, maybe this should be a new document, but not part of IMAP4rev2" Discussion on whether we think the general concept is useful, and whether it's so useful we should make it part of IMAP4rev2 in response to this please. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --8201d0a5890249769687a30e37f461e2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This is one of the open issues from imap4rev2 - which= extensions should be part of the mandatory baseline.

Thi= s was a discussion about a way to easily see if there are messages with = \Deleted in a mailbox, maybe to see how much quota can be freed up. = ; General agreement in the room was "IMAP4rev2 is for a baseline of exis= ting standards, maybe this should be a new document, but not part of IMA= P4rev2"

Discussion on whether we think the general concept = is useful, and whether it's so useful we should make it part of IMAP4rev= 2 in response to this please.

Cheers,

Bron.

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


--8201d0a5890249769687a30e37f461e2-- From nobody Thu Nov 8 03:32: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 3D6C1126BED for ; Thu, 8 Nov 2018 03:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=H0nET6T2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AYq485oL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxI0de6tPtVj for ; Thu, 8 Nov 2018 03:32:22 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF34123FFD for ; Thu, 8 Nov 2018 03:32:21 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3B9E421D1E for ; Thu, 8 Nov 2018 06:32:21 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:32:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=PpCPNu1WZJptrS3PTstLAQbvCSEIpbqOmUruiGr zVSg=; b=H0nET6T2GwAoJYtxwYoIV030lgmyxygxGRwaF6X+FTqKhZO8Rx+Qsp4 TDCUIDrDtJQqWFZ4cK4dp/fxTNxoHyt+lBm8C7f7PEhd7tDuJva1vpIzuRFOv/NZ lP2hh2P2x6RH6bRVDbxVxktuNZfjxdEYlN88re5qUFOVu0HSDRloK8zVjAUuVPRG p2fTsRCrL5C7MeUtbgCdQ07FZ6te/Oulz90qhky6c/kkDvb5IUyDbVdgY7uD03wU lfpRfeY4pT4y8bRb73qcRTeJuh/kw4YBhl0PZygddIeVziuvvYgTd84biposoG7S qcZS2PVVEZwCZ8TFV/A3g/4iPubxdRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=PpCPNu1WZJptrS3PTstLAQbvCSEIpbqOmUruiGrzVSg=; b=AYq485oL jbSP1z8N9TxkuJsSpp7jnF7oVM9ZzPtoHHX+FxqReBfXPryEQPm6vjPjvocQUrIq DfUYGYjh3rRniGo81z9p6A83xM5GLLnQNO2qeJyI9hXssaFZsxAU6civSmZsCv0Y eVrbHP1ljxZZMw9VyIyzn4xFM2Aj9L6Me7mD+mEgnQl/spo9NBlFMPXk15NowzvP JgfzcvNt5Njg+ly9h1vpiIGi8UsyKOnqyx3eayil3Tl2xohJNsdgGGawxQXtccwm 2vOx6ccFl5sA0ojLic95JMxLcrT+qU3j8drkEQjCTb7tdy0CuVfj/9BGrk/4VKVl lE94QTr1UoVhZA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 08E2B2030B; Thu, 8 Nov 2018 06:32:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <6f804b07-35bd-4ca3-ad84-bf69daeaa6e9@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 06:32:20 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=c092c007c7824a8cae7bd373ab1d39fc Archived-At: Subject: [Extra] imap4rev2: RFC8474 OBJECTID X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:32:23 -0000 --c092c007c7824a8cae7bd373ab1d39fc Content-Type: text/plain This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. In favour - it's very useful for client efficiency, and maps to very popular Gmail extensions. Against - it's very new, and not widely implemented yet. Arguments for and against in response to this please. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --c092c007c7824a8cae7bd373ab1d39fc Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This is one of the open issues from imap4rev2 - which= extensions should be part of the mandatory baseline.

In = favour - it's very useful for client efficiency, and maps to very popula= r Gmail extensions.

Against - it's very new, and not wide= ly implemented yet.

Arguments for and against in response= to this please.

Cheers,

Bron.
=
--
<= div class=3D"signature">  Bron Gondwana, CEO, FastMail Pty Ltd
<= /div>
  brong@fastmailteam.com

=
--c092c007c7824a8cae7bd373ab1d39fc-- From nobody Thu Nov 8 03:34: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 E3A1A130E6A for ; Thu, 8 Nov 2018 03:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=P44L5wTX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yr7mYy2D Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crZyD__QrTi3 for ; Thu, 8 Nov 2018 03:34:41 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE434123FFD for ; Thu, 8 Nov 2018 03:34:41 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 95D2421F24; Thu, 8 Nov 2018 06:34:39 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:34:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:cc:subject :content-type; s=fm1; bh=Q++S0A/54a+pwjoBLNWCk2JF30Wm62eZJf858Wb Yf14=; b=P44L5wTXxDW8ZE8GxqB1d72GPXyWWzzOpPIhNU5DulUR1GgOX00yEKU e6bShdtlN+3odgzrqtvkDuAPZqbU3T4dv2rX2d8pLzufegr6zXFVuE1Ddw68L9VR t4EqsqCsqxi5XelIfe5w3peC4tEdzLns8Vlcoy/QyBdcHtVA6hsBOd+uZLJuOWR+ hj/YUxK/+ws/Nhyl0mdC+3sZETSqGGUoc2deWgLF8R6jTQcMwyrmZ7PyVKeKda0/ nfRBUYkriEPoyTeNWSJsatuIdYabGsxu57tH9iEP+RGg9arK4bL5gAQL4D0aE36G 674QQpWYZW/DiH67y8EdfpHibtXe0Tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Q++S0A/54a+pwjoBLNWCk2JF30Wm62eZJf858WbYf 14=; b=yr7mYy2D6oOhDAQ/6C6wtaGg7VPdJ3UC5P3anRyaQKMIf3XsE7Vvb5PRy RosPTX51kzb1Cg4uVwH+2WRyMqQJeXQ5EVvucLQi0Rt+uPeGNhXT5+q/fkx0I1j9 6DDFVw30o8MUZkrEixQUTK7yAsomqREKfEwiRCNM7cNL84laL0nR47D2/x2mvHH7 1vC1o3hqwf79fGuzguhQh/QzOpmi5x986QNTGVqj9CNXDWwLD/3LNlvuDYOwEumh vGANdMowcCaTf86UxQOt/Ky2MvH2pLGwib9dQv2H4M0+wL/qfsaNy2zXLKeJMide QSx+9/HMvFJc6yBmSCyUh6ThvFm9A== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 436242030B; Thu, 8 Nov 2018 06:34:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <7a10e2be-5192-4955-8bd8-aa81a18a240b@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 06:34:38 -0500 From: "Bron Gondwana" To: extra@ietf.org Cc: "Alexey Melnikov" Content-Type: multipart/alternative; boundary=d6c84e9b80dc40598cd9a34a41d69e96 Archived-At: Subject: [Extra] imap4rev2: RFC3516 BINARY X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:34:43 -0000 --d6c84e9b80dc40598cd9a34a41d69e96 Content-Type: text/plain This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. This one might need some clarification from Alexey - I'm not sure why it's not trivially obviously a good thing to include. There was some stuff about "ability to fetch the decoded size" discussed, but I didn't capture good notes. Arguments for and against, or additional discussion, in response to this please. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --d6c84e9b80dc40598cd9a34a41d69e96 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This is one of the open issues from imap4rev2 - which= extensions should be part of the mandatory baseline.

Thi= s one might need some clarification from Alexey - I'm not sure why it's = not trivially obviously a good thing to include.  There was some st= uff about "ability to fetch the decoded size" discussed, but I didn't ca= pture good notes.

<= div style=3D"font-family:Arial;">Arguments for and against, or additiona= l discussion, in response to this please.

Cheers,
Bron.

--
  Bron Gondwana, C= EO, FastMail Pty Ltd
  brong@fast= mailteam.com


--d6c84e9b80dc40598cd9a34a41d69e96-- From nobody Thu Nov 8 03:37:21 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 9E200130E6A for ; Thu, 8 Nov 2018 03:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=eX4gXVcn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lKeNSQdK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah5emqESwJxe for ; Thu, 8 Nov 2018 03:37:18 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B88123FFD for ; Thu, 8 Nov 2018 03:37:18 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ED14D21FF5 for ; Thu, 8 Nov 2018 06:37:15 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:37:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=FRJ0RBpIlrpsHXw5sCRLcsc5IWAsYQj3xkuYcrJ g5oc=; b=eX4gXVcnS+5Q7JC7nUzjiu7RZjKnpsLVeN0eLy2KieHRHWxaRPQgRK6 gMJ/rCDjC0a/H5/5ftw/k2HtZCZIM8b4ugalS4Z6PQaDV49Zf/P1FDk9MD/AjrAD ljoerueW99pbsltdohub8xAK9AvgTJsq5DMXYXp2caot2niOrkPYPXUT+WqdArx1 1TCg+zLOM8b+geStdv0dpJDFaMqyQqSOZ/wJECOXLnHvKIVVcyNWG82w3Yv/PqUz 5323I5Ic+DOeJvvBCNdFTTBNFPAY3N4KEqo9oBBB924LDs3jWkLIh5v8cX+Wy2jS 2XJzm9QBUVxqlBCnZrn0EVJ2TeCSTsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=FRJ0RBpIlrpsHXw5sCRLcsc5IWAsYQj3xkuYcrJg5oc=; b=lKeNSQdK BQkzCKRPfU9Rd0EHFjRbdmFXtClkBMbd6ZKbIhTUyaog7aHktbD/pgN/njYSPc3U PWdS30b9qV8QfTURTA0FhRD9OqWwCE5LtZ/K9y9ut9U2fPPTyQ4nkHNErJyYi0x8 1hkd/OM7l7CUU1QWdDgJQF3udbf3jvfmpCyyKNX0MfCh7H9J0nvdMrLTzoaSLaUn B0sLI5rCi1y94RIQesY66mozzqa5KuqUcFb7Y2wW2mo1iJAhmGILrDCAWcNveTM3 CwUqjmhVRk7c9TwJuecCDwECGo2mypxPuN+9tcMN3k5Ngvx5vhVoAxb//aRSek5s oh+ZehReA8VaEQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 60EA52030B; Thu, 8 Nov 2018 06:37:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 06:37:14 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=43d29424c7e742f3a1af35c4a7ff9d8a Archived-At: Subject: [Extra] imap4rev2: disallow "RENAME INBOX" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:37:20 -0000 --43d29424c7e742f3a1af35c4a7ff9d8a Content-Type: text/plain This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. This one came from me. I dislike the weirdness of "RENAME INBOX Archive-foo" because of its special behaviour regarding sub mailboxes, and the auto-recreation of the source mailbox, and all that jazz. Argument in favour of keeping it - it's easier for clients, which is part of the point of IMAP4rev2 - servers have already suffered through this the first time, and will need to keep IMAP4rev1 support for a while anyway probably. Arguments for and against in response to this please. Also arguments about the suggested middleground saying that clients "SHOULD NOT" use it, or something like that - with the flip side that servers MAY reject rename of INBOX. We're particularly interested in "I use this, and want to keep it" from either servers that see their clients doing it, client authors, or even users! Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --43d29424c7e742f3a1af35c4a7ff9d8a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This is one of the open issues from imap4rev2 - which= extensions should be part of the mandatory baseline.

Thi= s one came from me.  I dislike the weirdness of "RENAME INBOX Archi= ve-foo" because of its special behaviour regarding sub mailboxes, and th= e auto-recreation of the source mailbox, and all that jazz.

Argument in favour of keeping it - it's easier for clients, which is = part of the point of IMAP4rev2 - servers have already suffered through t= his the first time, and will need to keep IMAP4rev1 support for a while = anyway probably.

Arguments for and against in response to= this please.  Also arguments about the suggested middleground sayi= ng that clients "SHOULD NOT" use it, or something like that - with the f= lip side that servers MAY reject rename of INBOX.

We're particularly interested in "I use this, a= nd want to keep it" from either servers that see their clients doing it,= client authors, or even users!

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMa= il Pty Ltd
  brong@fastmailteam.c= om


--43d29424c7e742f3a1af35c4a7ff9d8a-- From nobody Thu Nov 8 03:44: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 4617F130E46 for ; Thu, 8 Nov 2018 03:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=Ks4uuEKe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CxOXVBcZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNLHYfyekcXE for ; Thu, 8 Nov 2018 03:44:23 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6684128CB7 for ; Thu, 8 Nov 2018 03:44:22 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 18BAE221C9 for ; Thu, 8 Nov 2018 06:44:22 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:44:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=YuhEpOWkAtIQSBE3UD4OC6sMAlgNla4vBGyzcbi FUtM=; b=Ks4uuEKenlFYH6zt3EN9WnzJ6WXN9Yk3kx2wduePwyiYPOHcSJV9onC gO4f8SbRgzmD7PU67t4O9kQM0VOIqN84bXqoqinYFUQKdyRwSgGSL+W+I80lqWWv 6VCqEIovyLEzAUwIiHX+CNZPQUI/Qql1fjLodvpxkICScuo1sGaRFNBRvm617fcE vknyGVuGfXPIBCeEWpu5Q859/1g4QROb2NkI+7FDEyml/YWtT/7pl8NP0RqvkqZR imOLNLSRuznM0eU1LDZ47Y1syOtxOTi01otMwyvLEGpRyU2szSTz1G12UPm6C5Xe cMRKJ7QCZ+6TzfeP7Qf8cwkKIpDOjJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=YuhEpOWkAtIQSBE3UD4OC6sMAlgNla4vBGyzcbiFUtM=; b=CxOXVBcZ yPRKh+XwgBuT0tbpwExFmMMALKdANhmskctngVYbrEYsIynOW63+nbqf5rFPN0nU 7O/Cd0N78w+PmyBmvgli+o3rPjMd0AOoTvOx4o2vgLmB7Y14V/QRzNPZZs5sF/2j 1d55wiB24fZxPwg3YN9RC7uQ8J3FbM0UC0G5HwMo5eQXqcGg7a2ODYlRtwo9RO3H uhpLcV7AmHeVlMccdfBRGk+lyxTIbgcmTtYc0SuchU3q7e6BxgQx8xWaCXwxbfz7 hndOVA5Wd67Wtsqz3OwAT09kaqrx10AoQ4zaXHvP0VY1h8RoeqVDyCrbvsX+yJgu UKIMupCTysOM9w== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 86F6D2030B; Thu, 8 Nov 2018 06:44:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 06:44:17 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=46c61fdd9b93455897b90f50d1a18e72 Archived-At: Subject: [Extra] imap4rev2: draft-ietf-extra-imap-replace X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:44:24 -0000 --46c61fdd9b93455897b90f50d1a18e72 Content-Type: text/plain This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. This one isn't even standard yet, but it's a nice pair with MOVE as a way to avoid running into intermittent issues near QUOTA when you're doing things like editing Drafts, and it's similarly easy to implement on top of existing actions. Arguments for and against in response to this please. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --46c61fdd9b93455897b90f50d1a18e72 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This is one of the open issues from imap4rev2 - which= extensions should be part of the mandatory baseline.

Thi= s one isn't even standard yet, but it's a nice pair with MOVE as a way t= o avoid running into intermittent issues near QUOTA when you're doing th= ings like editing Drafts, and it's similarly easy to implement on top of= existing actions.

=
Arguments for and against in response = to this please.

Cheers,

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

<= br>
--46c61fdd9b93455897b90f50d1a18e72-- From nobody Thu Nov 8 03:50:18 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 82F6E130F34 for ; Thu, 8 Nov 2018 03:50:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154167781653.31285.15509544853786119051.idtracker@ietfa.amsl.com> Date: Thu, 08 Nov 2018 03:50:16 -0800 From: IETF Secretariat Archived-At: Subject: [Extra] Milestones changed for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:50:16 -0000 Deleted milestone "Submit "64bit body part and message sizes in IMAP4" to IESG as a Proposed Standard". URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Thu Nov 8 03:58:04 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 73426130E6A for ; Thu, 8 Nov 2018 03:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=V1aHe0Ty; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WEbngP0P Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr4jq3DuIKY8 for ; Thu, 8 Nov 2018 03:58:02 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CF6123FFD for ; Thu, 8 Nov 2018 03:58:02 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D2E8D220B9 for ; Thu, 8 Nov 2018 06:58:00 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:58:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=BRf0zKvrm36JSjihpdVdLNjC4aSYqgXZ/Gk9m2a WYBQ=; b=V1aHe0TyWRClpuKQBdk9A8ZOHw0ZeVIPNmcCbkT4i1ZbSxVQtpFPcd+ 0lbcCC3K+qZJmg0QxptaQSuqybXWns4hCc7oU5ZoO4jZ+Iq6bI5XWY8lsaJPEzY+ P3JEN32cMKSHiWree/aq+5yk38gk4ZWo/C/5qgRYEE6xAzzN7d0tCjwv6yEN06Gq TSyUYCIZzogOj6xJ8fzcHCFlzFKGmoKI5nO4pVYSOdeih/L8P78v7SSQytdqbvHR AUkVfLDed7orhpvoZVP8USd9b9bW2ua73/KyZpmk917+zWGIZhwTqqPwa9c+w0L9 1zAFXKIH9gb9RPDXoetTGsOLkTz+eBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=BRf0zKvrm36JSjihpdVdLNjC4aSYqgXZ/Gk9m2aWYBQ=; b=WEbngP0P 80cSozCoaNKWCdMhCZsXsUPLChNTHdhPuMB3rZhYsmYerZps4hhtg/tjWMgMvHpE pvlIEXnhJsj0Ayx0EzwUxUVzA4MATJSlzayQOwC6G38eB5ox7hQfuNjj+W7CvHti TqVSUR2X/mbCR5Q+nOkwalUDGfGCz2apvUShWfBZTqeXfQs78KND7XRj/m3j9mvV aczGn0wJQhmEiy1a/3JxLABohWpIyhURTmcI6kRa2RlFwo/lbiuRjP+hk0Vu3yjz Nuv6TQCIv0dzYHQH/XCjPHqVWeplY0g0Edk5s8ZrfbeoJV56+TL4QuaPGVHNG3jq RAjWJlr9l+z3Rw== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 63D1F2030B; Thu, 8 Nov 2018 06:58:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 06:57:59 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=4c7fcfc41aba4940a6f0ae4c8021e3fd Archived-At: Subject: [Extra] Call for adoption - work regarding EAI and Sieve X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:58:04 -0000 --4c7fcfc41aba4940a6f0ae4c8021e3fd Content-Type: text/plain >From today's meeting, Stephan Bosch has kindly offered to write up a document on the interactions of EAI and Sieve. Unless I see objections to this work, I will adopt the draft into the working group when it appears. I've set a milestone for February next year for when we expect the first draft to be complete, giving us time to review it before the Prague meeting. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --4c7fcfc41aba4940a6f0ae4c8021e3fd Content-Type: text/html Content-Transfer-Encoding: quoted-printable
From today's meeting, Stephan Bosch has kindly offered to = write up a document on the interactions of EAI and Sieve.

Unless I see objections to this work, I will adopt the draft into the w= orking group when it appears.

I've set a milestone for Fe= bruary next year for when we expect the first draft to be complete, givi= ng us time to review it before the Prague meeting.

Cheers,=

Bron.


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


--4c7fcfc41aba4940a6f0ae4c8021e3fd-- From nobody Thu Nov 8 04:00: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 2AA8B130DE1 for ; Thu, 8 Nov 2018 04:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=qo2vWQN5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j2VmqfZ7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lQrevBaUg-e for ; Thu, 8 Nov 2018 04:00:07 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D95C123FFD for ; Thu, 8 Nov 2018 04:00:07 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0C1432223C for ; Thu, 8 Nov 2018 07:00:06 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 07:00:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=b/U0pCAGoFa9tjCIbvfruCWAI2DTNzf48eB9sF3 p9PA=; b=qo2vWQN5Pv+B9ry6X6xh3/HMfGRKtokR4i7Ayb0y7c+CiVuGR59k7uq QzIvaZzMxAqAxIcdi37Od9Da3RgSSHSFQuEtt60hHnSBya9e92h/1tlYwTTlOf2P H6zBmBX9hkF5SmhGAzYpoj0JhYcBf9xuolE31FwGtWz4GT9lFSChFKTwcvEz3yMj AaF0L0DIqWNzCFo79yl+vKniUg7Ie9dMokutyvbQXEtVMYrbTstXM4qPXfcJO5mW Vx0YhbG+izBiwDs0Ed6VK3+LHd26hZhboAXh9mcyrXJPZo54hDnp24vX9gna8GMD s4TD/N7A9oAjxLrhQREzBb9E6sq3eBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=b/U0pCAGoFa9tjCIbvfruCWAI2DTNzf48eB9sF3p9PA=; b=j2VmqfZ7 JC+26yFfy8EBd4QAXmQxjL3ip+r4ue6aXpUnks8cnxrP5uA8VYwp1Ut0+ZhA6xnd OKVVbs68R835zal+uzh49gSyJVR0gb4AJbZD5SBAzzYz1BK/dCv7pTdn4wIC3ECn 64JdKNheNSimcdweAHLCksTTeHElv2fMjIJFrxU+gFbjyuyGdkuNO/w6QnTwx98j RuEZ2m8FipA0lpQugQGO2IWbKLfM07ayXS2QYum50cTKDkw0kY38XNeXL6m8fpgq Bz+zKmM9wHJNAmRDKCPMmibII/YOMeW4u2XqctHR65paaPrmt2OQY4+lL/xuVtmK tIBGI4TwR5X1hA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 55C8D2030B; Thu, 8 Nov 2018 07:00:05 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <5ae4158b-281e-4ff6-92d2-7b3cc8056f15@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 07:00:02 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=460208b39a674b01ac81d34d54f6e7cf Archived-At: Subject: [Extra] Call for adoption and author(s) - QUOTA-BIS X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 12:00:13 -0000 --460208b39a674b01ac81d34d54f6e7cf Content-Type: text/plain >From today's meeting, Alexey has started work on this, but would be very happy to hand the source documents over to a new editor. If anybody would like to take on the task of updating the QUOTA documents, please respond to this thread. Further, unless I see objections to this group taking on the work of new QUOTA specifications, I will accept the document when it's complete. I have set a milestone of February next year for an initial draft or drafts to be produced, so we have time to read them before Prague. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --460208b39a674b01ac81d34d54f6e7cf Content-Type: text/html Content-Transfer-Encoding: quoted-printable
From today's meeting, Alexey has started work on this, but= would be very happy to hand the source documents over to a new editor.&= nbsp; If anybody would like to take on the task of updating the QUOTA do= cuments, please respond to this thread.

Further, unless I= see objections to this group taking on the work of new QUOTA specificat= ions, I will accept the document when it's complete.

I have set a milestone of February next year= for an initial draft or drafts to be produced, so we have time to read = them before Prague.

Cheers,

Bron.

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


= --460208b39a674b01ac81d34d54f6e7cf-- From nobody Thu Nov 8 04:04: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 3948D13105F for ; Thu, 8 Nov 2018 04:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=B3NrvCBw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FLl2eytp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg5vXBnKUSRm for ; Thu, 8 Nov 2018 04:04:00 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31809130FDA for ; Thu, 8 Nov 2018 04:04:00 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 21C6B2206B for ; Thu, 8 Nov 2018 07:03:59 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 07:03:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=bxUydaOcjLURM9X+71asqcrpVO+O aGJlbttEJzxxD3E=; b=B3NrvCBwGmbl7+KwpwiiLDsEXs3oJi6jkZRHTjQFn4jU YBGXKjk0Y08qdX8RIsLppWoVgVyVYSQm9ZAvKg0xy19ay5daWfyHs82Vo5VtIXTe 4lpTdR7EvjKGDtUk1iYPZYFGthj7kpajU8nIjuP3yiSQJfoFoTtsxnax0jElFFxG KYQeqJ16La7SqQfx4jTW9LHJSaSNHESWErgT/Jiak94nh7UkkvRZjsqGZrdKJkU1 aoYumXK2X/Gil08XKAZ2t79/Bi4oH7yc+vKkUC3xAXDuq4t/7vCN+juyuycVCjA6 f7ziwD7xUCTY36vPD9fqSdKtTg+jkQvMee9HjnLeYA== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bxUydaOcjLURM9X+7 1asqcrpVO+OaGJlbttEJzxxD3E=; b=FLl2eytpTUDg3QZ1DuZOUeB2SxrsYDXm6 h6HEUm7HfXwX2HudhwBVtYVdtKPrmNEjQ0SRh14rRU8YttqdQb/0ysSWEc6oevE/ n1P8pAdEaLtDQO/8MxXgZi7pmFGbOE6LNDgbMsV4h/yTU+9oQtvsB74L/0mpZdC6 nopVx1b13v+nDxJe4fa4tOA63DFPK5qdGITapFxH1mZLRO6QH1Lszo1BGlF2BQm5 HWGj6JqLZYlBib88D2du9YP1UpcPgaBe63z2W5dBhpbpiBrHJtVKSY5g1MdEBE5q AhOWPQGGWdpPPx1tGvBzIpPIUcWZ4As9o+GRW/XPWCdzApgvEFuug== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AFE732030B; Thu, 8 Nov 2018 07:03:58 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: <222011778.12006.1541435419815@appsuite.open-xchange.com> References: <222011778.12006.1541435419815@appsuite.open-xchange.com> Date: Thu, 08 Nov 2018 07:03:58 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=9d4b4e31d5ef4c9cb655bad930581416 Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 12:04:07 -0000 --9d4b4e31d5ef4c9cb655bad930581416 Content-Type: text/plain Hi Michael, Thanks again for submitting this, and apologies that I haven't done a thorough review yet - it's on my todo list and I expect to do so soon. The ONLY remaining question was length. 200 is good, but JMAP says 255 and consistency will make it better. Unless you have a strong reason to lock it down to 200, would you consider changing it to "no more than 255 octets" with an understanding that there's no requirement that servers have to store that much, just that clients must be willing to accept that much. That will keep everything consistent. Other than this, we believe we're ready to take this document to working group last call, which I intend to do once I've heard back from you - it's easy to fix this up during last call. Thanks for your work and for getting us the update in time for this meeting. Cheers, Bron. On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: > I've submitted an update to the (formerly snippet, now) preview draft incorporating feedback received from this list and other implementers. > > Main change is the name - this is now "PREVIEW" instead of "SNIPPET". Also, increased recommended preview size to 200 characters (previously: 100). > > Will not be able to remotely join IETF 103 meeting as I am traveling, but wanted to make sure this draft was updated before then. > > michael > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --9d4b4e31d5ef4c9cb655bad930581416 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Michael,
Thanks again for submitting this, and apologies that I haven't done a t= horough review yet - it's on my todo list and I expect to do so soon.

The ONLY remaining question was= length.  200 is good, but JMAP says 255 and consistency will make = it better.  Unless you have a strong reason to lock it down to 200,= would you consider changing it to "no more than 255 octets" with an und= erstanding that there's no requirement that servers have to store that m= uch, just that clients must be willing to accept that much.  That w= ill keep everything consistent.
<= br>
Other than this, we believe w= e're ready to take this document to working group last call, which I int= end to do once I've heard back from you - it's easy to fix this up durin= g last call.

Thanks for your work and for getting us the = update in time for this meeting.

Cheers,

Bron.

On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote:
<= blockquote type=3D"cite" id=3D"fastmail-quoted">
I've submitted an update to the (formerly snippet, now) previe= w draft incorporating feedback received from this list and other impleme= nters.
 
Main change is the name - this is now "PREVI= EW" instead of "SNIPPET".  Also, increased recommended preview size= to 200 characters (previously: 100).
 
Will not be a= ble to remotely join IETF 103 meeting as I am traveling, but wanted to m= ake sure this draft was updated before then.

michael
<= /div>

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


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


--9d4b4e31d5ef4c9cb655bad930581416-- From nobody Thu Nov 8 04:09: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 D5FD0130E6A for ; Thu, 8 Nov 2018 04:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=ppoEOTbR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wMqlSFxx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22icVAoQgv_Z for ; Thu, 8 Nov 2018 04:09:21 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F21130E46 for ; Thu, 8 Nov 2018 04:09:21 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9909F21FC5 for ; Thu, 8 Nov 2018 07:09:20 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 07:09:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=4ipOAUiRLu00tfFCcmrsbZkyrJ3WXp3AxhLyotU iv3E=; b=ppoEOTbRotamZXcg8+lEOprM/GFtOy8YWekZcHVl9bL9LrWTjwc8tnA jOuMQajLiBD2GV0nAtqubbv8F08ZaTRiC5PtafkXNyhUQYPJJFhyEVdmkIdKhKIg D6WvdYS11qC5Q/5Fu4cXJRTvXhAGa381QhcjguVD/dGMMeQ49RecXVYSBALoKf+b 6lM5mR8Y7AUGSufikAsnxZFDrE41oTPnukjm0yn87lwwa06vlB+qJFrwaa5Pus5H HKFS47quM2znpLppxjJXByu3DVPGHVzHkliQy+hVT2LswebezqqB8HOVcch6NGsZ 6eCGq/A5/HRVyeqEz54bJyHv6wTamlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=4ipOAUiRLu00tfFCcmrsbZkyrJ3WXp3AxhLyotUiv3E=; b=wMqlSFxx PS4S80pimx6DE6kP3BidWknszviB1dTDO/qZOVaNY2cVQCcHsSpbiVbsb8k0d8rP FMiQ4cwndeic8C22obqZvNcMgMUY4Iw9Zz/4CcxRwAfNSwxeKetdtZjL5IPWpJjG UL9v3NhmyWixrZK3+iibR24mfKCyuf9CJPq2TROD4JucW4IYZ7BnZabNUFgjUcqA y1ZgizgvcAjN1dd5VQK6A3Xck0VJk2xd0WsgVOwO2QHQj5R2GhlnHrtdKD22FPok uFv/S+bce74pVkQTxmHWN+XM9oxEMPafetnDfjW2CY3RgKpVojbpzh1npvs4nuh1 arvEPf3dSaIYug== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EBBB42030B; Thu, 8 Nov 2018 07:09:19 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 08 Nov 2018 07:09:15 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=3255d202ad6e47aaae63999c04773a79 Archived-At: Subject: [Extra] Discussion of charter and SMTP related work X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 12:09:23 -0000 --3255d202ad6e47aaae63999c04773a79 Content-Type: text/plain Apologies for the flood, this is the last one, I promise! At least, it's the last checkbox ACTION item I have from today's meeting... Hi All, When we chartered this working group, we had a flood of work, and we deliberately excluded SMTP and MIME from our charter in order to stay focused. The flood has mostly abated now, and we find ourselves considering whether to open up our scope to accept some other work which has interest (fixing the fact that 822 is an obsolete INTERNET STANDARD replace by 5322 which is only a DRAFT STANDARD - which doesn't even exist any more, and also fixing accumulated errata). There's also some MIME work which could be tightened up and better described. The choices before us are roughly: a) spin up a new working group to take on the SMTP/MIME work b) recharter this group It's expected that much the same people will be involved regardless, so we'd be keen to hear arguments for or against these options. Please reply to this email with your opinions. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --3255d202ad6e47aaae63999c04773a79 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Apologies for the flood, this is the last one, I promise!&= nbsp; At least, it's the last checkbox ACTION item I have from today's m= eeting...

Hi All,

When we chartered this w= orking group, we had a flood of work, and we deliberately excluded SMTP = and MIME from our charter in order to stay focused.  The flood has = mostly abated now, and we find ourselves considering whether to open up = our scope to accept some other work which has interest (fixing the fact = that 822 is an obsolete INTERNET STANDARD replace by 5322 which is only = a DRAFT STANDARD - which doesn't even exist any more, and also fixing ac= cumulated errata).  There's also some MIME work which could be tigh= tened up and better described.

The choices before us are = roughly:

a) spin up a new working group to take on the SM= TP/MIME work
b) recharter thi= s group

It's expected that much the same people will be inv= olved regardless, so we'd be keen to hear arguments for or against these= options.  Please reply to this email with your opinions.
=

Thanks,

Bron.

=
--
  Bro= n Gondwana, CEO, FastMail Pty Ltd
&nbs= p; brong@fastmailteam.com


--3255d202ad6e47aaae63999c04773a79-- From nobody Thu Nov 8 06:02: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 580F4128B14 for ; Thu, 8 Nov 2018 06:02:39 -0800 (PST) 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 CDyCQq7zCArv for ; Thu, 8 Nov 2018 06:02:32 -0800 (PST) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 14DFC126BED for ; Thu, 8 Nov 2018 06:02:32 -0800 (PST) Received: from pear.dyn.dovecot.net (unknown [193.209.119.1]) by tss.iki.fi (Postfix) with ESMTPSA id 32B1A2B3CCA; Thu, 8 Nov 2018 14:02:30 +0000 (UTC) From: Timo Sirainen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0ABD5A98-CAC1-4A86-9999-D00AA042D7A4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 8 Nov 2018 16:02:29 +0200 In-Reply-To: Cc: extra@ietf.org To: Bron Gondwana References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Extra] imap4rev2: disallow "RENAME INBOX" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 14:02:39 -0000 --Apple-Mail=_0ABD5A98-CAC1-4A86-9999-D00AA042D7A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Nov 2018, at 13.37, Bron Gondwana wrote: >=20 > This is one of the open issues from imap4rev2 - which extensions = should be part of the mandatory baseline. >=20 > This one came from me. I dislike the weirdness of "RENAME INBOX = Archive-foo" because of its special behaviour regarding sub mailboxes, = and the auto-recreation of the source mailbox, and all that jazz. >=20 > Argument in favour of keeping it - it's easier for clients, which is = part of the point of IMAP4rev2 - servers have already suffered through = this the first time, and will need to keep IMAP4rev1 support for a while = anyway probably. >=20 > Arguments for and against in response to this please. Also arguments = about the suggested middleground saying that clients "SHOULD NOT" use = it, or something like that - with the flip side that servers MAY reject = rename of INBOX. >=20 > We're particularly interested in "I use this, and want to keep it" = from either servers that see their clients doing it, client authors, or = even users! Dovecot has always been rejecting this when used with Maildir format = (other formats allow it): a rename inbox plop a NO [CANNOT] Renaming INBOX isn't supported (0.001 + 0.000 secs). I've never heard anyone complain about it. I've a feeling Courier is rejecting it as well, but can't check now = easily. --Apple-Mail=_0ABD5A98-CAC1-4A86-9999-D00AA042D7A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 8 Nov 2018, at 13.37, Bron Gondwana <brong@fastmailteam.com> wrote:

This is one of = the open issues from imap4rev2 - which extensions should be part of the = mandatory baseline.

This one came = from me.  I dislike the weirdness of "RENAME INBOX Archive-foo" = because of its special behaviour regarding sub mailboxes, and the = auto-recreation of the source mailbox, and all that jazz.

Argument in favour of keeping it - = it's easier for clients, which is part of the point of IMAP4rev2 - = servers have already suffered through this the first time, and will need = to keep IMAP4rev1 support for a while anyway probably.

Arguments for and against in = response to this please.  Also arguments about the suggested = middleground saying that clients "SHOULD NOT" use it, or something like = that - with the flip side that servers MAY reject rename of INBOX.

We're particularly interested in "I = use this, and want to keep it" from either servers that see their = clients doing it, client authors, or even users!

Dovecot = has always been rejecting this when used with Maildir format (other = formats allow it):

a rename = inbox plop
a NO [CANNOT] Renaming INBOX isn't supported (0.001 = + 0.000 secs).

I've never heard = anyone complain about it.

I've a = feeling Courier is rejecting it as well, but can't check now = easily.

= --Apple-Mail=_0ABD5A98-CAC1-4A86-9999-D00AA042D7A4-- From nobody Thu Nov 8 06:08: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 A899B126CB6 for ; Thu, 8 Nov 2018 06:08:04 -0800 (PST) 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 0-T4xlxu5TCh for ; Thu, 8 Nov 2018 06:08:02 -0800 (PST) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB81126BED for ; Thu, 8 Nov 2018 06:08:02 -0800 (PST) Received: from pear.dyn.dovecot.net (unknown [193.209.119.1]) by tss.iki.fi (Postfix) with ESMTPSA id 495CC2B3CCA; Thu, 8 Nov 2018 14:08:01 +0000 (UTC) From: Timo Sirainen Message-Id: <39901AFF-A720-4251-873C-A9604B5B5154@iki.fi> Content-Type: multipart/alternative; boundary="Apple-Mail=_4E223FDE-1728-4A08-9064-9D7CA909A038" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 8 Nov 2018 16:08:00 +0200 In-Reply-To: Cc: extra@ietf.org To: Bron Gondwana References: <222011778.12006.1541435419815@appsuite.open-xchange.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 14:08:05 -0000 --Apple-Mail=_4E223FDE-1728-4A08-9064-9D7CA909A038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hmm. You're talking about octets and so far Dovecot (and Michael's = draft) has been talking about characters. So with a maximum of 4 bytes = per UTF-8 character and Dovecot's current 100 character limit, it could = already be sending 400 octets.. We chose characters rather than octets because it makes more sense from = the client's point of view to show approximately the same amount of text = no matter what characters are being used. > On 8 Nov 2018, at 14.03, Bron Gondwana wrote: >=20 > Hi Michael, >=20 > Thanks again for submitting this, and apologies that I haven't done a = thorough review yet - it's on my todo list and I expect to do so soon. >=20 > The ONLY remaining question was length. 200 is good, but JMAP says = 255 and consistency will make it better. Unless you have a strong = reason to lock it down to 200, would you consider changing it to "no = more than 255 octets" with an understanding that there's no requirement = that servers have to store that much, just that clients must be willing = to accept that much. That will keep everything consistent. >=20 > Other than this, we believe we're ready to take this document to = working group last call, which I intend to do once I've heard back from = you - it's easy to fix this up during last call. >=20 > Thanks for your work and for getting us the update in time for this = meeting. >=20 > Cheers, >=20 > Bron. >=20 > On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: >> I've submitted an update to the (formerly snippet, now) preview draft = incorporating feedback received from this list and other implementers. >> =20 >> Main change is the name - this is now "PREVIEW" instead of "SNIPPET". = Also, increased recommended preview size to 200 characters (previously: = 100). >> =20 >> Will not be able to remotely join IETF 103 meeting as I am traveling, = but wanted to make sure this draft was updated before then. >>=20 >> michael >>=20 >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >>=20 >=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=_4E223FDE-1728-4A08-9064-9D7CA909A038 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hmm. = You're talking about octets and so far Dovecot (and Michael's draft) has = been talking about characters. So with a maximum of 4 bytes per UTF-8 = character and Dovecot's current 100 character limit, it could already be = sending 400 octets..

We chose characters rather than octets because it makes more = sense from the client's point of view to show approximately the same = amount of text no matter what characters are being used.

On 8 Nov 2018, at 14.03, Bron Gondwana <brong@fastmailteam.com> wrote:

Hi Michael,

Thanks again for submitting this, and = apologies that I haven't done a thorough review yet - it's on my todo = list and I expect to do so soon.

The ONLY remaining = question was length.  200 is good, but JMAP says 255 and = consistency will make it better.  Unless you have a strong reason = to lock it down to 200, would you consider changing it to "no more than = 255 octets" with an understanding that there's no requirement that = servers have to store that much, just that clients must be willing to = accept that much.  That will keep everything consistent.

Other than this, we believe we're ready to take this = document to working group last call, which I intend to do once I've = heard back from you - it's easy to fix this up during last call.

Thanks for your work and for = getting us the update in time for this meeting.

Cheers,

Bron.

On Tue, Nov 6, 2018, at 03:30, = Michael Slusarz wrote:
I've submitted an update to the = (formerly snippet, now) preview draft incorporating feedback received = from this list and other implementers.
 
Main change is the name - this = is now "PREVIEW" instead of "SNIPPET".  Also, increased recommended = preview size to 200 characters (previously: 100).
 
Will not be able to remotely = join IETF 103 meeting as I am traveling, but wanted to make sure this = draft was updated before then.

michael

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


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


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

= --Apple-Mail=_4E223FDE-1728-4A08-9064-9D7CA909A038-- From nobody Thu Nov 8 06:42: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 69E21126CB6 for ; Thu, 8 Nov 2018 06:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=K+aF5st7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LM5Uu28b Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGqlIKjcu5JO for ; Thu, 8 Nov 2018 06:42:36 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565C512872C for ; Thu, 8 Nov 2018 06:42:36 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7624A22164 for ; Thu, 8 Nov 2018 09:42:35 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 09:42:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=V1oQvFn4yqs2cLytwziyhB8j28dh MvtePLxKnU16TFg=; b=K+aF5st79d0Pd+ehxguXkepZGeY7ojP0j2r8Ir73pyfk yCv5H/uYdfJeM71H1yN+RBg2mVWoZwJWLz6/9/9kaDgqE0afmX4bovZm8H5ivWWc YFYZkqJq6aKi7qtiVRW00hGySrtSUAOffUz9axhgbHlJV9Q1UPrKdTguCbI2ax8H uSjZ5qnS8rCF+ccLeq8D0pPjTiypqMn2gbkAhsNwXd/MoPiDvehNnU2CV7TEbHy3 4QzrI+9AvaQ61OV7h/3tnxW5ZzGKBxWfpYl83Du96+3kjYRQ7cS19+oFQefIvUGY 1mZ6sRWjU3sXSFiPR3tp1So6phMHvQBpGxVF3/F1yQ== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=V1oQvFn4yqs2cLytw ziyhB8j28dhMvtePLxKnU16TFg=; b=LM5Uu28bxHq8oYGQPvj2jwGsOZxyJFI6x yUtOinCemoTyFp7gi6YEap8km1wtCi7LpzQ+hsLESJKZJbeOdkYsMoF49X5yZmqj Zfbto3a1H2Zq5CE4xANfouMJBbQOpO61MRKD/DU8VKydrn6XBXYoU4xssOnuChi3 fFu0DAEKb2qWo3s+BJjG3FlBiXlOPfNmihO2fUFdxMJ/XUXnlxwhT+7BRepkTkj9 REWisXByc8HVmfs+qafcn/sH5lmuqi7OQrllyJ8LqCf9Urf/xdguTr4vvZjUDgcS O6WoL+iszdxXH6A4XyONNmbgeKAjtKNgb4uyIYcBIgTlFU3lEg5pQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E31EA2030B; Thu, 8 Nov 2018 09:42:34 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: <39901AFF-A720-4251-873C-A9604B5B5154@iki.fi> References: <222011778.12006.1541435419815@appsuite.open-xchange.com> <39901AFF-A720-4251-873C-A9604B5B5154@iki.fi> Date: Thu, 08 Nov 2018 09:42:34 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=a16a15d45e4c4b82b2c654eb3bef365b Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 14:42:40 -0000 --a16a15d45e4c4b82b2c654eb3bef365b Content-Type: text/plain The arguments for octets are storage space and network traffic, which is octets, but I do see your point. Should we say 255 characters maximum then - obviously servers can still do less, and clients can choose to truncate. Either way, we'll make sure JMAP aligns. Bron. On Fri, Nov 9, 2018, at 01:08, Timo Sirainen wrote: > Hmm. You're talking about octets and so far Dovecot (and Michael's draft) has been talking about characters. So with a maximum of 4 bytes per UTF-8 character and Dovecot's current 100 character limit, it could already be sending 400 octets.. > > We chose characters rather than octets because it makes more sense from the client's point of view to show approximately the same amount of text no matter what characters are being used. > >> On 8 Nov 2018, at 14.03, Bron Gondwana wrote: >> >> Hi Michael, >> >> Thanks again for submitting this, and apologies that I haven't done a thorough review yet - it's on my todo list and I expect to do so soon. >> >> The ONLY remaining question was length. 200 is good, but JMAP says 255 and consistency will make it better. Unless you have a strong reason to lock it down to 200, would you consider changing it to "no more than 255 octets" with an understanding that there's no requirement that servers have to store that much, just that clients must be willing to accept that much. That will keep everything consistent. >> >> Other than this, we believe we're ready to take this document to working group last call, which I intend to do once I've heard back from you - it's easy to fix this up during last call. >> >> Thanks for your work and for getting us the update in time for this meeting. >> >> Cheers, >> >> Bron. >> >> On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: >>> I've submitted an update to the (formerly snippet, now) preview draft incorporating feedback received from this list and other implementers. >>> >>> Main change is the name - this is now "PREVIEW" instead of "SNIPPET". Also, increased recommended preview size to 200 characters (previously: 100). >>> >>> Will not be able to remotely join IETF 103 meeting as I am traveling, but wanted to make sure this draft was updated before then. >>> >>> michael >>> >>> _______________________________________________ >>> Extra mailing list >>> Extra@ietf.org >>> https://www.ietf.org/mailman/listinfo/extra >>> >> >> -- >> 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 --a16a15d45e4c4b82b2c654eb3bef365b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
The arguments for octets are storage space and network tra= ffic, which is octets, but I do see your point.  Should we say 255 = characters maximum then - obviously servers can still do less, and clien= ts can choose to truncate.
Either way, we'll make sure JM= AP aligns.

Bron.

On Fri, Nov 9, 2018, at 01:08, Timo Sirainen wrote:
Hmm. You're talking about octets and so far Dovecot (and Michael'= s draft) has been talking about characters. So with a maximum of 4 bytes= per UTF-8 character and Dovecot's current 100 character limit, it could= already be sending 400 octets..

We chose characters rather than octets because it makes more sense= from the client's point of view to show approximately the same amount o= f text no matter what characters are being used.

On 8 Nov 2018, at 14.03,= Bron Gondwana <brong@fastmailteam.com> wrote:

Hi Michael,

Thanks again for submitting this, = and apologies that I haven't done a thorough review yet - it's on my tod= o list and I expect to do so soon.

The ONLY= remaining question was length.  200 is good, but JMAP says 255 and= consistency will make it better.  Unless you have a strong reason = to lock it down to 200, would you consider changing it to "no more than = 255 octets" with an understanding that there's no requirement that serve= rs have to store that much, just that clients must be willing to accept = that much.  That will keep everything consistent.

Other than this, we believe we're ready to take = this document to working group last call, which I intend to do once I've= heard back from you - it's easy to fix this up during last call.

Thanks for your work and for getting us the= update in time for this meeting.

Cheers,

Bron.

On Tu= e, Nov 6, 2018, at 03:30, Michael Slusarz wrote:
I've submitted an update to the (formerly snippet, now) preview draft = incorporating feedback received from this list and other implementers.
&nb= sp;
Main change is the name - this is now "PREVIEW" instead of "SNIPPET".&= nbsp; Also, increased recommended preview size to 200 characters (previo= usly: 100).
 
Will not be able to remotely join IETF 103 meeting as I a= m traveling, but wanted to make sure this draft was updated before then.=
<= br>
mi= chael

_______________________________________________
Extra mailing list
Extra@ietf.org=
<= a class=3D"fastmail-quoted-" href=3D"https://www.ietf.org/mailman/listin= fo/extra">https://www.ietf.org/mailman/listinfo/extra


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

<= br>
__= _____________________________________________
Extra mailing = list
https://www.ietf.org/mailman/listinfo/ext= ra
____________________= ___________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/ex= tra


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


--a16a15d45e4c4b82b2c654eb3bef365b-- From nobody Thu Nov 8 06:49: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 DECDB131057 for ; Thu, 8 Nov 2018 06:49:16 -0800 (PST) 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 yD8U1kTpZqOm for ; Thu, 8 Nov 2018 06:49:14 -0800 (PST) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 14E71130FDF for ; Thu, 8 Nov 2018 06:49:13 -0800 (PST) Received: (qmail 9830 invoked from network); 8 Nov 2018 14:49:12 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (AES128-SHA encrypted) SMTP (74bddf56-e365-11e8-b1e6-877903dfcc34); Thu, 08 Nov 2018 06:49:12 -0800 To: extra@ietf.org References: From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <9a7e6c6d-7fbb-d5ee-83d7-7a66499af4ed@linuxmagic.com> Date: Thu, 8 Nov 2018 06:49:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: 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: 74bddf56-e365-11e8-b1e6-877903dfcc34 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] Discussion of charter and SMTP related work X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 14:49:21 -0000 Would expanding the scope of this group open it up more to taking on the CLIENTID extensions? On 2018-11-08 4:09 a.m., Bron Gondwana wrote: > Apologies for the flood, this is the last one, I promise!  At least, > it's the last checkbox ACTION item I have from today's meeting... > > Hi All, > > When we chartered this working group, we had a flood of work, and we > deliberately excluded SMTP and MIME from our charter in order to stay > focused.  The flood has mostly abated now, and we find ourselves > considering whether to open up our scope to accept some other work which > has interest (fixing the fact that 822 is an obsolete INTERNET STANDARD > replace by 5322 which is only a DRAFT STANDARD - which doesn't even > exist any more, and also fixing accumulated errata).  There's also some > MIME work which could be tightened up and better described. > > The choices before us are roughly: > > a) spin up a new working group to take on the SMTP/MIME work > b) recharter this group > > It's expected that much the same people will be involved regardless, so > we'd be keen to hear arguments for or against these options.  Please > reply to this email with your opinions. > > Thanks, > > 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 Thu Nov 8 06:53: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 832F0128BCC for ; Thu, 8 Nov 2018 06:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=x6tCdXac; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sfg2Oyrt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzGQZA1bmamn for ; Thu, 8 Nov 2018 06:53:53 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C8512872C for ; Thu, 8 Nov 2018 06:53:53 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BE2192218B for ; Thu, 8 Nov 2018 09:53:51 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 09:53:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=WBKxsbPGpQ65mjkZLMIKdl/nbGyh D2Nsoj5wVckcNqo=; b=x6tCdXacod1LNwJH/CJbGFrlOrk9GfoYeHdCTZQ6pMGq GkOC/jPxiBo7uUt7Us3p5feCkoihHxu3Y3R1HCDflXGnkG5mRIeIBhwhaMyGAwgg ydmKF4mAX+2Q3vxPgJICwvlUOQGDjcxFOGQiNIJACAs9d2RUPeMFTIerkGjLZEMa uZDRS2pnTU3xGBeTrGduLMsPV15xeZmdYqveEfrHneU+6UjkBZPsjXamun6daUoP 8p9rRY27pRe1YELk9EALtOcdPj/nMPJoCQ9RmKn2YjBUl5ZUneA2kRaLQu9TrrJC Fhnk+7K8PFqqM/6PB2nXjQZzLGEBGw2ABi7MjT94FQ== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=WBKxsbPGpQ65mjkZL MIKdl/nbGyhD2Nsoj5wVckcNqo=; b=sfg2OyrtKySKRZCytUty6d8QVwTtozZlg PbvFdM9cKtaOdtlqN/I/ewptFqeg3LMa5Hk1YVn02pxDRhjOb658gbhcYPbzTEqF VWP+o4xHys7GDLdpFGBLQ6v5L1KYdUsePCWPRFGPePh0ERl9prSCK+42GdiwMOG4 mSw+mXn9XnL0pkw5d0domXVuEm/pTZ8wRBeXiPAjTv8JWWD0jktSSh/V+artmZVr 82Tf41orMQkcIZtjCweUqhcPhYXeZxG1+pyjIAdl1uYdSGMTAUwywbQZJqLmvTuA 02YBrZVluHmnCuRzGXlEsZYsPueM0/2yab1qx63oWqQ4mglFLMrxw== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4400A2030B; Thu, 8 Nov 2018 09:53:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: References: Date: Thu, 08 Nov 2018 09:53:50 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=30ea17d16b3f494c924612197b2e8506 Archived-At: Subject: Re: [Extra] imap4rev2: disallow "RENAME INBOX" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 14:53:56 -0000 --30ea17d16b3f494c924612197b2e8506 Content-Type: text/plain I'm tempted to see what Gmail does too. . OK brongondwana@gmail.com authenticated (Success) . rename INBOX oldinbox . OK Success Well, what do you know. They implemented it! ha... . select oldinbox . move 1:* INBOX ... . OK [COPYUID 2 1:15214 16312:31525] (Success) So it looks like it didn't reset the UID counter on the INBOX. I didn't get the UIDVALIDITY of the INBOX at the start to compare. Bron. On Fri, Nov 9, 2018, at 01:02, Timo Sirainen wrote: > On 8 Nov 2018, at 13.37, Bron Gondwana wrote: >> >> This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. >> >> This one came from me. I dislike the weirdness of "RENAME INBOX Archive-foo" because of its special behaviour regarding sub mailboxes, and the auto-recreation of the source mailbox, and all that jazz. >> >> Argument in favour of keeping it - it's easier for clients, which is part of the point of IMAP4rev2 - servers have already suffered through this the first time, and will need to keep IMAP4rev1 support for a while anyway probably. >> >> Arguments for and against in response to this please. Also arguments about the suggested middleground saying that clients "SHOULD NOT" use it, or something like that - with the flip side that servers MAY reject rename of INBOX. >> >> We're particularly interested in "I use this, and want to keep it" from either servers that see their clients doing it, client authors, or even users! > Dovecot has always been rejecting this when used with Maildir format (other formats allow it): > > a rename inbox plop > a NO [CANNOT] Renaming INBOX isn't supported (0.001 + 0.000 secs). > > I've never heard anyone complain about it. > > I've a feeling Courier is rejecting it as well, but can't check now easily. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --30ea17d16b3f494c924612197b2e8506 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I'm tempted to see what Gmail does too.

. O= K brongondwana@gmail.com a= uthenticated (Success)
. rena= me INBOX oldinbox
. OK Succes= s

Well, what do you know.  They implemented it!
<= /div>

ha...

. select oldinbox
. move 1:* INBOX

...

. OK [COPYUID 2 1:15214 16312:31525] (Success)

So it loo= ks like it didn't reset the UID counter on the INBOX.  I didn't get= the UIDVALIDITY of the INBOX at the start to compare.

Bron.

On Fri, Nov 9, 2018, = at 01:02, Timo Sirainen wrote:
On 8 Nov 2018, at 13.= 37, Bron Gondwana <brong@fastmailteam.com> wrote:
<= blockquote class=3D"fastmail-quoted-" type=3D"cite">

This is = one of the open issues from imap4rev2 - which extensions should be part = of the mandatory baseline.

This one c= ame from me.  I dislike the weirdness of "RENAME INBOX Archive-foo"= because of its special behaviour regarding sub mailboxes, and the auto-= recreation of the source mailbox, and all that jazz.
Argument in favour of keeping it - it's easier for clien= ts, which is part of the point of IMAP4rev2 - servers have already suffe= red through this the first time, and will need to keep IMAP4rev1 support= for a while anyway probably.

Argumen= ts for and against in response to this please.  Also arguments abou= t the suggested middleground saying that clients "SHOULD NOT" use it, or= something like that - with the flip side that servers MAY reject rename= of INBOX.

=
We're particularly interested in "I us= e this, and want to keep it" from either servers that see their clients = doing it, client authors, or even users!
Dovecot has always been rejecting this when used with Mail= dir format (other formats allow it):

a= rename inbox plop
a NO [CANNOT] Renaming INBOX isn't supp= orted (0.001 + 0.000 secs).

I've never hear= d anyone complain about it.

I've a feeling = Courier is rejecting it as well, but can't check now easily.

_______________________________________________<= br>
Extra mailing list
Extra@ietf.org
<= div>https://www.ietf.org/mailman/listinfo/extra

=

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

--30ea17d16b3f494c924612197b2e8506-- From nobody Thu Nov 8 07:19: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 A079B128CE4 for ; Thu, 8 Nov 2018 07:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=Bycnoc+z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gG8YjCqG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFh3vrlX1sij for ; Thu, 8 Nov 2018 07:19:40 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC33128BCC for ; Thu, 8 Nov 2018 07:19:39 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1E5BE22221 for ; Thu, 8 Nov 2018 10:19:38 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 10:19:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=JZnToIFfoTMzemMduFZb1O5ihzl9 nvMhFEKUbV/NsA8=; b=Bycnoc+z8dZhRtZl+9s69Guwk0G4geueJ2UszZKP0E9e QVkVHvUUEH+IQZ5c3O+p/7bj/pdKuS2JA6uP+e2hGPbIWzC8svc0MqEgBcLjJvJC Do4ECjfh+u0slCwZTW87P3WnDOVFh0aSNW9ojM1aaQeVdeE7/eIgk70V9jZ1l+vT i2yebJlqiDrCwoivT3b4Q6nXfH4aFbxqTFXqK8aJt3JCiR8jEnvqrd+3M2d+dzl+ Kp3KSxUHpOziYTz0yuHQkiPLFECs3mGoh24qDpPysWT390rwbyZYFrQKUjFKWQW3 gsi6OIRUPl6r/kVqdARs2S7oEDNxJM7HaMI83Dn5sw== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JZnToIFfoTMzemMdu FZb1O5ihzl9nvMhFEKUbV/NsA8=; b=gG8YjCqGpWx7RI/IR2znx2URsL0/Rm09H vB9+K7cyUFeHk6QDzy/eiNozlMbmQH6ceF7hhrN2o3PnI7c77L8IAda2XlfWUxDo Li8GTyKx6RA44lE4TNnEd1SAWvGP+sOQfOeNWP7/2O+BD5zXlJelJQctiByG4/kU 1ZNnjMsMYEoqKAovLarGf1TmnRgQ+ue/iZI0Kn8yxqVUfXb+yU82dREQeRSTFK3v Hq4pCVg6Whe7LXN4EpkXH5reV1WpA43VCbXCLMV/SPz5sK5rvVOnQw7FA7MTe3HF o7NbV2jpyiKWsTjlO/kfAYf9PYIGAYiMbDW3emJz5DqpO/NQyyxmA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7BB652030B; Thu, 8 Nov 2018 10:19:37 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <2bc9e8eb-16d3-4fc0-a1a0-46a063021843@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: <9a7e6c6d-7fbb-d5ee-83d7-7a66499af4ed@linuxmagic.com> References: <9a7e6c6d-7fbb-d5ee-83d7-7a66499af4ed@linuxmagic.com> Date: Thu, 08 Nov 2018 10:18:52 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=13f37e6190a24141a563a960276d6aa7 Archived-At: Subject: Re: [Extra] Discussion of charter and SMTP related work X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 15:19:44 -0000 --13f37e6190a24141a563a960276d6aa7 Content-Type: text/plain Hi Michael, It's possible, but I don't think the objections that were raised at Montreal have changed since then. We actually discussed how that session went and whether there's anything we could have done in terms of preparation to help set your expectations on how the IETF process works and that we're more interested in the problem to be solved and the technical requirements and challenges than in a particular pre-defined solution. We'd definitely love to keep talking about the problem that CLIENTID is looking to solve in the EXTRA group, or Alexey might have suggestions for a different venue for security work (which is not currently in our scope). We definitely see CLIENTID as being largely security related. Bron. On Fri, Nov 9, 2018, at 01:49, Michael Peddemors wrote: > Would expanding the scope of this group open it up more to taking on the > CLIENTID extensions? > > On 2018-11-08 4:09 a.m., Bron Gondwana wrote: > > Apologies for the flood, this is the last one, I promise! At least, > > it's the last checkbox ACTION item I have from today's meeting... > > > > Hi All, > > > > When we chartered this working group, we had a flood of work, and we > > deliberately excluded SMTP and MIME from our charter in order to stay > > focused. The flood has mostly abated now, and we find ourselves > > considering whether to open up our scope to accept some other work which > > has interest (fixing the fact that 822 is an obsolete INTERNET STANDARD > > replace by 5322 which is only a DRAFT STANDARD - which doesn't even > > exist any more, and also fixing accumulated errata). There's also some > > MIME work which could be tightened up and better described. > > > > The choices before us are roughly: > > > > a) spin up a new working group to take on the SMTP/MIME work > > b) recharter this group > > > > It's expected that much the same people will be involved regardless, so > > we'd be keen to hear arguments for or against these options. Please > > reply to this email with your opinions. > > > > Thanks, > > > > 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. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --13f37e6190a24141a563a960276d6aa7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Michael,
It's possible, but I don't thin= k the objections that were raised at Montreal have changed since then.

We actually discussed how that session went and whether th= ere's anything we could have done in terms of preparation to help set yo= ur expectations on how the IETF process works and that we're more intere= sted in the problem to be solved and the technical requirements and chal= lenges than in a particular pre-defined solution.

We'd de= finitely love to keep talking about the problem that CLIENTID is looking= to solve in the EXTRA group, or Alexey might have suggestions for a dif= ferent venue for security work (which is not currently in our scope).&nb= sp; We definitely see CLIENTID as being largely security related.

Bron.

On Fri, Nov 9, 2018, at 01:49, Michael Ped= demors wrote:
=
Would expanding the scope of this grou= p open it up more to taking on the 
CLIENTID extensions?

On 2018-11-08 4:09 a.m.,= Bron Gondwana wrote:
> Ap= ologies for the flood, this is the last one, I promise!  At least,&= nbsp;
> it's the last chec= kbox ACTION item I have from today's meeting...
> 
> Hi All,
> 
<= /div>
> When we chartered this worki= ng group, we had a flood of work, and we 
> deliberately excluded SMTP and MIME from our char= ter in order to stay 
&g= t; focused.  The flood has mostly abated now, and we find ourselves=  
> considering wheth= er to open up our scope to accept some other work which 
<= div style=3D"font-family:Arial;">> has interest (fixing the fact that= 822 is an obsolete INTERNET STANDARD 
> replace by 5322 which is only a DRAFT STANDARD - whi= ch doesn't even 
> ex= ist any more, and also fixing accumulated errata).  There's also so= me 
> MIME work which= could be tightened up and better described.
> 
&g= t; The choices before us are roughly:
> 
> a) s= pin up a new working group to take on the SMTP/MIME work
> b) recharter this group
> 
> It's expected that much the same people will be involved = regardless, so 
> we'= d be keen to hear arguments for or against these options.  Please&n= bsp;
> reply to this email= with your opinions.
>&nbs= p;
> Thanks,
> 
> Bron.
>&n= bsp;
> --
>    Bron Gondwana, CEO, FastMai= l Pty Ltd
>    b= rong@fastmailteam.com
>&nb= sp;
> 
> 
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
> 



-- 
"Catch the = Magic of Linux..."
----------= --------------------------------------------------------------
=
Michael Peddemors, President/CEO Linux= Magic 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 Wi= zard Tower TechnoServices Ltd.
----------------------------------------------------------------------= --
604-682-0300 Beautiful Bri= tish 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 th= at any views or opinions presented in this email are solely
those of the author and are not intended = to represent those of the company.

______________________= _________________________
Ext= ra mailing list
Extra@ietf.or= g
https://www.ietf.org/mailma= n/listinfo/extra


--
&nb= sp; Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

<= /div>

--13f37e6190a24141a563a960276d6aa7-- From nobody Thu Nov 8 16:52: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 B0AE7130DD0 for ; Thu, 8 Nov 2018 16:52:05 -0800 (PST) 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 wn3le2mG71fh for ; Thu, 8 Nov 2018 16:52:03 -0800 (PST) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 5AA2912D4EB for ; Thu, 8 Nov 2018 16:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1541724722; bh=rsPDH/hw73KDhgWxapRxEa3OV4XS49+sWvmCpFHv8U8=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=FMsR7/RXIaPNEOVX+ki5zURYrYTZrC2/oBAYKTkUtc9JvmtDv64V2euS6BfMGtP7SncH3eP2CbmS5f4mX2PXBbE9PVn5sbORB+HNvfXjOihgtJ6prFVoE+GdYZ+gi1wS9lgCv1TlTLozGtrLABHpPE85smvzlNCeja18GndGLd613dm8yUmXkxL7kT6kJyUOJ47fzpkkpZp4i3rjWyPKQ3cC+5qrifofTas9XX5q7vzbnZl7mokWNadkWdYXf+poTCOTNKeMx1vLqUMebqUEJ4C0wPFqKz7IfRcpJGISSicu36ZEgShQLW37rNz7uIkVtVry9mYdKo2KFNuMj4YmNg== X-YMail-OSG: svXsxkwVM1kr9_4Dl072Us78NrwXblRpzBofI0AnQA4SKJfXOYz1zJHpy_5Ym8d tHZW5qEXXo80Ci1XEv60rHjPnljYvef_iNrwC6ng78buhxMBfvVF8aEniZ3xwRzF3EUPpPjCn_l5 a5eiMppqmpcTK0aybqoiQ8ywQHMjs_fpqLT3FkQPYxsSZdWG8DLqpUfJHwbEJ7JwruXaz3_rPuCI 8D0k7C6NdbHbwtTY8j_hgSn0iot9APGUN4iQ6WRV.Z9X3.WZH7vuWbwtGQSvIzEWCmO7iW3rf5Iy s4JhGSBSETwS6q8.GKSSZjuRoUO0Ep1wHGQ8FS034LOnteHWbEyc.nYbTa9CCIw1gsYsTBHBSjor mB.GM6TcoZrZHjo2fLkMbu6Lm5w_TTDx0F0Uvxdd4QgNOJcaIOPuOYyUCryWT1tKCd9cy1GJtKew HMh4QLXnn_nyIbpjh16piHdbDRsUTK6tXqZpd96ysG945pmtCFiQNMIdvhJ4ABsAs2..eFdoWEFP ziEK99ataaAdh6ZOvDAZGWQehbLbh25IOfrUs03Mmwkgs8f2r_jPi9TS4qximyNMNW6WF9pJ0DKu WyCN1tfB7ls9LKByv.N.pFN4tas5i1_U.9kjlolq6eMkBUlmJ2cd1L7JSXcKXSqHanQ2H9VT2KiC aPzF5aDGq9gRQJ9.HmZTweuct9tebpLLf35KNB6vFXXsqgJBbk5nS0.6I8l_NfqCGucD154MhbVK q7KYhILos3dv6x1AVzcZnotuTUcuwdGs0hj5K5YVWJZ4PRFsLnxCp1rMFCcFvqzUHWUhA3IbewSD lwFOvAlzpOmWYLLPBv0oFe.L2zFdkGX3rtV_5QV9p7ViMzj4doA_SYyDc423Be2kAHngWfTEjGZi WJ86k.1s.Dc4PTgWy89c37pYlQTAsct4G2Z_SqKfmG7l6WIrlS7jS8KgtF.55zP_OqnhgzZ4mIac nSWezu9VafyrH7dbUWauN3XiEnURuxEvNoNA9yIwQBmlagcUNZESvrhBdHEY7JuLDsTHo231U_5L sfK8eb7ERWdL0lQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 9 Nov 2018 00:52:02 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 35c454da597fc10dbf749b0091f0fc39 for ; Fri, 09 Nov 2018 00:52:00 +0000 (UTC) To: extra@ietf.org References: <222011778.12006.1541435419815@appsuite.open-xchange.com> From: Stuart Brandt Message-ID: <5BE4D9CA.2040809@aol.com> Date: Thu, 8 Nov 2018 19:50:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 00:52:06 -0000 I know I brought this up years ago, but I'm not sure I ever saw solid resolution. If, as proposed, the Preview is mutable, then are we not addressing how to efficiently identify and sync changes that might have been made to it? If I were a client dev, I'd want to have the most recent Preview for a message because a new version likely means: a) server fixed a defective preview b) server improved preview's value-to-user Mutable data without an efficient way to sync leads to ugly polling. - Stu On 11/8/2018 7:03 AM, Bron Gondwana wrote: > Hi Michael, > > Thanks again for submitting this, and apologies that I haven't done a > thorough review yet - it's on my todo list and I expect to do so soon. > > The ONLY remaining question was length. 200 is good, but JMAP says 255 > and consistency will make it better. Unless you have a strong reason to > lock it down to 200, would you consider changing it to "no more than 255 > octets" with an understanding that there's no requirement that servers > have to store that much, just that clients must be willing to accept > that much. That will keep everything consistent. > > Other than this, we believe we're ready to take this document to working > group last call, which I intend to do once I've heard back from you - > it's easy to fix this up during last call. > > Thanks for your work and for getting us the update in time for this meeting. > > Cheers, > > Bron. > > On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: >> I've submitted an update to the (formerly snippet, now) preview draft >> incorporating feedback received from this list and other implementers. >> >> Main change is the name - this is now "PREVIEW" instead of "SNIPPET". >> Also, increased recommended preview size to 200 characters >> (previously: 100). >> >> Will not be able to remotely join IETF 103 meeting as I am traveling, >> but wanted to make sure this draft was updated before then. >> >> michael >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >> > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Thu Nov 8 16:57:35 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 701B2130DD0 for ; Thu, 8 Nov 2018 16:57:33 -0800 (PST) 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 kXgXkngCsAWD for ; Thu, 8 Nov 2018 16:57:31 -0800 (PST) Received: from sonic311-15.consmr.mail.bf2.yahoo.com (sonic311-15.consmr.mail.bf2.yahoo.com [74.6.131.125]) (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 A5651130DC1 for ; Thu, 8 Nov 2018 16:57:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1541725050; bh=lxUfCS2IDXl04La70uPxUD/Z95zY6k8a05a0Yu9OcBY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=g2ckzrm5WpT1e0lG/vcmIuk70jkoQNTlqcXHgd7mlK/I8Q59wAC3OA2MVCvAz06EgSLJ3RZqDxieWk3SBDeSsMNalnJALIp6LSGOm45P25Q43UH+webxKqOAYfU34fIa+XT0YDGTihbDeus0iYEmdmGDdJT+aMg1YFCnvsPKUa3S4Uk6XaMPJiF34eymzc/Z0ZFo/R8a6KKt8b1XDg+zcmhqIixZW347RDIhvSFZc6HvSdeGrtfsIA4/axaOyn4g2v4iENnWIJhq3wy7QOSQ3Y+sSbRQGWID7BjQ1Kwu4Nu98xpsgAGEErsgoH4wDxfF7fHjCyR/UVzTkeDP7QoAKQ== X-YMail-OSG: f0lTWfAVM1nnAKKcG3xfQxSjf0F99WdNRTB7b9VmS5wgs6LN1C7i9eXa9GPEV4A g2rRoYR98SD_nl26ZlTTnp1QvZavWNDY3VStQGsBOV_uxEKQ2XecbMEtQMIKg9Xg3F7vCW.jn5on 6.oG2jW_1nlsJSi.XYqrLVTdOmHwwKqGWlc9LpgmALgbF61k_0Ygvs8X6fGkcJaLsHXIZNjk1AHb xb5y5HVt8q0rxdVWz_tpDGvIDj39li7vR7iIh_n1GpvGG4zX_WAzmwuLArQX.2zovjRUP4.wNiGx UBp0pXeSwX9TDbiLUZs4gvkwUM51RXtN1uR15aeSAzSrwJGJUynlpTLv_pf4rZgMgeUHJ31qssLU d5Idt66QNNsXP45kSbf4VFu2dJxbEmkh9bpfG8Vq7wCWGnE.iTrkNITVGMN88VtuN8uCnXWRFXFE 2BocSqjeWR4riPtnuCu7HaWRbXGLU3NXaL9KXUT8yfcs3iGTSJpkx.XyKvTBRoWhTRoI3CY9nUf7 6f6z_CpPXp6ob5rsb6eq6lFKwANYNKpQwLZ3HD9wmvs78V7K64iNeNekQcvoJ0tJv_tcvpvTo3br 30bu1FJ9WfDSyfyP6GvfXCqQ3JD0ONUZrkf42zivZo8pu6O2U46f1qPBVnO5nbGoYGYn0LP2NywU ppRKJP9u_piEBYJIAOsBk_v3gzJYQQcf0iVIKB88y..rHrdi2CpXAMzxMaUCbD2z4drOGfSdhrBN Rh832.KSDzZlQuWm.5iAGLo6vjCTH.NFTW..Kyp2.MjL.zLIqyjXtYQSw_3Sq.edBDe5i4goARNr cvwqfjMUqN1wSw5aujm55TvEXeb40r0LxUxrZBygrgoCUyLgKH2f_W_uCUeZjkOTAJdFFmsA8Thy C8Jjt1.NCoGVwz6EAuNGT6Rghbc2KEwMageIqLeaOavxX3p4VuzHcupGL50uEIkk9piq5913lx_r nOrpzGy1QoUqQnVZOqbRgqrPlIFEXj4M2ABTnfOAS05WEQ217JktPTKL3.TqrrCEWFGVVWB4Rbb1 ypagLad_OoakF3g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 9 Nov 2018 00:57:30 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 636929034c0a76107f6d64e1491e88b1 for ; Fri, 09 Nov 2018 00:57:27 +0000 (UTC) To: extra@ietf.org References: From: Stuart Brandt Message-ID: <5BE4DB10.6090003@aol.com> Date: Thu, 8 Nov 2018 19:55:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 00:57:34 -0000 MOVE is a slam dunk in my view. Its support in clients is much broader than just Thunderbird. - Stu On 11/8/2018 6:25 AM, Bron Gondwana wrote: > This is one of the open issues from imap4rev2 - which extensions should > be part of the mandatory baseline. > > In favour - it's quite useful, and has fairly wide server support > (including Gmail and Exchange), and at least Thunderbird as a client > uses it. > > Against - Oracle haven't implemented it. > > Arguments for and against in response to this please. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Fri Nov 9 08:54: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 4917F12EB11 for ; Fri, 9 Nov 2018 08:54:46 -0800 (PST) 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=ahOZwBEH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wJziNQ6u Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2VKjZtO0qLb for ; Fri, 9 Nov 2018 08:54:43 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEE6128766 for ; Fri, 9 Nov 2018 08:54:43 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 451D2221D0; Fri, 9 Nov 2018 11:54:42 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 09 Nov 2018 11:54:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=2d8e7hwe8xiWg26VV+Xnr4avVPU YwDEhbUcO3C8Ylf0=; b=ahOZwBEHSRGtImyy93XgI7ZGOzXF5zLx4UpO8Ip9AsS cu4X+439lK0Fp1qqy5dEJ/TNdtZ1wStduI1Qw/s8pcV28cYtFyaxfmAwMWBVwdxR S2ViKbqjjW8E1U8j7hSMlQyL7EskBZbCTMcTi6+jsqpkf5l/OqM6YwaqFA5O/QP8 KdAbpR6mOOjWjefxXUXrgEW7AJD/6EtX9EawuJbfB78RSkrzvuf+aaQo9A+zG4RF HZmFteZuXT5IIoJpeoCse7IJzf1XPKXa8Ad3CVoNqwPsliB82Gm7rtfKek54jBmO dZXl0z8u3krHw7VusrrYzcZfpl9hB8kLIYAyxQm1EUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2d8e7h we8xiWg26VV+Xnr4avVPUYwDEhbUcO3C8Ylf0=; b=wJziNQ6ubEqbbumB1fUwK7 C4JHf584X8zyd9Hdd+cZh//okRi4S+G5s8oi7j509XsK+/QOQbnLlicmJYe2eW8t 4qgno5IgNwfHG9+PEr2eS3MTKbcIm2DM//rc/nD0tEd1tFTnCShpOw1Xx00+PLP7 75uDdhk7YTOuRG4ppledSyxdhEw/YkpD3vyCM2qMC1Qr2zhZoFe96hA6nsN+XkLq tlZz5HlVCdOdZ6MDm0YthuhmruLgPhS16VCc9TlEtisH73oRT0O6BomKHSqsex6m lJyKQdCQTsHk1rqVSh2Ockx03RxGL8Ss+jpF4PPSNhoNhshrfCoxTl+ATNyOOmdw == X-ME-Sender: X-ME-Proxy: Received: from localhost.localdomain (14.sub-174-224-140.myvzw.com [174.224.140.14]) by mail.messagingengine.com (Postfix) with ESMTPA id 5ED32E4750; Fri, 9 Nov 2018 11:54:41 -0500 (EST) To: Alexey Melnikov , extra References: <2a2f0f33-b056-1a04-aa11-8b8d0a448a4c@isode.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Fri, 9 Nov 2018 11:54:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2a2f0f33-b056-1a04-aa11-8b8d0a448a4c@isode.com> Content-Type: multipart/mixed; boundary="------------13B2525C5F3E3AFF44B223B8" Content-Language: en-US Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-sieve-fcc-06.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 16:54:46 -0000 This is a multi-part message in MIME format. --------------13B2525C5F3E3AFF44B223B8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/16/18 12:35 PM, Alexey Melnikov wrote: > Hi, > > The document is generally fine and contains enough details to > implement, but I found a few minor issues: > > > 3.  Tagged Argument ":fcc" > >    For convenience, the "FCC" syntax element is defined here using ABNF >    [RFC5234] so that it can be augmented by other extensions. > > Actually, you are not using ABNF, you are using Sieve syntax. > >    FCC = ":fcc" Hmm.  I'd like to use a syntax which can be extended to include compatible fileinto arguments as part of FCC (related to your point below about use of =/ > > Later in the same section: > >    If the specified mailbox doesn't exist, the >    implementation MAY treat it as an error, create the mailbox, or file >    the message into an implementation-defined mailbox. > > Allowing for either an error or filing into different mailboxes is going > to make scripts non portable, considering that there is no way to test > in a Sieve script which exact behaviour is supported. > > Also, why is it Ok to have all these different choices, which will > potentially > > confuse users? I would like to either have a way to test for different > behaviour > > or have some explanation in the document why all of the choices are > acceptable. I think some of this text was borrowed from special-use.  Would be be acceptable to do what fileinto does, which is if the target mailbox doesn't exist, then the message ends up in INBOX?  I'm also fine treating it as an error. > > > In 3.1: > >    o  Subject: The Subject header field is OPTIONAL and MAY be generated >       as follows: The subject is set to the characters "Fcc: " followed >       by the subject of the message being processed by the Sieve >       interpreter. > > Please make it clear that subject encodings used by RFC 2231 are Ok to > be used, > so if an implementation does prefix matching, this is done after > decoding. > > In 3.2: > >    Vacation auto-reply messages are MIME-compliant and MAY > > This is not an implementation choice and is not a compliance statement, > so use of RFC 2119 MAY is not appropriate here. So please use either > "may" or "can" here. I will use "can". > > There is similar text in Section 3.3. > >    be filed into >    the target mailbox without modification. > > In 3.3.1: > >    Example: > >    require ["enotify", "fcc"]; > >    if notify_method_capability "xmpp:" "Fcc" "yes" { > > > Is "fcc" case insensitive? (I didn't check). The default comparator used by notify_method_capability is i;acsii-casemap.  In fact, the example in RFC5435 is quite similar. > > >        notify :fcc "INBOX.Sent" >               :message "You got mail" >               "xmpp:ken@example.com?message;subject=SIEVE"; >    } else { >        notify :fcc "INBOX.Sent" >               :message "You got mail!" >               "mailto:ken@example.com"; >    } > > In 3.5: > > 3.5.  Interaction with Fileinto Extensions > >    The "fcc" extension can be used with some tagged arguments defined in >    extensions to the "fileinto" action. > > This got me initially very confused and I was confused till section > 3.5.4, > until I saw the example. I thought you were defining use of :fcc with > "fileinto", > but you are actually allowing use of some "fileinto" tagged arguments > together > with ":fcc" in other actions. So maybe rephrase this like this: > >    This document defines how some tagged arguments defined in >    extensions to the "fileinto" action can be used together with ":fcc" >    used in other actions. > > Or something like that. Agreed.  Your text is clearer. > >    The sections below describe its >    interaction with currently defined extensions.  Tagged arguments in >    future extensions to the "fileinto" command should describe their >    interaction with ":fcc", if any. > > In 3.5.1: > >    FCC =/ [":flags" ] > > I think use of "=/" is wrong here. You are not defining another > alternative to > ":fcc", you are allowing some tags to be used together with it. > > I suggest you either define a separate production from FCC or you just > use > Sieve syntax: See above.  I'm open to suggestions on how to handle the grammar. > >    ":flags" > >  and describe the rest in text. > > (Similar issue in 3.5.2 and 3.5.3) > > Best Regards, > > Alexey > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Ken Murchison Cyrus Development Team FastMail US LLC --------------13B2525C5F3E3AFF44B223B8 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------13B2525C5F3E3AFF44B223B8-- From nobody Fri Nov 9 11:07: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 5CA62130DC3 for ; Fri, 9 Nov 2018 11:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 begyigWygz9H for ; Fri, 9 Nov 2018 11:07:10 -0800 (PST) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 772D7130DC0 for ; Fri, 9 Nov 2018 11:07:10 -0800 (PST) Received: by mail-yw1-xc35.google.com with SMTP id w135-v6so2068743ywd.2 for ; Fri, 09 Nov 2018 11:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TNaYX83VN39JfgJ5BqdLdOu5dHpM7MjKDsHo0rpBDoA=; b=wVp/KzDxC216UGV2RHm8VggwvWYxX1/9NnLWzjzlXOMiwMAchJvkkDYHuZAxBk/ANH ZYKNG8PrkDJKf/oeQPY4kVcZbAMYfsWKuPb9NObjkOpywuTRwOgU2WKN6NY5gCA9DeY7 ZgToomIIgsGj3Ut/Etz29iKsJcs/56EDz/6sf0vVjnhGVRCvXKeG4EVu9aP15zp/OmGX YLXhBqdc85CvbxRGyusiz7C15TBHE8lx/PfcghWqBr5RUbr5LgqXO7j5qN0YROZ31kn9 ByMnHa+H4KPHo1/WASGS+kytV4zvg9ogsEqknjjjQKuHfQEeOcADlWlX+uhYRlbmYi63 JFEQ== 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=TNaYX83VN39JfgJ5BqdLdOu5dHpM7MjKDsHo0rpBDoA=; b=VDxzWXNEKrBV+Db5QC4XPUMYdLcVQjjvDMwyK2xTB+wxPioRqXp0PvvvTmV02jk0DB FTeqGt+IGHdDyE6ImrRbjIGZ74m6mywSBzLZHrvi7139AOraQIPuV7JBkNxOJYZirna4 tNFh5GfvNHiMUBghImGJbPH2t+xcEls9qVkcDy3VdCztb/nY2yEOKmLnnf0K5kkT/ts9 A+CaZEvBiUoC4a6nfZn2ZmWxQxPCkvD9Ast2WUHh/egKFmUH67SWZE96WtDHApjEJr0J kpjHCwryBxyjEekOr/NwSO2azSVMAnFtOeZPJayqGLXtD2nIky18RNIBEtUPV9/vkbtK tsEA== X-Gm-Message-State: AGRZ1gJAPW7NhfR1W+PV/2L0FC5NIQEfLUGauza7wqlcZBRYV9WNoMvd fM0mM/H5BnFkTosXExTXE4qXZIXQBdohVUQafKtu18A= X-Google-Smtp-Source: AJdET5eWAPtYzW+5LVp378vGkpZJhKFVh1cyLvo5VojhzW8UM1UNUkhRecJqvDSO8IWcietvq1Q6gEOZzDvZ91lEtgM= X-Received: by 2002:a0d:d455:: with SMTP id w82-v6mr10087329ywd.352.1541790429163; Fri, 09 Nov 2018 11:07:09 -0800 (PST) MIME-Version: 1.0 References: <5BE4DB10.6090003@aol.com> In-Reply-To: <5BE4DB10.6090003@aol.com> From: Brandon Long Date: Fri, 9 Nov 2018 11:06:56 -0800 Message-ID: To: stujenerin=40aol.com@dmarc.ietf.org Cc: extra@ietf.org Content-Type: multipart/alternative; boundary="000000000000d9b7be057a400e5e" Archived-At: Subject: Re: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 19:07:12 -0000 --000000000000d9b7be057a400e5e Content-Type: text/plain; charset="UTF-8" Agreed, it was pretty trivial to implement for Gmail, though maybe it was more trivial for us than for servers which keep folders more structurally separate, ie I can imagine mbox based servers having more trouble making it atomic, but I don't know how much they already have that problem. I think for most GUI clients, move is the default action, having to make two separate calls for that seems unnecessary, even if they can be pipelined. Brandon On Thu, Nov 8, 2018 at 4:57 PM Stuart Brandt wrote: > MOVE is a slam dunk in my view. Its support in clients is much broader > than just Thunderbird. > > - Stu > > On 11/8/2018 6:25 AM, Bron Gondwana wrote: > > This is one of the open issues from imap4rev2 - which extensions should > > be part of the mandatory baseline. > > > > In favour - it's quite useful, and has fairly wide server support > > (including Gmail and Exchange), and at least Thunderbird as a client > > uses it. > > > > Against - Oracle haven't implemented it. > > > > Arguments for and against in response to this please. > > > > Cheers, > > > > 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 > --000000000000d9b7be057a400e5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed, it was pretty trivial to implement for Gmail, thou= gh maybe it was more trivial for us than for servers which keep folders mor= e structurally separate, ie I can imagine mbox based servers having more tr= ouble making it atomic, but I don't know how much they already have tha= t problem.

I think for most GUI clients, move is the default action= , having to make two separate calls for that seems unnecessary, even if the= y can be pipelined.

Brandon

On Thu, Nov 8, 2018 at 4:57 PM Stu= art Brandt <stujenerin=3D40a= ol.com@dmarc.ietf.org> wrote:
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
--000000000000d9b7be057a400e5e-- From nobody Fri Nov 9 11:15: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 34BCB128BCC for ; Fri, 9 Nov 2018 11:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 WnCRHQ3drwxO for ; Fri, 9 Nov 2018 11:15:03 -0800 (PST) Received: from mail-yw1-xc30.google.com (mail-yw1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (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 97480130DC0 for ; Fri, 9 Nov 2018 11:15:03 -0800 (PST) Received: by mail-yw1-xc30.google.com with SMTP id l2-v6so2023249ywb.9 for ; Fri, 09 Nov 2018 11:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MXuQ5BPz/21I1H24RG8eJ9QgcafQTsbvfukeanKl/9o=; b=Og3A1wdmF3aTpRKU3EdMBojXPoUKnBkyU/9WMHTgj+FhvaIZHmvztA28Jl5puLfGAd kS1Nyk4QkjJAqmd1a091WhRMu6oHxOEw+aycA7OmnJZC/55neaVZUJMAwvk3BK7KSEq1 IETjbkBwVoVR6XWt0TqDxEqiRFYNUdxRyPJWskZsuTUCpObxnaH0S7N8xGbFKiuNWvIK PvJkkPSpKSydVrkIfkl9i0y1Gx5DrdIBJaaNf/IUF/yskrVVAJG3U+ayy5A38aIZSwm6 KcrUXbr4a46FUitVpLILavNILHZQ/5B9efUHN3Vnt7AxabzQ3grWKfcSZBRxdPDXtl2K 6yGw== 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=MXuQ5BPz/21I1H24RG8eJ9QgcafQTsbvfukeanKl/9o=; b=K0gSf9Ba78R+FOqTSScgom5qeziIo62Tk6yv9EX/IyS27PPzvx/NXlISv2WJ7N+Umg MDIGIg+3/cc0tWLnNR5RfGElWA41UTmukKjZGWyLIwOOdVpg1ln7n9CO3EeXTy2rWTF3 1tZhdX/r7Fp0YZyTC6VeaucWlczjTYoNsFtD8ZtajoMOaxNtHHrje5ktflhlMPK/7621 XrLcKPMNKIbTXbZ9yiliBrluzLLEc0F7A/49IglP9cS75DELZcsstFfK9WuyH8wL05BP ZLmCcKDodxFxhD5CgTQ5cNW8iU3h7MwwPOATSBoPmCjBWMGI9hZ+sOWVmf/J/4BP9HmK JQJg== X-Gm-Message-State: AGRZ1gL5/CMG2GO4hXB4kQWTfd8i6qc0VXWQ9NfUCbnltFE0zMuQZBWX 9/AYmTS7YrHDLPksJDhA/PPA2ZtT52yzc6nLCJtLHYE= X-Google-Smtp-Source: AJdET5elCG76lEWkY8DSu/mZHVveJOvZik51d13QWcS3MFgShkCwdeUIBDatXeo5PWNU1GhZTC+c5dEUcPtMvdke37o= X-Received: by 2002:a0d:cf85:: with SMTP id r127-v6mr10096345ywd.109.1541790902369; Fri, 09 Nov 2018 11:15:02 -0800 (PST) MIME-Version: 1.0 References: <222011778.12006.1541435419815@appsuite.open-xchange.com> <5BE4D9CA.2040809@aol.com> In-Reply-To: <5BE4D9CA.2040809@aol.com> From: Brandon Long Date: Fri, 9 Nov 2018 11:14:49 -0800 Message-ID: To: stujenerin=40aol.com@dmarc.ietf.org Cc: extra@ietf.org Content-Type: multipart/alternative; boundary="0000000000000e7c1f057a402bd1" Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 19:15:06 -0000 --0000000000000e7c1f057a402bd1 Content-Type: text/plain; charset="UTF-8" Do we think this is likely to be used for full-sync clients? Theoretically, those could just generate their own snippets locally from the rest of the data. For online clients, the preview would just be part of what they download to display the message list. Without QRESYNC, we still have some ugly polling, though obviously PREVEIWS are larger than UIDs. OTOH, I feel we already have part of this type of problem today, where improvements to our parsers or encoding detection might change our response to any given message based request, but obviously we won't rev the UIDVALIDITY folders on every bi-weekly release when its only ever going to affect a small number of messages. Brandon On Thu, Nov 8, 2018 at 4:52 PM Stuart Brandt wrote: > I know I brought this up years ago, but I'm not sure I ever saw solid > resolution. If, as proposed, the Preview is mutable, then are we not > addressing how to efficiently identify and sync changes that might have > been made to it? If I were a client dev, I'd want to have the most > recent Preview for a message because a new version likely means: > a) server fixed a defective preview > b) server improved preview's value-to-user > > Mutable data without an efficient way to sync leads to ugly polling. > > - Stu > > On 11/8/2018 7:03 AM, Bron Gondwana wrote: > > Hi Michael, > > > > Thanks again for submitting this, and apologies that I haven't done a > > thorough review yet - it's on my todo list and I expect to do so soon. > > > > The ONLY remaining question was length. 200 is good, but JMAP says 255 > > and consistency will make it better. Unless you have a strong reason to > > lock it down to 200, would you consider changing it to "no more than 255 > > octets" with an understanding that there's no requirement that servers > > have to store that much, just that clients must be willing to accept > > that much. That will keep everything consistent. > > > > Other than this, we believe we're ready to take this document to working > > group last call, which I intend to do once I've heard back from you - > > it's easy to fix this up during last call. > > > > Thanks for your work and for getting us the update in time for this > meeting. > > > > Cheers, > > > > Bron. > > > > On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: > >> I've submitted an update to the (formerly snippet, now) preview draft > >> incorporating feedback received from this list and other implementers. > >> > >> Main change is the name - this is now "PREVIEW" instead of "SNIPPET". > >> Also, increased recommended preview size to 200 characters > >> (previously: 100). > >> > >> Will not be able to remotely join IETF 103 meeting as I am traveling, > >> but wanted to make sure this draft was updated before then. > >> > >> michael > >> > >> _______________________________________________ > >> Extra mailing list > >> Extra@ietf.org > >> https://www.ietf.org/mailman/listinfo/extra > >> > > > > -- > > 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 > --0000000000000e7c1f057a402bd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do we think this is likely to be used for full-sync client= s?=C2=A0 Theoretically, those could just generate their own snippets locall= y from the rest of the data.

For online clients, the preview would = just be part of what they download to display the message list.
<= br>
Without QRESYNC, we still have some ugly polling, though obvi= ously PREVEIWS are larger than UIDs.

OTOH, I feel we already have pa= rt of this type of problem today, where improvements to our parsers or enco= ding detection might change our response to any
given message bas= ed request, but obviously we won't rev the UIDVALIDITY folders on every= bi-weekly release when its only ever going to affect a small number of mes= sages.

Brandon

On Thu, Nov 8, 2018 at 4:52 PM Stuart Brandt <st= ujenerin=3D40aol.com@dmarc.ietf= .org> wrote:
I know I brough= t this up years ago, but I'm not sure I ever saw solid
resolution. If, as proposed, the Preview is mutable, then are we not
addressing how to efficiently identify and sync changes that might have been made to it? If I were a client dev, I'd want to have the most
recent Preview for a message because a new version likely means:
a) server fixed a defective preview
b) server improved preview's value-to-user

Mutable data without an efficient way to sync leads to ugly polling.

- Stu

On 11/8/2018 7:03 AM, Bron Gondwana wrote:
> Hi Michael,
>
> Thanks again for submitting this, and apologies that I haven't don= e a
> thorough review yet - it's on my todo list and I expect to do so s= oon.
>
> The ONLY remaining question was length.=C2=A0 200 is good, but JMAP sa= ys 255
> and consistency will make it better.=C2=A0 Unless you have a strong re= ason to
> lock it down to 200, would you consider changing it to "no more t= han 255
> octets" with an understanding that there's no requirement tha= t servers
> have to store that much, just that clients must be willing to accept > that much.=C2=A0 That will keep everything consistent.
>
> Other than this, we believe we're ready to take this document to w= orking
> group last call, which I intend to do once I've heard back from yo= u -
> it's easy to fix this up during last call.
>
> Thanks for your work and for getting us the update in time for this me= eting.
>
> Cheers,
>
> Bron.
>
> On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote:
>> I've submitted an update to the (formerly snippet, now) previe= w draft
>> incorporating feedback received from this list and other implement= ers.
>>
>> Main change is the name - this is now "PREVIEW" instead = of "SNIPPET".
>> Also, increased recommended preview size to 200 characters
>> (previously: 100).
>>
>> Will not be able to remotely join IETF 103 meeting as I am traveli= ng,
>> but wanted to make sure this draft was updated before then.
>>
>> michael
>>
>> _______________________________________________
>> Extra mailing list
>> Extra@ietf.org=
>> https://www.ietf.org/mailman/listinfo/extra<= br> >>
>
> --
>=C2=A0 =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd
>=C2=A0 =C2=A0 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
--0000000000000e7c1f057a402bd1-- From nobody Fri Nov 9 11:26: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 5855B130DC3 for ; Fri, 9 Nov 2018 11:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 IQmT92Rh3F5Q for ; Fri, 9 Nov 2018 11:26:02 -0800 (PST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 72A6312426A for ; Fri, 9 Nov 2018 11:26:02 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id g192-v6so1508375ybf.3 for ; Fri, 09 Nov 2018 11:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NWvdTTcRNVLZMjo6uMyyK24XU0/ia3ejL1HQL3aZ2w4=; b=DOFuZ7PWbton668zxzJIQEqTAppCzT+FE3E5gyNlEw1he833nTvuHjGvjL3zysj3DR 7unUj5JaHCuUPA96jcR7VL3n05eAvaN1Ks7s5DTqpwG4RsfOBQpNeaf8Ly4TDcyZhSaz vNaOK8tZQmNMkem4XRXnCZIP5XtucNWnf8XnOlkym8BARo3aMSL07SpU5Xj6qV7Kt6BU SXh/RNaUzaEJy9r7OMm7hHsMgQsHl/2MST5x9hJEbd8L5sT70a7xKCWcMisQI90mh61S PPAH3jkSdPBMuKBrHJrNWEQCnchJN+h1f486dpArBZGWkW2etPT8UVcpkfflFccR9LtH veqQ== 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=NWvdTTcRNVLZMjo6uMyyK24XU0/ia3ejL1HQL3aZ2w4=; b=uKChkWGvVf5n4DDViWq4I+ZahjidA4LN6zGpSSiHQej/A6EhHD6vvGMbVbkRay1Lp7 cIRpyOz3HzZe2k7Nn+8HEhrVy7+ij30sgBJEMbkqflGS67eoVwmyy8QtzjKbpr4hCzLn yaWn0JzzyMSI10X8BQp9geI8MjlU9Nwl0xaKsB9QyzFcJX4fykx+TzqqHy8weE2vyZ3U 5BeEkkSCXsDaHNy5GaR6QiN0lusa47ppFP6RkBa/4TAk/FtqfKvC6dtY4bOSCEPnraXJ PwXEcsNbyPdJMSDdlWtgmk+zYTeGyhRzel+CIktSoZBhNJDWKUx+7FR/ueHtIRS7OKgC H/Nw== X-Gm-Message-State: AGRZ1gImrfaMfyea9u1di6tbRqSPfuVfrYnhvNHl395ktO0j4iymh5rJ c7UF9EybdYB2TkOJhSHIHUwyrI7FCKfpEBnBVl6izdk= X-Google-Smtp-Source: AJdET5f+wucZwZVGaiIKRTOeO90isvPsZmhJVwtbJvcM7VPp/TtOGNvgB1yem8qXcR8jhrbX33H/QESsWhdeNG+ZnVk= X-Received: by 2002:a25:3384:: with SMTP id z126-v6mr10022096ybz.444.1541791561106; Fri, 09 Nov 2018 11:26:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Long Date: Fri, 9 Nov 2018 11:25:47 -0800 Message-ID: To: Bron Gondwana Cc: extra@ietf.org Content-Type: multipart/alternative; boundary="00000000000051e55c057a4052c1" Archived-At: Subject: Re: [Extra] imap4rev2: disallow "RENAME INBOX" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 19:26:04 -0000 --00000000000051e55c057a4052c1 Content-Type: text/plain; charset="UTF-8" hey, it was in the spec, we implemented it, just removing the inbox label and adding another one, easy peasy, about the same as that move command. The things we didn't implement were things that were much harder (substring searching is probably the main one) or seemed silly and hard (\Recent). yes, we didn't reset the UID counter, I guess we could do that and the uidvalidity, but the initial impl didn't have a good way to change the underlying uidvalidity, so easier to leave the uid space the same. Brandon On Thu, Nov 8, 2018 at 6:54 AM Bron Gondwana wrote: > I'm tempted to see what Gmail does too. > > . OK brongondwana@gmail.com authenticated (Success) > . rename INBOX oldinbox > . OK Success > > Well, what do you know. They implemented it! > > ha... > > . select oldinbox > . move 1:* INBOX > > ... > > . OK [COPYUID 2 1:15214 16312:31525] (Success) > > So it looks like it didn't reset the UID counter on the INBOX. I didn't > get the UIDVALIDITY of the INBOX at the start to compare. > > Bron. > > On Fri, Nov 9, 2018, at 01:02, Timo Sirainen wrote: > > On 8 Nov 2018, at 13.37, Bron Gondwana wrote: > > > This is one of the open issues from imap4rev2 - which extensions should be > part of the mandatory baseline. > > This one came from me. I dislike the weirdness of "RENAME INBOX > Archive-foo" because of its special behaviour regarding sub mailboxes, and > the auto-recreation of the source mailbox, and all that jazz. > > Argument in favour of keeping it - it's easier for clients, which is part > of the point of IMAP4rev2 - servers have already suffered through this the > first time, and will need to keep IMAP4rev1 support for a while anyway > probably. > > Arguments for and against in response to this please. Also arguments > about the suggested middleground saying that clients "SHOULD NOT" use it, > or something like that - with the flip side that servers MAY reject rename > of INBOX. > > We're particularly interested in "I use this, and want to keep it" from > either servers that see their clients doing it, client authors, or even > users! > > Dovecot has always been rejecting this when used with Maildir format > (other formats allow it): > > a rename inbox plop > a NO [CANNOT] Renaming INBOX isn't supported (0.001 + 0.000 secs). > > I've never heard anyone complain about it. > > I've a feeling Courier is rejecting it as well, but can't check now easily. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > --00000000000051e55c057a4052c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hey, it was in the spec, we implemented it, just removing = the inbox label and adding another one, easy peasy, about the same as that = move command.=C2=A0 The things we didn't implement were things that wer= e much harder (substring searching is probably the main one) or seemed sill= y and hard (\Recent).

yes, we didn't reset the UID c= ounter, I guess we could do that and the uidvalidity, but the initial impl = didn't have a good way to change the underlying uidvalidity, so easier = to leave the uid space the same.

Brandon

On Thu, Nov 8, 2018 at 6:= 54 AM Bron Gondwana <brong@fas= tmailteam.com> wrote:
I'm tempted to see what Gmail do= es too.

. OK brongondwana@gmail.com authenticated (Success)
. rename INBOX oldinbox
. OK Success
Well, what do you know.=C2=A0 They = implemented it!

ha...
<= br>
. select oldinbox
. move 1:* INBOX

...

. OK [= COPYUID 2 1:15214 16312:31525] (Success)

So it looks like it didn= 't reset the UID counter on the INBOX.=C2=A0 I didn't get the UIDVA= LIDITY of the INBOX at the start to compare.

Bron.

<= div style=3D"font-family:Arial">On Fri, Nov 9, 2018, at 01:02, Timo Siraine= n wrote:
On 8 Nov 2018, at 13.37, Bron= Gondwana <brong@fastmailteam.com&g= t; wrote:

This is one of the open issues from imap4rev2 - = which extensions should be part of the mandatory baseline.

This one came from me.=C2=A0 I = dislike the weirdness of "RENAME INBOX Archive-foo" because of it= s special behaviour regarding sub mailboxes, and the auto-recreation of the= source mailbox, and all that jazz.

Argument in favour of keeping it - it's easier for= clients, which is part of the point of IMAP4rev2 - servers have already su= ffered through this the first time, and will need to keep IMAP4rev1 support= for a while anyway probably.

Arguments for and against in response to this please.=C2=A0 = Also arguments about the suggested middleground saying that clients "S= HOULD NOT" use it, or something like that - with the flip side that se= rvers MAY reject rename of INBOX.

We're particularly interested in "I use= this, and want to keep it" from either servers that see their clients= doing it, client authors, or even users!
Dovecot has always been rejecting this when used with Maildir f= ormat (other formats allow it):

a rename = inbox plop
a NO [CANNOT] Renaming INBOX isn't supported (= 0.001 + 0.000 secs).

I've never heard anyo= ne complain about it.

I've a feeling Couri= er is rejecting it as well, but can't check now easily.
<= br>
_______________________________________________
Extra mailing list


--
=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
--00000000000051e55c057a4052c1-- From nobody Fri Nov 9 15:09: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 B3E2B12D4F2 for ; Fri, 9 Nov 2018 15:09:38 -0800 (PST) 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=SwaYWMb8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bdAuP6jq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaKGCqgvBUN7 for ; Fri, 9 Nov 2018 15:09:37 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E117128C65 for ; Fri, 9 Nov 2018 15:09:37 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4E5662206B for ; Fri, 9 Nov 2018 18:09:36 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 09 Nov 2018 18:09:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=7115EvH3rIlLULmcMmZw5aVknUFR /Z9M4F7V/19kQhw=; b=SwaYWMb8stCupwR+H5DVoA/meD0XUlfxSSKKO6Se9nzY rGfRfODpdDFiJAM2zzEunOWYgTusZXOAkUurwRk7oTwNa6bHY2UULFeksGgQWH4B B5IblxapLy2LESgDBbX8jUJPkZ+xiwFjinmncEnJIVU+G+8VJE/MdSLDjvkxiEkW kdwmVAv4q3nVriZzFU7McDSec+aclDr9a/4PLWTeN+7nhiZDAPTQkKF6dP2AQjUa DqTYqnkSgegA4Bk7FicgqTFLtTEPEuEp6QLg8prC5n012Ov5Xessay0DX93HP17G J82FDMssqJV1Rf28SYx/iYAMKY0e5Xu3/ICe1+nCZA== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=7115EvH3rIlLULmcM mZw5aVknUFR/Z9M4F7V/19kQhw=; b=bdAuP6jqQoFh/n4nkJq79xIYLQOIijHV0 W4uf3RLuKbwv1VY38PknEdqrScAFvhOzFQLfNyiRIbS59T3B2fWxpEzMRFRvXvlz MpgyxHg7yHOwY7SJsq3UVET5PXjfc58R8OyOLUrFQAPMntR6fr4rGANMlrPiHNPE lHSjT/rKDHw77fykdWMEiBQxwDsnwSWsirOOqU3anS9flMiwDEkhdYzniQREH4RW FyB2h9wBNOn8mlkGRUKDQZ7if5eoTK6L50ocHBw2xcii7o+qnkSnYXgfmQEWblz3 09bYwHqRMhOQ9GB0sAxsbIaGLPV8a8+9Ba/+TKYQIyFLpKV8DpQjA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A979C2030B; Fri, 9 Nov 2018 18:09:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <6b99912d-ce76-44d5-8bb9-088d41ec25a0@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: References: <5BE4DB10.6090003@aol.com> Date: Fri, 09 Nov 2018 18:09:35 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=64a6b31d269e481ca478f44a4d267212 Archived-At: Subject: Re: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 23:09:39 -0000 --64a6b31d269e481ca478f44a4d267212 Content-Type: text/plain Honestly it's not 100% atomic in Cyrus, but it's pretty safe and it fails in the "as if it was the copy / store / expunge sequence". Bron On Sat, 10 Nov 2018, at 06:07, Brandon Long wrote: > Agreed, it was pretty trivial to implement for Gmail, though maybe it was more trivial for us than for servers which keep folders more structurally separate, ie I can imagine mbox based servers having more trouble making it atomic, but I don't know how much they already have that problem. > > I think for most GUI clients, move is the default action, having to make two separate calls for that seems unnecessary, even if they can be pipelined. > > Brandon > > On Thu, Nov 8, 2018 at 4:57 PM Stuart Brandt wrote: >> MOVE is a slam dunk in my view. Its support in clients is much broader >> than just Thunderbird. >> >> - Stu >> >> On 11/8/2018 6:25 AM, Bron Gondwana wrote: >> > This is one of the open issues from imap4rev2 - which extensions should >> > be part of the mandatory baseline. >> > >> > In favour - it's quite useful, and has fairly wide server support >> > (including Gmail and Exchange), and at least Thunderbird as a client >> > uses it. >> > >> > Against - Oracle haven't implemented it. >> > >> > Arguments for and against in response to this please. >> > >> > Cheers, >> > >> > 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 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --64a6b31d269e481ca478f44a4d267212 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Honestly it's not 100% atomic in Cyrus, but it's pretty sa= fe and it fails in the "as if it was the copy / store / expunge sequence= ".

Bron

=
On Sat, 10 Nov 2018, at 06:07, Brandon= Long wrote:
<= div dir=3D"ltr">
Agreed, it was pretty = trivial to implement for Gmail, though maybe it was more trivial for us = than for servers which keep folders more structurally separate, ie I can= imagine mbox based servers having more trouble making it atomic, but I = don't know how much they already have that problem.

= I think for most GUI clients, move is the default action, having to make= two separate calls for that seems unnecessary, even if they can be pipe= lined.

Brandon

On Thu, Nov 8, 2018 at 4:57 PM Stuart Brandt &l= t;stujenerin=3D40aol.com@dma= rc.ietf.org> wrote:
MOVE is a slam dunk in my view. Its support in clients is muc= h broader
than just Thunder= bird.

- Stu
=
On 11/8/2018 6:25 AM, Bron = Gondwana wrote:
> This is= one of the open issues from imap4rev2 - which extensions should
> be part of the mandatory basel= ine.
>
> In favour - it's quite useful, and has fa= irly wide server support
>= ; (including Gmail and Exchange), and at least Thunderbird as a client
> uses it.
>
> Against - Oracle haven't implemented it.
>
&= gt; Arguments for and against in response to this please.
>
> Cheers,
>
=
> Bron.
>
&= gt; --
>    Bro= n Gondwana, CEO, FastMail Pty Ltd
>
>
>
>=
> ______________________= _________________________
&g= t; Extra mailing list
> <= a href=3D"mailto:Extra@ietf.org">Extra@ietf.org
>

= _______________________________________________
Extra mailing list
________________________= _______________________
Extra mailing list
E= xtra@ietf.org
https://www.ietf.org/mailman/listinfo/extra<= br>

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

--64a6b31d269e481ca478f44a4d267212-- From nobody Fri Nov 9 15:18:11 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 2C2391277CC for ; Fri, 9 Nov 2018 15:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 80hVU3EgaCbK for ; Fri, 9 Nov 2018 15:18:08 -0800 (PST) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 AE7A41274D0 for ; Fri, 9 Nov 2018 15:18:08 -0800 (PST) Received: by mail-yw1-xc29.google.com with SMTP id v5-v6so2235706ywa.13 for ; Fri, 09 Nov 2018 15:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r3CMU0BbUwOAROiYIwB4hz664V2MoZngYT6I26A23mM=; b=DEDGdDeHRtCnjp9n6x+dFyhX/7wZqX0+vcjotQ19vNBMPHS6CdrP2f//tWzjjy5uzB 7azBvbxuiXvgPJ0/vUX89pgi8gRcHU0vpoxX6A+mLhD7YsrfnSp2JiPni7Dly3aAN8M/ WeAr+1b1zlu1f0dbkp/nXjjgMrq/33R6IhwC2bUpNthr+Lj7GALwRnxnJydf/i0kdsm1 N2P3NxQ8OMkJfItkvaNUIRaCLP3fD1FLwEUaonoMBqZT8wF4yHSWHBox2Za/Ybn8MgNF ifKU+vSkLXi5rb6PUEDDXIDDUo6N/zlFWW8ZXXPVeSkwSTycYiViby1VRp6GwM1t8/4a nSmA== 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=r3CMU0BbUwOAROiYIwB4hz664V2MoZngYT6I26A23mM=; b=fvbINur0IFg1xvF3D8Oz+p1y8UWIc2NlGkoKsczuj9yQDT26SS2EI+XeNjQpNON+ua 3lZZ7o3E7q8317vWvP0yDYXBksP/ZDZexiWuwebn+6Uz3wCPtecC5yjN9Uhhozc8Z3xI 3PmjE5AK3OINjR/883EPW3ffH8py2CopeHxORlAfSantAhSX+LTLO+aG5W0W4Uzx33Ns jF+GALsh4IFhWtPU9sH5L351DVPvWCE6VRVEt4TE92Qy/Elbf70MxF8EPi1pOpCcBxnE 5nXlfO+zc/NP1OOrZVoYMQugLPki8tgDG7CSr+pUthdTPXSYoEDJycdDLC2bqqsZlEs1 8oDA== X-Gm-Message-State: AGRZ1gIan9TsWu6Sc9qXdlUl6i+dwlZjjJTw5QIXZ2ZvymynDg2m90cy ofLmxnJXj0jx2TsKbQLqkE7cCxTZlv7NCTNyjC2M X-Google-Smtp-Source: AJdET5cLI/EMESoNqbiWsZSjxXn4WANAj7NAACCrTqJvGzU7H2c9hL+RUT0PDGi304BdbdzOfIJTYqUSC3I9LCLOTUE= X-Received: by 2002:a0d:cf85:: with SMTP id r127-v6mr10864536ywd.109.1541805486298; Fri, 09 Nov 2018 15:18:06 -0800 (PST) MIME-Version: 1.0 References: <7a10e2be-5192-4955-8bd8-aa81a18a240b@sloti7d1t02> In-Reply-To: <7a10e2be-5192-4955-8bd8-aa81a18a240b@sloti7d1t02> From: Brandon Long Date: Fri, 9 Nov 2018 15:17:53 -0800 Message-ID: To: Bron Gondwana Cc: extra@ietf.org, aamelnikov@fastmail.fm Content-Type: multipart/alternative; boundary="000000000000538a65057a43903a" Archived-At: Subject: Re: [Extra] imap4rev2: RFC3516 BINARY X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 23:18:11 -0000 --000000000000538a65057a43903a Content-Type: text/plain; charset="UTF-8" BINARYMIMEWe ran into some issues trying to implement BINARY, and also didn't see a large number of clients which supported it (looking back, we did this work mostly in 2014, so a while back). My memory is a bit sketchy of everything we ran into. If I recall, we had some questions with the standard, ie what happens if you request binary for non-leaf branches of the MIME tree (section-binary implies that there's something special about what you can request, but it's actually just the section-part). Ie, if you ask for BINARY on a message/rfc822, are we supposed to decode each individual part in that multipart? Again, we could have just responded NO with unknown-cte, I guess. There was also the question of what to do with data we'd munged, ie we have heuristics for extracting base64 data when there are multiple sections of it, or where a mailing list appended a non-encoded footer on base64 data, etc, we probably would have just sent the data we'd extracted instead of giving an unknown-cte response, for example. We also had some issues with binary append which I don't recall, though that you can just not support with some minor annoyance (why it didn't have a separate CAPABILITY for APPEND instead of just allowing the server to say NO, I dunno). If I recall, we were worried about what version to store and what to vend to non BINARY requests, and how that interoperated. I guess this wouldn't have mattered that much, we already have a "buggy" APPEND by the standard, since the standard basically says you have to accept whatever crap they APPEND, even if not an email message, and we have some base level requirements for message formatting. Overall, it was a part of our investigation into using binary more in emali, ie cte binary and smtp (BDAT and BINARYMIME). We implemented BDAT, but our testing basically showed very few clients or servers that could handle cte binary with embedded nulls. Perhaps a cleaned up more strictly specified BINARY could be included, otherwise I think you'll get a lot of unknown-cte responses from folks who have to claim support but can't. For one, its not clear that you can stream a base64 decode, at the least you'd need to do two passes, one to verify correctness of the base64 data, and the second to stream decode it. Brandon On Thu, Nov 8, 2018 at 3:34 AM Bron Gondwana wrote: > This is one of the open issues from imap4rev2 - which extensions should be > part of the mandatory baseline. > > This one might need some clarification from Alexey - I'm not sure why it's > not trivially obviously a good thing to include. There was some stuff > about "ability to fetch the decoded size" discussed, but I didn't capture > good notes. > > Arguments for and against, or additional discussion, in response to this > please. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > --000000000000538a65057a43903a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BINARYMIMEWe ran into so= me issues trying to implement BINARY, and also didn't see a large numbe= r of clients which supported it (looking back, we did this work mostly in 2= 014, so a while back).=C2=A0 My memory is a bit sketchy of everything we ra= n into.

If I recall, we had some questions with the stan= dard, ie what happens if you request binary for non-leaf branches of the MI= ME tree (section-binary implies that there's something special about wh= at you can request, but it's actually just the section-part).=C2=A0 Ie,= if you ask for BINARY on a message/rfc822, are we supposed to decode each = individual part in that multipart?=C2=A0 Again, we could have just responde= d NO with unknown-cte, I guess.=C2=A0 There was also the question of what t= o do with data we'd munged, ie we have heuristics for extracting base64= data when there are multiple sections of it, or where a mailing list appen= ded a non-encoded footer on base64 data, etc, we probably would have just s= ent the data we'd extracted instead of giving an unknown-cte response, = for example.

We also had some issues with binary a= ppend which I don't recall, though that you can just not support with s= ome minor annoyance (why it didn't have a separate CAPABILITY for APPEN= D instead of just allowing the server to say NO, I dunno).=C2=A0 If I recal= l, we were worried about what version to store and what to vend to non BINA= RY requests, and how that interoperated.=C2=A0 I guess this wouldn't ha= ve mattered that much, we already have a "buggy" APPEND by the st= andard, since the standard basically says you have to accept whatever crap = they APPEND, even if not an email message, and we have some base level requ= irements for message formatting.

Overall, it was a= part of our investigation into using binary more in emali, ie cte binary a= nd smtp (BDAT and BINARYMIME).=C2=A0 We implemented BDAT, but our testing b= asically showed very few clients or servers that could handle cte binary wi= th embedded nulls.

Perhaps a cleaned up more stric= tly specified BINARY could be included, otherwise I think you'll get a = lot of unknown-cte responses from folks who have to claim support but can&#= 39;t.
For one, its not clear that you can stream a base64 decode,= at the least you'd need to do two passes, one to verify correctness of= the base64 data, and the second to stream decode it.

<= div>Brandon

On Thu, Nov 8, 2018 at 3:34 AM Bron Gondwana <brong@fastmailteam.com> wrote:
Th= is is one of the open issues from imap4rev2 - which extensions should be pa= rt of the mandatory baseline.
This one might need some clarificat= ion from Alexey - I'm not sure why it's not trivially obviously a g= ood thing to include.=C2=A0 There was some stuff about "ability to fet= ch the decoded size" discussed, but I didn't capture good notes.

Arguments for and against, or additional discussion, in response t= o this please.

Cheers,
=

Bron.

--
=C2=A0 Bron Go= ndwana, CEO, FastMail Pty Ltd
=C2=A0 brong@fastmailteam.com


___= ____________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra
--000000000000538a65057a43903a-- From nobody Fri Nov 9 17:12: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 E0353130DF9 for ; Fri, 9 Nov 2018 17:12:56 -0800 (PST) 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 LBZf5hI1JP4p for ; Fri, 9 Nov 2018 17:12:54 -0800 (PST) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 736C1130DE3 for ; Fri, 9 Nov 2018 17:12:54 -0800 (PST) Received: from [192.168.10.106] (unknown [91.155.205.240]) by tss.iki.fi (Postfix) with ESMTPSA id 3B3832B3CCA; Sat, 10 Nov 2018 01:12:53 +0000 (UTC) From: Timo Sirainen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_756D46AB-2F17-493B-AECD-8684F1BC67C7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 10 Nov 2018 03:12:51 +0200 In-Reply-To: Cc: Bron Gondwana , extra@ietf.org, aamelnikov@fastmail.fm To: Brandon Long References: <7a10e2be-5192-4955-8bd8-aa81a18a240b@sloti7d1t02> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Extra] imap4rev2: RFC3516 BINARY X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 01:12:57 -0000 --Apple-Mail=_756D46AB-2F17-493B-AECD-8684F1BC67C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I remember the BINARY specification wasn't very clear for all the = troublesome cases. I mostly implemented it by thinking what made the = most sense to me. Also I vaguely remember there being some talk about = updating the RFC related to these? I couldn't find a new one now, so I = guess that plan died. I was also thinking whether COMPRESS (or TLS compression) might make = BINARY irrelevant. I thought I remembered it compressing nicely enough, = but then again now googling it the first hit is "Why does base64-encoded = data compress so bad?" All in all, I agree with Brandon. If BINARY is included, it needs to be = defined better. Here are links to my old troubles with it: = http://mailman13.u.washington.edu/pipermail/imap-protocol/2012-December/00= 1908.html = = http://mailman13.u.washington.edu/pipermail/imap-protocol/2012-August/0018= 02.html = = http://mailman13.u.washington.edu/pipermail/imap-protocol/2012-June/001788= .html = = http://mailman13.u.washington.edu/pipermail/imap-protocol/2012-June/001787= .html = > On 10 Nov 2018, at 1.17, Brandon Long = wrote: >=20 > BINARYMIMEWe ran into some issues trying to implement BINARY, and also = didn't see a large number of clients which supported it (looking back, = we did this work mostly in 2014, so a while back). My memory is a bit = sketchy of everything we ran into. >=20 > If I recall, we had some questions with the standard, ie what happens = if you request binary for non-leaf branches of the MIME tree = (section-binary implies that there's something special about what you = can request, but it's actually just the section-part). Ie, if you ask = for BINARY on a message/rfc822, are we supposed to decode each = individual part in that multipart? Again, we could have just responded = NO with unknown-cte, I guess. There was also the question of what to do = with data we'd munged, ie we have heuristics for extracting base64 data = when there are multiple sections of it, or where a mailing list appended = a non-encoded footer on base64 data, etc, we probably would have just = sent the data we'd extracted instead of giving an unknown-cte response, = for example. >=20 > We also had some issues with binary append which I don't recall, = though that you can just not support with some minor annoyance (why it = didn't have a separate CAPABILITY for APPEND instead of just allowing = the server to say NO, I dunno). If I recall, we were worried about what = version to store and what to vend to non BINARY requests, and how that = interoperated. I guess this wouldn't have mattered that much, we = already have a "buggy" APPEND by the standard, since the standard = basically says you have to accept whatever crap they APPEND, even if not = an email message, and we have some base level requirements for message = formatting. >=20 > Overall, it was a part of our investigation into using binary more in = emali, ie cte binary and smtp (BDAT and BINARYMIME). We implemented = BDAT, but our testing basically showed very few clients or servers that = could handle cte binary with embedded nulls. >=20 > Perhaps a cleaned up more strictly specified BINARY could be included, = otherwise I think you'll get a lot of unknown-cte responses from folks = who have to claim support but can't. > For one, its not clear that you can stream a base64 decode, at the = least you'd need to do two passes, one to verify correctness of the = base64 data, and the second to stream decode it. >=20 > Brandon >=20 > On Thu, Nov 8, 2018 at 3:34 AM Bron Gondwana > wrote: > This is one of the open issues from imap4rev2 - which extensions = should be part of the mandatory baseline. >=20 > This one might need some clarification from Alexey - I'm not sure why = it's not trivially obviously a good thing to include. There was some = stuff about "ability to fetch the decoded size" discussed, but I didn't = capture good notes. >=20 > Arguments for and against, or additional discussion, in response to = this please. >=20 > Cheers, >=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 = > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra --Apple-Mail=_756D46AB-2F17-493B-AECD-8684F1BC67C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = remember the BINARY specification wasn't very clear for all the = troublesome cases. I mostly implemented it by thinking what made the = most sense to me. Also I vaguely remember there being some talk about = updating the RFC related to these? I couldn't find a new one now, so I = guess that plan died.

I was also thinking whether COMPRESS (or TLS compression) = might make BINARY irrelevant. I thought I remembered it compressing = nicely enough, but then again now googling it the first hit is "Why does = base64-encoded data compress so bad?"

All in all, I agree with Brandon. If BINARY is = included, it needs to be defined better. Here are links to my old = troubles with it:


On 10 Nov 2018, at 1.17, = Brandon Long <blong=3D40google.com@dmarc.ietf.org> wrote:

BINARYMIMEWe ran into some issues trying to implement BINARY, = and also didn't see a large number of clients which supported it = (looking back, we did this work mostly in 2014, so a while back).  = My memory is a bit sketchy of everything we ran into.

If I recall, we had some questions with = the standard, ie what happens if you request binary for non-leaf = branches of the MIME tree (section-binary implies that there's something = special about what you can request, but it's actually just the = section-part).  Ie, if you ask for BINARY on a message/rfc822, are = we supposed to decode each individual part in that multipart?  = Again, we could have just responded NO with unknown-cte, I guess.  = There was also the question of what to do with data we'd munged, ie we = have heuristics for extracting base64 data when there are multiple = sections of it, or where a mailing list appended a non-encoded footer on = base64 data, etc, we probably would have just sent the data we'd = extracted instead of giving an unknown-cte response, for = example.

We = also had some issues with binary append which I don't recall, though = that you can just not support with some minor annoyance (why it didn't = have a separate CAPABILITY for APPEND instead of just allowing the = server to say NO, I dunno).  If I recall, we were worried about = what version to store and what to vend to non BINARY requests, and how = that interoperated.  I guess this wouldn't have mattered that much, = we already have a "buggy" APPEND by the standard, since the standard = basically says you have to accept whatever crap they APPEND, even if not = an email message, and we have some base level requirements for message = formatting.

Overall, it was a part of our investigation into using binary = more in emali, ie cte binary and smtp (BDAT and BINARYMIME).  We = implemented BDAT, but our testing basically showed very few clients or = servers that could handle cte binary with embedded nulls.

Perhaps a cleaned up = more strictly specified BINARY could be included, otherwise I think = you'll get a lot of unknown-cte responses from folks who have to claim = support but can't.
For one, its not clear that you = can stream a base64 decode, at the least you'd need to do two passes, = one to verify correctness of the base64 data, and the second to stream = decode it.

Brandon

On Thu, Nov 8, 2018 at = 3:34 AM Bron Gondwana <brong@fastmailteam.com> wrote:
This is one of = the open issues from imap4rev2 - which extensions should be part of the = mandatory baseline.

This one might need some clarification from Alexey - I'm not = sure why it's not trivially obviously a good thing to include.  = There was some stuff about "ability to fetch the decoded size" = discussed, but I didn't capture good notes.

Arguments for and against, or = additional discussion, in response to this please.

Cheers,

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

= --Apple-Mail=_756D46AB-2F17-493B-AECD-8684F1BC67C7-- From nobody Fri Nov 9 18:14: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 EE6D6130E41 for ; Fri, 9 Nov 2018 18:14:27 -0800 (PST) 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 ZqERlAUYnrGG for ; Fri, 9 Nov 2018 18:14:25 -0800 (PST) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id E1F93130E35 for ; Fri, 9 Nov 2018 18:14:24 -0800 (PST) Received: from [192.168.10.106] (unknown [91.155.205.240]) by tss.iki.fi (Postfix) with ESMTPSA id A3DE22B3CCA; Sat, 10 Nov 2018 02:14:23 +0000 (UTC) From: Timo Sirainen Message-Id: <9CA9D1B7-CB4B-4D8B-8A53-B92E815F690F@iki.fi> Content-Type: multipart/alternative; boundary="Apple-Mail=_F53D91BE-EA87-4D7C-B692-6C532A5BF06B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 10 Nov 2018 04:14:22 +0200 In-Reply-To: Cc: stujenerin=40aol.com@dmarc.ietf.org, extra@ietf.org To: Brandon Long References: <222011778.12006.1541435419815@appsuite.open-xchange.com> <5BE4D9CA.2040809@aol.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 02:14:28 -0000 --Apple-Mail=_F53D91BE-EA87-4D7C-B692-6C532A5BF06B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think from IMAP protocol purity point of view it would be nice if we = didn't have fields that could suddenly change without any indication. = But from a practical point of view: Who cares, really? The previews are = mainly intended for clients that don't have a local cache. Even if we = implemented modseq changes for previews, would any client (that has more = than a couple of users) ever really use them? I find it doubtful. More = likely these additional requirements would make it more difficult for = servers to implement this feature, so the clients wouldn't have it at = all. > On 9 Nov 2018, at 21.14, Brandon Long = wrote: >=20 > Do we think this is likely to be used for full-sync clients? = Theoretically, those could just generate their own snippets locally from = the rest of the data. >=20 > For online clients, the preview would just be part of what they = download to display the message list. >=20 > Without QRESYNC, we still have some ugly polling, though obviously = PREVEIWS are larger than UIDs. >=20 > OTOH, I feel we already have part of this type of problem today, where = improvements to our parsers or encoding detection might change our = response to any > given message based request, but obviously we won't rev the = UIDVALIDITY folders on every bi-weekly release when its only ever going = to affect a small number of messages. >=20 > Brandon >=20 > On Thu, Nov 8, 2018 at 4:52 PM Stuart Brandt = > wrote: > I know I brought this up years ago, but I'm not sure I ever saw solid=20= > resolution. If, as proposed, the Preview is mutable, then are we not=20= > addressing how to efficiently identify and sync changes that might = have=20 > been made to it? If I were a client dev, I'd want to have the most=20 > recent Preview for a message because a new version likely means: > a) server fixed a defective preview > b) server improved preview's value-to-user >=20 > Mutable data without an efficient way to sync leads to ugly polling. >=20 > - Stu >=20 > On 11/8/2018 7:03 AM, Bron Gondwana wrote: > > Hi Michael, > > > > Thanks again for submitting this, and apologies that I haven't done = a > > thorough review yet - it's on my todo list and I expect to do so = soon. > > > > The ONLY remaining question was length. 200 is good, but JMAP says = 255 > > and consistency will make it better. Unless you have a strong = reason to > > lock it down to 200, would you consider changing it to "no more than = 255 > > octets" with an understanding that there's no requirement that = servers > > have to store that much, just that clients must be willing to accept > > that much. That will keep everything consistent. > > > > Other than this, we believe we're ready to take this document to = working > > group last call, which I intend to do once I've heard back from you = - > > it's easy to fix this up during last call. > > > > Thanks for your work and for getting us the update in time for this = meeting. > > > > Cheers, > > > > Bron. > > > > On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: > >> I've submitted an update to the (formerly snippet, now) preview = draft > >> incorporating feedback received from this list and other = implementers. > >> > >> Main change is the name - this is now "PREVIEW" instead of = "SNIPPET". > >> Also, increased recommended preview size to 200 characters > >> (previously: 100). > >> > >> Will not be able to remotely join IETF 103 meeting as I am = traveling, > >> but wanted to make sure this draft was updated before then. > >> > >> michael > >> > >> _______________________________________________ > >> Extra mailing list > >> Extra@ietf.org > >> https://www.ietf.org/mailman/listinfo/extra = > >> > > > > -- > > Bron Gondwana, CEO, FastMail Pty Ltd > > brong@fastmailteam.com > > > > > > > > > > _______________________________________________ > > Extra mailing list > > Extra@ietf.org > > https://www.ietf.org/mailman/listinfo/extra = > > >=20 > _______________________________________________ > 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 --Apple-Mail=_F53D91BE-EA87-4D7C-B692-6C532A5BF06B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think from IMAP protocol purity point of view it would be nice if we = didn't have fields that could suddenly change without any indication. = But from a practical point of view: Who cares, really? The previews are = mainly intended for clients that don't have a local cache. Even if we = implemented modseq changes for previews, would any client (that has more = than a couple of users) ever really use them? I find it doubtful. More = likely these additional requirements would make it more difficult for = servers to implement this feature, so the clients wouldn't have it at = all.

On 9 Nov 2018, at 21.14, Brandon Long <blong=3D40google.com@dmarc.ietf.org> wrote:

Do we think this is likely to be used for full-sync = clients?  Theoretically, those could just generate their own = snippets locally from the rest of the data.

For online clients, the preview would just be part of what = they download to display the message list.

Without QRESYNC, we still have some = ugly polling, though obviously PREVEIWS are larger than UIDs.

OTOH, I feel we already have part of this type = of problem today, where improvements to our parsers or encoding = detection might change our response to any
given = message based request, but obviously we won't rev the UIDVALIDITY = folders on every bi-weekly release when its only ever going to affect a = small number of messages.

Brandon

On Thu, Nov 8, 2018 at = 4:52 PM Stuart Brandt <stujenerin=3D40aol.com@dmarc.ietf..org> wrote:
I know I brought this = up years ago, but I'm not sure I ever saw solid
resolution. If, as proposed, the Preview is mutable, then are we not
addressing how to efficiently identify and sync changes that might have =
been made to it? If I were a client dev, I'd want to have the most
recent Preview for a message because a new version likely means:
a) server fixed a defective preview
b) server improved preview's value-to-user

Mutable data without an efficient way to sync leads to ugly polling.

- Stu

On 11/8/2018 7:03 AM, Bron Gondwana wrote:
> Hi Michael,
>
> Thanks again for submitting this, and apologies that I haven't done = a
> thorough review yet - it's on my todo list and I expect to do so = soon.
>
> The ONLY remaining question was length.  200 is good, but JMAP = says 255
> and consistency will make it better.  Unless you have a strong = reason to
> lock it down to 200, would you consider changing it to "no more = than 255
> octets" with an understanding that there's no requirement that = servers
> have to store that much, just that clients must be willing to = accept
> that much.  That will keep everything consistent.
= >
> Other than this, we believe we're ready to take this document to = working
> group last call, which I intend to do once I've heard back from you = -
> it's easy to fix this up during last call.
>
> Thanks for your work and for getting us the update in time for this = meeting.
>
> Cheers,
>
> Bron.
>
> On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote:
>> I've submitted an update to the (formerly snippet, now) preview = draft
>> incorporating feedback received from this list and other = implementers.
>>
>> Main change is the name - this is now "PREVIEW" instead of = "SNIPPET".
>> Also, increased recommended preview size to 200 characters
>> (previously: 100).
>>
>> Will not be able to remotely join IETF 103 meeting as I am = traveling,
>> but wanted to make sure this draft was updated before then.
>>
>> michael
>>
>> _______________________________________________
>> Extra mailing list
>> Extra@ietf.org
>> https://www.ietf.org/mailman/listinfo/extra
>>
>
> --
>    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
_______________________________________________
Extra = mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra

= --Apple-Mail=_F53D91BE-EA87-4D7C-B692-6C532A5BF06B-- From nobody Fri Nov 9 21:15: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 62835131122 for ; Fri, 9 Nov 2018 21:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=iPSUcyGF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oOhWzrl0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUGWRNf8HLCO for ; Fri, 9 Nov 2018 21:15:17 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90AAE1310D8 for ; Fri, 9 Nov 2018 21:15:17 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DA2EE21FDA for ; Sat, 10 Nov 2018 00:15:16 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 10 Nov 2018 00:15:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=dG3QvJsFkd2xmy+K/o0IZNLRJIKy GX4b2ZhUq8zC+CM=; b=iPSUcyGF1TlVV+GvWVPK58DsnsLWkw1Kksa1SB9yHU1L UbkomMM9unIlnztxhe+1ka/jbvfjZkWziXvzDQwF8isY4rDT3fji5CfEeQxIMNrs p0LMix7YKMETiGmEtBiaYpse7O0MwjD2TH7IKmqUSMjty+w+fKNIeUaIm1SEgEWK 9kL1OBLNKlRylxfWp53amsG0ERzrcPzAYBG9ZttPcD0XiU2nyeKo1+RtiLM9JykH a8HVFzLRDGOZZOAMcTL3Zg1BZxjWAqbtp7NYBLrcL/64A32Dy4FiDq19Zb2Jx0m5 XR6Uma7lBsKoF5F6d4QRWvHMwpmq1dPWAeG4OqjAJw== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dG3QvJsFkd2xmy+K/ o0IZNLRJIKyGX4b2ZhUq8zC+CM=; b=oOhWzrl0hqt3ppPLJUdHX0S29S2W4dMlK e+3ICpezFQ9avP80QDmW/DwiKjm9uY+4v9c0bcF/g83bE94oCEu2tY1XHi8rh0VW 8YcUxUV8Lgl+DD86thuYQOPSAa0xY4gbub5rfPN7xqvjkVxgJqSGrsrnh1bkY+Qz jb3hqSU8LzKMTYlU9YLWcM5JW6kMVD9A1enY6Q6qLThiL49OrcdVd4aDi6pwhP7a CGEejmhI/3muXJAIg02ORhFkuJTz6jdJlG45UeGRLnxDYkqm6dFj9Vuos0Ebqofr 0fTXDAV89MHLtrIRRfE9Ye+RnfB7aPn614m0jzZztUh5J6NDr6cOg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7B6B62030B; Sat, 10 Nov 2018 00:15:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: <9CA9D1B7-CB4B-4D8B-8A53-B92E815F690F@iki.fi> References: <222011778.12006.1541435419815@appsuite.open-xchange.com> <5BE4D9CA.2040809@aol.com> <9CA9D1B7-CB4B-4D8B-8A53-B92E815F690F@iki.fi> Date: Sat, 10 Nov 2018 00:15:15 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=776fe583cb174dd48be10bddc5a776c8 Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 05:15:23 -0000 --776fe583cb174dd48be10bddc5a776c8 Content-Type: text/plain That's my attitude to previews too, they don't "change" but they might not be byte identical if fetched again later due to changing server algorithms. The old value is never "wrong" though, short of buggy servers. Bron. On Sat, 10 Nov 2018, at 13:14, Timo Sirainen wrote: > I think from IMAP protocol purity point of view it would be nice if we didn't have fields that could suddenly change without any indication. But from a practical point of view: Who cares, really? The previews are mainly intended for clients that don't have a local cache. Even if we implemented modseq changes for previews, would any client (that has more than a couple of users) ever really use them? I find it doubtful. More likely these additional requirements would make it more difficult for servers to implement this feature, so the clients wouldn't have it at all. > >> On 9 Nov 2018, at 21.14, Brandon Long wrote: >> >> Do we think this is likely to be used for full-sync clients? Theoretically, those could just generate their own snippets locally from the rest of the data. >> >> For online clients, the preview would just be part of what they download to display the message list. >> >> Without QRESYNC, we still have some ugly polling, though obviously PREVEIWS are larger than UIDs. >> >> OTOH, I feel we already have part of this type of problem today, where improvements to our parsers or encoding detection might change our response to any >> given message based request, but obviously we won't rev the UIDVALIDITY folders on every bi-weekly release when its only ever going to affect a small number of messages. >> >> Brandon >> >> On Thu, Nov 8, 2018 at 4:52 PM Stuart Brandt > wrote: >>> I know I brought this up years ago, but I'm not sure I ever saw solid >>> resolution. If, as proposed, the Preview is mutable, then are we not >>> addressing how to efficiently identify and sync changes that might have >>> been made to it? If I were a client dev, I'd want to have the most >>> recent Preview for a message because a new version likely means: >>> a) server fixed a defective preview >>> b) server improved preview's value-to-user >>> >>> Mutable data without an efficient way to sync leads to ugly polling. >>> >>> - Stu >>> >>> On 11/8/2018 7:03 AM, Bron Gondwana wrote: >>> > Hi Michael, >>> > >>> > Thanks again for submitting this, and apologies that I haven't done a >>> > thorough review yet - it's on my todo list and I expect to do so soon. >>> > >>> > The ONLY remaining question was length. 200 is good, but JMAP says 255 >>> > and consistency will make it better. Unless you have a strong reason to >>> > lock it down to 200, would you consider changing it to "no more than 255 >>> > octets" with an understanding that there's no requirement that servers >>> > have to store that much, just that clients must be willing to accept >>> > that much. That will keep everything consistent. >>> > >>> > Other than this, we believe we're ready to take this document to working >>> > group last call, which I intend to do once I've heard back from you - >>> > it's easy to fix this up during last call. >>> > >>> > Thanks for your work and for getting us the update in time for this meeting. >>> > >>> > Cheers, >>> > >>> > Bron. >>> > >>> > On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: >>> >> I've submitted an update to the (formerly snippet, now) preview draft >>> >> incorporating feedback received from this list and other implementers. >>> >> >>> >> Main change is the name - this is now "PREVIEW" instead of "SNIPPET". >>> >> Also, increased recommended preview size to 200 characters >>> >> (previously: 100). >>> >> >>> >> Will not be able to remotely join IETF 103 meeting as I am traveling, >>> >> but wanted to make sure this draft was updated before then. >>> >> >>> >> michael >>> >> >>> >> _______________________________________________ >>> >> Extra mailing list >>> >> Extra@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/extra >>> >> >>> > >>> > -- >>> > 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 >> _______________________________________________ >> 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 --776fe583cb174dd48be10bddc5a776c8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
That's my attitude to previews too, they don't "change" bu= t they might not be byte identical if fetched again later due to changin= g server algorithms. The old value is never "wrong" though, short of bug= gy servers.

Bron.
=
On Sat, 10 Nov 2018, at 13:1= 4, Timo Sirainen wrote:
I think from IMAP protocol p= urity point of view it would be nice if we didn't have fields that could= suddenly change without any indication. But from a practical point of v= iew: Who cares, really? The previews are mainly intended for clients tha= t don't have a local cache. Even if we implemented modseq changes for pr= eviews, would any client (that has more than a couple of users) ever rea= lly use them? I find it doubtful. More likely these additional requireme= nts would make it more difficult for servers to implement this feature, = so the clients wouldn't have it at all.

On 9 Nov 2018, at 21.14, Brandon = Long <blong=3D40google.com@dmarc.ietf.org> wrote:

Do we think this is likely to be used for full-sync cli= ents?  Theoretically, those could just generate their own snippets = locally from the rest of the data.

For online clients, the preview would just be part of what the= y download to display the message list.

Without QRESYNC, we still have some ugly polling, tho= ugh obviously PREVEIWS are larger than UIDs.

OTOH, I feel= we already have part of this type of problem today, where improvements = to our parsers or encoding detection might change our response to any
given message based request= , but obviously we won't rev the UIDVALIDITY folders on every bi-weekly = release when its only ever going to affect a small number of messages.

Brandon

<= /div>
On Thu, Nov 8, 2018 at 4:52 PM Stuart Brandt <stu= jenerin=3D40aol.com@dmarc.ietf..org> wrote:
I know I brought this up years ago= , but I'm not sure I ever saw solid
resolution. If, as proposed, the Preview is mutable, then are w= e not
addressing how to eff= iciently identify and sync changes that might have
been made to it? If I were a client dev, I'd want = to have the most
recent Pre= view for a message because a new version likely means:
a) server fixed a defective preview
=
b) server improved preview's value-to= -user

Mutable data without an efficient way to sync lead= s to ugly polling.

- Stu

On 11/8/2018 = 7:03 AM, Bron Gondwana wrote:
> Hi Michael,
>
<= /div>
> Thanks again for submitting= this, and apologies that I haven't done a
> thorough review yet - it's on my todo list and I exp= ect to do so soon.
>
<= /div>
> The ONLY remaining question= was length.  200 is good, but JMAP says 255
> and consistency will make it better.  Un= less you have a strong reason to
> lock it down to 200, would you consider changing it to "no mor= e than 255
> octets" with= an understanding that there's no requirement that servers
> have to store that much, just that c= lients must be willing to accept
> that much.  That will keep everything consistent.
>
> Other than this, we believe we're ready to take this = document to working
> gro= up last call, which I intend to do once I've heard back from you -
> it's easy to fix this up dur= ing last call.
>
> Thanks for your work and for ge= tting us the update in time for this meeting.
>
> = Cheers,
>
> Bron.
>
> On Tue= , Nov 6, 2018, at 03:30, Michael Slusarz wrote:
>> I've submitted an update to the (formerly s= nippet, now) preview draft
&= gt;> incorporating feedback received from this list and other impleme= nters.
>>
>> Main change is the name - this = is now "PREVIEW" instead of "SNIPPET".
>> Also, increased recommended preview size to 200 char= acters
>> (previously:= 100).
>>
>> Will not be able to remotely jo= in IETF 103 meeting as I am traveling,
>> but wanted to make sure this draft was updated befor= e then.
>>
>> michael
>>
>> _______________________________________________
>> Extra mailing list
>> Extra@ietf.org
>>
>
> --
>    Bron Gondwana, CEO, FastMail Pty Ltd=
>
<= div style=3D"font-family:Arial;"> >
>
>
> ______________________________= _________________
> Extra= mailing list
>
<= br>
____________________________= ___________________
Extra ma= iling list
=
_________________________________________= ______
Extra mailing list
=
https://www.ietf.org/mailman/listinfo/extra
=

_______________________________________________
Extra ma= iling list
Extra@ietf.org
https://www.ietf.o= rg/mailman/listinfo/extra


--
  Bron Gondwana, C= EO, FastMail Pty Ltd
  brong@fast= mailteam.com

--776fe583cb174dd48be10bddc5a776c8-- From nobody Sun Nov 11 15:38: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 01C44130E2F for ; Sun, 11 Nov 2018 15:38:29 -0800 (PST) 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 by2gKW6dsOUF for ; Sun, 11 Nov 2018 15:38:26 -0800 (PST) Received: from sonic313-14.consmr.mail.bf2.yahoo.com (sonic313-14.consmr.mail.bf2.yahoo.com [74.6.133.124]) (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 0F23E130E48 for ; Sun, 11 Nov 2018 15:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1541979504; bh=+ALhwEY+bgOv+d703S4aaagvieDCsymfHY1DipvTnk8=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=F/wAWylpaSqBJ1DHF+04G13LdqRq5yXQVFzK7EMpt8XvLXScmFvSbbOl1L+1vguV5dS7gjcqyxc5R3WxbdPNqIN16CU7m58j9iWVtOiL/Vo8sg3QpkrXM1fe8uC8kHH9i35jim5d1shXKGHop3ijIfjj2sFWFnn6kKpYqexhtSGddzgN9WnrmOrg6yrCBomWD8sKSy8JSr9l2pIsrYgCQvDV2pXngoZ/mXbSiYn6QySAbP5GkZl+vJ39nRXgXPLRtGrZqtwXJ4GtKwd/7DSUNI52vupv9ZNPtkL9tdvjadoPRZct4Akpkbe9WJsPKoQlA+GK3hOKtxk8ark/UgcGGg== X-YMail-OSG: XYo5hdkVM1lxQNttsD4An9m0ywv0aJMwRBufGGT.DIyu6rGdoMI0Vlw97Uoh3nY fp10wE4jYCiU7KBhWl6aGMkuuHW9qffTMkprX1neLkHplBzRsKRSvmPtOl5EX6hyxJ2gEqKWbRc3 NkbKl.uwEpGQLfaTZBIG.zSpfIErg_iHRG6HoiY8eQMqwWp.HK1a2EtCUzM4aB0FkbxX6SZtUum3 qCiqE_0Yf8HdBlGxuW0XWdyzQUlL.0hYJvWC7TcEpebsjBB8NPkM2jr1vlr6JJT0qutH9ac.6BkO w9vugsUFdgFu.7wx0PcMzfIdOD3GZnm8GCQt9VsRKMJJ887wnLT6y5OVkGuZBfcTxHc068WKNQ0h CCndPs8bFEiQfuLxyoLwjxyLH0sy.In52mpKdK9bdedMsIl7sHVC.6UPmlDNc2PR6N37wZZOojM3 dzSXZNiVG1Bpj6H5syswKSf7cEerQuO9kGW6ur20qoOtoYY.HkUi3.VzC77B05EhFRqkKsl1h8E1 xKqyzqQYyAGDXxKRkxftSF5mbfqDblj1eWsHBNBu6aIKDYF6oIk.qrHVhUxpqsvSPGiH4CXzcJ5o OVN_TLOypOy6lgQdmqaz6y9dBtnz2t7L8ETnvhtRb.nVnwbBB4xsdmdfqclRbvkNAQz4ZWfQ1iwC vQYZb2N0GhQRwyQi_5fHQtcrqLnDYYmpycduz_Pvx8fcDuiJRH61LFhbVc0vjPaEjpoAjXp3TSUV B6F4nk3bNlYmiIdw6H6WXzLAj1CSq.qEaHgBrEEHmXlKaopz0o.mpBqxob.9AT2Yqtc7e9pzXsD. ldQYTz7MAiXSCNPikydHJuG1sMxfKEKJufrmAjmRAofeytCvz3WHsA0Vi0JnJpAya5PN1jlTYJq. pev37Yvb37y2RR39i1_b828fi0vxNNLMuoupnUWWAIUOw8LFebnVc.ADM.m05qFdOPEd_eCpEWn7 7Cxow6LBpfs31SdBjtilRDW0LvNNio_VUog2_Z44l3vDIizep5TzcNha3JVaGhUHUMARNrbpjtkg wPL1SPvTXqH_W Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Sun, 11 Nov 2018 23:38:24 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp420.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1736d2dd96a40834d5c0c8274cbd514f for ; Sun, 11 Nov 2018 23:38:23 +0000 (UTC) To: extra@ietf.org References: <222011778.12006.1541435419815@appsuite.open-xchange.com> <5BE4D9CA.2040809@aol.com> <9CA9D1B7-CB4B-4D8B-8A53-B92E815F690F@iki.fi> From: Stuart Brandt Message-ID: <5BE8BD67.3060507@aol.com> Date: Sun, 11 Nov 2018 18:38:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Nov 2018 23:38:36 -0000 If this is the case, then it might be best to include some level of recommendation in the draft that clients *not* make an effort to stay up to date with any changes that the server might make. I sure would hate to see FETCH 1:* (FLAGS) become FETCH 1:* (FLAGS PREVIEW), adding up to 255bytes per item to the FETCH response just because PREVIEW *might* change. - Stu On 11/10/2018 12:15 AM, Bron Gondwana wrote: > That's my attitude to previews too, they don't "change" but they might > not be byte identical if fetched again later due to changing server > algorithms. The old value is never "wrong" though, short of buggy servers. > > Bron. > > On Sat, 10 Nov 2018, at 13:14, Timo Sirainen wrote: >> I think from IMAP protocol purity point of view it would be nice if we >> didn't have fields that could suddenly change without any indication. >> But from a practical point of view: Who cares, really? The previews >> are mainly intended for clients that don't have a local cache. Even if >> we implemented modseq changes for previews, would any client (that has >> more than a couple of users) ever really use them? I find it doubtful. >> More likely these additional requirements would make it more difficult >> for servers to implement this feature, so the clients wouldn't have it >> at all. >> >>> On 9 Nov 2018, at 21.14, Brandon Long >>> >> > wrote: >>> >>> Do we think this is likely to be used for full-sync clients? >>> Theoretically, those could just generate their own snippets locally >>> from the rest of the data. >>> >>> For online clients, the preview would just be part of what they >>> download to display the message list. >>> >>> Without QRESYNC, we still have some ugly polling, though obviously >>> PREVEIWS are larger than UIDs. >>> >>> OTOH, I feel we already have part of this type of problem today, >>> where improvements to our parsers or encoding detection might change >>> our response to any >>> given message based request, but obviously we won't rev the >>> UIDVALIDITY folders on every bi-weekly release when its only ever >>> going to affect a small number of messages. >>> >>> Brandon >>> >>> On Thu, Nov 8, 2018 at 4:52 PM Stuart Brandt >>> >> > wrote: >>> >>> I know I brought this up years ago, but I'm not sure I ever saw >>> solid >>> resolution. If, as proposed, the Preview is mutable, then are we not >>> addressing how to efficiently identify and sync changes that >>> might have >>> been made to it? If I were a client dev, I'd want to have the most >>> recent Preview for a message because a new version likely means: >>> a) server fixed a defective preview >>> b) server improved preview's value-to-user >>> >>> Mutable data without an efficient way to sync leads to ugly polling. >>> >>> - Stu >>> >>> On 11/8/2018 7:03 AM, Bron Gondwana wrote: >>> > Hi Michael, >>> > >>> > Thanks again for submitting this, and apologies that I haven't >>> done a >>> > thorough review yet - it's on my todo list and I expect to do >>> so soon. >>> > >>> > The ONLY remaining question was length. 200 is good, but JMAP >>> says 255 >>> > and consistency will make it better. Unless you have a strong >>> reason to >>> > lock it down to 200, would you consider changing it to "no more >>> than 255 >>> > octets" with an understanding that there's no requirement that >>> servers >>> > have to store that much, just that clients must be willing to >>> accept >>> > that much. That will keep everything consistent. >>> > >>> > Other than this, we believe we're ready to take this document >>> to working >>> > group last call, which I intend to do once I've heard back from >>> you - >>> > it's easy to fix this up during last call. >>> > >>> > Thanks for your work and for getting us the update in time for >>> this meeting. >>> > >>> > Cheers, >>> > >>> > Bron. >>> > >>> > On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: >>> >> I've submitted an update to the (formerly snippet, now) >>> preview draft >>> >> incorporating feedback received from this list and other >>> implementers. >>> >> >>> >> Main change is the name - this is now "PREVIEW" instead of >>> "SNIPPET". >>> >> Also, increased recommended preview size to 200 characters >>> >> (previously: 100). >>> >> >>> >> Will not be able to remotely join IETF 103 meeting as I am >>> traveling, >>> >> but wanted to make sure this draft was updated before then. >>> >> >>> >> michael >>> >> >>> >> _______________________________________________ >>> >> Extra mailing list >>> >> Extra@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/extra >>> >> >>> > >>> > -- >>> > 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 >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Sun Nov 11 18:48: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 04340127B92 for ; Sun, 11 Nov 2018 18:48:48 -0800 (PST) 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=XadeqjTT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JfaUdvNc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2fIGvA-2in1 for ; Sun, 11 Nov 2018 18:48:46 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356A0124BE5 for ; Sun, 11 Nov 2018 18:48:46 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1120621111 for ; Sun, 11 Nov 2018 21:48:43 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 11 Nov 2018 21:48:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=ml43GoUG6JtglFWyrj6tps47v4i/ slY1yKwTQvsxDc4=; b=XadeqjTTVKAhWPF76DNhFYfy2h7b7iX0QG6+nVOgpuDM RW1g5fS460HplJGXjUjSOk6RyLWu/RICkfsmsPfXLEW33MUWBz7+S0aWfigMddlD uVGYgP2Nw7aJJJrFsiBrwIGSpRk/eNVrpOA0E2TqkvH3GWPrmQkR3idQfvKLz8w6 R/2c+e+qj945W1sG9/4BewIXynx+9vBq9NSybdfCO4UrcQIpJAXvMBbtcqQ3wRGx LjE0+Ib71Lgv2GtY3jX9M0WyGgyyLypN5qFtHtgHVl2r/qS9wbi0paxDcrT7LChp NIwzTmnkS4nj7TXK0Bv4i3MKU4TfWtldh+a6sQHs6w== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ml43GoUG6JtglFWyr j6tps47v4i/slY1yKwTQvsxDc4=; b=JfaUdvNc8YrD/XVLl5FdZrnkajgbuKC5N CiSLWaM8NpJMY5Xxp1xoYNyMtR++lX7RYsaAPsJdQujBkRwFcTsX6UsO8PbedW+t 3dziRw4Cgl07kUye57GrO4h2RN+PHkEFiQANiksimovQbD14KdjKRNQBABqm2Lo2 bI1hN0SSDAUgIrsal7kpJJlw72G+nFHwzAI0j3ThiD0BDDwxNWwQaX3WdPqK7zHu F2xJETblBu6u/+4/1kv6tpfdNqBqJGVRYY6wphVl8jp1DsAfuPlZ4NKXUk3/ySMu ktbl2Of5OZUaPV9NU5We63H2hcXS+qBvj+jPNOqk0KKC2qQZe37Cg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 41D752030B; Sun, 11 Nov 2018 21:48:43 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <004c11b5-6f5d-49aa-951d-bf561124a8f7@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 In-Reply-To: <5BE8BD67.3060507@aol.com> References: <222011778.12006.1541435419815@appsuite.open-xchange.com> <5BE4D9CA.2040809@aol.com> <9CA9D1B7-CB4B-4D8B-8A53-B92E815F690F@iki.fi> <5BE8BD67.3060507@aol.com> Date: Sun, 11 Nov 2018 21:48:42 -0500 From: "Neil Jenkins" To: extra@ietf.org Content-Type: multipart/alternative; boundary=786d7e0c1c54402a8d2d9516227f2595 Archived-At: Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 12 Nov 2018 02:48:48 -0000 --786d7e0c1c54402a8d2d9516227f2595 Content-Type: text/plain On Mon, 12 Nov 2018, at 10:38 AM, Stuart Brandt wrote: > If this is the case, then it might be best to include some level of > recommendation in the draft that clients *not* make an effort to stay up > to date with any changes that the server might make. I sure would hate > to see FETCH 1:* (FLAGS) become FETCH 1:* (FLAGS PREVIEW), > adding up to 255bytes per item to the FETCH response just because > PREVIEW *might* change. That sounds reasonable. In the JMAP spec, the "preview" field is marked as immutable (as are all fields except keywords and mailboxes, to match IMAP). I would agree that in practice it might change if the server updates its algorithm for excluding salutations, or fixes a MIME parsing bug, (just as the latter might affect the body structure returned), but this previous value is not considered "wrong" and clients are not informed of the changes, nor expected to resync them. Neil. --786d7e0c1c54402a8d2d9516227f2595 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, 12 Nov = 2018, at 10:38 AM, Stuart Brandt wrote:
If this is the case, then it might be bes= t to include some level of 
recommendation in the dra= ft that clients *not* make an effort to stay up 
to d= ate with any changes that the server might make. I sure would hate =
to see <tag> FETCH 1:* (FLAGS) become <tag> F= ETCH 1:* (FLAGS PREVIEW), 
adding up to 255bytes per = item to the FETCH response just because 
PREVIEW *mig= ht* change.

That sounds reason= able. In the JMAP spec, the "preview" field is marked as immutable (as a= re all fields except keywords and mailboxes, to match IMAP). I would agr= ee that in practice it might change if the server updates its algorithm = for excluding salutations, or fixes a MIME parsing bug, (just as the lat= ter might affect the body structure returned), but this previous value i= s not considered "wrong" and clients are not informed of the changes, no= r expected to resync them.

Neil.
--786d7e0c1c54402a8d2d9516227f2595-- From nobody Mon Nov 12 06:43:17 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 15B3E130E43 for ; Mon, 12 Nov 2018 06:43:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154203379508.4274.14493199271290262099.idtracker@ietfa.amsl.com> Date: Mon, 12 Nov 2018 06:43:15 -0800 From: IETF Secretariat Archived-At: Subject: [Extra] Milestones changed for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 12 Nov 2018 14:43:15 -0000 Changed milestone "Adopt a document for EAI with Sieve", set state to active from review, accepting new milestone. Changed milestone "Adopt a QUOTA-BIS document", set state to active from review, accepting new milestone. Changed milestone "Submit "IMAP4rev2" to IESG as a Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Tue Nov 13 15:11:04 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 58035130DF5 for ; Tue, 13 Nov 2018 15:11:02 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 46HFp370HSY5 for ; Tue, 13 Nov 2018 15:11:00 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7A701130DEE for ; Tue, 13 Nov 2018 15:11:00 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id D885D2B3C92 for ; Wed, 14 Nov 2018 01:10:57 +0200 (EET) To: extra@ietf.org From: Stephan Bosch Message-ID: Date: Wed, 14 Nov 2018 00:10:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------EFD33831B692D7C216C0A137" Content-Language: en-US Archived-At: Subject: [Extra] Implementation questions regarding IMAP REPLACE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 13 Nov 2018 23:11:02 -0000 This is a multi-part message in MIME format. --------------EFD33831B692D7C216C0A137 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I've been evaluating a bit what effort an implementation of IMAP REPLACE would require at our end. I got two remarks/questions now: 1) The MOVE capability has some overlap with this one and that document states the following: The server may send EXPUNGE (or VANISHED) responses before the tagged response, so the client cannot safely send more commands with message sequence number arguments while the server is processing MOVE or UID MOVE. Both MOVE and UID MOVE can be pipelined with other commands, but care has to be taken. Both commands modify sequence numbers and also allow unrelated EXPUNGE responses. The renumbering of other messages in the source mailbox following any EXPUNGE response can be surprising and makes it unsafe to pipeline any command that relies on message sequence numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be pipelined with a command that might cause message renumbering. See[RFC3501], Section 5.5 , for more information about ambiguities as well as handling requirements for both clients and servers. I'd say similar considerations apply to REPLACE, don't they? 2) What happens when the replaced message does not exist at all (no such seqnum/UID). Will the whole command fail or will it assume that the replaced message is already expunged and continue as a normal APPEND? Regards, Stephan. --------------EFD33831B692D7C216C0A137 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I've been evaluating a bit what effort an implementation of IMAP REPLACE would require at our end. I got two remarks/questions now:

1) The MOVE capability has some overlap with this one and that document states the following:

   The server may send EXPUNGE (or VANISHED) responses before the tagged
   response, so the client cannot safely send more commands with message
   sequence number arguments while the server is processing MOVE or UID
   MOVE.

   Both MOVE and UID MOVE can be pipelined with other commands, but care
   has to be taken.  Both commands modify sequence numbers and also
   allow unrelated EXPUNGE responses.  The renumbering of other messages
   in the source mailbox following any EXPUNGE response can be
   surprising and makes it unsafe to pipeline any command that relies on
   message sequence numbers after a MOVE or UID MOVE.  Similarly, MOVE
   cannot be pipelined with a command that might cause message
   renumbering.  See [RFC3501], Section 5.5, for more information about
   ambiguities as well as handling requirements for both clients and
   servers.

I'd say similar considerations apply to REPLACE, don't they?

2) What happens when the replaced message does not exist at all (no such seqnum/UID). Will the whole command fail or will it assume that the replaced message is already expunged and continue as a normal APPEND?

Regards,

Stephan.

--------------EFD33831B692D7C216C0A137-- From nobody Tue Nov 13 19:14: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 13662127148 for ; Tue, 13 Nov 2018 19:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (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 qxPbgQREYYL8 for ; Tue, 13 Nov 2018 19:14:48 -0800 (PST) Received: from sonic308-4.consmr.mail.bf2.yahoo.com (sonic308-4.consmr.mail.bf2.yahoo.com [74.6.130.43]) (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 F0BEA130ED7 for ; Tue, 13 Nov 2018 19:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542165282; bh=UZN2l2bpexcXvo+omCqwdHpaRijYHU1rgr5UWHImxkY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=azUINkKCtqJhcezNLWxUHWNky8D1MZlQ0aNl9MJp91akiU7zPlgP3WIejYwFrVDC1mZi17kIOnQJ+kdsmtXizSo4vvSjcK+kZVJasF3tPEWaLBFYqk6NErxC3ndSoKUZ3pIZb8qn87mSWgtWvCd+mfJ8ia4/mrkuxHEJHtKk5APToyreu1Smsr1s66hw1Yg9u8OnByNGYnyG4sV43esnMabg9mg5uT5G8OaezO7E3o174z9cO2/ZX7Sttz0Ua6oz7QY+oJFczA4e3rlCUu2EHHO74M9XXn6rJ625oc8yHgJ0RKU1pighjHZBVTnAkE3QmYWM+f16Cf9KoUQ6Tl1j0Q== X-YMail-OSG: LA3.LGQVM1kQDCqwARC8iEurwufWXDiXMYZRb10w_zznMmkBnpYIYbVVk8ko93a Kk.RN3ZzfrksQyxn8CEwN5zduk6IDOON9BXa0yzJWgk6QjnlXxHr.rniF.zSueaXggAOlgaBYkd1 0L3_lXni9CoKZjB5bVeKNYrWhI0vsu..9PCKgfIsHGlrAo_ioAcJkJy8Ucm8y5.tPXNMehMsbaaz 7NUkjaXULfymny5kZLeMkJ_59nLU_bHPlcTnh7RU5a7kU5rg4e5QUxqjzpz2quFtKh1hR7XHsuhd fkCK4zn5tNXMITv7DW71oC.dPimaz_j9fhCMlQH239RVlaTPKKmYAi.y9NcnBGSVWmP9D6AM1rM4 KOpgSvUdziEkpMg8QU5Q7ITbpvgy8inYr1ZcsBicwAournLq0ITRZG9ynU.D93MYzIarpQL4HOpB ljQ1WIkfLxkGSBpqCDyw5J1iHkkOJ.HeD_SU5MPdjoLjN0XIwRk6mpwnnioDiWlnC2FCJBYKvp6A g0JjLnA2apN2hFUsvS4ft6jhpm9InihIIr9STaIgenCp5iliRMYf7r.1Mblc_r4iWE6QM78SgS8Q Wcn01rTuo5rmvM9OHQVv47MvoaYKO08z5c4X8UuUdPQjTiUUW.E1TXF_2_Yzt72EsxsWF8izLUuR 8Y7CuQ1IjvRbyCkXWDY6d6dMYYTtDZvBhxC19KFVbUdP_65CHWGUPIeuj9LGgV2I0raLTtg0ckJq bI_Rz9IKdIqUv0tqxa_hPn68.GV51PkXcy1aY6g8.N.gUbUzChbrVEtJu5wQ_khPcCQdcs_5lph2 osMdST8wFPMtPtDmPjelSXvGj5ctqVD_68VsbFBRSvIzwgMDPDqGKeNThmP2NSQ8j5X0qiBy5KOp 6PiHESInmICbGp0V3WPpB6kg_nhMLmsjdMcvmy4RO2UiUurpcI9eIAh2FJsOEDniltIwoyb.xUUe 1aCRJ82zRtDWKz8o3xXhw40HsLfXnNqicp2NW1jBcxNK846LE0mzLlda70D5ayDwm6wumHnDaDZg zrkDlCeqWm_USQg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Wed, 14 Nov 2018 03:14:42 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fe4192eb452ec1a6c83a1a1b6fdc1776 for ; Wed, 14 Nov 2018 03:14:39 +0000 (UTC) To: extra@ietf.org References: From: Stuart Brandt Message-ID: <5BEB9304.1070207@aol.com> Date: Tue, 13 Nov 2018 22:14:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Implementation questions regarding IMAP REPLACE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2018 03:14:50 -0000 Stephan - Thanks for the input...comments inline: On 11/13/2018 6:10 PM, Stephan Bosch wrote: > Hi, > > I've been evaluating a bit what effort an implementation of IMAP REPLACE > would require at our end. I got two remarks/questions now: > > 1) The MOVE capability has some overlap with this one and that document > states the following: > > The server may send EXPUNGE (or VANISHED) responses before the tagged > response, so the client cannot safely send more commands with message > sequence number arguments while the server is processing MOVE or UID > MOVE. > > Both MOVE and UID MOVE can be pipelined with other commands, but care > has to be taken. Both commands modify sequence numbers and also > allow unrelated EXPUNGE responses. The renumbering of other messages > in the source mailbox following any EXPUNGE response can be > surprising and makes it unsafe to pipeline any command that relies on > message sequence numbers after a MOVE or UID MOVE. Similarly, MOVE > cannot be pipelined with a command that might cause message > renumbering. See[RFC3501], Section 5.5 , for more information about > ambiguities as well as handling requirements for both clients and > servers. > > I'd say similar considerations apply to REPLACE, don't they? Likely, yes. > > 2) What happens when the replaced message does not exist at all (no such > seqnum/UID). Will the whole command fail or will it assume that the > replaced message is already expunged and continue as a normal APPEND? The intention is that it would fail and fail quickly -- prior to upload of the replacing data. Continuing with the Append can be problematic in a multi-client/session scenario and can lead to re-introduction of a Draft that was already sent or creation of a draft that appears newer than the one that replaced the referenced message. Additionally, it's important that a client actually *know* when it's not in sync with the present mail store, something that's downright dangerous when dealing with sequence numbers. > > Regards, > > Stephan. > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Thu Nov 15 05:52: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 0349212D4EF for ; Thu, 15 Nov 2018 05:52:33 -0800 (PST) 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 hg9R5GXfBJr3 for ; Thu, 15 Nov 2018 05:52:31 -0800 (PST) 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 E012612D4E7 for ; Thu, 15 Nov 2018 05:52:30 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 41ED3C001B; Thu, 15 Nov 2018 13:53:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1542290011; bh=rKmlie0CGzp0YS5dTL01UdRMpKeBJuxoBR6FoZxKAGE=; h=From:To:Subject:Date:References:From; b=cNniKuzLZm+oI+IO0OULBroSNwWuYL60i6u4+b8sXWz+0ho/Qhzv7syFkLN9kYiRj aNV3O1W5VRVXgSxJdAUxY7h+RUaVHpnsaGjjcf77rfW4RmD6C9Uvvr39hByEYI77fG 0v3cng766RGITPIK8YS8xtJTg7AJwiK9pqCeALtc= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1542290010-32427-32424/10/6033; Thu, 15 Nov 2018 13:53:30 +0000 From: Arnt Gulbrandsen To: extra@ietf.org, Stuart Brandt Date: Thu, 15 Nov 2018 14:52:26 +0100 Message-Id: <+zYCDTO4ZdsjSWin88IbqbIxTnobzOcvIPeIiYbAjBA=.sha-256@antelope.email> References: <5BE4DB10.6090003@aol.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2018 13:52:33 -0000 Move had 10-15 implementations soon after being published as RFC, and judging by my inbox, people did not have problems implementing it. And: it was regularly requested before that time. So... what are the criteria for inclusion, and how can something like move not pass the test? Arnt From nobody Thu Nov 15 08:13: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 55A9C12F1A5 for ; Thu, 15 Nov 2018 08:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 d4qej4ISSvJg for ; Thu, 15 Nov 2018 08:13:00 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 9617B130DDF for ; Thu, 15 Nov 2018 08:13:00 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 814766A356 for ; Thu, 15 Nov 2018 17:12:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1542298378; bh=WmPCV8oNHYSg6taHFuM9bbpwujYlbwqgUwr3dZoEXj0=; h=Date:From:To:In-Reply-To:References:Subject:From; b=lorSwiYzhsz7VlIbcMDpIuQxsATXOjSD8RYy/hwsBBYC9pRkUovSVf0HTowFf2hqb iI+ap3b9NMXgo9/mKvX3mtIDt7PtK3i+YbBUehNaGRo7emqphkwRN+EbFYEqQ/3BA0 gjuxNGqqq2W7EgchrEAJI3vmxhXfGR4rjjzI856UKeXAIPKhjfJQkGCQdQV3NIZhlp UhJNG9l+AyNd4KTCUQTjIJBkoppiKRDFSGJ38A6y0PSuN4zJyPVUpjsaF5v6rtsvnU FhLBCIRFE/qFuzmlF8PfqZwJOlPnz+rtNT8g7WAw3MSW5YTcUOvlmhX2w94H05ySor /2ouUcr7BvlnA== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 7A24F3C17C9 for ; Thu, 15 Nov 2018 17:12:58 +0100 (CET) Date: Thu, 15 Nov 2018 09:12:58 -0700 (MST) From: Michael Slusarz To: extra@ietf.org Message-ID: <776977791.12860.1542298378436@appsuite.open-xchange.com> In-Reply-To: <+zYCDTO4ZdsjSWin88IbqbIxTnobzOcvIPeIiYbAjBA=.sha-256@antelope.email> References: <5BE4DB10.6090003@aol.com> <+zYCDTO4ZdsjSWin88IbqbIxTnobzOcvIPeIiYbAjBA=.sha-256@antelope.email> 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-Rev19 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2018 16:13:02 -0000 > On November 15, 2018 at 6:52 AM Arnt Gulbrandsen wrote: > > Move had 10-15 implementations soon after being published as RFC, and > judging by my inbox, people did not have problems implementing it. And: > it was regularly requested before that time. > > So... what are the > criteria for inclusion, and how can something like move not pass the > test? Playing devil's advocate... what were the reason(s) this wasn't part of previous specs? Was it simply due to the belief that we already have the necessary plumbing to do this (COPY/STORE/EXPUNGE), so MOVE was nothing more than a "shortcut", and shortcuts should be left out lest the base spec get too bloated? (MOVE atomicity guarantees trump this logic, in my opinion. Seems many others share this view.) michael From nobody Thu Nov 15 08:15: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 65308130DE0 for ; Thu, 15 Nov 2018 08:15:44 -0800 (PST) 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 kbpr3aPEe4wp for ; Thu, 15 Nov 2018 08:15:43 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1A130DDF for ; Thu, 15 Nov 2018 08:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1542298542; d=isode.com; s=june2016; i=@isode.com; bh=vR0TnDTEnD1PfUZBIjcpcfp2fsFn6IhhLhC8Pe6c5FU=; 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=HIHNK/U9Q4Z5SXM8LscRVCINorBRcSU/fZhr6oeIu0lhR5dR1zw4/wP/8XZ3PvuVy9Kt74 Rjj3UAfpquo2+4xsDwKM7bHRsnFkkP9RLvxX0C+ntLfkoSDms3dRsXE9DxebEcFZsbK/sD 4TI/v+TPsR7UXtCz9513frmVnkDf40I=; 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 ; Thu, 15 Nov 2018 16:15:41 +0000 To: Michael Slusarz , extra@ietf.org References: <5BE4DB10.6090003@aol.com> <+zYCDTO4ZdsjSWin88IbqbIxTnobzOcvIPeIiYbAjBA=.sha-256@antelope.email> <776977791.12860.1542298378436@appsuite.open-xchange.com> From: Alexey Melnikov Message-ID: <1496a607-4bf1-3e37-af9a-6e7ede6a4923@isode.com> Date: Thu, 15 Nov 2018 16:15:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <776977791.12860.1542298378436@appsuite.open-xchange.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] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2018 16:15:44 -0000 Hi Michael, On 15/11/2018 16:12, Michael Slusarz wrote: >> On November 15, 2018 at 6:52 AM Arnt Gulbrandsen wrote: >> >> Move had 10-15 implementations soon after being published as RFC, and >> judging by my inbox, people did not have problems implementing it. And: >> it was regularly requested before that time. >> >> So... what are the >> criteria for inclusion, and how can something like move not pass the >> test? > Playing devil's advocate... what were the reason(s) this wasn't part of previous specs? The short answer is a) Mark disliked MOVE and b) MOVE spec wasn't written yet. > Was it simply due to the belief that we already have the necessary plumbing to do this (COPY/STORE/EXPUNGE), so MOVE was nothing more than a "shortcut", and shortcuts should be left out lest the base spec get too bloated? > > (MOVE atomicity guarantees trump this logic, in my opinion. Seems many others share this view.) From nobody Thu Nov 15 13:41: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 D76C1130DEC for ; Thu, 15 Nov 2018 13:41:51 -0800 (PST) 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 lZDnjgx3oB1L for ; Thu, 15 Nov 2018 13:41:49 -0800 (PST) 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 263CC12870E for ; Thu, 15 Nov 2018 13:41:48 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 4F507C001B; Thu, 15 Nov 2018 21:42:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1542318169; bh=aPb5ssXkf3BPpuwIH1iECEAV1OeVFhB0mDrkkYPMZKU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FP82k7fDOB/Mydsp2hhFuT1XYR8iP6LKZUGE9tfEfBHI8ghxOUOzudw3KtZtlGdlD Gjg/woIh2MgqXUwCpQ6lIX2vvNAZhJF+edmfxb9fWHLpAL7Nj13h1veTT0UJaMMgBa MT2+Nj48qUDxmktq2u2nFSFS2y/k0qqDKwUZyV4s= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1542318168-32426-32424/9/246; Thu, 15 Nov 2018 21:42:48 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Thu, 15 Nov 2018 22:41:45 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: <776977791.12860.1542298378436@appsuite.open-xchange.com> References: <5BE4DB10.6090003@aol.com> <+zYCDTO4ZdsjSWin88IbqbIxTnobzOcvIPeIiYbAjBA=.sha-256@antelope.email> <776977791.12860.1542298378436@appsuite.open-xchange.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] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2018 21:41:52 -0000 On Thursday 15 November 2018 17:12:58 CET, Michael Slusarz wrote: > Playing devil's advocate... what were the reason(s) this wasn't > part of previous specs? Mark hated the idea. I don't think anyone understood why. As I recall, there had been nine other substantially similar proposals before the one I wrote, most or all from actual implementers. Some weren't competently designed and written, but nine is an amazingly large number for this kind of thing. There was no lack of demand for MOVE, just Mark's resistance. Arnt From nobody Thu Nov 15 13:44: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 BD550130DF7 for ; Thu, 15 Nov 2018 13:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 zl59-fp0s6gT for ; Thu, 15 Nov 2018 13:44:03 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 26B8F130DEC for ; Thu, 15 Nov 2018 13:44:03 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id s22so3718156ioc.8 for ; Thu, 15 Nov 2018 13:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RqP/EXd0voE8kf/diQDOpZ5ctePZfznJIygO30eZj00=; b=mmALgt1KW1tXNoCvAm6bgOQrLFEka2HNdvmrmIMsqzv6zrloM2p96/a7rEBxKrEN86 oMX8XF9LE0r1165F4y+XMVVpOTvtpmxsIlwWvl3YBCOlwZ76rMf9vaJb5whfZJgh2ERg PcyTAHr1sUwwn9qWX+39VRxJLaadTD2Muy83n3qJIzjxR964/7Y2ZaWp3oYyItRbXU1z rDF/c6cnan2RbT/fZDqNZFfPD6rSXXgfZOZ8T3Ldz+DeI5YdupNTSelcM88X7O9v2kHm eKR5XoDrRJ67Q9t012U3Dbs6R/joZRMjGyQT81+/gCqEDL9cmbf+n3AWDdKJFYvP3v6I S2bg== 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=RqP/EXd0voE8kf/diQDOpZ5ctePZfznJIygO30eZj00=; b=BzfIRjVJ9pC1JuynE0643Smji1cHhXMofutlvck8tKpCb8yP+AJ6RoAmx3Pw9LOSn9 GWFufvCuAf2KxK4irtRP1QK7B9YRZOPVsNzhLdKvjnT17bLN1tYfdlzIGrEl0W4Z5G3K cz78p9HBbqg03UlGJr0voW5ZvpKCtJPaLv6/2TMC8nM9aQhB/n8H/FAqKDkjkNcL4RB3 FieIATEoDh5DC8FWw+1PVgp6fxtigYfrlJcW9ZrnYhnTO0fY0DPAUdyQpT9CjYgEQhyf c8Fbv7JJRseQKAlpwhSDBc7h0X50RuGfl2opqnI2Q/dnJgIN7KsYOqPoCzhX8fEZpRZU J7hQ== X-Gm-Message-State: AA+aEWYBTpKLibao3G8emGLM5sQYjqcUX7QsNnVeq2V1pF/PwV6CftFn 5J9iesbdAi6cAzcsWsRd1x0hqTh8XXlnz3voPOXq5b3VALQ= X-Google-Smtp-Source: AJdET5cKIiDnBvfrim9dHx/C+SH5crJKEqORkS5wBDqKAeDAbO9fHWMLuKqfvHmZmR5edfxna5ZW5hLE0adFyIwjj3Q= X-Received: by 2002:a5e:8217:: with SMTP id l23-v6mr6599911iom.232.1542318242187; Thu, 15 Nov 2018 13:44:02 -0800 (PST) MIME-Version: 1.0 References: <5BE4DB10.6090003@aol.com> <+zYCDTO4ZdsjSWin88IbqbIxTnobzOcvIPeIiYbAjBA=.sha-256@antelope.email> <776977791.12860.1542298378436@appsuite.open-xchange.com> In-Reply-To: From: Rob Siemborski Date: Thu, 15 Nov 2018 13:43:47 -0800 Message-ID: To: Arnt Gulbrandsen Cc: extra@ietf.org Content-Type: multipart/alternative; boundary="000000000000f55f6e057abaf2b7" Archived-At: Subject: Re: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2018 21:44:05 -0000 --000000000000f55f6e057abaf2b7 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 15, 2018 at 1:41 PM Arnt Gulbrandsen wrote: > On Thursday 15 November 2018 17:12:58 CET, Michael Slusarz wrote: > > Playing devil's advocate... what were the reason(s) this wasn't > > part of previous specs? > > Mark hated the idea. I don't think anyone understood why. > > As I recall, there had been nine other substantially similar proposals > before the one I wrote, most or all from actual implementers. Some weren't > competently designed and written, but nine is an amazingly large number > for > this kind of thing. There was no lack of demand for MOVE, just Mark's > resistance. > IIRC, Mark's resistance came from the "its a shortcut" idea that Michael mentioned. -Rob --000000000000f55f6e057abaf2b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Nov 15, 2018 at 1:41 PM Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
On Thursday 15 November 2018 17:12:58 CET, Michael Slu= sarz wrote:
> Playing devil's advocate... what were the reason(s) this wasn'= t
> part of previous specs?

Mark hated the idea. I don't think anyone understood why.

As I recall, there had been nine other substantially similar proposals
before the one I wrote, most or all from actual implementers. Some weren= 9;t
competently designed and written, but nine is an amazingly large number for=
this kind of thing. There was no lack of demand for MOVE, just Mark's <= br> resistance.

IIRC, Mark's resistance= came from the "its a shortcut" idea that Michael mentioned.

-Rob
--000000000000f55f6e057abaf2b7-- From nobody Thu Nov 15 14:12: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 BA421130E55 for ; Thu, 15 Nov 2018 14:12:54 -0800 (PST) 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 RhLbXhlg6bs1 for ; Thu, 15 Nov 2018 14:12:53 -0800 (PST) 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 02A57130E19 for ; Thu, 15 Nov 2018 14:12:52 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 616A6C001B; Thu, 15 Nov 2018 22:13:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1542320034; bh=M2ooOi9FUCQRrFwf5QHcrJJdUtPwT4aZvp3YyiWpLNM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mlj2cGzACWwwhdz7A8nCLOO2Ut4ynWGFwe7L9gUL53YVoHfH3t5sAug+15XSZEA+d UDHsu4hs3fQ9L+Od0Oo92FQfwaKV+cTGk3fOaG43tB05/kqw1NUDlHA65BlCsJq0KC MO5VhoPpCqkrut7PwG0RJXcb4rXFNNRaq/kqLJ5Y= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1542320033-32426-32424/9/247; Thu, 15 Nov 2018 22:13:53 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Thu, 15 Nov 2018 23:12:50 +0100 Mime-Version: 1.0 Message-Id: <0cd69746-bcbd-4cea-8500-8d485eef33ea@gulbrandsen.priv.no> In-Reply-To: References: <5BE4DB10.6090003@aol.com> <+zYCDTO4ZdsjSWin88IbqbIxTnobzOcvIPeIiYbAjBA=.sha-256@antelope.email> <776977791.12860.1542298378436@appsuite.open-xchange.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] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2018 22:12:55 -0000 On Thursday 15 November 2018 22:43:47 CET, Rob Siemborski wrote: > IIRC, Mark's resistance came from the "its a shortcut" idea > that Michael mentioned. One of the people who proposed a MOVE argued that the command wasn't a shortcut in case of... at least three formats that were in use at the time. MH, djb's format and one more. I don't remember the details. But I do remember that Mark ignored that, and that I assumed that the shortcut argument was just a superficial rhetorical device, not a deeply held conviction. I found his position very puzzling. Arnt From nobody Fri Nov 16 10:26: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 C7D761292AD for ; Fri, 16 Nov 2018 10:26:24 -0800 (PST) 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 HcJApjvyca3r for ; Fri, 16 Nov 2018 10:26:22 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 90CC3126BED for ; Fri, 16 Nov 2018 10:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1542392781; d=isode.com; s=june2016; i=@isode.com; bh=mtEmjBcuqZNZ0GivJMo9r6CjHFJNkk4jNyJFfcq6t8w=; 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=AMbbkFrbjYTFANzOKhpa4lub17ecuKnGWxxkJWw84GpoHguLDzt0onKDbTmXAq8PnSuP3L 5BPfBbpO1wBsUG4f85s48w5QIyMxQbZPB/AjfRQpvFtcTiqQgPNdI2OMKKkbbQkNImxvr8 JPhIAkWukVVnLGLAs2q5s+ZMjyeOz/8=; 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, 16 Nov 2018 18:26:21 +0000 To: Ken Murchison , extra References: <2a2f0f33-b056-1a04-aa11-8b8d0a448a4c@isode.com> From: Alexey Melnikov Message-ID: Date: Fri, 16 Nov 2018 18:25:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-sieve-fcc-06.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2018 18:26:25 -0000 Hi Ken, On 09/11/2018 16:54, Ken Murchison wrote: > > On 10/16/18 12:35 PM, Alexey Melnikov wrote: >> Hi, >> >> The document is generally fine and contains enough details to=20 >> implement, but I found a few minor issues: >> >> >> 3.=C2=A0 Tagged Argument ":fcc" >> >> =C2=A0=C2=A0 For convenience, the "FCC" syntax element is defined here us= ing ABNF >> =C2=A0=C2=A0 [RFC5234] so that it can be augmented by other extensions. >> >> Actually, you are not using ABNF, you are using Sieve syntax. >> >> =C2=A0=C2=A0 FCC =3D ":fcc" > > Hmm.=C2=A0 I'd like to use a syntax which can be extended to include=20 > compatible fileinto arguments as part of FCC (related to your point=20 > below about use of =3D/ I think you either need to change the comment that starts with "For=20 convenience" to reference Sieve RFC syntax or you change FCC to be=20 proper ABNF. I think doing the former would be easier. > >> >> Later in the same section: >> >> =C2=A0=C2=A0 If the specified mailbox doesn't exist, the >> =C2=A0=C2=A0 implementation MAY treat it as an error, create the mailbox,= or file >> =C2=A0=C2=A0 the message into an implementation-defined mailbox. >> >> Allowing for either an error or filing into different mailboxes is going >> to make scripts non portable, considering that there is no way to test >> in a Sieve script which exact behaviour is supported. >> >> Also, why is it Ok to have all these different choices, which will=20 >> potentially >> >> confuse users? I would like to either have a way to test for=20 >> different behaviour >> >> or have some explanation in the document why all of the choices are=20 >> acceptable. > > I think some of this text was borrowed from special-use.=C2=A0 Would be be= =20 > acceptable to do what fileinto does, which is if the target mailbox=20 > doesn't exist, then the message ends up in INBOX?=C2=A0 I'm also fine=20 > treating it as an error. That would be fine with me. >> In 3.1: >> >> =C2=A0=C2=A0 o=C2=A0 Subject: The Subject header field is OPTIONAL and MA= Y be generated >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as follows: The subject is set to the char= acters "Fcc: " followed >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by the subject of the message being proces= sed by the Sieve >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interpreter. >> >> Please make it clear that subject encodings used by RFC 2231 are Ok=20 >> to be used, >> so if an implementation does prefix matching, this is done after=20 >> decoding. >> >> In 3.2: >> >> =C2=A0=C2=A0 Vacation auto-reply messages are MIME-compliant and MAY >> >> This is not an implementation choice and is not a compliance statement, >> so use of RFC 2119 MAY is not appropriate here. So please use either >> "may" or "can" here. > I will use "can". > >> >> There is similar text in Section 3.3. >> >> =C2=A0=C2=A0 be filed into >> =C2=A0=C2=A0 the target mailbox without modification. >> >> In 3.3.1: >> >> =C2=A0=C2=A0 Example: >> >> =C2=A0=C2=A0 require ["enotify", "fcc"]; >> >> =C2=A0=C2=A0 if notify_method_capability "xmpp:" "Fcc" "yes" { >> >> >> Is "fcc" case insensitive? (I didn't check). > > The default comparator used by notify_method_capability is=20 > i;acsii-casemap.=C2=A0 In fact, the example in RFC5435 is quite similar. Ok. Maybe it is worth pointing this out. > >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 notify :fcc "INBOX.Sent" >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 :message "You got mail" >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "xmpp:ken@example.com?message;subject=3DSIEVE"; >> =C2=A0=C2=A0 } else { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 notify :fcc "INBOX.Sent" >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 :message "You got mail!" >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "mailto:ken@example.com"; >> =C2=A0=C2=A0 } >> >> In 3.5: >> >> 3.5.=C2=A0 Interaction with Fileinto Extensions >> >> =C2=A0=C2=A0 The "fcc" extension can be used with some tagged arguments d= efined in >> =C2=A0=C2=A0 extensions to the "fileinto" action. >> >> This got me initially very confused and I was confused till section=20 >> 3.5.4, >> until I saw the example. I thought you were defining use of :fcc with=20 >> "fileinto", >> but you are actually allowing use of some "fileinto" tagged arguments=20 >> together >> with ":fcc" in other actions. So maybe rephrase this like this: >> >> =C2=A0=C2=A0 This document defines how some tagged arguments defined in >> =C2=A0=C2=A0 extensions to the "fileinto" action can be used together wit= h ":fcc" >> =C2=A0=C2=A0 used in other actions. >> >> Or something like that. > > Agreed.=C2=A0 Your text is clearer. > > >> >> =C2=A0=C2=A0 The sections below describe its >> =C2=A0=C2=A0 interaction with currently defined extensions.=C2=A0 Tagged = arguments in >> =C2=A0=C2=A0 future extensions to the "fileinto" command should describe = their >> =C2=A0=C2=A0 interaction with ":fcc", if any. >> >> In 3.5.1: >> >> =C2=A0=C2=A0 FCC =3D/ [":flags" ] >> >> I think use of "=3D/" is wrong here. You are not defining another=20 >> alternative to >> ":fcc", you are allowing some tags to be used together with it. >> >> I suggest you either define a separate production from FCC or you=20 >> just use >> Sieve syntax: > > See above.=C2=A0 I'm open to suggestions on how to handle the grammar. I would something like this instead: FCC_EXTRA =3D [":flags" ] And explain that FCC_EXTRA can be used any time FCC is included. It is probably ok to use "=3D/" for FCC_EXTRA, but you might want to=20 define this in prose. Something along the lines of using =3D/ similar to=20 the way that ABNF defines it, although you are not using exact ABNF syntax. > >> >> =C2=A0=C2=A0 ":flags" >> >> =C2=A0and describe the rest in text. >> >> (Similar issue in 3.5.2 and 3.5.3) >> >> Best Regards, >> >> Alexey=20 From nobody Tue Nov 20 13:12:21 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 6BCFA130DD0 for ; Tue, 20 Nov 2018 13:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 Pz_LoPd0PxZX for ; Tue, 20 Nov 2018 13:12:17 -0800 (PST) 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 4B96F128D0C for ; Tue, 20 Nov 2018 13:12:17 -0800 (PST) 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 wAKL8aRN086328; Tue, 20 Nov 2018 21:12:14 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=/JfMQDpF0EHbWvwvC7S4sS71cEH2pVg0v0hkxJwZgSs=; b=upf6bRwS8bU09waiDw6zqNaWVDGFpsCgEyT4+hbupxO4h6sraqnRD1CfLLtF5liig1Iu tin2afhYvElEuaHJ6XioySRHpiGLBA8zHkZFjUm1q4BXd2AT4Z1jyldNVB43+kl0m+Ea mGqQncWjgqHjfy6ZVKTl10/nujO78UfUSu7NqzxtxRLrpYg1iHsmFLSEgkq+m+nBL0kM OMx0OJjyaHx1TJa+qIJ87OtMsJek/x3g3o2rysKgc/HRfr1+gxzIsXA62nc61S5E2aWn laSs3Xz45/1uc/+2Q0HvMyJnOpJmje6AtCO4cPiwekPdmMzeUaXpLMINV9ZHsRRexB7s 2Q== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2ntaxq66th-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 21:12:14 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wAKLC8A8010801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 21:12:08 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wAKLC8b4000662; Tue, 20 Nov 2018 21:12:08 GMT Received: from [10.154.161.204] (/10.154.161.204) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2018 13:12:08 -0800 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org Date: Tue, 20 Nov 2018 13:12:07 -0800 X-Mailer: MailMate (1.12.1r5552) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_BE34D393-E993-4E92-8C74-63821041AC64_=" Embedded-HTML: [{"HTML":[1593, 1190], "plain":[240, 360], "uuid":"546B200F-9245-4350-B34D-EC9542A8D3E6"}] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9083 signatures=668683 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-1810050000 definitions=main-1811200185 Archived-At: Subject: Re: [Extra] imap4rev2: RFC5182 SEARCHRES X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 21:12:19 -0000 --=_MailMate_BE34D393-E993-4E92-8C74-63821041AC64_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable We've implemented this extension and it's not difficult to implement on = the server side so I'm in favor of including this. I'd be interested in = a client implementer's perspective. - Chris On 8 Nov 2018, at 3:27, Bron Gondwana wrote: > This is one of the open issues from imap4rev2 - which extensions = > should be part of the mandatory baseline. > > In favour - it's useful to compose actions. > > Against - it's not widely implemented or used. > > Arguments for and against in response to this please. > > Cheers, > > 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_mai= lman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3D6krI1FgmWhZv2Lq= blI2h4VuwuAN9JX254RcYg-ZMIGE&s=3DtOzMc_3golA1EPLg7hmfq0_-klVUFWcd4k9fF17i= wwU&e=3D --=_MailMate_BE34D393-E993-4E92-8C74-63821041AC64_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

We've implemented this exten= sion and it's not difficult to implement on the server side so I'= m in favor of including this. I'd be interested in a client implement= er's perspective.

- Chris

On 8 Nov 2018, at 3:27, Bron Gondwana wrote:

This is one of the open issues from ima= p4rev2 - which extensions should be part of the mandatory baseline.

In favour - it's useful to compose actions.

Against = - it's not widely implemented or used.

Arguments for and ag= ainst in response to this please.

Cheers,

Bron.

-= -
  Bron Gondwana, CEO, FastMail P= ty Ltd
  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=3D6krI1FgmWhZv2LqblI2h4VuwuAN9JX2= 54RcYg-ZMIGE&s=3DtOzMc_3golA1EPLg7hmfq0_-klVUFWcd4k9fF17iwwU&e=3D=

--=_MailMate_BE34D393-E993-4E92-8C74-63821041AC64_=-- From nobody Tue Nov 20 13:19:46 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 56441126DBF for ; Tue, 20 Nov 2018 13:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 cQlXOM_4-Mtq for ; Tue, 20 Nov 2018 13:19:44 -0800 (PST) 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 CB0E2124D68 for ; Tue, 20 Nov 2018 13:19:43 -0800 (PST) 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 wAKLJH8l128278; Tue, 20 Nov 2018 21:19:39 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=ohLiPjFvNp0yR1ngW3RjmJNMdt15AuPHk6ChvzIy6dI=; b=VC+5yIxFLvOXGfxIw0j89fosIOvBTZlM3u9DjKD1OFdJxXhUL3L1vhtOJ7gxb0lQwql/ RK4TLPaoGnWvmNxm1MtsQPH/HdZCqmRK/hWGmFgYAxq7Zx591lqPeR6L/Tik+4RycTrr ffkhdcvSHnvD+Kq0RsGgTJNrW+AWvD0BxX+g+3xR0uoXQJ91VQc0BDLj/wNQzZ5t7HHn X4u0E8O1zhX2ZfhLdozEnbbjstxVMCaRbxGkrUo/W+UOIGbg6Pk1KJLe2BPICsvmm342 rRNHN2fN2y7Feg+64qk04t4rMvZYez09OPtWXYH/zPH9WWBPW+TJn3fTDble02VskCsJ tw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2ntadtx94u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 21:19:39 +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 wAKLJcnB024763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 21:19:39 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wAKLJcL4001033; Tue, 20 Nov 2018 21:19:38 GMT Received: from [10.154.161.204] (/10.154.161.204) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2018 13:19:38 -0800 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org Date: Tue, 20 Nov 2018 13:19:36 -0800 X-Mailer: MailMate (1.12.1r5552) Message-ID: <50B39537-6D3D-47CF-B1FC-1B592C66F69B@oracle.com> In-Reply-To: <8fcce54e-4d33-4f2b-92b2-0a5ec8bfec5b@sloti7d1t02> References: <8fcce54e-4d33-4f2b-92b2-0a5ec8bfec5b@sloti7d1t02> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9083 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=831 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811200186 Archived-At: Subject: Re: [Extra] imap4rev2: STATUS DELETED X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 21:19:45 -0000 On 8 Nov 2018, at 3:30, Bron Gondwana wrote: > This is one of the open issues from imap4rev2 - which extensions > should be part of the mandatory baseline. > > This was a discussion about a way to easily see if there are messages > with \Deleted in a mailbox, maybe to see how much quota can be freed > up. General agreement in the room was "IMAP4rev2 is for a baseline of > existing standards, maybe this should be a new document, but not part > of IMAP4rev2" > > Discussion on whether we think the general concept is useful, and > whether it's so useful we should make it part of IMAP4rev2 in response > to this please. We've implemented a custom 'status counts' extension that provides counts based on each configured message type including: * total, seen, deleted, seen-deleted the intention of this extension was to help support voicemail and similar unified messaging features. We implemented quota & quota-usage by message type via a quota root naming convention. I don't think we should delay IMAP4rev2 to include something like this, but I can see it being helpful for some use cases. - Chris From nobody Tue Nov 20 13:41: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 5EAFC12F1AB for ; Tue, 20 Nov 2018 13:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 3M_LM5QeBmmS for ; Tue, 20 Nov 2018 13:41:52 -0800 (PST) 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 8ADF8128BCC for ; Tue, 20 Nov 2018 13:41:52 -0800 (PST) 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 wAKLdZrm143335; Tue, 20 Nov 2018 21:41: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=Bf73MZZGWGmlOtEFxpXfRp7/POD/IQMz2aHxzbiKkp8=; b=fn2YFQJSvEm6vYCqpfcvTqDmK725TNsINpgfbn84DSeW0CRPzEHuOQDc2eb1VZNLJ6iS 8RHRtE6tqDWa+qdfKVWpyFd/26NEdrb2b+RbVzsV62gCBVgaQSaQX3QSNQObNWxpER6S XoGYIihiXahuA7BPQUy4EVD8lhHrCsmFADssxVFcZeDWQ/k52Do8PVfKUjpJ+88P+qyK HYHYj4xhBFz6wx78bjlrIf+dsW/DGiknAmGdEYZnD9J4oVG3XpA0I6lm+A9+TomYXx9z /imlJlc2GbaJ5hBel+fse6Y40LMzj8yKcvXed7stQBR4p0ITLSRAin2XpKw0vNHYRB65 Qg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2ntadtxbqn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 21:41:48 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wAKLfgTs007046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 21:41:42 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAKLfflG011923; Tue, 20 Nov 2018 21:41:42 GMT Received: from [192.168.15.59] (/47.41.1.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2018 13:41:41 -0800 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org Date: Tue, 20 Nov 2018 13:41:40 -0800 X-Mailer: MailMate (1.12.1r5552) Message-ID: <7C112497-CA9C-4926-B3B1-4E3440CE9365@oracle.com> In-Reply-To: <6f804b07-35bd-4ca3-ad84-bf69daeaa6e9@sloti7d1t02> References: <6f804b07-35bd-4ca3-ad84-bf69daeaa6e9@sloti7d1t02> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9083 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=796 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811200189 Archived-At: Subject: Re: [Extra] imap4rev2: RFC8474 OBJECTID X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 21:41:54 -0000 We've implemented an extension equivalent to MAILBOXID already; no objections to that part. As THREADID is optional, no objections to that. We've not implemented EMAILID yet. I believe FETCH of EMAILID is reasonably straightforward, but SEARCH by EMAILID may add significant complexity, particularly with respect to search index version migration issues. As a result of the latter issue, it will be difficult for us to find cycles to implement and test OBJECTID, so I oppose mandatory inclusion of OBJECTID in IMAP4rev2. - Chris On 8 Nov 2018, at 3:32, Bron Gondwana wrote: > This is one of the open issues from imap4rev2 - which extensions > should be part of the mandatory baseline. > > In favour - it's very useful for client efficiency, and maps to very > popular Gmail extensions. > > Against - it's very new, and not widely implemented yet. > > Arguments for and against in response to this please. From nobody Tue Nov 20 13: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 C111C130DD3 for ; Tue, 20 Nov 2018 13:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 kgEOVePAbc4f for ; Tue, 20 Nov 2018 13:44:07 -0800 (PST) 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 4BCDE130DD4 for ; Tue, 20 Nov 2018 13:44:07 -0800 (PST) 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 wAKLdTNO103400; Tue, 20 Nov 2018 21:44: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=qJLdOkc5YfUsozJYx17KyTTjWwQeAYi1J8muyPILn48=; b=cBu4nF875XJQv6WPHlNRnD+Gfq0DQzV+NBgqRJN17FXsYJLZkLPoQEVh2lvQERTZ5kWB GLIPWT+DrbuIqBKykLAkH7uVY50MVcfM0Qi5wUQHUR2lhk6orrq81c4XB2jzyjaKmUGp T1Qd/8MmoVtIZyuS69FY4NyTrbi3sfhzJvqXINHdE/w2vMpYurD+HV8NCy/6cX0Pu8m3 eO2/rJGGdcZzAC76K4Oqem99LqfLH9O2UJYr88ILMuseERGcSPFuZ/wwaBKmvvBUoTYy J2EtCFfY1R3A3bqe0CzjK+1yB8O929670MfCkOql/rFILtCqNm5SMzjSy/bzXpllzBpc Tg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2ntbmqp86r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 21:44:03 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wAKLhwXh013246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 21:43:58 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wAKLhwvo021139; Tue, 20 Nov 2018 21:43:58 GMT Received: from [192.168.15.59] (/47.41.1.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2018 13:43:57 -0800 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org Date: Tue, 20 Nov 2018 13:43:56 -0800 X-Mailer: MailMate (1.12.1r5552) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9083 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=518 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811200189 Archived-At: Subject: Re: [Extra] imap4rev2: draft-ietf-extra-imap-replace X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 21:44:09 -0000 On 8 Nov 2018, at 3:44, Bron Gondwana wrote: > This is one of the open issues from imap4rev2 - which extensions > should be part of the mandatory baseline. > > This one isn't even standard yet, but it's a nice pair with MOVE as a > way to avoid running into intermittent issues near QUOTA when you're > doing things like editing Drafts, and it's similarly easy to implement > on top of existing actions. > > Arguments for and against in response to this please. I'm neutral on inclusion of this extension. We've not implemented it yet, but it should be straightforward to implement. If enough client authors are interested in making use of it, I'd consider implementing it. - Chris From nobody Tue Nov 20 14:00: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 8DAFD130E16 for ; Tue, 20 Nov 2018 14:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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=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 o0kYNpQau63y for ; Tue, 20 Nov 2018 14:00:29 -0800 (PST) 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 CAFE5130DEB for ; Tue, 20 Nov 2018 14:00:29 -0800 (PST) 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 wAKLreNc153563; Tue, 20 Nov 2018 22:00:11 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=YP7VNDpJfiSPJx5FFqBclB5sUnNBYOCVIawuEIz31Dc=; b=JOdj4vijRxcx2d5C8ZiIx64qBS925A02A7GjtD/w/LfENxQcnnUjN98bjN44X+94b2gR 2nJSbDZs/IJgz+J9nFTNf4eehcuhBj8xI9GPfm850GErRphGUuNMnXKdITVT3UoFTmQJ PMdUUhoC231Ci5E9+AjiXavkKLMxE3EN4tN/hH/9aTs92BMhmcUmz+RirkDsuiYnwBqA rPrP8OxHOtnoLidkp1KYea0U/kNiqI8+DlQBZM2TbTqjihnZrWdSiiUb1aqdoaVRQoO9 TIwGH/Y/XNkr4pAoMcWu57eUqn+U9fNqirfLGaKgt30V4g0LLofEcID8W0LXsAsZkp5d 5w== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2ntadtxdrx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 22:00:10 +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 wAKM09Bh005082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 22:00:10 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wAKM09kX031064; Tue, 20 Nov 2018 22:00:09 GMT Received: from [192.168.15.59] (/47.41.1.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2018 14:00:09 -0800 From: "Chris Newman" To: extra@ietf.org Cc: "Bron Gondwana" Date: Tue, 20 Nov 2018 14:00:07 -0800 X-Mailer: MailMate (1.12.1r5552) Message-ID: <74E8A9EC-3569-443B-B6D9-CD76F0D3FA34@oracle.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9083 signatures=668683 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-1810050000 definitions=main-1811200192 Archived-At: Subject: Re: [Extra] imap4rev2: disallow "RENAME INBOX" X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 22:00:33 -0000 On 9 Nov 2018, at 11:25, Brandon Long wrote: > The things we didn't implement were things that were much harder = > (substring > searching is probably the main one) A very good point. For IMAP4rev2, can we loosen the specified = requirements for searching? At a minimum, I'd like to see word-based = searching for message content to be considered valid by the standard = (that is, a search for "ood" won't necessarily match a message = containing the word "good"). - Chris > yes, we didn't reset the UID counter, I guess we could do that and the > uidvalidity, but the initial impl didn't have a good way to change the > underlying uidvalidity, so easier to leave the uid space the same. > > Brandon > > On Thu, Nov 8, 2018 at 6:54 AM Bron Gondwana = > wrote: > >> I'm tempted to see what Gmail does too. >> >> . OK brongondwana@gmail.com authenticated (Success) >> . rename INBOX oldinbox >> . OK Success >> >> Well, what do you know. They implemented it! >> >> ha... >> >> . select oldinbox >> . move 1:* INBOX >> >> ... >> >> . OK [COPYUID 2 1:15214 16312:31525] (Success) >> >> So it looks like it didn't reset the UID counter on the INBOX. I = >> didn't >> get the UIDVALIDITY of the INBOX at the start to compare. >> >> Bron. >> >> On Fri, Nov 9, 2018, at 01:02, Timo Sirainen wrote: >> >> On 8 Nov 2018, at 13.37, Bron Gondwana = >> wrote: >> >> >> This is one of the open issues from imap4rev2 - which extensions = >> should be >> part of the mandatory baseline. >> >> This one came from me. I dislike the weirdness of "RENAME INBOX >> Archive-foo" because of its special behaviour regarding sub = >> mailboxes, and >> the auto-recreation of the source mailbox, and all that jazz. >> >> Argument in favour of keeping it - it's easier for clients, which is = >> part >> of the point of IMAP4rev2 - servers have already suffered through = >> this the >> first time, and will need to keep IMAP4rev1 support for a while = >> anyway >> probably. >> >> Arguments for and against in response to this please. Also arguments >> about the suggested middleground saying that clients "SHOULD NOT" use = >> it, >> or something like that - with the flip side that servers MAY reject = >> rename >> of INBOX. >> >> We're particularly interested in "I use this, and want to keep it" = >> from >> either servers that see their clients doing it, client authors, or = >> even >> users! >> >> Dovecot has always been rejecting this when used with Maildir format >> (other formats allow it): >> >> a rename inbox plop >> a NO [CANNOT] Renaming INBOX isn't supported (0.001 + 0.000 secs). >> >> I've never heard anyone complain about it. >> >> I've a feeling Courier is rejecting it as well, but can't check now = >> easily. >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_extra&d=3DDwIBaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DoP5PJjpDZQDR4d= twrheZ_EnhR-XlvT9UB5wDPKQ5Jko&s=3DDh9CwBxeKEF6SBLq7LW_42yNKCwMt7jRk44kDdI= x7J0&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_ma= ilman_listinfo_extra&d=3DDwIBaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DoP5PJjpDZQDR4d= twrheZ_EnhR-XlvT9UB5wDPKQ5Jko&s=3DDh9CwBxeKEF6SBLq7LW_42yNKCwMt7jRk44kDdI= x7J0&e=3D >> > _______________________________________________ > 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=3DoP5PJjpDZQDR4dt= wrheZ_EnhR-XlvT9UB5wDPKQ5Jko&s=3DDh9CwBxeKEF6SBLq7LW_42yNKCwMt7jRk44kDdIx= 7J0&e=3D From nobody Tue Nov 20 14:16: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 E9D96130E73 for ; Tue, 20 Nov 2018 14:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 VD9C1WlHAxsO for ; Tue, 20 Nov 2018 14:15:57 -0800 (PST) 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 82B38130E6A for ; Tue, 20 Nov 2018 14:15:57 -0800 (PST) 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 wAKME8WW128457; Tue, 20 Nov 2018 22:15:53 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=zr3skekHCSShLTtNllpSIjTQU2rA+BSIoB22NoLtQB8=; b=W9wbCBqEEPotMk8s73km/siQbyoJZ3yAvB2a0NgO1Nz5dz7/3eyL/nAFIO0HnpSoGV6t b1upa9OLS33wG/akW28JuQ8PCScmFl6m0n7fMzO5HUhtpUUYHZ+q6Nha6y1nhL3Cd4ek 66B12+ggT9X7SlgKa7mkiBZD189a6uJpMUbx4wLxrmNndvHscIwcY1dmwNBhzv85IZO7 hj9d2qtjJVbEd8hd/KxHyW4Fv/Y4LR3UrzPZb8RNthH6bKyfGZon226bP2S6Ygat1mgP p/r+ESyFjarzXbF+NIyJeG048IagTOM5iHIL03X/9SIEqLugM1E03evaYc8RDyl4DcQN sA== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2ntbmqpbj0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 22:15:53 +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 wAKMFlcM005321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 22:15:47 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAKMFkLG031748; Tue, 20 Nov 2018 22:15:46 GMT Received: from [192.168.15.59] (/47.41.1.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2018 14:15:46 -0800 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org, "Alexey Melnikov" Date: Tue, 20 Nov 2018 14:15:44 -0800 X-Mailer: MailMate (1.12.1r5552) Message-ID: In-Reply-To: <7a10e2be-5192-4955-8bd8-aa81a18a240b@sloti7d1t02> References: <7a10e2be-5192-4955-8bd8-aa81a18a240b@sloti7d1t02> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9083 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=475 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811200195 Archived-At: Subject: Re: [Extra] imap4rev2: RFC3516 BINARY X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 22:15:59 -0000 I have no objections to adding BINARY fetch of leaf MIME parts, although it would be helpful to hear that client vendors found that useful prior to adoption. I oppose adding BINARY fetch of non-leaf parts to IMAP4rev2 -- that gets complicated quickly. Having IMAP4rev2 require support for binary-content-transfer-encoding on APPEND would also be problematic as it creates several new cases with potential interoperability problems. - Chris On 8 Nov 2018, at 3:34, Bron Gondwana wrote: > This is one of the open issues from imap4rev2 - which extensions > should be part of the mandatory baseline. > > This one might need some clarification from Alexey - I'm not sure why > it's not trivially obviously a good thing to include. There was some > stuff about "ability to fetch the decoded size" discussed, but I > didn't capture good notes. > > Arguments for and against, or additional discussion, in response to > this please. From nobody Tue Nov 20 15:28: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 905AF126CC7 for ; Tue, 20 Nov 2018 15:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Os5asER2O_Ay for ; Tue, 20 Nov 2018 15:28:10 -0800 (PST) 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 6B77312007C for ; Tue, 20 Nov 2018 15:28:10 -0800 (PST) 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 wAKNPCUh181958 for ; Tue, 20 Nov 2018 23:28:09 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=aOkWQ88QgKZSHrloc5r88cCvqyp3I29Q44ollk8p3Gs=; b=qe1lPpBUR7fhsYMj+4uCb4loqNhb0lii18Lc2Bu0XqUuWFl2bYOgViiFZ2d+oB1un16l lD1bdUqr4evuP5zftYqlbkRPmf9mhomDPjIKPld2AAQqlvTIrSWHJ7zD54C8SCzGWYN6 k/ZP0p46HsDxc//hXy7kjeYwkqu6Vz8r0tzO+AguPuAWKzoD9xzCpRwOr8EBHLD/ONjE zIiONyGYUjFJSLcRQzz3iyUmeQp4LVoiUjnl16cw0IUhWqbxqozjEhnbs5+MEb1+rxky SsXR89qkTVmGgM98IO2u7AMr1D39n58kkSMRFBMC9ohLZUWhYRStBVwAmNQLOvv9S5Tp +A== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2ntaxq6mnc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 20 Nov 2018 23:28:09 +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 wAKNS3Jj021293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 20 Nov 2018 23:28:03 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAKNS3IL002051 for ; Tue, 20 Nov 2018 23:28:03 GMT Received: from [192.168.15.59] (/47.41.1.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2018 15:28:03 -0800 From: "Chris Newman" To: extra@ietf.org Date: Tue, 20 Nov 2018 15:28:02 -0800 X-Mailer: MailMate (1.12.1r5552) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9083 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=517 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811200206 Archived-At: Subject: [Extra] IMAP RFC 6855 (IMAP EAI) implementation experience: input to IMAP4rev2 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 23:28:13 -0000 Sometimes the philosophy behind a standard and what happens when it encounters the real-world result in implementations that willfully ignore some aspects of the standard. Since I wrote the first draft of RFC 6855, any such differences between the spec and real life are mostly my fault. For better or worse, RFC 6530 took a very different approach from past IETF specifications when it comes to backwards compatibility. It choose not to introduce yet-another-ascii-encoding for email local parts and takes a "MUST bounce" position when a UTF-8 message encounters a 5321/5322-only system. From a standards-purist viewpoint, this preserves interoperability but is a deployment deterrent to the new format. However, from an implementer viewpoint, I believe this is mostly a non-starter. Although we documented downgrading options (RFC 6857,6858) these options end up having poor cost/benefit in the real world. Ned's implementation experience from RFC 6531 was that the real world just can't usefully work the way the specification describes. That experience informed my work implementing RFC 6855. My experience with RFC 6855 implementation is as follows: 1. Support to accept and validate UTF-8 in quoted-strings was straightforward to implement. I made the support unconditional as that was much simpler than adding ENABLE-conditional code branches that would require extra testing. 2. Support to append UTF-8 messages was medium complexity to implement because I decided to validate the header UTF-8 syntax and push any garbage-8-bit headers into the message body. I ended up just ignoring the <"UTF8" SP> protocol syntax when present and processing the message the same way regardless. 3. I choose not to implement downgrading or UTF-8-message hiding. If UTF-8 messages become common and legacy clients start choking on them, I might add a downgrading option, but I suspect it will be much easier for clients to just deal with UTF-8 where it wasn't previously allowed than to do anything useful with a downgraded UTF-8 email message or even fully implement RFC 6855 (which I suspect is far simpler for clients than for servers). 4. With my implementer hat on, I willfully ignored this requirement: The IMAP server MUST NOT send UTF-8 in quoted-strings to the client unless the client has indicated support for that syntax by using the "ENABLE UTF8=ACCEPT" command. It's interesting that my implementer hat and standards hat result in diametrically opposed positions on this issue, but so be it. If there's a message with UTF-8 headers in the message store, IMAP clients will see it uncorrupted regardless of whether the client can handle it. 5. The requirement to eliminate modified-UTF-7 in mailbox names was medium complexity due to some past implementation choices. I was comfortable with the cost/benefit of the effort. MUTF-7 is ugly; good riddance. This code has to be conditional based on use of the ENABLE command -- however, if the implementation sees a client-provided UTF-8 mailbox name, it treats that one name as if ENABLE had been set. It's only 7-bit mailboxes containing ampersand that have a behavior difference based on whether ENABLE was used. 6. The most difficult part of the project is supporting UTF-8 usernames throughout the server. IDN is actually the hardest part of this since it's necessary to support both A-labels and U-labels for the domain portion of a user name and treat them as synonyms. Luckily RFC 6855 does not mandate support for UTF-8 usernames so this doesn't impact the previous decision of whether to include RFC 6855 in IMAP4rev2. The U-label/A-label issue is also a problem for SMTP servers, milters, and Sieve. Based on 1-5, I believe the text in the current IMAP4rev2 draft is correct, appropriate, and implementable. Based on 6, we might want to consider some additional text with respect to UTF-8 usernames & passwords. - Chris From nobody Wed Nov 21 04:51: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 8828712D4EE for ; Wed, 21 Nov 2018 04:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vt8Ex3hDreGy for ; Wed, 21 Nov 2018 04:51:37 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA7B128CE4 for ; Wed, 21 Nov 2018 04:51:35 -0800 (PST) Received: from healthyao-PC (unknown [159.226.7.2]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJdq3SVPVbAhEGAA--.3852S2; Wed, 21 Nov 2018 20:51:30 +0800 (CST) Date: Wed, 21 Nov 2018 20:51:25 +0800 From: "Jiankang Yao" To: chris.newman , extra Reply-To: yaojk References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201811212051229361548@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart367707556202_=----" X-CM-TRANSID: AQAAf0BJdq3SVPVbAhEGAA--.3852S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKw13tFWfurWrWF43GFyfZwb_yoW3tFb_u3 ykJF1UW3WUtr45trs8tF1vqFna9w4kCa1fA3yxXrWSk34UZa1DGa9xt34a9F45Gw4YvFy3 XF9Fk3y7Ka47ujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbvAYjsxI4VWkKwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z2 80aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2x7xS 6r1j6r4UMc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCY02 Avz4vE14v_Xr1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAq x4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r 17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF 7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67 AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsG vfC2KfnxnUUI43ZEXa7IU5L_-JUUUUU== X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Extra] IMAP RFC 6855 (IMAP EAI) implementation experience: input to IMAP4rev2 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 12:51:40 -0000 This is a multi-part message in MIME format. ------=_001_NextPart367707556202_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCkZyb206IENocmlzIE5ld21hbg0KRGF0ZTogMjAxOC0xMS0yMSAwNzoyOA0KVG86IGV4dHJh DQpTdWJqZWN0OiBbRXh0cmFdIElNQVAgUkZDIDY4NTUgKElNQVAgRUFJKSBpbXBsZW1lbnRhdGlv biBleHBlcmllbmNlOiBpbnB1dCB0byBJTUFQNHJldjINCj4gTmVkJ3MgDQo+aW1wbGVtZW50YXRp b24gZXhwZXJpZW5jZSBmcm9tIFJGQyA2NTMxIHdhcyB0aGF0IHRoZSByZWFsIHdvcmxkIGp1c3Qg DQo+Y2FuJ3QgdXNlZnVsbHkgd29yayB0aGUgd2F5IHRoZSBzcGVjaWZpY2F0aW9uIGRlc2NyaWJl cy4gVGhhdCBleHBlcmllbmNlIA0KPmluZm9ybWVkIG15IHdvcmsgaW1wbGVtZW50aW5nIFJGQyA2 ODU1Lg0KPg0KDQpJQ0FOTiBVQVNHIEVBSSBXRyBpcyBwdXNoaW5nIHRoZSBkZXBsb3ltZW50IG9m IEVBSS4gSm9obiBMZXZpbmUgaGFzIHJ1biBhbiBhbmFseXNpcyBvZiB0aGUgRUFJIFJlYWRpbmVz cyBvZiB0aGUgSW50ZXJuZXShr3MgbWFpbCBzZXJ2ZXJzLg0KSGlzIERSQUZUIHJlcG9ydCBpcyBh dCBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9kLzE4Vy1kQXIxTmhlX2dWbEZLRFFa cXNxQjRiZjVOODZ3cnlFY0FMbnlVUFRjL2VkaXQjaGVhZGluZz1oLmRiYTdwMWthenhxYQ0KRnJv bSB0aGlzIHJlcG9ydCwgdGhlIGN1cnJlbnQgRUFJIGRlcGxveW1lbnQgIGlzIGFtYXppbmcuDQoN CllvdSBtYXkgYWxzbyBiZSBpbnRlcmVzdGVkIGluIHRoaXMgbGlzdCBkaXNjdXNzaW9uIGhlcmUg aHR0cHM6Ly9tbS5pY2Fubi5vcmcvbWFpbG1hbi9saXN0aW5mby91YS1lYWkgDQoNCg0KQmVzdCBS ZWdhcmRzDQpKaWFua2FuZyBZYW8= ------=_001_NextPart367707556202_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
Date: 2018-11-21 07:28
To: extra
Subject: [Extra] IMAP RFC 6855 (IMAP EAI) implementation=20 experience: input to IMAP4rev2
> Ned's 
>implementation experience from RFC 6531 = was that the real world just 
>can't usefully work the way the spe= cification describes. That experience 
>informed my work implementing RFC 6855.<= /DIV>
>
 
ICANN UASG EAI WG is pushing the deployment of EAI. John=20 Levine has run an analysis of the EAI Readiness of the Internet=A1=AF= s mail=20 servers.

His DRAFT report is at https://docs.google.com/document/d/18W-dAr1Nhe_gVlFKDQZqsq= B4bf5N86wryEcALnyUPTc/edit#heading=3Dh.dba7p1kazxqa

From this report, the current EAI deployment  is= =20 amazing.

 

You may also be interested in this list discussion he= re https://mm.icann.org= /mailman/listinfo/ua-eai=20

 

 

Best Regards

Jiankang Yao

 

------=_001_NextPart367707556202_=------ From nobody Wed Nov 21 10:16: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 D8450130F2B for ; Wed, 21 Nov 2018 10:16:42 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 0rbKr6GKR5Vg for ; Wed, 21 Nov 2018 10:16:40 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 E8C59130E7E for ; Wed, 21 Nov 2018 10:16:39 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 8D8D46A26B for ; Wed, 21 Nov 2018 19:16:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1542824197; bh=fXoBOFSiqQUoSEDPvLodmSiHXgTc19GW2VjLTGh/K9M=; h=Date:From:To:In-Reply-To:References:Subject:From; b=8hvx/Zwm4fBrkge02JbEaQiSa/RDyvC1lr5Wt+ORfzT41KqS1SWz55nIy/PsdbTm6 7a5l2j/0aRJCGPvzgCYD/XnHYgAP2kPDDx5D3LbAE4PNTdKjn+SuREBq8tCNOkkmNe uoSVytU14+OtKapaFOLk+JtNHzmI87FJw4WuZyDf3aGdqgf/242vZX+AcHhsKP/MFA 2JDlfgF+nh+j9IstW3CJSBBEQ/POZJ3wrztLDhdFFF1eKlmFIaSvQixR3vzifc9czM /f+JLEMF6cU3JPneeokIl8tC5xn+P13xyiyFvBNzN6ih2Pot0xRiWrQCzPKVGf+LtY /N9TDKgIXOGsA== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 8586E3C06FD for ; Wed, 21 Nov 2018 19:16:37 +0100 (CET) Date: Wed, 21 Nov 2018 11:16:37 -0700 (MST) From: Michael Slusarz To: extra@ietf.org Message-ID: <1309404114.9749.1542824197488@appsuite.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9748_793789840.1542824197478" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev20 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] imap4rev2: RFC5182 SEARCHRES X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 18:16:45 -0000 ------=_Part_9748_793789840.1542824197478 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [FYI: I'll be replying to all of Bron's imap4rev2 messages with the "official" Dovecot response. Don't worry - the feedback is from people much smarter than me - I'm mainly in charge of being the messenger!] SEARCHRES is already implemented by Dovecot (has been for awhile). No objection to including in imap4rev2. Only question - similar to Chris' - is what the usage is on the client side? SEARCHRES doesn't seem useful for non-pipelining clients, which is the way the vast majority of IMAP libraries are implemented, at least the ones I have looked at. e.g. code that programatically calls a search() function, then uses the response from search() and does a fetch() function or whatever. FWIW, I included a SEARCHRES example in PREVIEW draft in hopes of demonstrating how this extension can be practically useful. See https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-00#page-8 michael > On November 20, 2018 at 2:12 PM Chris Newman wrote: > > > We've implemented this extension and it's not difficult to implement on the server side so I'm in favor of including this. I'd be interested in a client implementer's perspective. > > - Chris > > On 8 Nov 2018, at 3:27, Bron Gondwana wrote: > > > > This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. > > > > In favour - it's useful to compose actions. > > > > Against - it's not widely implemented or used. > > > > Arguments for and against in response to this please. > > > > Cheers, > > > > Bron. > > > > -- > > Bron Gondwana, CEO, FastMail Pty Ltd > > brong@fastmailteam.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Extra mailing list > > Extra@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=6krI1FgmWhZv2LqblI2h4VuwuAN9JX254RcYg-ZMIGE&s=tOzMc_3golA1EPLg7hmfq0_-klVUFWcd4k9fF17iwwU&e= > > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > ------=_Part_9748_793789840.1542824197478 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
[FYI: I'll be replying to all of Bron's imap4rev2 messages with the "official" Dovecot response.  Don't worry - the feedback is from people much smarter than me - I'm mainly in charge of being the messenger!]

SEARCHRES is already implemented by Dovecot (has been for awhile).  No objection to including in imap4rev2.

Only question - similar to Chris' - is what the usage is on the client side?  SEARCHRES doesn't seem useful for non-pipelining clients, which is the way the vast majority of IMAP libraries are implemented, at least the ones I have looked at.  e.g. code that programatically calls a search() function, then uses the response from search() and does a fetch() function or whatever.

FWIW, I included a SEARCHRES example in PREVIEW draft in hopes of demonstrating how this extension can be practically useful.  See https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-00#page-8

michael

On November 20, 2018 at 2:12 PM Chris Newman <chris.newman@oracle.com> wrote:

We've implemented this extension and it's not difficult to implement on the server side so I'm in favor of including this. I'd be interested in a client implementer's perspective.

- Chris

On 8 Nov 2018, at 3:27, Bron Gondwana wrote:

This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline.

In favour - it's useful to compose actions.

Against - it's not widely implemented or used.

Arguments for and against in response to this please.

Cheers,

Bron.

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


_______________________________________________
Extra mailing list
Extra@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=6krI1FgmWhZv2LqblI2h4VuwuAN9JX254RcYg-ZMIGE&s=tOzMc_3golA1EPLg7hmfq0_-klVUFWcd4k9fF17iwwU&e=

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

 
------=_Part_9748_793789840.1542824197478-- From nobody Wed Nov 21 10:24: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 A40E3130F3F for ; Wed, 21 Nov 2018 10:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 NIfOVU8eCAuP for ; Wed, 21 Nov 2018 10:24:45 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 DC298130E14 for ; Wed, 21 Nov 2018 10:24:44 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 3F1A56A272 for ; Wed, 21 Nov 2018 19:24:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1542824683; bh=neR9/m30psrdwbbGhFxMI8BCG5/QPmIc+s1UBSrmZQU=; h=Date:From:To:In-Reply-To:References:Subject:From; b=0efN18H0opyBXU57zN+bo87SZluBPYHyuvtYA012lPaf3rIwO/fYx4vD/MR86LS/O D48fMKnSg6KfKn5T0T1W8xUrudboZZnskAp1kxkyTY261ZFGKleZ5Dp/nO8vB3oF+w OE+C2GsycQ0Dk1XHsjpdoB3q7nVzNJ7oaG/NYmnk5zf/6oIa+TvgILh4HXa7qLtNMQ mip5tj2XI8TfKBgcTUvhw+Sr7l/Ti2n0k78O6tY5jDI9uW29kaIbjfLEobp7pVuBWV bmepNdCt2rJjJ0O9MVKFct+kSFDXrMqobM+xgaMobcd1I2AD5iMVojroNrUzakHRfM sZUkMVRIcoi8g== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 384C33C06FD for ; Wed, 21 Nov 2018 19:24:43 +0100 (CET) Date: Wed, 21 Nov 2018 11:24:42 -0700 (MST) From: Michael Slusarz To: extra@ietf.org Message-ID: <2090524145.9759.1542824683173@appsuite.open-xchange.com> In-Reply-To: <50B39537-6D3D-47CF-B1FC-1B592C66F69B@oracle.com> References: <8fcce54e-4d33-4f2b-92b2-0a5ec8bfec5b@sloti7d1t02> <50B39537-6D3D-47CF-B1FC-1B592C66F69B@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-Rev20 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] imap4rev2: STATUS DELETED X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 18:24:55 -0000 > On November 20, 2018 at 2:19 PM Chris Newman wrote: > > > On 8 Nov 2018, at 3:30, Bron Gondwana wrote: > > This is one of the open issues from imap4rev2 - which extensions > > should be part of the mandatory baseline. > > > > This was a discussion about a way to easily see if there are messages > > with \Deleted in a mailbox, maybe to see how much quota can be freed > > up. General agreement in the room was "IMAP4rev2 is for a baseline of > > existing standards, maybe this should be a new document, but not part > > of IMAP4rev2" > > > > Discussion on whether we think the general concept is useful, and > > whether it's so useful we should make it part of IMAP4rev2 in response > > to this please. > > We've implemented a custom 'status counts' extension that provides > counts based on each configured message type including: > * total, seen, deleted, seen-deleted > the intention of this extension was to help support voicemail and > similar unified messaging features. We implemented quota & quota-usage > by message type via a quota root naming convention. > > I don't think we should delay IMAP4rev2 to include something like this, > but I can see it being helpful for some use cases. Not much support from us on this. We question its usefulness, as proposed. Timo pointed out this somewhat related former proposal: https://tools.ietf.org/html/draft-neystadt-imap-status-counters-01 Maybe this makes sense if status checking is more extensible, and not limited to a single attribute? But it also seems that this kind of solution is not something to cram into rev2 at this stage. michael From nobody Wed Nov 21 10:48: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 F2A8812875B for ; Wed, 21 Nov 2018 10:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 j0xnTAqGQvbR for ; Wed, 21 Nov 2018 10:48:04 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 7A30D12426A for ; Wed, 21 Nov 2018 10:48:04 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 7F7726A272 for ; Wed, 21 Nov 2018 19:48:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1542826082; bh=KJxbVcLE6Qta6rSrWHeS1h3PYIGr+PKLBDR3mkvvSqs=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Kj/Xgr7yQXA8ZtvBpVrrwzOMtZhtJNz/t61dGnwUgGBAxhqRNQNc1FBKRIuGSPz7Q RjFsppftnQ8nrNScdFe7ip9CrERs5S2JCvrX1HS4a2dmxsTh8tNeceLxgDFBu+QkXN 9sEVWg6iIngUJOAMHIsF+HigmlN77jO1xYNklo5wb4MrNntbS7piKkFmsVpiPIO4Kr rEqmkpJpS7FYhe9bPQJtsKTU4XSK5jmBQu5pIx9O9uoPozpMFODIiJz85SbFPoCWLB pKi2CvNTnmaI6eck8FQsizPuGx10KG1Nn44W7Si6t0KsQw0ydMFYk6sModu9wpJ3sM YKWmuodVJei6Q== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 649773C06FD for ; Wed, 21 Nov 2018 19:48:02 +0100 (CET) Date: Wed, 21 Nov 2018 11:48:02 -0700 (MST) From: Michael Slusarz To: extra@ietf.org Message-ID: <1619478286.9776.1542826082345@appsuite.open-xchange.com> In-Reply-To: <7C112497-CA9C-4926-B3B1-4E3440CE9365@oracle.com> References: <6f804b07-35bd-4ca3-ad84-bf69daeaa6e9@sloti7d1t02> <7C112497-CA9C-4926-B3B1-4E3440CE9365@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-Rev20 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] imap4rev2: RFC8474 OBJECTID X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 18:48:07 -0000 > On November 20, 2018 at 2:41 PM Chris Newman wrote: > > We've implemented an extension equivalent to MAILBOXID already; no > objections to that part. As THREADID is optional, no objections to that. > We've not implemented EMAILID yet. I believe FETCH of EMAILID is > reasonably straightforward, but SEARCH by EMAILID may add significant > complexity, particularly with respect to search index version migration > issues. As a result of the latter issue, it will be difficult for us to > find cycles to implement and test OBJECTID, so I oppose mandatory > inclusion of OBJECTID in IMAP4rev2. We have the internal support for much of this already - it's just a matter of exposing this via the standard API. We are working on a project now that essentially requires THREADID for performance reasons, but it's also the hardest to implement since it requires implementation of a thread tracking database to efficiently handle these queries. I can't think of any other "optional" items in base imap4 at the moment, so this would be a bit of an outlier. And I would think that we see more use cases for thread based access models going forward, as messaging in general has moved in that direction in the last decade. But with THREADID being the most interesting part of this, and it being optional, there doesn't seem much difference between having in rev2 or having as an extension since there is no guarantee it will exist either way. So this seems better left as an extension at this time. michael > On 8 Nov 2018, at 3:32, Bron Gondwana wrote: > > This is one of the open issues from imap4rev2 - which extensions > > should be part of the mandatory baseline. > > > > In favour - it's very useful for client efficiency, and maps to very > > popular Gmail extensions. > > > > Against - it's very new, and not widely implemented yet. From nobody Wed Nov 21 10:52:35 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 1979F1294D0 for ; Wed, 21 Nov 2018 10:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 roQqqSQwRqsj for ; Wed, 21 Nov 2018 10:52:33 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 E04CB12426A for ; Wed, 21 Nov 2018 10:52:32 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 578A06A272 for ; Wed, 21 Nov 2018 19:52:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1542826351; bh=rV70KLVEFj5QRDIo4pydxfKehlx1UlpvHPlAhVVxe8A=; h=Date:From:To:In-Reply-To:References:Subject:From; b=u/GV1TKhsjlRtAFftlIZIFxaxNsCI0j0rMZQlUuAN+bh1wZM3e/MZ5HfbZNHGVmH/ q1Rxfqmo5qXSMdFlYUhztoHXrqn6X7mjTiE/KxM7OpGD3a+vc9a/u5vaV95TrPX3MI x7xYmup6mRssYpmgWZy2HbxEGLot4UQyQBHt2vzRrt/EOmOKejnvgyX/Dg4sQzPJ2d nzF4mS/wQUkHK63Cu/JptCA7yuF17FXSCN/FiAT8wZ7Pyb7Y0EQMtiVLq5tF5h7IPl HntnHA6xvnLkt6R4wOwueD3etBmT3p5dUpDYMB9INRE1p2JpaOdAp6ktcQk7p7rH4V 1l8ozTQhubvyA== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 436AE3C06FD for ; Wed, 21 Nov 2018 19:52:31 +0100 (CET) Date: Wed, 21 Nov 2018 11:52:30 -0700 (MST) From: Michael Slusarz To: extra@ietf.org Message-ID: <738498375.9779.1542826351211@appsuite.open-xchange.com> In-Reply-To: References: 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-Rev20 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] imap4rev2: draft-ietf-extra-imap-replace X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 18:52:34 -0000 > On November 20, 2018 at 2:43 PM Chris Newman wrote: > > > On 8 Nov 2018, at 3:44, Bron Gondwana wrote: > > This is one of the open issues from imap4rev2 - which extensions > > should be part of the mandatory baseline. > > > > This one isn't even standard yet, but it's a nice pair with MOVE as a > > way to avoid running into intermittent issues near QUOTA when you're > > doing things like editing Drafts, and it's similarly easy to implement > > on top of existing actions. > > > > Arguments for and against in response to this please. > > I'm neutral on inclusion of this extension. We've not implemented it > yet, but it should be straightforward to implement. If enough client > authors are interested in making use of it, I'd consider implementing > it. Neutral/slightly agree on inclusion. No support yet in Dovecot. Internally this is tricky for us due to our quota system design, so it's not a straightforward implementation. michael From nobody Wed Nov 21 11:07: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 C9FD9130DC8 for ; Wed, 21 Nov 2018 11:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 IUIy6xmpUjiU for ; Wed, 21 Nov 2018 11:07:12 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 E85A9130DC4 for ; Wed, 21 Nov 2018 11:07:11 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 4B4586A272 for ; Wed, 21 Nov 2018 20:07:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1542827230; bh=5lLC8itlGn37gA0vCrrcAVdo/aflSt6nu1wc1UHK4Us=; h=Date:From:To:In-Reply-To:References:Subject:From; b=e4D6foq9ApwfDNwCM9jNbK8Jx8rGg7fP7tG1eFZa0rt94ZmiP195e7wlgySMh74XU ADjTsHXrooXTIhnCh7KwYlIbB3MfUv8FTE1AbvxaK12tx4USXlVlDBKU1/a3iO48Vl +CylVqtUzsM4k5MMhrY+kpdguFK65O7/+NtPcY8kJRDx4fIHba2GZ94NcOjuRsMd2Z Ljb6pi5Ayh8Njaxu/nBkjMeC92+BrVNfBqIyWcrVbC5y6eJQDPbN/x5N/C/+6W3v+m Dw4sClZXL4HBos1TDqLKPhrvjf+eBA/Kf886sNLrhfLcauspbPnlgOtua8y8RdQDG3 fq73yQebL6OPw== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 365223C06FD for ; Wed, 21 Nov 2018 20:07:10 +0100 (CET) Date: Wed, 21 Nov 2018 12:07:09 -0700 (MST) From: Michael Slusarz To: extra@ietf.org Message-ID: <1414723034.9788.1542827230159@appsuite.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev20 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 19:07:14 -0000 > On November 8, 2018 at 4:25 AM Bron Gondwana wro= te:=20 >=20 > This is one of the open issues from imap4rev2 - which extensions should b= e part of the mandatory baseline.=20 > =C2=A0 > In favour - it's quite useful, and has fairly wide server support (includ= ing Gmail and Exchange), and at least Thunderbird as a client uses it.=20 > =C2=A0 > Against - Oracle haven't implemented it. Dovecot team in favor of adding to imap4rev2. Dovecot has support for MOVE= already. michael From nobody Thu Nov 22 07:22: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 4506E129A87 for ; Thu, 22 Nov 2018 07:22:48 -0800 (PST) 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 8bZaTeT-DWmq for ; Thu, 22 Nov 2018 07:22:46 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (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 B91051292AD for ; Thu, 22 Nov 2018 07:22:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QZXQYRTZ28000BPM@mauve.mrochek.com> for extra@ietf.org; Thu, 22 Nov 2018 07:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1542899863; bh=5i9Jt1sIbyP1GYxenP8YYVxAmRw+5CRt6XMh2dTW5W8=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=XspTD5Iym9S391nGeFT19c+O9DOA+FppOTe0Oj6ReCpSornLP9RfcQVo6Sip9gf3W gHn9YWY3k7YbZlzgFmYdjLv4x42+bjwppcnX0km3hm1pcZ3Ro3RYJC0fYsrItNWJbY 22V6x4Aw8QJZBpBXmJQWRPZ11bynThzC3JaVGFno= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=gb2312 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QZVOKD2WTC00004R@mauve.mrochek.com>; Thu, 22 Nov 2018 07:17:37 -0800 (PST) Cc: "chris.newman" , extra Message-id: <01QZXQYPV3MA00004R@mauve.mrochek.com> Date: Thu, 22 Nov 2018 07:00:55 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 21 Nov 2018 20:51:25 +0800" <201811212051229361548@cnnic.cn> References: <201811212051229361548@cnnic.cn> To: Jiankang Yao Archived-At: Subject: Re: [Extra] IMAP RFC 6855 (IMAP EAI) implementation experience: input to IMAP4rev2 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 22 Nov 2018 15:22:48 -0000 > From: Chris Newman > Date: 2018-11-21 07:28 > To: extra > Subject: [Extra] IMAP RFC 6855 (IMAP EAI) implementation experience: input to IMAP4rev2 > > Ned's > >implementation experience from RFC 6531 was that the real world just > >can't usefully work the way the specification describes. That experience > >informed my work implementing RFC 6855. > > > ICANN UASG EAI WG is pushing the deployment of EAI. John Levine has run an > analysis of the EAI Readiness of the Internet¡¯s mail servers. > His DRAFT report is at https://docs.google.com/document/d/18W-dAr1Nhe_gVlFKDQZqsqB4bf5N86wryEcALnyUPTc/edit#heading=h.dba7p1kazxqa > From this report, the current EAI deployment is amazing. I would use a very different term to describe the degree of what the report calls deployment, but that's really beside the point. The fact is that since these numbers count services like gmail as a successful deployment of EAI, they are irrelevant to point Chris is making. Why? Because gmail doesn't implement EAI acccording to the standards - and Google makes no secret of this. The last I checked gmail will happily send an EAI message to server that doesn't support EAI - which is the only sensible thing to do, gmail doesn't implement the user agent side of EAI at all, and most importantly, gmail only supports other people's EAI addresses; not its own. Indeed, the fact that Google saw fit to "implement" EAI this way only serves to support the point Chris was making: EAI as specified has some serious issues, and sooner or later the IETF is gong to have to deal with this. > You may also be interested in this list discussion here > https://mm.icann.org/mailman/listinfo/ua-eai It's a private list; the archives of which are not public. Ned From nobody Thu Nov 22 21:09: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 93F9C126CC7 for ; Thu, 22 Nov 2018 21:09:50 -0800 (PST) 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=oG7WRgLf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=el3cQZwb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5zKwbZ9viOU for ; Thu, 22 Nov 2018 21:09:49 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0363127B92 for ; Thu, 22 Nov 2018 21:09:48 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D7C8021DC7 for ; Fri, 23 Nov 2018 00:09:47 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 23 Nov 2018 00:09:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=L18Snl53A87OdyzR/w9gaNuOHXLF W67EQvdjGG1EZPQ=; b=oG7WRgLfyY1k2QWCGiRaagcce8Rfo3S5rKcJ7+5o/01d P+W3VyYTh11OeCOudZHYF8dI876oMNHo3pLMzJbKdihp+8T2DBzVXJREoAWFQShf U1i6w6lqNX8QCeYR2Ou682eAXTwpS+u+1dwXF9KOHlI6TPgG+76s4l52CD5jUBIq xhYsQdtvAtxVhaY9IOJ0nF/LSQx0Icln18+gGv5k/yTJDT7PSELOejWZr0ikKLbQ tPzp72jPTXhjxp5OFyGLfAkdZceOs1D81q6fOUjYUuBsElT+yiCcryG+Ry+vZCjd Yaa+1sFxSB8M0H3OwVaCDOzeja3tkh63Lo4BaJlOHg== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=L18Snl53A87OdyzR/ w9gaNuOHXLFW67EQvdjGG1EZPQ=; b=el3cQZwbMf3+Opl5hzcroNiZxhZbE1+bO IfuVPUjax2ikVGX/k1o1xa9YkhZIynSIvTCfBZaQtsQC+JrtNRATMNXGynxmLpsi Bzpc8KhWA8UaX5u5gu7Q2E17lrMHOXmIgwAKzqU4L/P9Wvwi6X7DS1dXHHyoeLKm 5YvT1nkFxtS8jEUCjy53JFvwrk9kcmBFYAmufhMfM+kz3Tr/El1IKdfBVoD4o09H uL+EQYn9t8Axs4BwvFAYg3VrK1dXMixCa5Ml5ejTLxGQsKj7FV328hL2ktJNhag/ V18luE804F/Y0/+2mrJ7LObT17i9rir36ZOrAQcB57SrdusPihjNw== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7EC3F204DC; Fri, 23 Nov 2018 00:09:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: <0cd69746-bcbd-4cea-8500-8d485eef33ea@gulbrandsen.priv.no> References: <5BE4DB10.6090003@aol.com> <+zYCDTO4ZdsjSWin88IbqbIxTnobzOcvIPeIiYbAjBA=.sha-256@antelope.email> <776977791.12860.1542298378436@appsuite.open-xchange.com> <0cd69746-bcbd-4cea-8500-8d485eef33ea@gulbrandsen.priv.no> Date: Fri, 23 Nov 2018 00:09:47 -0500 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=8ade84b69df149698ba257a9b5e64e2c Archived-At: Subject: Re: [Extra] imap4rev2: RFC6851 MOVE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2018 05:09:51 -0000 --8ade84b69df149698ba257a9b5e64e2c Content-Type: text/plain On Fri, Nov 16, 2018, at 09:13, Arnt Gulbrandsen wrote: > On Thursday 15 November 2018 22:43:47 CET, Rob Siemborski wrote: > > IIRC, Mark's resistance came from the "its a shortcut" idea > > that Michael mentioned. > > One of the people who proposed a MOVE argued that the command wasn't a > shortcut in case of... at least three formats that were in use at the time. > MH, djb's format and one more. I don't remember the details. But I do > remember that Mark ignored that, and that I assumed that the shortcut > argument was just a superficial rhetorical device, not a deeply held > conviction. > > I found his position very puzzling. My protocol philosophy is that the protocol should describe, as accurately as possible, the user's intention in a way that the server can then decide the best way to implement that intention - which is why I argued for move, because that's what the user is doing! So yeah, I strongly support adding MOVE to the base protocol. Everyone seems to like it. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --8ade84b69df149698ba257a9b5e64e2c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Nov 16, 2018, at 09:13, Arnt Gulbrandsen wrot= e:
On Thursday 15 November 2018 22:43:47 CET, Rob Siem= borski wrote:
> IIRC, Mark= 's resistance came from the "its a shortcut" idea 
> that Michael mentioned.

O= ne of the people who proposed a MOVE argued that the command wasn't a&nb= sp;
shortcut in case of... at= least three formats that were in use at the time. 
MH, djb's format and one more. I don't remem= ber the details. But I do 
remember that Mark ignored that, and that I assumed that the shortcut=  
argument was just a su= perficial rhetorical device, not a deeply held 
conviction.

I found his position = very puzzling.
<= br>
My protocol philosophy is tha= t the protocol should describe, as accurately as possible, the user's in= tention in a way that the server can then decide the best way to impleme= nt that intention - which is why I argued for move, because that's what = the user is doing!

So yea= h, I strongly support adding MOVE to the base protocol.  Everyone s= eems to like it.

Bron.

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


--8ade84b69df149698ba257a9b5e64e2c-- From nobody Mon Nov 26 09:37: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 C779F12F1A2 for ; Mon, 26 Nov 2018 09:37:37 -0800 (PST) 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=c554H00+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y7UfjIFU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4xM0KH7hcN1 for ; Mon, 26 Nov 2018 09:37:35 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8B5126CC7 for ; Mon, 26 Nov 2018 09:37:35 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D6F0021D19; Mon, 26 Nov 2018 12:37:33 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 26 Nov 2018 12:37:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=OYGcWICbc+fXGbPEy6qzC8LxO2n sFSRwwZgSqol86Lg=; b=c554H00+Ikoj3h3NwU7YpXHHeg4KRug1XO/c4Pil/8O 8Fso1dBw85j54pypnxSdRGAAOXL87utO3RJVL/b5T0doev4lsD0PRsm2fh3SCykO qVr+B2bKWPVnTQ1kx+DIZGG/xTod1iF60AhHEodjceZ9kPSmZBb147V81LkupwJ/ +XAIf7L5TcgxCReYqOLCjo7l+y+ph2l8Of0m06yEjOTmnskGG/VPrmn/mXi6hb+0 QtX0TECsEDJq9LBfiNb2ZWET/2eZ6Q/4d7+jDb6/fX3XZbFFlex+9RCSxyTRUUat hha0bx5FJYsVQB4PezUOuHMOxEaxyCE8B8MBtISPttw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OYGcWI Cbc+fXGbPEy6qzC8LxO2nsFSRwwZgSqol86Lg=; b=Y7UfjIFURpLLYawFy92HGc BkjuvKNHhrOj8fJeTpkIU0ZA2rBhhPl53dgIpdC6nOc77+MX+aUcPNMs9KXgtAIS BKpoaBAFXsUY3uCyxl3iygyXjrEA8R0hfCShfq3tkzglvfKKaetlB+YW4gjiJ/HT Eo1MLmhZHmfQf3m9JMtZH6NnyPHzK4zqbpX+JSjz3S6ub5Iu9AVZ6/kkeYLvvC0P F6OTXQVwilfiJikb0B2CO8HrEf1N9h7onqKzHmu2l1BSB8j5USi/chXVGsIaekVF 1Ml26w6ielsMkoTcXk5ay/tyQd3UfxdSaO8hSJCQxgM1RWjhapmOZTtddjrIL0/A == X-ME-Sender: X-ME-Proxy: Received: from localhost.localdomain (unknown [205.197.242.27]) by mail.messagingengine.com (Postfix) with ESMTPA id B520D102F3; Mon, 26 Nov 2018 12:37:32 -0500 (EST) To: Alexey Melnikov , extra References: <2a2f0f33-b056-1a04-aa11-8b8d0a448a4c@isode.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <1ed8498f-4418-69c7-708d-337296722fa5@fastmail.com> Date: Mon, 26 Nov 2018 12:37:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------72D6194687A3AF15AA65C5C3" Content-Language: en-US Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-sieve-fcc-06.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 26 Nov 2018 17:37:38 -0000 This is a multi-part message in MIME format. --------------72D6194687A3AF15AA65C5C3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/16/18 1:25 PM, Alexey Melnikov wrote: > Hi Ken, > > On 09/11/2018 16:54, Ken Murchison wrote: >> >> On 10/16/18 12:35 PM, Alexey Melnikov wrote: >>> >>> Later in the same section: >>> >>>    If the specified mailbox doesn't exist, the >>>    implementation MAY treat it as an error, create the mailbox, or file >>>    the message into an implementation-defined mailbox. >>> >>> Allowing for either an error or filing into different mailboxes is >>> going >>> to make scripts non portable, considering that there is no way to test >>> in a Sieve script which exact behaviour is supported. >>> >>> Also, why is it Ok to have all these different choices, which will >>> potentially >>> >>> confuse users? I would like to either have a way to test for >>> different behaviour >>> >>> or have some explanation in the document why all of the choices are >>> acceptable. >> >> I think some of this text was borrowed from special-use.  Would be be >> acceptable to do what fileinto does, which is if the target mailbox >> doesn't exist, then the message ends up in INBOX?  I'm also fine >> treating it as an error. Actually, the text that you quote comes straight from the fileinto description in RFC 5228.  Do you still want me to put a stake in the ground and pick one behavior? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------72D6194687A3AF15AA65C5C3 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------72D6194687A3AF15AA65C5C3-- From nobody Tue Nov 27 12:46: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 DF8B1126F72; Tue, 27 Nov 2018 12:46:43 -0800 (PST) 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.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <154335160386.11805.11486350625060621324@ietfa.amsl.com> Date: Tue, 27 Nov 2018 12:46:43 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-04.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 20:46:44 -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 : Sieve Email Filtering: Delivering to Special-Use Mailboxes Author : Stephan Bosch Filename : draft-ietf-extra-sieve-special-use-04.txt Pages : 11 Date : 2018-11-27 Abstract: The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes; e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into an anonymous mailbox that has a particular special-use attribute assigned. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-04 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-use-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-special-use-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 Nov 27 12:48: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 8980B126F72 for ; Tue, 27 Nov 2018 12:48:50 -0800 (PST) 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 YNA3tGZk9oY3 for ; Tue, 27 Nov 2018 12:48:48 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9B897124D68 for ; Tue, 27 Nov 2018 12:48:48 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id AED4F2B3C96 for ; Tue, 27 Nov 2018 22:48:46 +0200 (EET) To: extra@ietf.org References: <154335160386.11805.11486350625060621324@ietfa.amsl.com> From: Stephan Bosch Message-ID: Date: Tue, 27 Nov 2018 21:48:45 +0100 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: <154335160386.11805.11486350625060621324@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-04.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 20:48:51 -0000 Hi, I posted a new draft of the Sieve special-use extension, which now includes the IMAP examples suggested by Ned Freed. Did I forget to include any other fixes discussed earlier? Regards, Stephan. Op 27/11/2018 om 21:46 schreef internet-drafts@ietf.org: > 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 : Sieve Email Filtering: Delivering to Special-Use Mailboxes > Author : Stephan Bosch > Filename : draft-ietf-extra-sieve-special-use-04.txt > Pages : 11 > Date : 2018-11-27 > > Abstract: > The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows > clients to identify special-use mailboxes; e.g., where draft or sent > messages should be put. This simplifies client configuration. In > contrast, the Sieve mail filtering language (RFC 5228) currently has > no such capability. This memo defines a Sieve extension that fills > this gap: it adds a test for checking whether a special-use attribute > is assigned for a particular mailbox or any mailbox, and it adds the > ability to file messages into an anonymous mailbox that has a > particular special-use attribute assigned. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-04 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-use-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-special-use-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/ > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Thu Nov 29 12:19: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 25D8E130EBE; Thu, 29 Nov 2018 12:19:07 -0800 (PST) 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.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <154352274712.26100.17890487584452373074@ietfa.amsl.com> Date: Thu, 29 Nov 2018 12:19:07 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-07.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 29 Nov 2018 20:19:07 -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 : Sieve Extension: File Carbon Copy (Fcc) Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-sieve-fcc-07.txt Pages : 14 Date : 2018-11-29 Abstract: The Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFC5230 and RFC5435 by adding a new tagged argument to the "vacation" and "enotify" actions respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-07 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-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 Thu Nov 29 12:20: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 85833130EBF for ; Thu, 29 Nov 2018 12:20:38 -0800 (PST) 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=JBVxVSOg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bzgN7Gh1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M93U79CVj3Rl for ; Thu, 29 Nov 2018 12:20:36 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51961130EBE for ; Thu, 29 Nov 2018 12:20:36 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 84E1D242A1; Thu, 29 Nov 2018 15:20:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 29 Nov 2018 15:20:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=n4EfPZ9/L1rP/pvXXKvakwjgKPj lDg1kAVx8U+FPd/o=; b=JBVxVSOgdRPzP7oq3eYdRcBHPr/zK109jQfxnhxyMc+ ZEwX/33YszzN4+PzGWRwSYuwycLViD2VAc0G3MD4I0bn2rc4Sx9YKrrB/hIGrlF0 I3ek32T5NXO7X5x8M2cJFoP1Knsb4htuscsjr7p524mD1dH022PQUBghVJzvS5DN voCwDOQAjKYuuko1LR26Fd9sJCkYx84+DJm5/QMcT77YfMWi6mF4KYhbtoVo+HaS 6R+ZEHDP/Jprf0UZKQR1eHNxw4l3SjXt/+XxhzAo9pFdlh74yGqIKYtr+dMXF/Nj FtpESz5/ey2Mht05kYXqg3rflkcLs5dv3sIht7j73BA== 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-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=n4EfPZ 9/L1rP/pvXXKvakwjgKPjlDg1kAVx8U+FPd/o=; b=bzgN7Gh1o4GJxwXsW/Hv4P Zt97gsgl6ePNTk3lprKn7T8OMv0pWoJeBWFalnsYFiOBtG5zrR3AeyUrFJy6jvaP /b/R1bQPfTWAOeiI5QHThEqDhojZSDRws50j2jnjIsvcSXnm656k2CzDOEk9L99R +MH+ZqImSHXmkWMctznRCtQjjFqsQI9Y+yFbsP2khv5+yAcHBTOndeoRsGYTIuwy SCb+kSFKKhzEmcVZ5qhhZ9TqbR28MphLyMtotjqjh0dUxrTAdQgMCmfxNXKbcynX NAFT/jIAWtXZ0gZli7KLxHBiPZqmXryLyG8ZAWhQVNFBp/iHrnDwVbSIvXlLRV8g == X-ME-Sender: X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id B189DE446A; Thu, 29 Nov 2018 15:20:34 -0500 (EST) To: extra@ietf.org References: <154352274712.26100.17890487584452373074@ietfa.amsl.com> Cc: Alexey Melnikov From: Ken Murchison Organization: FastMail US LLC Message-ID: <0150902b-8f04-5a2a-1ba4-3e0fe644f169@fastmail.com> Date: Thu, 29 Nov 2018 15:20:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <154352274712.26100.17890487584452373074@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------4F0F637999802FA4B6000C2F" Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-07.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 29 Nov 2018 20:20:38 -0000 This is a multi-part message in MIME format. --------------4F0F637999802FA4B6000C2F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Alexey, Please let me know if this update addresses all of your issues with -06. On 11/29/18 3:19 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. > > Title : Sieve Extension: File Carbon Copy (Fcc) > Authors : Kenneth Murchison > Bron Gondwana > Filename : draft-ietf-extra-sieve-fcc-07.txt > Pages : 14 > Date : 2018-11-29 > > Abstract: > The Sieve Email Filtering Language provides a number of action > commands, some of which can generate additional messages on behalf of > the user. This document defines an extension to such commands to > allow a copy of any generated message to be filed into a target > mailbox. > > This document updates RFC5230 and RFC5435 by adding a new tagged > argument to the "vacation" and "enotify" actions respectively. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-07 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-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/ > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Ken Murchison Cyrus Development Team FastMail US LLC --------------4F0F637999802FA4B6000C2F Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------4F0F637999802FA4B6000C2F-- From nobody Fri Nov 30 04:00: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 17D74130DDF for ; Fri, 30 Nov 2018 04:00:12 -0800 (PST) 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 3Hsitjc3fWPp for ; Fri, 30 Nov 2018 04:00:09 -0800 (PST) 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 24564130DE0 for ; Fri, 30 Nov 2018 04:00:08 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 46511C00EE; Fri, 30 Nov 2018 12:01:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1543579276; bh=ON3yKSodFM2Cav2vgkfFaaiwvAhjhLekaRGUISDSwNE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=N3z/Y5CbvGHvGQnA4Dh6JagylpY67Wsy4eHO55GZMeQ2QA+HAS5kejY20GMgC1lVy BYBMS4BAc83t2UOrWxBB19D/FWhEoW0PWGDeMTLUZaPNPnAoRPliuaIlWSQNwce6Q/ Cij57CZ7iibTQDTihnYfl4leoxfMhyz2X5iYGcLU= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1543579274-32426-32424/9/269; Fri, 30 Nov 2018 12:01:14 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Fri, 30 Nov 2018 13:00:05 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: References: 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] IMAP RFC 6855 (IMAP EAI) implementation experience: input to IMAP4rev2 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 30 Nov 2018 12:00:12 -0000 Chris Newman wrote: > It's interesting that my implementer hat and standards hat > result in diametrically opposed positions on this issue, but so > be it. I think this is because RFCs are obliged to respect other RFCs more than implementers are. You, as implementer, may reasonably look at what hurts most in practice in your part of the world; the set of RFCs ought to be consistent if at all possible. BTW, this is why RFC 6858 exists in the first place. Enabling reading using 6857 is IMO too much work compared to just-send-8, which is IMO tantamount to encouraging violating 3501's rules. The simplest possible conformant implementation shouldn't be hard. You should find 6858 easy to implement well enough that mail can be read without violating any rule in 3501. If not, I failed. Almost as an aside, doing so should minimise the risk of provoking a bug related to sending mail, by making replying and composing fail in a safe/predictable manner. But not implementing it is IMO also entirely reasonable, even if an RFC should not say so. Arnt