From nobody Sun Nov 1 21:00:42 2020 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 8E2893A0D95; Sun, 1 Nov 2020 21:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=pj6Z8KYA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SuuQgcGT 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 Wl0EmfCC6Oqk; Sun, 1 Nov 2020 21:00:33 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D073A0D8B; Sun, 1 Nov 2020 21:00:29 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 809735C009C; Mon, 2 Nov 2020 00:00:28 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Mon, 02 Nov 2020 00:00:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=ffyC lxxqi1F3mDbjDQgkyrKqlYhI0FvZrC9VY07qlLA=; b=pj6Z8KYASCnazRVl/C7v QuA7UyNBQHb+mGMKVrypuhDtpgi6dIo4nMj6rrb7YT2zguKmaPZ1RHJWybO8Tddq Wu5C7v5OObrlYvhGuv0t6PTlUVEdNCYp+x6JqimjPEfnJatMGGn6QchTMlwTbZum fzaLqu55K9ycEBqahqsSx6fvDY/RiQJwC1mYZcRdmTt3MJ5AjmziO1TuKXsmm3Ob cH4pBd+rgFdr/siqNXRhp66fp8Css/9Uv56mm4NVeLGRyGneB6M41mKFeQTpHhgB M//UodhWrLA3g2xdwFTji42YNa0l/KYX067T70yUDRyUkCa9NpQrlSyd1meL28IX iw== 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=ffyClx xqi1F3mDbjDQgkyrKqlYhI0FvZrC9VY07qlLA=; b=SuuQgcGTaqcFD8aJJiuM0w AMD6pUXz45uvO1CaTYhk+o/tObAY1EKcl7x1q4mOgagMGsaYxJs62mC0uRVUKIL5 PdERs3lYIKEWCBNMb0PRkbPHzkeYC/6r5qtvvLOCy4YMt9djxcf1Sa2Uk3dQ+YE6 D6Uwz4C4HY/d+8R6/ZN28uS6SD3d0kj1PV6Y5vuu4jcXjcZvGw8NQRagg5WpB2vl QiydiSQxL/fB9yOyKqV1hash/skZUV1x0TWQKOvfy052XxAN9lAOtHjjDuuHz3GO cUP9wHMrrrmRD0e2gmVUYDqwltyc+z5H06/y0cA01bzRBPGgUUpLdNVgy79lY+Kw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddttddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnheptdehteegfeevteduffevteehfffghefhvdevkeeuhfeh ueetudehgfegieekjeetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0921C180093; Mon, 2 Nov 2020 00:00:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 02 Nov 2020 16:00:06 +1100 From: "Bron Gondwana" To: "Barry Leiba" , draft-ietf-extra-sieve-mailboxid.all@ietf.org Cc: extra@ietf.org Content-Type: multipart/alternative; boundary=476301d9189a49a8bd7b9193e11c07c4 Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-sieve-mailboxid-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: Mon, 02 Nov 2020 05:00:41 -0000 --476301d9189a49a8bd7b9193e11c07c4 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 7, 2020, at 11:01, Bron Gondwana wrote: >=20 >=20 > On Sat, Sep 5, 2020, at 03:23, Barry Leiba wrote: >> Here's my AD review of the subject document. I have some issues to >> discuss about the specification, so please read my comments and let's= >> have the discussion. I'll set the substrate to "AD Followup". [...] >> =E2=80=94 Section 4.2 =E2=80=94 >>=20 >> What=E2=80=99s the use case for prioritising the mailboxid over the s= pecial >> use? That also seems an odd choice, given the context of special use= >> mailboxes. The combination just seems strange =E2=80=94 I would norm= ally >> specify *either* the special use of the mailbox *or* the name, but no= t >> both. Adding mailboxid to that just adds more weirdness. >=20 > That's fair - I would be willing to change the order there. I expect = that nobody will do it, but I don't want to forbid it either, and I want= to define a fixed order that works the same across servers. >=20 > I will write an email to the list about this particular issue, so it d= oesn't get lost in this. I ran into too much complexity with this in the end. It means we can't = just say "follow the process in the other doc" and instead have to creat= e a big messy state machine that replicates it - for no real benefit. If you don't want delivery to stick with the mailboxid, then in this cas= e you would indeed create a rule that is just "fileinto by specialuse" a= nd not specify a mailboxid - so the only reason to specify the ID is if = you wanted to stick with the mailbox even if the specialuse was moved. = Maybe it doesn't make sense to allow both, but I also don't think it hur= ts to allow both, and having the ID bind more tightly is clean, because = the ID can never be moved to another mailbox. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --476301d9189a49a8bd7b9193e11c07c4 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 7, 2020, at 11:01, Bron Gondwana wrote:


<= div>On Sat, Sep 5, 2020, at 03:23, Barry Leiba wrote:
Here's my AD review of the subject document.  I have some issues= to
discuss about the specifi= cation, so please read my comments and let's
have the discussion.  I'll set the substrate to "AD= Followup".

[...]

=E2=80=94 Section 4.2 =E2=80=94

What=E2=80=99s the use case for prioritising the mailboxid over the sp= ecial
use?  That also se= ems an odd choice, given the context of special use
mailboxes.  The combination just seems strange= =E2=80=94 I would normally
s= pecify *either* the special use of the mailbox *or* the name, but not
both.  Adding mailboxid to= that just adds more weirdness.

That's fair = - I would be willing to change the order there.  I expect that nobo= dy will do it, but I don't want to forbid it either, and I want to defin= e a fixed order that works the same across servers.

I will = write an email to the list about this particular issue, so it doesn't ge= t lost in this.
=
I ran into too much complexi= ty with this in the end.  It means we can't just say "follow the pr= ocess in the other doc" and instead have to create a big messy state mac= hine that replicates it - for no real benefit.

If you don= 't want delivery to stick with the mailboxid, then in this case you woul= d indeed create a rule that is just "fileinto by specialuse" and not spe= cify a mailboxid - so the only reason to specify the ID is if you wanted= to stick with the mailbox even if the specialuse was moved.  Maybe= it doesn't make sense to allow both, but I also don't think it hurts to= allow both, and having the ID bind more tightly is clean, because the I= D can never be moved to another mailbox.

Bron.
<= div style=3D"font-family:Arial;">
--
  Bron Gon= dwana, CEO, Fastmail Pty Ltd
  br= ong@fastmailteam.com

<= div style=3D"font-family:Arial;">
--476301d9189a49a8bd7b9193e11c07c4-- From nobody Sun Nov 1 21:03:11 2020 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 B6CAF3A0D66; Sun, 1 Nov 2020 21:03:09 -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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <160429338964.18165.3323101143890051522@ietfa.amsl.com> Date: Sun, 01 Nov 2020 21:03:09 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-mailboxid-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: Mon, 02 Nov 2020 05:03:10 -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: delivery by mailboxid Author : Bron Gondwana Filename : draft-ietf-extra-sieve-mailboxid-04.txt Pages : 10 Date : 2020-11-01 Abstract: The OBJECTID capability of the IMAP protocol (RFC8474) allows clients to identify mailboxes by a unique identifier which survives rename. This document extends the Sieve mail filtering language (RFC5228) to allow using that same unique identifier as a target for fileinto rules, and for testing the existance of mailboxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-extra-sieve-mailboxid-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-mailboxid-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 Mon Nov 2 12:29:35 2020 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 24E6E3A11D7; Mon, 2 Nov 2020 12:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 SoS61UgDbG_Z; Mon, 2 Nov 2020 12:29:33 -0800 (PST) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 6CB093A142D; Mon, 2 Nov 2020 12:28:29 -0800 (PST) Received: by mail-vs1-f46.google.com with SMTP id b129so8208425vsb.1; Mon, 02 Nov 2020 12:28:29 -0800 (PST) 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:content-transfer-encoding; bh=xzCF39mlF9j0BW0+p4Wt6vuqRiJmrV5vLBEfkfB7nlQ=; b=AL2PsLIzMjF8yj+njanBvO4oG+wht/uYLIgJSpTuO4QBrmom/HvEWDAmXG6K2Ld5eK Qoo8733BLllTJow5hRFe6QwtSXa9AaIAW+A9ACAwwbpD/7f7xI9aK0q+4UrEBvVvOPmW Rk1N9nPUhaoUEY9dsi3x/WfhCJDPetYVpxrIBY4xrWZxVXHAm3dLEla8iyofz7ZkCWIC +xB2MDTD5Zq327VqXaXjlWQVn3heUf+SUO0jxpStUyFjwLDqMXblHBJRqFpTYdI1ICKl pJXd+icGAZPV88RnneKALe9fztM7CB/fcfd1Zmj1I5Oy4WEFseapGKtSDT5Y3bQKHK7t F9uw== X-Gm-Message-State: AOAM531zKofCUrYHOeMbqBEyARzLe6IHG/ZyV/UToivs60pjxTl4P+z7 EQjrtQ4t9wuHmM2Q568pPq2aAmTkEF3k+mT/Ms4Pk4Hg8xw= X-Google-Smtp-Source: ABdhPJxPXte0W4/ObRDsdnehXFFEssJXgu9VHO6bGQIQZi84LxP0VBXQx/Wfvt9gRCYsNIlVfVFYpKvoR/nZG66ZcKA= X-Received: by 2002:a67:7908:: with SMTP id u8mr10160959vsc.9.1604348908261; Mon, 02 Nov 2020 12:28:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Mon, 2 Nov 2020 15:28:17 -0500 Message-ID: To: Bron Gondwana Cc: draft-ietf-extra-sieve-mailboxid.all@ietf.org, extra@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-sieve-mailboxid-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: Mon, 02 Nov 2020 20:29:34 -0000 I'm not sure what complexity you're talking about here. The real issue is that I don't see that it's meaningful in any way to specify both a special use and a mailbox ID. The mailbox ID is looking for a specific mailbox, and the special use is looking for whatever mailbox has the special use. It seems to me that they're contradictory options. So correct me here: what does it *mean* to specify both, and how does that make any sense? Once you allow specifying both, THEN you get into complexity because you're trying to make sense of something that simply doesn't make sense. Barry On Mon, Nov 2, 2020 at 12:00 AM Bron Gondwana wrot= e: > > On Mon, Sep 7, 2020, at 11:01, Bron Gondwana wrote: > > > > On Sat, Sep 5, 2020, at 03:23, Barry Leiba wrote: > > Here's my AD review of the subject document. I have some issues to > discuss about the specification, so please read my comments and let's > have the discussion. I'll set the substrate to "AD Followup". > > > [...] > > =E2=80=94 Section 4.2 =E2=80=94 > > What=E2=80=99s the use case for prioritising the mailboxid over the speci= al > use? That also seems an odd choice, given the context of special use > mailboxes. The combination just seems strange =E2=80=94 I would normally > specify *either* the special use of the mailbox *or* the name, but not > both. Adding mailboxid to that just adds more weirdness. > > > That's fair - I would be willing to change the order there. I expect tha= t nobody will do it, but I don't want to forbid it either, and I want to de= fine a fixed order that works the same across servers. > > I will write an email to the list about this particular issue, so it does= n't get lost in this. > > > I ran into too much complexity with this in the end. It means we can't j= ust say "follow the process in the other doc" and instead have to create a = big messy state machine that replicates it - for no real benefit. > > If you don't want delivery to stick with the mailboxid, then in this case= you would indeed create a rule that is just "fileinto by specialuse" and n= ot specify a mailboxid - so the only reason to specify the ID is if you wan= ted to stick with the mailbox even if the specialuse was moved. Maybe it d= oesn't make sense to allow both, but I also don't think it hurts to allow b= oth, and having the ID bind more tightly is clean, because the ID can never= be moved to another mailbox. > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > From nobody Tue Nov 17 03:15:13 2020 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 390673A1059; Tue, 17 Nov 2020 03:15: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: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <160561170815.2974.10328215031798938766@ietfa.amsl.com> Date: Tue, 17 Nov 2020 03:15:08 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-quota-03.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, 17 Nov 2020 11:15: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 : IMAP QUOTA Extension Author : Alexey Melnikov Filename : draft-ietf-extra-quota-03.txt Pages : 18 Date : 2020-11-17 Abstract: The QUOTA extension of the Internet Message Access Protocol (RFC 3501) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This memo obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-quota/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-quota-03 https://datatracker.ietf.org/doc/html/draft-ietf-extra-quota-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-quota-03 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 Wed Nov 18 00:04:18 2020 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 E131A3A0880; Wed, 18 Nov 2020 00:04:08 -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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Bron Gondwana , extra-chairs@ietf.org, The IESG , barryleiba@gmail.com, rfc-editor@rfc-editor.org, draft-ietf-extra-imap-fetch-preview@ietf.org, brong@fastmailteam.com, extra@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160568664883.561.7833208207958596785@ietfa.amsl.com> Date: Wed, 18 Nov 2020 00:04:08 -0800 Archived-At: Subject: [Extra] Protocol Action: 'IMAP4 Extension: Message Preview Generation' to Proposed Standard (draft-ietf-extra-imap-fetch-preview-10.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: Wed, 18 Nov 2020 08:04:09 -0000 The IESG has approved the following document: - 'IMAP4 Extension: Message Preview Generation' (draft-ietf-extra-imap-fetch-preview-10.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 Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ Technical Summary This spec extends IMAP with an additional fetch item (PREVIEW) which allows clients to obtain a short piece of text to use as a preview line in mailbox listings. Working Group Summary This document and fetch item was originally named "snippet", however JMAP uses "preview" for the equivalent field, and "snippet" for a marked up section of the message containing search terms, so the working group agreed to change the naming to be consistent. There was also debate over the maximum length, with both JMAP and EXTRA working groups settling on 256 characters maximum. Finally there were questions over whether "LAZY" was useful, but nobody saw any downside to including it. Servers can choose to always calculate the preview even if LAZY is given. There was a significant amount of rework through multiple meetings which led to a very complex document. In the end, the authors asked to drop the complexity and go back to an earlier version, which achieved working group consensus. Document Quality This spec is quite easy to implement - it has multiple examples for all the likely cases. It's been implemented in Dovecot and Cyrus IMAPd. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Barry Leiba RFC Editor Note Please make the following change to the second paragraph in Section 1: OLD Generation of a preview on the server has several benefits. First, it allows consistent representation of previews across all clients. This standardized display can reduce user confusion when using multiple clients, as abbreviated message representations in clients will show identical message contents. NEW Generation of a preview on the server has several benefits. First, it allows consistent representation of previews across all clients. While different clients might generate quite different preview text, having common preview text generated by the server can give a more consistent user experience to those who use multiple clients. From nobody Wed Nov 18 16:26:47 2020 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 E4B763A100E; Wed, 18 Nov 2020 16:26:45 -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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <160574560585.29566.4699228249066000638@ietfa.amsl.com> Date: Wed, 18 Nov 2020 16:26:45 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-mailboxid-05.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, 19 Nov 2020 00:26:46 -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: delivery by mailboxid Author : Bron Gondwana Filename : draft-ietf-extra-sieve-mailboxid-05.txt Pages : 10 Date : 2020-11-18 Abstract: The OBJECTID capability of the IMAP protocol (RFC8474) allows clients to identify mailboxes by a unique identifier which survives rename. This document extends the Sieve mail filtering language (RFC5228) to allow using that same unique identifier as a target for fileinto rules, and for testing the existance of mailboxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-extra-sieve-mailboxid-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-mailboxid-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 18 16:30:03 2020 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 CAFE73A101A for ; Wed, 18 Nov 2020 16:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=itV8EQNy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AzSVIn7k 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 6EIFCSWxRxJ2 for ; Wed, 18 Nov 2020 16:29:59 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239C13A1016 for ; Wed, 18 Nov 2020 16:29:59 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 43BBED72 for ; Wed, 18 Nov 2020 19:29:58 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 18 Nov 2020 19:29:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=vLWGQJVA7T2ZCZ1wcqmx6CR54N998VemYn5iwkH 60Go=; b=itV8EQNyRyfhjuB12fVPefUCj7dZUPGj45ubA+E6AAm4vhimwpRp0zw 2X9WHNjcna6ne2ermwqB663mIZkJ9tBVf84Y+4gcfOL3pXIZ5fW0ZT7N/+OQkwqx i7J99NdTnh01EJOmVvAhrAyMXiCrhUE5J4Gb+4FQNxQwD88Ali0lBUpCZa3rK9oC t5XcxTrafjWB36BfI7I1/pYzOCAjMOZRWbWgfBmWju5CCr3x4npyG4ykBkF/Avo+ C4xy1c3dxEg0yirOwGX4GEgd22rnQ8hG3WCfztrESacmfYYC/5+DU/fjEQXeUb8C ozrovMSpzoqS07MQjdM+fRf4Qrql5EA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=vLWGQJVA7T2ZCZ1wcqmx6CR54N998 VemYn5iwkH60Go=; b=AzSVIn7kyTF7vR9LfKp4KJW54/YAgihRJ4BxDTPBJpqEM d+gii+pK95yx2MOVMugSf+rXhm4v5tZeARUW/Ueg8Dt7Qn25oCylAQPNHoeSwo/4 ZUge++oF8cUUJ5C+fYt2VKDHsgWbMH7Zj8fHf90oScDGUw4OnYT06RdeDNahJzv2 fc9/R7ci9fNnuTqp+ar/ozirE9IC6yDHRfU3c/0CGL2npnldAkEDPsd9NcbkiQJz AzlUbwKYoCQSRqS3f1XETPqrljkZ61cMXebpSgnJgaku7DDnl26ejLemrmws9Ef3 LvrW5OtduoZB5Q1LpygTuVop4YB9z7rfh2aelzkfg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefiedgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedtleefgeduteethf ehgedtleevhfduudfhieejgeehtdeviedttdeugfegvdejheenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 65AE71802ED; Wed, 18 Nov 2020 19:29:57 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 x-forwarded-message-id: <160574560611.29566.8626322036951855192@ietfa.amsl.com> Message-Id: <34ac5155-4481-4abd-ab11-a52f14404020@dogfood.fastmail.com> Date: Thu, 19 Nov 2020 11:29:37 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=656f2d4eb4b04d168a7c626d5d87b3f8 Archived-At: Subject: [Extra] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-ietf?= =?utf-8?q?-extra-sieve-mailboxid-05=2Etxt?= 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, 19 Nov 2020 00:30:01 -0000 --656f2d4eb4b04d168a7c626d5d87b3f8 Content-Type: text/plain I've just uploaded a new version with the change we agreed upon in yesterday's meeting: 4.2. Interaction with "specialuse" extension For servers which also support [!@RFC8579] delivery to special-use mailboxes, it is an error to specify both ":mailboxid" and ":special-use" in the same fileinto command. Advanced filtering based on both special-use and mailboxid can be built with explicit "specialuse_exists" and "mailboxidexists" tests. Note to developers of sieve generation tools: it is advisable to use special-use rather than mailboxid when creating rules that are based on a special-use purpose (e.g. delivery directly to the Junk folder based on a header that was added by a scanning agent earlier in the mailflow). ... I'm not sure if we need to keep RFC8579 normative here, though I don't think it hurts. Any other feedback on wording happily received :) Cheers, Bron. ----- Original message ----- From: internet-drafts@ietf.org To: Bron Gondwana Subject: New Version Notification for draft-ietf-extra-sieve-mailboxid-05.txt Date: Thursday, November 19, 2020 11:26 A new version of I-D, draft-ietf-extra-sieve-mailboxid-05.txt has been successfully submitted by Bron Gondwana and posted to the IETF repository. Name: draft-ietf-extra-sieve-mailboxid Revision: 05 Title: Sieve Email Filtering: delivery by mailboxid Document date: 2020-11-19 Group: extra Pages: 10 URL: https://www.ietf.org/archive/id/draft-ietf-extra-sieve-mailboxid-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/ Html: https://www.ietf.org/archive/id/draft-ietf-extra-sieve-mailboxid-05.html Htmlized: https://tools.ietf.org/html/draft-ietf-extra-sieve-mailboxid-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-mailboxid-05 Abstract: The OBJECTID capability of the IMAP protocol (RFC8474) allows clients to identify mailboxes by a unique identifier which survives rename. This document extends the Sieve mail filtering language (RFC5228) to allow using that same unique identifier as a target for fileinto rules, and for testing the existance of mailboxes. 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. The IETF Secretariat -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --656f2d4eb4b04d168a7c626d5d87b3f8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I've just uploaded a new version with the change we agreed= upon in yesterday's meeting:

4.2. Interaction with = "specialuse" extension

For servers w= hich also support [!@RFC8579] delivery to special-use mailboxes, it is an error to specify both ":mailboxid" and ":special-use" in the sa= me fileinto command.

Advanced filtering based on both special-u= se and mailboxid can be built with explicit "specialuse_exists" and "mailboxidexists" tests.
=

Note to developers of sieve generation tools: it is advisabl= e to use special-use rather than mailboxid when creating rules that are based on a special-use purpose (e.g. delivery directly to the Junk folder based on a header that was added by a scanning agent earlier in the mailflow).


...

I'm not sure if we need to keep= RFC8579 normative here, though I don't think it hurts.  Any other = feedback on wording happily received :)

Cheers,

Bron.

<= div style=3D"font-family:Arial;">
----- Original message -= ----
To: Bron Gondwana <brong@fastmailteam.com>
<= /div>
Subject: New Version Notification for draft-ietf-extra-sieve-m= ailboxid-05.txt
Date: Thursday, November 19, 2020 11:26


A ne= w version of I-D, draft-ietf-extra-sieve-mailboxid-05.txt
has been successfully submitted by Bron Gon= dwana and posted to the
IETF = repository.

Name: draft-ietf-extra-sieve-mailboxid
Revision: 05
Title: Sieve Email Filtering: delivery by mailboxi= d
Document date: 2020-11-19
Group: extra
Pages: 10
= Status:         http= s://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/
=

Abstract:
   = The OBJECTID capability of the IMAP protocol (RFC8474) allows clients
   to identify mailbo= xes by a unique identifier which survives rename.

 &= nbsp; This document extends the Sieve mail filtering language (RFC5228) = to
   allow using t= hat same unique identifier as a target for fileinto
   rules, and for testing the existance o= f mailboxes.

       &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;  


Please note that it may take a couple of minutes from the time of su= bmission
until the htmlized v= ersion and diff are available at tools.ietf.org.

The IETF= Secretariat


=

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

--656f2d4eb4b04d168a7c626d5d87b3f8-- From nobody Wed Nov 18 16:59:03 2020 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 5ECF63A106D; Wed, 18 Nov 2020 16:59:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bron Gondwana via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org Message-ID: <160574754031.9455.10787367467158737545@ietfa.amsl.com> Date: Wed, 18 Nov 2020 16:59:00 -0800 Archived-At: Subject: [Extra] Publication has been requested for draft-ietf-extra-imap4rev2-20 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, 19 Nov 2020 00:59:00 -0000 Bron Gondwana has requested publication of draft-ietf-extra-imap4rev2-20 as Proposed Standard on behalf of the EXTRA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ From nobody Wed Nov 18 17:02:38 2020 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 5C3593A108E for ; Wed, 18 Nov 2020 17:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=LqFXxVPC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XG/X05t0 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 aS_fW2xJjKCg for ; Wed, 18 Nov 2020 17:02:34 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927A93A1086 for ; Wed, 18 Nov 2020 17:02:34 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id DBEC5D6D for ; Wed, 18 Nov 2020 20:02:33 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 18 Nov 2020 20:02:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=safcpQj35SKE7kdZvCIxSDQu7DYj08rtD0LoNva C+G4=; b=LqFXxVPCP/0iT7v1gRYJ5jvNXdI4HrsmmqxeC2iVuMFzX2dCsEEPw0U B228iJngJdUBxWmqhYpTV+cYiSI2zDFRxtVFEIxl8+HyV21wLrAUdcixuvdpio3h FgoqJH+OqAjifhOhiUx2rK+49XkxwDXbH5vJ2qYgTjAgz8YsG8y8TQNC5JostYgG 6+pwYkxIvhxEPwXk4FgZuowuznHzEAV9cuoz5KvG8cI131ALtBG6mPK9vy5eN8an tw8maBXvvRG7l42SruVJgVZKxQf8Iq+8KI22DPb06iORUuyBzj6wwcKBC1ML58cJ pv/RqvBG9F9RHhWjmxZCF6cESPdIc+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=safcpQj35SKE7kdZvCIxSDQu7DYj0 8rtD0LoNvaC+G4=; b=XG/X05t0odBMYCcHqG7iCbKGAtqhwgtg8zWWOpTDVv1uB 6WNDF3jCgGFSz15kkRY10eg8iwSDpgxy6bNgGvhICOz2k1bNCIN2LRmuk2ySlEk8 VxW3wDjyr7P4yOrn3PiP3+3aVw7iBr0Zn+RbLMUvtXo6IFuhoOBH4/x+MLnNGgor aBB2G/4egIjrzpCocRtvuXQo5ys7wzsCDn5hljUI8m58W5RBRuyFIb9No6yexQI5 E+g3+8qCIAVSaOMJz2C12DLoXxxJtqioCTC6DGKg6t9bABDmevUtuo389Qg/vo2p cvn5i9qv9X2IzngYG5+JQckChqNG0p0iGdb9ePbzw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefiedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0CA631802ED; Wed, 18 Nov 2020 20:02:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: Date: Thu, 19 Nov 2020 12:02:12 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=b978ef54933b408a86e19fcf14a8d2b0 Archived-At: Subject: [Extra] Working Group Last Call: quota 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, 19 Nov 2020 01:02:36 -0000 --b978ef54933b408a86e19fcf14a8d2b0 Content-Type: text/plain Hi all, This message starts a 2 week working group last call for: https://datatracker.ietf.org/doc/draft-ietf-extra-quota/ NOTE: there is an action item to remove the 'OVERQUOTA SP tag' construction, per discussion at IETF109. I have tagged the document with "revised ID needed" in the datatracker. Please provide feedback by December 4th. Regards, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --b978ef54933b408a86e19fcf14a8d2b0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

This message starts a 2 week workin= g group last call for:


<= /div>
NOTE: there is an action item to = remove the 'OVERQUOTA SP tag' construction, per discussion at IETF109.&n= bsp; I have tagged the document with "revised ID needed" in the datatrac= ker.

Please provide feedback by December 4th.

Regards,

Bron.

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


--b978ef54933b408a86e19fcf14a8d2b0-- From nobody Wed Nov 18 17:06:10 2020 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 2C77B3A109B for ; Wed, 18 Nov 2020 17:06:09 -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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160574796916.24987.11031230155773069596@ietfa.amsl.com> Date: Wed, 18 Nov 2020 17:06:09 -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, 19 Nov 2020 01:06:09 -0000 Changed milestone "Adopt a sieve-snooze document", resolved as "Done". Changed milestone "Submit sieve-mailboxid to the IESG as a proposed standard", resolved as "Done". Changed milestone "Submit "IMAP4rev2" to IESG as a Proposed Standard", set due date to November 2020 from September 2020, resolved as "Done". Changed milestone "Adopt a document for EAI with Sieve", set due date to December 2020 from August 2020. Changed milestone "Update charter to reflect current and planned work", set due date to March 2021 from December 2020. Changed milestone "Submit Sieve EAI to IESG", set due date to March 2021 from December 2020. URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Wed Nov 18 17:07:47 2020 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 426C63A109E for ; Wed, 18 Nov 2020 17:07:45 -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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160574806525.6321.1320216815886790455@ietfa.amsl.com> Date: Wed, 18 Nov 2020 17:07:45 -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, 19 Nov 2020 01:07:45 -0000 Changed milestone "Adopt a document creating a sieve actions registry", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Wed Nov 18 18:12:05 2020 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 BD2AB3A0836 for ; Wed, 18 Nov 2020 18:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=oaRmBSk2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A0tkNCGD 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 IYjDikqjDe7l for ; Wed, 18 Nov 2020 18:11:59 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9B33A0822 for ; Wed, 18 Nov 2020 18:11:59 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id D14928D5; Wed, 18 Nov 2020 21:11:58 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 18 Nov 2020 21:11:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=JLmQ TGtb53gQDPvrIzfofoZYK0Tt5I3F7upgWQE923Y=; b=oaRmBSk2RbJKxO8L3GDP b6B6OdUG2hTmLwZ+TklPboN6VNqiPR/QfKqotylfqBhoUuOJAe7p8X0lmoT/T9wn c2JDqEy6+kZTQR1JUAZhIuyfP1biRBz/rd5EDxxnxwmGIZS69pZqtbakW3LpEKws 2BwRYgmT85cuyx+ZgZ8iSo4vfNVptldhi0vOl0DSPUv1PGmL9iLKtls4YKYJ+PhD u4et7cjRJMmG4nJmO421Z5gW+vTfXDThNTjFh0REd1iSemKEJ0En6+M2QJH77qWa EASti5r0fmiC0ZWdrqgDqeFGYmQxT+7fYACU+1mPj9oK3UsNA+Agz2CRc7qp7v6O KA== 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=JLmQTG tb53gQDPvrIzfofoZYK0Tt5I3F7upgWQE923Y=; b=A0tkNCGDROhiZmwWqQAOi0 47Hb7jp40jnd4tib1QaOEZmthRjlKEO0r7KQZZUm107iTUrbeN1Xj2c3am0UIDxy XBaVfLfWs0npUcJ+qh41TFpoYiQATlKln0aEQIeSCmwjaBbLiuXJP7uF8QQIKquO XUCQxngmZEKNzg79b7C+mJm/zHxRnSBGxtXSh4wpWQKB9Q1UQDohLvb3pQ+b5dc1 HKg+SeRC8TrYvneXkO9SZxL4mMUnacAGabrwZlBiid7zfm94W5Ahq24TtayysyzX fOtjo4U42Bn3k6r7mFXBWUWZXdXIG9ZLLkfxGzgihWNBOSK2LvHXnhbWv0eLNsFQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefiedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepffevfeeigfejveetheehleegteelteevgeeutdfhhefg hfdtjefhvdehhfdtkefgnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F02961802D3; Wed, 18 Nov 2020 21:11:57 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <8577aa36-4d91-4aeb-adf2-93cfed735b52@dogfood.fastmail.com> In-Reply-To: References: <67511f7a-b273-4b0b-a874-9be5542c5eaa@beta.fastmail.com> Date: Thu, 19 Nov 2020 13:11:32 +1100 From: "Bron Gondwana" To: extra@ietf.org Cc: "Stephan Bosch" Content-Type: multipart/alternative; boundary=4f663cad0a4745b8bc83ab00cd600452 Archived-At: Subject: Re: [Extra] EAI 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, 19 Nov 2020 02:12:04 -0000 --4f663cad0a4745b8bc83ab00cd600452 Content-Type: text/plain I've bumped the milestones for this document out into early next year, but it's also expired! Stephan, are you able to upload again as -01 and I'll issue a formal call for adoption, which I see I forgot to do earlier in the year. Thanks, Bron. On Sun, Mar 22, 2020, at 05:29, Stephan Bosch wrote: > Hi, > > On 17/01/2020 05:51, Bron Gondwana wrote: > > Hi Stephan, > > > > According to the minutes from the EXTRA session in Singapore, you have > > been volunteered to write a Sieve EAI spec. Can you please upload it if > > you have one, or write one, or let us know not to expect it if you've > > changed your mind. > > > > It is very much a draft document with lots of holes, but it should > provide enough content for discussion and feedback: > > A new version of I-D, draft-bosch-sieve-eai-00.txt > has been successfully submitted by Stephan Bosch and posted to the > IETF repository. > > Name: draft-bosch-sieve-eai > Revision: 00 > Title: Sieve: Internationalized Email > Document date: 2020-03-21 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/internet-drafts/draft-bosch-sieve-eai-00.txt > Status: https://datatracker.ietf.org/doc/draft-bosch-sieve-eai/ > Htmlized: https://tools.ietf.org/html/draft-bosch-sieve-eai-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bosch-sieve-eai > > > Abstract: > This document defines an extension to the Sieve language called "eai" > which adds full support for internationalized email. > > > Regards, > > Stephan. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --4f663cad0a4745b8bc83ab00cd600452 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I've bumped the milestones for this document out into= early next year, but it's also expired!  Stephan, are you able to = upload again as -01 and I'll issue a formal call for adoption, which I s= ee I forgot to do earlier in the year.

Thanks,
<= div style=3D"font-family:Arial;">
Bron.

On Sun, Mar 22, 2020, at 05:29, Stephan Bos= ch wrote:
Hi,

On 17/01/2020 05:51, Bron= Gondwana wrote:
> Hi Step= han,
> 
> According to the minutes from the EXT= RA session in Singapore, you have 
> been volunteered to write a Sieve EAI spec.  Can yo= u please upload it if 
&= gt; you have one, or write one, or let us know not to expect it if you'v= e 
> changed your min= d.
> 

= It is very much a draft document with lots of holes, but it should =
provide enough content for d= iscussion and feedback:

<= /div>
A new version of I-D, draft-bosch= -sieve-eai-00.txt
has been su= ccessfully submitted by Stephan Bosch and posted to the
IETF repository.

Name: draft-= bosch-sieve-eai
Revision: 00<= br>
Title: Sieve: Internationali= zed Email
Document date: 2020= -03-21
Group: Individual Sub= mission
Pages: 8
URL: 


Abstract:
    This document defines an extension to= the Sieve language called "eai"
    which adds full support for internationalized ema= il.


Regards,<= br>

Stephan.

<= /div>
_________________________________= ______________
Extra mailing = list


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


--4f663cad0a4745b8bc83ab00cd600452-- From nobody Wed Nov 18 22:12:22 2020 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 A754F3A0E51; Wed, 18 Nov 2020 22:12:20 -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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk CC: barryleiba@gmail.com, yaojk@cnnic.cn, Jiankang Yao , extra@ietf.org, draft-ietf-extra-sieve-mailboxid@ietf.org, extra-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160576634067.18013.16969656855328043620@ietfa.amsl.com> Date: Wed, 18 Nov 2020 22:12:20 -0800 Archived-At: Subject: [Extra] Last Call: (Sieve Email Filtering: delivery by mailboxid) to Proposed Standard 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, 19 Nov 2020 06:12:21 -0000 The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'Sieve Email Filtering: delivery by mailboxid' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The OBJECTID capability of the IMAP protocol (RFC8474) allows clients to identify mailboxes by a unique identifier which survives rename. This document extends the Sieve mail filtering language (RFC5228) to allow using that same unique identifier as a target for fileinto rules, and for testing the existance of mailboxes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Nov 23 07:31:30 2020 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 3ADC23A064E; Mon, 23 Nov 2020 07:31:25 -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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <160614548512.5323.12299256975089876617@ietfa.amsl.com> Date: Mon, 23 Nov 2020 07:31:25 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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: Mon, 23 Nov 2020 15:31:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Internet Message Access Protocol (IMAP) - Version 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-21.txt Pages : 163 Date : 2020-11-23 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-21 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 Mon Nov 23 07:39:31 2020 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 141DC3A0763 for ; Mon, 23 Nov 2020 07:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBPGjwDXr_nI for ; Mon, 23 Nov 2020 07:39:29 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D3B4E3A07A0 for ; Mon, 23 Nov 2020 07:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1606145967; d=isode.com; s=june2016; i=@isode.com; bh=+l3R54yF6ehcGFbYVUHWj/mC9n0JIqXdDfyytO5ipeU=; 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=u1LsU7Gy/sokiNrpH49FXV/H6IWfAcZIyJgQw/IamH6Q/5PrhWn46V9O58UzqiLmz9K55v lCGqfMx6V4GWSuh7HUdYdTBJzwDuB2Frs1Xo8oQ+7ML7sGq/aMW5/FciibvCxnLnR0kjRW fpitTs/iXXlBn41Th7WKlCVF9VSUmHo=; Received: from [172.27.255.65] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 23 Nov 2020 15:39:27 +0000 To: extra@ietf.org References: <160614548512.5323.12299256975089876617@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> Date: Mon, 23 Nov 2020 15:39:26 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 In-Reply-To: <160614548512.5323.12299256975089876617@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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, 23 Nov 2020 15:39:30 -0000 On 23/11/2020 15:31, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-21 This version adds support for 63bit body part and message sizes. From nobody Mon Nov 23 07:45:36 2020 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 A18A63A07D3 for ; Mon, 23 Nov 2020 07:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, 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 Y4VR_OWF7GcT for ; Mon, 23 Nov 2020 07:45:32 -0800 (PST) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 90F033A07CE for ; Mon, 23 Nov 2020 07:45:32 -0800 (PST) Received: from [10.105.241.6] (unknown [194.204.11.145]) by sirainen.com (Postfix) with ESMTPSA id 4F3E92B3CE6; Mon, 23 Nov 2020 15:45:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Timo Sirainen In-Reply-To: <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> Date: Mon, 23 Nov 2020 17:45:26 +0200 Cc: extra@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9A5617DC-91B7-443A-80AE-AA1E24558FDE@sirainen.com> References: <160614548512.5323.12299256975089876617@ietfa.amsl.com> <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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, 23 Nov 2020 15:45:35 -0000 On 23. Nov 2020, at 17.39, Alexey Melnikov = wrote: >=20 > On 23/11/2020 15:31, internet-drafts@ietf.org wrote: >=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21 >> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap4rev2-21 >=20 > This version adds support for 63bit body part and message sizes. Hiding large messages from rev1 sounds a bit bad. Better would be to = replace the message with some template body, which could either explain = that this message is too large for the client or simply be an empty body = and let the user figure it out themselves. From nobody Mon Nov 23 08:05:30 2020 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 32C163A03F3 for ; Mon, 23 Nov 2020 08:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 2CHK_waqwyYF for ; Mon, 23 Nov 2020 08:05:26 -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 957163A03F2 for ; Mon, 23 Nov 2020 08:05:26 -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 40E96C004E; Mon, 23 Nov 2020 16:11:59 +0000 (GMT) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1606147919; bh=oOtpNxTcls9mRcebsEJKH5pcTwT2Fpnis7SSIXKf/Mg=; h=From:To:Subject:Date:References:From; b=gRs0NKC/Khq6LB93NSgjcnTG5A0whimIgd/GuaqzdJG2n2d9leAy1JrnMPE59MBX4 YH1zKEdQSMRCfUgn66PBwAok7Tac8dDbOvMJdFUYHH9Uo05pgKz8dUjzZaO9zkRGew lW9IgFltHplx6QeqTKVgtE05VTC3xTMFELcpcuKk= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1606147918-28185-28182/10/5101; Mon, 23 Nov 2020 16:11:58 +0000 From: Arnt Gulbrandsen To: extra@ietf.org, Alexey Melnikov Date: Mon, 23 Nov 2020 17:05:18 +0100 Message-Id: References: <160614548512.5323.12299256975089876617@ietfa.amsl.com> <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> <9A5617DC-91B7-443A-80AE-AA1E24558FDE@sirainen.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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, 23 Nov 2020 16:05:28 -0000 Imo a server that supports r1 cannot support a maximum size larger than... 2G? 4G? Which should be plenty for the moment. Senders cannot trust receivers to accept even 100M today, so supporting twenty times that is fine for a while. Practically speaking, all that r2 does is change the syntax, so that a too-large literal is too large instead of being a syntax error. Arnt From nobody Mon Nov 23 08:21:57 2020 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 905AB3A0420 for ; Mon, 23 Nov 2020 08:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.com header.b=kKKVkPar; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n5s7u6KM 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 PyA8QdW6poCn for ; Mon, 23 Nov 2020 08:21:54 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9743A0A00 for ; Mon, 23 Nov 2020 08:21:47 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0C46018CF for ; Mon, 23 Nov 2020 11:21:46 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 23 Nov 2020 11:21:47 -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:content-transfer-encoding; s=fm1; bh=h up0TCrBGd+uc0ZyoewGZtoF6zrFJaOh/KSMU9ZXu0I=; b=kKKVkPar8WnVx04q1 awyFWzKogYywUlaY1R913AvbO7ZE1XJMpiqDGhlLjyizeaFNhygKHnRKPBanOOMH 8ECX3Dk2iVz6HYWsDJvR/U2sdHiTpxPlP5oSRKlOERWjcyKZ6fOipPV7awdR7mZ5 kskH2w5wht6Nkhk6JwCMp5QhvNAtdlK+8cmt2wWvn7Y/IZpxPMeEEUetSQIEiw1d 5nQn2+SZ1u7wLBobwfnP2+iwfrvRrg2iDeb6G+OE3Uultg3h4qBCQzjsFBKNkk94 NwBDZHpVDWpXa0FPSHYpTPBwRVriKoUKX0gcaJ90uxEk70NY663t8/SgqJAzyDi+ jEE7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=hup0TCrBGd+uc0ZyoewGZtoF6zrFJaOh/KSMU9ZXu 0I=; b=n5s7u6KMKZNlCdBQLyma4P3k2w/8tVMQ1fJdrSIabrFs/eSADfSw1XKLb Ydzfv9VQ7eojaq+IGXL6uckBCLbq/TiU38dm3jMvilSBib8FBzAxz8oPAPzcekmW M6Sd6d49RMnED4m5ILR3Yf27pp3dT7cO+cRHMyJIU3T58dDHXyAv9h2vjjNDl9ri 4W1IasQiQnyCL2QfS/seURYuxBe68184ArAZ4/KTwtrWXFt7Wdv4pfwR2uglG4Nw KxvKHWzKU19OJfpwYj5SSvf9z4H+eB0jwGCH4OyQxFMyBeuvcNSYol73ec1PAOH4 AbtRwAmGCj6dVfLvJ4qpgsLjwCQ8Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegiedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpedvueetudegieffieetvdfhie dutedvgeejkeekudetvddvvdduteejvefghfdvkeenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 6378D3280060 for ; Mon, 23 Nov 2020 11:21:46 -0500 (EST) To: extra@ietf.org References: <160614548512.5323.12299256975089876617@ietfa.amsl.com> <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> <9A5617DC-91B7-443A-80AE-AA1E24558FDE@sirainen.com> From: Ken Murchison Message-ID: <9fbd8db1-b3ed-c133-5d0f-77cd939c95c1@fastmail.com> Date: Mon, 23 Nov 2020 11:21:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <9A5617DC-91B7-443A-80AE-AA1E24558FDE@sirainen.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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, 23 Nov 2020 16:21:57 -0000 On 11/23/20 10:45 AM, Timo Sirainen wrote: > On 23. Nov 2020, at 17.39, Alexey Melnikov wrote: >> On 23/11/2020 15:31, internet-drafts@ietf.org wrote: >> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21 >>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-21 >> This version adds support for 63bit body part and message sizes. > Hiding large messages from rev1 sounds a bit bad. Better would be to replace the message with some template body, which could either explain that this message is too large for the client or simply be an empty body and let the user figure it out themselves. Presumably a message that exceeds the 32-bit limit contains one or more attachments that pushes it over the limit.  Perhaps the server could synthesize a message for IMAPrev1 clients that replaces large attachments with message/external-body parts. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Mon Nov 23 08:36:07 2020 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 6D91D3A09A4 for ; Mon, 23 Nov 2020 08:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 WcOO-TejRHpl for ; Mon, 23 Nov 2020 08:36:04 -0800 (PST) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD333A09D7 for ; Mon, 23 Nov 2020 08:36:03 -0800 (PST) Received: from [10.105.241.6] (unknown [194.100.26.110]) by sirainen.com (Postfix) with ESMTPSA id 8AEC82B3CE6 for ; Mon, 23 Nov 2020 16:36:02 +0000 (UTC) From: Timo Sirainen Content-Type: multipart/alternative; boundary="Apple-Mail=_9F9749D8-4865-46F6-9543-301813C8F91E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Mon, 23 Nov 2020 18:36:00 +0200 References: <160614548512.5323.12299256975089876617@ietfa.amsl.com> <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> <9A5617DC-91B7-443A-80AE-AA1E24558FDE@sirainen.com> <9fbd8db1-b3ed-c133-5d0f-77cd939c95c1@fastmail.com> To: extra@ietf.org In-Reply-To: <9fbd8db1-b3ed-c133-5d0f-77cd939c95c1@fastmail.com> Message-Id: X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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, 23 Nov 2020 16:36:06 -0000 --Apple-Mail=_9F9749D8-4865-46F6-9543-301813C8F91E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23. Nov 2020, at 18.21, Ken Murchison wrote: >=20 >=20 > On 11/23/20 10:45 AM, Timo Sirainen wrote: >> On 23. Nov 2020, at 17.39, Alexey Melnikov = wrote: >>> On 23/11/2020 15:31, internet-drafts@ietf.org wrote: >>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ >>>>=20 >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap4rev2-21 >>> This version adds support for 63bit body part and message sizes. >> Hiding large messages from rev1 sounds a bit bad. Better would be to = replace the message with some template body, which could either explain = that this message is too large for the client or simply be an empty body = and let the user figure it out themselves. >=20 >=20 > Presumably a message that exceeds the 32-bit limit contains one or = more attachments that pushes it over the limit. Perhaps the server = could synthesize a message for IMAPrev1 clients that replaces large = attachments with message/external-body parts. My suggestion would be to just leave this implementation-defined, rather = than recommending anything specific. --Apple-Mail=_9F9749D8-4865-46F6-9543-301813C8F91E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 23. Nov 2020, at 18.21, Ken Murchison <murch@fastmail.com> = wrote:


On 11/23/20 10:45 AM, Timo Sirainen wrote:
On = 23. Nov 2020, at 17.39, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
On 23/11/2020 15:31, internet-drafts@ietf.org wrote:

The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21
https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev= 2-21

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap4rev2-= 21
This version adds support for 63bit body = part and message sizes.
Hiding large messages = from rev1 sounds a bit bad. Better would be to replace the message with = some template body, which could either explain that this message is too = large for the client or simply be an empty body and let the user figure = it out themselves.


Presumably a message that exceeds the 32-bit limit contains = one or more attachments that pushes it over the limit.  Perhaps the = server could synthesize a message for IMAPrev1 clients that replaces = large attachments with message/external-body parts.

My = suggestion would be to just leave this implementation-defined, rather = than recommending anything specific.

= --Apple-Mail=_9F9749D8-4865-46F6-9543-301813C8F91E-- From nobody Mon Nov 23 08:45:47 2020 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 36A2E3A0BB2 for ; Mon, 23 Nov 2020 08:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lEJUP9VKJiz for ; Mon, 23 Nov 2020 08:45:44 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0D63A0B3B for ; Mon, 23 Nov 2020 08:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1606149941; d=isode.com; s=june2016; i=@isode.com; bh=YqKvEAKyHjyTGuiqEf/5RoSizD3nSAJZm9tYnswR5qU=; 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=MqLcQxmzUFEVLngaSa909Ld1kjwnnGj9sndW4eJMvljjoGOqV4aDtjBs5ECPWPfcllAW66 9NUd0DLCRS6nn2wzg8FUKkhGIjrbbiviw0kG3zZDmewTWvNQq31gqISGMM1lR0Difn6DtN OFEqKhDkFCvpkvu2+E5ZBWVmwEaV/t8=; Received: from [172.27.255.65] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 23 Nov 2020 16:45:41 +0000 To: Timo Sirainen , extra@ietf.org References: <160614548512.5323.12299256975089876617@ietfa.amsl.com> <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> <9A5617DC-91B7-443A-80AE-AA1E24558FDE@sirainen.com> <9fbd8db1-b3ed-c133-5d0f-77cd939c95c1@fastmail.com> From: Alexey Melnikov Message-ID: <206ae981-f8d0-897c-a95c-5b102a216f06@isode.com> Date: Mon, 23 Nov 2020 16:45:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000B10E69A027601F4894A49" Content-Language: en-GB Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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, 23 Nov 2020 16:45:46 -0000 --------------000B10E69A027601F4894A49 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable On 23/11/2020 16:36, Timo Sirainen wrote: > On 23. Nov 2020, at 18.21, Ken Murchison > wrote: >> >> >> On 11/23/20 10:45 AM, Timo Sirainen wrote: >>> On 23. Nov 2020, at 17.39, Alexey Melnikov=20 >>> > wrote: >>>> On 23/11/2020 15:31, internet-drafts@ietf.org=20 >>>> wrote: >>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/=20 >>>>> >>>>> >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21 >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap4rev2-21 >>>> This version adds support for 63bit body part and message sizes. >>> Hiding large messages from rev1 sounds a bit bad. Better would be to=20 >>> replace the message with some template body, which could either=20 >>> explain that this message is too large for the client or simply be=20 >>> an empty body and let the user figure it out themselves. >> >> >> Presumably a message that exceeds the 32-bit limit contains one or=20 >> more attachments that pushes it over the limit.=A0 Perhaps the server=20 >> could synthesize a message for IMAPrev1 clients that replaces large=20 >> attachments with message/external-body parts. > > My suggestion would be to just leave this implementation-defined,=20 > rather than recommending anything specific. Are there choices that we should advise against? Maybe message truncation? --------------000B10E69A027601F4894A49 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

On 23/11/2020 16:36, Timo Sirainen wrote:

On 23. Nov 2020, at 18.21, Ken Murchison <murch@fastmail.com> wrote:


On 11/23/20 10:45 AM, Timo Sirainen wrote:
On 23. Nov 2020, at 17.39, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
On 23/11/2020 15:31, internet-drafts@ietf.org wrote:

The IETF datatracker status page for this draft is:
https://datatracker.= ietf.org/doc/draft-ietf-extra-imap4rev2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-extra-imap4= rev2-21
https://datatracker.ietf.org/doc/html/dr= aft-ietf-extra-imap4rev2-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-extra-imap4rev2-21
This version adds support for 63bit body part and message sizes.
Hiding large messages from rev1 sounds a bit bad. Better would be to replace the message with some template body, which could either explain that this message is too large for the client or simply be an empty body and let the user figure it out themselves.


Presumably a message that exceeds the 32-bit limit contains one or more attachments that pushes it over the limit.=A0 Perhaps the server could synthesize a message for IMAPrev1 clients that replaces large attachments with message/external-body parts.

My suggestion would be to just leave this implementation-defined, rather than recommending anything specific.

Are there choices that we should advise against? Maybe message truncation?


--------------000B10E69A027601F4894A49-- From nobody Wed Nov 25 05:31:25 2020 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 618783A12AE for ; Wed, 25 Nov 2020 05:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 NQRFCLSEFiii for ; Wed, 25 Nov 2020 05:31:21 -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 462D93A129E for ; Wed, 25 Nov 2020 05:31:19 -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 65DDAC01EB; Wed, 25 Nov 2020 13:37:52 +0000 (GMT) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1606311472; bh=3gLMPO7BcawsS0WTdhjwnoyLmJtiLl2G3hE6Ml4hnMY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Rk9a6xOQQ97M4ziUGoCb49wQKbwQcAsY/B2O6N5t0mPpnMzUlN3NwiinQV7KBBb2m mFa9LAn6KVl191ltilGbDrnj23EJUe5DlUB4CZhiLEd8e7hTYIl+2RkfS+7wv7mzbf BkeFE/kj15rNJA2wgGE007i/PRhnQcau9NI+jKNc= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1606311471-28185-28182/9/5; Wed, 25 Nov 2020 13:37:51 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Wed, 25 Nov 2020 14:50:36 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: <206ae981-f8d0-897c-a95c-5b102a216f06@isode.com> References: <160614548512.5323.12299256975089876617@ietfa.amsl.com> <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> <9A5617DC-91B7-443A-80AE-AA1E24558FDE@sirainen.com> <9fbd8db1-b3ed-c133-5d0f-77cd939c95c1@fastmail.com> <206ae981-f8d0-897c-a95c-5b102a216f06@isode.com> User-Agent: Trojita/0.7; Qt/5.11.3; xcb; Linux; Devuan GNU/Linux 3 (beowulf) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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: Wed, 25 Nov 2020 13:31:23 -0000 On Monday 23 November 2020 17:45:40 CET, Alexey Melnikov wrote: > Are there choices that we should advise against? Maybe message = truncation? IMO: "Note that the syntaxes for SMTP/LMTP, IMAP4rev1 and IMAP4rev2 all=20 have different ranges for message size. Implementers are advised to=20 restrict their software's suported range to conform to all relevant=20 protocols, and to fail gracefully in case a message is too large." (SMTP's limit is.... hm.... 10=C2=B2=E2=81=B0 bytes, or about 10=E2=81=B5= =E2=81=B0=E2=81=B0, or maybe =E2=88=9E. Wow.) Arnt From nobody Wed Nov 25 05:47:48 2020 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 0827F3A138F for ; Wed, 25 Nov 2020 05:47:47 -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, 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 7p9k0Az2gnx5 for ; Wed, 25 Nov 2020 05:47:45 -0800 (PST) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id B58FE3A138B for ; Wed, 25 Nov 2020 05:47:44 -0800 (PST) Received: from [10.97.19.189] (unknown [89.18.105.226]) by sirainen.com (Postfix) with ESMTPSA id D9CAB2B3CE6; Wed, 25 Nov 2020 13:47:42 +0000 (UTC) From: Timo Sirainen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F29EADFD-24C0-4DBE-A084-81DBD9067461" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Wed, 25 Nov 2020 14:47:41 +0100 In-Reply-To: <206ae981-f8d0-897c-a95c-5b102a216f06@isode.com> Cc: extra@ietf.org To: Alexey Melnikov References: <160614548512.5323.12299256975089876617@ietfa.amsl.com> <633f53e8-f9b0-4960-c88b-6c074882438f@isode.com> <9A5617DC-91B7-443A-80AE-AA1E24558FDE@sirainen.com> <9fbd8db1-b3ed-c133-5d0f-77cd939c95c1@fastmail.com> <206ae981-f8d0-897c-a95c-5b102a216f06@isode.com> X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-21.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: Wed, 25 Nov 2020 13:47:47 -0000 --Apple-Mail=_F29EADFD-24C0-4DBE-A084-81DBD9067461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 23. Nov 2020, at 17.45, Alexey Melnikov = wrote: >=20 > On 23/11/2020 16:36, Timo Sirainen wrote: >=20 >> On 23. Nov 2020, at 18.21, Ken Murchison > wrote: >>>=20 >>>=20 >>> On 11/23/20 10:45 AM, Timo Sirainen wrote: >>>> On 23. Nov 2020, at 17.39, Alexey Melnikov = > wrote: >>>>> On 23/11/2020 15:31, internet-drafts@ietf.org = wrote: >>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ = >>>>>>=20 >>>>>> There are also htmlized versions available at: >>>>>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21 = >>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21 = >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap4rev2-21 = >>>>> This version adds support for 63bit body part and message sizes. >>>> Hiding large messages from rev1 sounds a bit bad. Better would be = to replace the message with some template body, which could either = explain that this message is too large for the client or simply be an = empty body and let the user figure it out themselves. >>>=20 >>>=20 >>> Presumably a message that exceeds the 32-bit limit contains one or = more attachments that pushes it over the limit. Perhaps the server = could synthesize a message for IMAPrev1 clients that replaces large = attachments with message/external-body parts. >>=20 >> My suggestion would be to just leave this implementation-defined, = rather than recommending anything specific. > Are there choices that we should advise against? Maybe message = truncation? >=20 I don't really have an opinion on this. I think even message truncation = might be acceptable in some situations. --Apple-Mail=_F29EADFD-24C0-4DBE-A084-81DBD9067461 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 23. Nov 2020, at 17.45, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On 23/11/2020 16:36, Timo Sirainen wrote:

On 23. Nov 2020, at 18.21, Ken Murchison <murch@fastmail.com> wrote:


On 11/23/20 10:45 AM, Timo Sirainen wrote:
On 23. Nov 2020, at 17.39, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
On 23/11/2020 15:31, internet-drafts@ietf.org wrote:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-21
https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-21
This version adds support for 63bit body part and message sizes.
Hiding large messages from rev1 sounds a bit bad. Better would be to replace the message with some template body, which could either explain that this message is too large for the client or simply be an empty body and let the user figure it out themselves.


Presumably a message that exceeds the 32-bit limit contains one or more attachments that pushes it over the limit.  Perhaps the server could synthesize a message for IMAPrev1 clients that replaces large attachments with message/external-body parts.

My suggestion would be to just leave this implementation-defined, rather than recommending anything specific.

Are there choices that we should advise against? Maybe message truncation?


I don't really have an opinion on this. I think even message truncation might be acceptable in some situations.

--Apple-Mail=_F29EADFD-24C0-4DBE-A084-81DBD9067461-- From nobody Mon Nov 30 22:06:06 2020 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 30A143A0ADD; Mon, 30 Nov 2020 22:06:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick via Datatracker To: Cc: extra@ietf.org, draft-ietf-extra-sieve-mailboxid.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160680275991.19519.15021073145558109806@ietfa.amsl.com> Reply-To: Pete Resnick Date: Mon, 30 Nov 2020 22:05:59 -0800 Archived-At: Subject: [Extra] Genart last call review of draft-ietf-extra-sieve-mailboxid-05 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, 01 Dec 2020 06:06:00 -0000 Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-extra-sieve-mailboxid-05 Reviewer: Pete Resnick Review Date: 2020-11-30 IETF LC End Date: 2020-12-02 IESG Telechat date: Not scheduled for a telechat Summary: Looking good. Just one minor issue and one nit. Major issues: None. Minor issues: Section 4 says: If there is no such mailbox, the "fileinto" action proceeds as it would without the ":mailboxid" argument. But the in the example in section 6, it shows: if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" { fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3" "INBOX.harassment"; } else { fileinto "INBOX.harassment"; } That appears correct, but as far as I can tell, it is semantically identical to: fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3" "INBOX.harassment"; That is, the rule in section 4 means that fileinto already does an implicit existence check and only uses the named mailbox if the one specified by the mailboxid doesn't exist. It's not that the example is particularly a problem, but it did confuse me for a few minutes while I tried to figure out what it was trying to do. Perhaps if the example was: if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" { fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3" "this.name.will.never.be.used"; } else { fileinto "INBOX.harassment"; } or an example that did something other than "fileinto" it would have made a bit more sense. Certainly not absolutely necessary to fix, but a change might improve understanding. Nits/editorial comments: In sections 4.1 and 4.2, you have references that appear as "[!@RFC5490]" and "[!@RFC5879]". I assume that's some sort of markdown or other formatting tool mistake. From nobody Mon Nov 30 23:58:25 2020 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 A460E3A0936; Mon, 30 Nov 2020 23:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=k0C5viqF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nh2Eyc0d 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 vX3qsMbiU6vt; Mon, 30 Nov 2020 23:58:21 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CAD3A0937; Mon, 30 Nov 2020 23:58:21 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 618051291; Tue, 1 Dec 2020 02:58:20 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 01 Dec 2020 02:58:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=Lf+0 zLQxsEEFpINtqZMmzT/qDFPkQqxvkCMLf8oyl6Y=; b=k0C5viqFOSxZZpTKDIW2 VmDEPFFfyLju20dmNzlljMKAKjF22ukuccDOyibRv5EhuD3zFEjoiC1hY5g1DJeg 2eDItKbwfkGn0uL9SpQR1KqKsbs24pfVXTlVzld678s1DrYiNOHp+TA4lM74VYpV OVMuwDqgycGOCvA4QubNKHBiS8logMKgldXEH9I20iAf0MDf7I32dE5BpwYM7+BI FtMaNbsQmBeTMp/EqI4tdQ81kx/hXNqCcVyz8MmRw14fzIUzsf3Y0Xzb5dKI6dRO GIJPoQHDI3meCHPpu8YGFmzLe4C6o+4SO31+Sc+0fTPXowyNh69RyQfvCjAeyDqf ew== 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=Lf+0zL QxsEEFpINtqZMmzT/qDFPkQqxvkCMLf8oyl6Y=; b=nh2Eyc0dV/kV7KQJ8HGd0W RxlJMDBa9M7xRqHLcaXQQ9h/w2CQCQj+o9mLu+zWZ7wfvn57ZVK8nUGm8SkIhqnr 7CSepRXcAc7yLnkBIcQ/H7ODc6aBqbckrjOu5upU9u8ORSVUf8MXvBCaWvRP9OBY 5CrIA0RXKEQDZlqS6YuzNtmx1o2IupiyXtAAAgQa/5Zw/Rt0PW1Dih6mqVbQCEnW SDNh5H1EYlm5f+kgfcdklw40c1+HwwIDDstlNXh0OADtYX9BApnO6fHVhR/kuYVf XYuhn9qhOz1Bee71kEDKhRYs4MmTTx/ENih2bktt50tzZ4YsH0q0kHTVxXpP6kjw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeiuddgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehr ohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeevudfgjedtveetkeffkeekleeiueelkeevheekhfdv fefgfeekffeludffgfeljeenucffohhmrghinhepihgvthhfrdhorhhgpdhnvghvvghrrd gsvgenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegs rhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3614C180093; Tue, 1 Dec 2020 02:58:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <04396f38-431b-48e8-8b0f-65e2518d8ed4@dogfood.fastmail.com> In-Reply-To: <160680275991.19519.15021073145558109806@ietfa.amsl.com> References: <160680275991.19519.15021073145558109806@ietfa.amsl.com> Date: Tue, 01 Dec 2020 18:57:58 +1100 From: "Bron Gondwana" To: "Pete Resnick" , gen-art@ietf.org Cc: extra@ietf.org, draft-ietf-extra-sieve-mailboxid.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary=fce01c17df83433c9ca0054f487211e9 Archived-At: Subject: Re: [Extra] Genart last call review of draft-ietf-extra-sieve-mailboxid-05 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, 01 Dec 2020 07:58:24 -0000 --fce01c17df83433c9ca0054f487211e9 Content-Type: text/plain Thanks Pete, fair enough - I can see how a semantically pointless example is a problem. I'll update that in my copy and wait for any other review changes before uploading again. And yeah - if the latest mmark is causing artifacts I'll see what I can do about those. I admit I didn't read through the whole thing in detail again after making the last updates. Cheers, Bron On Tue, Dec 1, 2020, at 17:05, Pete Resnick via Datatracker wrote: > Reviewer: Pete Resnick > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-extra-sieve-mailboxid-05 > Reviewer: Pete Resnick > Review Date: 2020-11-30 > IETF LC End Date: 2020-12-02 > IESG Telechat date: Not scheduled for a telechat > > Summary: Looking good. Just one minor issue and one nit. > > Major issues: > > None. > > Minor issues: > > Section 4 says: > > If there is no such mailbox, the "fileinto" action proceeds as it > would without the ":mailboxid" argument. > > But the in the example in section 6, it shows: > > if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" { > fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3" > "INBOX.harassment"; > } else { > fileinto "INBOX.harassment"; > } > > That appears correct, but as far as I can tell, it is semantically identical to: > > fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3" > "INBOX.harassment"; > > That is, the rule in section 4 means that fileinto already does an implicit > existence check and only uses the named mailbox if the one specified by the > mailboxid doesn't exist. It's not that the example is particularly a problem, > but it did confuse me for a few minutes while I tried to figure out what it was > trying to do. Perhaps if the example was: > > if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" { > fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3" > "this.name.will.never.be.used"; > } else { > fileinto "INBOX.harassment"; > } > > or an example that did something other than "fileinto" it would have made a bit > more sense. Certainly not absolutely necessary to fix, but a change might > improve understanding. > > Nits/editorial comments: > > In sections 4.1 and 4.2, you have references that appear as "[!@RFC5490]" and > "[!@RFC5879]". I assume that's some sort of markdown or other formatting tool > mistake. > > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --fce01c17df83433c9ca0054f487211e9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Pete, fair enough - I can see how a semantically po= intless example is a problem.  I'll update that in my copy and wait= for any other review changes before uploading again.

And= yeah - if the latest mmark is causing artifacts I'll see what I can do = about those.  I admit I didn't read through the whole thing in deta= il again after making the last updates.

Cheers,
=

Bron

On = Tue, Dec 1, 2020, at 17:05, Pete Resnick via Datatracker wrote:
Reviewer: Pete Resnick
Review result: Ready with Issues

I am the assigned Ge= n-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents bein= g processed
by the IESG for t= he IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-e= xtra-sieve-mailboxid-05
Revie= wer: Pete Resnick
Review Date= : 2020-11-30
IETF LC End Date= : 2020-12-02
IESG Telechat da= te: Not scheduled for a telechat

Summary: Looking good. J= ust one minor issue and one nit.

Major issues:
<= div style=3D"font-family:Arial;">
None.

Minor issues:

Section 4 says:

   If there is no such mailbox, the "fileinto" a= ction proceeds as it
 &n= bsp; would without the ":mailboxid" argument.

But the in = the example in section 6, it shows:

   &nb= sp;   if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" {=
    &nbs= p;      fileinto :mailboxid "F6352ae03-b7f5-463= c-896f-d8b48ee3"
  =             =             =      "INBOX.harassment";
       } else {
<= div style=3D"font-family:Arial;">      &nb= sp;    fileinto "INBOX.harassment";
       }

That appears correct, but as far as I can tell, it is semantically id= entical to:

       &nb= sp;   fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"<= br>
     = ;            = ;            = ;  "INBOX.harassment";
<= br>
That is, the rule in section = 4 means that fileinto already does an implicit
existence check and only uses the named mailbox if the= one specified by the
mailbox= id doesn't exist. It's not that the example is particularly a problem,
but it did confuse me for a fe= w minutes while I tried to figure out what it was
trying to do. Perhaps if the example was:
=

       if mailboxidexists "F6352ae03= -b7f5-463c-896f-d8b48ee3" {
&= nbsp;          fileinto :ma= ilboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
         &nb= sp;           &nb= sp;         "this.name.will.neve= r.be.used";
   = ;    } else {
=            fileinto "I= NBOX.harassment";
  = ;     }
<= br>
or an example that did someth= ing other than "fileinto" it would have made a bit
more sense. Certainly not absolutely necessary to f= ix, but a change might
improv= e understanding.

Nits/editorial comments:

= In sections 4.1 and 4.2, you have references that appear as "[!@RFC5490]= " and
"[!@RFC5879]". I assume= that's some sort of markdown or other formatting tool
mistake.




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


--fce01c17df83433c9ca0054f487211e9--