From nobody Wed Jul 1 06:54:16 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 8719A3A0B5B; Wed, 1 Jul 2020 06:54:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.6.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159361165041.18981.14615284539898696428@ietfa.amsl.com> Date: Wed, 01 Jul 2020 06:54:10 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-quota-02.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, 01 Jul 2020 13:54:11 -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-02.txt Pages : 17 Date : 2020-07-01 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-extra-quota-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-quota-02 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 Jul 1 07:01: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 B7AF23A07F7 for ; Wed, 1 Jul 2020 07:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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 Bz_Td2BFPBMB for ; Wed, 1 Jul 2020 07:01:36 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 184083A0B62 for ; Wed, 1 Jul 2020 07:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1593612094; d=isode.com; s=june2016; i=@isode.com; bh=yoi93tJKsvJ+52h0OLFsT/0fVc4OrP0+apBU3fAYW7o=; 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=tVnb9lUlwCgJlT24MhVas3Gv2/9DxN1AM1mc7DLQ2kLLjT7tqjn6j7YYHDWhdtA1HNd+a/ xTXbZmoHmFvxgMAnfrk5PmTgktvLc/ycKjc5rmCcmqhea0w0yDT3WKLj+G+t8ntOOIxpBN 0Md6CQJFWKCq5U98dvCp25Y7l43Kd2Q=; Received: from [172.27.253.76] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 1 Jul 2020 15:01:34 +0100 To: extra@ietf.org References: <159361165041.18981.14615284539898696428@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <9a766b2b-0f18-69c3-c919-9af2ffaff074@isode.com> Date: Wed, 1 Jul 2020 15:01:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <159361165041.18981.14615284539898696428@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-quota-02.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, 01 Jul 2020 14:01:38 -0000 Hi all, On 01/07/2020 14:54, internet-drafts@ietf.org wrote: > 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-02 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-quota-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-quota-02 In this version I tried to address all issues I discussed during the interim. In particular quota usage/limits are now unsigned 64 (well 63) bits and there is a new section on interaction with IMAP ACL. Even though there are a couple of open issues remaining (see the new section), I think this is ready for WGLC. Reviewers should pay special attention to my questions in "Open Issues" and the new section about interaction with IMAP ACL. Thank you, Alexey From nobody Wed Jul 1 17:38: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 979E33A1299; Wed, 1 Jul 2020 17:38:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159365030850.18653.12655103558306241610@ietfa.amsl.com> Date: Wed, 01 Jul 2020 17:38:28 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-preview-08.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, 02 Jul 2020 00:38:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP4 Extension: Message Preview Generation Author : Michael M. Slusarz Filename : draft-ietf-extra-imap-fetch-preview-08.txt Pages : 13 Date : 2020-07-01 Abstract: This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated text representation of message data useful as a contextual preview of the entire message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-08 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-preview-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-fetch-preview-08 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 Jul 1 18:56: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 698C53A0593 for ; Wed, 1 Jul 2020 18:56:28 -0700 (PDT) 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=LBPNfOwE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ppzWjFcS 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 mjIRTqdJ13Nm for ; Wed, 1 Jul 2020 18:56:27 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299C33A0528 for ; Wed, 1 Jul 2020 18:56:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 726395C016D for ; Wed, 1 Jul 2020 21:56:26 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Wed, 01 Jul 2020 21:56:26 -0400 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=fm3; bh=6fTRrgrFg+moa2qBILMFCQZYwyIoIAwk7wJYz8X DnpU=; b=LBPNfOwE4Om3NxNJntAIIz8OQgZoOBLXCk2BuxZ5Go+7u+TmGV0cSAD CvHpVc276u4h9PvTELnWj1R9av3NkZsasXMnTQ1XNZfO0oPWml86ZNGEFCj/EnL3 eDn4OoHuLfOzMl2UbaYm6xWLwGWsHYy2+L+zCl5wfX+jRO0FP7nYrAOzTt7fgOkq eLVFATo7hvqctJCptpxpQqqNykDM/6fnvz62r5okr9hn7S7yUKjk+kv927Y/niqw 53+HJtnY3vYIVNdxMzM15BQtAp59uv5FWZqB/Ufck56/cYBNfNUtFgZH2eN7ij0s Iz+70dcF3cBYF704Ku30vkay3WGiJtg== 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=fm3; bh=6fTRrgrFg+moa2qBILMFCQZYwyIoI Awk7wJYz8XDnpU=; b=ppzWjFcSdxLRkml41Q5bnmhHPrYXB5qtvRxo/B4uOF5sK 0ndj662W2fSbQMQB+86yA8Yf1AyngtTdV4gJSyeFgTw/KgUXsiDVmtZrbd/kdfG0 aUCYr3LB8e4dgyMZfrCU85zXjCUA9NilOwCVw7SkiHeP0sMHeAtplhuUbPoF1t0z G2ekLm+vl7qsQgr+s++AtgJPYNHJnVnsvRn5TpOZ7s6j/kv9BS+sUz1ikbYYkjXT DgneA4JQ/P3jkeqJf63D/nLOlPkIAbaQxmDqVEQSrlN2oMVISkIV+0fU6C3Lv2V7 uis7Bmi9rQUS6vDku0/pz7Av57pob+Q3ZFq9z6kyQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdefgdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihfegie dtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlth gvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0A3104AA005C; Wed, 1 Jul 2020 21:56:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-598-ga0ddc1b-fm-idx2020-20200630.003-ga0ddc1ba Mime-Version: 1.0 Message-Id: Date: Thu, 02 Jul 2020 11:56:04 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=dc341f1161a64181874242a66d1111dd Archived-At: Subject: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08 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, 02 Jul 2020 01:56:28 -0000 --dc341f1161a64181874242a66d1111dd Content-Type: text/plain As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version. This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication. Please reply with any comments by Thursday, July 16th 2020. Let's get this one off our plates before IETF108. Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --dc341f1161a64181874242a66d1111dd Content-Type: text/html Content-Transfer-Encoding: quoted-printable
As discussed in the interim meeting, this document was bro= ught back to the working group to be reverted to an earlier and simpler = version.

This email announces a 2 week working group last= call for any further comments on this version before I re-submit to IES= G for publication.  Please reply with any comments by Thursday, Jul= y 16th 2020.  Let's get this one off our plates before IETF108.
=

Thanks,

Bron.

--
&nbs= p; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastm= ailteam.com


--dc341f1161a64181874242a66d1111dd-- From nobody Thu Jul 2 02:20:17 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 C27793A0044 for ; Thu, 2 Jul 2020 02:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 sfK0TX1FWNWa for ; Thu, 2 Jul 2020 02:20:14 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id F2A6C3A0029 for ; Thu, 2 Jul 2020 02:20:13 -0700 (PDT) Received: from [172.20.10.2] (unknown [85.76.76.90]) by sirainen.com (Postfix) with ESMTPSA id 4F2E12B3C8B for ; Thu, 2 Jul 2020 09:20:12 +0000 (UTC) From: Timo Sirainen Content-Type: multipart/alternative; boundary="Apple-Mail=_32721D75-845B-4667-9D9D-AA89B3B67AAE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 2 Jul 2020 12:20:10 +0300 References: To: extra@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08 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, 02 Jul 2020 09:20:16 -0000 --Apple-Mail=_32721D75-845B-4667-9D9D-AA89B3B67AAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2. Jul 2020, at 4.56, Bron Gondwana wrote: >=20 > As discussed in the interim meeting, this document was brought back to = the working group to be reverted to an earlier and simpler version. >=20 > This email announces a 2 week working group last call for any further = comments on this version before I re-submit to IESG for publication. = Please reply with any comments by Thursday, July 16th 2020. Let's get = this one off our plates before IETF108. It is possible that preview text is not available now, but might be available later -- perhaps the server's preview-generating resources are overloaded, there is a server-imposed timeout during preview generation, or there is some transient issue with fetching the message body. In such cases, the server will return NIL as the preview response, and the client can try to retrieve the preview later. This sounds like it's possible for server to return NIL even when the = LAZY modifier isn't specified. Is this really wanted? I'd think client = developers would prefer that only LAZY can return NILs. Either way, it's = not clearly enough specified what is intended. --Apple-Mail=_32721D75-845B-4667-9D9D-AA89B3B67AAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 2. Jul 2020, at 4.56, Bron Gondwana <brong@fastmailteam.com> wrote:

As discussed in = the interim meeting, this document was brought back to the working group = to be reverted to an earlier and simpler version.

This email announces a 2 week working group last call = for any further comments on this version before I re-submit to IESG for = publication.  Please reply with any comments by Thursday, July 16th = 2020.  Let's get this one off our plates before IETF108.

   It is possible that = preview text is not available now, but might be
   available later -- perhaps the server's = preview-generating resources
   are = overloaded, there is a server-imposed timeout during preview
   generation, or there is some transient issue = with fetching the
   message body. =  In such cases, the server will return NIL as the
   preview response, and the client can try to = retrieve the preview
   later.

This sounds like it's possible for = server to return NIL even when the LAZY modifier isn't specified. Is = this really wanted? I'd think client developers would prefer that only = LAZY can return NILs. Either way, it's not clearly enough specified what = is intended.

= --Apple-Mail=_32721D75-845B-4667-9D9D-AA89B3B67AAE-- From nobody Thu Jul 2 04:46:19 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 6DD5A3A0BD8 for ; Thu, 2 Jul 2020 04:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 oyHfZ-IMV4MK for ; Thu, 2 Jul 2020 04:46:15 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B655A3A0BD4 for ; Thu, 2 Jul 2020 04:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1593690374; d=isode.com; s=june2016; i=@isode.com; bh=lFPsrnQF+Zs8XOYN+w4wstlLRG4qwTVg8B8muRDgYGU=; 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=Za3H6VG3Ne34sM5rwsCmW/jf1PLGOgNnIQtPELU2HReW+ZWxXW4IlM3pDZSYhMaAiCimpJ BcA2TD5ewFyzhjdbiFs16YoHu7WSoJEmHwmhwxdOdTlcKspwC8Nm6eQjfC58PKhTSmHrNn p+yp+4FNCKjm6gSUG73L7uVPApMzHNo=; Received: from [172.27.253.137] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 2 Jul 2020 12:46:14 +0100 To: Bron Gondwana , extra@ietf.org References: From: Alexey Melnikov Message-ID: Date: Thu, 2 Jul 2020 12:45:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------14D103975B601BFBDC81BC86" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08 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, 02 Jul 2020 11:46:17 -0000 --------------14D103975B601BFBDC81BC86 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 02/07/2020 02:56, Bron Gondwana wrote: > As discussed in the interim meeting, this document was brought back to=20 > the working group to be reverted to an earlier and simpler version. > > This email announces a 2 week working group last call for any further=20 > comments on this version before I re-submit to IESG for publication.=C2=A0= =20 > Please reply with any comments by Thursday, July 16th 2020.=C2=A0 Let's ge= t=20 > this one off our plates before IETF108. Other than what Timo reported, this version looks good to me. --------------14D103975B601BFBDC81BC86 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 02/07/2020 02:56, Bron Gondwana wrote:

As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version.

This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication.=C2=A0 Please reply with any comments by Thursday, July 16th 2020.=C2=A0 Let's get this one off our plates before IETF108.

Other than what Timo reported, this version looks good to me.


--------------14D103975B601BFBDC81BC86-- From nobody Thu Jul 2 17:22: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 E79203A099A; Thu, 2 Jul 2020 17:20:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: extra@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563393.30173.11545178371873864187@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:33 -0700 Archived-At: Subject: [Extra] extra - Requested session has been scheduled for IETF 108 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: Fri, 03 Jul 2020 00:20:43 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. extra Session 1 (0:50 requested) Thursday, 30 July 2020, Session I 1100-1240 Room Name: Room 2 size: 2 --------------------------------------------- Special Note: Joint with JMAP iCalendar: https://datatracker.ietf.org/meeting/108/sessions/extra.ics Request Information: --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: jmap calext dispatch People who must be present: Barry Leiba Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Special Requests: Per the notes on the JMAP session - we'd like to do a combined session for both. Barry suggested putting this request in so "extra" is listed on the agenda. --------------------------------------------------------- From nobody Mon Jul 6 10:38:11 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 17A0F3A005F for ; Mon, 6 Jul 2020 10:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 mKnQA5px8g2E for ; Mon, 6 Jul 2020 10:38:08 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9F73A005B for ; Mon, 6 Jul 2020 10:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594057087; d=isode.com; s=june2016; i=@isode.com; bh=M4C50GX/w/OcHlotdFBq5cbvfUMcmV4Z6tnRavSklO0=; 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=ckg82nAHKKV5nBvrYxLIkio9VaVT6eG0CniMXxJVHgXK8Atu6I9flMz6H2zlTPlikJwt1g 4FqGk9HoZP2PbRrXyF3TRhVNHooCY7E/Nu3SrkzeC6BhBdRhTA6ca26zyCuDc5n7YKef6H 0HAHIFZPnxFkeqWM1VJa38c+ES2yq9E=; Received: from [172.27.253.179] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 6 Jul 2020 18:38:07 +0100 To: Bron Gondwana , Timo Sirainen Cc: extra@ietf.org References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> From: Alexey Melnikov Message-ID: <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> Date: Mon, 6 Jul 2020 18:38:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5D37FA9A6870CB100AC4823C" Content-Language: en-GB Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE 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, 06 Jul 2020 17:38:10 -0000 --------------5D37FA9A6870CB100AC4823C Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 17/06/2020 13:27, Bron Gondwana wrote: > On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >>> >>> 1) abandon use of this response code (and use a new response=20 >>> instead), e.g. >>> >>> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >>> >>> =C2=A0This would require clients to ignore an extra response, if they=20 >>> don't recognize it. >>> >> >> Somehow I've a feeling that there are going to be clients that will=20 >> break if they see these kind of unknown untagged replies. But that's=20 >> just a guess, so maybe not. We could of course send it only when=20 >> client has used ENABLE IMAP4REV2 and then there wouldn't be any problems. > > I like this.=C2=A0 Only send if IMAP4REV2 is enabled and all[tm] your=20 > problems go away. Following on the suggestion to use LIST extended data items for this =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C: C04 create NonCannonicalName =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S: * LIST () "/" "CannonicalName" ("TAG" ("C= 04")) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S: C04 OK done In the example above imagine that "CannonicalName" is the canonical=20 (normalized) version of "NonCannonicalName" And the corresponding ABNF: tag-extended-item =3D "TAG" SP "(" tag-string ")" =C2=A0=C2=A0 ; Complies with <mbox-list-extended-item> =C2=A0=C2=A0 ; The value complies with <tagged-ext-val> =C2=A0=C2=A0 ; The value is the tag of the corresponding =C2=A0=C2=A0 ; CREATE command. And a similar extended data item can be used to return MAILBOXID (when=20 supported). Does this work for people? Best Regards, Alexey --------------5D37FA9A6870CB100AC4823C Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 17/06/2020 13:27, Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote:

1) abandon use of this response code (and use a new response instead), e.g.

* CREATED "a123" "Denormalized name" MAILBOXID "123456"

=C2=A0This would require clients to ignore an extra response, if they don't recognize it.


Somehow I've a feeling that there are going to be clients that will break if they see these kind of unknown untagged replies. But that's just a guess, so maybe not. We could of course send it only when client has used ENABLE IMAP4REV2 and then there wouldn't be any problems.

I like this.=C2=A0 Only send if IMAP4REV2 is enabled and all[tm] your problems go away.

Following on the suggestion to use LIST extended data items for this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C: C04 create NonCannonicalName
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S: * LIST () "/" "CannonicalName" ("TAG= " ("C04"))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S: C04 OK done

In the example above imagine that "CannonicalName" is the canonical (normalized) version of "NonCannonicalName"

And the corresponding ABNF:

tag-extended-item =3D "TAG" SP "(" tag-string ")"
=C2=A0=C2=A0 ; Complies with &lt;mbox-list-extended-item&gt; =C2=A0=C2=A0 ; The value complies with &lt;tagged-ext-val&gt;<= br> =C2=A0=C2=A0 ; The value is the tag of the corresponding
=C2=A0=C2=A0 ; CREATE command.

And a similar extended data item can be used to return MAILBOXID (when supported).

Does this work for people?

Best Regards,

Alexey

--------------5D37FA9A6870CB100AC4823C-- From nobody Mon Jul 6 16:31:18 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 D19023A0035 for ; Mon, 6 Jul 2020 16:31:15 -0700 (PDT) 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=dNYWJ0KM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=M+JFPTkB 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 SkjfYE8twfgU for ; Mon, 6 Jul 2020 16:31:14 -0700 (PDT) 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 7FEB83A0029 for ; Mon, 6 Jul 2020 16:31:14 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C2A2E162F for ; Mon, 6 Jul 2020 19:31:13 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Mon, 06 Jul 2020 19:31:13 -0400 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:subject:content-type; s=fm3; bh=e1yacME zC7UKFCciXUnQMeMWv8HzgEs4+zgvGcA9j0Y=; b=dNYWJ0KMU0O7dNT61VVjCZV CPr/vGvEut5O/b7+gU+UmnXbIPu6szziPrXYaXHe1vF1xmMgEPARGe7Rv3hQOZ3Q bh8YWe4z5oeMbv3CTa+NMkC0EcIjOZDIOx6G5j2PoQ7mRJK5Ub4xBkkIt1gsjhoL qKtFkctkRmCpJSNab3XcY2PHmPBNEk+Os/0N95L/+3mVGmrrL6cBe5G1EGeRPaxA cxYuYoGWi2PmWh/mNn0c97LjM6xoVoml5fKo4oW8zYAJzo7RNEWxlIxP8tr4tYB5 goUnUGSZ+5vnUVq2aZ+XK4flChmLYBtjpul4QVefl8iO+CZQTDb+wC9GSvpemZQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=e1yacM EzC7UKFCciXUnQMeMWv8HzgEs4+zgvGcA9j0Y=; b=M+JFPTkBIXTep296pTf55O S/ORwi8m/C8x8WyHRKn0GE34qDbjO5fC5/8a39kiDi0phHBsiLhc4v5ILcV7lhT2 kiJ7OQZdLwmqNUpgoI9qNLK8eNomcjWFn4WinTX7G97yzOMVssIwCf4zeuDUEDCz desV67qoCQUAELJXYLEv/AWzjrxUvz6uay3Y5+02cgo40YyI7f2eTOF5mWfdDbeD JmG58zHZj5pn8HuzEV5MCHkOQS5OXGP0/aqDBS/ZQtPqnDSPQMdFOWv6o6oM1gqu Pf5MwoKUofv6F1d90H+RUz5ivSCfyl5ZMcgXXmYGmswrhnki/QLzuxIeW5texOFw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeggddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdehteegfeevte duffevteehfffghefhvdevkeeuhfehueetudehgfegieekjeetnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2FEB14AA005D; Mon, 6 Jul 2020 19:31:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-598-ga0ddc1b-fm-idx2020-20200630.003-ga0ddc1ba Mime-Version: 1.0 Message-Id: <178ba905-36d9-493e-a02f-ac1a91f3ae68@dogfood.fastmail.com> In-Reply-To: <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> Date: Tue, 07 Jul 2020 09:30:51 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=7f05bfa543e94499ae0a2c8d76a1dc24 Archived-At: Subject: Re: [Extra] =?utf-8?q?IMAP4rev2=3A_how_to_signal_canonical_mailbox_n?= =?utf-8?q?ame_after_CREATE?= 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, 06 Jul 2020 23:31:16 -0000 --7f05bfa543e94499ae0a2c8d76a1dc24 Content-Type: text/plain On Tue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote: > On 17/06/2020 13:27, Bron Gondwana wrote: >> On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >>>> 1) abandon use of this response code (and use a new response instead), e.g. >>>> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >>>> This would require clients to ignore an extra response, if they don't recognize it. >>> >>> Somehow I've a feeling that there are going to be clients that will break if they see these kind of unknown untagged replies. But that's just a guess, so maybe not. We could of course send it only when client has used ENABLE IMAP4REV2 and then there wouldn't be any problems. >> >> I like this. Only send if IMAP4REV2 is enabled and all[tm] your problems go away. > Following on the suggestion to use LIST extended data items for this > > C: C04 create NonCannonicalName > S: * LIST () "/" "CannonicalName" ("TAG" ("C04")) > S: C04 OK done > > In the example above imagine that "CannonicalName" is the canonical (normalized) version of "NonCannonicalName" > > And the corresponding ABNF: > > tag-extended-item = "TAG" SP "(" tag-string ")" > ; Complies with <mbox-list-extended-item> > ; The value complies with <tagged-ext-val> > ; The value is the tag of the corresponding > ; CREATE command. > > And a similar extended data item can be used to return MAILBOXID (when supported). Yes, this works for me. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --7f05bfa543e94499ae0a2c8d76a1dc24 Content-Type: text/html
On Tue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote:

On 17/06/2020 13:27, Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote:

1) abandon use of this response code (and use a new response instead), e.g.

* CREATED "a123" "Denormalized name" MAILBOXID "123456"

 This would require clients to ignore an extra response, if they don't recognize it.


Somehow I've a feeling that there are going to be clients that will break if they see these kind of unknown untagged replies. But that's just a guess, so maybe not. We could of course send it only when client has used ENABLE IMAP4REV2 and then there wouldn't be any problems.

I like this.  Only send if IMAP4REV2 is enabled and all[tm] your problems go away.

Following on the suggestion to use LIST extended data items for this


      C: C04 create NonCannonicalName
      S: * LIST () "/" "CannonicalName" ("TAG" ("C04"))
      S: C04 OK done


In the example above imagine that "CannonicalName" is the canonical (normalized) version of "NonCannonicalName"


And the corresponding ABNF:

tag-extended-item = "TAG" SP "(" tag-string ")"
   ; Complies with &lt;mbox-list-extended-item&gt;
   ; The value complies with &lt;tagged-ext-val&gt;
   ; The value is the tag of the corresponding
   ; CREATE command.


And a similar extended data item can be used to return MAILBOXID (when supported).


Yes, this works for me.

Bron.

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


--7f05bfa543e94499ae0a2c8d76a1dc24-- From nobody Mon Jul 6 20:22:15 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 C64D73A09CD for ; Mon, 6 Jul 2020 20:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwzuhGT3QGTJ for ; Mon, 6 Jul 2020 20:22:12 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A023A09C9 for ; Mon, 6 Jul 2020 20:22:11 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 7F3CF6A2FF for ; Tue, 7 Jul 2020 05:22:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1594092129; bh=LAe7Jr90X/zbmIO0r7tEHlQa69Wcyr7UpgN8a+h1iFw=; h=Date:From:To:In-Reply-To:References:Subject:From; b=fbWOZGY3gYKW9T4jIscoLDDJUqs47Jd7hDdQvF9RihXQ/1frYvrQOrqJueUyigHip jCrsLadn5mkDgTITzZt2Ebm0RzIMxsLFOm89eMrw5V7HEMiSO6KrfwRdluXdtXl1oh 3KLL++wDvo+Rc3HNo+CbwqW7GnJBOvvPWW/6k+1xMmUK/DEdupZdMyCve9sCi6yikz 6Nsdnk7k6lEL5NqvBTWSbQNnKIqaQL2CLxyn6Fy9nyc6Ulmf7XLKHFrpY3UWp8DEHT tPfWQKLiaoY39xcU1pc0PBE8K47KyC8CNXwkRysMI0kJc/X0mVN+Hkwzfa4DXeq3e/ YfVq/kckpg0nQ== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 6CC9D3C004B for ; Tue, 7 Jul 2020 05:22:09 +0200 (CEST) Date: Mon, 6 Jul 2020 21:22:08 -0600 (MDT) From: Michael Slusarz To: extra@ietf.org Message-ID: <1948688035.19548.1594092129291@appsuite.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19547_2068058439.1594092129283" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev15 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08 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, 07 Jul 2020 03:22:14 -0000 ------=_Part_19547_2068058439.1594092129283 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > On 07/02/2020 3:20 AM Timo Sirainen wrote: > > > On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com mailto:brong@fastmailteam.com > wrote: > > > > As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version. > > > > This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication. Please reply with any comments by Thursday, July 16th 2020. Let's get this one off our plates before IETF108. > > > > > > It is possible that preview text is not available now, but might be > available later -- perhaps the server's preview-generating resources > are overloaded, there is a server-imposed timeout during preview > generation, or there is some transient issue with fetching the > message body. In such cases, the server will return NIL as the > preview response, and the client can try to retrieve the preview > later. > This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended. > I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time. If a server can't produce a preview within a certain time threshold, it should somehow be able to abort the request. NIL might not be the best solution, but what if it empty string ("") is returned? Then a caching client may never have preview text for that message, even though the inability to return the text may be a temporary issue. LAZY means a server should return preview only if it is pre-generated (or can be generated without noticeable delay to user). non-LAZY request should return PREVIEW unless it exceeds some sort of server-defined timeout. But in the latter case - unless the server knows it can never create a PREVIEW, it does seem that NIL is the semantically correct response, at least given the current definitions. Empty string means the server has canonically decided that no reasonable preview can be generated. Another suggestion might be to return NO response to the FETCH ... but semantics of that are a little tortured if the rest of the FETCH request could be returned, or if preview can be returned for all but one of the messages requested in the FETCH. In the IMAP spec we have: "The LIST command SHOULD return its data quickly, without undue delay." Maybe adopt this language and leave it to server to figure out what is "undue delay?" But that doesn't address whether empty string or NIL is the correct response if undue delay is reached... michael ------=_Part_19547_2068058439.1594092129283 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 07/02/2020 3:20 AM Timo Sirainen <timo@sirainen.com> wrote:


On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com> wrote:
As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version.

This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication.  Please reply with any comments by Thursday, July 16th 2020.  Let's get this one off our plates before IETF108.

   It is possible that preview text is not available now, but might be
   available later -- perhaps the server's preview-generating resources
   are overloaded, there is a server-imposed timeout during preview
   generation, or there is some transient issue with fetching the
   message body.  In such cases, the server will return NIL as the
   preview response, and the client can try to retrieve the preview
   later.
This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended.
I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time.

If a server can't produce a preview within a certain time threshold, it should somehow be able to abort the request.  NIL might not be the best solution, but what if it empty string ("") is returned?  Then a caching client may never have preview text for that message, even though the inability to return the text may be a temporary issue.

LAZY means a server should return preview only if it is pre-generated (or can be generated without noticeable delay to user).  non-LAZY request should return PREVIEW unless it exceeds some sort of server-defined timeout.  But in the latter case - unless the server knows it can never create a PREVIEW, it does seem that NIL is the semantically correct response, at least given the current definitions.  Empty string means the server has canonically decided that no reasonable preview can be generated.

Another suggestion might be to return NO response to the FETCH ... but semantics of that are a little tortured if the rest of the FETCH request could be returned, or if preview can be returned for all but one of the messages requested in the FETCH.

In the IMAP spec we have: "The LIST command SHOULD return its data quickly, without undue delay."  Maybe adopt this language and leave it to server to figure out what is "undue delay?"  But that doesn't address whether empty string or NIL is the correct response if undue delay is reached...

michael
------=_Part_19547_2068058439.1594092129283-- From nobody Mon Jul 6 21:38:33 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 A4F193A07B3 for ; Mon, 6 Jul 2020 21:38:31 -0700 (PDT) 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=pUkqNJ7p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tDUGdH8K 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 QD6-iXjYUuk6 for ; Mon, 6 Jul 2020 21:38:29 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4163A07B1 for ; Mon, 6 Jul 2020 21:38:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8D8CAD60 for ; Tue, 7 Jul 2020 00:38:28 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Tue, 07 Jul 2020 00:38:28 -0400 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:subject:content-type; s=fm3; bh=zwgBCBC myIZvtMfrmsLQjqK/M4iL28ksXxCypfDNc48=; b=pUkqNJ7p0xgc6DgUDn2wbu/ SIdwLX7wFUl9m9lEPD+Vd9mbGFb9J4bZXfxiq3M3cMyTz0EdUFqpWAb8at3p8EiC u+nmIpxhM/H0US+WbvM6ZHBNJlRyLQflEj/5+CGwe935qK/eSoQTxujX+pniQpk5 BbOkwGXb7cGi8YWZiCdcSboqEoN/Z0qlKCScA+I2NMMWvYd7oEviPNV3rxshiyVD oSr0QxJlhn+2QL6qQYjdj4TGd5BPXwoQfVr5p51vu3Bm/EOJQTEJor7AUsGmuwF6 hveg8aYiFbUOMSqZ5p1qhqLnyYkJj/8WNU+KklO/UOnlnmEI6PTQItKtyAL4p2w= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=zwgBCB CmyIZvtMfrmsLQjqK/M4iL28ksXxCypfDNc48=; b=tDUGdH8KlM0OQVBcUbrSPH MapdTCcguMpr2NuwiOBq0cww+Vb6l9S6PuTh4pbixlc/sfDaDn46KZgEMSbFHVnF I+Rodf00Itpwm6a8atmRXcd/6hxWeuEpPQNPzQzFRW96c06l78kd4ojMIUhIDdeg d1MqzeCAkgtrEn+edYidpLBp/NVBqJVw/euN0adXAnJ78q+dQxPSIv7XRGxt4Tj0 GVKKGTmewtIzceZFRa3LkWFIpJ0PM88W+9HfQ3pjxTiR8k7UWkzWgLo6WuWR7mZh SBsVSIjHnLBwcAQKqHiuORh1MAQxQLoiXE1E4c6Bt9gAUy7R29kXWl4eYe+YsD5A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeggdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdehteegfeevte duffevteehfffghefhvdevkeeuhfehueetudehgfegieekjeetnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C8EFC4AA005D; Tue, 7 Jul 2020 00:38:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-619-g3deeb4d-fm-idx2020-20200707.001-g3deeb4df Mime-Version: 1.0 Message-Id: <0cbbf363-2652-40a7-baad-e0d7e38037e8@dogfood.fastmail.com> In-Reply-To: <1948688035.19548.1594092129291@appsuite.open-xchange.com> References: <1948688035.19548.1594092129291@appsuite.open-xchange.com> Date: Tue, 07 Jul 2020 14:38:04 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=25559856873c4785920591f9707dcaba Archived-At: Subject: Re: [Extra] =?utf-8?q?Working_Group_Last_Call_-_draft-ietf-extra-ima?= =?utf-8?q?p-fetch-preview-08?= 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, 07 Jul 2020 04:38:32 -0000 --25559856873c4785920591f9707dcaba Content-Type: text/plain On Tue, Jul 7, 2020, at 13:22, Michael Slusarz wrote: >> On 07/02/2020 3:20 AM Timo Sirainen wrote: >> >> >> On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com> wrote: >> >>> As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version. >>> >>> This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication. Please reply with any comments by Thursday, July 16th 2020. Let's get this one off our plates before IETF108. >> >> It is possible that preview text is not available now, but might be >> available later -- perhaps the server's preview-generating resources >> are overloaded, there is a server-imposed timeout during preview >> generation, or there is some transient issue with fetching the >> message body. In such cases, the server will return NIL as the >> preview response, and the client can try to retrieve the preview >> later. >> This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended. > I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time. > > If a server can't produce a preview within a certain time threshold, it should somehow be able to abort the request. NIL might not be the best solution, but what if it empty string ("") is returned? Then a caching client may never have preview text for that message, even though the inability to return the text may be a temporary issue. > > LAZY means a server should return preview only if it is pre-generated (or can be generated without noticeable delay to user). non-LAZY request should return PREVIEW unless it exceeds some sort of server-defined timeout. But in the latter case - unless the server knows it can never create a PREVIEW, it does seem that NIL is the semantically correct response, at least given the current definitions. Empty string means the server has canonically decided that no reasonable preview can be generated. > > Another suggestion might be to return NO response to the FETCH ... but semantics of that are a little tortured if the rest of the FETCH request could be returned, or if preview can be returned for all but one of the messages requested in the FETCH. > > In the IMAP spec we have: "The LIST command SHOULD return its data quickly, without undue delay." Maybe adopt this language and leave it to server to figure out what is "undue delay?" But that doesn't address whether empty string or NIL is the correct response if undue delay is reached... I'm good with the server returning a NO to the whole fetch with text like "preview generation took too long, try again with LAZY". I mean - the Cyrus server does something like that with SEARCH results that take too long these days - it'll just tell you "NO try again with a less expensive search" if it takes over 30s with our config. I expect we'd do the same with FETCH - send a NO (possibly part way through the fetch results) if we hit this kind of error. Maybe some client advice: 1) make the initial fetch with PREVIEW (LAZY) and the other fields you care about. 2) for items that got a NIL response, batch request non-lazy PREVIEW in sensible-sized batches (e.g. 64 at a time) Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --25559856873c4785920591f9707dcaba Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2020, at 13:22, Michael Slusarz wrote:
<= /div>
On 07/02/2020 3:20 AM Timo Sirainen <timo@sirainen.com>= wrote:


On 2. Jul 2020, at 4= .56, Bron Gondwana < brong@fastmailteam.com> wrote:

=
As discussed in the interim meeting, this document was brought back = to the working group to be reverted to an earlier and simpler version. <= br>

T= his email announces a 2 week working group last call for any further com= ments on this version before I re-submit to IESG for publication.  = Please reply with any comments by Thursday, July 16th 2020.  Let's = get this one off our plates before IETF108.

   It is possibl= e that preview text is not available now, but might be
   available later -- perhaps the server's preview-= generating resources
   are overlo= aded, there is a server-imposed timeout during preview
   generation, or there is some transient issue wit= h fetching the
   message body. &n= bsp;In such cases, the server will return NIL as the
   preview response, and the client can try to retrie= ve the preview
   later.
=
This sounds like it's possible for server to return NIL even when t= he LAZY modifier isn't specified. Is this really wanted? I'd think clien= t developers would prefer that only LAZY can return NILs. Either way, it= 's not clearly enough specified what is intended.
I was originally going to agree with Timo ... but then = I remember we added this part as a direct response to a potential DoS si= tuation - what happens if preview requests are (subjectively) taking too= much time.

If a server can't produce a pre= view within a certain time threshold, it should somehow be able to abort= the request.  NIL might not be the best solution, but what if it e= mpty string ("") is returned?  Then a caching client may never have= preview text for that message, even though the inability to return the = text may be a temporary issue.

LAZY means = a server should return preview only if it is pre-generated (or can be ge= nerated without noticeable delay to user).  non-LAZY request should= return PREVIEW unless it exceeds some sort of server-defined timeout.&n= bsp; But in the latter case - unless the server knows it can never creat= e a PREVIEW, it does seem that NIL is the semantically correct response,= at least given the current definitions.  Empty string means the se= rver has canonically decided that no reasonable preview can be generated= .

Another suggestion might be to return NO= response to the FETCH ... but semantics of that are a little tortured i= f the rest of the FETCH request could be returned, or if preview can be = returned for all but one of the messages requested in the FETCH.

In the IMAP spec we have: "The LIST command SHOULD= return its data quickly, without undue delay."  Maybe adopt this l= anguage and leave it to server to figure out what is "undue delay?" = ; But that doesn't address whether empty string or NIL is the correct re= sponse if undue delay is reached...

I= 'm good with the server returning a NO to the whole fetch with text like= "preview generation took too long, try again with LAZY".  I mean -= the Cyrus server does something like that with SEARCH results that take= too long these days - it'll just tell you "NO try again with a less exp= ensive search" if it takes over 30s with our config.  I expect we'd= do the same with FETCH - send a NO (possibly part way through the fetch= results) if we hit this kind of error.

Maybe some client= advice:

1) make the initial fetch with PREVIEW (LAZY) an= d the other fields you care about.
2) for items that got a NIL response, batch request non-lazy PREVI= EW in sensible-sized batches (e.g. 64 at a time)

Bron.


--
&nb= sp; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fast= mailteam.com


--25559856873c4785920591f9707dcaba-- From nobody Tue Jul 7 01:31:16 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 B5E7E3A07C3 for ; Tue, 7 Jul 2020 01:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 nNw9iz3PB2NT for ; Tue, 7 Jul 2020 01:31:13 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id BBCE23A07E2 for ; Tue, 7 Jul 2020 01:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594110671; d=isode.com; s=june2016; i=@isode.com; bh=nOBqBFwOV3U10Y8uQ3sVkScbH90QyKc4MmTZ6uVD11I=; 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=QbQlwhnQkJYsobK2HlHQidh7OdL/szCwogQjck2xxSRMSf7oPkCMPipxz/SDl9rTMZiR9z GKRlhuaHcOL1XvEeTR406Q9RWrMQKYRWeGGjATgGsz6FwS4Y9/OikGVpqlZ1RTufpOAae3 Oe2SJmf41Ipcp2DoPWtWlgQYJYrmTR0=; Received: from [192.168.1.222] (host81-151-37-172.range81-151.btcentralplus.com [81.151.37.172]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Jul 2020 09:31:10 +0100 To: Bron Gondwana , extra@ietf.org References: <1948688035.19548.1594092129291@appsuite.open-xchange.com> <0cbbf363-2652-40a7-baad-e0d7e38037e8@dogfood.fastmail.com> From: Alexey Melnikov Message-ID: <01948a8c-3879-b47a-dfc6-a46f8a0cdf6d@isode.com> Date: Tue, 7 Jul 2020 09:30:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <0cbbf363-2652-40a7-baad-e0d7e38037e8@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------401223FF3C51DD2652950B48" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08 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, 07 Jul 2020 08:31:15 -0000 --------------401223FF3C51DD2652950B48 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 07/07/2020 05:38, Bron Gondwana wrote: > On Tue, Jul 7, 2020, at 13:22, Michael Slusarz wrote: >>> On 07/02/2020 3:20 AM Timo Sirainen wrote: >>> >>> >>> On 2. Jul 2020, at 4..56, Bron Gondwana < brong@fastmailteam.com=20 >>> > wrote: >>> >>>> As discussed in the interim meeting, this document was brought back=20 >>>> to the working group to be reverted to an earlier and simpler version. >>>> >>>> This email announces a 2 week working group last call for any=20 >>>> further comments on this version before I re-submit to IESG for=20 >>>> publication.=C2=A0 Please reply with any comments by Thursday, July 16t= h=20 >>>> 2020.=C2=A0 Let's get this one off our plates before IETF108. >>> >>> =C2=A0 =C2=A0It is possible that preview text is not available now, but = might be >>> =C2=A0 =C2=A0available later -- perhaps the server's preview-generating = resources >>> =C2=A0 =C2=A0are overloaded, there is a server-imposed timeout during pr= eview >>> =C2=A0 =C2=A0generation, or there is some transient issue with fetching = the >>> =C2=A0 =C2=A0message body. =C2=A0In such cases, the server will return N= IL as the >>> =C2=A0 =C2=A0preview response, and the client can try to retrieve the pr= eview >>> =C2=A0 =C2=A0later. >>> This sounds like it's possible for server to return NIL even when=20 >>> the LAZY modifier isn't specified. Is this really wanted? I'd think=20 >>> client developers would prefer that only LAZY can return NILs.=20 >>> Either way, it's not clearly enough specified what is intended. >> I was originally going to agree with Timo ... but then I remember we=20 >> added this part as a direct response to a potential DoS situation -=20 >> what happens if preview requests are (subjectively) taking too much time. >> >> If a server can't produce a preview within a certain time threshold,=20 >> it should somehow be able to abort the request. NIL might not be the=20 >> best solution, but what if it empty string ("") is returned?=C2=A0 Then a= =20 >> caching client may never have preview text for that message, even=20 >> though the inability to return the text may be a temporary issue. >> >> LAZY means a server should return preview only if it is pre-generated=20 >> (or can be generated without noticeable delay to user).=C2=A0 non-LAZY=20 >> request should return PREVIEW unless it exceeds some sort of=20 >> server-defined timeout.=C2=A0 But in the latter case - unless the server= =20 >> knows it can never create a PREVIEW, it does seem that NIL is the=20 >> semantically correct response, at least given the current=20 >> definitions.=C2=A0 Empty string means the server has canonically decided= =20 >> that no reasonable preview can be generated.. >> >> Another suggestion might be to return NO response to the FETCH ...=20 >> but semantics of that are a little tortured if the rest of the FETCH=20 >> request could be returned, or if preview can be returned for all but=20 >> one of the messages requested in the FETCH. >> >> In the IMAP spec we have: "The LIST command SHOULD return its data=20 >> quickly, without undue delay."=C2=A0 Maybe adopt this language and leave= =20 >> it to server to figure out what is "undue delay?"=C2=A0 But that doesn't= =20 >> address whether empty string or NIL is the correct response if undue=20 >> delay is reached... > > I'm good with the server returning a NO to the whole fetch with text=20 > like "preview generation took too long, try again with LAZY".=C2=A0 I mean= =20 > - the Cyrus server does something like that with SEARCH results that=20 > take too long these days - it'll just tell you "NO try again with a=20 > less expensive search" if it takes over 30s with our config.=C2=A0 I expec= t=20 > we'd do the same with FETCH - send a NO (possibly part way through the=20 > fetch results) if we hit this kind of error. I think returning NO to FETCH is problematic and will cause problems=20 with clients as they don't expect it. Untagged NO might be slightly better. > Maybe some client advice: > > 1) make the initial fetch with PREVIEW (LAZY) and the other fields you=20 > care about. > 2) for items that got a NIL response, batch request non-lazy PREVIEW=20 > in sensible-sized batches (e.g. 64 at a time) These recommendations are good. --------------401223FF3C51DD2652950B48 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 07/07/2020 05:38, Bron Gondwana wrote:

On Tue, Jul 7, 2020, at 13:22, Michael Slusarz wrote:
On 07/02/2020 3:20 AM Timo Sirainen <timo@sirainen.com> wrote:


On 2. Jul 2020, at 4..56, Bron Gondwana < brong@fastmailteam.com> wrote:

As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version.

This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication.=C2=A0 Please reply with any comments by Thursday, July 16th 2020.=C2=A0 Let's get this one off our plates before IETF108.

=C2=A0 =C2=A0It is possible that preview text= is not available now, but might be
=C2=A0 =C2=A0available later -- perhaps the s= erver's preview-generating resources
=C2=A0 =C2=A0are overloaded, there is a server-imposed timeout during preview
=C2=A0 =C2=A0generation, or there is some tra= nsient issue with fetching the
=C2=A0 =C2=A0message body. =C2=A0In such case= s, the server will return NIL as the
=C2=A0 =C2=A0preview response, and the client= can try to retrieve the preview
=C2=A0 =C2=A0later.
This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended.
I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time.

If a server can't produce a preview within a certain time threshold, it should somehow be able to abort the request.=C2=A0 NIL might not be the best solution, but what if it empty string ("") is returned?=C2=A0 Then a caching client may never have preview text for that message, even though the inability to return the text may be a temporary issue.

LAZY means a server should return preview only if it is pre-generated (or can be generated without noticeable delay to user).=C2=A0 non-LAZY request should return PREVIEW unless it exceeds some sort of server-defined timeout.=C2=A0 But in the latter case - unless the server knows it can never create a PREVIEW, it does seem that NIL is the semantically correct response, at least given the current definitions.=C2=A0 Empty string means the server has canonically decided that no reasonable preview can be generated..

Another suggestion might be to return NO response to the FETCH ... but semantics of that are a little tortured if the rest of the FETCH request could be returned, or if preview can be returned for all but one of the messages requested in the FETCH.

In the IMAP spec we have: "The LIST command SHOULD return its data quickly, without undue delay."=C2=A0 Maybe adopt this language and leave it to server to figure out what is "undue delay?"=C2=A0 But that doesn't address whether empty string or NIL is the correct response if undue delay is reached...

I'm good with the server returning a NO to the whole fetch with text like "preview generation took too long, try again with LAZY".=C2=A0 I mean - the Cyrus server does something like that with SEARCH results that take too long these days - it'll just tell you "NO try again with a less expensive search" if it takes over 30s with our config.=C2=A0 I expect we'd do the same with FETCH - send a NO (possibly part way through the fetch results) if we hit this kind of error.

I think returning NO to FETCH is problematic and will cause problems with clients as they don't expect it. Untagged NO might be slightly better.

Maybe some client advice:

1) make the initial fetch with PREVIEW (LAZY) and the other fields you care about.
2) for items that got a NIL response, batch request non-lazy PREVIEW in sensible-sized batches (e.g. 64 at a time)

These recommendations are good.


--------------401223FF3C51DD2652950B48-- From nobody Tue Jul 7 01:54:37 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 4C82C3A0784 for ; Tue, 7 Jul 2020 01:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 yJqSPPdnhb7m for ; Tue, 7 Jul 2020 01:54:34 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id EF2843A0781 for ; Tue, 7 Jul 2020 01:54:33 -0700 (PDT) Received: from [192.168.8.102] (unknown [109.240.41.51]) by sirainen.com (Postfix) with ESMTPSA id BA3C92B3C8B; Tue, 7 Jul 2020 08:54:31 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_36447BDD-A26F-4EE4-823C-B6A6706F1BBB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Timo Sirainen X-Priority: 3 In-Reply-To: <1948688035.19548.1594092129291@appsuite.open-xchange.com> Date: Tue, 7 Jul 2020 11:54:30 +0300 Cc: extra@ietf.org Message-Id: <388F9721-0CB5-4146-AC23-503C4481A090@sirainen.com> References: <1948688035.19548.1594092129291@appsuite.open-xchange.com> To: Michael Slusarz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08 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, 07 Jul 2020 08:54:36 -0000 --Apple-Mail=_36447BDD-A26F-4EE4-823C-B6A6706F1BBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7. Jul 2020, at 6.22, Michael Slusarz = wrote: >=20 >> On 07/02/2020 3:20 AM Timo Sirainen wrote: >>=20 >>=20 >> On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com = > wrote:=20 >>> As discussed in the interim meeting, this document was brought back = to the working group to be reverted to an earlier and simpler version.=20= >>>=20 >>> This email announces a 2 week working group last call for any = further comments on this version before I re-submit to IESG for = publication. Please reply with any comments by Thursday, July 16th = 2020. Let's get this one off our plates before IETF108.=20 >>=20 >>=20 >> It is possible that preview text is not available now, but might = be >> available later -- perhaps the server's preview-generating = resources >> are overloaded, there is a server-imposed timeout during preview >> generation, or there is some transient issue with fetching the >> message body. In such cases, the server will return NIL as the >> preview response, and the client can try to retrieve the preview >> later. >> This sounds like it's possible for server to return NIL even when the = LAZY modifier isn't specified. Is this really wanted? I'd think client = developers would prefer that only LAZY can return NILs. Either way, it's = not clearly enough specified what is intended. > I was originally going to agree with Timo ... but then I remember we = added this part as a direct response to a potential DoS situation - what = happens if preview requests are (subjectively) taking too much time. I don't really see why this would be an issue. IMAP protocol doesn't = have this kind of a special "DoS-prevention feature" anywhere else. = Especially now that the preview is always text, I don't think it can be = excessively slow to generate it. At least in Dovecot's implementation = it's basically as expensive as fetching BODYSTRUCTURE, and we don't have = DoS prevention against fetching those. Maybe in theory if server wanted = to analyze attachments in some way .. but is it really worth the added = complexity for a problem that probably will remain theoretical? FETCH is also good in that it returns the results after each mail. So = the server is allowed to start throttling the responses to the client = without actually failing it. --Apple-Mail=_36447BDD-A26F-4EE4-823C-B6A6706F1BBB Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On 7. Jul 2020, at 6.22, Michael Slusarz <michael.slusarz=40open-xchange.com@dmarc.ietf.org> wrote:

On 07/02/2020 3:20 AM Timo Sirainen <timo@sirainen.com> wrote:


On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com> wrote:
As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version.

This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication.  Please reply with any comments by Thursday, July 16th 2020.  Let's get this one off our plates before IETF108.

   It is possible that preview text is not available now, but might be
   available later -- perhaps the server's preview-generating resources
   are overloaded, there is a server-imposed timeout during preview
   generation, or there is some transient issue with fetching the
   message body.  In such cases, the server will return NIL as the
   preview response, and the client can try to retrieve the preview
   later.
This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended.
I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time.

I don't really see why this would be an issue. IMAP protocol doesn't have this kind of a special "DoS-prevention feature" anywhere else. Especially now that the preview is always text, I don't think it can be excessively slow to generate it. At least in Dovecot's implementation it's basically as expensive as fetching BODYSTRUCTURE, and we don't have DoS prevention against fetching those. Maybe in theory if server wanted to analyze attachments in some way .. but is it really worth the added complexity for a problem that probably will remain theoretical?

FETCH is also good in that it returns the results after each mail. So the server is allowed to start throttling the responses to the client without actually failing it.

--Apple-Mail=_36447BDD-A26F-4EE4-823C-B6A6706F1BBB-- From nobody Tue Jul 7 04:01:28 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 A72C73A0B8F for ; Tue, 7 Jul 2020 04:01:26 -0700 (PDT) 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=s8ZjlJ1y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eUg1HJTr 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 MRhh1R4g3nDm for ; Tue, 7 Jul 2020 04:01:24 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E05E3A0B60 for ; Tue, 7 Jul 2020 04:01:17 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9A35A5C01E8 for ; Tue, 7 Jul 2020 07:01:15 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Tue, 07 Jul 2020 07:01:15 -0400 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:subject:content-type; s=fm3; bh=Ov1DHB4 S4TcUxWXlVYd3KEZdN6FbIMpSAtK+6c64Las=; b=s8ZjlJ1yG+IlzUsCmVH+gRA NfU3LLJxVSxWouVWR91m+VWMADqZxMwwDdNazPWQ8Y9J7Mam0yv/xiXqgWSEL/Qc 83u5FCVbXxTPCaVuu8NZlhpwK+0RlNz07xgl8oCgcNgaoJK3fJ0TUqscGlkY9bqh Qum3HCXu/Yzz/gkugIbMYz1dyygORVECyns9uqL8t4dsT4j+FtPSCOcgE7qA6N/I AkAV+t++dV8lWeYG7bjq9J8mGPw/V1VW1N/3THPeq9eXAHSQYsRadZ9rDEVHsWX9 kVpexagm0M75eVG3SFSFBrMhAR/TZHrljvunRMFR4DsKAbqtiulI5H2QjfxRUfQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Ov1DHB 4S4TcUxWXlVYd3KEZdN6FbIMpSAtK+6c64Las=; b=eUg1HJTreiNMTeNeLHEGo/ 5vkAyy8jSAXfc82QXDd9qbjiQLIUvQUe2A56pfrdCNqNzOzaQj6qBaWKAtEDUWuR s8yYlbqq9cV0YkFr6SQdwdksY9C8Az6QQdvvifY2OtGyKfN5AVTaveqsmiP7ofL8 pFURF5IFXv0me/BmJVRPJBlAPnkBcrNR1dNBMytt/C7zBIs410OsdvLlBMKaPCIR a9h/3m2+Y0Tv+J2HvQOAe0GwxLK/VWc/T+gJk9IeeaLlm7p6ZsmwOe+cLJ1EOHZu Fv/ArjHxRBINA6FUXqHLBqjDkaiGV5MxMpywrz649HgwebZ2wFJE2WUxaZu9u50w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdehteegfeevte duffevteehfffghefhvdevkeeuhfehueetudehgfegieekjeetnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5E95B4AA005D; Tue, 7 Jul 2020 07:01:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-619-g3deeb4d-fm-idx2020-20200707.001-g3deeb4df Mime-Version: 1.0 Message-Id: In-Reply-To: <388F9721-0CB5-4146-AC23-503C4481A090@sirainen.com> References: <1948688035.19548.1594092129291@appsuite.open-xchange.com> <388F9721-0CB5-4146-AC23-503C4481A090@sirainen.com> Date: Tue, 07 Jul 2020 21:00:55 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=c314520df2a945eb8693e641ff9d12ba Archived-At: Subject: Re: [Extra] =?utf-8?q?Working_Group_Last_Call_-_draft-ietf-extra-ima?= =?utf-8?q?p-fetch-preview-08?= 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, 07 Jul 2020 11:01:27 -0000 --c314520df2a945eb8693e641ff9d12ba Content-Type: text/plain On Tue, Jul 7, 2020, at 18:54, Timo Sirainen wrote: > On 7. Jul 2020, at 6.22, Michael Slusarz wrote: >> >>> On 07/02/2020 3:20 AM Timo Sirainen wrote: >>> >>> >>> On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com> wrote: >>> >>>> As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version. >>>> >>>> This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication. Please reply with any comments by Thursday, July 16th 2020. Let's get this one off our plates before IETF108. >>> >>> It is possible that preview text is not available now, but might be >>> available later -- perhaps the server's preview-generating resources >>> are overloaded, there is a server-imposed timeout during preview >>> generation, or there is some transient issue with fetching the >>> message body. In such cases, the server will return NIL as the >>> preview response, and the client can try to retrieve the preview >>> later. >>> This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended. >> I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time. > > I don't really see why this would be an issue. IMAP protocol doesn't have this kind of a special "DoS-prevention feature" anywhere else. Especially now that the preview is always text, I don't think it can be excessively slow to generate it. At least in Dovecot's implementation it's basically as expensive as fetching BODYSTRUCTURE, and we don't have DoS prevention against fetching those. Maybe in theory if server wanted to analyze attachments in some way .. but is it really worth the added complexity for a problem that probably will remain theoretical? > > FETCH is also good in that it returns the results after each mail. So the server is allowed to start throttling the responses to the client without actually failing it. You're right. Here we are overcomplexing it again! Server MUST NOT return NIL to a non-lazy preview is fine by me. Server SHOULD NOT return NIL is fine by me as well, along with clients SHOULD NOT cache a NIL response. Either way our server is always going to have one because it gets calculated on APPEND. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --c314520df2a945eb8693e641ff9d12ba Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2020, at 18:54, Timo Sirainen wrote:
On 7. Jul 2020, at 6.22, Michael Slusarz <michae= l.slusarz=3D40open-xchange.com@dmarc.ietf.org> wrote:

On 07/02/2020 3:20 AM Timo Sirainen <timo@sirainen.com> wrote:
=


On 2. Jul= 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com> wrote:
=
As discussed in the interim m= eeting, this document was brought back to the working group to be revert= ed to an earlier and simpler version.

This email announces a 2 week work= ing group last call for any further comments on this version before I re= -submit to IESG for publication.  Please reply with any comments by= Thursday, July 16th 2020.  Let's get this one off our plates befor= e IETF108.

   It is possible tha= t preview text is not available now, but might be
   available later -- perhaps the server's preview-gener= ating resources
   are overloaded,= there is a server-imposed timeout during preview
   generation, or there is some transient issue with fet= ching the
   message body.  I= n such cases, the server will return NIL as the
   preview response, and the client can try to retrieve th= e preview
   later.
= This sounds like it's possible for server to return NIL even when the LA= ZY modifier isn't specified. Is this really wanted? I'd think client dev= elopers would prefer that only LAZY can return NILs. Either way, it's no= t clearly enough specified what is intended.
I was originally going to agree = with Timo ... but then I remember we added this part as a direct respons= e to a potential DoS situation - what happens if preview requests are (s= ubjectively) taking too much time.

I don't really see why this would be an issue. IM= AP protocol doesn't have this kind of a special "DoS-prevention feature"= anywhere else. Especially now that the preview is always text, I don't = think it can be excessively slow to generate it. At least in Dovecot's i= mplementation it's basically as expensive as fetching BODYSTRUCTURE, and= we don't have DoS prevention against fetching those. Maybe in theory if= server wanted to analyze attachments in some way .. but is it really wo= rth the added complexity for a problem that probably will remain theoret= ical?

FETCH is also good in that it returns= the results after each mail. So the server is allowed to start throttli= ng the responses to the client without actually failing it.

You're right.  Here we are overcomplexing it a= gain!

Server MUST NOT return NIL to a non-lazy preview is= fine by me.

Server SHOULD NOT return NIL is fine by me a= s well, along with clients SHOULD NOT cache a NIL response.  Either= way our server is always going to have one because it gets calculated o= n APPEND.

Bron.


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


--c314520df2a945eb8693e641ff9d12ba-- From nobody Wed Jul 8 05:59:13 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 511E33A0AF8 for ; Wed, 8 Jul 2020 05:59:05 -0700 (PDT) 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=2KZHx74A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QP03GcqX 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 F_YqKsYRZpoK for ; Wed, 8 Jul 2020 05:59:00 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B7D3A0A85 for ; Wed, 8 Jul 2020 05:59:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8226AC41 for ; Wed, 8 Jul 2020 08:58:59 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Wed, 08 Jul 2020 08:58:59 -0400 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:subject:content-type; s=fm3; bh=5HPUwTH gTVh+P34WqXWkJqIr9ErgZdSR0R6Ip2kECT4=; b=2KZHx74AQZ1B+dFMDOnp7dd yhWWc7AOCMx5Cq2Q5uDTqWItLSh/HKreYjuYOWckaIc4RPoEwKjCwsZBVRxdaMPg COeZ7d1wmlNKpaRpgmco2Q7Je79n9xeKH1O53VdXE7C7OgVhKowKW3GlOjb1i5gM QpblwRFN5VzMseutznhOAq2J/C84vgnH6l1hSz8Eg3Ax6d+3iduFshoXHoOQov4N OZGV/LQefwSkG6xbEgyuIzTEoL781WmRE8In8P7Nbc5iAFnJpj52596xZtpbNAzp CznYoouMTm3sOi5Im5jk8Ky/+seLdumTTbT8OtvPg3+2ITIQWBlZOHzIkVd/v6A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=5HPUwT HgTVh+P34WqXWkJqIr9ErgZdSR0R6Ip2kECT4=; b=QP03GcqXczdXnOiicVTr18 vjy+VpIcBtQY9Qt0nkhRSk7I6RC1PT4CR6DTn/Y5YdAUWEnmbsREjZzCfkGsGg7m AT/2mmz/CltJnkSsc7ZIcFA5x2mv1QESia97O3Qwk7prqHoYENccDRAbI+ujDKiX 4umV4MYjQqMIfEydze+j+BwD6+1Xyn7HBfrrSZiK4f74P6RvtFLWP3A21YlBJftL HvUTdjrPAUgtT3EQgBIFjEHSVIG8qToWpOa8iHNX7jUPfR+nPo31germTiLyfva0 JPlf1yK9SeyZSM18tuCRHXGbKMumJnD40dKgBlO698sY1tKi9TxFK4HB5DO0vGJw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdehlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepffevfeeigfejve etheehleegteelteevgeeutdfhhefghfdtjefhvdehhfdtkefgnecuffhomhgrihhnpehi vghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D6F854AA005D; Wed, 8 Jul 2020 08:58:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-623-g16e0e99-fm-idx2020-20200708.001-g16e0e99e Mime-Version: 1.0 Message-Id: <3da1a65d-4825-426a-8b6d-70f0e923310e@dogfood.fastmail.com> In-Reply-To: <345e934f-e540-4b42-bd5e-8c1e1f6965f8@www.fastmail.com> References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <345e934f-e540-4b42-bd5e-8c1e1f6965f8@www.fastmail.com> Date: Wed, 08 Jul 2020 22:58:38 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=5bcae40328e94799b81f2a007e0916fe Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 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, 08 Jul 2020 12:59:12 -0000 --5bcae40328e94799b81f2a007e0916fe Content-Type: text/plain I have reviewed all the changes from -12 to -15 and am still mostly happy :) I haven't reviewed -15 in full because it's a big job! Regarding the changes in -13, I have a couple of small things: *Regarding unsolicited fetch:** * If the server chooses to send unsolicited FETCH responses, they MUST include UID FETCH item. Note that this is a new requirement when compared to RFC 3501. This could do with a clarification that this only applies after "ENABLED IMAP4REV2". *Regarding SELECT allowing non-canonical names:** * We've already discussed the list response to CREATE. Should SELECT also return the canonical representation of the mailbox name as part of the reply? *Next steps:** * Alexey - are there any other changes still waiting before we do a working group last call? Thanks, Bron. On Fri, Feb 14, 2020, at 10:47, Bron Gondwana wrote: > Thanks Alexey, I see there's a -12 there now, and I'm happy with all the edits in it :) > > There are still some outstanding points from this thread - are you expecting to issue a -13 for those? > > Thanks, > > Bron. > > On Sat, Feb 8, 2020, at 04:04, Alexey Melnikov wrote: >> Hi Bron, >> Replying to issues raised not covered by my reply to Timo: >> On 29/01/2020 12:08, Bron Gondwana wrote: >>> Sorry about the delay in doing this! I was supposed to be doing the shepherding write-up, and so I figured I should read it properly. >>> >>> I've had a full read through over some very many days (I admit, I skimmed through the ABNF) and I have comments. It's long, and hopefully comprehensive - though I'm sure I missed things. >>> >>> >>> *2.1 Link level* >>> >>> Is it appropriate to mention TLS on 993 here? It's mentioned deep within the document, but not here. >> Done. >> >>> *2.3.2 Flags Message Attribute* >>> >>> formatting issue: $Forwarded is duplicated 3 times and $MDNSent is duplicated twice in the plain-text format. >> This is actually a bug in TXT rendering from XML. >> [snip] >>> *6.3.1 ENABLE command* >>> >>> The example shows a conversation with an imap4rev1 only server. >> Fixed. >> >>> The examples don't clearly show that only the newly enabled responses are correct, e.g. the sequence: >>> >>> C1 ENABLE CONDSTORE >>> * ENABLED CONDSTORE >>> C1 OK foo >>> C2 ENABLE CONDSTORE QRESYNC >>> * ENABLED QRESYNC >>> C2 OK foo >>> >>> The second doesn't say "ENABLED CONDSTORE" because it was already enabled earlier on this connection. >> Actually, it is perfectly Ok for the server to return in response to C2: >> * ENABLED QRESYNC CONDSTORE >> >> The text in the document wasn't entirely clear. It was trying to say that the preferred server behaviour is: >> >> L1 ENABLE A B >> * ENABLED A B >> L1 OK foo >> >> L2 ENABLE C >> * ENABLED C >> L2 OK foo >> >> and not >> >> L2 ENABLE C >> * ENABLED A B C >> L2 OK foo >> >> I clarified this. >>> >>> (AKA: clients MUST remember what they have enabled) >>> >>> *6.3.2 SELECT command* >>> >>> The [UIDNEXT ] response is duplicated with two different pieces of text. >> Again, this is a tool issue. >> >>> *When deselecting a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox *is closed (see Paragraph 10). ***- I'm not sure where "Paragraph 10" is.* >> I will check. I think the section reference for response codes is missing. >> >>> The last paragraph of this section has the word "deprecated" spelled as "depractated". >> Fixed. >> >>> >>> *6.3.7 SUBSCRIBE* >>> >>> Speak of the devil. Lots of sites violate the MUST NOT unilaterally remove rule. Should we weaken it to SHOULD? >> Done. >> >>> The justification for the MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want. >>> >>> (also: by enabling a non-default break the rules config, it's what our server does!) >>> >>> *6.3.8 UNSUBSCRIBE* >>> >>> *This command returns a tagged OK response only if the unsubscription is successful. *- this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error? >>> >>> For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed - and likewise for subscribe if it's already subscribed it just say "yep, all good". >> I agree that your server behaviour is sensible. Updated description of both SUBSCRIBE and UNSUBSCRIBE. >> >>> >>> . create INBOX.foo >>> . OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed >>> . subscribe INBOX.foo >>> . OK Completed >>> . unsubscribe INBOX.foo >>> . OK Completed >>> . unsubscribe INBOX.foo >>> . OK Completed >>> . subscribe INBOX.foo >>> . OK Completed >>> . subscribe INBOX.foo >>> . OK Completed >>> >>> >>> *6.3.9 LIST* >>> >>> There's a weird line wrapping near the top of page 44 where a paragraph is split in half: >>> >>> The reference and mailbox name arguments are interpreted into a canonical form that represents an unambiguous left-to-right hierarchy. The returned mailbox names will be in the interpreted form, that we call "canonical LIST pattern" later in this document. To define the term "canonical LIST pattern" formally: it refers to the canonical pattern constructed internally by the server from the reference and mailbox name arguments. >>> >> I will double check, but I think it is another rendering issue to TXT format (there is a comment in bettween 2 parts of the sentence. >> >>> >>> *6.3.9.2 LIST Return Options* >>> >>> The CHILDREN item is duplicated with two different pieces of text. >> Again, a rendering issue. These are actually 2 separate paragraphs under the same item. >> >>> *6.4.4 SEARCH* >>> >>> For example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all deleted messages from Smith that were placed in the mailbox since February 1, 1994. >>> >>> >>> That's not strictly true - SAVEDATE would be "placed in the mailbox". The wording should say "with INTERNALDATE greater than February 1, 1994" or so. >> Good point. Fixed. >> >>> *6.4.4.1 SAVE Result* >>> >>> I'm not sure I understand the interaction here with closing and re-opening a mailbox. I would expect that closing a mailbox would wipe the SAVED result, and that trying to use a SAVED result when there isn't one should return an error. >> I think Timo explained this well in his response. >> >> >> [snip] >>> >>> *7.1 Status Responses* >>> >>> Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks like an attempt to do dot points! >> Changed :-). >> >> [snip] >> Best Regards, >> Alexey >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >> > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --5bcae40328e94799b81f2a007e0916fe Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I have reviewed all the changes from -12 to -15 and a= m still mostly happy :)  I haven't reviewed -15 in full because it'= s a big job!

Regarding the changes in -13, I have a coupl= e of small things:

=
Regarding unsolicited fetch:=

= If the server chooses to send unsolicited FETCH responses, they MUST include UID FETCH item.  Note that this = is a new requirement when compared to RFC 3501.

Th= is could do with a clarification that this only applies after "ENABLED I= MAP4REV2".

Regarding SELECT allowing non-canonical nam= es:

We've already discussed the list response = to CREATE.  Should SELECT also return the canonical representation = of the mailbox name as part of the reply?

Next steps:<= /b>

Alexey - are there any other changes still wai= ting before we do a working group last call?

Thanks,
<= /div>

Bron.

On Fri, Feb 14, 2020, at 10:47, Bron = Gondwana wrote:
=
Thanks Alexey, I see there's a -12 the= re now, and I'm happy with all the edits in it :)

There a= re still some outstanding points from this thread - are you expecting to= issue a -13 for those?

<= /div>
Thanks,

Bron.
<= /div>

On Sat, Feb 8, 202= 0, at 04:04, Alexey Melnikov wrote:

Hi Bron,

Replying to issues raised not covered= by my reply to Timo:

On 29/= 01/2020 12:08, Bron Gondwana wrote:
Sorry about the delay in doing this!   I was supposed to be doing the shepherding wri= te-up, and so I figured I should read it properly.

I've had = a full read through over some very many days (I admit, I skimmed through the ABNF) and I have comments.  It's long, and hopefully comprehensive - th= ough I'm sure I missed things.


2.1 Link level

Is it appropri= ate to mention TLS on 993 here?  It's mentioned deep within the document, but = not here.
Done.

<= blockquote cite=3D"mid:9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fast= mail.com" type=3D"cite">
2.3.2 Flags= Message Attribute

formatting issue: $Forwarded is duplicated 3 times and $MDNSent is duplicated twice in the plain-text format.

This is actually a b= ug in TXT rendering from XML.

 [snip]

6.3.1 ENABLE command

The example shows a conversation with an imap4rev1 only server.
Fixed.=

The examples don't clearly show that only the newly enabled responses are correct, e.g. the sequence:

<= div style=3D"font-family:Arial;">C1 ENABLE CONDSTORE
* ENABLED CONDSTORE
C1 OK foo
C2 E= NABLE CONDSTORE QRESYNC
* ENA= BLED QRESYNC
C2 OK foo

The second doesn't say "ENABLED CONDSTORE" because it was already enabled earlier on this connection.

Actually, it is per= fectly Ok for the server to return in response to C2:

* ENABLED QRESYNC = CONDSTORE

The text in the document wasn't entirely clear. It was trying to say that the preferred server behaviour is:

L1 = ENABLE A B
* ENABLED A B
<= /div>
L1 OK foo

L2 ENABL= E C
* ENABLED C
L2 OK foo

and not

L2 ENABLE C
= * ENABLED A B C
L2 OK foo
=

I clarified this.

(AKA: clients MUST rem= ember what they have enabled)

6.3.2 SELECT comman= d

The [UIDNEXT <n>] response is duplicated with two different pieces of text.
Again, this is a tool issue.

When deselecting = a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox is closed (see Paragraph 10). - I'm not sure where "Paragraph 10" is.
I will check. I think the section reference for response codes is missing.

The last paragraph of this section has the word "deprecated" spelled as "depractated".
Fixed.

<= div>
6.3.7 SUBSCRIBE

Speak of the devil.  Lots of sites violate the MUST NOT unilaterally remove rule.  Should we w= eaken it to SHOULD?
Done.
 = The justification for the MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want.

(also: by enabli= ng a non-default break the rules config, it's what our server does!)

6.3.8 UNSUBSCRIBE
<= br>
This command returns a tag= ged OK response only if the unsubscription is successful. - this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error?

<= /div>
For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed -= and likewise for subscribe if it's already subscribed it just say "yep, all good".
I agree that you= r server behaviour is sensible. Updated description of both SUBSCRIBE and UNSUBSCRIBE.


. create INBOX.foo
. OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed
. subscribe INBOX.foo
. OK Completed
. unsubscribe INBOX.foo
. OK Completed
. unsubscrib= e INBOX.foo
. OK Completed
. subscribe INBOX.foo
=
. OK Completed
. subscribe INBOX.foo
. OK Completed
<= br>

6.3.9 LIST

There's a weird line wra= pping near the top of page 44 where a paragraph is split in half:
= 

   The reference and ma=
ilbox name arguments are interpreted into a
   canonical form that represents an unambiguous left-to-right
   hierarchy.  The returned mailbox names will be in the interpreted
   form,

   that we call "canonical LIST pattern" later in this document.  To
   define the term "canonical LIST pattern" formally: it refers to the
   canonical pattern constructed internally by the server from the
   reference and mailbox name arguments.
I will double check, but I think it is anoth= er rendering issue to TXT format (there is a comment in bettween 2 parts of the sentence.<= br>


6.3.9.2 LIST R= eturn Options

<= div style=3D"font-family:Arial;">The CHILDREN item is duplicated with two different pieces of text.

Agai= n, a rendering issue. These are actually 2 separate paragraphs under the same item.


6.4.4 SEARCH

= 
   For example,
   the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
   deleted messages from Smith that were placed in the mailbox since
   February 1, 1994.

That's not strictly true - SAVEDATE would be "placed in the mailbox".  The wording sho= uld say "with INTERNALDATE greater than February 1, 1994" or so.
=

Good point. Fixed.


6.4.4.1 SAVE Result=

I'm not sure I understand the interaction here with closing and re-opening a mailbox.  I = would expect that closing a mailbox would wipe the SAVED result, and that trying to use a SAVED result when there isn't one should return an error.
I think Timo explain= ed this well in his response.


=  [snip]


7.1 Status Respons= es

Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks like an attempt to do dot points!
Changed :-).

 [snip]

Best Regards,

Alexey
=

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


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


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


--5bcae40328e94799b81f2a007e0916fe-- From nobody Thu Jul 9 03:34:13 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 528DA3A0829 for ; Thu, 9 Jul 2020 03:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 VxMByFSdKhyh for ; Thu, 9 Jul 2020 03:34:09 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 827B13A082B for ; Thu, 9 Jul 2020 03:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594290848; d=isode.com; s=june2016; i=@isode.com; bh=8uPEN+mZ5lax+kFyHEG5kk4TDQYnX/MvMgf7OOsSoqY=; 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=Jn2sa9qWO8JEUCx5oecNpCPnsCG6+2kUdmhmXcbskqSq7colRFQPPYFOnFChTPplv6d1nD pSP4lxk4UgVgVWZd3o6/MeeM+OvkK/fHoTXzHUDFGf25uwmXGuzwn1kLQGFHSjJvMdTSFM lwUu+adnMSFacuY/1GBodnyJT1foNt8=; Received: from [172.27.254.202] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 9 Jul 2020 11:34:08 +0100 To: Bron Gondwana , extra@ietf.org References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <345e934f-e540-4b42-bd5e-8c1e1f6965f8@www.fastmail.com> <3da1a65d-4825-426a-8b6d-70f0e923310e@dogfood.fastmail.com> From: Alexey Melnikov Message-ID: Date: Thu, 9 Jul 2020 11:33:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <3da1a65d-4825-426a-8b6d-70f0e923310e@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------453512003D9B53847427F364" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 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, 09 Jul 2020 10:34:12 -0000 --------------453512003D9B53847427F364 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Bron, On 08/07/2020 13:58, Bron Gondwana wrote: > I have reviewed all the changes from -12 to -15 and am still mostly=20 > happy :)=C2=A0 I haven't reviewed -15 in full because it's a big job! > > Regarding the changes in -13, I have a couple of small things: > > *Regarding unsolicited fetch:** > * > > If the server chooses to send unsolicited FETCH responses, they=20 > MUST=C2=A0include UID FETCH item.=C2=A0 Note that this is a new requiremen= t when=20 > compared to RFC 3501. > > This could do with a clarification that this only applies after=20 > "ENABLED IMAP4REV2". Actually, in this one case: I don't think so. It shouldn't break any old=20 (IMAP4rev1 only) clients to return this. But this made me think: Maybe the document needs a new section that list=20 everything that the server should do after ENABLED IMAP4rev2? > *Regarding SELECT allowing non-canonical names:** > * > > We've already discussed the list response to CREATE.=C2=A0 Should SELECT= =20 > also return the canonical representation of the mailbox name as part=20 > of the reply? This will be again returning an untagged LIST response on SELECT. I will add it to my to do list. > > *Next steps:** > * > > Alexey - are there any other changes still waiting before we do a=20 > working group last call? > > Thanks, > > Bron. > > On Fri, Feb 14, 2020, at 10:47, Bron Gondwana wrote: >> Thanks Alexey, I see there's a -12 there now, and I'm happy with all=20 >> the edits in it :) >> >> There are still some outstanding points from this thread - are you=20 >> expecting to issue a -13 for those? >> >> Thanks, >> >> Bron. >> >> On Sat, Feb 8, 2020, at 04:04, Alexey Melnikov wrote: >>> >>> Hi Bron, >>> >>> Replying to issues raised not covered by my reply to Timo: >>> >>> On 29/01/2020 12:08, Bron Gondwana wrote: >>>> Sorry about the delay in doing this!=C2=A0=C2=A0 I was supposed to be d= oing=20 >>>> the shepherding write-up, and so I figured I should read it properly. >>>> >>>> I've had a full read through over some very many days (I admit, I=20 >>>> skimmed through the ABNF) and I have comments.=C2=A0 It's long, and=20 >>>> hopefully comprehensive - though I'm sure I missed things. >>>> >>>> >>>> *2.1 Link level* >>>> >>>> Is it appropriate to mention TLS on 993 here?=C2=A0 It's mentioned deep= =20 >>>> within the document, but not here. >>> Done. >>> >>>> *2.3.2 Flags Message Attribute* >>>> >>>> formatting issue: $Forwarded is duplicated 3 times and $MDNSent is=20 >>>> duplicated twice in the plain-text format. >>> >>> This is actually a bug in TXT rendering from XML. >>> >>> =C2=A0[snip] >>> >>>> *6.3.1 ENABLE command* >>>> >>>> The example shows a conversation with an imap4rev1 only server. >>> Fixed. >>> >>>> The examples don't clearly show that only the newly enabled=20 >>>> responses are correct, e.g. the sequence: >>>> >>>> C1 ENABLE CONDSTORE >>>> * ENABLED CONDSTORE >>>> C1 OK foo >>>> C2 ENABLE CONDSTORE QRESYNC >>>> * ENABLED QRESYNC >>>> C2 OK foo >>>> >>>> The second doesn't say "ENABLED CONDSTORE" because it was already=20 >>>> enabled earlier on this connection. >>> >>> Actually, it is perfectly Ok for the server to return in response to C2: >>> >>> * ENABLED QRESYNC CONDSTORE >>> >>> The text in the document wasn't entirely clear. It was trying to say=20 >>> that the preferred server behaviour is: >>> >>> L1 ENABLE A B >>> * ENABLED A B >>> L1 OK foo >>> >>> L2 ENABLE C >>> * ENABLED C >>> L2 OK foo >>> >>> and not >>> >>> L2 ENABLE C >>> * ENABLED A B C >>> L2 OK foo >>> >>> I clarified this. >>>> >>>> (AKA: clients MUST remember what they have enabled) >>>> >>>> *6.3.2 SELECT command* >>>> >>>> The [UIDNEXT ] response is duplicated with two different pieces=20 >>>> of text. >>> Again, this is a tool issue. >>> >>>> /When deselecting a selected mailbox, the server MUST return an=20 >>>> untagged OK response with the "[CLOSED]" response code when the=20 >>>> currently selected mailbox *is closed (see Paragraph 10). */*- I'm=20 >>>> not sure where "Paragraph 10" is.* >>> I will check. I think the section reference for response codes is=20 >>> missing. >>> >>>> The last paragraph of this section has the word "deprecated"=20 >>>> spelled as "depractated". >>> Fixed. >>> >>>> >>>> *6.3.7 SUBSCRIBE* >>>> >>>> Speak of the devil.=C2=A0 Lots of sites violate the MUST NOT=20 >>>> unilaterally remove rule. Should we weaken it to SHOULD? >>> Done. >>> >>>> =C2=A0 The justification for the MUST is "the server site might choose= =20 >>>> to do X" - well, if the server site is doing that, then maybe they=20 >>>> SHOULDN'T unilaterally remove the subscriptions, but otherwise it's=20 >>>> a better user experience and what people want. >>>> >>>> (also: by enabling a non-default break the rules config, it's what=20 >>>> our server does!) >>>> >>>> *6.3.8 UNSUBSCRIBE* >>>> >>>> /This command returns a tagged OK response only if the=20 >>>> unsubscription is successful. /- this is not clear on what happens=20 >>>> if the mailbox is not currently subscribed - does it silently=20 >>>> succeed, or is there an expected error? >>>> >>>> For what it's worth, our server just says "OK Completed" even if=20 >>>> it's already been unsubscrbed - and likewise for subscribe if it's=20 >>>> already subscribed it just say "yep, all good". >>> I agree that your server behaviour is sensible. Updated description=20 >>> of both SUBSCRIBE and UNSUBSCRIBE. >>> >>>> >>>> . create INBOX.foo >>>> . OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed >>>> . subscribe INBOX.foo >>>> . OK Completed >>>> . unsubscribe INBOX.foo >>>> . OK Completed >>>> . unsubscribe INBOX.foo >>>> . OK Completed >>>> . subscribe INBOX.foo >>>> . OK Completed >>>> . subscribe INBOX.foo >>>> . OK Completed >>>> >>>> >>>> *6.3.9 LIST* >>>> >>>> There's a weird line wrapping near the top of page 44 where a=20 >>>> paragraph is split in half: >>>> >>>> The reference and mailbox name arguments are interpreted into a >>>> canonical form that represents an unambiguous left-to-right >>>> hierarchy. The returned mailbox names will be in the interpreted >>>> form, >>>> >>>> that we call "canonical LIST pattern" later in this document. To >>>> define the term "canonical LIST pattern" formally: it refers to the >>>> canonical pattern constructed internally by the server from the >>>> reference and mailbox name arguments. >>>> >>> I will double check, but I think it is another rendering issue to=20 >>> TXT format (there is a comment in bettween 2 parts of the sentence. >>> >>>> >>>> *6.3.9.2 LIST Return Options* >>>> >>>> The CHILDREN item is duplicated with two different pieces of text. >>> >>> Again, a rendering issue. These are actually 2 separate paragraphs=20 >>> under the same item. >>> >>> >>>> *6.4.4 SEARCH* >>>> >>>> For example, >>>> the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all >>>> deleted messages from Smith that were placed in the mailbox since >>>> February 1, 1994. >>>> >>>> >>>> That's not strictly true - SAVEDATE would be "placed in the=20 >>>> mailbox".=C2=A0 The wording should say "with INTERNALDATE greater than= =20 >>>> February 1, 1994" or so. >>> >>> Good point. Fixed. >>> >>> >>>> *6.4.4.1 SAVE Result* >>>> >>>> I'm not sure I understand the interaction here with closing and=20 >>>> re-opening a mailbox.=C2=A0 I would expect that closing a mailbox would= =20 >>>> wipe the SAVED result, and that trying to use a SAVED result when=20 >>>> there isn't one should return an error. >>> I think Timo explained this well in his response. >>> >>> >>> =C2=A0[snip] >>> >>>> >>>> *7.1 Status Responses* >>>> >>>> Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks=20 >>>> like an attempt to do dot points! >>> Changed :-). >>> >>> =C2=A0[snip] >>> >>> Best Regards, >>> >>> Alexey >>> >>> _______________________________________________ >>> Extra mailing list >>> Extra@ietf.org >>> https://www..ietf.org/mailman/listinfo/extra >>> >> >> -- >> =C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd >> =C2=A0 brong@fastmailteam.com >> >> > > -- > =C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd > =C2=A0 brong@fastmailteam.com > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra --------------453512003D9B53847427F364 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Bron,

On 08/07/2020 13:58, Bron Gondwana wrote:
I have reviewed all the changes from -12 to -15 and am still mostly happy :)=C2=A0 I haven't reviewe= d -15 in full because it's a big job!

Regarding the changes in -13, I have a couple of small things:

Regarding unsolicited fetch:<= b>

If the server chooses to send unsolicited FETCH responses, they MUST=C2= =A0include UID FETCH item.=C2=A0 Note that this is a new requirement when compared to RFC 3501.

This could do with a clarification that this only applies after "ENABLED IMAP4REV2".

Actually, in this one case: I don't think so. It shouldn't break any old (IMAP4rev1 only) clients to return this.

But this made me think: Maybe the document needs a new section that list everything that the server should do after ENABLED IMAP4rev2?

Regarding SELECT allowing non-canonical names:

We've already discussed the list response to CREATE.=C2=A0 Should SELECT also return the canonical representation of the mailbox name as part of the reply?

This will be again returning an untagged LIST response on SELECT.

I will add it to my to do list.


Next steps:

Alexey - are there any other changes still waiting before we do a working group last call?

Thanks,

Bron.

On Fri, Feb 14, 2020, at 10:47, Bron Gondwana wrote:
Thanks Alexey, I see there's a -12 there now, and I'm happy with all the edits in it :)

There are still some outstanding points from this thread - are you expecting to issue a -13 for those?

Thanks,

Bron.

On Sat, Feb 8, 2020, at 04:04, Alexey Melnikov wrote:

Hi Bron,

Replying to issues raised not covered by my reply to Timo:

On 29/01/2020 12:08, Bron Gondwana wrote:
Sorry about the delay in doing this!=C2=A0=C2=A0 I was supposed to be doing the shepher= ding write-up, and so I figured I should read it properly.

I've had a full read through over some very many days (I admit, I skimmed through the ABNF) and I have comments.=C2=A0 It's long, and hopefully comprehensive - though I'm sure I missed things.


2.1 Link level

Is it appropriate to mention TLS on 993 here?=C2=A0 It's mentioned deep within the document= , but not here.
Done.

2.3.2 Flags Message Attribute

formatting issue: $Forwarded is duplicated 3 times and $MDNSent is duplicated twice in the plain-text format.

This is actually a bug in TXT rendering from XML.

=C2=A0[snip]

6.3.1 ENABLE command

The example shows a conversation with an imap4rev1 only server.
Fixed.

The examples don't clearly show that only the newly enabled responses are correct, e.g. the sequence:

C1 ENABLE CONDSTORE
* ENABLED CONDSTORE
C1 OK foo
C2 ENABLE CONDSTORE QRESYNC
* ENABLED QRESYNC
C2 OK foo

The second doesn't say "ENABLED CONDSTORE" because it was already enabled earlier on this connection.

Actually, it is perfectly Ok for the server to return in response to C2:

* ENABLED QRESYNC CONDSTORE

The text in the document wasn't entirely clear. It was trying to say that the preferred server behaviour is:

L1 ENABLE A B
* ENABLED A B
L1 OK foo

L2 ENABLE C
* ENABLED C
L2 OK foo

and not

L2 ENABLE C
* ENABLED A B C
L2 OK foo

I clarified this.

(AKA: clients MUST remember what they have enabled)

6.3.2 SELECT command

The [UIDNEXT <n>] response is duplicated with two different pieces of text.
Again, this is a tool issue.

When deselecting a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox is closed (see Paragraph 10). - I'm not sure where "Paragraph 10" is.
I will check. I think the section reference for response codes is missing.

The last paragraph of this section has the word "deprecated" spelled as "depractated".
Fixed.


6.3.7 SUBSCRIBE

Speak of the devil.=C2=A0 Lots= of sites violate the MUST NOT unilaterally remove rule.=C2=A0 Should we weaken it to SHOULD?
Done.

=C2=A0 The justification for t= he MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want.

(also: by enabling a non-default break the rules config, it's what our server does!)

6.3.8 UNSUBSCRIBE

This command returns a tagged OK response only if the unsubscription is successful. - this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error?

For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed - and likewise for subscribe if it's already subscribed it just say "yep, all good".
I agree that your server behaviour is sensible. Updated description of both SUBSCRIBE and UNSUBSCRIBE.


. create INBOX.foo
. OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed
. subscribe INBOX.foo
. OK Completed
. unsubscribe INBOX.foo
. OK Completed
. unsubscribe INBOX.foo
. OK Completed
. subscribe INBOX.foo
. OK Completed
. subscribe INBOX.foo
. OK Completed


6.3.9 LIST

There's a weird line wrapping near the top of page 44 where a paragraph is split in half:

   The reference and mailbox name arguments are interpreted=
 into a
   canonical form that represents an unambiguous left-to-right
   hierarchy.  The returned mailbox names will be in the interpreted
   form,

   that we call "canonical LIST pattern" later in this document.  To
   define the term "canonical LIST pattern" formally: it refers to the
   canonical pattern constructed internally by the server from the
   reference and mailbox name arguments.
I will double check, but I think it is another rendering issue to TXT format (there is a comment in bettween 2 parts of the sentence.


6.3.9.2 LIST Return Options

The CHILDREN item is duplicated with two different pieces of text.

Again, a rendering issue. These are actually 2 separate paragraphs under the same item.


6.4.4 SEARCH

   For example,
   the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
   deleted messages from Smith that were placed in the mailbox since
   February 1, 1994.

That's not strictly true - SAVEDATE would be "placed in the mailbox".=C2=A0 The wording should say "with INTERNALDATE greater than February 1, 1994" or so.

Good point. Fixed.


6.4.4.1 SAVE Result

I'm not sure I understand the interaction here with closing and re-opening a mailbox.=C2=A0 I would expect that closing a mailbox would wip= e the SAVED result, and that trying to use a SAVED result when there isn't one should return an error.
I think Timo explained this well in his response.


=C2=A0[snip]


7.1 Status Responses

Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks like an attempt to do dot points!
Changed :-).

=C2=A0[snip]

Best Regards,

Alexey

_______________________________________________
Extra mailing list


--
=C2=A0 Bron Gondwana, CEO, Fastmail Pt= y Ltd
=C2=A0 brong@fastmailteam.com



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



_______________________________=
________________
Extra mailing list
Extra@i=
etf.org
https://www.ietf.org/mailman/listinfo/extra
--------------453512003D9B53847427F364-- From nobody Thu Jul 9 04:03:41 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 229E43A08AA for ; Thu, 9 Jul 2020 04:03:40 -0700 (PDT) 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=Um1j60jz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GhYrpKZn 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 XXo084KHV9Yy for ; Thu, 9 Jul 2020 04:03:38 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29A33A08AB for ; Thu, 9 Jul 2020 04:03:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3766A5C00CD; Thu, 9 Jul 2020 07:03:36 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Thu, 09 Jul 2020 07:03:36 -0400 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:subject:content-type; s=fm3; bh=jHP/NWM Z34+9uigtr5Cz1X4hirDr8l7fz21tazF7RGs=; b=Um1j60jzmKiuR4iwvkAGvuJ To27sOushBuceFDXYJZM6WfkhkQXGRuBwm3WTYxVlVZvrcWxh41GJCe7y9XSXXrH scBLjjL1xuUr3+GHu7VjSJ9TVXkHRLBdpP7RqwuShAeTS66o24CgSf1aBVsf47lW dgSB9zq7RzIJstkzLzUANX4o+3cqs4aR3mPh0lZB4kG/Or44JZI+8Azkhh6XQDy7 7MAVdBprOmZyxtCF92FbLuoRd4G/nyTaWbz0HsM/ejYsZzLb0jVj/PCppKT67toK 9GIuKJ/ahWHb/a9HS6K7GEyHVlJHtixs9jKMgZhABEUp+KNh7ISGZ7SN0VkCvog= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jHP/NW MZ34+9uigtr5Cz1X4hirDr8l7fz21tazF7RGs=; b=GhYrpKZnpdA8EkuQr0gJ9G HMgCCpW+ZTiMo/yCbu9kMHHnTI709wQAwJ9Srgh1Z/QxCTPWmwSk+QyFQX+UsEis ElaVQKIyzpYYgq53P7U8gzJl/TUbn2LgSzk5hIXsDalTvW7eKCVhQrRzACd3kkhy HgtnwnH91rh544hphD587TUHB1kZ51QwhD+FohIYmm8M0D4Quna4tdM1XC2xF1Bg 9aHruaNpz1Az65yIqSk/eW/nkAq6nj8xGl0C4QiNzhhsUxvx/Zv2b8NRqNcFehBQ ymkbrBhhaaP9FPnAPOUdxtcxEVZQDHH31Nf4CSVmeCzJiYDq6OlqHGLu+9eBA9DA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudelgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpedvudeuieehgfdvheeuueejjeeuudfgiefgveetfeelteef fffgtdejjefgueduvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7AD4C4AA005D; Thu, 9 Jul 2020 07:03:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-637-g57f734b-fm-idx2020-20200709.002-g57f734bf Mime-Version: 1.0 Message-Id: <4429b64a-d767-4483-9d03-98e87dce89bd@dogfood.fastmail.com> In-Reply-To: References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <345e934f-e540-4b42-bd5e-8c1e1f6965f8@www.fastmail.com> <3da1a65d-4825-426a-8b6d-70f0e923310e@dogfood.fastmail.com> Date: Thu, 09 Jul 2020 21:03:14 +1000 From: "Bron Gondwana" To: "Alexey Melnikov" , extra@ietf.org Content-Type: multipart/alternative; boundary=a43bfb5214f545cfbe5ea3114419a98c Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 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, 09 Jul 2020 11:03:40 -0000 --a43bfb5214f545cfbe5ea3114419a98c Content-Type: text/plain On Thu, Jul 9, 2020, at 20:33, Alexey Melnikov wrote: > Hi Bron, > On 08/07/2020 13:58, Bron Gondwana wrote: >> I have reviewed all the changes from -12 to -15 and am still mostly happy :) I haven't reviewed -15 in full because it's a big job! >> >> Regarding the changes in -13, I have a couple of small things: >> >> *Regarding unsolicited fetch:*** >> >> If the server chooses to send unsolicited FETCH responses, they MUST include UID FETCH item. Note that this is a new requirement when compared to RFC 3501. >> >> This could do with a clarification that this only applies after "ENABLED IMAP4REV2". > Actually, in this one case: I don't think so. It shouldn't break any old (IMAP4rev1 only) clients to return this. I don't even remember which client it bothered, but I remember one of them didn't like it. Maybe it just didn't like it if you added UID to explicit FETCH when you didn't ask for it, not sure. > But this made me think: Maybe the document needs a new section that list everything that the server should do after ENABLED IMAP4rev2? >> *Regarding SELECT allowing non-canonical names:*** >> >> We've already discussed the list response to CREATE. Should SELECT also return the canonical representation of the mailbox name as part of the reply? > This will be again returning an untagged LIST response on SELECT. > I will add it to my to do list. Yeah, that makes sense. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --a43bfb5214f545cfbe5ea3114419a98c Content-Type: text/html
On Thu, Jul 9, 2020, at 20:33, Alexey Melnikov wrote:

Hi Bron,

On 08/07/2020 13:58, Bron Gondwana wrote:
I have reviewed all the changes from -12 to -15 and am still mostly happy :)  I haven't reviewed -15 in full because it's a big job!

Regarding the changes in -13, I have a couple of small things:

Regarding unsolicited fetch:

If the server chooses to send unsolicited FETCH responses, they MUST include UID FETCH item.  Note that this is a new requirement when compared to RFC 3501.

This could do with a clarification that this only applies after "ENABLED IMAP4REV2".

Actually, in this one case: I don't think so. It shouldn't break any old (IMAP4rev1 only) clients to return this.


I don't even remember which client it bothered, but I remember one of them didn't like it.

Maybe it just didn't like it if you added UID to explicit FETCH when you didn't ask for it, not sure.

But this made me think: Maybe the document needs a new section that list everything that the server should do after ENABLED IMAP4rev2?

Regarding SELECT allowing non-canonical names:

We've already discussed the list response to CREATE.  Should SELECT also return the canonical representation of the mailbox name as part of the reply?

This will be again returning an untagged LIST response on SELECT.

I will add it to my to do list.


Yeah, that makes sense.

Cheers,

Bron.

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


--a43bfb5214f545cfbe5ea3114419a98c-- From nobody Thu Jul 9 23:44:55 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 2F99D3A0DD1 for ; Thu, 9 Jul 2020 23:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ra8tVeYtQLHL for ; Thu, 9 Jul 2020 23:44:51 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2462E3A0DCE for ; Thu, 9 Jul 2020 23:44:50 -0700 (PDT) Received: from [192.168.10.110] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 4CE6B2B3C8B; Fri, 10 Jul 2020 06:44:49 +0000 (UTC) From: Timo Sirainen Message-Id: <94C68CF3-1B2C-425B-8EE3-D31AEB2AE1C8@sirainen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2C0D1EBB-CD16-4986-B69D-04BB9F8E8F51" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 10 Jul 2020 09:44:48 +0300 In-Reply-To: <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> Cc: Bron Gondwana , extra@ietf.org To: Alexey Melnikov References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 06:44:53 -0000 --Apple-Mail=_2C0D1EBB-CD16-4986-B69D-04BB9F8E8F51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6. Jul 2020, at 20.38, Alexey Melnikov = wrote: >=20 > On 17/06/2020 13:27, Bron Gondwana wrote: >=20 >> On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >>>> 1) abandon use of this response code (and use a new response = instead), e.g. >>>>=20 >>>> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >>>>=20 >>>> This would require clients to ignore an extra response, if they = don't recognize it. >>>>=20 >>>=20 >>> Somehow I've a feeling that there are going to be clients that will = break if they see these kind of unknown untagged replies. But that's = just a guess, so maybe not. We could of course send it only when client = has used ENABLE IMAP4REV2 and then there wouldn't be any problems. >>=20 >> I like this. Only send if IMAP4REV2 is enabled and all[tm] your = problems go away. > Following on the suggestion to use LIST extended data items for this >=20 > C: C04 create NonCannonicalName > S: * LIST () "/" "CannonicalName" ("TAG" ("C04")) > S: C04 OK done >=20 > In the example above imagine that "CannonicalName" is the canonical = (normalized) version of "NonCannonicalName" >=20 > And the corresponding ABNF: >=20 > tag-extended-item =3D "TAG" SP "(" tag-string ")" > ; Complies with <mbox-list-extended-item> > ; The value complies with <tagged-ext-val> > ; The value is the tag of the corresponding > ; CREATE command. >=20 > And a similar extended data item can be used to return MAILBOXID (when = supported). >=20 > Does this work for people? >=20 OK. But should we return this always or only when canonical name = changes? With MAILBOXID at least always. I guess it could be nice to do = it always in any case so clients don't forget to support it. But in SELECT case perhaps only return it on name change? --Apple-Mail=_2C0D1EBB-CD16-4986-B69D-04BB9F8E8F51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 6. Jul 2020, at 20.38, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On = 17/06/2020 13:27, Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote:

1) abandon use of this response code = (and use a new response instead), e.g.

* = CREATED "a123" "Denormalized name" MAILBOXID "123456"

 This would require clients to = ignore an extra response, if they don't recognize it.


Somehow I've a feeling that there are = going to be clients that will break if they see these kind of unknown = untagged replies. But that's just a guess, so maybe not. We could of = course send it only when client has used ENABLE IMAP4REV2 and then there = wouldn't be any problems.

I like this.  Only send if = IMAP4REV2 is enabled and all[tm] your problems go away.

Following on the suggestion to use = LIST extended data items for this

      C: C04 create = NonCannonicalName
      S: * LIST = () "/" "CannonicalName" ("TAG" ("C04"))
      S: C04 OK done

In = the example above imagine that "CannonicalName" is the canonical = (normalized) version of "NonCannonicalName"

And the corresponding ABNF:

tag-extended-item =3D "TAG" SP "(" tag-string = ")"
   ; Complies with = &lt;mbox-list-extended-item&gt;
   ; The = value complies with &lt;tagged-ext-val&gt;
   ; The value is the tag of the corresponding
   ; CREATE command.

And a similar extended data item can = be used to return MAILBOXID (when supported).

Does = this work for people?


OK. = But should we return this always or only when canonical name changes? = With MAILBOXID at least always. I guess it could be nice to do it always = in any case so clients don't forget to support it.

But in SELECT case perhaps only return it on = name change?

= --Apple-Mail=_2C0D1EBB-CD16-4986-B69D-04BB9F8E8F51-- From nobody Fri Jul 10 03:48: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 329393A08BB for ; Fri, 10 Jul 2020 03:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 uyv6LcVL0_Dx for ; Fri, 10 Jul 2020 03:48:01 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C77B23A08B7 for ; Fri, 10 Jul 2020 03:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594378081; d=isode.com; s=june2016; i=@isode.com; bh=eIj0hlHiDAVE0WwWyDM3cRulGjX8wmqyx9OJW2utwwI=; 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=lhh6LpENaKeOT1OxrUaJ+m3ZRiXHlsFprFLxocRN6CUkVhA61vGS3v5U9Q4OEIBV/g/3ej 7jQEa3Tyn5ClS3KQ5ut+PIGcDcoTLkW8AAHS9BUnuqZ/cuFCKDVB0Rkwg0M086U98N27GM w7oP6I2zaLee7F9GuIoyO0fCHlLHlpM=; Received: from [172.27.254.207] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 10 Jul 2020 11:48:00 +0100 From: Alexey Melnikov To: Bron Gondwana , extra@ietf.org References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> <178ba905-36d9-493e-a02f-ac1a91f3ae68@dogfood.fastmail.com> Message-ID: Date: Fri, 10 Jul 2020 11:47:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <178ba905-36d9-493e-a02f-ac1a91f3ae68@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F953B8A3472B7F3BFB5D856A" Content-Language: en-GB Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 10:48:03 -0000 --------------F953B8A3472B7F3BFB5D856A Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 07/07/2020 00:30, Bron Gondwana wrote: > On Tue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote: >> >> On 17/06/2020 13:27, Bron Gondwana wrote: >> >>> On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >>>>> >>>>> 1) abandon use of this response code (and use a new response=20 >>>>> instead), e.g. >>>>> >>>>> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >>>>> >>>>> =C2=A0This would require clients to ignore an extra response, if they= =20 >>>>> don't recognize it. >>>>> >>>> >>>> Somehow I've a feeling that there are going to be clients that will=20 >>>> break if they see these kind of unknown untagged replies. But=20 >>>> that's just a guess, so maybe not. We could of course send it only=20 >>>> when client has used ENABLE IMAP4REV2 and then there wouldn't be=20 >>>> any problems. >>> >>> I like this.=C2=A0 Only send if IMAP4REV2 is enabled and all[tm] your=20 >>> problems go away. >> >> Following on the suggestion to use LIST extended data items for this >> >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C: C04 create NonCannonicalName >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S: * LIST () "/" "CannonicalName" ("TAG" (= "C04")) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S: C04 OK done >> >> >> In the example above imagine that "CannonicalName" is the canonical=20 >> (normalized) version of "NonCannonicalName" >> >> >> And the corresponding ABNF: >> >> tag-extended-item =3D "TAG" SP "(" tag-string ")" >> =C2=A0=C2=A0 ; Complies with <mbox-list-extended-item> >> =C2=A0=C2=A0 ; The value complies with <tagged-ext-val> >> =C2=A0=C2=A0 ; The value is the tag of the corresponding >> =C2=A0=C2=A0 ; CREATE command. >> >> >> And a similar extended data item can be used to return MAILBOXID=20 >> (when supported). >> > > Yes, this works for me. After thinking a bit more about this, I remembered that we already=20 registered OLDNAME extended data item in Section 5.4 of RFC 5465. (We=20 can think of canonical mailbox name as the server "renaming" the mailbox.) Matching to oldname is easier than matching to the tag of the command=20 that generated the change. So unless there are objections, I would go with that instead. --------------F953B8A3472B7F3BFB5D856A Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 07/07/2020 00:30, Bron Gondwana wrote:

On Tue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote:

On 17/06/2020 13:27, Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote:

1) abandon use of this response code (and use a new response instead), e.g.

* CREATED "a123" "Denormalized name" MAILBOXID "123456"

=C2=A0This would require clients to ign= ore an extra response, if they don't recognize it.


Somehow I've a feeling that there are going to be clients that will break if they see these kind of unknown untagged replies. But that's just a guess, so maybe not. We could of course send it only when client has used ENABLE IMAP4REV2 and then there wouldn't be any problems.

I like this.=C2=A0 Only send if IMAP4REV2 is enabled and all[tm] your problems go away.

Following on the suggestion to use LIST extended data items for this


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C: C04 create NonCannonicalName<= br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S: * LIST () "/" "CannonicalName= " ("TAG" ("C04"))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S: C04 OK done


In the example above imagine that "CannonicalName" is the canonical (normalized) version of "NonCannonicalName"


And the corresponding ABNF:

tag-extended-item =3D "TAG" SP "(" tag-string ")"
=C2=A0=C2=A0 ; Complies with &lt;mbox-list-extended-item&am= p;gt;
=C2=A0=C2=A0 ; The value complies with &lt;tagged-ext-val&a= mp;gt;
=C2=A0=C2=A0 ; The value is the tag of the corresponding
=C2=A0=C2=A0 ; CREATE command.


And a similar extended data item can be used to return MAILBOXID (when supported).


Yes, this works for me.

After thinking a bit more about this, I remembered that we already registered OLDNAME extended data item in Section 5.4 of RFC 5465. (We can think of canonical mailbox name as the server "renaming" the mailbox.)

Matching to oldname is easier than matching to the tag of the command that generated the change.


So unless there are objections, I would go with that instead.


--------------F953B8A3472B7F3BFB5D856A-- From nobody Sat Jul 11 01:26:33 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 7A88E3A087B for ; Sat, 11 Jul 2020 01:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5Mob5avlZ5HB for ; Sat, 11 Jul 2020 01:26:19 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 687A03A0879 for ; Sat, 11 Jul 2020 01:26:18 -0700 (PDT) Received: from [172.20.10.2] (unknown [85.76.76.90]) by sirainen.com (Postfix) with ESMTPSA id F1FC22B3C8B; Sat, 11 Jul 2020 08:26:15 +0000 (UTC) From: Timo Sirainen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D24B35DB-51F8-41CE-822D-248F25D55580" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 11 Jul 2020 11:26:15 +0300 In-Reply-To: Cc: Bron Gondwana , extra@ietf.org To: Alexey Melnikov References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> <178ba905-36d9-493e-a02f-ac1a91f3ae68@dogfood.fastmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 08:26:23 -0000 --Apple-Mail=_D24B35DB-51F8-41CE-822D-248F25D55580 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 10. Jul 2020, at 13.47, Alexey Melnikov = wrote: >=20 > On 07/07/2020 00:30, Bron Gondwana wrote: >=20 >> On Tue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote: >>> On 17/06/2020 13:27, Bron Gondwana wrote: >>>=20 >>>> On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >>>>>> 1) abandon use of this response code (and use a new response = instead), e.g. >>>>>>=20 >>>>>> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >>>>>>=20 >>>>>> This would require clients to ignore an extra response, if they = don't recognize it. >>>>>>=20 >>>>>=20 >>>>> Somehow I've a feeling that there are going to be clients that = will break if they see these kind of unknown untagged replies. But = that's just a guess, so maybe not. We could of course send it only when = client has used ENABLE IMAP4REV2 and then there wouldn't be any = problems. >>>>=20 >>>> I like this. Only send if IMAP4REV2 is enabled and all[tm] your = problems go away. >>> Following on the suggestion to use LIST extended data items for this >>>=20 >>>=20 >>>=20 >>> C: C04 create NonCannonicalName >>> S: * LIST () "/" "CannonicalName" ("TAG" ("C04")) >>> S: C04 OK done >>>=20 >>>=20 >>> In the example above imagine that "CannonicalName" is the canonical = (normalized) version of "NonCannonicalName" >>>=20 >>>=20 >>>=20 >>> And the corresponding ABNF: >>>=20 >>> tag-extended-item =3D "TAG" SP "(" tag-string ")" >>> ; Complies with <mbox-list-extended-item> >>> ; The value complies with <tagged-ext-val> >>> ; The value is the tag of the corresponding >>> ; CREATE command. >>>=20 >>>=20 >>> And a similar extended data item can be used to return MAILBOXID = (when supported). >>>=20 >>=20 >> Yes, this works for me. > After thinking a bit more about this, I remembered that we already = registered OLDNAME extended data item in Section 5.4 of RFC 5465. (We = can think of canonical mailbox name as the server "renaming" the = mailbox.) >=20 > Matching to oldname is easier than matching to the tag of the command = that generated the change. >=20 >=20 >=20 > So unless there are objections, I would go with that instead. >=20 Hmm. I guess that could work.. What's the behavior if the mailbox name = doesn't change? First I was thinking: * MAILBOXID supported: Send LIST () "/" "name" (MAILBOXID "12345") * No MAILBOXID supported: Don't send LIST reply at all But since CREATE already should return MAILBOXID in the tagged reply, = it's not very useful to send MAILBOXID in the LIST reply, right? So the = LIST reply should be only if the mailbox name changes? If it happens = rarely enough, it could be that clients won't actually implement that. Also, should we require that this name changing only is allowed for = normalizing UTF8, or could it be used for "mailbox alias names"? That's = been kind of an issue previously where two different folder names (both = in LIST reply) point to the same physical folder, but there's no way to = tell this to cilents so they cache the mails twice. Although in theory = the client could realize this already by seeing that two folders have = the same MAILBOXID. --Apple-Mail=_D24B35DB-51F8-41CE-822D-248F25D55580 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 10. Jul 2020, at 13.47, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On = 07/07/2020 00:30, Bron Gondwana wrote:

On Tue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote:

On 17/06/2020 13:27, Bron Gondwana wrote:

On Wed, Jun 17, = 2020, at 22:15, Timo Sirainen wrote:

1) abandon use of this response code = (and use a new response instead), e.g.

* CREATED "a123" "Denormalized name" = MAILBOXID "123456"

 This would require clients to ignore an extra response, if = they don't recognize it.


Somehow I've a feeling = that there are going to be clients that will break if they see these = kind of unknown untagged replies. But that's just a guess, so maybe not. = We could of course send it only when client has used ENABLE IMAP4REV2 = and then there wouldn't be any problems.

I like this.  Only send if IMAP4REV2 is enabled and = all[tm] your problems go away.

Following on the suggestion to use LIST extended data items = for this


      C: C04 create = NonCannonicalName
      S: * LIST () "/" = "CannonicalName" ("TAG" ("C04"))
      S: C04 OK done


In the = example above imagine that "CannonicalName" is the canonical = (normalized) version of "NonCannonicalName"


And the corresponding = ABNF:

tag-extended-item =3D "TAG" SP "(" tag-string ")"
   ; Complies with = &lt;mbox-list-extended-item&gt;
   ; The value complies with = &lt;tagged-ext-val&gt;
   ; The value is the tag of = the corresponding
   ; CREATE command.


And a = similar extended data item can be used to return MAILBOXID (when = supported).


Yes, this works for me.

After thinking a bit more about this, = I remembered that we already registered OLDNAME extended data item in = Section 5.4 of RFC 5465. (We can think of canonical mailbox name as the = server "renaming" the mailbox.)

Matching to oldname is easier than = matching to the tag of the command that generated the change.


So unless there are objections, I would go with that = instead.


Hmm. I guess = that could work.. What's the behavior if the mailbox name doesn't = change? First I was thinking:

 * = MAILBOXID supported: Send LIST () "/" "name" (MAILBOXID = "12345")
 * No MAILBOXID supported: Don't send LIST reply = at all

But = since CREATE already should return MAILBOXID in the tagged reply, it's = not very useful to send MAILBOXID in the LIST reply, right? So the LIST = reply should be only if the mailbox name changes? If it happens rarely = enough, it could be that clients won't actually implement = that.

Also, = should we require that this name changing only is allowed for = normalizing UTF8, or could it be used for "mailbox alias names"? That's = been kind of an issue previously where two different folder names (both = in LIST reply) point to the same physical folder, but there's no way to = tell this to cilents so they cache the mails twice. Although in theory = the client could realize this already by seeing that two folders have = the same MAILBOXID.

= --Apple-Mail=_D24B35DB-51F8-41CE-822D-248F25D55580-- From nobody Mon Jul 13 03:23: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 DC32A3A0781; Mon, 13 Jul 2020 03:23:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159463579679.27278.5198375345224157588@ietfa.amsl.com> Date: Mon, 13 Jul 2020 03:23:16 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-16.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, 13 Jul 2020 10:23:17 -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-16.txt Pages : 161 Date : 2020-07-13 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 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-16 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 Jul 13 08:23: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 970E63A126A for ; Mon, 13 Jul 2020 08:23:36 -0700 (PDT) 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, MIME_QP_LONG_LINE=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 n_uFLD9pA2wq for ; Mon, 13 Jul 2020 08:23:35 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id D7D623A0B3B for ; Mon, 13 Jul 2020 08:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594653813; d=isode.com; s=june2016; i=@isode.com; bh=QYZsKnRs7J2c0y/pR3DvCh3zdyShIHuSHWwDdmxqKYw=; 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=dLEONHIYl+eIVCuQzlShY7sbFv1WJqYEROmAjL2oOQNuMvJBJD66Cx6F2ReMYIXccuQQ0u 6N6SeTlVjGT/9roswXmsqPKscFD0bnCHCbGfnmvroVkueykTGmSkDnWS3SDe6fDW83lbco Bm4N0M45ETODk+Enu8aa1vAMoyYtAnw=; Received: from [192.168.0.2] (0546cbcb.skybroadband.com [5.70.203.203]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Jul 2020 16:23:33 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: <94C68CF3-1B2C-425B-8EE3-D31AEB2AE1C8@sirainen.com> Date: Mon, 13 Jul 2020 16:23:32 +0100 Cc: Bron Gondwana , extra@ietf.org Message-Id: References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> <94C68CF3-1B2C-425B-8EE3-D31AEB2AE1C8@sirainen.com> To: Timo Sirainen MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-FA1FD059-E426-4522-965E-E0C347A42CFC Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE 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, 13 Jul 2020 15:23:37 -0000 --Apple-Mail-FA1FD059-E426-4522-965E-E0C347A42CFC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Timo, > On 10 Jul 2020, at 07:44, Timo Sirainen wrote: >=20 >> On 6. Jul 2020, at 20.38, Alexey Melnikov wro= te: >>=20 >>> On 17/06/2020 13:27, Bron Gondwana wrote: >>> On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >>>>> 1) abandon use of this response code (and use a new response instead),= e.g. >>>>>=20 >>>>> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >>>>>=20 >>>>> This would require clients to ignore an extra response, if they don't= recognize it. >>>>>=20 >>>>=20 >>>> Somehow I've a feeling that there are going to be clients that will bre= ak if they see these kind of unknown untagged replies. But that's just a gue= ss, so maybe not. We could of course send it only when client has used ENABL= E IMAP4REV2 and then there wouldn't be any problems. >>>=20 >>> I like this. Only send if IMAP4REV2 is enabled and all[tm] your problem= s go away. >> Following on the suggestion to use LIST extended data items for this >>=20 >> C: C04 create NonCannonicalName >> S: * LIST () "/" "CannonicalName" ("TAG" ("C04")) >> S: C04 OK done >>=20 >> In the example above imagine that "CannonicalName" is the canonical (norm= alized) version of "NonCannonicalName" >>=20 >> And the corresponding ABNF: >>=20 >> tag-extended-item =3D "TAG" SP "(" tag-string ")" >> ; Complies with <mbox-list-extended-item> >> ; The value complies with <tagged-ext-val> >> ; The value is the tag of the corresponding >> ; CREATE command. >>=20 >> And a similar extended data item can be used to return MAILBOXID (when su= pported). >>=20 >> Does this work for people? >>=20 >=20 > OK. But should we return this always or only when canonical name changes? W= ith MAILBOXID at least always. I guess it could be nice to do it always in a= ny case so clients don't forget to support it. (The same answer applies to both TAG and OLDNAME) I think when it changes (or MAILBOXID is returned), but this doesn=E2=80=99t= break if the server returns it always. > But in SELECT case perhaps only return it on name change? Yes, save these extra bytes :-). Best Regards, Alexey= --Apple-Mail-FA1FD059-E426-4522-965E-E0C347A42CFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi T= imo,

On 10 Jul 2020, at 07:= 44, Timo Sirainen <timo@sirainen.com= > wrote:

On 6= . Jul 2020, at 20.38, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On 17/06/2020 13:27= , Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote:

1) abandon us= e of this response code (and use a new response instead), e.g.

* CREATED "a123" "Denormalized n= ame" MAILBOXID "123456"

 This would require clients to ignore an extra response, if they d= on't recognize it.


Somehow I've a feeling that there are going t= o be clients that will break if they see these kind of unknown untagged repl= ies. But that's just a guess, so maybe not. We could of course send it only w= hen client has used ENABLE IMAP4REV2 and then there wouldn't be any problems= .

I like this.  Only send if IMAP4REV2 is enabled and all[tm] your probl= ems go away.

Following on the suggestion to use LIST extended data items for this

    &nbs= p; C: C04 create NonCannonicalName
    &nb= sp; S: * LIST () "/" "CannonicalName" ("TAG" ("C04"))
 &n= bsp;    S: C04 OK done

In= the example above imagine that "CannonicalName" is the canonical (normalize= d) version of "NonCannonicalName"

And th= e corresponding ABNF:

tag-extended-item =3D "TA= G" SP "(" tag-string ")"
   ; Complies with &lt;= mbox-list-extended-item&gt;
   ; The value compl= ies with &lt;tagged-ext-val&gt;
   ; The val= ue is the tag of the corresponding
   ; CREATE comma= nd.

And a similar extended data item ca= n be used to return MAILBOXID (when supported).

Does this work for people?


OK. But should we return this always or only when canon= ical name changes? With MAILBOXID at least always. I guess it could be nice t= o do it always in any case so clients don't forget to support it.

(The same answer applies to both TAG and OLDNAM= E)
I think when it changes (or MAILBOXID is returned), but this doesn=E2= =80=99t break if the server returns it always.

But in SELECT case perhaps only r= eturn it on name change?

Yes, save th= ese extra bytes :-).

Best Regards,
Alexey=
= --Apple-Mail-FA1FD059-E426-4522-965E-E0C347A42CFC-- From nobody Mon Jul 13 08:29:44 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 60F063A135F for ; Mon, 13 Jul 2020 08:29:42 -0700 (PDT) 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, MIME_QP_LONG_LINE=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 r_S8CCZDF2UY for ; Mon, 13 Jul 2020 08:29:40 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A5C8A3A135C for ; Mon, 13 Jul 2020 08:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594654179; d=isode.com; s=june2016; i=@isode.com; bh=OYd7g+7iN3/kld55HfTilrBRkh5TG0uxknNUJD94wr0=; 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=OIRAhFy2A85YCqmGDhnBiUSCCcpMxPKZ9cyk0/r4dPU/b1fQ1xOFfHU7F8cpcy8S1SKi99 GmM2aCMjjU8CJJWGvXcUZyTj2bJZkpjHnjrzwUq7CCR7lnWxAUBBV4NwbBLuCa5EGjtQ3A rwQ5qD6rj2+RClR8SdP+U2nJ6z4kM68=; Received: from [192.168.0.2] (0546cbcb.skybroadband.com [5.70.203.203]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Jul 2020 16:29:39 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: Date: Mon, 13 Jul 2020 16:29:38 +0100 Cc: extra@ietf.org, Bron Gondwana Message-Id: References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> <178ba905-36d9-493e-a02f-ac1a91f3ae68@dogfood.fastmail.com> To: Timo Sirainen MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-1D4EB44A-A898-4188-9DD2-D432CEF21E86 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE 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, 13 Jul 2020 15:29:42 -0000 --Apple-Mail-1D4EB44A-A898-4188-9DD2-D432CEF21E86 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Timo, > On 11 Jul 2020, at 09:26, Timo Sirainen wrote: >=20 >> On 10. Jul 2020, at 13.47, Alexey Melnikov wr= ote: >>=20 >>> On 07/07/2020 00:30, Bron Gondwana wrote: >>>> On Tue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote: >>>>> On 17/06/2020 13:27, Bron Gondwana wrote: >>>>> On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >>>>>>> 1) abandon use of this response code (and use a new response instead= ), e.g. >>>>>>>=20 >>>>>>> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >>>>>>>=20 >>>>>>> This would require clients to ignore an extra response, if they don= 't recognize it. >>>>>>>=20 >>>>>>=20 >>>>>> Somehow I've a feeling that there are going to be clients that will b= reak if they see these kind of unknown untagged replies. But that's just a g= uess, so maybe not. We could of course send it only when client has used ENA= BLE IMAP4REV2 and then there wouldn't be any problems. >>>>>=20 >>>>> I like this. Only send if IMAP4REV2 is enabled and all[tm] your probl= ems go away. >>>> Following on the suggestion to use LIST extended data items for this >>>>=20 >>>>=20 >>>>=20 >>>> C: C04 create NonCannonicalName >>>> S: * LIST () "/" "CannonicalName" ("TAG" ("C04")) >>>> S: C04 OK done >>>>=20 >>>>=20 >>>> In the example above imagine that "CannonicalName" is the canonical (no= rmalized) version of "NonCannonicalName" >>>>=20 >>>>=20 >>>>=20 >>>> And the corresponding ABNF: >>>>=20 >>>> tag-extended-item =3D "TAG" SP "(" tag-string ")" >>>> ; Complies with <mbox-list-extended-item> >>>> ; The value complies with <tagged-ext-val> >>>> ; The value is the tag of the corresponding >>>> ; CREATE command. >>>>=20 >>>>=20 >>>> And a similar extended data item can be used to return MAILBOXID (when s= upported). >>>>=20 >>>=20 >>> Yes, this works for me. >> After thinking a bit more about this, I remembered that we already regist= ered OLDNAME extended data item in Section 5.4 of RFC 5465. (We can think of= canonical mailbox name as the server "renaming" the mailbox.) >>=20 >> Matching to oldname is easier than matching to the tag of the command tha= t generated the change. >>=20 >>=20 >>=20 >> So unless there are objections, I would go with that instead. >>=20 >=20 > Hmm. I guess that could work.. What's the behavior if the mailbox name doe= sn't change? First I was thinking: >=20 > * MAILBOXID supported: Send LIST () "/" "name" (MAILBOXID "12345") > * No MAILBOXID supported: Don't send LIST reply at all >=20 > But since CREATE already should return MAILBOXID in the tagged reply, it's= not very useful to send MAILBOXID in the LIST reply, right? Indeed. > So the LIST reply should be only if the mailbox name changes? If it happen= s rarely enough, it could be that clients won't actually implement that. >=20 > Also, should we require that this name changing only is allowed for normal= izing UTF8, or could it be used for "mailbox alias names"? That's been kind o= f an issue previously where two different folder names (both in LIST reply) p= oint to the same physical folder, but there's no way to tell this to cilents= so they cache the mails twice. Although in theory the client could realize t= his already by seeing that two folders have the same MAILBOXID. I am thinking that mailbox alias names can be supported by exact the same me= chanism. I had a similar thought about aliases. But I was not sure what, if a= nything the document should say about them. Best Regards, Alexey --Apple-Mail-1D4EB44A-A898-4188-9DD2-D432CEF21E86 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi T= imo,

On 11 Jul 2020, at 09:26, Timo Sirainen <<= a href=3D"mailto:timo@sirainen.com">timo@sirainen.com> wrote:

=
On 10. Jul 2020, at 13.47, A= lexey Melnikov <a= lexey.melnikov@isode.com> wrote:

On 07/07/2020 00:30, Bron Gondwana wrote:

On T= ue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote:

On 17/06/2020 13:27, B= ron Gondwana wrote:

On Wed, Jun 17, 2020, at 22:15, Timo= Sirainen wrote:

1) abandon use of this response code (and use a new respon= se instead), e.g.

* CREATED "a123" "Denormalized name" MAILBOXID "123456"

<= p class=3D"qt-qt-" style=3D"font-family: Helvetica; font-size: 12px; font-st= yle: normal; font-variant-caps: normal; font-weight: normal; letter-spacing:= normal; text-align: start; text-indent: 0px; text-transform: none; white-sp= ace: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decorat= ion-line: none; text-decoration-style: solid; text-decoration-color: current= color; text-decoration-thickness: auto;"> This would require clients to= ignore an extra response, if they don't recognize it.


Somehow= I've a feeling that there are going to be clients that will break if they s= ee these kind of unknown untagged replies. But that's just a guess, so maybe= not. We could of course send it only when client has used ENABLE IMAP4REV2 a= nd then there wouldn't be any problems.

I like this.  Only send if IMAP= 4REV2 is enabled and all[tm] your problems go away.

Following on the suggestion to use LIST extended data= items for this


     &= nbsp;C: C04 create NonCannonicalName
      = ;S: * LIST () "/" "CannonicalName" ("TAG" ("C04"))
      S: C04 OK done


In the example above imagine that "CannonicalNam= e" is the canonical (normalized) version of "NonCannonicalName"


And the corresponding= ABNF:

tag-extended-item =3D "TAG" SP "(" tag-string ")"
   = ; Complies with &lt;mbox-list-extended-item&gt;
=
   ; The value complies with &lt;tagged-ext-val&gt;
   = ; The value is the tag of the corresponding
   ; C= REATE command.


And a similar extended data item can be used to return MAILBOXID (when= supported).


Yes, this works for me.

After thinking a bit more about this, I remembered that we a= lready registered OLDNAME extended data item in Section 5.4 of RFC 5465. (We= can think of canonical mailbox name as the server "renaming" the mailbox.)<= /p>

Matching to oldname is easier than match= ing to the tag of the command that generated the change.


So unl= ess there are objections, I would go with that instead.


Hmm. I guess that could work.. What's the behavi= or if the mailbox name doesn't change? First I was thinking:

 * MAILBOXID supported: Send LIST () "/" "name" (M= AILBOXID "12345")
 * No MAILBOXID supported: Don't send LIST r= eply at all

But si= nce CREATE already should return MAILBOXID in the tagged reply, it's not ver= y useful to send MAILBOXID in the LIST reply, right?
Indeed.

So the LIST reply should be only if the mailbox name changes? If it happens= rarely enough, it could be that clients won't actually implement that.

Also, should we requir= e that this name changing only is allowed for normalizing UTF8, or could it b= e used for "mailbox alias names"? That's been kind of an issue previously wh= ere two different folder names (both in LIST reply) point to the same physic= al folder, but there's no way to tell this to cilents so they cache the mail= s twice. Although in theory the client could realize this already by seeing t= hat two folders have the same MAILBOXID.

I am thinking that mailbox alias names can be supported by exact the sam= e mechanism. I had a similar thought about aliases. But I was not sure what,= if anything the document should say about them.

Be= st Regards,
Alexey


= --Apple-Mail-1D4EB44A-A898-4188-9DD2-D432CEF21E86-- From nobody Mon Jul 13 15:24: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 D9E003A0BDD for ; Mon, 13 Jul 2020 15:24:29 -0700 (PDT) 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=BdupkFD8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fBnQURtu 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 b0UPBmId1lTT for ; Mon, 13 Jul 2020 15:24:24 -0700 (PDT) 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 968253A003E for ; Mon, 13 Jul 2020 15:24:24 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AB7EB9AB for ; Mon, 13 Jul 2020 18:24:23 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 13 Jul 2020 18:24:23 -0400 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:subject:content-type; s=fm3; bh=qCGRbeQ bb80M5G0DP1OzLTQ2/BLw+XEuB3S9OzG0vDE=; b=BdupkFD8mP/2KkAj1V2Llzm pM6JfMerAXjYKMeoEXmHCtZvrBF1ytNmQhejTTR0D3AY0CS521ywMyLcSbS2vl7P 64rDHvodxl3QzsT5fzmHqNkW0arHUEEQLEG4QfLpg6VvJ4iimVvySSiYx2SYsSSr doNQ5zQt7+rwB8BkhdXXyK4dyMgx8B5BlY16FchpAzpU2FijwqAXoFWMYdLNcu+m 9QEXNEgOUe5Ehbb4HnUKrt3ZIVqIMUiDwdrl/ZQ5IA6CIG6AAgGSHxTWac9Qds+u yRNRiguWay8OBajKbDsKaznVKN7GDsJJRaot0o5yGYxrTQNNOzSwWvPgSt6Vmgw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qCGRbe Qbb80M5G0DP1OzLTQ2/BLw+XEuB3S9OzG0vDE=; b=fBnQURtumV2vPHX7hqNakw yfx+8LJtGI9HMVZT5HPnW03Nra2/zSkWRjcBf7F1Wq+GhNEmueXWV0ui6ESyLfX5 OnjgxThG666KhStMHhST4E499KN8WakDCJM4VKmdq/ZuZZspMHNI6Zc3ylwmthm+ RnMid+R+Hj73ei1sDFpops93QOIqFWCfn4ptz6YbjoOfOBBE3LgBG9chYP2k9J/i bAaQVqop89q2+ltODUme9+a4i4up1AuGgLTE9yfs5dp/Q6JzyIKJ7WASfdaYktzX i6lHGA6S5YAkyDCJ1E8vqUM+hQqLpJb5ueWhYa9B2NUdp6RfgDtnpwOFAScD/ZSQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdelgddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdehteegfeevte duffevteehfffghefhvdevkeeuhfehueetudehgfegieekjeetnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BF91318012D; Mon, 13 Jul 2020 18:24:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-637-g57f734b-fm-idx2020-20200709.002-g57f734bf Mime-Version: 1.0 Message-Id: <27b47fbc-c487-45c7-ab7c-e4b96a5f2cfc@dogfood.fastmail.com> In-Reply-To: References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> <94C68CF3-1B2C-425B-8EE3-D31AEB2AE1C8@sirainen.com> Date: Tue, 14 Jul 2020 08:24:02 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=0c8a18b4bb874690ac272a6246acb308 Archived-At: Subject: Re: [Extra] =?utf-8?q?IMAP4rev2=3A_how_to_signal_canonical_mailbox_n?= =?utf-8?q?ame_after_CREATE?= 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, 13 Jul 2020 22:24:35 -0000 --0c8a18b4bb874690ac272a6246acb308 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2020, at 01:23, Alexey Melnikov wrote: >=20 > Hi Timo, >=20 > On 10 Jul 2020, at 07:44, Timo Sirainen wrote: >> On 6.. Jul 2020, at 20.38, Alexey Melnikov wrote: >>>=20 >>> On 17/06/2020 13:27, Bron Gondwana wrote: >>>> On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >>>>>> 1) abandon use of this response code (and use a new response inst= ead), e.g. >>>>>> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >>>>>> This would require clients to ignore an extra response, if they = don't recognize it. >>>>>=20 >>>>> Somehow I've a feeling that there are going to be clients that wil= l break if they see these kind of unknown untagged replies. But that's j= ust a guess, so maybe not. We could of course send it only when client h= as used ENABLE IMAP4REV2 and then there wouldn't be any problems.. >>>>=20 >>>> I like this. Only send if IMAP4REV2 is enabled and all[tm] your pro= blems go away. >>> Following on the suggestion to use LIST extended data items for this= >>> C: C04 create NonCannonicalName >>> S: * LIST () "/" "CannonicalName" ("TAG" ("C04")) >>> S: C04 OK done >>> In the example above imagine that "CannonicalName" is the canonical = (normalized) version of "NonCannonicalName" >>> And the corresponding ABNF: >>>=20 >>> tag-extended-item =3D "TAG" SP "(" tag-string ")" >>> ; Complies with <mbox-list-extended-item> >>> ; The value complies with <tagged-ext-val> >>> ; The value is the tag of the corresponding >>> ; CREATE command. >>> And a similar extended data item can be used to return MAILBOXID (wh= en supported). >>> Does this work for people? >> OK. But should we return this always or only when canonical name chan= ges? With MAILBOXID at least always. I guess it could be nice to do it a= lways in any case so clients don't forget to support it. >=20 > (The same answer applies to both TAG and OLDNAME) > I think when it changes (or MAILBOXID is returned), but this doesn=E2=80= =99t break if the server returns it always. >=20 >> But in SELECT case perhaps only return it on name change? > Yes, save these extra bytes :-). I disagree - I'd rather just have it ALWAYS be in the SELECT/EXAMINE res= ponse. It will still fit within a single packet, so it's not going to co= st any more on the wire. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --0c8a18b4bb874690ac272a6246acb308 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2020, at 01:23, Alexey Melnikov wrote:

Hi Timo,

On 10 Jul 2020, at 07:44, Timo Sirainen <timo@sirainen.com> wrote:
On 6.. Jul 2020, at 20.38, Alexe= y Melnikov <alexey.melnikov@isode.com> wrote:

On 17/06/2020 13:27, Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 22= :15, Timo Sirainen wrote:
<= blockquote type=3D"cite" class=3D"qt-qt-">

1) abandon use of this response code (and use a n= ew response instead), e.g.

* CREAT= ED "a123" "Denormalized name" MAILBOXID "123456"

 This would require clients to ignore an extra respo= nse, if they don't recognize it.


Somehow I've a feeling that there are= going to be clients that will break if they see these kind of unknown u= ntagged replies. But that's just a guess, so maybe not. We could of cour= se send it only when client has used ENABLE IMAP4REV2 and then there wou= ldn't be any problems..

I like this.  Only send if IMAP4REV2 is enabled and a= ll[tm] your problems go away.

Following on the suggestion to use LIST extended data items for th= is

    &= nbsp; C: C04 create NonCannonicalName
   &n= bsp;  S: * LIST () "/" "CannonicalName" ("TAG" ("C04"))
      S: C04 OK done

In the example above imagine that "CannonicalName" = is the canonical (normalized) version of "NonCannonicalName"

And the corresponding ABNF:

tag-extended-item =3D "TAG" SP "(" tag-string ")"
<= /div>
   ; Complies with &lt;mbox-list-extended-item&a= mp;gt;
   ; The value complies with &lt;tagg= ed-ext-val&gt;
   ; The value is the tag of = the corresponding
   ; CREATE command.
=

And a similar extended data item can = be used to return MAILBOXID (when supported).

Does this work for people?

OK. But should we return this always or only when canonical name change= s? With MAILBOXID at least always. I guess it could be nice to do it alw= ays in any case so clients don't forget to support it.

(The same answer applies to both TAG and = OLDNAME)
I think when it changes (or MAILBOXID is returned= ), but this doesn=E2=80=99t break if the server returns it always.

But in SELECT case perhaps only return it on name change?<= br>
Yes, save these extra bytes :-).<= br>

I disagree - I'd rather just have it ALWAYS = be in the SELECT/EXAMINE response.  It will still fit within a sing= le packet, so it's not going to cost any more on the wire.

Bron.

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


--0c8a18b4bb874690ac272a6246acb308-- From nobody Tue Jul 14 20:29:41 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 D3DA53A0E0C for ; Tue, 14 Jul 2020 20:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aLwG7d_916Y for ; Tue, 14 Jul 2020 20:29:37 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750293A0E09 for ; Tue, 14 Jul 2020 20:29:37 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id AD6E36A312 for ; Wed, 15 Jul 2020 05:29:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1594783773; bh=2+GhpZ6F5xL8bIhfDT4EUykfhKnMLMwHW/6DbINy3pI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=g+DdybiBqceDena9uJzBgjorypuBkbdXBCMPd47R0+OSrlsmbYvLP2gs1TM6HRMrU J8fsm+ruBEwUm05n7XeJnb0BLM2cWQIea1l921O5dimhZAyK9fxAYROMCehIR8NtED d7F2N3a+IysMs1re/979fMPdRSY26twu/MUqCvM7BzFOKGLUeZUbIdyWb1U2Xsh3pn UV92gXE4CnxcUa5jqF9o+/7ovyLlmMTKEpK0HNt/6RAe7UJHnRrFQx+xc5kamcsm8V 6T6xBVR6uiclQer3Kk4j8EqF4Dw77Ws2QIx7shYELpBvT8+Vv+01Njf+LtLuknOEvM ueBWEfzm1ChSA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 9ED283C02B0 for ; Wed, 15 Jul 2020 05:29:33 +0200 (CEST) Date: Tue, 14 Jul 2020 21:29:33 -0600 (MDT) From: Michael Slusarz To: extra@ietf.org Message-ID: <381786159.2271.1594783773523@appsuite.open-xchange.com> In-Reply-To: References: <1948688035.19548.1594092129291@appsuite.open-xchange.com> <388F9721-0CB5-4146-AC23-503C4481A090@sirainen.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2270_1403645970.1594783773511" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev17 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08 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, 15 Jul 2020 03:29:40 -0000 ------=_Part_2270_1403645970.1594783773511 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It seems I was a day late to submit, as submissions are paused before the meeting... I've finished the -09 draft. If interested, I could post a copy. Otherwise, I will just submit at end of the month when submission tool is reopened. Changes in -09: * PREVIEW without LAZY MUST NOT return NIL (kept it simple) * Rewrote the LAZY modifier section a bit to break apart the semantics of LAZY from "Client Implementation Advice". The latter is a combo of some of the text previously in the section with list recommendations. Slightly tweaked Example 2 to request two previews in a single FETCH request in background. Decided to make no mention of NO response in this document. After discussion here, it seems like that is expected to be an extremely rare case - and that case is already adequately handled by FETCH command definition in base IMAP spec. michael > On 07/07/2020 5:00 AM Bron Gondwana wrote: > > > On Tue, Jul 7, 2020, at 18:54, Timo Sirainen wrote: > > > > On 7. Jul 2020, at 6.22, Michael Slusarz wrote: > > > > > > > > > > > > > > > > > On 07/02/2020 3:20 AM Timo Sirainen wrote: > > > > > > > > > > > > On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com mailto:brong@fastmailteam.com > wrote: > > > > > > > > > > > > > > > > > As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version. > > > > > > > > > > This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication. Please reply with any comments by Thursday, July 16th 2020. Let's get this one off our plates before IETF108. > > > > > > > > > > > > > > > > > > It is possible that preview text is not available now, but might be > > > > available later -- perhaps the server's preview-generating resources > > > > are overloaded, there is a server-imposed timeout during preview > > > > generation, or there is some transient issue with fetching the > > > > message body. In such cases, the server will return NIL as the > > > > preview response, and the client can try to retrieve the preview > > > > later. > > > > This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended. > > > > > > > > > > > I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time. > > > > > > > > > > I don't really see why this would be an issue. IMAP protocol doesn't have this kind of a special "DoS-prevention feature" anywhere else. Especially now that the preview is always text, I don't think it can be excessively slow to generate it. At least in Dovecot's implementation it's basically as expensive as fetching BODYSTRUCTURE, and we don't have DoS prevention against fetching those. Maybe in theory if server wanted to analyze attachments in some way .. but is it really worth the added complexity for a problem that probably will remain theoretical? > > > > FETCH is also good in that it returns the results after each mail. So the server is allowed to start throttling the responses to the client without actually failing it. > > > > > > You're right. Here we are overcomplexing it again! > > Server MUST NOT return NIL to a non-lazy preview is fine by me. > > Server SHOULD NOT return NIL is fine by me as well, along with clients SHOULD NOT cache a NIL response. Either way our server is always going to have one because it gets calculated on APPEND. > > Bron. > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > ------=_Part_2270_1403645970.1594783773511 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
It seems I was a day late to submit, as submissions are paused before the meeting...
 
I've finished the -09 draft.  If interested, I could post a copy.  Otherwise, I will just submit at end of the month when submission tool is reopened.
 
Changes in -09:
  • PREVIEW without LAZY MUST NOT return NIL (kept it simple)
  • Rewrote the LAZY modifier section a bit to break apart the semantics of LAZY from "Client Implementation Advice".  The latter is a combo of some of the text previously in the section with list recommendations.  Slightly tweaked Example 2 to request two previews in a single FETCH request in background.
Decided to make no mention of NO response in this document.  After discussion here, it seems like that is expected to be an extremely rare case - and that case is already adequately handled by FETCH command definition in base IMAP spec.
 
michael
 
On 07/07/2020 5:00 AM Bron Gondwana <brong@fastmailteam.com> wrote:
 
 
On Tue, Jul 7, 2020, at 18:54, Timo Sirainen wrote:
On 7. Jul 2020, at 6.22, Michael Slusarz <michael.slusarz=40open-xchange.com@dmarc.ietf.org> wrote:
 
On 07/02/2020 3:20 AM Timo Sirainen <timo@sirainen.com> wrote:
 
 
On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com> wrote:
 
As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version.
 
This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication.  Please reply with any comments by Thursday, July 16th 2020.  Let's get this one off our plates before IETF108.
 
   It is possible that preview text is not available now, but might be
   available later -- perhaps the server's preview-generating resources
   are overloaded, there is a server-imposed timeout during preview
   generation, or there is some transient issue with fetching the
   message body.  In such cases, the server will return NIL as the
   preview response, and the client can try to retrieve the preview
   later.
This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended.
I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time.
 
I don't really see why this would be an issue. IMAP protocol doesn't have this kind of a special "DoS-prevention feature" anywhere else. Especially now that the preview is always text, I don't think it can be excessively slow to generate it. At least in Dovecot's implementation it's basically as expensive as fetching BODYSTRUCTURE, and we don't have DoS prevention against fetching those. Maybe in theory if server wanted to analyze attachments in some way .. but is it really worth the added complexity for a problem that probably will remain theoretical?
 
FETCH is also good in that it returns the results after each mail. So the server is allowed to start throttling the responses to the client without actually failing it.
 
You're right.  Here we are overcomplexing it again!
 
Server MUST NOT return NIL to a non-lazy preview is fine by me.
 
Server SHOULD NOT return NIL is fine by me as well, along with clients SHOULD NOT cache a NIL response.  Either way our server is always going to have one because it gets calculated on APPEND.
 
Bron.
 
 
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com
 
 
_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra
------=_Part_2270_1403645970.1594783773511-- From nobody Thu Jul 16 05:23:39 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 60E183A07D4 for ; Thu, 16 Jul 2020 05:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFFt8YuL1jEg for ; Thu, 16 Jul 2020 05:23:35 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC1F3A07D7 for ; Thu, 16 Jul 2020 05:23:34 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id D27F96A311; Thu, 16 Jul 2020 14:23:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1594902211; bh=HgL0eOE0gc+FFCbDaET/OdHRhsLy29Q358r7hIm1utw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=24++Nvo4NvpAdaE4fta5+UggGNEO/BHSKGA6RthJMgRX/Z3EspXmU6X01HBVd7Z17 ijIGzecAreipPwGoaEz/wkbmumHuZ471Opec0XQuoEa6zZ0lLr6wpxznNyf48FoK2i SR/F6/h0Hhm0h4bLmrclweoCGswH865suMP1RLI8RcSgAP4E4ZKASjeme/YSqbyqWg rc8oVQJrEYBxkDxg/Srdz9CN0lBTui25gu62DPXjU4v0KU6YByo7eckAFIu3GnGOtw Kpl/5YMt7iCU8KD4Jj1yWmXmDfaz+MEdXf/0xmnXXGhlqXmDSrjdBZj1T6SZAvX1oz dqFyKRwsscr8w== Received: from [192.168.1.112] (lab.inertia-technology.com [217.119.239.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id B83753C0379; Thu, 16 Jul 2020 14:23:31 +0200 (CEST) To: Alexey Melnikov , extra@ietf.org References: <159238763595.1803.574245566610096074@ietfa.amsl.com> From: Stephan Bosch Message-ID: Date: Thu, 16 Jul 2020 14:21:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: 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-15.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 12:23:37 -0000 Hi Alexey, Did you see my review (below) ? Regards, Stephan. Op 22-6-2020 om 19:56 schreef Stephan Bosch: > Hi, > > On 17/06/2020 13:53, Alexey Melnikov wrote: >> Hi all, >> >> On 17/06/2020 10:53, 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-15 >>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-15 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-15 >> >> In this version I finally removed multiple list patterns and also >> clarified a few things based on earlier comments. > > I gave this document a quick review. Below are my comments so far. > Quoted text from the document is copied directly, while my comments > are prefixed with "-> ". > > Regards, > > Stephan > > section-2.3.2: > > $Phishing  The $Phishing keyword can be used by a delivery agent to >       mark a message as highly likely to be a phishing email.  An email >       that's determined to be a phishing email by the delivery agent >       should also be considered a junk email and have the appropriate >       junk filtering applied, including setting the $Junk flag and >       placing in the \Junk special-use mailbox if available. > -> Special-use is not mentioned up to this point. It needs to be > explained briefly or referred elsewhere. > > section-5.1: > >    5.  Two characters, "#" and "&", have meanings by convention, and >        should be avoided except when used in that convention. > -> Maybe remove the mystery and mention briefly what these are used > for conventionally (or provide some citation). Section 5.1.2.1 does > part of this, so that could at least be referred from here. > > section-6.3.9: > > -> This section mentions several examples of specific selection and > return options without introduction. It should maybe refer to > subsequent sections at the first instance of this. > >    Future extensions to this >    specification should keep parallelism in mind and define a pair of >    corresponding options. > -> So, what exactly is meant by "parallelism" here? Do you mean > "dualism" or something like that (which I actually find equally > confusing)? > > -> The SPECIAL-USE extension, which adds selection and return options, > is not mentioned here, while the specification envelops it. > > section-6.3.9.2: > >                                                            For each >          selectable mailbox matching the list pattern and selection >          options, the server MUST return an untagged LIST response >          followed by an untagged STATUS response containing the >          information requested in the STATUS return option. > -> This sentence describes a hard requirement, but subsequent > paragraphs describe what amounts to exceptions. Maybe this sentence > should already announce this to the reader; e.g. ", except for the > following cases." or something like that. This should also avoid > confusion about the contraction that seems to exist between the > paragraphs. > > section-6.3.9.5: > >    The CHILDREN return option implements the Child Mailbox Extension, >    originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft >    Corporation. Most of the information in this section is taken >    directly from their original specification [RFC3348]. > -> Is it conventional to have acknowledgements like this in the > normative text? Also, text borrowed from other RFCs is only > acknowledged in Appendix E. > >    It is an error for the server to return both a \HasChildren and a >    \HasNoChildren attribute in the same LIST response. > -> Any recommendation for what clients should do if this does happen? > Provisionally treat it as \HasChildren? > > section-6.3.10: > >    Namespace-Response-Extensions ABNF non >    terminal is defined for extensibility and MAY be included in the >    response. > -> What is this? And this sentence is incomplete (no article at the > beginning). > > section-6.3.12: > >    On successful completion of an APPEND, the server SHOULD return an >    APPENDUID response code. > -> This response code is not explained at this port. Provide brief > purpose or reference to where it is explained. > >    In the case of a mailbox that has UIDNOTSTICKY status (see >    UIDNOTSTICKY response code definition) > -> See where? Needs reference. > > section-6.4.5: > > -> Now that the BINARY fetch items are also part of the specification, > the "
" bit should probably be described separately before the > enumeration of fetch data items. Stuffing it in the description of > BODY is confusing, as it applies to several fetch items now. > >    BODYSTRUCTURE  The [MIME-IMB] body structure of the message. This is >       computed by the server by parsing the [MIME-IMB] header fields in >       the [RFC-5322] header and [MIME-IMB] headers. > >    ENVELOPE  The envelope structure of the message.  This is computed by >       the server by parsing the [RFC-5322] header into the component >       parts, defaulting various fields as necessary. > -> At least these two could use a forward reference to the FETCH > response section, where the semantics of these are described in more > detail. Could also put a single reference in the sentence announcing > the list of data items. > > section-6.4.7: > >    On successful completion of a COPY, the server SHOULD return a >    COPYUID response code. > -> This response code is not explained at this point. Provide brief > purpose or reference to where it is explained (weirdly, section on > MOVE does this correctly). > >    In the case of a mailbox that has UIDNOTSTICKY status (see the >    UIDNOTSTICKY response code), the server MAY omit the COPYUID response >    code as it is not meaningful. > -> See where? Needs reference. > > section-7.4.1: > > -> Isn't this sub-section supposed to be in the section before? It is > about the mailbox size, not message data. > > section-7.4.2: > >             Note: [RFC-5322] requires that all messages have a valid >             Date header.  Therefore, the date member in the envelope can >             not be NIL or the empty string. > -> We all like to live in a perfect world, but what should the server > do if the sender is naughty and the message has no Date header? Return > the internal date instead? > >         Note: [RFC-5322] requires that the In-Reply-To and Message- >             ID headers, if present, have non-empty content. Therefore, >             the in-reply-to and message-id members in the envelope can >             not be the empty string. > -> Same... > >             Note: [RFC-5322] requires that all messages have a valid >             From header.  Therefore, the from, sender, and reply-to >             members in the envelope can not be NIL. > -> Same... > > section-10: > > -> What about RFC 3501? > > section-11.4: > >    Additional security considerations are discussed in the section >    discussing the AUTHENTICATE and LOGIN commands. > -> Explicit references > > section-12.1: > >    As this specification revises the AUTH= prefix, STARTTLS and >    LOGINDISABLED extensions previously defined in [IMAP-TLS], IANA is >    requested to update registry entries for these 3 extensions to point >    to this document. > -> This is not noted in the document header. > > General comments: > > -> This document should probably mention at the appropriate locations > pre-existing and often-implemented extensions that significantly > improve upon the base IMAP4rev1/2 protocol. So, for example, the > section describing IDLE could mention the NOTIFY capability. > -> Enumerations of options/flags/items/identifiers are often strangely > formatted. Compare e.g. the search key descriptions in > https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-15#section-6.4.4 > to the old  https://tools.ietf.org/html/rfc3501#section-6.4.4 > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@open-xchange.com Direct Chat: https://chat.open-xchange.com/direct/stephan.bosch ------------------------------------------------------------------------------------- Open-Xchange AG, Hohenzollernring 72, 50672 Cologne, District Court Cologne HRB 95366 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin Chairman of the Board: Richard Seibt Open-Xchange Oy, Lars Sonckin Kaari 12, 02600 Espoo, Finland Managing Director: Carsten Dirks Board: Michael Knapstein (Chairman) and Timo Sirainen (board member) ------------------------------------------------------------------------------------- From nobody Thu Jul 16 05:52:56 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 C73913A059F for ; Thu, 16 Jul 2020 05:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 gBKrgizFoeuz for ; Thu, 16 Jul 2020 05:52:55 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D542B3A0400 for ; Thu, 16 Jul 2020 05:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594903973; d=isode.com; s=june2016; i=@isode.com; bh=CKbCaxdZTdgQhxo0isE9A/Ppq23WJMHAF3QPsMH7HAk=; 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=szr63nf7kS1qEH83AIW5M1WX3UNeBLvYU/bIsgbpVOvHDalMIP24QyI24tIHlDogAekpZK XU9sr1h7X8RxgirzRNn4S99qwA/4qxHFUAS/mya2nbJxeNprxZOeexj9IP33wPArfjr1Kx taovPn7B2MUR17JRMfGzYul2SbebEyU=; Received: from [172.27.248.54] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 16 Jul 2020 13:52:53 +0100 To: Stephan Bosch References: <159238763595.1803.574245566610096074@ietfa.amsl.com> Cc: extra From: Alexey Melnikov Message-ID: <5158daed-3705-cb8e-4a90-4c493a78f983@isode.com> Date: Thu, 16 Jul 2020 13:52:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: 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-15.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 12:52:56 -0000 Hi Stephan, On 16/07/2020 13:21, Stephan Bosch wrote: > Hi Alexey, > > Did you see my review (below) ? My apologies for missing your review. I will incorporate in -17. Best Regards, Alexey From nobody Thu Jul 23 21:22:01 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 3B3AC3A0AFF for ; Thu, 23 Jul 2020 21:22:00 -0700 (PDT) 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=EX5jfBGC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ffmnPif5 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 pDv57iAXdVMt for ; Thu, 23 Jul 2020 21:21:58 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316EC3A0B03 for ; Thu, 23 Jul 2020 21:21:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8327EA1E for ; Fri, 24 Jul 2020 00:21:56 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 24 Jul 2020 00:21:56 -0400 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:subject:content-type; s=fm3; bh=Yg9Jg0K AITnOWpPhLzeaefIq+H+bZklKZBHCIDWzkOg=; b=EX5jfBGCKqc3zlqft5UR+th bI4zwT23CExPYbsjnXfPEHyLdUm34kEasHIR1LlAroEoe7OxDgm7WXYeqqbesbpv Sg+Hvjjaa5LWaUudXskVFp3DwNFzDTulzqO9yszPVy5xDiFW3JZTFpzCdVE5t/V5 RfZVmav8ymALFDbERUMyXngn04JXWVMoPMTG7P1Aa0HI/JO/HSJz4wDc5VDexFK7 wXjvGlbsBLzZxjWsG2wBHoGhOJVrKEmMY0rDRcI+zQlM/04APTeytKSYiXutmW7J UCegC3bX+zL5zQmcuzGuZpOugsSZ3ZNDrBK7XLE63cV7DMijG1qud8yH6k60MkA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Yg9Jg0 KAITnOWpPhLzeaefIq+H+bZklKZBHCIDWzkOg=; b=ffmnPif5sBS7OXbM9cRhZU bycTuiYc4D4CIY55Xdf7aWaM8DMrS/j554UMhC4L5xSOwCka+D5+Zs8ARTW8gtYL VSTFdIeZI3OR80W4PpY5H67yhvNwqY9PEfdGBML8iQ2NTAcIaR5A4O9NLuNgPMbX ftS8/PlRQAAvD4GF48cVAna7IKNyOK8U18xp0oSD4Mho/MSf4iHVvkDYsmG/RrOP RgxzoqwSiX/Jis4dEwb2bEULk62pfmhKl3PW82TrKJZmTqP2dQ4QiAwwp1jbcV65 Kj5UcD0zg08x4rUWw6PjzsNhlXEQXHFgBQmM3DBOF3FmLhND2L8khsG50X/M6BaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedvgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepffdvkeefgeelie eutedttdffheevvefffeekuddvtddtkeeigfejuddvhfdvudelnecuffhomhgrihhnpehi vghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DCF351803EE; Fri, 24 Jul 2020 00:21:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: <4d502b60-f4a3-4c33-8301-b6c552437359@dogfood.fastmail.com> In-Reply-To: <381786159.2271.1594783773523@appsuite.open-xchange.com> References: <1948688035.19548.1594092129291@appsuite.open-xchange.com> <388F9721-0CB5-4146-AC23-503C4481A090@sirainen.com> <381786159.2271.1594783773523@appsuite.open-xchange.com> Date: Fri, 24 Jul 2020 14:21:35 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=4f21dc92b23a44ed9a81ac38df5a90f6 Archived-At: Subject: Re: [Extra] =?utf-8?q?Working_Group_Last_Call_-_draft-ietf-extra-ima?= =?utf-8?q?p-fetch-preview-08?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 04:22:00 -0000 --4f21dc92b23a44ed9a81ac38df5a90f6 Content-Type: text/plain I'm ready to go with this on Monday :) On Wed, Jul 15, 2020, at 13:29, Michael Slusarz wrote: > It seems I was a day late to submit, as submissions are paused before the meeting... > > I've finished the -09 draft. If interested, I could post a copy. Otherwise, I will just submit at end of the month when submission tool is reopened. > > Changes in -09: > * PREVIEW without LAZY MUST NOT return NIL (kept it simple) > * Rewrote the LAZY modifier section a bit to break apart the semantics of LAZY from "Client Implementation Advice". The latter is a combo of some of the text previously in the section with list recommendations. Slightly tweaked Example 2 to request two previews in a single FETCH request in background. > Decided to make no mention of NO response in this document. After discussion here, it seems like that is expected to be an extremely rare case - and that case is already adequately handled by FETCH command definition in base IMAP spec. > > michael > >> On 07/07/2020 5:00 AM Bron Gondwana wrote: >> >> >> On Tue, Jul 7, 2020, at 18:54, Timo Sirainen wrote: >>> On 7. Jul 2020, at 6.22, Michael Slusarz wrote: >>>> >>>>> On 07/02/2020 3:20 AM Timo Sirainen wrote: >>>>> >>>>> >>>>> On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com> wrote: >>>>> >>>>>> As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version. >>>>>> >>>>>> This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication. Please reply with any comments by Thursday, July 16th 2020. Let's get this one off our plates before IETF108. >>>>> >>>>> It is possible that preview text is not available now, but might be >>>>> available later -- perhaps the server's preview-generating resources >>>>> are overloaded, there is a server-imposed timeout during preview >>>>> generation, or there is some transient issue with fetching the >>>>> message body. In such cases, the server will return NIL as the >>>>> preview response, and the client can try to retrieve the preview >>>>> later. >>>>> This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended. >>>> I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time. >>> >>> I don't really see why this would be an issue. IMAP protocol doesn't have this kind of a special "DoS-prevention feature" anywhere else. Especially now that the preview is always text, I don't think it can be excessively slow to generate it. At least in Dovecot's implementation it's basically as expensive as fetching BODYSTRUCTURE, and we don't have DoS prevention against fetching those. Maybe in theory if server wanted to analyze attachments in some way .. but is it really worth the added complexity for a problem that probably will remain theoretical? >>> >>> FETCH is also good in that it returns the results after each mail. So the server is allowed to start throttling the responses to the client without actually failing it. >> >> You're right. Here we are overcomplexing it again! >> >> Server MUST NOT return NIL to a non-lazy preview is fine by me. >> >> Server SHOULD NOT return NIL is fine by me as well, along with clients SHOULD NOT cache a NIL response. Either way our server is always going to have one because it gets calculated on APPEND. >> >> Bron. >> >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --4f21dc92b23a44ed9a81ac38df5a90f6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I'm ready to go with this on Monday :)

On Wed, Jul 15, 2020, at 13:29, M= ichael Slusarz wrote:
It seems I was a day late to submit, as submissions are pause= d before the meeting...
 
I've finished= the -09 draft.  If interested, I could post a copy.  Otherwis= e, I will just submit at end of the month when submission tool is reopen= ed.
 
Changes in -09:
  • = PREVIEW without LAZY MUST NOT return NIL (kept it simple)
  • Re= wrote the LAZY modifier section a bit to break apart the semantics of LA= ZY from "Client Implementation Advice".  The latter is a combo of s= ome of the text previously in the section with list recommendations.&nbs= p; Slightly tweaked Example 2 to request two previews in a single FETCH = request in background.
Deci= ded to make no mention of NO response in this document.  After disc= ussion here, it seems like that is expected to be an extremely rare case= - and that case is already adequately handled by FETCH command definiti= on in base IMAP spec.
 
michael
 
<= /div>
On 07/07/2020 5:00 AM Bron Gondwana = <brong@fastmailteam.com> wrote:
 
 
On Tue, Jul 7, 2020, = at 18:54, Timo Sirainen wrote:
O= n 7. Jul 2020, at 6.22, Michael Slusarz <michael.slus= arz=3D40open-xchange.com@dmarc.ietf.org> wrote:
 
On 07/02= /2020 3:20 AM Timo Sirainen <timo@sirainen.com> wrote:
 
 
On 2. J= ul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com> wrote:
<= div> 
As discussed in the inter= im meeting, this document was brought back to the working group to be re= verted to an earlier and simpler version.
 
This email announce= s a 2 week working group last call for any further comments on this vers= ion before I re-submit to IESG for publication.  Please reply with = any comments by Thursday, July 16th 2020.  Let's get this one off o= ur plates before IETF108.
 
&nb= sp;  It is possible that preview text is not available now, but mig= ht be
   available later -- per= haps the server's preview-generating resources
   are overloaded, there is a server-imposed timeout dur= ing preview
   generation, or t= here is some transient issue with fetching the
   message body.  In such cases, the server will re= turn NIL as the
   preview resp= onse, and the client can try to retrieve the preview
   later.
This sounds like it's poss= ible for server to return NIL even when the LAZY modifier isn't specifie= d. Is this really wanted? I'd think client developers would prefer that = only LAZY can return NILs. Either way, it's not clearly enough specified= what is intended.
I was originally going to agree with Timo ... but the= n I remember we added this part as a direct response to a potential DoS = situation - what happens if preview requests are (subjectively) taking t= oo much time.
 
I don't really see why this would be an issue. IMAP protocol doe= sn't have this kind of a special "DoS-prevention feature" anywhere else.= Especially now that the preview is always text, I don't think it can be= excessively slow to generate it. At least in Dovecot's implementation i= t's basically as expensive as fetching BODYSTRUCTURE, and we don't have = DoS prevention against fetching those. Maybe in theory if server wanted = to analyze attachments in some way .. but is it really worth the added c= omplexity for a problem that probably will remain theoretical?
=
 
FETCH is also good in that it returns the resu= lts after each mail. So the server is allowed to start throttling the re= sponses to the client without actually failing it.
 
You're right.  Here we are overcomplexing it aga= in!
 
Server MUST NOT return NIL to a non-lazy previe= w is fine by me.
 
Server SHOULD NOT return NIL is fi= ne by me as well, along with clients SHOULD NOT cache a NIL response.&nb= sp; Either way our server is always going to have one because it gets ca= lculated on APPEND.
 
Bron.
 
&nbs= p;
--
  Bron= Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam= .com
 
 
_______________________________________________<= br>
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra
_______________________________________________
Extr= a mailing list

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

--4f21dc92b23a44ed9a81ac38df5a90f6-- From nobody Wed Jul 29 08:30:33 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 1D81B3A0B9D; Wed, 29 Jul 2020 08:30:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159603663196.4734.2900827477637114514@ietfa.amsl.com> Date: Wed, 29 Jul 2020 08:30:32 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-17.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, 29 Jul 2020 15:30:32 -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-17.txt Pages : 162 Date : 2020-07-29 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 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-17 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-17 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 Jul 29 08:44:06 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 36A0F3A0BD8 for ; Wed, 29 Jul 2020 08:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 UX2Arai50DJC for ; Wed, 29 Jul 2020 08:44:03 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5E3A0BE3 for ; Wed, 29 Jul 2020 08:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1596037442; d=isode.com; s=june2016; i=@isode.com; bh=7MQ1uhfS6tZRnmVoLjF8sTf2NAAwwvLDLLRG5ReZJNQ=; 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=twK3OgGBM9KzifUwkS0lcdCK7D0ZNJNUwnOODOcQj79IqDLakmbRtcPR20eEh3t1WxkLvn IjzPSAixy4Zsr9fEu+E4+N+cm4GBzOC2KtfObPFPgjbHjojvW8x61ZqHXS5O+yN8ayxRlW n8gWXbB3qSI1F6tqPVepizJUBj0l7gE=; Received: from [192.168.1.216] (host31-49-142-53.range31-49.btcentralplus.com [31.49.142.53]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 29 Jul 2020 16:44:02 +0100 To: extra@ietf.org References: <159603663196.4734.2900827477637114514@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <21ac48aa-ad13-4a52-728a-dd26f83fd464@isode.com> Date: Wed, 29 Jul 2020 16:44:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <159603663196.4734.2900827477637114514@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-17.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, 29 Jul 2020 15:44:05 -0000 On 29/07/2020 16:30, 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-17 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-17 This version addresses most of comments from Stephan, but some are still outstanding. From nobody Wed Jul 29 08:55:34 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 535E83A0BDF for ; Wed, 29 Jul 2020 08:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 56V6Oov-RlnZ for ; Wed, 29 Jul 2020 08:55:30 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 33CDD3A0BD8 for ; Wed, 29 Jul 2020 08:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1596038129; d=isode.com; s=june2016; i=@isode.com; bh=vbqCgpjj2k5d7eTTAX/3GecZtAkm8APS10UuH3hITJc=; 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=nqz7Hk9x7nViLDhiG8MdPfIH1XficaWv2P+D1QDcUrIoPVK6stvJ/naCo91Af3qxrdRLgU 7411aZYXm1icz5cvPcQgfai30mVA4Asu8Ls4/hMXi15V2DI7gmIb5bcakpNTS20RAnAPZs vzMw8S3iG5J3celUTfIv9o5APEa3e9s=; Received: from [192.168.1.216] (host31-49-142-53.range31-49.btcentralplus.com [31.49.142.53]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 29 Jul 2020 16:55:29 +0100 From: Alexey Melnikov To: Stephan Bosch , extra@ietf.org References: <159238763595.1803.574245566610096074@ietfa.amsl.com> Message-ID: Date: Wed, 29 Jul 2020 16:55:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-15.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, 29 Jul 2020 15:55:32 -0000 Hi Stephan, Thank you very much for your detailed review. Replying to most of your=20 comments below. Your remaining issues I will address in a later=20 revision/reply to later. On 16/07/2020 13:21, Stephan Bosch wrote: > Hi Alexey, > > Did you see my review (below) ? > > Regards, > > Stephan. > > Op 22-6-2020 om 19:56 schreef Stephan Bosch: >> Hi, >> >> On 17/06/2020 13:53, Alexey Melnikov wrote: >>> Hi all, >>> >>> On 17/06/2020 10:53, 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-15 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-15 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap4rev2-15 >>> >>> In this version I finally removed multiple list patterns and also=20 >>> clarified a few things based on earlier comments. >> >> I gave this document a quick review. Below are my comments so far.=20 >> Quoted text from the document is copied directly, while my comments=20 >> are prefixed with "-> ". >> >> Regards, >> >> Stephan >> >> section-2.3.2: >> >> $Phishing=C2=A0 The $Phishing keyword can be used by a delivery agent to >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mark a message as highly likely to be a ph= ishing email. An email >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that's determined to be a phishing email b= y the delivery agent >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 should also be considered a junk email and= have the appropriate >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 junk filtering applied, including setting = the $Junk flag and >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 placing in the \Junk special-use mailbox i= f available. >> -> Special-use is not mentioned up to this point. It needs to be=20 >> explained briefly or referred elsewhere. Added a reference. >> >> section-5.1: >> >> =C2=A0=C2=A0 5.=C2=A0 Two characters, "#" and "&", have meanings by conve= ntion, and >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 should be avoided except when used i= n that convention. >> -> Maybe remove the mystery and mention briefly what these are used=20 >> for conventionally (or provide some citation). Section 5.1.2.1 does=20 >> part of this, so that could at least be referred from here. Done >> section-6.3.9: >> >> -> This section mentions several examples of specific selection and=20 >> return options without introduction. It should maybe refer to=20 >> subsequent sections at the first instance of this. The document already says: =C2=A0=C2=A0 Initial selection options and return options are defined in th= e =C2=A0=C2=A0 following subsections, and new ones will also be defined in =C2=A0=C2=A0 extensions. Do you think this is not sufficient? >> >> =C2=A0=C2=A0 Future extensions to this >> =C2=A0=C2=A0 specification should keep parallelism in mind and define a p= air of >> =C2=A0=C2=A0 corresponding options. >> -> So, what exactly is meant by "parallelism" here? Do you mean=20 >> "dualism" or something like that (which I actually find equally=20 >> confusing)? I think I clarified this a bit, but expanding the description: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In general, each selection option except REC= URSIVEMATCH will have =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a corresponding return option with the same = name.=C2=A0 The REMOTE=20 selection option is an anomaly =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in this regard, and does not have a correspo= nding return option. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 That is because it expands, rather than rest= ricts, the set of=20 mailboxes =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that are returned.=C2=A0 Future extensions t= o this specification=20 should keep =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this parallelism in mind and define a pair o= f corresponding =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 selection and return options. =C2=A0[snip] >> section-6.3.9.2: >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For each >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 selectable mailbox match= ing the list pattern and selection >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 options, the server MUST= return an untagged LIST response >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 followed by an untagged = STATUS response containing the >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information requested in= the STATUS return option. >> -> This sentence describes a hard requirement, but subsequent=20 >> paragraphs describe what amounts to exceptions. Maybe this sentence=20 >> should already announce this to the reader; e.g. ", except for the=20 >> following cases." or something like that. This should also avoid=20 >> confusion about the contraction that seems to exist between the=20 >> paragraphs. Done, thanks. >> >> section-6.3.9.5: >> >> =C2=A0=C2=A0 The CHILDREN return option implements the Child Mailbox Exte= nsion, >> =C2=A0=C2=A0 originally proposed by Mike Gahrns and Raymond Cheng, of Mic= rosoft >> =C2=A0=C2=A0 Corporation. Most of the information in this section is take= n >> =C2=A0=C2=A0 directly from their original specification [RFC3348]. >> -> Is it conventional to have acknowledgements like this in the=20 >> normative text? Also, text borrowed from other RFCs is only=20 >> acknowledged in Appendix E. You are right, this is unusual. I moved this text to the Appendix E. >> >> =C2=A0=C2=A0 It is an error for the server to return both a \HasChildren = and a >> =C2=A0=C2=A0 \HasNoChildren attribute in the same LIST response. >> -> Any recommendation for what clients should do if this does happen?=20 >> Provisionally treat it as \HasChildren? >> >> section-6.3.10: >> >> =C2=A0=C2=A0 Namespace-Response-Extensions ABNF non >> =C2=A0=C2=A0 terminal is defined for extensibility and MAY be included in= the >> =C2=A0=C2=A0 response. >> -> What is this? And this sentence is incomplete (no article at the=20 >> beginning). There was a language extension to NAMESPACE response, but it is not=20 specified in this document. I clarified. =C2=A0[snip] >> section-7.4.1: >> >> -> Isn't this sub-section supposed to be in the section before? It is=20 >> about the mailbox size, not message data. Arguably EXPUNGE is about message status (the message is no longer=20 there). But I can go either way on this. =C2=A0[snip] >> section-10: >> >> -> What about RFC 3501? Good point. Added. >> >> section-11.4: >> >> =C2=A0=C2=A0 Additional security considerations are discussed in the sect= ion >> =C2=A0=C2=A0 discussing the AUTHENTICATE and LOGIN commands. >> -> Explicit references Added >> >> section-12.1: >> >> =C2=A0=C2=A0 As this specification revises the AUTH=3D prefix, STARTTLS a= nd >> =C2=A0=C2=A0 LOGINDISABLED extensions previously defined in [IMAP-TLS], I= ANA is >> =C2=A0=C2=A0 requested to update registry entries for these 3 extensions = to point >> =C2=A0=C2=A0 to this document. >> -> This is not noted in the document header. Can you explain what is the issue with this text? Are you talking about=20 documents listed as Updated/Obsolete? Thank you, Alexey From nobody Wed Jul 29 09:29:19 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 5FEAF3A0D03; Wed, 29 Jul 2020 09:29:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159604014431.11725.652474034633841130@ietfa.amsl.com> Date: Wed, 29 Jul 2020 09:29:04 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-preview-09.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, 29 Jul 2020 16:29:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP4 Extension: Message Preview Generation Author : Michael M. Slusarz Filename : draft-ietf-extra-imap-fetch-preview-09.txt Pages : 13 Date : 2020-07-29 Abstract: This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated text representation of message data useful as a contextual preview of the entire message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-09 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-preview-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-fetch-preview-09 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 Jul 29 22:03:09 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 D3B4B3A0DAD; Wed, 29 Jul 2020 22:02:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159608534181.28175.6773664769539291890@ietfa.amsl.com> Date: Wed, 29 Jul 2020 22:02:21 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-mailboxid-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 05:02:22 -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-00.txt Pages : 9 Date : 2020-07-29 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-mailboxid-00 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-mailboxid-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 29 22:22:45 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 86D433A0DD0; Wed, 29 Jul 2020 22:21:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159608648559.1489.14432199763365337689@ietfa.amsl.com> Date: Wed, 29 Jul 2020 22:21:25 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-mailboxid-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 05:21:30 -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-01.txt Pages : 9 Date : 2020-07-29 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-mailboxid-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-mailboxid-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-mailboxid-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 31 07:55:44 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 0245C3A11F6 for ; Fri, 31 Jul 2020 07:55:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159620734200.15569.14944606443520618029@ietfa.amsl.com> Date: Fri, 31 Jul 2020 07:55:42 -0700 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: Fri, 31 Jul 2020 14:55:42 -0000 Changed milestone "Adopt a document for EAI with Sieve", set due date to August 2020 from June 2020. Changed milestone "Adopt a sieve-snooze document", set due date to August 2020 from July 2020. Changed milestone "Submit sieve-mailboxid to the IESG as a proposed standard", set due date to August 2020 from July 2020, added draft-ietf-extra-sieve-mailboxid to milestone, removed draft-gondwana-sieve-mailboxid from milestone. URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Fri Jul 31 07:58:39 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 0947F3A140E for ; Fri, 31 Jul 2020 07:58:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159620751202.32659.5132498868787441426@ietfa.amsl.com> Date: Fri, 31 Jul 2020 07:58:32 -0700 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: Fri, 31 Jul 2020 14:58:32 -0000 Changed milestone "Submit Sieve EAI to IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/extra/about/