From nobody Wed Sep 5 00:11:37 2018 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 79036130E04 for ; Wed, 5 Sep 2018 00:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 auOjJs719EFD for ; Wed, 5 Sep 2018 00:11:33 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA94128CB7 for ; Wed, 5 Sep 2018 00:11:31 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZIPyegY9bX08UAA--.13092S2; Wed, 05 Sep 2018 15:11:26 +0800 (CST) Date: Wed, 5 Sep 2018 15:11:20 +0800 From: "Jiankang Yao" To: extra Reply-To: yaojk X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201809051510363082103@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart201075256172_=----" X-CM-TRANSID: AQAAf0AZIPyegY9bX08UAA--.13092S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Aw1rAw17Cw1kAr4rZFW5KFg_yoW8Zr47pF 43Xry3Krn5Xw18G3yxGr18Zw15A345XFW5AFnxGry8C3yUAa4DXr18t3yrAa47Jr9xJFsr Ar109w1UWw15X3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Kb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAqx4xG6I8vx48I62xC7I0kMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67 AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAx ZF0Ew4CEw7xC0wCY02Avz4vE14v_GF4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7 v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF 1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIx AIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0D MIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4 xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU2GYLDUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: [Extra] Fw: I-D Action: draft-ietf-extra-sieve-fcc-04.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 07:11:36 -0000 This is a multi-part message in MIME format. ------=_001_NextPart201075256172_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkdlbnRsZSByZW1pbmRlci4NClRoaXMgZHJhZnQgd2lsbCBiZSBpbiBXRyBs YXN0IGNhbGwgZm9yIDMgd2Vla3MsIHdoaWNoIGVuZHMgaW4gMjYgU2VwdGVtYmVyLg0KQW55IGNv bW1lbnRzIGFyZSB3ZWxjb21lLg0KVGhhbmtzIGEgbG90Lg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KSmlhbmthbmcgWWFvDQoNCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzDQoNCkRh dGU6IDIwMTgtMDgtMTIgMjI6MDUNCg0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KDQpDQzog ZXh0cmENCg0KU3ViamVjdDogW0V4dHJhXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWV4dHJhLXNp ZXZlLWZjYy0wNC50eHQNCg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRW1haWwgbWFpbHN0b3JlIGFuZCBlWHRlbnNpb25zIFRv IFJldmlzZSBvciBBbWVuZCBXRyBvZiB0aGUgSUVURi4NCg0KDQoNCiAgICAgICAgVGl0bGUgICAg ICAgICAgIDogU2lldmUgRXh0ZW5zaW9uOiBGaWxlIENhcmJvbiBDb3B5IChGY2MpDQoNCiAgICAg ICAgQXV0aG9ycyAgICAgICAgIDogS2VubmV0aCBNdXJjaGlzb24NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBCcm9uIEdvbmR3YW5hDQoNCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt ZXh0cmEtc2lldmUtZmNjLTA0LnR4dA0KDQpQYWdlcyAgICAgICAgICAgOiAxMw0KDQpEYXRlICAg ICAgICAgICAgOiAyMDE4LTA4LTEyDQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgVGhlIFNpZXZlIEVt YWlsIEZpbHRlcmluZyBMYW5ndWFnZSBwcm92aWRlcyBhIG51bWJlciBvZiBhY3Rpb24NCg0KICAg Y29tbWFuZHMsIHNvbWUgb2Ygd2hpY2ggY2FuIGdlbmVyYXRlIGFkZGl0aW9uYWwgbWVzc2FnZXMg b24gYmVoYWxmIG9mDQoNCiAgIHRoZSB1c2VyLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGV4 dGVuc2lvbiB0byBzdWNoIGNvbW1hbmRzIHRvDQoNCiAgIGFsbG93IGEgY29weSBvZiBhbnkgZ2Vu ZXJhdGVkIG1lc3NhZ2UgdG8gYmUgZmlsZWQgaW50byBhIHRhcmdldA0KDQogICBtYWlsYm94Lg0K DQoNCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0 IGlzOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWV4dHJh LXNpZXZlLWZjYy8NCg0KDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWls YWJsZSBhdDoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZXh0cmEt c2lldmUtZmNjLTA0DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1leHRyYS1zaWV2ZS1mY2MtMDQNCg0KDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtZXh0cmEtc2lldmUtZmNjLTA0DQoNCg0KDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQoNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KDQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KRXh0cmEgbWFpbGluZyBsaXN0DQoNCkV4dHJhQGlldGYub3JnDQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZXh0cmENCg0KDQoNCi0tDQoNCiAg QnJvbiBHb25kd2FuYSwgQ0VPLCBGYXN0TWFpbCBQdHkgTHRkDQoNCiAgYnJvbmdAZmFzdG1haWx0 ZWFtLmNvbQ== ------=_001_NextPart201075256172_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Dear all,
 
Gentle reminder.
This draft will be in WG last call=  for 3 weeks, which ends in 26=20 September.
Any comments are welcome.
Thanks a lot.
 
 
 
---------------------------------------------------------------------= -----------
 
Jiankang Yao

 
From: internet-drafts
Date: 2018-08-12 22:05
To: i-d-announce@ietf.org
CC: extra
Subject: [Extra] I-D Action:=20 draft-ietf-extra-sieve-fcc-04.txt

 
A New Internet-Draft is available from&nbs= p;the on-line Internet-Drafts directories.
This draft is a work item of the=  Email mailstore and eXtensions To Revise&nb= sp;or Amend WG of the IETF.

 
        Title  &n= bsp;        : Sieve Exte= nsion: File Carbon Copy (Fcc)
        Authors  =        : Kenneth Murchison
           &= nbsp;           &nb= sp;  Bron Gondwana
Filename        : draf= t-ietf-extra-sieve-fcc-04.txt
Pages          &n= bsp;: 13
Date          &nb= sp; : 2018-08-12

 
Abstract:
   The Sieve Email Filtering Lan= guage provides a number of action
   commands, some of which can&n= bsp;generate additional messages on behalf of
=
   the user.  This document = ;defines an extension to such commands to
   allow a copy of any gene= rated message to be filed into a target=
   mailbox.

 

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

 
There are also htmlized versions available=  at:
https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-04
https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-04=

 
A diff from the previous version is&n= bsp;available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-sieve-fcc-04

 

 
Please note that it may take a c= ouple of minutes from the time of submi= ssion
until the htmlized version and diff a= re available at tools.ietf.org.

 
Internet-Drafts are also available by anon= ymous 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

------=_001_NextPart201075256172_=------ From nobody Wed Sep 5 08:40:08 2018 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 09A3C1252B7; Wed, 5 Sep 2018 08:40:07 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153616200699.19753.13957702160049989504@ietfa.amsl.com> Date: Wed, 05 Sep 2018 08:40:07 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-03.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 15:40:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Sieve Email Filtering: Delivering to Special-Use Mailboxes Author : Stephan Bosch Filename : draft-ietf-extra-sieve-special-use-03.txt Pages : 9 Date : 2018-09-05 Abstract: 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 an anonymous mailbox that has a particular special-use attribute assigned. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-03 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-use-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-special-use-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 5 08:47:04 2018 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 2738E130E3C for ; Wed, 5 Sep 2018 08:47:02 -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 iKo4xCskwM2H for ; Wed, 5 Sep 2018 08:47:00 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAF7130DF4 for ; Wed, 5 Sep 2018 08:47:00 -0700 (PDT) Received: from [10.168.3.2] (unknown [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 70FE82AEF59 for ; Wed, 5 Sep 2018 18:46:47 +0300 (EEST) To: extra@ietf.org References: <153616200699.19753.13957702160049989504@ietfa.amsl.com> From: Stephan Bosch Message-ID: <69488269-7acb-761a-2370-c25f55cac652@dovecot.fi> Date: Wed, 5 Sep 2018 17:45:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153616200699.19753.13957702160049989504@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-03.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 15:47:02 -0000 Hi, Since the last revision was about to expire, I submitted a new draft for the Sieve special-use extension. It includes the following changes (from Git): - Always use the default mailbox to break a fileinto special-use mailbox ambiguity if it is part of the options. - Change the MUST for graceful handling of fileinto special-use mailbox ambiguity into a SHOULD. - Clarify that fileinto may also implicitly create the mailbox without ":create". I am still waiting for Ned to review my IMAP example changes. That is currently the only TODO item for this draft. Regards, Stephan Op 05/09/2018 om 17:40 schreef internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. > > Title : Sieve Email Filtering: Delivering to Special-Use Mailboxes > Author : Stephan Bosch > Filename : draft-ietf-extra-sieve-special-use-03.txt > Pages : 9 > Date : 2018-09-05 > > Abstract: > 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 an anonymous mailbox that has a > particular special-use attribute assigned. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-03 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-use-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-special-use-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Thu Sep 6 10:19:03 2018 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 7EC14130EDC for ; Thu, 6 Sep 2018 10:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYXCnrg36qPS for ; Thu, 6 Sep 2018 10:19:00 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (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 620C51277C8 for ; Thu, 6 Sep 2018 10:19:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QWYCOP8LKW00428O@mauve.mrochek.com> for extra@ietf.org; Thu, 6 Sep 2018 10:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1536254036; bh=Om0pinYP9ry5cO1ZR5tWFxQ+Qgbcv+ovRYuNjHm9yns=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=dlG1vcIbMnIZDjfaH4jvNtPjwbPtS3fUEdcrEjd8HoMHyVEgaUk8jwilIpZHynZm3 lwoLU6d5qLLOLUbwwztiEwiEQj3pUIj4XSBsKqH3yw5GdwJQUWM93Gj/FPRftL2IDn 3GSx/d1DZ/+VLMHXA81z2nC+mYLDpCfx9fTCXJoI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QWGA6AREZ400004T@mauve.mrochek.com>; Thu, 6 Sep 2018 10:13:53 -0700 (PDT) Cc: Ned Freed , Bron Gondwana , extra@ietf.org Message-id: <01QWYCONJRJM00004T@mauve.mrochek.com> Date: Thu, 06 Sep 2018 07:09:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 03 Aug 2018 11:08:16 -0400" References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> <01QTIJ66FRSK000051@mauve.mrochek.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] sieve-fcc next steps 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, 06 Sep 2018 17:19:02 -0000 I finally got a chance to take a look at the latest version, and I have a few remaining comments. The introduction says: It is sometimes desirable to have an archive of the messages generated by these commands. This is a bit nonspecific and therefore confusing. I suggest changing it to say something like: It is sometimes desirable for a Sieve user to maintain an archive of the messages generated by these commands. The document contains the following example illustrating the use of the "fcc" notification capability: if notify_method_capability "xmpp:" "Fcc" "yes" { ... Although this check makes logical sense, it exposes an issue with the underlying semantics of both notify_method_capability and valid_notify_method in regards to the notification-uri and notification-uris parameters, respectively. I'll first note that while "xmpp:" is a syntactically valid URL according to RFC 5122 and makes sense in an "fcc" capability check, it does not make sense in an "online" capability check - for that the URL needs to include the user whose online status is being checked. Additionally, according to RFC 5435 section 4, the valid_notify_method test: MUST perform exactly the same validation as would be performed on the "method" parameter to the "notify" action. And while the validation requirements aren't explicitly specified anywhere AFAICT, in our implementation at least the :method URL has to specified a recipient for the notification. And in fact RFC 5435 section 3.2 actually gives "XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI]" as an example, as opposed to just saying "XMPP" URL. And mailto: URLs have exactly the same issues: "mailto:" is syntactially valid but makes no sense in an online capability check or as a :method parameter value. RFC 5436 doesn't come out and say a recipient has to be specified, but section 2.1 and the second bullet point of section 2.7 kind of assume it. The situation is further complicated by the example in RFC 5435 section 4: if not valid_notify_method ["mailto:", "http://gw.example.net/notify?test"] { stop; } Since "mailto:" lacks a recipient it's not a valid URL to specify in a :method parameter to enotify, and so in our implementation at least it causes the test to fail. (Note that the RFC doesn't actually say what the results of this test are supposed to be, but I would assume it was expected to succeed.) As to what to do about all this, I'm not sure. As far as the current draft is concerned it probably suffices to add a sentence saying that the URL doesn't need to specify a recipient or anything else for the "fcc" capability check. But does nothing to address the underlying issues. Moving on... I was thinking that it would be good to note that the corresponding extension must be enabled in order to use :flags, :create, and/or :specialuse with :fcc, but repeating that in each section seems tedious. How about putting a note to this effect after the example in section 3.5.4? In regards to section 4 and our implementtion, you could say something like: 4.2 Oracle Communications Messaging Server The Oracle's Messaging Server product supports the :fcc extension in conjunction with both the notify and vacation extensions. The implementation meets all the requirements given in this document. The product also supports the imap4flags extension so the :flags may be used in conjunction :fcc. That's it for now. Ned From nobody Thu Sep 6 17:14:51 2018 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 DC00C130F76; Thu, 6 Sep 2018 17:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV2sD0EYkDkx; Thu, 6 Sep 2018 17:14:33 -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 C6C45130FBD; Thu, 6 Sep 2018 17:14:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AB894B8152B; Thu, 6 Sep 2018 17:14:32 -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: <20180907001432.AB894B8152B@rfc-editor.org> Date: Thu, 6 Sep 2018 17:14:32 -0700 (PDT) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8457_on_IMAP_=22=24Important=22_Keyword_an?= =?utf-8?q?d_=22=5CImportant=22_Special-Use_Attribute?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 00:14:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8457 Title: IMAP "$Important" Keyword and "Important" Special-Use Attribute Author: B. Leiba, Ed. Status: Standards Track Stream: IETF Date: September 2018 Mailbox: barryleiba@computer.org Pages: 11 Characters: 22542 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-extra-specialuse-important-04.txt URL: https://www.rfc-editor.org/info/rfc8457 DOI: 10.17487/RFC8457 RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute, "Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788. 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 Mon Sep 10 17:20:40 2018 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 B0502131004; Mon, 10 Sep 2018 17:20:37 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153662523769.16137.7151778749740462039@ietfa.amsl.com> Date: Mon, 10 Sep 2018 17:20:37 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-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, 11 Sep 2018 00:20:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Sieve Extension: File Carbon Copy (Fcc) Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-sieve-fcc-05.txt Pages : 13 Date : 2018-09-10 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-05 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-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 Sep 16 04:09:13 2018 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 4BAF0130DD6; Sun, 16 Sep 2018 04:09:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153709615123.17047.10188760959650702068.idtracker@ietfa.amsl.com> Date: Sun, 16 Sep 2018 04:09:11 -0700 Archived-At: Subject: [Extra] extra - New Meeting Session Request for IETF 103 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: Sun, 16 Sep 2018 11:09:11 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the extra working group. --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dispatch dcrup doh uta dmarc Second Priority: oauth tls calext People who must be present: Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field Special Requests: --------------------------------------------------------- From nobody Sun Sep 16 04:10:16 2018 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 27A11130DD2; Sun, 16 Sep 2018 04:10:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153709621515.16995.2996644968900165833.idtracker@ietfa.amsl.com> Date: Sun, 16 Sep 2018 04:10:15 -0700 Archived-At: Subject: [Extra] extra - Update to a Meeting Session Request for IETF 103 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: Sun, 16 Sep 2018 11:10:15 -0000 An update to a meeting session request has just been submitted by Bron Gondwana, a Chair of the extra working group. --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dispatch dcrup doh uta dmarc Second Priority: oauth tls calext People who must be present: Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Special Requests: One chair is not available on Monday, so please schedule later in the week. It would be quite good to hold this meeting combined with JMAP, since many of the same people attend both. --------------------------------------------------------- From nobody Sun Sep 16 04:14:24 2018 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 D9D4D130DD2; Sun, 16 Sep 2018 04:14:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153709646285.16875.6242480897816325732.idtracker@ietfa.amsl.com> Date: Sun, 16 Sep 2018 04:14:22 -0700 Archived-At: Subject: [Extra] extra - Update to a Meeting Session Request for IETF 103 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: Sun, 16 Sep 2018 11:14:23 -0000 An update to a meeting session request has just been submitted by Bron Gondwana, a Chair of the extra working group. --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dispatch dcrup doh uta dmarc Second Priority: oauth tls calext People who must be present: Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Special Requests: One chair is not available on Monday. Please schedule later in the week. It would be good to hold this meeting directly before/after JMAP, since many people attend both. --------------------------------------------------------- From nobody Sun Sep 16 04:16:21 2018 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 4141C130DD2 for ; Sun, 16 Sep 2018 04:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=SSSuLWRr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oIrp2Xtt 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 OYSl9SRjWoqA for ; Sun, 16 Sep 2018 04:16:18 -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 D2C1C130E13 for ; Sun, 16 Sep 2018 04:16:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 32D4721E33 for ; Sun, 16 Sep 2018 07:16:17 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Sun, 16 Sep 2018 07:16:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=MeTru7N1CgQkOWTuV 6nzSaLYHcJGQbDJbgPaPhbX/vA=; b=SSSuLWRr7ZrLw+pd7zH+GSbDtOv98nFn8 7MMbAWG4ULdgEep/Uj5Stzb09hoZxpcqTbcrRulxUsEiD0kH/gaEn1CbxU/+29Fw 27d/xJEs6as8kXGedxhOSx4NPHKnxLJmTWkUzehbVzfIhtG81mQXtHQe+tq5t+2Z 8zt/ZqhSjXlex1x1WKySKIAUE9wnULHOmp8mA+AyQr4ATe1abZ96MLjYj64zheWS xmSzBe9XEddGoy80VHxfUHZhtRAdQwJlR857PzR1b69z3XGhR42gFv+rSAUC11WX mFC0sT7rNYhiCnKuu9zjD4jy1a/Rm2Ofa/Y/AEXV6dQbs5qB3kPfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=MeTru7N1CgQkOW TuV6nzSaLYHcJGQbDJbgPaPhbX/vA=; b=oIrp2XttzoryQflghh4dAXzdumGVfc I92QkAaaXPKd+l+i7tCUTW7QYXTs/6y5z3IbLBkpocddv22Pso8LmNXowqmigxvo GGo0YWPw7n2izf4CuvY6vDPRhtl+VOVHGxmijuHkVXyC1fXZyaP6j3hNGWGbRu0Q JI7ESZSBqf/eb5MYJN/FHibkAhfCemcbcKN7pwlxeropt36gra3/9Jov9VIsl3T1 Byl1Unxr9NtiTN/QtTFvZjYSLPj8rj9zNuOVSDjzaO/90Ia/VLKis2JN/TNLIH0v SFynTGdG0cA6bARQEm5elVyozHpTUBBG/Qt3ppUh5dWqIKz4WlDr8LbQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 73CBBE7A5; Sun, 16 Sep 2018 07:16:16 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.5-486-gb761102-fmnext-20180914v1 x-jmap-identity-id: 56629417 Date: Sun, 16 Sep 2018 07:16:15 -0400 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=cc0a27b418cb4c0483a806a73e26dba3 Archived-At: Subject: [Extra] EXTRA session for IETF in Thailand 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, 16 Sep 2018 11:16:19 -0000 --cc0a27b418cb4c0483a806a73e26dba3 Content-Type: text/plain Hi All, I have just submitted the session request for IETF103. It turns out that I can leave Australia earlier than I thought, so I'll miss the hackathon and the first day, but I can arrive on Monday night. I've also asked that the meeting be scheduled close to JMAP, possibly in the same room and alongside, since so many people do both. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --cc0a27b418cb4c0483a806a73e26dba3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

I have just submitted the session r= equest for IETF103.  It turns out that I can leave Australia earlie= r than I thought, so I'll miss the hackathon and the first day, but I ca= n arrive on Monday night.
I've also asked that the meeting be scheduled close to JMAP, possibly i= n the same room and alongside, since so many people do both.

= Cheers,

Bron.

--
  Bron Gond= wana, CEO, FastMail Pty Ltd
  bro= ng@fastmailteam.com


--cc0a27b418cb4c0483a806a73e26dba3-- From nobody Mon Sep 17 04:36:45 2018 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 A53CC130E3D; Mon, 17 Sep 2018 04:36:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bron Gondwana To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: extra@ietf.org, brong@fastmailteam.com, Bron Gondwana , iesg-secretary@ietf.org, extra-chairs@ietf.org Message-ID: <153718420366.24741.16173875889199019115.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2018 04:36:43 -0700 Archived-At: Subject: [Extra] Publication has been requested for draft-ietf-extra-imap-replace-00 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, 17 Sep 2018 11:36:44 -0000 Bron Gondwana has requested publication of draft-ietf-extra-imap-replace-00 as Proposed Standard on behalf of the EXTRA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ From nobody Mon Sep 17 04:52:48 2018 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 9C4F1130E1B for ; Mon, 17 Sep 2018 04:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=B1A9wC0x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZZWeQ9BJ 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 ePH6AUXlTtJ6 for ; Mon, 17 Sep 2018 04:52:45 -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 0D4FF1271FF for ; Mon, 17 Sep 2018 04:52:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AED66212A0; Mon, 17 Sep 2018 07:52:43 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 17 Sep 2018 07:52:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=LWA5EbiD7NkNTn UR0BV+ZWT4zkafg3SkLZO53UUMK7g=; b=B1A9wC0xQBEzDDR2Fgt4MpHZb9qaGD FXXV5gwyfbGC2HkkSSOv0ipXUs2Tumy1IclQitNk5TVC2jnx+TOd6cxHXdfITaaG Zh7T4tUPiMdfaqnhqBpHIJu9XkG35XFgLGd8RvOiARDpW1+eY8brYdU8jBTivQTG cDuCFGzwnP4bO2P7Y63LkwuNOh6Hv6YEtIacRLLrgmIoB37kJ4pUD8F8X/uo5Pu+ 3+po/r1rmor/8QdklwliQmYvpozq1PEVCQo2Yi8JVP34oKg7cPpWdnSIo4O4QAp8 6ALygLKfNfs8VgBhv91t7eigwT89f/65XtHPtSmCf9FxwHV+c4OhnCog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=LWA5Eb iD7NkNTnUR0BV+ZWT4zkafg3SkLZO53UUMK7g=; b=ZZWeQ9BJHdfJWIzrE4xcOd JU3UH4wwPz0eYcxlGFrNAi1GyhSrySiE6N0S77PuilDYQL8J1Lo33Co+4DcnCS89 MOLLgIM37TEQ1hpwKCPSTlaO3KrpeSZeCstijQXF1TonfmOfFRbfeoHB0meY/QJl A9iBX4eeTbrCpPokq117BEisWdvOKdSUX9ZhnRPqrJ6Yzsjq+mrIv8EIHSRAtcah 7nfx0jLFMiVcv35rRK25RTefwh7XJga1uyJ/cjUIOXP697mcY0BAUyhUPAPwWkd1 D7R1AWFDJOsCqnoQcur8b+1c2jXU4WlItBRhMue5vmmqs/6MofORjEWh+DopSnyg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F0A3BE311; Mon, 17 Sep 2018 07:52:42 -0400 (EDT) Message-Id: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-497-g962c979-fmnext-20180917v5 x-jmap-identity-id: 56629417 Date: Mon, 17 Sep 2018 07:52:42 -0400 From: "Bron Gondwana" To: extra@ietf.org Cc: "Michael Slusarz" Content-Type: multipart/alternative; boundary=a6caac384d3742ca90aadbc1f7bbd2c9 Archived-At: Subject: [Extra] Discussing SNIPPET 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, 17 Sep 2018 11:52:47 -0000 --a6caac384d3742ca90aadbc1f7bbd2c9 Content-Type: text/plain Hi All, I've just posted REPLACE off for publication after the expiry of the WGLC period and confirming the IPR status. In terms of the remaining documents, we have a couple of Sieve docs which Jiankang is busy Shepherding through their last calls, we have 64bit which we allowed to lapse (for now) and we have imap4rev2 which is a giant piece of work. Finally, we have the recently adopted draft-ietf-extra-imap-fetch-snippet-00. To summarise the discussion: 1) there's nobody who thinks this is a bad idea 2) there's general agreement that specifying an exact algorithm is bad 3) while LAZY may or may not be that valuable, nobody minds it that much. Easy approach is to always generate regardless of the modifier. So much for the things everyone agreed on (please correct me if I missed anything!) Here's the issues under debate: a) Naming. The great difficulties, naming and cache invalidation! (and yep, we've got the second one too). Should it be called SNIPPET, or something else like PREVIEW? I'm asking largely because JMAP used "SearchSnippet" to refer to a fragment of matching text with terms hilighted. And JMAP used "preview" for the short piece of text (up to 256 characters) that represents the email content. b) Cache Invalidation. Ho hum. Is this an immutable property? If so, what happens if the server implementation changes? I'm quite happy to call it "softly immutable" myself - it might not be exactly the same bytes, but you can use the old version without major problems. c) Length: The server SHOULD limit the length of the snippet text to 100 characters. The server MUST NOT output snippet text longer than 200 characters. I would prefer to bring this up to more like 200 for should and 256 for MUST NOT. 100 is a pretty short preview on big screens. I'd also be willing to have a way for the client to hint for shorter previews to save network bandwidth, but have servers generally store 256 chars. The syntax makes it quite easy to add a MAXLEN=80 or whatever to the fetch command. And yes, this would be trivial to implement in our server with its existing previews, and I would totally do it during last call :) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --a6caac384d3742ca90aadbc1f7bbd2c9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

I've just posted REPLACE off for pu= blication after the expiry of the WGLC period and confirming the IPR sta= tus.

In terms of the remaining documents, we have a coupl= e of Sieve docs which Jiankang is busy Shepherding through their last ca= lls, we have 64bit which we allowed to lapse (for now) and we have imap4= rev2 which is a giant piece of work.

Finally, we have the recently adopted draft-ietf-extra-imap-= fetch-snippet-00.

To summarise the discussion:

1) there's nobody who thinks this is a bad idea
2) there's general agreement that specifying an exac= t algorithm is bad
3) while L= AZY may or may not be that valuable, nobody minds it that much.  Ea= sy approach is to always generate regardless of the modifier.
<= div style=3D"font-family:Arial;">
So much for the things everyone agreed on (please correct me if I m= issed anything!)  Here's the issues under debate:

a)= Naming.  The great difficulties, naming and cache invalidation! (a= nd yep, we've got the second one too).  Should it be called SNIPPET= , or something else like PREVIEW?  I'm asking largely because JMAP = used "SearchSnippet" to refer to a fragment of matching text with terms = hilighted.  And JMAP used "preview" for the short piece of text (up= to 256 characters) that represents the email content.

b)= Cache Invalidation.   Ho hum.  Is this an immutable prop= erty?  If so, what happens if the server implementation changes?&nb= sp; I'm quite happy to call it "softly immutable" myself - it might not = be exactly the same bytes, but you can use the old version without major= problems.

c) Length:  
   The server =
SHOULD limit the length of the snippet text to 100
   characters.  The server MUST NOT output snippet text longer than 200
   characters.

I would prefer to bring this up to more li= ke 200 for should and 256 for MUST NOT.  100 is a pretty short prev= iew on big screens.  I'd also be willing to have a way for the clie= nt to hint for shorter previews to save network bandwidth, but have serv= ers generally store 256 chars.  The syntax makes it quite easy to a= dd a MAXLEN=3D80 or whatever to the fetch command.

And yes= , this would be trivial to implement in our server with its existing pre= views, and I would totally do it during last call :)

Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com
<= br>

--a6caac384d3742ca90aadbc1f7bbd2c9-- From nobody Mon Sep 17 17:31:33 2018 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 786B8126BED for ; Mon, 17 Sep 2018 17:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 24RGSpiqO1bS for ; Mon, 17 Sep 2018 17:31:30 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 300D7130DFB for ; Mon, 17 Sep 2018 17:31:30 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8I0UGcn019375; Tue, 18 Sep 2018 00:31:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=IJgRQ4orFaBehVTVsvSWM/NTs73WLJVdl7RhaiBS4PM=; b=QCw8WRIYjzlr1x+W+QkYRpe6/Bj0ZY0djmoHZQ4qNa+ujd4TsYNoTNRvzp2EtokyT5Ia 7+5UmfmHk8HEJep86T7ct6JzR9Oho3MttYpCRglolHeTNkYRgXlZiV9hJWOFnyFw6l8N hb7MXfOGEJmtAoyOkQGD0KzMQCifQAUb5HVQ5XV1TuMM44OAjVM8g+LuT7u9m/lJAn9L GuUdauxLh9lrrXrjJiabkcdfEodQZdo2HjGvhCzxG0mcVfWazvFjQeBalHJ7/Ddu48R6 qmN2u3O5rWV2jwRtG9kJBmr5XB+xBFngniGDv7MsZoZ3UxUwSQsRhvVtcWXV1+uF2kgQ RQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2mgsgthd4u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Sep 2018 00:31:26 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w8I0VOca017556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Sep 2018 00:31:25 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w8I0VNUS023026; Tue, 18 Sep 2018 00:31:24 GMT Received: from [10.145.183.37] (/10.145.183.37) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Sep 2018 17:31:23 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org, "Michael Slusarz" Date: Mon, 17 Sep 2018 17:31:23 -0700 X-Mailer: MailMate (1.12r5523) Message-ID: <3E644603-F6E1-438E-841C-B4DE45DD8136@oracle.com> In-Reply-To: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> References: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9019 signatures=668708 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809180003 Archived-At: Subject: Re: [Extra] Discussing SNIPPET 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, 18 Sep 2018 00:31:33 -0000 On 17 Sep 2018, at 4:52, Bron Gondwana wrote: > Hi All, > > I've just posted REPLACE off for publication after the expiry of the = > WGLC period and confirming the IPR status. > > In terms of the remaining documents, we have a couple of Sieve docs = > which Jiankang is busy Shepherding through their last calls, we have = > 64bit which we allowed to lapse (for now) and we have imap4rev2 which = > is a giant piece of work. > Finally, we have the recently adopted = > draft-ietf-extra-imap-fetch-snippet-00. > > To summarise the discussion: > > 1) there's nobody who thinks this is a bad idea > 2) there's general agreement that specifying an exact algorithm is bad > 3) while LAZY may or may not be that valuable, nobody minds it that = > much. Easy approach is to always generate regardless of the modifier. +1. > So much for the things everyone agreed on (please correct me if I = > missed anything!) Here's the issues under debate: > > a) Naming. The great difficulties, naming and cache invalidation! (and = > yep, we've got the second one too). Should it be called SNIPPET, or = > something else like PREVIEW? I'm asking largely because JMAP used = > "SearchSnippet" to refer to a fragment of matching text with terms = > hilighted. And JMAP used "preview" for the short piece of text (up to = > 256 characters) that represents the email content. I strongly feel that JMAP and IMAP should use consistent terminology = when possible. Although the term 'snippet' is cute, the term 'preview' = is more technically accurate for the desired functionality, particularly = when producing a fuzzy preview for an image-only message (in which case = the dictionary definition of 'snippet' is not what's desired). So I have = a mild preference for changing SNIPPET to match JMAP terminology. > b) Cache Invalidation. Ho hum. Is this an immutable property? If so, = > what happens if the server implementation changes? I'm quite happy to = > call it "softly immutable" myself - it might not be exactly the same = > bytes, but you can use the old version without major problems. The 'softly immutable' option works for me. However, I'll propose an = alternative so we can contrast two reasonable options. We could add a = way to fetch a FUZZY algorithm identifier for a given folder. Something = like: C: A043 STATUS blurdybloop (FUZZYALG) S: * STATUS blurdybloop (FUZZYALG ("ocms:8.0")) A cached PREVIEW=3DFUZZY (SNIPPET=3DFUZZY) from that folder is immutable = unless the FUZZYALG string changes. This has some non-trivial server = implications, but if clients really need predictable PREVIEW caching = behavior, this is a protocol model I'd be willing to implement to = provide that. > c) Length: > The server SHOULD limit the length of the snippet text to 100 > characters. The server MUST NOT output snippet text longer than = > 200 > characters. > > I would prefer to bring this up to more like 200 for should and 256 = > for MUST NOT. 100 is a pretty short preview on big screens. I'd also = > be willing to have a way for the client to hint for shorter previews = > to save network bandwidth, but have servers generally store 256 chars. = > The syntax makes it quite easy to add a MAXLEN=3D80 or whatever to the = > fetch command. No opinions here. Also easy for me to implement, but only useful if = client implementers use it. - Chris > And yes, this would be trivial to implement in our server with its = > existing previews, and I would totally do it during last call :) > Bron. > > > -- = > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DBzf8nG-Anmd7ybQ= FCYQd_kA5QfrsUFDlskrm11eWwSY&s=3DHOeED7FM1BpaoYj0D522AM5_Ke2XpfLSYfjTUoqh= rPc&e=3D From nobody Tue Sep 18 00:47:26 2018 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 B9D9F130DED for ; Tue, 18 Sep 2018 00:47:24 -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 3f1txzJ98NIj for ; Tue, 18 Sep 2018 00:47:23 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E09130DDE for ; Tue, 18 Sep 2018 00:47:22 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 8E42A6A330; Tue, 18 Sep 2018 09:47:20 +0200 (CEST) Received: from meili (alcatraz.oxoe.int [192.168.32.3]) (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 323E83C1842; Tue, 18 Sep 2018 09:47:20 +0200 (CEST) Date: Tue, 18 Sep 2018 10:47:21 +0300 From: Josef 'Jeff' Sipek To: Chris Newman Cc: Bron Gondwana , extra@ietf.org, Michael Slusarz Message-ID: <20180918074720.GB1384@meili> References: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> <3E644603-F6E1-438E-841C-B4DE45DD8136@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E644603-F6E1-438E-841C-B4DE45DD8136@oracle.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Extra] Discussing SNIPPET 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, 18 Sep 2018 07:47:25 -0000 On Mon, Sep 17, 2018 at 17:31:23 -0700, Chris Newman wrote: > On 17 Sep 2018, at 4:52, Bron Gondwana wrote: ... > > b) Cache Invalidation. Ho hum. Is this an immutable property? If so, > > what happens if the server implementation changes? I'm quite happy to > > call it "softly immutable" myself - it might not be exactly the same > > bytes, but you can use the old version without major problems. > > The 'softly immutable' option works for me. However, I'll propose an > alternative so we can contrast two reasonable options. We could add a way to > fetch a FUZZY algorithm identifier for a given folder. Something like: > > C: A043 STATUS blurdybloop (FUZZYALG) > S: * STATUS blurdybloop (FUZZYALG ("ocms:8.0")) > > A cached PREVIEW=FUZZY (SNIPPET=FUZZY) from that folder is immutable unless > the FUZZYALG string changes. This has some non-trivial server implications, > but if clients really need predictable PREVIEW caching behavior, this is a > protocol model I'd be willing to implement to provide that. For what it's worth, in Dovecot we cache the generated snippet/preview along with a version number and take the 'softly immutable' approach. For example, an email with body of "foobar" would turn into "1foobar" in the cache file. When a client FETCHes it, we strip the version. We haven't had the need to up the version yet, but at least in theory it should provide us with a way to tweak the snippet algo and know which cached values are stale. I'm not fully caught up on the discussions here so maybe I'm missing something, but I was under the impression that the algo can be selected per *email* so wouldn't it really have to be a FETCH * FUZZYALG?. I don't quite understand what the above STATUS accomplishes; I guess it is something like a uidvalidity for snippets in a folder but I'm not convinced that it is worth it. If you want to have the latest snippet, just FETCH it. Jeff. -- mainframe, n.: An obsolete device still used by thousands of obsolete companies serving billions of obsolete customers and making huge obsolete profits for their obsolete shareholders. And this year's run twice as fast as last year's. From nobody Tue Sep 18 00:54:05 2018 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 0F44C130DDE for ; Tue, 18 Sep 2018 00:54:03 -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=I9pHmVqL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WzZ5WTcH 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 JJ7nkTjrLmiz for ; Tue, 18 Sep 2018 00:54:00 -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 A17D3127AC2 for ; Tue, 18 Sep 2018 00:54:00 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 9D75721E59; Tue, 18 Sep 2018 03:53:59 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 18 Sep 2018 03:53:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9XKzTX A/7z/kXyxjAEoSTiVWvngU/3xqFAgX7isPHkY=; b=I9pHmVqLgxEDyGeGTRD+eq CCeM2m/0x5ZQ294tDBbDyozFD5AE9kehIF+ECoIVw2MPuRscKxVLBBj6MajMwBVE u7Eqk01BqwRVkLkvc4keW/URFY+a1S9vPXQS8d0DgGmvdc/HT+yDO/7aPoyAwlPV KKqlqsGSUg5cc1sGE454QTyAp3GCKHaKtxFHHT/1ecGbAfqOMR8U22+23rkyiaTJ BoYDWRtt0E7FWzkufm1SOxkuG2GMBJ9WBYnOd/R7eajktVg4KXO/EDvOh7kOZs6B 5+eJ1iZfGkkx1XUUjIghCRSrj/Z1e5oWxIv7Gp18C5snVCVH9arL0boeEQs81ypQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9XKzTX A/7z/kXyxjAEoSTiVWvngU/3xqFAgX7isPHkY=; b=WzZ5WTcH4ZeBoMWG3gA4cd YI9d92YruX9NQQNoBl4KsDgPtNWIhMVlG7YQO9Mdze3DpyuoDRnmvfK6g3YbAG0S Nb6iP9tpZgP6pxdVSMfgZK5y0bGlQEgjMxtFGxa1lbOeRorwCVAzKCcqh0erUepU 2b3tLo/jDXm61FyfsYlqtdUAYc6CRqQQTOL0jx6X4IcnbU/zxf0iEH7QOHXqogsk UCeIBIdkZHCkRVG29pYV7K6Zec6ulyd7P1Mc0sPwcLoaJUOYk9SrzYpaO8v7dzmM v21GYl2a5JFn/whyofHUPShkFRxZLUQDKOf1n/dwrJAo+U+6GtMkHpytEn07TKUA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 944C1E2319; Tue, 18 Sep 2018 03:53:58 -0400 (EDT) Message-Id: <1537257238.2278116.1511804688.496B30F1@webmail.messagingengine.com> From: Bron Gondwana To: Josef Jeff Sipek , Chris Newman Cc: extra@ietf.org, Michael Slusarz MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153725723822781160" X-Mailer: MessagingEngine.com Webmail Interface - ajax-15b169d8 References: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> <3E644603-F6E1-438E-841C-B4DE45DD8136@oracle.com> <20180918074720.GB1384@meili> Date: Tue, 18 Sep 2018 17:53:58 +1000 In-Reply-To: <20180918074720.GB1384@meili> Archived-At: Subject: Re: [Extra] Discussing SNIPPET 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, 18 Sep 2018 07:54:03 -0000 This is a multi-part message in MIME format. --_----------=_153725723822781160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, Sep 18, 2018, at 17:47, Josef 'Jeff' Sipek wrote: > On Mon, Sep 17, 2018 at 17:31:23 -0700, Chris Newman wrote: >> On 17 Sep 2018, at 4:52, Bron Gondwana wrote: > ... >>> b) Cache Invalidation. Ho hum. Is this an immutable property? If so,>>> what happens if the server implementation changes? I'm quite >>> happy to>>> call it "softly immutable" myself - it might not be exactly the same>>> bytes, but you can use the old version without major problems. >> >> The 'softly immutable' option works for me. However, I'll propose an>> alternative so we can contrast two reasonable options. We could add >> a way to>> fetch a FUZZY algorithm identifier for a given folder. >> Something like:>> >> C: A043 STATUS blurdybloop (FUZZYALG) >> S: * STATUS blurdybloop (FUZZYALG ("ocms:8.0")) >> >> A cached PREVIEW=FUZZY (SNIPPET=FUZZY) from that folder is >> immutable unless>> the FUZZYALG string changes. This has some non-trivial server >> implications,>> but if clients really need predictable PREVIEW caching behavior, >> this is a>> protocol model I'd be willing to implement to provide that. > > For what it's worth, in Dovecot we cache the generated > snippet/preview along> with a version number and take the 'softly immutable' approach. For > example, an email with body of "foobar" would turn into > "1foobar" in the> cache file. When a client FETCHes it, we strip the version. We > haven't had> the need to up the version yet, but at least in theory it should > provide us> with a way to tweak the snippet algo and know which cached values > are stale. We do something similar at FastMail - we have a keyword (currently $X-ME-Annot- 2) which is a version number for the logic which generated the preview and a couple of other keywords like $HasAttachment by parsing the message content. > I'm not fully caught up on the discussions here so maybe I'm missing > something, but I was under the impression that the algo can be > selected per> **email** so wouldn't it really have to be a FETCH * FUZZYALG?. I > don't quite> understand what the above STATUS accomplishes; I guess it is > something like> a uidvalidity for snippets in a folder but I'm not convinced > that it is> worth it. If you want to have the latest snippet, just FETCH it. I agree with that! It's small enough that re-fetching isn't a big deal if you are worried that it might be old - and the cost in roundtrips to check the version first plus the added complexity isn't worth it. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153725723822781160 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, Sep 18, 2018, at 17:47, Josef 'Jeff' Sipek wrote:
On Mon, Sep 17, 2018 at 17:31:23 -0700, Chris Newman wrote:
On 17 Sep 2018, at 4:52, Bron Gondwana wrote:
...
b) Cache Invalidation. Ho hum. Is this an immutable property? If so,
what happens if the server implementation changes? I'm quite happy to
call it "softly immutable" myself - it might not be exactly the same
bytes, but you can use the old version without major problems.

The 'softly immutable' option works for me. However, I'll propose an
alternative so we can contrast two reasonable options. We could add a way to
fetch a FUZZY algorithm identifier for a given folder. Something like:

C: A043 STATUS blurdybloop (FUZZYALG)
S: * STATUS blurdybloop (FUZZYALG ("ocms:8.0"))

A cached PREVIEW=FUZZY (SNIPPET=FUZZY) from that folder is immutable unless
the FUZZYALG string changes. This has some non-trivial server implications,
but if clients really need predictable PREVIEW caching behavior, this is a
protocol model I'd be willing to implement to provide that.

For what it's worth, in Dovecot we cache the generated snippet/preview along
with a version number and take the 'softly immutable' approach.  For
example, an email with body of "foobar" would turn into "1foobar" in the
cache file.  When a client FETCHes it, we strip the version.  We haven't had
the need to up the version yet, but at least in theory it should provide us
with a way to tweak the snippet algo and know which cached values are stale.

We do something similar at FastMail - we have a keyword (currently $X-ME-Annot-2) which is a version number for the logic which generated the preview and a couple of other keywords like $HasAttachment by parsing the message content.

I'm not fully caught up on the discussions here so maybe I'm missing
something, but I was under the impression that the algo can be selected per
*email* so wouldn't it really have to be a FETCH * FUZZYALG?.  I don't quite
understand what the above STATUS accomplishes; I guess it is something like
a uidvalidity for snippets in a folder but I'm not convinced that it is
worth it.  If you want to have the latest snippet, just FETCH it.

I agree with that!  It's small enough that re-fetching isn't a big deal if you are worried that it might be old - and the cost in roundtrips to check the version first plus the added complexity isn't worth it.

Bron.

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


--_----------=_153725723822781160-- From nobody Wed Sep 19 11:46:35 2018 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 29641130E77; Wed, 19 Sep 2018 11:46:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-extra-imap-savedate@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org, shwethab@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153738279315.21432.7627304332491585454.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2018 11:46:33 -0700 Archived-At: Subject: [Extra] Warren Kumari's No Objection on draft-ietf-extra-imap-savedate-01: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 18:46:33 -0000 Warren Kumari has entered the following ballot position for draft-ietf-extra-imap-savedate-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Shwetha Bhandari for the OpsDir review - it is much appreciated. From nobody Thu Sep 20 17:03:15 2018 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 102D6130DC6 for ; Thu, 20 Sep 2018 17:03:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 LNdkfFtZgMe3 for ; Thu, 20 Sep 2018 17:03:11 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC9B124D68 for ; Thu, 20 Sep 2018 17:03:10 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 6E1266A29E; Fri, 21 Sep 2018 02:03:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1537488188; bh=73OzXv5yZc5Zvh9+qM2m8hLnE0+ptV+UwfjErZ5pLEc=; h=Date:From:To:In-Reply-To:References:Subject:From; b=KJtDo2KBgn8gcMTxhgcyDJBWemgEy/YGTaHgdW9Ag1hDYj5PHZ/OdZDZTH7uhR4A6 HV9EzDdPy+X0GDikiKv3DXEMMt1JEOBXHhcOGM0QyzPvxb4WV+WqAwjXCcO0F8f8Q8 3us6lUZ4/uVF53cFawCkXploQEaTF5poPHkj7l1bnO9zT24r8ridwMMqrbMifyDyzW mIkmi5jmUlZELVwtrclEpE+P63izxAHqIM5EaOGB1Hi4TLnyqWi2dFAr1agJIKEaJQ q62vkDEH2KbElmbTaSDqLdaDQ6NFBtICZLsYNZgE01miqt2+s1YGvCXJu+uR49esbt NNLjINoXUPusg== Received: from null (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 4D55B3C01CB; Fri, 21 Sep 2018 02:03:08 +0200 (CEST) Date: Thu, 20 Sep 2018 18:03:08 -0600 (MDT) From: Michael Slusarz To: Bron Gondwana , extra@ietf.org Message-ID: <1732679468.1800.1537488188251@appsuite.open-xchange.com> In-Reply-To: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> References: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1799_1714875867.1537488188242" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev15 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Discussing SNIPPET X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 00:03:14 -0000 ------=_Part_1799_1714875867.1537488188242 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > On September 17, 2018 at 5:52 AM Bron Gondwana wrote: > > a) Naming. The great difficulties, naming and cache invalidation! (and yep, we've got the second one too). Should it be called SNIPPET, or something else like PREVIEW? I'm asking largely because JMAP used "SearchSnippet" to refer to a fragment of matching text with terms hilighted. And JMAP used "preview" for the short piece of text (up to 256 characters) that represents the email content. > I don't have a personal attachment to SNIPPET (other than we already implemented with that terminology, but that's easily worked around by some internal aliasing). PREVIEW makes sense if we are looking to a future where additional algorithms would be developed. As Chris points out, if you have algorithms that return both text blobs and something like image data, preview makes more sense semantically than snippet. I have no objection if we wanted to change the label. > b) Cache Invalidation. Ho hum. Is this an immutable property? If so, what happens if the server implementation changes? I'm quite happy to call it "softly immutable" myself - it might not be exactly the same bytes, but you can use the old version without major problems. > I spent quite a bit of time formulating the logic behind this topic when drafting the spec. Reproduced here for convenience: ----- A server SHOULD strive to generate the same string for a given message for each request. However, since snippets are understood to be a representation of the message data and not a canonical view of its contents, a client MUST NOT assume that a message snippet is immutable for a given message. This relaxed requirement permits a server to offer snippets 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. ---- I would love to hear feedback what parts of this are weak or what parts need to be explained further. I was thinking less about the situation of a server invalidating its cache rather than the scenario where a server loses its cache. Demanding that server upgrades ensure that its algorithm stays exactly the same across versions, in order to rebuild exactly the preview data, is a burden I don't think is useful to enforce. No user is going to be confused if their preview text suddenly differs across mail sessions. Feedback so far doesn't seem to indicate this is too troubling of a design decision. As mentioned above, I welcome feedback on how this can be explained better in the document. > c) Length: > > The server SHOULD limit the length of the snippet text to 100 > characters. The server MUST NOT output snippet text longer than 200 > characters. > > > I would prefer to bring this up to more like 200 for should and 256 for MUST NOT. 100 is a pretty short preview on big screens. I'd also be willing to have a way for the client to hint for shorter previews to save network bandwidth, but have servers generally store 256 chars. The syntax makes it quite easy to add a MAXLEN=80 or whatever to the fetch command. > 100 characters was selected via an informal survey of several different clients, both mobile and desktop, and how they currently display preview-like information in their UI. It's probably a bit mobile-centric, since I had more of those applications available at the time. More important, that analysis was probably too English-centric. English is quite compact compared to many other languages, so it's probably a bad example to use when trying to determine ideal lengths (see, e.g., https://www.w3.org/International/articles/article-text-size). 200 characters seems just as arbitrary :) But arguing over 100 extra characters stored per message is probably not a fight worth pursuing. So I don't have a strong opinion on raising to 200 or max length as 256. Although 256 isn't all that special since we are talking UTF-8 characters, not bytes, so landing on a power of 2 doesn't seem that necessary (just say 250 characters?). MAXLEN seems like overkill though. If a server is buffering output, we're not going to save that many network packets if a client requests partial text, since the use-case of preview is only to load data for the mailbox viewport. And it adds more complexity on server side that doesn't seem to give us much benefit. If we really wanted some sort of maxlen, for consistency sake it probably makes more sense to implement as <> syntax anyway. michael ------=_Part_1799_1714875867.1537488188242 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On September 17, 2018 at 5:52 AM Bron Gondwana <brong@fastmailteam.com> wrote:

a) Naming.  The great difficulties, naming and cache invalidation! (and yep, we've got the second one too).  Should it be called SNIPPET, or something else like PREVIEW?  I'm asking largely because JMAP used "SearchSnippet" to refer to a fragment of matching text with terms hilighted.  And JMAP used "preview" for the short piece of text (up to 256 characters) that represents the email content.
I don't have a personal attachment to SNIPPET (other than we already implemented with that terminology, but that's easily worked around by some internal aliasing).

PREVIEW makes sense if we are looking to a future where additional algorithms would be developed.  As Chris points out, if you have algorithms that return both text blobs and something like image data, preview makes more sense semantically than snippet.

I have no objection if we wanted to change the label.

b) Cache Invalidation.   Ho hum.  Is this an immutable property?  If so, what happens if the server implementation changes?  I'm quite happy to call it "softly immutable" myself - it might not be exactly the same bytes, but you can use the old version without major problems.
I spent quite a bit of time formulating the logic behind this topic when drafting the spec. Reproduced here for convenience:

-----

A server SHOULD strive to generate the same string for a given message for each request. However, since snippets are understood to be a representation of the message data and not a canonical view of its contents, a client MUST NOT assume that a message snippet is immutable for a given message. This relaxed requirement permits a server to offer snippets 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.

----

I would love to hear feedback what parts of this are weak or what parts need to be explained further.

I was thinking less about the situation of a server invalidating its cache rather than the scenario where a server loses its cache.  Demanding that server upgrades ensure that its algorithm stays exactly the same across versions, in order to rebuild exactly the preview data, is a burden I don't think is useful to enforce.  No user is going to be confused if their preview text suddenly differs across mail sessions.

Feedback so far doesn't seem to indicate this is too troubling of a design decision.  As mentioned above, I welcome feedback on how this can be explained better in the document.

c) Length:  
   The server SHOULD limit the length of the snippet text to 100
   characters.  The server MUST NOT output snippet text longer than 200
   characters.

I would prefer to bring this up to more like 200 for should and 256 for MUST NOT.  100 is a pretty short preview on big screens.  I'd also be willing to have a way for the client to hint for shorter previews to save network bandwidth, but have servers generally store 256 chars.  The syntax makes it quite easy to add a MAXLEN=80 or whatever to the fetch command.
100 characters was selected via an informal survey of several different clients, both mobile and desktop, and how they currently display preview-like information in their UI.  It's probably a bit mobile-centric, since I had more of those applications available at the time.

More important, that analysis was probably too English-centric.  English is quite compact compared to many other languages, so it's probably a bad example to use when trying to determine ideal lengths (see, e.g., https://www.w3.org/International/articles/article-text-size).

200 characters seems just as arbitrary :)  But arguing over 100 extra characters stored per message is probably not a fight worth pursuing.  So I don't have a strong opinion on raising to 200 or max length as 256.  Although 256 isn't all that special since we are talking UTF-8 characters, not bytes, so landing on a power of 2 doesn't seem that necessary (just say 250 characters?).

MAXLEN seems like overkill though.  If a server is buffering output, we're not going to save that many network packets if a client requests partial text, since the use-case of preview is only to load data for the mailbox viewport.  And it adds more complexity on server side that doesn't seem to give us much benefit.

If we really wanted some sort of maxlen, for consistency sake it probably makes more sense to implement as <<partial>> syntax anyway.

michael
------=_Part_1799_1714875867.1537488188242-- From nobody Thu Sep 20 19:49:15 2018 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 B3AA3130EC1 for ; Thu, 20 Sep 2018 19:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAsdzN8gW3LV for ; Thu, 20 Sep 2018 19:49:04 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id BB740130E84 for ; Thu, 20 Sep 2018 19:48:59 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CZcecTXKRbmwoZAA--.17247S2; Fri, 21 Sep 2018 10:48:51 +0800 (CST) Date: Fri, 21 Sep 2018 10:48:49 +0800 From: "Jiankang Yao" To: extra Reply-To: yaojk References: <201809051510363082103@cnnic.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201809211047476520364@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart031024617341_=----" X-CM-TRANSID: AQAAf0CZcecTXKRbmwoZAA--.17247S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tr4xAF4fJF1UAFW5trW5Jrb_yoW8tr4DpF W3XryfKrn5Xr1kG3yxGr18Zw15A34fXFW5AFnxGry8A3yUAa4qqr18t3yFya47Jr9xJFsr Ar109w1jgw1Yq3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBjb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I2 6xC2a48xMc02F40ExcI2r2IE04Ijxs4lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2js IE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k0 4243AVAKzVAKj4xxMxkIecxEwVAFwVW8JwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7x kEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E 67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCw CI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E 3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64 xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jexRDUUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Extra] Fw: I-D Action: draft-ietf-extra-sieve-fcc X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 02:49:14 -0000 This is a multi-part message in MIME format. ------=_001_NextPart031024617341_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiAgIFdhaXRpbmcgZm9yIHlvdXIga2luZCByZXZpZXcvY29tbWVudHMgZm9yIHRo aXMgZG9jdW1lbnQuIFRoZSBsYXN0IGNhbGwgd2lsbCBlbmQgaW4gYSB3ZWVrLg0KDQpUaGFua3Mu DQoNCg0KDQoNCkppYW5rYW5nIFlhbw0KDQpGcm9tOiBKaWFua2FuZyBZYW8NCkRhdGU6IDIwMTgt MDktMDUgMTU6MTENClRvOiBleHRyYQ0KU3ViamVjdDogW0V4dHJhXSBGdzogSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1leHRyYS1zaWV2ZS1mY2MtMDQudHh0DQpEZWFyIGFsbCwNCg0KR2VudGxlIHJl bWluZGVyLg0KVGhpcyBkcmFmdCB3aWxsIGJlIGluIFdHIGxhc3QgY2FsbCBmb3IgMyB3ZWVrcywg d2hpY2ggZW5kcyBpbiAyNiBTZXB0ZW1iZXIuDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQpU aGFua3MgYSBsb3QuDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpKaWFua2FuZyBZ YW8NCg0KIA0KRnJvbTogaW50ZXJuZXQtZHJhZnRzDQoNCkRhdGU6IDIwMTgtMDgtMTIgMjI6MDUN Cg0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KDQpDQzogZXh0cmENCg0KU3ViamVjdDogW0V4 dHJhXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWV4dHJhLXNpZXZlLWZjYy0wNC50eHQNCg0KDQog DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIEVtYWlsIG1haWxzdG9yZSBhbmQgZVh0ZW5zaW9ucyBUbyBSZXZpc2Ugb3IgQW1lbmQgV0cg b2YgdGhlIElFVEYuDQoNCg0KIA0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTaWV2ZSBFeHRl bnNpb246IEZpbGUgQ2FyYm9uIENvcHkgKEZjYykNCg0KICAgICAgICBBdXRob3JzICAgICAgICAg OiBLZW5uZXRoIE11cmNoaXNvbg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIEJyb24gR29u ZHdhbmENCg0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1leHRyYS1zaWV2ZS1mY2MtMDQu dHh0DQoNClBhZ2VzICAgICAgICAgICA6IDEzDQoNCkRhdGUgICAgICAgICAgICA6IDIwMTgtMDgt MTINCg0KDQogDQpBYnN0cmFjdDoNCg0KICAgVGhlIFNpZXZlIEVtYWlsIEZpbHRlcmluZyBMYW5n dWFnZSBwcm92aWRlcyBhIG51bWJlciBvZiBhY3Rpb24NCg0KICAgY29tbWFuZHMsIHNvbWUgb2Yg d2hpY2ggY2FuIGdlbmVyYXRlIGFkZGl0aW9uYWwgbWVzc2FnZXMgb24gYmVoYWxmIG9mDQoNCiAg IHRoZSB1c2VyLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGV4dGVuc2lvbiB0byBzdWNoIGNv bW1hbmRzIHRvDQoNCiAgIGFsbG93IGEgY29weSBvZiBhbnkgZ2VuZXJhdGVkIG1lc3NhZ2UgdG8g YmUgZmlsZWQgaW50byBhIHRhcmdldA0KDQogICBtYWlsYm94Lg0KDQoNCiANCg0KIA0KVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZXh0cmEtc2lldmUtZmNjLw0KDQoN CiANClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZXh0cmEtc2lldmUtZmNjLTA0DQoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1leHRyYS1z aWV2ZS1mY2MtMDQNCg0KDQogDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWV4dHJhLXNpZXZlLWZjYy0wNA0KDQoNCiANCg0KIA0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KDQoNCiANCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy8NCg0KDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpFeHRyYSBtYWlsaW5nIGxpc3QNCg0KRXh0cmFAaWV0Zi5vcmcNCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9leHRyYQ0KDQoNCg0KLS0NCg0KICBCcm9uIEdvbmR3 YW5hLCBDRU8sIEZhc3RNYWlsIFB0eSBMdGQNCg0KICBicm9uZ0BmYXN0bWFpbHRlYW0uY29t ------=_001_NextPart031024617341_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hello,
 
   Waiting for your kind review/comments for this document.= The=20 last call will end in a week.
 
Thanks.
 
Jiankang Yao
 
From: Jiankang Yao<= /DIV>
Date: 2018-09-05 15:11
To: extra
Subject: [Extra] Fw: I-D Action:=20 draft-ietf-extra-sieve-fcc-04.txt
Dear all,
 
Gentle reminder.
This draft will be in WG last call=  for 3 weeks, which ends in 26=20 September.
Any comments are welcome.
Thanks a lot.
 
 
 
---------------------------------------------------------------------= -----------
 
Jiankang Yao

 
From: internet-drafts
Date: 2018-08-12 22:05
To: i-d-announce@ietf.org
CC: extra
Subject: [Extra] I-D Action:=20 draft-ietf-extra-sieve-fcc-04.txt

 
A New Internet-Draft is available from&nbs= p;the on-line Internet-Drafts directories.
This draft is a work item of the=  Email mailstore and eXtensions To Revise&nb= sp;or Amend WG of the IETF.

 
        Title  &n= bsp;        : Sieve Exte= nsion: File Carbon Copy (Fcc)
        Authors  =        : Kenneth Murchison
           &= nbsp;           &nb= sp;  Bron Gondwana
Filename        : draf= t-ietf-extra-sieve-fcc-04.txt
Pages          &n= bsp;: 13
Date          &nb= sp; : 2018-08-12

 
Abstract:
   The Sieve Email Filtering Lan= guage provides a number of action
   commands, some of which can&n= bsp;generate additional messages on behalf of
=
   the user.  This document = ;defines an extension to such commands to
   allow a copy of any gene= rated message to be filed into a target=
   mailbox.

 

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

 
There are also htmlized versions available=  at:
https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-04
https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-04=

 
A diff from the previous version is&n= bsp;available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-sieve-fcc-04

 

 
Please note that it may take a c= ouple of minutes from the time of submi= ssion
until the htmlized version and diff a= re available at tools.ietf.org.

 
Internet-Drafts are also available by anon= ymous 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

------=_001_NextPart031024617341_=------ From nobody Mon Sep 24 22:03:34 2018 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 7C1CF131220; Mon, 24 Sep 2018 22:03:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-extra-imap-savedate@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153785181249.31287.13479743016328520407.idtracker@ietfa.amsl.com> Date: Mon, 24 Sep 2018 22:03:32 -0700 Archived-At: Subject: [Extra] Adam Roach's Yes on draft-ietf-extra-imap-savedate-01: (with COMMENT) 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, 25 Sep 2018 05:03:33 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-imap-savedate-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This seems a very useful mechanism. Thanks to everyone who contributed. ยง2: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [KEYWORDS]. Please update to use RFC 8174's boilerplate. From nobody Tue Sep 25 07:11:55 2018 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 4A0FC131338; Tue, 25 Sep 2018 07:11:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-extra-imap-savedate@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153788471329.4728.13625249224205071592.idtracker@ietfa.amsl.com> Date: Tue, 25 Sep 2018 07:11:53 -0700 Archived-At: Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-savedate-01: (with COMMENT) 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, 25 Sep 2018 14:11:53 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-imap-savedate-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 to permanently remove (expunge) all messages in that Trash mailbox deleted before a certain time (e.g. a configurable expiration nit: comma after "e.g.". Section 4.2 Should there be an example for the 'NIL response' case? From nobody Tue Sep 25 07:49:28 2018 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 AA3AD131011; Tue, 25 Sep 2018 07:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GThjQR4KSYL; Tue, 25 Sep 2018 07:49:20 -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 3A3CD130F53; Tue, 25 Sep 2018 07:49:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B487DB810D7; Tue, 25 Sep 2018 07:49:19 -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: <20180925144919.B487DB810D7@rfc-editor.org> Date: Tue, 25 Sep 2018 07:49:19 -0700 (PDT) Archived-At: Subject: [Extra] =?utf-8?q?RFC_8474_on_IMAP_Extension_for_Object_Identifi?= =?utf-8?q?ers?= 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, 25 Sep 2018 14:49:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8474 Title: IMAP Extension for Object Identifiers Author: B. Gondwana, Ed. Status: Standards Track Stream: IETF Date: September 2018 Mailbox: brong@fastmailteam.com Pages: 16 Characters: 29546 Updates: RFC 3501 I-D Tag: draft-ietf-extra-imap-objectid-08.txt URL: https://www.rfc-editor.org/info/rfc8474 DOI: 10.17487/RFC8474 This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. 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 Wed Sep 26 18:12:41 2018 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 848E6127AC2 for ; Wed, 26 Sep 2018 18:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFIFV20c3vtC for ; Wed, 26 Sep 2018 18:12:35 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 310D9128B14 for ; Wed, 26 Sep 2018 18:12:33 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QAh9Lqxb3qkaAA--.11752S2; Thu, 27 Sep 2018 09:12:29 +0800 (CST) Date: Thu, 27 Sep 2018 09:12:28 +0800 From: "Jiankang Yao" To: extra Reply-To: yaojk References: <153616200699.19753.13957702160049989504@ietfa.amsl.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2018092709114637832442@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart666328535056_=----" X-CM-TRANSID: AQAAf0A5QAh9Lqxb3qkaAA--.11752S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Aw1rAw17Zr4fZrWxCFyrCrg_yoW8uw1rpF 43X34fGr1kJ3WxKw48Gryjqw1UA34YgayfC3ZxKr18Aay5Ga4vyF1Sy3yYv343Jr4rWFs7 Zr1S9w1jvwn5XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF 0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xv F2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6w4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j 6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6V ACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU2y8BUUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-03.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 01:12:39 -0000 This is a multi-part message in MIME format. ------=_001_NextPart666328535056_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpEZWFyIGFsbCwNCg0KR2VudGxlIHJlbWluZGVyLg0KVGhpcyBkcmFmdCB3aWxsIGJlIGluIFdH IGxhc3QgY2FsbCBmb3IgMyB3ZWVrcywgd2hpY2ggZW5kcyBpbiAxOCBPY3QuDQpBbnkgY29tbWVu dHMgYXJlIHdlbGNvbWUuDQpUaGFua3MgYSBsb3QuDQoNCg0KDQoNCkppYW5rYW5nIFlhbw0KDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHMNCkRhdGU6IDIwMTgtMDktMDUgMjM6NDANClRvOiBpLWQtYW5u b3VuY2VAaWV0Zi5vcmcNCkNDOiBleHRyYQ0KU3ViamVjdDogW0V4dHJhXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWV4dHJhLXNpZXZlLXNwZWNpYWwtdXNlLTAzLnR4dA0KDQpBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBFbWFpbCBtYWlsc3Rv cmUgYW5kIGVYdGVuc2lvbnMgVG8gUmV2aXNlIG9yIEFtZW5kIFdHIG9mIHRoZSBJRVRGLg0KDQog ICAgICAgIFRpdGxlICAgICAgICAgICA6IFNpZXZlIEVtYWlsIEZpbHRlcmluZzogRGVsaXZlcmlu ZyB0byBTcGVjaWFsLVVzZSBNYWlsYm94ZXMNCiAgICAgICAgQXV0aG9yICAgICAgICAgIDogU3Rl cGhhbiBCb3NjaA0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1leHRyYS1zaWV2ZS1zcGVj aWFsLXVzZS0wMy50eHQNClBhZ2VzICAgICAgICAgICA6IDkNCkRhdGUgICAgICAgICAgICA6IDIw MTgtMDktMDUNCg0KQWJzdHJhY3Q6DQogICBUaGUgU1BFQ0lBTC1VU0UgY2FwYWJpbGl0eSBvZiB0 aGUgSU1BUCBwcm90b2NvbCAoUkZDIDYxNTQpIGFsbG93cw0KICAgY2xpZW50cyB0byBpZGVudGlm eSBzcGVjaWFsLXVzZSBtYWlsYm94ZXM7IGUuZy4sIHdoZXJlIGRyYWZ0IG9yIHNlbnQNCiAgIG1l c3NhZ2VzIHNob3VsZCBiZSBwdXQuICBUaGlzIHNpbXBsaWZpZXMgY2xpZW50IGNvbmZpZ3VyYXRp b24uICBJbg0KICAgY29udHJhc3QsIHRoZSBTaWV2ZSBtYWlsIGZpbHRlcmluZyBsYW5ndWFnZSAo UkZDIDUyMjgpIGN1cnJlbnRseSBoYXMNCiAgIG5vIHN1Y2ggY2FwYWJpbGl0eS4gIFRoaXMgbWVt byBkZWZpbmVzIGEgU2lldmUgZXh0ZW5zaW9uIHRoYXQgZmlsbHMNCiAgIHRoaXMgZ2FwOiBpdCBh ZGRzIGEgdGVzdCBmb3IgY2hlY2tpbmcgd2hldGhlciBhIHNwZWNpYWwtdXNlIGF0dHJpYnV0ZQ0K ICAgaXMgYXNzaWduZWQgZm9yIGEgcGFydGljdWxhciBtYWlsYm94IG9yIGFueSBtYWlsYm94LCBh bmQgaXQgYWRkcyB0aGUNCiAgIGFiaWxpdHkgdG8gZmlsZSBtZXNzYWdlcyBpbnRvIGFuIGFub255 bW91cyBtYWlsYm94IHRoYXQgaGFzIGENCiAgIHBhcnRpY3VsYXIgc3BlY2lhbC11c2UgYXR0cmli dXRlIGFzc2lnbmVkLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1leHRyYS1zaWV2ZS1zcGVjaWFsLXVzZS8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZXh0cmEtc2lldmUtc3BlY2lhbC11c2UtMDMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1leHRyYS1zaWV2ZS1zcGVjaWFsLXVzZS0wMw0KDQpBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1leHRyYS1zaWV2ZS1zcGVjaWFsLXVz ZS0wMw0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpFeHRyYSBtYWlsaW5nIGxpc3QNCkV4dHJhQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2V4dHJh ------=_001_NextPart666328535056_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
Dear all,
 
Gentle reminder.
This draft will be in WG last call=  for 3 weeks, which ends in 18 Oct= .
Any comments are welcome.
Thanks a lot.
 
Jiankang Yao
 
From: internet-drafts
Date: 2018-09-05 23:40
To: i-d-announce@ietf.org
CC: extra
Subject: [Extra] I-D Action:=20 draft-ietf-extra-sieve-special-use-03.txt
 
A New Internet-Draft is available from = the on-line Internet-Drafts directories.
This draft is a work item of the&n= bsp;Email mailstore and eXtensions To Revise = ;or Amend WG of the IETF.
 
        Title  &nbs= p;        : Sieve Email&= nbsp;Filtering: Delivering to Special-Use Mailboxes
        Author  &nb= sp;       : Stephan Bosch
Filename        : draft-= ietf-extra-sieve-special-use-03.txt
Pages          &nbs= p;: 9
Date           = ; : 2018-09-05
 
Abstract:
   The SPECIAL-USE capability of t= he IMAP protocol (RFC 6154) allows
   clients to identify special-use = ;mailboxes; e.g., where draft or sent
   messages should be put.  T= his simplifies client configuration.  In
   contrast, the Sieve mail filter= ing language (RFC 5228) currently has
   no such capability.  This = memo defines a Sieve extension that fills
   this gap: it adds a test&n= bsp;for checking whether a special-use attribute<= /DIV>
   is assigned for a particular&nb= sp;mailbox or any mailbox, and it adds = the
   ability to file messages into&n= bsp;an anonymous mailbox that has a
   particular special-use attribute ass= igned.
 
 
The IETF datatracker status page for th= is draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/<= /DIV>
 
There are also htmlized versions available&n= bsp;at:
https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-03
https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-= use-03
 
A diff from the previous version is&nbs= p;available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-sieve-special-us= e-03
 
 
Please note that it may take a cou= ple of minutes from the time of submiss= ion
until the htmlized version and diff are=  available at tools.ietf.org.
 
Internet-Drafts are also available by anonym= ous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra
------=_001_NextPart666328535056_=------ From nobody Fri Sep 28 20:38:25 2018 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 A6E66127AC2; Fri, 28 Sep 2018 20:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnuiweuRu1SX; Fri, 28 Sep 2018 20:38:21 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id AA1E8126F72; Fri, 28 Sep 2018 20:38:15 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZIPyh865bFTEbAA--.19766S2; Sat, 29 Sep 2018 11:38:09 +0800 (CST) Date: Sat, 29 Sep 2018 11:38:05 +0800 From: "Jiankang Yao" To: draft-ietf-extra-sieve-fcc Cc: extra Reply-To: yaojk References: <153662523769.16137.7151778749740462039@ietfa.amsl.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2018092911370230091886@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart077660771763_=----" X-CM-TRANSID: AQAAf0AZIPyh865bFTEbAA--.19766S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCr15Zry7ur43KryxXw4kXrb_yoW5ur4DpF W3Wry3Kr1rJa1xK3yxXr15ZF1Y9ry3JFWrA3ZxKrykAFW5Aa4ktr1xtwsYvr9rCr93GFWD Zw129w1UW395XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I2 6xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4I kC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI 67k04243AVC20s07MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7x kEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E 67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCw CI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E 3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64 xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07brWlkUUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-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: Sat, 29 Sep 2018 03:38:24 -0000 This is a multi-part message in MIME format. ------=_001_NextPart077660771763_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzLA0KDQogIEkgYW0gcHJlcGFyaW5nIGZvciB0aGUgc2hlcGhlcmQgd3JpdGUt dXAuDQoNCiAgQ291bGQgeW91IGtpbmRseSBhZGRyZXNzIHRoZSBmb2xsb3dpbmcgaXNzdWVzIGFu ZCB1cGRhdGUgYSBuZXcgdmVyc2lvbj8gVGhhbmtzLiANCg0KICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2lkbml0cz91cmw9aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWV4dHJh LXNpZXZlLWZjYy0wNS50eHQgDQoNCg0KICAqKiBUaGVyZSBpcyAxIGluc3RhbmNlIG9mIHRvbyBs b25nIGxpbmVzIGluIHRoZSBkb2N1bWVudCwgdGhlIGxvbmdlc3Qgb25lDQogICAgIGJlaW5nIDIg Y2hhcmFjdGVycyBpbiBleGNlc3Mgb2YgNzIuDQoNCiAgLS0gVGhlIGRyYWZ0IGhlYWRlciBpbmRp Y2F0ZXMgdGhhdCB0aGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNTQzNSwgYnV0IHRoZQ0KICAgICBh YnN0cmFjdCBkb2Vzbid0IHNlZW0gdG8gbWVudGlvbiB0aGlzLCB3aGljaCBpdCBzaG91bGQuDQoN CiAgLS0gVGhlIGRyYWZ0IGhlYWRlciBpbmRpY2F0ZXMgdGhhdCB0aGlzIGRvY3VtZW50IHVwZGF0 ZXMgUkZDNTIzMCwgYnV0IHRoZQ0KICAgICBhYnN0cmFjdCBkb2Vzbid0IHNlZW0gdG8gbWVudGlv biB0aGlzLCB3aGljaCBpdCBzaG91bGQuDQoNCg0KICBDaGVja2luZyByZWZlcmVuY2VzIGZvciBp bnRlbmRlZCBzdGF0dXM6IFByb3Bvc2VkIFN0YW5kYXJkDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KICAgICAoU2VlIFJGQ3MgMzk2NyBhbmQgNDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNp bmcgbm9ybWF0aXZlIHJlZmVyZW5jZXMNCiAgICAgdG8gbG93ZXItbWF0dXJpdHkgZG9jdW1lbnRz IGluIFJGQ3MpDQoNCiAgLS0gTG9va3MgbGlrZSBhIHJlZmVyZW5jZSwgYnV0IHByb2JhYmx5IGlz bid0OiAnMScgb24gbGluZSA1MjQNCg0KICA9PSBNaXNzaW5nIFJlZmVyZW5jZTogJ0ZDQycgaXMg bWVudGlvbmVkIG9uIGxpbmUgMTk2LCBidXQgbm90IGRlZmluZWQNCg0KICAtLSBMb29rcyBsaWtl IGEgcmVmZXJlbmNlLCBidXQgcHJvYmFibHkgaXNuJ3Q6ICcyJyBvbiBsaW5lIDUyNg0KDQogIC0t IExvb2tzIGxpa2UgYSByZWZlcmVuY2UsIGJ1dCBwcm9iYWJseSBpc24ndDogJzMnIG9uIGxpbmUg NTI4DQoNCiAgLS0gTG9va3MgbGlrZSBhIHJlZmVyZW5jZSwgYnV0IHByb2JhYmx5IGlzbid0OiAn NCcgb24gbGluZSA1MzANCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNTMyMScgaXMgZGVm aW5lZCBvbiBsaW5lIDQ5NSwgYnV0IG5vIGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3YXMgZm91 bmQgaW4gdGhlIHRleHQNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNTQyOScgaXMgZGVm aW5lZCBvbiBsaW5lIDQ5OSwgYnV0IG5vIGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3YXMgZm91 bmQgaW4gdGhlIHRleHQNCg0KICAqKiBPYnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMg NDIzNCAoT2Jzb2xldGVkIGJ5IFJGQyA1MjM0KQ0KDQoNCiAgICAgU3VtbWFyeTogMiBlcnJvcnMg KCoqKSwgMCBmbGF3cyAofn4pLCA0IHdhcm5pbmdzICg9PSksIDkgY29tbWVudHMgKC0tKS4NCg0K ICAgICBSdW4gaWRuaXRzIHdpdGggdGhlIC0tdmVyYm9zZSBvcHRpb24gZm9yIG1vcmUgZGV0YWls ZWQgaW5mb3JtYXRpb24gYWJvdXQNCiAgICAgdGhlIGl0ZW1zIGFib3ZlLg0KDQoNCg0KDQoNCg0K DQoNCkppYW5rYW5nIFlhbw0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHMNCkRhdGU6IDIwMTgtMDkt MTEgMDg6MjANClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNDOiBleHRyYQ0KU3ViamVjdDog W0V4dHJhXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWV4dHJhLXNpZXZlLWZjYy0wNS50eHQNCg0K QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg RW1haWwgbWFpbHN0b3JlIGFuZCBlWHRlbnNpb25zIFRvIFJldmlzZSBvciBBbWVuZCBXRyBvZiB0 aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTaWV2ZSBFeHRlbnNpb246IEZp bGUgQ2FyYm9uIENvcHkgKEZjYykNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VubmV0aCBN dXJjaGlzb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgQnJvbiBHb25kd2FuYQ0KRmlsZW5h bWUgICAgICAgIDogZHJhZnQtaWV0Zi1leHRyYS1zaWV2ZS1mY2MtMDUudHh0DQpQYWdlcyAgICAg ICAgICAgOiAxMw0KRGF0ZSAgICAgICAgICAgIDogMjAxOC0wOS0xMA0KDQpBYnN0cmFjdDoNCiAg IFRoZSBTaWV2ZSBFbWFpbCBGaWx0ZXJpbmcgTGFuZ3VhZ2UgcHJvdmlkZXMgYSBudW1iZXIgb2Yg YWN0aW9uDQogICBjb21tYW5kcywgc29tZSBvZiB3aGljaCBjYW4gZ2VuZXJhdGUgYWRkaXRpb25h bCBtZXNzYWdlcyBvbiBiZWhhbGYgb2YNCiAgIHRoZSB1c2VyLiAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIGFuIGV4dGVuc2lvbiB0byBzdWNoIGNvbW1hbmRzIHRvDQogICBhbGxvdyBhIGNvcHkgb2Yg YW55IGdlbmVyYXRlZCBtZXNzYWdlIHRvIGJlIGZpbGVkIGludG8gYSB0YXJnZXQNCiAgIG1haWxi b3guDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWV4dHJhLXNp ZXZlLWZjYy8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0 Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZXh0cmEtc2lldmUtZmNj LTA1DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZXh0 cmEtc2lldmUtZmNjLTA1DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LWV4dHJhLXNpZXZlLWZjYy0wNQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFeHRyYSBtYWlsaW5nIGxpc3QNCkV4 dHJhQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2V4dHJh ------=_001_NextPart077660771763_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear authors,
 
  I am preparing for the shepherd write-up.
 
  Could you kindly address the following issues and up= date a=20 new version? Thanks. 
 
  https://tools.ietf.org/idnits?url=3Dhttps:/= /tools.ietf.org/id/draft-ietf-extra-sieve-fcc-05.txt=20
 
 
  ** There is 1 instance of too long lines in the=
 document, the longest one
     being 2 characters in excess of 72.

  -- The draft header indicates that this document updates RFC5435, but th=
e
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC5230, but th=
e
     abstract doesn't seem to mention this, which it should.
 
  Checking references for intended status: Proposed Standard
  ------------------------------------------------------------------------=
----

     (See RFCs 3967 and 4897 for information about using normative referen=
ces
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 524

  =3D=3D Missing Reference: 'FCC' is mentioned on line 196, but not define=
d

  -- Looks like a reference, but probably isn't: '2' on line 526

  -- Looks like a reference, but probably isn't: '3' on line 528

  -- Looks like a reference, but probably isn't: '4' on line 530

  =3D=3D Unused Reference: 'RFC5321' is defined on line 495, but no explic=
it
     reference was found in the text

  =3D=3D Unused Reference: 'RFC5429' is defined on line 499, but no explic=
it
     reference was found in the text

  ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)


     Summary: 2 errors (**), 0 flaws (~~), 4 warnings (=3D=3D), 9 comments=
 (--).

     Run idnits with the --verbose option for more detailed information ab=
out
     the items above.


Jiankang Yao
 
From: internet-drafts
Date: 2018-09-11 08:20
To: i-d-announce@ietf.org
CC: extra
Subject: [Extra] I-D Action:=20 draft-ietf-extra-sieve-fcc-05.txt
 
A New Internet-Draft is available from = the on-line Internet-Drafts directories.
This draft is a work item of the&n= bsp;Email mailstore and eXtensions To Revise = ;or Amend WG of the IETF.
 
        Title  &nbs= p;        : Sieve Extens= ion: File Carbon Copy (Fcc)
        Authors  &n= bsp;      : Kenneth Murchison
           &nb= sp;            = ;  Bron Gondwana
Filename        : draft-= ietf-extra-sieve-fcc-05.txt
Pages          &nbs= p;: 13
Date           = ; : 2018-09-10
 
Abstract:
   The Sieve Email Filtering Langu= age provides a number of action
   commands, some of which can&nbs= p;generate additional messages on behalf of
   the user.  This document d= efines an extension to such commands to
   allow a copy of any genera= ted message to be filed into a target
   mailbox.
 
 
The IETF datatracker status page for th= is draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/
 
There are also htmlized versions available&n= bsp;at:
https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-05
https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-05
 
A diff from the previous version is&nbs= p;available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-sieve-fcc-05
 
 
Please note that it may take a cou= ple of minutes from the time of submiss= ion
until the htmlized version and diff are=  available at tools.ietf.org.
 
Internet-Drafts are also available by anonym= ous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra
------=_001_NextPart077660771763_=------