From nobody Mon Jul 1 00:29:26 2019 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 6F7F812000E; Mon, 1 Jul 2019 00:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utim4DiWkJ-d; Mon, 1 Jul 2019 00:29:16 -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 5A89612001B; Mon, 1 Jul 2019 00:29:16 -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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id CB72F6A28C; Mon, 1 Jul 2019 09:29:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1561966151; bh=bhJ6Tzbe/bnWypagtWJla9XBlf18OY8lbOT5DZIY8s0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=KDO5fxzJLJ8SsyC0Z1tFc9Ozz9hLO+i1boucys4FGjGilaKHv60vx2/0Mm1RIny5J 06FAwaKW5Ged0QJEKDqMEVIGXYEHKb7ZydcM+zmolL0uLbs/yzL1XmijMc0XjIt8+f /OIklcEZR8vdQ813SuD0j6Q5F9IM429WyYLGj9BlEnOCrsfEfhQgW4gAyqwwctGgnR 3yJ9HcxN8xaHnfNOzvL9yajBjoTCqdHGaQcsIGZVazFTTPrIY+E3RqRHxgYcO3/1jZ YixhPMVEhLtu+LIqHdad41SmMmb49Y2j3Nn6IH5INC9sIKCPDl0i1da9yT8zqN3uGK DqQuiEGglDHkQ== 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 BEFA13C0024; Mon, 1 Jul 2019 09:29:11 +0200 (CEST) Date: Mon, 1 Jul 2019 01:29:11 -0600 (MDT) From: Michael Slusarz Reply-To: Michael Slusarz To: Barry Leiba Cc: extra@ietf.org, Bron Gondwana , The IESG , draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <891167002.11504.1561966151796@appsuite-gw2.open-xchange.com> In-Reply-To: References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.2-Rev6 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=michael.slusarz@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFdRf+ABCACjsnzeuEJqUrZHnmyTL0r8JwN0YF6ZS/hgHYx83/dhz2LRgq0bkl5FSYPc6ZY7j7G NqvvPxR4Ri6xfevym91IhdJbQaiJ2B0kWAz+p4H/iXhgZwsYdjFN/c3+MPEjSazCPwASWCDHv2ueCay 0YO2dmw9TnR6rA6GiReQPGumgCZJ4xX8AUBUQftdJOrq/fl1xpYWrsFrTIfBml1x3Q4Mf3+ocH7ZT/u SST2IJTx4a9szQcnrsVHn/Fc2wp4P4FkW87sQFpLND80E5VAwxEdCAtQrhoocUfmh3LyyIncAOIRdw0 aR/1PSgwuj8A2c1W0DRYuzCNaGveugCT6GmbF7qbABEBAAG5AQ0EV1F/4AEIAJ98e4BRvKeJSzSqybD ZzOcphkUy+PlMrhkQkc2m36U01+4E9AtUz3XGNIJE+in9yYKqXbtHJCavOPcFhktVGFvSADKT311ZXq Cx/ibvrWI/DmoBCCIY9iwrutJX08nOoj53wpiNVOuR6vGFJIHO7TNosPcWWsw16LiZIwo9GiU2KseU/ xW0h26ouPbVqVpFX1Tgv+xaCBF8rj4kgoghnvTVG5aEgF+QExOLqx6BmarePKboTFVnMk6NYAwC5TtJ DfpWqa/5vQa8oVAex09elUrN+IQM/tcbMG+tAe5mhjJCke96tdEno29KYjs3Ecl9t1GMcsVAM1k8D8J DJzPCB/cAEQEAAYkBMQQYAQIAGwUCV1F/4AIbDAQLCQgHBhUKCQgLAgUJEswDAAAKCRAH1y6/pl54M6 obB/9AbXRu5SYhYrmTMFGDNqq0BKeoeS1n6cA2rvYRPmmwKSd9/sZG6815X8worSUjPb4r0P/9UoUUy P99BIN0aKc/7baCCV2/00fITrW0sS5Es2xuDuwcRAwwMJX09yMDeCu6M0Y2kn8QjKr1Pu87isoxliQz QDdsYJd9b/iSPFAW+sV7xYlkVcw4XoXYolQTUjNBuWbl6tV6dQN66m6RnCnB1uolFtbZENRiVcHOAdI DmYMjX3UL8cMtqpMyAXe0HTkb1BK2I5m4Kz0thK+beBBLyd6M4bK45zI6L3f5oDOty9o2jAnxlSVdUi ZfBSBypOekOX0bw2w/4XtUoS9emDRk Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) 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, 01 Jul 2019 07:29:19 -0000 Apologies on taking too long to respond. I neglected to update the draft with the other changes discussed in previous messages; I will upload that now. See below for additional responses. > On June 2, 2019 11:33 AM Barry Leiba wrote: > > > I think we're still in significant disagreement here; I'd like others > from the working group to comment, and see if that can move us in one > direction or the other. > > > > > I'll start with providing a (future) real-world example, and why this > > > > behavior exists in its present form. Given a hypothetical future > > > > algorithm "IMAGE" (generate image/jpeg preview if image data exists in > > > > message), I issue this preview command: > > > > > > > > a FETCH 1 (PREVIEW (LAZY=IMAGE FUZZY)) > > > > > > > > This is asking the server: provide me an image preview of the message, > > > > but ONLY if 1) the message actually contains image information and 2) > > > > that image information is already generated or can be generated very > > > > quickly. Otherwise, fall back to FUZZY generation. > > > > > > Hm. That really seems like a contrived example. How would the client > > > software possibly know whether there's useful information in the > > > image, or whether the information in the accompanying text is more or > > > less important? Suppose I have two messages: > > > > > > 1. text/plain that basically says nothing; image/jpeg that has a > > > diagram that explains everything > > > > > > 2. text/plain that has the entire real content of the message; > > > image/jpeg of the senders company logo > > > > > > It's pretty clear from that explanation that for message 1 I want some > > > sort of description of the image and for message 2 I want a preview of > > > the text. But how would the client software know that, and, > > > therefore, know what to ask for? > > > > Is that what a typical received message looks like? To me, that looks like the edge case. > > It's not the "typical" message, but I don't think it's an edge case > either. I do often get messages where the only significant content is > in an image. (I've tried to dissuade those responsible from sending > things that way, but they persist.) So, no, I wouldn't call it an > "edge case" either. And even if it were, that's not really the point; > see below. Agreed that this is not really the point of this discussion. We aren't discussing how an image preview algorithm would work, since in practice it would likely need to be designed to be smart enough to not return image data for things like embedded company logos. (This is approaching "what is an attachment?" territory.) > > Seems that a server could figure out (through experience) when image > > preview data should be calculated or ignored. Image size, MIME > > structure information, MIME order, etc. could all be used to reach some > > sort of 95% accuracy threshold. Maybe that doesn't happen day 1 of > > implementation, but a competitive, reactive server implementation will > > work on this. > > > > The same issue exists for text previews, FWIW. What about a text/plain > > + text/html alternative message, where text/plain is "Please click on > > this URL to view the text part", and the text/html part is empty text > > (it's a single image link). A server can be programmed to be smart > > enough to ignore that part re: preview. > > > > As written, we allow a server to be given the latitude to figure these > > kind of issues out. Closing down that opportunity because it might be > > a difficult logical problem isn't the right approach from my view. > > I note that in your response you say "server" four times, at least > once per paragraph, and "client" never. But my point (see above) was, > "But how would the client software know that, and, therefore, know > what to ask for?" These are things a *client* is requesting; how does > the client know whether to request that the preview be preferentially > done on the image or on the text? I contend that it doesn't, and > can't, and that, therefore, it's strange to expect it to ask, and > strange to say that the server has to take the client's "priority > decision" into account. Client: "Please provide me the richest content you can - richest content is defined via the priority list I provided." I don't see how a client providing a priority order of preview algorithms is any different than what the client would do if it had to download the message and parse it for preview data? Also, how this is any different than issuing two consecutive FETCH PREVIEW commands? If the first PREVIEW command returns the empty string, a client is just going to send another FETCH command using the next PREVIEW algorithm in the list. Thus, the client is indicating its "priority decision" by the order it is sending its commands. Why not do that in a single command? > I'm still looking for a real use case where the *client* is the entity > that's better suited to asking for any specific action with respect to > a message preview. See below. > > > Apart from that, if we're going to do any sort of text-based preview > > > of an image, I would think we'd just say that when FUZZY is applied to > > > an image, that's what it does. > > > > FUZZY is explicitly defined as text only output though, since that's generally mapping > > what clients already do. > > Well, but saying, "That's the way it works now," isn't really the > point. We need to be looking at how we *want* this to work going > forward, and I think that having the *server* decide what the best way > is to give a preview of a message is the right answer. And if that > means that the server decides to make a preview from the text/plain > part, the text/html part, the application/pdf part, or the image/jpeg > part (perhaps using OCR on the image), then I think that's fine. > FUZZY is explicitly defined as text only, only because that's how > we've defined it so far. How would a client handle this? Does it need to provide a list of all media types it supports to the server, ala the HTTP Accept header? That sounds overly complicated for a solution where text/plain is the primary use-case (see, e.g., JMAP preview). More generally, I can provide this (real-world) example as my final argument as to the behavior at issue in this message. Client: - images, videos, and URLs are commonly sent in messages - client wants to show small image preview if image is only content of message - client wants to show small image preview (or maybe a short GIF) if video is only content of message - client wants to show small image preview of website if a URL is only content of the message - server supports 3 PREVIEW extensions: IMG, VID, URL The client, when listing (syncing) messages in the mailbox, will issue a FETCH PREVIEW for all of (IMG, VID, URL). These PREVIEW extensions describe mutually exclusive message data, so the client doesn't care which one is returned - it is identifying to the client what it supports display-wise. For this client, it might make the decision whether to FETCH BODY text based on whether preview data is returned for a message. This scenario is describing the UI behavior of every chat-like client out there: whether it be SMS/MMS, WhatsApp, iMessage, etc. So it is extremely common, and generally reflects the experience a user expects when using messaging. So a preview specification should theoretically be extensible to handle this kind of use-case. To me it makes the most sense to allow this in a single FETCH call - one of the stated goals of the FETCH PREVIEW spec is to reduce roundtrips. A "priority list" of algorithms is nothing more than a potential list of sequential FETCH calls the client might make. michael From nobody Mon Jul 1 00:29:42 2019 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 55DD812001B for ; Mon, 1 Jul 2019 00:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zZ9vf_dig8X for ; Mon, 1 Jul 2019 00:29:38 -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 22B8312001A for ; Mon, 1 Jul 2019 00:29:38 -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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 92C406A28C; Mon, 1 Jul 2019 09:29:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1561966176; bh=mKSHCd/sXbrQufmuWh//chbaA1yjlqxM2hEWFiT5Njk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=0lgGCyHcbZyYy97kFLKx1Mf9qrwQMzZeW7qBV/rYiXf+uRGi4d6gfxowLjfoae9on gyeeh9l28vs49PZE97d157W4Mr0msKgre++H6Z9cfAwj1m5FkLzE1sgVY9f5NqitnL YpfnC+K9JOkjCLAAEK7oXYySmw9WTkYU/cNk1pRhGgAh9ythOdBSWvrZeKtcfB1IFM trePn1UuKumSOZy19LtptOqen00DG0vVaxt5XSABLW9Yg/h8ZhzFmx4fHTGUcDJJdN 82V5dtdX+/DEqnNjohpdxp968Uc1Nc+IepnnZoba4Vm7vKiEAujiOd/apkmkoJjRnS KG8QkL5DV8HHQ== 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 869F43C0024; Mon, 1 Jul 2019 09:29:36 +0200 (CEST) Date: Mon, 1 Jul 2019 01:29:35 -0600 (MDT) From: Michael Slusarz Reply-To: Michael Slusarz To: Neil Jenkins , extra@ietf.org Message-ID: <855477053.11506.1561966175692@appsuite-gw2.open-xchange.com> In-Reply-To: <70781805-f45f-43aa-b71b-a1862a3610bb@beta.fastmail.com> References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> <70781805-f45f-43aa-b71b-a1862a3610bb@beta.fastmail.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.2-Rev6 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=michael.slusarz@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFdRf+ABCACjsnzeuEJqUrZHnmyTL0r8JwN0YF6ZS/hgHYx83/dhz2LRgq0bkl5FSYPc6ZY7j7G NqvvPxR4Ri6xfevym91IhdJbQaiJ2B0kWAz+p4H/iXhgZwsYdjFN/c3+MPEjSazCPwASWCDHv2ueCay 0YO2dmw9TnR6rA6GiReQPGumgCZJ4xX8AUBUQftdJOrq/fl1xpYWrsFrTIfBml1x3Q4Mf3+ocH7ZT/u SST2IJTx4a9szQcnrsVHn/Fc2wp4P4FkW87sQFpLND80E5VAwxEdCAtQrhoocUfmh3LyyIncAOIRdw0 aR/1PSgwuj8A2c1W0DRYuzCNaGveugCT6GmbF7qbABEBAAG5AQ0EV1F/4AEIAJ98e4BRvKeJSzSqybD ZzOcphkUy+PlMrhkQkc2m36U01+4E9AtUz3XGNIJE+in9yYKqXbtHJCavOPcFhktVGFvSADKT311ZXq Cx/ibvrWI/DmoBCCIY9iwrutJX08nOoj53wpiNVOuR6vGFJIHO7TNosPcWWsw16LiZIwo9GiU2KseU/ xW0h26ouPbVqVpFX1Tgv+xaCBF8rj4kgoghnvTVG5aEgF+QExOLqx6BmarePKboTFVnMk6NYAwC5TtJ DfpWqa/5vQa8oVAex09elUrN+IQM/tcbMG+tAe5mhjJCke96tdEno29KYjs3Ecl9t1GMcsVAM1k8D8J DJzPCB/cAEQEAAYkBMQQYAQIAGwUCV1F/4AIbDAQLCQgHBhUKCQgLAgUJEswDAAAKCRAH1y6/pl54M6 obB/9AbXRu5SYhYrmTMFGDNqq0BKeoeS1n6cA2rvYRPmmwKSd9/sZG6815X8worSUjPb4r0P/9UoUUy P99BIN0aKc/7baCCV2/00fITrW0sS5Es2xuDuwcRAwwMJX09yMDeCu6M0Y2kn8QjKr1Pu87isoxliQz QDdsYJd9b/iSPFAW+sV7xYlkVcw4XoXYolQTUjNBuWbl6tV6dQN66m6RnCnB1uolFtbZENRiVcHOAdI DmYMjX3UL8cMtqpMyAXe0HTkb1BK2I5m4Kz0thK+beBBLyd6M4bK45zI6L3f5oDOty9o2jAnxlSVdUi ZfBSBypOekOX0bw2w/4XtUoS9emDRk Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) 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, 01 Jul 2019 07:29:41 -0000 =20 =20
Neil,
Thanks for your comments.  Responses below.

On June 2, 2019 6:27 PM Neil Jenkins <neilj@fastmailteam.com> wro= te:


I must admit to having skimmed this discussion, but it seems to me that= this extension is getting way over-complicated. The key here is simply to = answer the question: what is this for? The only purpose of this is to provi= de a way for clients to get a snippet of (plain) text to shown in the mailb= ox listing without downloading whole body parts and expecting a fast respon= se from the server (like fetching common headers). This is a common feature= and worth making more efficient. Trying to do anything else is making thin= gs more complicated for close to zero benefit.
I agree that a plaintext preview, to mimic what exists in current client= UIs, was a main driving factor for creating this draft.  I disagree t= hat this is the only potential use-case.

I would contend:
  • No server is going to implement more than one algorithm. Like with = fuzzy searching, we should not specify the algorithm in the spec. Servers s= hould be free to implement the best solution they can, which is likely to c= hange over time as new edge cases are found and new capabilities are availa= ble (for example, skipping salutations, OCRing an image-only body, skipping= broken auto-generated plain text components and generating the preview fro= m the text/html version instead, etc.). The server should be free to choose= which parts it thinks it should use to generate the preview.
We are in agreement here.  This is FUZZY.  We have defined som= e output requirements and limitations, but that output is up to the server.

  • The client either accepts the server is going to give it a good pre= view or it will ignore the whole capability and generate its own, at the ex= pense of being slower and more data hungry.
  • The output is always just plain text. This is what is shown in mail= box listings as the preview in Apple Mail, Gmail, FastMail, etc. If you thi= nk an image or text/html preview is useful, I disagree, but regardless that= should be a different spec rather than overcomplicating one that solves an= actual use case today. (To be clear, I think the spec already says this, b= ut some of the comments in this thread seemed to indicate to me people thou= ght you might want different typed outputs in the future).
I disagree with this logic, as it is essentially "let's standardize what= already exists in clients."  I'd rather design a standard that fits t= he current use cases AND can be extended to future use cases.

A real world example - we are currently working on an initiative to push= email as a chat medium (Shameless plug:=20 https://www.coi-dev.org/). = ; In every chat client I have ever used, sending images and/or video is an = important part of conversations.  When an image/video appears in a cha= t stream, the full contents are not generally displayed - it is a small pre= view of the image (or a small preview of a frame of the video).  That = small image that is surely a "preview" of that message.  Mixed media p= reviews are a very common paradigm in other messaging systems - why should = email be any different?

We shouldn't have to come back in a year and propose a new "FETCH IMAGEP= REVIEW" standard to support this - we should instead be able to propose a s= imple, optional extension to the base PREVIEW behavior.

  • (Perhaps controversial but=E2=80=A6) If the server offers the capab= ility it should always have the data readily available, so the LAZY modifie= r is not necessary. I would expect servers that implement this to generally= calculate and cache a preview on delivery. If it's going to take a while, = the benefit to the client is much less and it might as well just calculate = its own. That way the client only has two code paths (server-preview or cli= ent-preview) rather than three (server delayed preview as well).
We index on delivery, but there's plenty of reasons why preview may not = be available at a later time.  More important, a preview is not a fund= amental part of the message data - it is data created via transformation of= that data.  The original message cannot be recreated, but previews ca= n - a server operator should be allowed to choose different storage and/ret= ention policies based on that fact.

A client doesn't have to use LAZY.  A server can quickly support LA= ZY by returning NIL for every message requested - this doesn't add any appr= eciable overhead to the client/server interaction, as the client would need= to issue a separate FETCH PREVIEW call regardless of whether LAZY was supp= orted or not.  If LAZY is not something a client/server operator wants= to deal with the complexities of, they can be avoided at almost zero devel= opment cost.

In the JMAP Mail spec, we simply specify the following for the equivale= nt property:

preview :  String
A plain text fragment of the message body. This is intended to be s= hown as a preview line on a mailbox listing, and may be truncated when show= n. The server may choose which part of the message to include in the previe= w; skipping quoted sections and salutations and collapsing white-space can = result in a more useful preview.

This MUST NOT be more than 256 characters in length.
PREVIEW=3DFUZZY and JMAP preview can be serviced by the same data (Bron = suggested changes to the preview spec in the past to ensure this), so I thi= nk we are good here.

michael
=20 From nobody Mon Jul 1 00:32:57 2019 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 3000C120019; Mon, 1 Jul 2019 00:32:56 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <156196637616.5792.1503981132867191765@ietfa.amsl.com> Date: Mon, 01 Jul 2019 00:32:56 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-preview-06.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, 01 Jul 2019 07:32:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP4 Extension: Message Preview Generation Author : Michael M. Slusarz Filename : draft-ietf-extra-imap-fetch-preview-06.txt Pages : 14 Date : 2019-07-01 Abstract: This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-preview-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-fetch-preview-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 1 21:53:31 2019 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 8EC0912008D for ; Mon, 1 Jul 2019 21:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=e3SxkUED; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kCtgqqZ7 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 PCjm1RQUY8pB for ; Mon, 1 Jul 2019 21:53:27 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5199812004D for ; Mon, 1 Jul 2019 21:53:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 77D2D21E44; Tue, 2 Jul 2019 00:53:26 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 02 Jul 2019 00:53:26 -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=Wa5eSig Hpm509xJkEt+yUduWSPo5fzpSH9Wt4gsyulc=; b=e3SxkUED56iVTuhRYrCYPDR HOBq4Es/326rnGrK+URtXpDXTN+yhKHqQqSeXqPr1QNZnBXvbRk0Mz71t78mkTVj /74lU9wqzBefad9AL/Cc5JylzfGzbg+XzHiyA5vAgfKHe9mphcDRCv/Naj5Jgwj6 hVNVC/248x4e5MITzYg/DaFTZKZeYIiSs73sOX26o89JJ/fWSpOm662yKP4JKsbH fUOkFW/OCL/phRrDisrAoG/MM33VU3iomrSk0gWWmmWhQBrQQonNGiADRKYf7AtO mrv3nqaZ20O+PT2Z8cvxDae5jr4UTQo69TPdExsSiaA8yNrBqbsqp4i0OjJ7AUw= = 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=Wa5eSi gHpm509xJkEt+yUduWSPo5fzpSH9Wt4gsyulc=; b=kCtgqqZ7L1biDIhZT+ApCs 2tc59rBPxsUeSOLewaql6vtITcFmhCW6Wd2wrbqiVfMgb0vX9XJa8qIONkOwyUqg qaHwpKrQbHyrdfFhgcjchDyJKdsj7DxiRbff67+YfvJRIAP4YHHE2K9vVsS9EPuv 2uM8eYCINgo5PXYCKlW3yqCp9KszL3J58lkkHC8J0q4d1ZP/95UzeLpx1KQxopsb 7PCXgC/JlERB5Itq3D1frhk+W6qpo6w8u1fVCTG8YJ2estYPucqEZfRnNU1bLIx5 RNwmBgjijrNR8+jzhL0LobC32NVrpShKcqUSOY4WpDHYm5Ke59tVC/FE7qzYyH2g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdejgdekjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpegtohhiqdguvghvrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhm pehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CB349180091; Tue, 2 Jul 2019 00:53:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <855477053.11506.1561966175692@appsuite-gw2.open-xchange.com> References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> <70781805-f45f-43aa-b71b-a1862a3610bb@beta.fastmail.com> <855477053.11506.1561966175692@appsuite-gw2.open-xchange.com> Date: Tue, 02 Jul 2019 14:53:25 +1000 From: "Neil Jenkins" To: "Michael Slusarz" , extra@ietf.org Content-Type: multipart/alternative; boundary=c7d44cde9c614c94945526a90beeb650 Archived-At: Subject: Re: [Extra] =?utf-8?q?Barry_Leiba=27s_Discuss_on_draft-ietf-extra-im?= =?utf-8?q?ap-fetch-preview-03=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 02 Jul 2019 04:53:30 -0000 --c7d44cde9c614c94945526a90beeb650 Content-Type: text/plain On Mon, 1 Jul 2019, at 17:29, Michael Slusarz wrote: > A real world example - we are currently working on an initiative to push email as a chat medium (Shameless plug: https://www.coi-dev.org/). In every chat client I have ever used, sending images and/or video is an important part of conversations. When an image/video appears in a chat stream, the full contents are not generally displayed - it is a small preview of the image (or a small preview of a frame of the video). That small image that is surely a "preview" of that message. Mixed media previews are a very common paradigm in other messaging systems - why should email be any different? > > We shouldn't have to come back in a year and propose a new "FETCH IMAGEPREVIEW" standard to support this - we should instead be able to propose a simple, optional extension to the base PREVIEW behavior. I see, thanks for providing your motivation for this, it makes it much easier to discuss. This is certainly *a* solution to this problem, but I do wonder if it's the best one. If we start with the requirement that we must use IMAP for the chat message sync protocol, which admittedly does limit the options somewhat, the other main thing I would try is fetching the body structure with the COI client when getting a message listing. You would be able to see that, for example, a message has only an image/png part and how large it is. If it's small, the client may just fetch it directly. If it's large, you want a way for the client to ask the server for this image downsampled to a particular size; the client can specify exactly what it needs to optimise bandwidth usage. Neil. --c7d44cde9c614c94945526a90beeb650 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, 1 Jul 2= 019, at 17:29, Michael Slusarz wrote:
A real world example - we are currently working on an in= itiative to push email as a chat medium (Shameless plug: https://www.coi-dev.org/).  In every chat= client I have ever used, sending images and/or video is an important pa= rt of conversations.  When an image/video appears in a chat stream,= the full contents are not generally displayed - it is a small preview o= f the image (or a small preview of a frame of the video).  That sma= ll image that is surely a "preview" of that message.  Mixed media p= reviews are a very common paradigm in other messaging systems - why shou= ld email be any different?

We shouldn't ha= ve to come back in a year and propose a new "FETCH IMAGEPREVIEW" standar= d to support this - we should instead be able to propose a simple, optio= nal extension to the base PREVIEW behavior.
<= br>
I see, thanks for providing your motivation for this, it m= akes it much easier to discuss. This is certainly a solution= to this problem, but I do wonder if it's the best one. If we start with= the requirement that we must use IMAP for the chat message sync protoco= l, which admittedly does limit the options somewhat, the other main thin= g I would try is fetching the body structure with the COI client when ge= tting a message listing. You would be able to see that, for example, a m= essage has only an image/png part and how large it is. If it's small, th= e client may just fetch it directly. If it's large, you want a way for t= he client to ask the server for this image downsampled to a particular s= ize; the client can specify exactly what it needs to optimise bandwidth = usage.

Neil.
--c7d44cde9c614c94945526a90beeb650-- From nobody Tue Jul 9 09:15:35 2019 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 786551206CF; Tue, 9 Jul 2019 09:15: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: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <156268893231.15786.8849995440978646095@ietfa.amsl.com> Date: Tue, 09 Jul 2019 09:15:32 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-05.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:15:33 -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-05.txt Pages : 145 Date : 2019-07-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-05 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 14 05:40:00 2019 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 6071A1200E3 for ; Sun, 14 Jul 2019 05:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=uOZTqolO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rCaHN9Vn 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 TGzH7pMG9Zrx for ; Sun, 14 Jul 2019 05:39:57 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FA312017C for ; Sun, 14 Jul 2019 05:39:56 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9CC4621B42; Sun, 14 Jul 2019 08:39:53 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 14 Jul 2019 08:39:53 -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:cc:subject:content-type; s=fm3; bh=NhML XnsQmpgiYT5RYW49aEqOfKc54n8NidDLZ1BdDsw=; b=uOZTqolOJqift7r985lZ ewr8M58QPCDsHY7ZXoBam5EekJdp9XYtsPUz4hFjoNP7jkyC0f30fA5bt4s4J6sj 70s3Xb+y3KhIoicIESLtTb03Qwa+Yu8LyIT0Anpl0H9w9/XO+PeoOfnXWQswa+Ik oQ4Et8A+uMZVMfUXJS5Tff9RJlE9s1gAz21DFPkhx0SIVXBpUi9QvT3Lhqea/GFm NZG8zG77BYyP5re8swXrIybkagu3qOuC+dSPHgPzbXQDKlrg7LzSlXbB/RclrjUk GxGLFbK6ZX5JMj2qjE6Ai20v+sY/X4Xz69CHV3ONFdNFLmtoDAEbSYLmTJPmCwoV Yw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NhMLXn sQmpgiYT5RYW49aEqOfKc54n8NidDLZ1BdDsw=; b=rCaHN9VnLTrl93ba+wz2f6 qIrSnylzsJUGjopi8cDeZWst6LU3hyXZQhJHV6YNuIrcsY5rXVj7n2liUmyApt36 b5dRmGiJaRMwIzq7z3uPiF2EWsVcUkOVMFJRdCQHz8p44qVSl4TJpADwIQlEgEWf NyQcho63lsr5h2DUz+wbpGXHDUczV9icY7V49J6O5xKr6eOood2BPjTUNDGVqDC4 Gmi4uW52A5+07z3pb/kfZoDEXhT9atWgYZwZ9wQ6kROtqIrkahumFcWfsAvtXlgq f+Fq1hpTmEZ4sjeP695u5zJonN46J1shA+zWQdLcJHzitJ2i5DLe71CM8yn4MLMQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrheehgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegs rhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C66C4185C67; Sun, 14 Jul 2019 08:39:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <33b03176-fd2d-474a-abb8-043f1d45451d@www.fastmail.com> In-Reply-To: <156268893231.15786.8849995440978646095@ietfa.amsl.com> References: <156268893231.15786.8849995440978646095@ietfa.amsl.com> Date: Sun, 14 Jul 2019 22:39:52 +1000 From: "Bron Gondwana" To: extra@ietf.org Cc: "Alexey Melnikov" , "Barry Leiba" Content-Type: multipart/alternative; boundary=de90ead9656e4a0c89aab29558332034 Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-05.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: Sun, 14 Jul 2019 12:39:59 -0000 --de90ead9656e4a0c89aab29558332034 Content-Type: text/plain Late comment on this - based on a query that came up in info-cyrus. RFC3501 was not clear on the handling of subscription when renaming folders, or when a client uses the DELETE command itself via IMAP. It does say that the server must not unilaterally remove the subscription if the folder no longer exists (e.g. an alerts mailbox when gets deleted when empty and recreated when new email arrives), but nothing else. It would be good to clarify expected behaviour in those two cases, and at least say the server MAY delete the subscription if the user deletes a folder, and maybe even SHOULD rename the subscription if the user renames the folder! Cheers, Bron. On Wed, Jul 10, 2019, at 02:15, 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-05.txt > Pages : 145 > Date : 2019-07-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-05 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --de90ead9656e4a0c89aab29558332034 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Late comment on this - based on a query that came up in in= fo-cyrus.  RFC3501 was not clear on the handling of subscription wh= en renaming folders, or when a client uses the DELETE command itself via= IMAP.  It does say that the server must not unilaterally remove th= e subscription if the folder no longer exists (e.g. an alerts mailbox wh= en gets deleted when empty and recreated when new email arrives), but no= thing else.

It would be good to clarify expected behaviou= r in those two cases, and at least say the server MAY delete the subscri= ption if the user deletes a folder, and maybe even SHOULD rename the sub= scription if the user renames the folder!

Cheers,

Bron.

On Wed, Jul 10, 2019, at 02:15, internet= -drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts di= rectories.
This draft is a wo= rk item of the Email mailstore and eXtensions To Revise or Amend WG of t= he IETF.

        Title=            : INTERNET = MESSAGE ACCESS PROTOCOL - VERSION 4rev2
        Authors  = ;       : Alexey Melnikov
       &nb= sp;           &nb= sp;      Barry Leiba
Filename        : dr= aft-ietf-extra-imap4rev2-05.txt
Pages           : 1= 45
Date   &nbs= p;        : 2019-07-09

Abstract:
   The I= nternet Message Access Protocol, Version 4rev2 (IMAP4rev2)
   allows a client to access and= manipulate electronic mail messages on
   a server.  IMAP4rev2 permits manipulation o= f mailboxes (remote
 &nb= sp; message folders) in a way that is functionally equivalent to local
   folders.  IM= AP4rev2 also provides the capability for an offline
   client to resynchronize with the serve= r.

   IMAP4rev2 includes operations for creatin= g, deleting, and renaming
&nb= sp;  mailboxes, checking for new messages, permanently removing mes= sages,
   setting a= nd clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing,
   searching, and selective fet= ching of message attributes, texts, and
   portions thereof.  Messages in IMAP4rev2 ar= e accessed by the use of
&nbs= p;  numbers.  These numbers are either message sequence number= s or unique
   iden= tifiers.

   IMAP4rev2 does not specify a means = of posting mail; this function is
   handled by a mail submission protocol such as RFC 6409= .


The IETF da= tatracker 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-05
https://d= atatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extr= a-imap4rev2-05


Please note that it may take a couple of minutes from the time of subm= ission
until the htmlized ver= sion and diff are available at tools.ietf.org.

Internet-D= rafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

____= ___________________________________________
Extra mailing list
Extra@ietf.org
https://w= ww.ietf.org/mailman/listinfo/extra


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


= --de90ead9656e4a0c89aab29558332034-- From nobody Sun Jul 14 06:12:37 2019 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 3EB361201F8 for ; Sun, 14 Jul 2019 06:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC9xRS8wcXWz for ; Sun, 14 Jul 2019 06:12:33 -0700 (PDT) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DE71201EC for ; Sun, 14 Jul 2019 06:12:33 -0700 (PDT) Received: by mail-io1-f49.google.com with SMTP id j6so29989175ioa.5 for ; Sun, 14 Jul 2019 06:12:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vkM7GWqxMum84gz5RK7O7MpFxIdmkLluhfzsizT8jrw=; b=M5JpDy4ztpG4Pqf8T8IRE+MRvZ/EQY4m6DwhmwsNoAo1wsushhMlWkvULG/R5iNyDl ip9HaQAX8feBCT6GfPrZrRUVxoUtiTHDFjOWVGNOhaVRfMFN3fJG6vCSzpfbX/zfraZs cj13WBTBXTOsORrR6IMd6pBrdiWMG1iF7vj0Xj6fZVa5JJRaiVnTPcAwgYWzcDp4mfWI Syto0jXS2RL7R30juXZcLJzxw7UPnBpb8ZeXOgp1oX+DQrj6mc7PudFcnUOynGGvWwHG zg9W494taa3rmEYiUFZZzRD/8QBmGUiAQEzNMDVQzeWMEgmi8Xmh5tUP5AMpoBr47OiW I7Gg== X-Gm-Message-State: APjAAAWa4KZcHZMht0s7JAIzBmTJvrLshmm0YZOwLXzjd1smhDYDdj/i P8RG+xa7uoslE9Tg51Hh88UKvcecOIfdStdAo98= X-Google-Smtp-Source: APXvYqxe0GfpTjDYQBIV2iNb6wTSuAh01px4KxmLJwms3FrjcVu9c2K1NifLV4DcUo/z28l47PJC0DQBLfqeZHwLoq0= X-Received: by 2002:a5e:9701:: with SMTP id w1mr20633083ioj.294.1563109952728; Sun, 14 Jul 2019 06:12:32 -0700 (PDT) MIME-Version: 1.0 References: <156268893231.15786.8849995440978646095@ietfa.amsl.com> <33b03176-fd2d-474a-abb8-043f1d45451d@www.fastmail.com> In-Reply-To: <33b03176-fd2d-474a-abb8-043f1d45451d@www.fastmail.com> From: Barry Leiba Date: Sun, 14 Jul 2019 09:12:22 -0400 Message-ID: To: Bron Gondwana Cc: Alexey Melnikov , extra@ietf.org Content-Type: multipart/alternative; boundary="0000000000007a34ad058da3e52e" Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-05.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: Sun, 14 Jul 2019 13:12:35 -0000 --0000000000007a34ad058da3e52e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is a really dicey situation, because it=E2=80=99s impossible to know w= hat the user wants, depending upon the situation. One can easily come up with reasonable scenarios where the subscription is strictly to a mailbox=E2=80= =99s name, and it should not follow a rename. I think the best we can do is talk about the options and use cases, and leave it without normative statements. Barry On Sun, Jul 14, 2019 at 8:40 AM Bron Gondwana wrote: > Late comment on this - based on a query that came up in info-cyrus. > RFC3501 was not clear on the handling of subscription when renaming > folders, or when a client uses the DELETE command itself via IMAP. It do= es > say that the server must not unilaterally remove the subscription if the > folder no longer exists (e.g. an alerts mailbox when gets deleted when > empty and recreated when new email arrives), but nothing else. > > It would be good to clarify expected behaviour in those two cases, and at > least say the server MAY delete the subscription if the user deletes a > folder, and maybe even SHOULD rename the subscription if the user renames > the folder! > > Cheers, > > Bron. > > On Wed, Jul 10, 2019, at 02:15, 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 4rev= 2 > Authors : Alexey Melnikov > Barry Leiba > Filename : draft-ietf-extra-imap4rev2-05.txt > Pages : 145 > Date : 2019-07-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-05 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap4rev2-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > --0000000000007a34ad058da3e52e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a really dicey situation, because it=E2=80= =99s impossible to know what the user wants, depending upon the situation.= =C2=A0 One can easily come up with reasonable scenarios where the subscript= ion is strictly to a mailbox=E2=80=99s name, and it should not follow a ren= ame.

I think the b= est we can do is talk about the options and use cases, and leave it without= normative statements.

B= arry

On Sun, Jul 14, 2019 at 8:40 AM Bron Gondwana <brong@fastmailteam.com> wrote:
L= ate comment on this - based on a query that came up in info-cyrus.=C2=A0 RF= C3501 was not clear on the handling of subscription when renaming folders, = or when a client uses the DELETE command itself via IMAP.=C2=A0 It does say= that the server must not unilaterally remove the subscription if the folde= r no longer exists (e.g. an alerts mailbox when gets deleted when empty and= recreated when new email arrives), but nothing else.

It would = be good to clarify expected behaviour in those two cases, and at least say = the server MAY delete the subscription if the user deletes a folder, and ma= ybe even SHOULD rename the subscription if the user renames the folder!
=

Cheers,

Bron.

On Wed, Jul 10, 2019, at 0= 2:15, interne= t-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line I= nternet-Drafts directories.
This = draft is a work item of the Email mailstore and eXtensions To Revise or Ame= nd WG of the IETF.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tit= le=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : INTERNET M= ESSAGE ACCESS PROTOCOL - VERSION 4rev2
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Alexey Melnikov
=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 Barry Leiba
Fi= lename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-ietf-extra-imap4re= v2-05.txt
Pages=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 145
Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 : 2019-07-09

Abstract:
=C2=A0=C2=A0 The Internet Message Access Protocol, Version 4re= v2 (IMAP4rev2)
=C2=A0=C2=A0 allow= s a client to access and manipulate electronic mail messages on
=C2=A0=C2=A0 a server.=C2=A0 IMAP4rev2 permi= ts manipulation of mailboxes (remote
=C2=A0=C2=A0 message folders) in a way that is functionally equivalent = to local
=C2=A0=C2=A0 folders.=C2= =A0 IMAP4rev2 also provides the capability for an offline
=C2=A0=C2=A0 client to resynchronize with the serv= er.

=C2=A0=C2=A0 IMAP4rev2 includes operations for creating, dele= ting, and renaming
=C2=A0=C2=A0 m= ailboxes, checking for new messages, permanently removing messages,
=C2=A0=C2=A0 setting and clearing flags,= RFC 5322, RFC 2045 and RFC 2231 parsing,
=C2=A0=C2=A0 searching, and selective fetching of message attribut= es, texts, and
=C2=A0=C2=A0 porti= ons thereof.=C2=A0 Messages in IMAP4rev2 are accessed by the use of
=C2=A0=C2=A0 numbers.=C2=A0 These number= s are either message sequence numbers or unique
=C2=A0=C2=A0 identifiers.

=C2=A0=C2=A0 IMAP4rev2 d= oes not specify a means of posting mail; this function is
=C2=A0=C2=A0 handled by a mail submission protocol= such as RFC 6409.


The= IETF datatracker status page for this draft is:

<= div style=3D"font-family:Arial">There are also htmlized versions available = at:
=
A diff from the previous version= is available at:


Please note that it m= ay 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
--
=C2=A0 Bron Gondwana, CEO, Fastmail= Pty Ltd
=C2=A0 brong@fastmailteam.= com


--0000000000007a34ad058da3e52e-- From nobody Mon Jul 15 06:23:02 2019 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 77C1412008A for ; Mon, 15 Jul 2019 06:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=b5+IJYoq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oRfMiOkc 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 xQCsY17HGwvU for ; Mon, 15 Jul 2019 06:22:58 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFC612004C for ; Mon, 15 Jul 2019 06:22:58 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 03FFE20D2D for ; Mon, 15 Jul 2019 09:22:58 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 15 Jul 2019 09:22:58 -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=aH67WZY TzYYgK3AxNbRW47bbh612DI34biPXgiL+tas=; b=b5+IJYoqce+OSnSFoTcIYvw vwGOFpNrvFOZe2KX/xmoEV5KY2tJJTHqbWpkelkk70/E1m+f5pSV/NA6fCZ1/Tja bU0RgYG6UYUl2oA7yihM9WDF4x6LrRQfM/Op6CiSywZSUvRGLKio7f9h6xL2Upg+ hvwZbE8xX67Q5qGDMQZa6cWqNKs5iExJL5CYBLEaMoDTRw16Tq8cmjIfekmy49RG vFqnrsClT+zHtJffBy4D2OHEqR5aGudrWdNyJ2J5LTZWbEaqSEIioGKDRTMo4uBt M7ra1vBl3ynvc6JRzNiSZ5DUDr5n9yjWSXeN6hR54I4MKZ0+Q1yJcqvtzYpgWdw= = 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=aH67WZ YTzYYgK3AxNbRW47bbh612DI34biPXgiL+tas=; b=oRfMiOkchYIvNlRRlTApsI NryTSrykXEvUt1cL57sZt8flcNhJfM4R1xoKa2XpZkbTDYTOzlIcssbFRuOhXUCo hv9thx56jvO/Gb8j3vQxPH+wXaUjbrDVKE1TouhWaFuArPKdVd94liLTLpCByEA1 mjyxyaWr5ge5ESFP24OuGQAiZmAl5QQnC+FYqcAME4Xy+fWx+NqRVZrXCwNYcPGV 2Q4xjbjLorxIHb3vxeq+wndqutDnDDs9tkR1MfZ9YsLCp4lhcz64xSPBUv8WfRja f2XcIW64/dpVwuIa1Eb/Smd+Ec7bYphJ2F2ZYO2jRilml76QDj9//AT+xSLAqL3Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrheekgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghdpih gvthhfrddrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshht mhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 59E1F190AEB; Mon, 15 Jul 2019 09:22:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <70c02daf-4b3f-4cc3-8ef3-ae7e6da4db1b@www.fastmail.com> In-Reply-To: References: <156268893231.15786.8849995440978646095@ietfa.amsl.com> <33b03176-fd2d-474a-abb8-043f1d45451d@www.fastmail.com> Date: Mon, 15 Jul 2019 23:22:56 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=5d83bfb673624a36a4e8ca28e0036ab9 Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-05.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 13:23:02 -0000 --5d83bfb673624a36a4e8ca28e0036ab9 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Can we give clients a reliable sequence? I expect it's probably somethin= g like: a RENAME X Y b SUBSCRIBE Y c UNSUBSCRIBE X Bron. On Sun, Jul 14, 2019, at 23:12, Barry Leiba wrote: > This is a really dicey situation, because it=E2=80=99s impossible to k= now what the user wants, depending upon the situation. One can easily co= me up with reasonable scenarios where the subscription is strictly to a = mailbox=E2=80=99s name, and it should not follow a rename. >=20 > I think the best we can do is talk about the options and use cases, an= d leave it without normative statements. >=20 > Barry >=20 > On Sun, Jul 14, 2019 at 8:40 AM Bron Gondwana = wrote: >> __ >> Late comment on this - based on a query that came up in info-cyrus. R= FC3501 was not clear on the handling of subscription when renaming folde= rs, or when a client uses the DELETE command itself via IMAP. It does sa= y that the server must not unilaterally remove the subscription if the f= older no longer exists (e.g. an alerts mailbox when gets deleted when em= pty and recreated when new email arrives), but nothing else. >>=20 >> It would be good to clarify expected behaviour in those two cases, an= d at least say the server MAY delete the subscription if the user delete= s a folder, and maybe even SHOULD rename the subscription if the user re= names the folder! >>=20 >> Cheers, >>=20 >> Bron. >>=20 >> On Wed, Jul 10, 2019, at 02:15, internet-drafts@ietf.org wrote: >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. >>> This draft is a work item of the Email mailstore and eXtensions To R= evise or Amend WG of the IETF. >>>=20 >>> Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 >>> Authors : Alexey Melnikov >>> Barry Leiba >>> Filename : draft-ietf-extra-imap4rev2-05.txt >>> Pages : 145 >>> Date : 2019-07-09 >>>=20 >>> Abstract: >>> The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) >>> allows a client to access and manipulate electronic mail messages o= n >>> 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. >>>=20 >>> 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 uniqu= e >>> identifiers. >>>=20 >>> IMAP4rev2 does not specify a means of posting mail; this function i= s >>> handled by a mail submission protocol such as RFC 6409. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-05 >>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-05 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-imap4rev2-05 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of su= bmission >>> until the htmlized version and diff are available at tools.ietf.org.= >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> Extra mailing list >>> Extra@ietf.org >>> https://www.ietf.org/mailman/listinfo/extra >>>=20 >>=20 >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --5d83bfb673624a36a4e8ca28e0036ab9 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Can we give clients a reliable sequence?  I expect it= 's probably something like:
<= br>
a RENAME X Y
b SUBSCRIBE Y
c UNSUBSCRIBE X
<= br>
Bron.

On Sun, Jul 14, 2019, at 23:12, Barry= Leiba wrote:
This is a really dicey situation, because it=E2=80=99s impossi= ble to know what the user wants, depending upon the situation.  One= can easily come up with reasonable scenarios where the subscription is = strictly to a mailbox=E2=80=99s name, and it should not follow a rename.=

I think th= e best we can do is talk about the options and use cases, and leave it w= ithout normative statements.

Barry

On Sun, Jul 14, 2019 at 8:40 AM Bron Gondwana <brong@fastmailteam.com> wrote:

Late comment on this - based on a query that came up in = info-cyrus.  RFC3501 was not clear on the handling of subscription = when renaming folders, or when a client uses the DELETE command itself v= ia IMAP.  It does say that the server must not unilaterally remove = the subscription if the folder no longer exists (e.g. an alerts mailbox = when gets deleted when empty and recreated when new email arrives), but = nothing else.

It would be good to clarify expected behavi= our in those two cases, and at least say the server MAY delete the subsc= ription if the user deletes a folder, and maybe even SHOULD rename the s= ubscription if the user renames the folder!

Cheers,
=
Bron.

On Wed, Jul 10, 2019, at 02:15= , internet-drafts@ietf.org wrote:


=
      &n= bsp; Title           := INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
        Authors&= nbsp;        : Alexey Melnikov
      = ;            = ;        Barry Leiba
Filename      &= nbsp; : draft-ietf-extra-imap4rev2-05.txt
Pages         =   : 145
Date  =           : 2019-07-09
<= /div>

Abstract:
 &n= bsp; The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
=
   allows a client to = access and manipulate electronic mail messages on
   a server.  IMAP4rev2 permits mani= pulation of mailboxes (remote
   message folders) in a way that is functionally equivalent = to local
   folders= .  IMAP4rev2 also provides the capability for an offline
<= div style=3D"font-family:Arial;">   client to resynchronize wi= th the server.

   IMAP4rev2 includes operations= for creating, deleting, and renaming
   mailboxes, checking for new messages, permanently = removing messages,
 &nbs= p; setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing,<= br>
   searching, and s= elective fetching of message attributes, texts, and
   portions thereof.  Messages in IM= AP4rev2 are accessed by the use of
   numbers.  These numbers are either message seque= nce numbers or unique
 &= nbsp; identifiers.

=
   IMAP4rev2 does not specif= y a means of posting mail; this function is
   handled by a mail submission protocol such a= s RFC 6409.


T= he IETF datatracker status page for this draft is:

There are also htmlized versions available= at:

A diff from the previous version is avail= able at:

<= br>
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.

Int= ernet-Drafts are also available by anonymous FTP at:

_________________= ______________________________
Extra mailing list


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


_____= __________________________________________
Extra mailing l= ist
Extra@ietf.org
https://www.ietf.org/mail= man/listinfo/extra


--
  Bron Gondwana, CEO, Fas= tmail Pty Ltd
  brong@fastmailtea= m.com


--5d83bfb673624a36a4e8ca28e0036ab9--