From nobody Mon Mar 9 08:26:28 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 C32153A1225; Mon, 9 Mar 2020 08:26:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <158376758563.5527.1104411405685252513@ietfa.amsl.com> Date: Mon, 09 Mar 2020 08:26:25 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-13.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, 09 Mar 2020 15:26:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-13.txt Pages : 159 Date : 2020-03-09 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-13 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 Mar 9 08:39:26 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 4116D3A1239 for ; Mon, 9 Mar 2020 08:39:24 -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 LFdLVDmyNV7x for ; Mon, 9 Mar 2020 08:39:22 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B33D73A1238 for ; Mon, 9 Mar 2020 08:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1583768357; d=isode.com; s=june2016; i=@isode.com; bh=+yT3SmSXBazRvxAzN2Be0CdtMz+6rzju3N6gLeV4ixg=; 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=aqdAbYNOtzQRmuFgjKJEOy4+1dA+qoe4tLR77yDRu7wwCIYoaghdwW7yVz/ma62A1MVM50 dS0/AnNVswJaazhRazzT9aWWfK6eh6BG4ge+yioDq8Ldy+Mk9lMl8BR0d6faOwmZ7JiKAj oKFoPg8s1Nm1Lw+4hUOjg+VSnXFDUSU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Mar 2020 15:39:17 +0000 From: Alexey Melnikov To: Bron Gondwana , extra@ietf.org Cc: Barry Leiba References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> Message-ID: Date: Mon, 9 Mar 2020 15:39:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------338EE19ED86927065B8790FE" Content-Language: en-US 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: Mon, 09 Mar 2020 15:39:24 -0000 --------------338EE19ED86927065B8790FE Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Bron, I addressed several more comments from you in -13: On 29/01/2020 12:08, Bron Gondwana wrote: > *2.2.1 Client protocol* > * > * > /"A different tag is generated by the client for each command"./=C2=A0=20 > There's no "MUST" on this, and certainly I've seen clients which=20 > don't.=C2=A0 Do we want to make that more strict in rev2?=C2=A0 It would b= e a=20 > bit of a pain on the commandline where I normally use ".", but it's=20 > also annoying as a server author that you can't rely on tag uniqueness. > > Maybe the client SHOULD generate a different tag for every command,=20 > but a server MUST accept tag reuse (could restrict concurrency, a tag=20 > can only be reused after it's been "returned") I added: =C2=A0=C2=A0 (More formally: the client SHOULD generate a unique tag for ev= ery=20 command, =C2=A0=C2=A0 but a server MUST accept tag reuse.) /* */ > > *2.3.1.1 UID Attribute > * > / > / > Both UID and UIDVALIDITY say "unsigned 32-bit value" - but strictly=20 > (as seen later in the ABNF) they aren't allowed to be zero.=C2=A0 It would= =20 > be good to say "non-zero" when each is first mentioned, but I don't=20 > care strongly about this one. Clarified. > > *2.3.2 Flags Message Attribute > * > > Should this section also reference=20 > https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xht= ml=20 > ? Added > > *5.1 Mailbox Naming > * > > This doesn't solve one of my naming bugbears.=C2=A0 The spec says things= =20 > like /"servers MAY accept a de-normalized UTF-8 mailbox name and=20 > conver it to Net-Unicode prior to mailbox creation." -/*//*there is no=20 > clear way to know what the SELECTable name will be after creating a=20 > mailbox. > > If I was designing this myself from scratch I would say that "SELECT=20 > of the same octets that were passed to CREATE MUST open that same=20 > mailbox" or something to that effect.=C2=A0 Since we're messing with how= =20 > mailbox naming works somewhat for imap4rev2, I'd be keen to add this=20 > restriction on server behaviour so that clients don't fall into a=20 > "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop. > > It still doesn't mean that you can reliably tell the correct octets=20 > for the matching mailbox from the LIST response though :( > I believe I clarified this with the following text: =C2=A0=C2=A0 However, servers MAY accept a de-normalized UTF-8 =C2=A0=C2=A0 mailbox name and convert it to Unicode normalization form "NFC= " =C2=A0=C2=A0 (as per Net-Unicode requirements) prior to mailbox creation. =C2=A0=C2=A0 Servers that choose to accept such de-normalized UTF-8 mailbox =C2=A0=C2=A0 names MUST accept them in all IMAP commands that have a mailbo= x name=20 parameter. =C2=A0=C2=A0 In particular SELECT <name> must open the same mailbox t= hat =C2=A0=C2=A0 was successfully created with CREATE <name>, even if <= ;name> =C2=A0=C2=A0 is a de-normalized UTF-8 mailbox name. > > *7.2.3 LIST Response > * > > This is the interesting bit for SPECIAL-USE - it should reference that=20 > here - as well as referencing the registry since it reproduces some of=20 > it inline. > > https://www.iana.org/assignments/imap-mailbox-name-attributes/imap-mailbox= -name-attributes.xhtml I've added the IANA registry reference. _ _ > __ > __ > *7.4.2 FETCH Response > * > > I remember past bugs with UID in "unsolicited" FLAGS responses.=C2=A0 Do w= e=20 > need to require that including UID only happen after ENABLE IMAP4REV2=20 > (as it is for ENABLE QRESYNC)? I am border line on this, but I don't think so. This should be common=20 enough that even IMAP4rev1 clients should be able to handle this. > *Appendix C: Changes > * > > Right now it's still stated as "the planned changes" and there's still=20 > some TODO in there (some of which I think could be well handled by=20 > referencing the registries rather than replicating them inline). I cleaned this up and there are only 2 smaller items remaining, that we=20 might want to discuss in the WG. Best Regards, Alexey --------------338EE19ED86927065B8790FE Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Bron,

I addressed several more comments from you in -13:

On 29/01/2020 12:08, Bron Gondwana wrote:
2.2.1 Client protocol

"A different tag is generated by the client for each command".=C2=A0 There's no "MUST" on this, and certainly I've seen clients which don't.=C2=A0 Do we want to make that more strict in rev2?=C2=A0 It would be a bit of a pain on the commandline where I normally use ".", but it's also annoying as a server author that you can't rely on tag uniqueness.

Maybe the client SHOULD generate a different tag for every command, but a server MUST accept tag reuse (could restrict concurrency, a tag can only be reused after it's been "returned")

I added:

=C2=A0=C2=A0 (More formally: the client SHOULD generate a unique tag = for every command,
=C2=A0=C2=A0 but a server MUST accept tag reuse.)


2.3.1.1 UID Attribute

Both UID and UIDVALIDITY say "unsigned 32-bit value" - but strictly (as seen later in the ABNF) they aren't allowed to be zero.=C2=A0 It would be good to say "non-zero" when each is first mentioned, but I don't care strongly about this one.

Clarified.


2.3.2 Flags Message Attribute

Added

5.1 Mailbox Naming

This doesn't solve one of my naming bugbears.=C2=A0 The spec says things like "servers MAY accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." - there is no clear way to know what the SELECTable name will be after creating a mailbox.

If I was designing this myself from scratch I would say that "SELECT of the same octets that were passed to CREATE MUST open that same mailbox" or something to that effect.=C2=A0 Since we're messing with how mailbox naming works somewhat for imap4rev2, I'd be keen to add this restriction on server behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop.

It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :(

I believe I clarified this with the following text:

=C2=A0=C2=A0 However, servers MAY accept a de-normalized UTF-8
=C2=A0=C2=A0 mailbox name and convert it to Unicode normalization form= "NFC"
=C2=A0=C2=A0 (as per Net-Unicode requirements) prior to mailbox creati= on.
=C2=A0=C2=A0 Servers that choose to accept such de-normalized UTF-8 ma= ilbox
=C2=A0=C2=A0 names MUST accept them in all IMAP commands that have a m= ailbox name parameter.
=C2=A0=C2=A0 In particular SELECT &lt;name&gt; must open the s= ame mailbox that
=C2=A0=C2=A0 was successfully created with CREATE &lt;name&gt;= , even if &lt;name&gt;
=C2=A0=C2=A0 is a de-normalized UTF-8 mailbox name.



7.2.3 LIST Response

This is the interesting bit for SPECIAL-USE - it should reference that here - as well as referencing the registry since it reproduces some of it inline.

I've added the IANA registry reference.


7.4.2 FETCH Response

I remember past bugs with UID in "unsolicited" FLAGS responses.=C2=A0 Do we need to require that including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)?

I am border line on this, but I don't think so. This should be common enough that even IMAP4rev1 clients should be able to handle this.


Appendix C: Changes

Right now it's still stated as "the planned changes" and there's still some TODO in there (some of which I think could be well handled by referencing the registries rather than replicating them inline).

I cleaned this up and there are only 2 smaller items remaining, that we might want to discuss in the WG.

Best Regards,

Alexey

--------------338EE19ED86927065B8790FE-- From nobody Mon Mar 9 08:45:03 2020 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD253A1337 for ; Mon, 9 Mar 2020 08:44:56 -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=LvLGZfXh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yIZpUYLp 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 dU17VOKHuujy for ; Mon, 9 Mar 2020 08:44:53 -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 5A8873A1336 for ; Mon, 9 Mar 2020 08:44:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 94EC2220D5 for ; Mon, 9 Mar 2020 11:44:52 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 09 Mar 2020 11:44:52 -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=fm2; bh=x0VEQF6 lQC6qfvFVGmhpj9i1m1PsrcNni/LZB/Bw11I=; b=LvLGZfXhkeLtnANMi1Ie9nr 7f3GA7gt2JGM8G0Lxro8Gk2YKV23f8LSpvElZUjc7rJPaXr4yE4iUfTqGbVE0Ct/ 5ZKEBHd5W2blW2R9D1rzGG5xnUZMHhxIld/K93sKTCDHQlqqfoXGm9PVHQZG4Br5 bqNzvVqSyq6MLB5TBoCRuKd7l57HQrpwkQbQKC+TzfjZg2m+wq9nrCV4b7ZeLBVS m0B6+/xLzBaPMC4J2Jqte9uzMJA4q/fCZ3etIeCuua6SbG2mNCU/02mno2rFJbO8 FeYxbYRrj5i+QBKf9JzezZB4l6gHpRa+Opopg8YTGOxiHWJztHGajL19xNQ7E8Q= = 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=fm2; bh=x0VEQF 6lQC6qfvFVGmhpj9i1m1PsrcNni/LZB/Bw11I=; b=yIZpUYLpcUx6SIu/ObnQOK +dZgcl6j5OUsN3LBf6BaZMjCUWKSstaXNH1ewIEtLfCG8m56iFWUvBfQwzujZWfq +oE/ZHFP0L+6xN2qSdQKNaBW+3J4RFq2M/1m3aALdWi4wNs1851ZnWue3nNUTTOz Dt4bN+EQU6p8XrS7cijIZQhBvBP/OTueCnftp+DF2mx4RSNwchaXfwlvTJlwGhgv UjqktV9H9a1w/qPv7fkbkWNBl/TVRF3a2zNgYx7pyJKzqPZUWNt7FvRYtIF4AbU4 qkRjgguTK6S+uvEuSW7PrZwTHajZpTOYlel7HtBfR9udhyV0E3J2qXhep9OS5MuQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddukedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgrnhgrrdhorhhgpd hivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 27AC2180091; Mon, 9 Mar 2020 11:44:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> Date: Mon, 09 Mar 2020 08:44:29 -0700 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=19852b6f2db9466ca830f42c84b884be 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: Mon, 09 Mar 2020 15:45:01 -0000 --19852b6f2db9466ca830f42c84b884be Content-Type: text/plain Thanks Alexey. Am traveling this week but will try to make time to review. Extra isn't meeting in Vancouver, so we will have to discuss things on the list! Probably good with the number of people not coming anyway. I'm not so sure that unsolicited UID is common, but then I haven't looked at what other servers do for 10 years or so... Cheers, Bron. On Mon, Mar 9, 2020, at 08:39, Alexey Melnikov wrote: > Hi Bron, > I addressed several more comments from you in -13: > On 29/01/2020 12:08, Bron Gondwana wrote: >> *2.2.1 Client protocol* >> ** >> *"A different tag is generated by the client for each command".* There's no "MUST" on this, and certainly I've seen clients which don't. Do we want to make that more strict in rev2? It would be a bit of a pain on the commandline where I normally use ".", but it's also annoying as a server author that you can't rely on tag uniqueness. >> >> Maybe the client SHOULD generate a different tag for every command, but a server MUST accept tag reuse (could restrict concurrency, a tag can only be reused after it's been "returned") > I added: > (More formally: the client SHOULD generate a unique tag for every command, > but a server MUST accept tag reuse.) > **** >> >> >> *2.3.1.1 UID Attribute* >> ** >> Both UID and UIDVALIDITY say "unsigned 32-bit value" - but strictly (as seen later in the ABNF) they aren't allowed to be zero. It would be good to say "non-zero" when each is first mentioned, but I don't care strongly about this one. > Clarified. >> >> >> *2.3.2 Flags Message Attribute* >> >> Should this section also reference https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml ? > Added > >> >> >> *5.1 Mailbox Naming* >> >> This doesn't solve one of my naming bugbears. The spec says things like *"servers MAY accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." -*** **there is no clear way to know what the SELECTable name will be after creating a mailbox. >> >> If I was designing this myself from scratch I would say that "SELECT of the same octets that were passed to CREATE MUST open that same mailbox" or something to that effect. Since we're messing with how mailbox naming works somewhat for imap4rev2, I'd be keen to add this restriction on server behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop. >> >> It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :( >> > I believe I clarified this with the following text: > However, servers MAY accept a de-normalized UTF-8 > mailbox name and convert it to Unicode normalization form "NFC" > (as per Net-Unicode requirements) prior to mailbox creation. > Servers that choose to accept such de-normalized UTF-8 mailbox > names MUST accept them in all IMAP commands that have a mailbox name parameter. > In particular SELECT <name> must open the same mailbox that > was successfully created with CREATE <name>, even if <name> > is a de-normalized UTF-8 mailbox name. > >> >> *7.2.3 LIST Response* >> >> This is the interesting bit for SPECIAL-USE - it should reference that here - as well as referencing the registry since it reproduces some of it inline. >> >> https://www.iana.org/assignments/imap-mailbox-name-attributes/imap-mailbox-name-attributes.xhtml > I've added the IANA registry reference. > __ >> __ >> __ >> *7.4.2 FETCH Response* >> >> I remember past bugs with UID in "unsolicited" FLAGS responses. Do we need to require that including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)? > I am border line on this, but I don't think so. This should be common enough that even IMAP4rev1 clients should be able to handle this. > >> >> *Appendix C: Changes* >> >> Right now it's still stated as "the planned changes" and there's still some TODO in there (some of which I think could be well handled by referencing the registries rather than replicating them inline). > I cleaned this up and there are only 2 smaller items remaining, that we might want to discuss in the WG. > 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 --19852b6f2db9466ca830f42c84b884be Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Alexey. Am traveling this week but will try to= make time to review.

Extra isn't meeting in Vancouver, s= o we will have to discuss things on the list! Probably good with the num= ber of people not coming anyway.

I'm not so sure that uns= olicited UID is common, but then I haven't looked at what other servers = do for 10 years or so...

Cheers,

Bron.



On Mon, M= ar 9, 2020, at 08:39, Alexey Melnikov wrote:

Hi Bron,

I addressed several more comments= from you in -13:

On 29/01/2020= 12:08, Bron Gondwana wrote:
2.2.1 Client protocol

"A differ= ent tag is generated by the client for each command".  There's no "MUST" o= n this, and certainly I've seen clients which don't.  Do we w= ant to make that more strict in rev2?  It would be a bit of a p= ain on the commandline where I normally use ".", but it's also annoying as a server author that you can't rely on tag uniqueness.

Maybe the client SHOULD generate a different tag for every command, but a server MUST accept tag reuse (could restrict concurrency, a tag can only be reused after it's been "returned")

I added:

   (More formally: the client SHOULD generate= a unique tag for every command,
   but a server MUST accep= t tag reuse.)



2.3.1.= 1 UID Attribute
Both UID and UIDVALIDITY say "unsigned 32-bit value" - but strictly (as seen later in the ABNF) they aren't allowed to be zero.  It would be good to = say "non-zero" when each is first mentioned, but I don't care strongly about this one.

Clarified.
=



2.3.2 Flags Message Attribute

Added

=

5.1 Mailbox Naming

This doesn't so= lve one of my naming bugbears.  The spec says things like "servers MAY= accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." - th= ere is no clear way to know what the SELECTable name will be after creating a mailbox.
<= br>
If I was designing this mysel= f from scratch I would say that "SELECT of the same octets that were passed to CREATE MUST open that same mailbox" or something to that effect.  Since we're messing with how mailbox namin= g works somewhat for imap4rev2, I'd be keen to add this restriction on server behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop.

It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :(

I believe I clarified this with the fol= lowing text:

   However, servers MAY accept= a de-normalized UTF-8
   mailbox name and conv= ert it to Unicode normalization form "NFC"
   (= as per Net-Unicode requirements) prior to mailbox creation.
   Servers that choose to accept such de-normalized UTF-8 m= ailbox
   names MUST accept them in all IMAP co= mmands that have a mailbox name parameter.
   In particular SELECT &= amp;lt;name&gt; must open the same mailbox that
   was successfully created = with CREATE &lt;name&gt;, even if &lt;name&gt;
   is a de-normal= ized UTF-8 mailbox name.



7.2.3 LIST Response

This is the int= eresting bit for SPECIAL-USE - it should reference that here - as well as referencing the registry since it reproduces some of it inline.<= br>

I've added the IANA registry reference= .




7.4.2 FETCH Response

I remember pas= t bugs with UID in "unsolicited" FLAGS responses.  Do we need to require that including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)?

I am border line on th= is, but I don't think so. This should be common enough that even IMAP4rev1 clients should be able to handle= this.



Appendix= C: Changes

Right now it's still stated as "the planned changes" and there's still some TODO in there (some= of which I think could be well handled by referencing the registries rather than replicating them inline).

I cleaned this up and there are only 2 smaller items remaining= , that we might want to discuss in the WG.

Best Regards,

Alexey

____________________________________________= ___
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra


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

--19852b6f2db9466ca830f42c84b884be-- From nobody Wed Mar 11 06:19: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 9CFD23A18C4 for ; Wed, 11 Mar 2020 06:19: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, FREEMAIL_FROM=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=fastmail.com header.b=iPT+cWXj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IWFXAwVp 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 3XIeED8dvEpN for ; Wed, 11 Mar 2020 06:19:36 -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 3063C3A18C1 for ; Wed, 11 Mar 2020 06:19:36 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8E43F5EC for ; Wed, 11 Mar 2020 09:19:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 11 Mar 2020 09:19:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=H xhIQP8kLo1M433+HQmVf2Ez9m9nbIYDeHBn1GL04ow=; b=iPT+cWXjdZIDOtqdv 5x0LvIjiTyvKnAgVnTzh95qgftkx5EFfVip4krKKDATMuzPxQAfAF2dQVKKpzU6m nVW9gMOMTEn4WPEZXPFa35XItPgC5ykpVY1Q3X68A0NBU7z0/C7cU4bOfqOYN1+D jw9xSDGDy9Ex+UoxrOcaEle3WKddcr+26KvPvvGh+5v8y/ZbR/8N2JAGOMqsUgMz x13j+KUJFJNtxTZp0G0ivSQu9cDMQrrVaRjHHBMl+1y1oK3JZDyezR0DSBXVj0Ee ok+1I666j+9QiLKUNdcohPVTlGrJU0ci9d+nVfaylMRA3M5pJGpxlJNPIg6fDoCE WSSMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=HxhIQP8kLo1M433+HQmVf2Ez9m9nbIYDeHBn1GL04 ow=; b=IWFXAwVpnbUauLvJ4MBGUcj5+VNDsFccxql+7M6NE+UzS/nVzMSMn3876 4YKA28QtbdniTtXZ8q/gmlNchUNlIb82fb11XcSlV5wstByReOFJf+1J8Z9SERCt 5fMhCsGddhniacNnTy4/SuZanE5lyWZVfepY0ZiL8BPaOS8m3rmnFbZC99Yuphl7 vQXrpSZufXwUb99MIQrFzEfdfty7GN5IMUMMWk/JXnFg3a8Duj9M6bLJc4WQ+PLN 0w64LVJV90LIIZPzUfTJWumNzqA3ElcKMlXlGu/VW5PUMSUXDuz9AOeBceHA7V+o dD+gOjtzC18h725OTH/14XHlIRCVA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddvvddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhfhokffffgggjggtgfesth ekredttdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehf rghsthhmrghilhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepje egrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id E8C043280066 for ; Wed, 11 Mar 2020 09:19:34 -0400 (EDT) To: extra@ietf.org References: <158376758563.5527.1104411405685252513@ietfa.amsl.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <6e37698f-15d6-2e24-5484-2a4284760e58@fastmail.com> Date: Wed, 11 Mar 2020 09:19:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158376758563.5527.1104411405685252513@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-13.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, 11 Mar 2020 13:19:38 -0000 All, For several reasons we are considering changing the Cyrus IMAP server so that a mailbox can not be DELETEd if it has children mailboxes.  That appears to be allowed by new text in IMAP4rev2: "If the server implementation does not permit deleting the name while inferior hierarchical names exists then it SHOULD disallow the DELETE command by returning tagged NO response..." I'm wondering if we should define a new HASCHILDREN response code when refusing such a DELETE.  None of the existing response codes seem to accurately capture the reason for such a refusal. On 3/9/20 11:26 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. > > Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 > Authors : Alexey Melnikov > Barry Leiba > Filename : draft-ietf-extra-imap4rev2-13.txt > Pages : 159 > Date : 2020-03-09 > > 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-13 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-13 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Ken Murchison Cyrus Development Team Fastmail US LLC From nobody Thu Mar 12 05:21: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 8B4473A0EF8 for ; Thu, 12 Mar 2020 05:21:04 -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 YV_9pV0_ELwq for ; Thu, 12 Mar 2020 05:21:02 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A3D3D3A0EFB for ; Thu, 12 Mar 2020 05:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1584015661; d=isode.com; s=june2016; i=@isode.com; bh=B4rDUOKJoPAl7JG6/lyJCXSqQfpjheNyGAas8NmGqEM=; 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=NMlu/exmXQJ/g14SN4cHygRAbzHuwJaN6lMZF4sPkm+DWgbDU++fWSMjfI8TrkUO87Iub3 l31MinGduRB7tvVhsEzgyZx+3/GmWvxmQ+CTqF6w/8X9Wq+1FUttFGM2+QaJFZUrvZ2ZnK ikvp82iguK3JgJVRtekKKObdAKxTYf8=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 12 Mar 2020 12:21:01 +0000 To: Ken Murchison References: <158376758563.5527.1104411405685252513@ietfa.amsl.com> <6e37698f-15d6-2e24-5484-2a4284760e58@fastmail.com> From: Alexey Melnikov Cc: extra@ietf.org Message-ID: Date: Thu, 12 Mar 2020 12:20:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: <6e37698f-15d6-2e24-5484-2a4284760e58@fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-13.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, 12 Mar 2020 12:21:05 -0000 Hi Ken, On 11/03/2020 13:19, Ken Murchison wrote: > All, > > For several reasons we are considering changing the Cyrus IMAP server=20 > so that a mailbox can not be DELETEd if it has children mailboxes.=C2=A0= =20 > That appears to be allowed by new text in IMAP4rev2: > > "If the server implementation does not permit deleting the name while=20 > inferior hierarchical names exists then it SHOULD disallow the DELETE=20 > command by returning tagged NO response..." > > I'm wondering if we should define a new HASCHILDREN response code when=20 > refusing such a DELETE.=C2=A0 None of the existing response codes seem to= =20 > accurately capture the reason for such a refusal. Sounds like a good idea. I've added this to my copy that will be in=20 revision -14 Best Regards, Alexey From nobody Fri Mar 13 03:23: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 752DF3A0911 for ; Fri, 13 Mar 2020 03:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W000OZJrGaMt for ; Fri, 13 Mar 2020 03:22:56 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id AD6083A07FA for ; Fri, 13 Mar 2020 03:22:56 -0700 (PDT) Received: from [192.168.10.104] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 22DF22B3C8B for ; Fri, 13 Mar 2020 10:22:55 +0000 (UTC) From: Timo Sirainen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com> Date: Fri, 13 Mar 2020 12:22:54 +0200 To: extra@ietf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Extra] SEARCHRES / IMAP4rev2 clarifications 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, 13 Mar 2020 10:23:00 -0000 I was just fixing various bugs in my SEARCHRES implementation and = realized that there's a few issues that aren't too clear: 1) SEARCH RETURN (SAVE) $ It's possible to use $ in the same search query that updates it, so the = above search should preserve $. My code cleared $ before running the = search, so the result was that $ was cleared. 2) The RFC text says: Upon successful completion of a SELECT or an EXAMINE command (after the tagged OK response), the current search result variable is reset to the empty sequence. So I was going to test that $ is preserved if SEARCH/EXAMINE fails. = Except selecting nonexistent mailbox closes the current mailbox. So then = I thought testing with invalid SELECT options, like SELECT INBOX (blah) = which returns BAD. But my current code still closes the current mailbox, = and I don't see anything in RFCs whether this should or shouldn't = happen. I suppose it's safer that the mailbox is still closed? So that = means it's a bit strange/unnecessary to specify "tagged OK response" in = the RFC text. 3) Interaction of CONTEXT and SEARCHRES:=20 SEARCH RETURN (SAVE MIN PARTIAL 2:10) 1:100 Is the $ value going to be 1 (MIN), 2:10 (PARTIAL), 1:10 (MIN+PARTIAL) = or 1:100 (ALL)? I'm thinking 1:100 is the right answer here. SEARCH RETURN (SAVE MIN UPDATE) 1:100 I suppose UPDATE should be ignored here and $ is 1. RFC 5267 does say = pretty clearly "There is no interaction between UPDATE and any other = return options" 4) Interaction of FUZZY and SEARCHRES: SEARCH RETURN (SAVE MIN = RELEVANCY) Well, this is probably clear enough that RELEVANCY shouldn't affect $ = results? But the FUZZY RFC doesn't specify very clearly how RELEVANCY = should interact with MIN, MAX or COUNT options. Maybe it could use = errata to clarify? I suppose with MIN/MAX only the one relevancy should = be returned, and with COUNT all the relevancies? From nobody Fri Mar 13 06:44:36 2020 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED3E3A07BF for ; Fri, 13 Mar 2020 06:44:27 -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 chlHICrqdzJ4 for ; Fri, 13 Mar 2020 06:44:26 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 60D013A07D3 for ; Fri, 13 Mar 2020 06:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1584107060; d=isode.com; s=june2016; i=@isode.com; bh=iG4Ao3U7KoNtGysZCmboNf07cS3210CXnTEviErc3wE=; 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=afXeZem8igOEragR6w1m/dBAjKvN/sXdjYd95Ng4mhUAqK6SL41z1Bz9A2+8M4qK/IHJAK KmRQFlCmLKxPXeJZ1ekMuEs2JT33zEt7pPNLMJvzX17W4s3NkH6S27vMPlT1Bj/PkjxUWT LAyNUGolmYVefOw7E5FQklNyKMXNUu4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Mar 2020 13:44:20 +0000 From: Alexey Melnikov To: Timo Sirainen , extra@ietf.org References: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com> Message-ID: <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com> Date: Fri, 13 Mar 2020 13:43:51 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] SEARCHRES / IMAP4rev2 clarifications 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, 13 Mar 2020 13:44:34 -0000 Hi Timo, On 13/03/2020 10:22, Timo Sirainen wrote: > I was just fixing various bugs in my SEARCHRES implementation and realized that there's a few issues that aren't too clear: > > 1) SEARCH RETURN (SAVE) $ > > It's possible to use $ in the same search query that updates it, so the above search should preserve $. My code cleared $ before running the search, so the result was that $ was cleared. Right. So "SEARCH RETURN (SAVE) $ " does nothing to the $ value. > 2) The RFC text says: > > Upon successful completion of a SELECT or an EXAMINE command (after > the tagged OK response), the current search result variable is reset > to the empty sequence. > > So I was going to test that $ is preserved if SEARCH/EXAMINE fails. Except selecting nonexistent mailbox closes the current mailbox. So then I thought testing with invalid SELECT options, like SELECT INBOX (blah) which returns BAD. But my current code still closes the current mailbox, and I don't see anything in RFCs whether this should or shouldn't happen. I suppose it's safer that the mailbox is still closed? So that means it's a bit strange/unnecessary to specify "tagged OK response" in the RFC text. Let me think about this, need more coffee :-). > 3) Interaction of CONTEXT and SEARCHRES: > > SEARCH RETURN (SAVE MIN PARTIAL 2:10) 1:100 > > Is the $ value going to be 1 (MIN), 2:10 (PARTIAL), 1:10 (MIN+PARTIAL) or 1:100 (ALL)? I'm thinking 1:100 is the right answer here. I think you found a real issue here. You are right that none of RFCs say anything about this case. I think my implementation is doing 2:10 (PARTIAL), but I need to double check. The intent of is for SAVE to use what is returned or what would have been returned. One can argue that "1:10 (MIN+PARTIAL)" is also a valid choice here. I don't think setting $ to 1:100 (ALL) is right here, because this client only wants to know PARTIAL and MIN data. Data about ALL messages might not even be available in the server, depending on how PARTIAL is constructed. > SEARCH RETURN (SAVE MIN UPDATE) 1:100 > > I suppose UPDATE should be ignored here and $ is 1. RFC 5267 does say pretty clearly "There is no interaction between UPDATE and any other return options" Agreed. > 4) Interaction of FUZZY and SEARCHRES: SEARCH RETURN (SAVE MIN RELEVANCY) > > Well, this is probably clear enough that RELEVANCY shouldn't affect $ results? But the FUZZY RFC doesn't specify very clearly how RELEVANCY should interact with MIN, MAX or COUNT options. Maybe it could use errata to clarify? I suppose with MIN/MAX only the one relevancy should be returned, and with COUNT all the relevancies? We probably need to do an update at some point, but submitting errata is sensible in this case. Best Regards, Alexey From nobody Fri Mar 13 07:09:53 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 148493A07CE for ; Fri, 13 Mar 2020 07:09:52 -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 I3q9oOqXOMy4 for ; Fri, 13 Mar 2020 07:09:50 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFC73A07CC for ; Fri, 13 Mar 2020 07:09:50 -0700 (PDT) Received: from [192.168.10.104] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 610BC2B3C8B; Fri, 13 Mar 2020 14:09:48 +0000 (UTC) From: Timo Sirainen Message-Id: <4F653ABF-8CBB-421B-AE09-DC2904C5DD56@sirainen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0B2B463A-14D0-4C86-BE5C-E780FD2545B3" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 13 Mar 2020 16:09:47 +0200 In-Reply-To: <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com> Cc: extra@ietf.org To: Alexey Melnikov References: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com> <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Extra] SEARCHRES / IMAP4rev2 clarifications 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, 13 Mar 2020 14:09:52 -0000 --Apple-Mail=_0B2B463A-14D0-4C86-BE5C-E780FD2545B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13. Mar 2020, at 15.43, Alexey Melnikov = wrote: >=20 >> 3) Interaction of CONTEXT and SEARCHRES: >>=20 >> SEARCH RETURN (SAVE MIN PARTIAL 2:10) 1:100 >>=20 >> Is the $ value going to be 1 (MIN), 2:10 (PARTIAL), 1:10 = (MIN+PARTIAL) or 1:100 (ALL)? I'm thinking 1:100 is the right answer = here. >=20 > I think you found a real issue here. You are right that none of RFCs = say anything about this case. >=20 > I think my implementation is doing 2:10 (PARTIAL), but I need to = double check. The intent of is for SAVE to use what is returned or what = would have been returned. One can argue that "1:10 (MIN+PARTIAL)" is = also a valid choice here. >=20 > I don't think setting $ to 1:100 (ALL) is right here, because this = client only wants to know PARTIAL and MIN data. Data about ALL messages = might not even be available in the server, depending on how PARTIAL is = constructed. I guess this same question also applies to what happens even if MIN = isn't used. My current code is saving 1:100, but that's mainly because = of how the implementation happens to work right now (PARTIAL isn't very = optimized). I had also been thinking that maybe a client could work like: a SEARCH RETURN (SAVE PARTIAL 1:10) TEXT stuff .. b SEARCH RETURN (PARTIAL 11:20) $ .. c SEARCH RETURN (PARTIAL 21:30) $ But I suppose that's not really something clients would do. Then again, if you do: a SEARCH RETURN (SAVE COUNT PARTIAL 1:10) 1:100 COUNT would override PARTIAL here in any case, so $ would have to be = 1:100. I wonder if we should just disallow SAVE+PARTIAL combination?= --Apple-Mail=_0B2B463A-14D0-4C86-BE5C-E780FD2545B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 13. Mar 2020, at 15.43, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

3) = Interaction of CONTEXT and SEARCHRES:

SEARCH = RETURN (SAVE MIN PARTIAL 2:10) 1:100

Is the = $ value going to be 1 (MIN), 2:10 (PARTIAL), 1:10 (MIN+PARTIAL) or 1:100 = (ALL)? I'm thinking 1:100 is the right answer here.

I think you found a real issue here. You are right that none = of RFCs say anything about this case.

I think my implementation is doing 2:10 (PARTIAL), but I need = to double check. The intent of is for SAVE to use what is returned or = what would have been returned. One can argue that "1:10 (MIN+PARTIAL)" = is also a valid choice here.

I don't think setting $ to 1:100 (ALL) is right here, because = this client only wants to know PARTIAL and MIN data. Data about ALL = messages might not even be available in the server, depending on how = PARTIAL is constructed.

I guess this same question also applies to what = happens even if MIN isn't used. My current code is saving 1:100, but = that's mainly because of how the implementation happens to work right = now (PARTIAL isn't very optimized).

I = had also been thinking that maybe a client could work = like:

a SEARCH RETURN (SAVE PARTIAL = 1:10) TEXT stuff
..
b SEARCH RETURN (PARTIAL = 11:20) $
..
c SEARCH RETURN (PARTIAL 21:30) = $

But I = suppose that's not really something clients would do.

Then again, if you = do:

a = SEARCH RETURN (SAVE COUNT PARTIAL 1:10) 1:100

COUNT would override = PARTIAL here in any case, so $ would have to be 1:100.

I wonder if we should = just disallow SAVE+PARTIAL combination?
= --Apple-Mail=_0B2B463A-14D0-4C86-BE5C-E780FD2545B3-- From nobody Fri Mar 13 08:39: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 39AD93A0A5F for ; Fri, 13 Mar 2020 08:39: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 LI5-hM3un8VF for ; Fri, 13 Mar 2020 08:39:12 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C290C3A0A05 for ; Fri, 13 Mar 2020 08:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1584113951; d=isode.com; s=june2016; i=@isode.com; bh=DZdZMD/5adqqTT4BH6ydv2KO8FAHDNcmztlK50osoUs=; 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=be0233lqAZXFJyXAp9r8ZX6+0xxSwiV/bimK0xriPFEuLYoiwNN0xKKyGImBg//Ea/5d+s 2OJ+mMcs8zyTPNnDVSzDYWhbDUV1vfAqMQ8lac5P3LWYMPjCjsbF+oQ2Gf9cjChx9+js6Q djLQH5b9jnMO0+BkD+WtO0fT5hrTjek=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Mar 2020 15:39:11 +0000 To: Timo Sirainen Cc: extra@ietf.org References: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com> <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com> <4F653ABF-8CBB-421B-AE09-DC2904C5DD56@sirainen.com> From: Alexey Melnikov Message-ID: Date: Fri, 13 Mar 2020 15:38:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: <4F653ABF-8CBB-421B-AE09-DC2904C5DD56@sirainen.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------91457AF121647BD669D43239" Content-Language: en-US Archived-At: Subject: Re: [Extra] SEARCHRES / IMAP4rev2 clarifications 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, 13 Mar 2020 15:39:14 -0000 This is a multi-part message in MIME format. --------------91457AF121647BD669D43239 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Timo, On 13/03/2020 14:09, Timo Sirainen wrote: > On 13. Mar 2020, at 15.43, Alexey Melnikov > wrote: >> >>> 3) Interaction of CONTEXT and SEARCHRES: >>> >>> SEARCH RETURN (SAVE MIN PARTIAL 2:10) 1:100 >>> >>> Is the $ value going to be 1 (MIN), 2:10 (PARTIAL), 1:10 >>> (MIN+PARTIAL) or 1:100 (ALL)? I'm thinking 1:100 is the right answer >>> here. >> >> I think you found a real issue here. You are right that none of RFCs >> say anything about this case. >> >> I think my implementation is doing 2:10 (PARTIAL), but I need to >> double check. The intent of is for SAVE to use what is returned or >> what would have been returned. One can argue that "1:10 >> (MIN+PARTIAL)" is also a valid choice here. >> >> I don't think setting $ to 1:100 (ALL) is right here, because this >> client only wants to know PARTIAL and MIN data. Data about ALL >> messages might not even be available in the server, depending on how >> PARTIAL is constructed. > > I guess this same question also applies to what happens even if MIN > isn't used. My current code is saving 1:100, but that's mainly because > of how the implementation happens to work right now (PARTIAL isn't > very optimized). > > I had also been thinking that maybe a client could work like: > > a SEARCH RETURN (SAVE PARTIAL 1:10) TEXT stuff This means save the current partial segment into $, so I think it should be 1:10 > .. > b SEARCH RETURN (PARTIAL 11:20) $ > .. > c SEARCH RETURN (PARTIAL 21:30) $ > > But I suppose that's not really something clients would do. Probably not. And if they do, they better know what it means! > Then again, if you do: > > a SEARCH RETURN (SAVE COUNT PARTIAL 1:10) 1:100 > > COUNT would override PARTIAL here in any case, so $ would have to be > 1:100. Yes. If this is surprising, then I think it should be clarified somewhere. If a client wants to retrieve COUNT, but save PARTIAL, it would have to do 2 commands. > I wonder if we should just disallow SAVE+PARTIAL combination? I would rather not. I think combination of SAVE and PARTIAL has a well specified semantics. Best Regards, Alexey --------------91457AF121647BD669D43239 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi Timo,

On 13/03/2020 14:09, Timo Sirainen wrote:
On 13. Mar 2020, at 15.43, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

3) Interaction of CONTEXT and SEARCHRES:

SEARCH RETURN (SAVE MIN PARTIAL 2:10) 1:100

Is the $ value going to be 1 (MIN), 2:10 (PARTIAL), 1:10 (MIN+PARTIAL) or 1:100 (ALL)? I'm thinking 1:100 is the right answer here.

I think you found a real issue here. You are right that none of RFCs say anything about this case.

I think my implementation is doing 2:10 (PARTIAL), but I need to double check. The intent of is for SAVE to use what is returned or what would have been returned. One can argue that "1:10 (MIN+PARTIAL)" is also a valid choice here.

I don't think setting $ to 1:100 (ALL) is right here, because this client only wants to know PARTIAL and MIN data. Data about ALL messages might not even be available in the server, depending on how PARTIAL is constructed.

I guess this same question also applies to what happens even if MIN isn't used. My current code is saving 1:100, but that's mainly because of how the implementation happens to work right now (PARTIAL isn't very optimized).

I had also been thinking that maybe a client could work like:

a SEARCH RETURN (SAVE PARTIAL 1:10) TEXT stuff
This means save the current partial segment into $, so I think it should be 1:10
..
b SEARCH RETURN (PARTIAL 11:20) $
..
c SEARCH RETURN (PARTIAL 21:30) $

But I suppose that's not really something clients would do.
Probably not. And if they do, they better know what it means!
Then again, if you do:

a SEARCH RETURN (SAVE COUNT PARTIAL 1:10) 1:100

COUNT would override PARTIAL here in any case, so $ would have to be 1:100.
Yes. If this is surprising, then I think it should be clarified somewhere. If a client wants to retrieve COUNT, but save PARTIAL, it would have to do 2 commands.
I wonder if we should just disallow SAVE+PARTIAL combination?

I would rather not. I think combination of SAVE and PARTIAL has a well specified semantics.

Best Regards,

Alexey



--------------91457AF121647BD669D43239-- From nobody Mon Mar 16 04:52:53 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 2BBB43A236B for ; Mon, 16 Mar 2020 04:52:41 -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 Oj6JvZS_jStH for ; Mon, 16 Mar 2020 04:52:39 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 18A1F3A2372 for ; Mon, 16 Mar 2020 04:52:38 -0700 (PDT) Received: from [172.20.10.2] (unknown [85.76.111.113]) by sirainen.com (Postfix) with ESMTPSA id 1B2E22B3C8B; Mon, 16 Mar 2020 11:52:37 +0000 (UTC) From: Timo Sirainen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_05F39232-2CE6-4422-B410-5673AECDC139" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Mon, 16 Mar 2020 13:52:32 +0200 In-Reply-To: <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com> Cc: extra@ietf.org To: Alexey Melnikov References: <741FE532-1213-49E9-901F-46EECB7A223C@sirainen.com> <6805c44c-83ce-49f7-2f24-e5b9a97479b4@isode.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Extra] SEARCHRES / IMAP4rev2 clarifications 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, 16 Mar 2020 11:52:52 -0000 --Apple-Mail=_05F39232-2CE6-4422-B410-5673AECDC139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13. Mar 2020, at 15.43, Alexey Melnikov = wrote: >=20 >> 4) Interaction of FUZZY and SEARCHRES: SEARCH RETURN (SAVE MIN = RELEVANCY) >>=20 >> Well, this is probably clear enough that RELEVANCY shouldn't affect $ = results? But the FUZZY RFC doesn't specify very clearly how RELEVANCY = should interact with MIN, MAX or COUNT options. Maybe it could use = errata to clarify? I suppose with MIN/MAX only the one relevancy should = be returned, and with COUNT all the relevancies? >=20 > We probably need to do an update at some point, but submitting errata = is sensible in this case. This is actually getting a bit confusing as well. The simple cases: RETURN (ALL RELEVANCY) : return ALL relevancies RETURN (MIN RELEVANCY) : return only the MIN's relevancy RETURN (MAX RELEVANCY) : return only the MAX's relevancy RETURN (PARTIAL n:m RELEVANCY) : return only the PARTIAL result's = relevancies The more confusing ones: RETURN (MIN MAX RELEVANCY) : return MIN and MAX relevancies. But what if = MIN=3DMAX, i.e. only one result? Is there 1 or 2 relevancies returned? RETURN (MIN MAX PARTIAL n:m RELEVANCY) : Similar to above - what if = MIN/MAX overlaps the PARTIAL results? RETURN (RELEVANCY) : Maybe this should be an error? RETURN (COUNT RELEVANCY) : Does this even make sense either? RETURN (MIN MAX PARTIAL n:m COUNT RELEVANCY) : Should COUNT change = anything? Maybe MIN and MAX should always prepend and append the min/max = relevancies, regardless of whether they overlap each others or PARTIAL. = And in COUNT case I'd make it a no-op regarding RELEVANCY. --Apple-Mail=_05F39232-2CE6-4422-B410-5673AECDC139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 13. Mar 2020, at 15.43, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

4) = Interaction of FUZZY and SEARCHRES: SEARCH RETURN (SAVE MIN = RELEVANCY)

Well, this is probably clear = enough that RELEVANCY shouldn't affect $ results? But the FUZZY RFC = doesn't specify very clearly how RELEVANCY should interact with MIN, MAX = or COUNT options. Maybe it could use errata to clarify? I suppose with = MIN/MAX only the one relevancy should be returned, and with COUNT all = the relevancies?

We probably need to do an update at some point, but = submitting errata is sensible in this case.

This is = actually getting a bit confusing as well. The simple = cases:

RETURN (ALL = RELEVANCY) : return ALL relevancies
RETURN (MIN = RELEVANCY) : return only the MIN's relevancy
RETURN (MAX = RELEVANCY) : return only the MAX's relevancy
RETURN (PARTIAL n:m RELEVANCY) : return only the PARTIAL = result's relevancies

The more confusing ones:

RETURN (MIN MAX RELEVANCY) : return MIN and = MAX relevancies. But what if MIN=3DMAX, i.e. only one result? Is there 1 = or 2 relevancies returned?
RETURN (MIN MAX PARTIAL n:m = RELEVANCY) : Similar to above - what if MIN/MAX overlaps the PARTIAL = results?
RETURN (RELEVANCY) : Maybe this should be = an error?
RETURN (COUNT RELEVANCY) : Does this even make sense = either?
RETURN (MIN MAX PARTIAL n:m COUNT RELEVANCY) : = Should COUNT change anything?

Maybe MIN and MAX should always prepend and = append the min/max relevancies, regardless of whether they overlap each = others or PARTIAL. And in COUNT case I'd make it a no-op regarding = RELEVANCY.

= --Apple-Mail=_05F39232-2CE6-4422-B410-5673AECDC139-- From nobody Sat Mar 21 11:30:12 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 837343A0887 for ; Sat, 21 Mar 2020 11:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zqvlaQHQ3bRx for ; Sat, 21 Mar 2020 11:30:04 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951CD3A088D for ; Sat, 21 Mar 2020 11:30:03 -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 mx4.open-xchange.com (Postfix) with ESMTPS id 62F0A6A25C; Sat, 21 Mar 2020 19:30:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1584815400; bh=AdenvNOePR3yMfzRQijwevtzp/O8VxZRo1FoYRQUJAM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=DZM4vGjIwyiXmv1Q5A8vPGrpoTJMetVmBm2orB+FIctaOcE/3NUUJ7iVqP62BcD+b x1z95sCRT4wz8r3XVxx0Nz5lIM939uUrgfR/5DEshEv3WAQid/cVNkx8xNQu9SssYf Fq1j1qrhI7QSdqBX2ncJHM3S92fJ4KMg7vKz7PQK1ndRITEd4lGDbNVYblvp8DTgQd OpLkUymyRbG1Jtz9r9q7aQcQFzAKCmIHyU5DLPv1KvrGvItLXcPX72IzRas02iQ8Ax sm+uaSNvM13/SPXE1siI1U+iwMpl+8wEng+oN7+3+h0Z9O53DVgPl+I79L0FataAsc O9M3LZ13MmpwA== Received: from [10.168.3.2] (unknown [10.217.131.6]) (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 2545D3C008C; Sat, 21 Mar 2020 19:30:00 +0100 (CET) To: Bron Gondwana Cc: extra@ietf.org References: <67511f7a-b273-4b0b-a874-9be5542c5eaa@beta.fastmail.com> From: Stephan Bosch Message-ID: Date: Sat, 21 Mar 2020 19:29:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <67511f7a-b273-4b0b-a874-9be5542c5eaa@beta.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Extra] EAI Sieve X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:30:10 -0000 Hi, On 17/01/2020 05:51, Bron Gondwana wrote: > Hi Stephan, > > According to the minutes from the EXTRA session in Singapore, you have > been volunteered to write a Sieve EAI spec.  Can you please upload it if > you have one, or write one, or let us know not to expect it if you've > changed your mind. > It is very much a draft document with lots of holes, but it should provide enough content for discussion and feedback: A new version of I-D, draft-bosch-sieve-eai-00.txt has been successfully submitted by Stephan Bosch and posted to the IETF repository. Name: draft-bosch-sieve-eai Revision: 00 Title: Sieve: Internationalized Email Document date: 2020-03-21 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-bosch-sieve-eai-00.txt Status: https://datatracker.ietf.org/doc/draft-bosch-sieve-eai/ Htmlized: https://tools.ietf.org/html/draft-bosch-sieve-eai-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-bosch-sieve-eai Abstract: This document defines an extension to the Sieve language called "eai" which adds full support for internationalized email. Regards, Stephan. From nobody Tue Mar 31 12:28:22 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 5CBBC3A0F2E for ; Tue, 31 Mar 2020 12:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=fastmail.com header.b=Ev4pV1Nk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZLa7dxgv 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 Ejnm-KA-cSLi for ; Tue, 31 Mar 2020 12:28:17 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCC03A0F2D for ; Tue, 31 Mar 2020 12:28:17 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 118825C01BB for ; Tue, 31 Mar 2020 15:28:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 31 Mar 2020 15:28:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= to:from:subject:message-id:date:mime-version:content-type; s= fm2; bh=U2c7YhGK5GYrhVcG1eYTzag5fj68DaHpv+ofi8j0Ka0=; b=Ev4pV1Nk RRX5i239r2v0PT+p2CHQP8bYj9Xi3RKIL3zQ74Htu+yCSt4uI6wX42CwWpTI5UkL sqO+1kY0tmSOooDiQM+3aX/J8vMuwm+uIuBqDlMjLOJKKlrhu22uOrULzmUWNsWW 5N5q7aUDDrjRZuWJ2Xeu2TqE+bRQ2ekHSwSjxn0elvmZ8/iD51BEBxjaIgNB3Ts4 vbLPNrZmO1OMVDGO4jyWgtPfIJeK4jxkCy7C3LQA6ampBqnQhuGG2VBBt0QiRj4Q 1Ay65MKO5dajiyHTKuzVg/ZJZ5p5zcoVkY7OcGpQDQLYnaAkTbpfmTl0eTxyGBkX qWaAtJ3abL3zJQ== 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=fm2; bh=U2c7YhGK5GYrhVcG1eYTzag5fj68D aHpv+ofi8j0Ka0=; b=ZLa7dxgvlQmc2we1YHrebTcbsXoL+Q01LnJPRDa7zQs9m 9pieluzg8qS9MggynZpg7dhBLOBVqa4T5Jeo6AMUJ3HukQecypAU1ZdM1JQidMus TY6RzDZ8a4hUGAoFKre9cKph/SIlwALGUArG+iqonxqhA+oFCBzV10p0EMXQy2SE k1xrzpOKwbYwWRVHTkkWMH0xYBW0d/8fB6p15lawGaCohk261psTWs5bbyRTaXL0 HAY/442QVVKs92Vgtbt1iai/f+6Hlq/Jtkh8eYYLXXDKXEzX4DgZjARf/+35sQ9R gDDDXwe/Ok4o7kQ0mPp4F+thoovv4NSkxNlXIwryQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvhffuohfkffgfgggtsegrtderre dtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshht mhgrihhlrdgtohhmqeenucffohhmrghinhepfiefrdhorhhgpdgvgigrmhhplhgvrdgtoh hmnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id B8076306CBA4 for ; Tue, 31 Mar 2020 15:28:16 -0400 (EDT) To: extra@ietf.org From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Tue, 31 Mar 2020 15:28:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CC388FEBB4A995FB7A566CEF" Content-Language: en-US Archived-At: Subject: [Extra] Sieve Vacation question 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, 31 Mar 2020 19:28:20 -0000 This is a multi-part message in MIME format. --------------CC388FEBB4A995FB7A566CEF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All, Reading and re-reading Section 4.4 of RFC5230, I'm not sure if the :mime data is supposed to be inserted into the response message as-is (after To, From, Date, Subject, etc), or if it needs to be wrapped in another MIME entity. In other words, is the complete outgoing message simply: To: foo@example.org From: bar@example.net Subject: Automated Reply Date: Tue, 31 Mar 2020 15:00:00 -0400 Auto-Submitted: auto-replied (vacation) Content-Type: multipart/alternative; boundary=foo --foo I'm at the beach relaxing. Mmmm, surf... --foo Content-Type: text/html; charset=us-ascii How to relax

I'm at the beach relaxing. Mmmm, surf... --foo-- -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------CC388FEBB4A995FB7A566CEF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

All,

Reading and re-reading Section 4.4 of RFC5230, I'm not sure if the :mime data is supposed to be inserted into the response message as-is (after To, From, Date, Subject, etc), or if it needs to be wrapped in another MIME entity.

In other words, is the complete outgoing message simply:


To: foo@example.org
From: bar@example.net
Subject: Automated Reply
Date: Tue, 31 Mar 2020 15:00:00 -0400
Auto-Submitted: auto-replied (vacation)
Content-Type: multipart/alternative; boundary=foo

--foo

I'm at the beach relaxing.  Mmmm, surf...

--foo
Content-Type: text/html; charset=us-ascii

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
 "http://www.w3.org/TR/REC-html40/strict.dtd">
<HTML><HEAD><TITLE>How to relax</TITLE>
<BASE HREF="http://home.example.com/pictures/"></HEAD>
<BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
Mmmm, <A HREF="ocean.gif">surf</A>...
</BODY></HTML>

--foo--

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC
--------------CC388FEBB4A995FB7A566CEF-- From nobody Tue Mar 31 12:54:24 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 D7CB53A2AAC for ; Tue, 31 Mar 2020 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwIh_0xh_Y5Z for ; Tue, 31 Mar 2020 12:54:19 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 8D3FF3A2A96 for ; Tue, 31 Mar 2020 12:54:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJ5KSUJKSG005D48@mauve.mrochek.com> for extra@ietf.org; Tue, 31 Mar 2020 12:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1585684156; bh=JJA+8i8sH8D0qO2jbtL0u74r0bTWOxZvtgiesBys+hE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=NTBv4qqjuAGdVc8HUnW/dFaZ7yWPFZSSU2WB5WhDy4KZ7jNNyeYRH+oDz5VRgQ5Bt lWZA2HG4qHk/OrBFmr357lcUYYTwHdBylkQL0Z6BIQxG8xf9UdVGfCSTrxfOfTaLw2 knCzwu+Myyna3FVC93lhRN7xidfMUFYgfvVLdqX8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RIHLDFQH34000058@mauve.mrochek.com>; Tue, 31 Mar 2020 12:49:13 -0700 (PDT) Cc: extra@ietf.org Message-id: <01RJ5KSSZ2FA000058@mauve.mrochek.com> Date: Tue, 31 Mar 2020 12:45:09 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 31 Mar 2020 15:28:15 -0400" References: To: Ken Murchison Archived-At: Subject: Re: [Extra] Sieve Vacation question 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, 31 Mar 2020 19:54:22 -0000 I don't see anything in there saying to insert an extra entity level, so no, there's no wrapping involved. And as a practical matter, if you wrap the supplied example in either a multipart/something or a message/rfc822, it's not going to work correctly in some clients. Ned P.S. The reason it limits things to "MIME entity" is that way you can't specify message headers, only MIME stuff, using this mechanism. > All, > Reading and re-reading Section 4.4 of RFC5230, I'm not sure if the :mime > data is supposed to be inserted into the response message as-is (after > To, From, Date, Subject, etc), or if it needs to be wrapped in another > MIME entity. > In other words, is the complete outgoing message simply: > To: foo@example.org > From: bar@example.net > Subject: Automated Reply > Date: Tue, 31 Mar 2020 15:00:00 -0400 > Auto-Submitted: auto-replied (vacation) > Content-Type: multipart/alternative; boundary=foo > --foo > I'm at the beach relaxing. Mmmm, surf... > --foo > Content-Type: text/html; charset=us-ascii > "http://www.w3.org/TR/REC-html40/strict.dtd"> > How to relax > >

I'm at the beach relaxing. > Mmmm, surf... > > --foo-- > -- > Ken Murchison > Cyrus Development Team > Fastmail US LLC From nobody Tue Mar 31 12:55: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 63CC23A2AAE for ; Tue, 31 Mar 2020 12:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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=fastmail.com header.b=FIsu6ymK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ybAJSbSz 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 zZABFQQkgyh8 for ; Tue, 31 Mar 2020 12:55:15 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299FB3A2AAD for ; Tue, 31 Mar 2020 12:55:15 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 599125C0407; Tue, 31 Mar 2020 15:55:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 31 Mar 2020 15:55:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=d tfjjtShT/z4g8Gjq32iWmDg6k+LzsjtIXxws5UxSbE=; b=FIsu6ymKljawZPJPc 2kFkfXcUFQD9fQ/BNE+V4p/y1DQBYLsB4KWPjxbgQLrpFxP2mkGaDUJsBA082EsM ZRDWaojNIsffyktyb3LIsq2VJtYIVoiCxt1RSKyTSaHEzo4KwXaOxSZghPlflEe/ BMP2RLAKUpZ2iapnmRNrcjnP3+vvrB/ObZfT/5PacTfESZhsvGtEAXjTsPj3Rr1N os7KZzZ1CNSM4oKrNm/psY9QRMYJkVGNCgTwGBG249qKOYN1ESkjP/YcUQqhynuU cdTPRJjdzV0W/UswdPsQTQ5Kz358OrGua2dhlLA1aRaoIvmxEVno92wPisphyK4K aRlxw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=dtfjjtShT/z4g8Gjq32iWmDg6k+LzsjtIXxws5UxS bE=; b=ybAJSbSzd+QWTctR9jS8yn5ERu4fL/1P+3+4M2xK7GRcV0oVi1arPf9vt QUYlsReHkdaqTS/JTZ7AhBTmQLgC87SapNpdv7w9EfOmUdrVlPb8PziEWDyztWJn lTpUCnAeVcZflWxzGgZjsA/7bpvD+yLUIPe5CfoqQrh55xo7X0LAX59DSrs4URnv SY8QrR+42OooWZKSVoC2IbDjpNs+VxEne87aE8w6g6/tjHrB5/t3jWJ9+eO0SsNi +5cf2Ao1hLrZPBqIkIBNwRd6KwOCRsxWoqDdDMeeUOocvYEnUGBoAWrv5oDuTNYM mft1oI1/L/OONhPYWEjVo2H+0xV0w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghn ucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucffoh hmrghinhepfiefrdhorhhgpdgvgigrmhhplhgvrdgtohhmnecukfhppeejgedrjeejrdek hedrvdehtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id C6A2D306CBC6; Tue, 31 Mar 2020 15:55:12 -0400 (EDT) To: Ned Freed Cc: extra@ietf.org References: <01RJ5KSSZ2FA000058@mauve.mrochek.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <23430a57-2636-2cad-ddfe-671f01188cc4@fastmail.com> Date: Tue, 31 Mar 2020 15:55:12 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <01RJ5KSSZ2FA000058@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] Sieve Vacation question 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, 31 Mar 2020 19:55:18 -0000 Thanks for the quick response Ned. On 3/31/20 3:45 PM, Ned Freed wrote: > I don't see anything in there saying to insert an extra entity level, so > no, there's no wrapping involved. > > And as a practical matter, if you wrap the supplied example in either > a multipart/something or a message/rfc822, it's not going to work > correctly in some clients. >                 Ned > > P.S. The reason it limits things to "MIME entity" is that way you > can't specify > message headers, only MIME stuff, using this mechanism. >> All, > >> Reading and re-reading Section 4.4 of RFC5230, I'm not sure if the :mime >> data is supposed to be inserted into the response message as-is (after >> To, From, Date, Subject, etc), or if it needs to be wrapped in another >> MIME entity. > >> In other words, is the complete outgoing message simply: > > >> To: foo@example.org >> From: bar@example.net >> Subject: Automated Reply >> Date: Tue, 31 Mar 2020 15:00:00 -0400 >> Auto-Submitted: auto-replied (vacation) >> Content-Type: multipart/alternative; boundary=foo > >> --foo > >> I'm at the beach relaxing.  Mmmm, surf... > >> --foo >> Content-Type: text/html; charset=us-ascii > >> >   "http://www.w3.org/TR/REC-html40/strict.dtd"> >> How to relax >> >>

I'm at the beach relaxing. >> Mmmm, surf... >> > >> --foo-- > > >> -- >> Ken Murchison >> Cyrus Development Team >> Fastmail US LLC > -- Ken Murchison Cyrus Development Team Fastmail US LLC