From nobody Fri May 10 22:30:49 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 82687120112; Fri, 10 May 2019 22:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYYr7Rv46hjr; Fri, 10 May 2019 22:30:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC66912004F; Fri, 10 May 2019 22:30:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1F4C9B81FE8; Fri, 10 May 2019 22:30:37 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, extra@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190511053037.1F4C9B81FE8@rfc-editor.org> Date: Fri, 10 May 2019 22:30:37 -0700 (PDT) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8579_on_Sieve_Email_Filtering=3A_Deliverin?= =?utf-8?q?g_to_Special-Use_Mailboxes?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 05:30:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8579 Title: Sieve Email Filtering: Delivering to Special-Use Mailboxes Author: S. Bosch Status: Standards Track Stream: IETF Date: May 2019 Mailbox: stephan.bosch@open-xchange.com Pages: 12 Characters: 24716 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-extra-sieve-special-use-05.txt URL: https://www.rfc-editor.org/info/rfc8579 DOI: 10.17487/RFC8579 The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute. This document is a product of the Email mailstore and eXtensions To Revise or Amend Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri May 10 22:31:16 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 731F812027A; Fri, 10 May 2019 22:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf59vwDPBO6f; Fri, 10 May 2019 22:30:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A695C12025C; Fri, 10 May 2019 22:30:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0644CB81FF3; Fri, 10 May 2019 22:30:51 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, extra@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190511053051.0644CB81FF3@rfc-editor.org> Date: Fri, 10 May 2019 22:30:51 -0700 (PDT) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8580_on_Sieve_Extension=3A_File_Carbon_Cop?= =?utf-8?q?y_=28FCC=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: Sat, 11 May 2019 05:31:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8580 Title: Sieve Extension: File Carbon Copy (FCC) Author: K. Murchison, B. Gondwana Status: Standards Track Stream: IETF Date: May 2019 Mailbox: murch@fastmailteam.com, brong@fastmailteam.com Pages: 12 Characters: 25316 Updates: RFC 5230, RFC 5435 I-D Tag: draft-ietf-extra-sieve-fcc-09.txt URL: https://www.rfc-editor.org/info/rfc8580 DOI: 10.17487/RFC8580 The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively. This document is a product of the Email mailstore and eXtensions To Revise or Amend Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat May 11 03:51:40 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 69A68120142 for ; Sat, 11 May 2019 03:51:38 -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=c+x/hZnI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=y+lYu/j6 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 ugf552JFCXaP for ; Sat, 11 May 2019 03:51:37 -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 553CB1200EF for ; Sat, 11 May 2019 03:51:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7A2B02AC85 for ; Sat, 11 May 2019 06:51:36 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 11 May 2019 06:51:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=AuVzpp9vwje30qRvRmlLGQPrF5UfvwuK3qXWvYT ziU4=; b=c+x/hZnItLYp399/D6zTKqaBRkQaQgXDGuX45A7oNehmm4ICkQefEs/ YBnukEAR058jIKXsytW3WSitiYPTEZiQ5KSAwa0Th+rbBp0r3v+2812My/FkgWTX sNn5b30D+dNewmAyeAlXJ+6R2u2hOG61JmKt0EdGdrC+C9blZQAiwxuKvQa8JAT+ ih3hypfrzT94nbG+mPwpttDRe2iiKm2vtGNiY29ERBPBMZY0DeOSGTvJMEcimw1Z MXZprXiHuLXzIJM6L7KQ4VQWcyzEoCGEAexqN2+e4BH/1jbADeFyL65pzV8I97kb y13v20UsDdp/ntkNWA002qoXNbsWKOw== 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=AuVzpp9vwje30qRvRmlLGQPrF5Ufv wuK3qXWvYTziU4=; b=y+lYu/j6Pjkz1Yze6TEdGQn7u1BXnhaERG1upFxDB8fS9 b3CjQfhW4QwiOKAwpWQnjUXTzJsPSFwlNkODnNISR6hjWn/tG2uMKfwy7x92OMRm k5XucdVn6DxibFSFqWCE4Y74DmOD7ZP4ntb4O6W+80dK1jsSWBp/DkhoFrCdDMln tpivZcoEiWUmNxX/v5CHDinPblx4ZRMdI39F+kBHYg4VixRdbKi3BgtLjhdOgjkw Mvt3dc7Rwrk5xNjK5xOepN1amxizjJEam9SSfGfWsT7+ptRVf7HFwqURyva1PkwA 0/Ck6et9ZlL/5Pm1DO66d59FYpsE4yLGex0ALwkBw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrledtgdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonh hgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E2A77211C4; Sat, 11 May 2019 06:51:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <4fcf402d-973d-412b-8b57-47cb827e581f@www.fastmail.com> Date: Sat, 11 May 2019 06:51:35 -0400 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=dad9910b0579400591798471540a158f Archived-At: Subject: [Extra] Congrats on the last two RFCs! X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 10:51:38 -0000 --dad9910b0579400591798471540a158f Content-Type: text/plain Wow, look at us :) EXTRA is delivering tons of great work! Congrats Stephan and Ken. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --dad9910b0579400591798471540a158f Content-Type: text/html
Wow, look at us :)  EXTRA is delivering tons of great work!  Congrats Stephan and Ken.

Cheers,

Bron.

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


--dad9910b0579400591798471540a158f-- From nobody Mon May 13 19:22:45 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 86CDA1201B7; Mon, 13 May 2019 19:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 NK2b6NYH6O2k; Mon, 13 May 2019 19:22:41 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 8096E12006D; Mon, 13 May 2019 19:22:41 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id q21so8543077iog.13; Mon, 13 May 2019 19:22:41 -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:content-transfer-encoding; bh=eL2118ge2fK+8MLncgyghGI0m9xTwF/GEmGhNBck7kI=; b=VwK/IkVkUd3lR3lIQNtwBGv7ok/GjUmi/XQINbOv9Y9ln/dxYafurGZloRkCOG3auD qAhk6dWO2Eu6C9x8/BIPcz1D3araslRJKVcsn3Dz9uOBPS4IbNLeXSa6VCRaIHXhIaRD AQvoZ4xzgePXLOOdgR7OsV2gIpLIFixXJ6Vy0PA6hUM3yIZUZwJyzPcaawYsak2cuBbM wkSsOd4OidDZ6OIu8W+GpERo/zmKNxya1qRNRK9xgKhw51f9e17bj76T3zYs0ZQJK+Q7 ZvYhTBAcvVTNdtL8FvgsAnvf2+wWsMZ4gR0vY7ukXcfVP7e8/KlFoC5FZqWvjveUYTUb SgUA== X-Gm-Message-State: APjAAAU5Q0ALmKb46F1KbHGmNMNs0G7tvJvSBOXwyRj2EcxSMU2RLWmW AtUXlsWZyYgk0GdTb/pHYbVxm/nBq/3Pl6OlK99mDSks X-Google-Smtp-Source: APXvYqw4Sp7gDbbjaYpeQ0bw7IobOWLlM+k4B0GVfUWwVxbsj/MiO9ZPnW1zNUnN83HRmlurtsE+kf6/sGzzPOQykBQ= X-Received: by 2002:a5d:8357:: with SMTP id q23mr18154945ior.10.1557800560381; Mon, 13 May 2019 19:22:40 -0700 (PDT) MIME-Version: 1.0 References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> In-Reply-To: <1478535427.18024.1554953503900@appsuite.open-xchange.com> From: Barry Leiba Date: Mon, 13 May 2019 22:22:29 -0400 Message-ID: To: Michael Slusarz Cc: The IESG , extra@ietf.org, Bron Gondwana , draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Tue, 14 May 2019 02:22:43 -0000 Hi, Michael, I'm sorry it took me so long to get back to this, and I won't let that happen again. > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > =E2=80=94 Section 3.1 =E2=80=94 > > > > I don=E2=80=99t understand =E2=80=9Cthe client=E2=80=99s priority decis= ion=E2=80=9D: what decision is that? > > And what=E2=80=99s the point of giving the server a list of algorithms = here, given that > > they all have to be ones that are supported by the server? Won=E2=80= =99t the server > > always have to use the first one in the list? If not, please add some = text > > explaining what the server does. > > Consensus seems to be this section is confusing, or unclear, or unneeded,= or some combination of this three. But it's still there and still unexplained in version -05. Let's see where we can go with it: > 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=3DIMAGE 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? 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. > I find that use-case plausible, albeit not something useful given the > current landscape of a single algorithm. The alternative would be to > have to send PREVIEW algorithms one at a time, non-pipelined, which is > precisely the kind of inefficient client/server interaction this > extension is trying to minimize. We disagree on the plausibility. Realistically, I can't think of *any* other plausible preview algorithms that a *client* might ask for without user interaction. The most I can see is something about how to apply FUZZY to non-text media types. > I do agree that there is language that can surely be cleaned up here, > especially regarding error handling. But I will hold off on rewriting > the section until we can have some discussion/consensus as to whether > the proposed usage discussed above is something that others believe we > should be supporting. *If* we're going to keep the multi-algorithm syntax, I think the new paragraph you added has it covered, and the paragraph with the phrase "priority decision" is now unnecessary. But I'd still like to see someone give a good argument for a case where having a client ask for multiple algorithms to be applied could really be useful and practical. > > =E2=80=94 Section 3.2 =E2=80=94 > > > > If the preview is not available, the server MUST return NIL as the > > PREVIEW response. A NIL response indicates to the client that > > preview information MAY become available in a future PREVIEW FETCH > > request. Note that this is semantically different than returning a > > zero-length string, which indicates an empty preview. > > > > I think the MUST here is hard to follow, because the text doesn=E2=80= =99t make a clear > > enough distinction between =E2=80=9Cpreview is not available=E2=80=9D a= nd =E2=80=9Can empty preview=E2=80=9D. > > Can you expand the text a bit to explain the distinction more clearly, = as this > > is a protocol requirement? > > "Preview not available" examples =3D > * Preview generation isn't available at the moment (previews are genera= ted in a separate thread, and that pool is saturated) > * Body text is not available at the moment, so preview can't be generat= ed. > * The preview text has not been generated within the alotted time (e.g.= LAZY modifier) OK, so you're saying that NIL means that there's some transient issue, and that a non-empty preview might be available later... and an empty string means that there's no preview text available for this message and never will be. Yes? If that's right (and actually a necessary distinction), I suggest this: OLD If the preview is not available, the server MUST return NIL as the PREVIEW response. A NIL response indicates to the client that preview information MAY become available in a future PREVIEW FETCH request. Examples why a preview may not be available include: the preview generation process is not available due to transient server resource limitations, the message body text is unavailable, or a server- imposed timeout was reached during generation. A NIL response is semantically different than returning a zero-length string, which indicates that no meaningful preview text can be generated for the message. NEW It is possible that preview text is not available now, but might be available later -- perhaps the server's preview-generating resources are overloaded, there is a server-imposed timeout during preview generation, or there is some transient issue with fetching the message body. In such cases, the server will return NIL as the preview response, and the client might possibly try again later. On the other hand, it's possible that the server has determined that no meaningful preview text can be generated for a particular message, and that won't change later. Examples of this involve encrypted messages, content types the server does not support previews of, and other situations where the server is not able to extract information for a preview. In such cases, the server will return a zero-length string. Clients should not send another FETCH for a preview for such messages. END But let's be sure we really think the distinction is important. > > =E2=80=94 Section 8 =E2=80=94 > > > > It seems like a bad idea to have to keep the IMAP Capabilities registry= in sync > > with the two new registries: as it stands, when you add a new algorithm= you > > have to add it to the Preview Algorithms registry, and also add a corre= sponding > > entry in the Capabilities registry... and similarly for a modifier, if = I have > > that right above. > > > > Why not follow the model of AUTH=3D and RIGHTS=3D, and just reserve the= PREVIEW=3D > > capability in the registry, allowing it to apply to entries from the tw= o new > > registries? That avoids inconsistencies in registrations if we later a= dd > > algorithms or modifiers. > > See above. With my proposal to remove priority modifiers, I believe this= discussion > point becomes moot. It does not; it's still an issue with algorithms. If you register "PREVIEW=3DFUZZY" as a capability string and also register "FUZZY" as an algorithm, you're doing double registration and are prone to getting inconsistencies. But if, instead, you just register "PREVIEW=3D" as a capability string and let that stand for any "PREVIEW=3DX", where X is a registered preview algorithm, you don't get into that sort of trouble. That's what AUTH=3D and RIGHTS=3D did. Is there a reason not to do that? > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > =E2=80=94 Section 3.2 =E2=80=94 > > > > This relaxed requirement permits a > > server to offer previews as an option without requiring potentially > > burdensome storage and/or processing requirements to guarantee > > immutability for a use case that does not require this strictness. > > > > That=E2=80=99s sensible, but can you include some text giving an exampl= e of a situation > > where the preview might change? Given that the messages themselves are > > immutable, why would applying the same algorithm to the same text give > > different results? > > We discussed this on the list in the past, but one example would be > loss of cached preview data on the server and re-generation uses a > newer algorithm version which produces slightly different text. > > The consensus was that we should not be making extraordinary > efforts/costs to ensure this text never changes, where this text is not > being held out as being the canonical view of the message contents in > the first place. That's fine. So, as the first sentence of my comment says, can you include some text to explain the situation? I'm not looking for a lot, just a sentence. (If you think it's best not to, that's OK too: this is a comment, not a discuss point). Again, sorry for the delay in responding, and I'll keep up with the discussion from here. Barry From nobody Thu May 30 01:33:16 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 E1170120096 for ; Thu, 30 May 2019 01:33:14 -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=T225j+H+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=5tPER4/O 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 0oXl9ioOZG_x for ; Thu, 30 May 2019 01:33:11 -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 8E5B112004F for ; Thu, 30 May 2019 01:33:11 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 48FDC22221 for ; Thu, 30 May 2019 04:33:10 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 30 May 2019 04:33:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=xxyFiZjVI5Kb4qGK7c+7xS8iDkk47F8GdIJD+Zz ygZ0=; b=T225j+H+veYY2BLSBC0kMgCcrxsqY8iR8Avww1OmwYoo8qtw22Ql42g onqKDp0zQdrzYzgx8ESIglWY59ddUDWv/ixrUHIOYD4S/oACjPPJOU5p+o1yPvx+ JzcaycgEr/3lbovbeNHcP8clj6yPUQwdj3LTZxMc9nD0BGwwwnN3yJHisgPQlrv/ 83q6hapGynFn8tYM1hD3nkg0Bga2KmR6ykzNk0ZAcswzRhcVOujf6+6nlslwSAFX Xi/YaIaXR6ODWU1Dt3YbR4WfbxPzm1vTFHX3JY8l9Kar2kJqO29osJJkrHB+uMPL 3wmMkggFzvWgFkBH8g3KuzcmLe2ANSw== 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=xxyFiZjVI5Kb4qGK7c+7xS8iDkk47 F8GdIJD+ZzygZ0=; b=5tPER4/Ob2T56OZedPzLdojMqpsgxmBxNoqPx0PpFiXw/ /0o21E4TkuWL6SF6QMk/wweBrEWme25EdChydgr2OuHwfczAQJzEHOvjayjsf4G0 5E4IAvPCDuXX0Ggy4/cXNi1/tNWLNO2+vuYFsJYIhGAevid60fEMkFZWWnJOUuy+ cnln9BdHN1E80uGIK7EGU2BFtg+8n11fGvdLzywV0pgWQ3nRJ74VhoV4H8W3FGtC xV3MT144IxJQanSw6VbSK9JyKB0IrHsHTIsizvW+hrG3fF1i1wJ5IsKfxZZa3kl/ iiLkVVK/JFpxITcZlFf+Zzlb1g3bfWOPfF5uD1WXw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvledgtdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsghroh hnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E4D75180091; Thu, 30 May 2019 04:33:09 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-555-g49357e1-fmstable-20190528v2 Mime-Version: 1.0 Message-Id: <5fc290fd-65f9-4183-8a96-5937914a2290@www.fastmail.com> Date: Thu, 30 May 2019 18:32:43 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=871b29621ba14286850d0a8d16eb776e Archived-At: Subject: [Extra] Should we skip meeting in Montreal? 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, 30 May 2019 08:33:15 -0000 --871b29621ba14286850d0a8d16eb776e Content-Type: text/plain Both Yiankang and I are uncertain whether we will be able to make it to IETF105 in Montreal. Given that the main work item is IMAP4rev2 and the list of outstanding work to do is quite self contained, shall we skip this one? Alexey and Barry - given that you're the lead authors on our main open work item, it's probably your call whether you want to have a meeting. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --871b29621ba14286850d0a8d16eb776e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Both Yiankang and I are uncertain whether we will be able = to make it to IETF105 in Montreal.  Given that the main work item i= s IMAP4rev2 and the list of outstanding work to do is quite self contain= ed, shall we skip this one?
<= br>
Alexey and Barry - given that= you're the lead authors on our main open work item, it's probably your = call whether you want to have a meeting.

Cheers,

Bron.

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


--871b29621ba14286850d0a8d16eb776e--