From nobody Mon May 1 09:52:59 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC7912717E for ; Mon, 1 May 2017 09:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 GPFsgpFN3-mH for ; Mon, 1 May 2017 09:52:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 384F8129455 for ; Mon, 1 May 2017 09:50:28 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v41GoLNM032551 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 May 2017 16:50:22 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v41GoJXN017684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 May 2017 16:50:21 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v41GoIsv006456; Mon, 1 May 2017 16:50:18 GMT Received: from [10.145.239.190] (/10.145.239.190) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 May 2017 09:50:18 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: jmap@ietf.org, "Arnt Gulbrandsen" Date: Mon, 01 May 2017 09:50:17 -0700 Message-ID: <9FA9B645-EAE3-412C-923A-77B0987E70B4@oracle.com> In-Reply-To: <1493360522.1171603.959013464.217C003E@webmail.messagingengine.com> References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> <1A7624AF-2FD9-4FE8-A29D-23BFADEED04B@apple.com> <1493360522.1171603.959013464.217C003E@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 16:52:57 -0000 On 27 Apr 2017, at 23:22, Neil Jenkins wrote: > Firstly, I think we should map the 4 \System flags to $System in JMAP. > Using backslash is a real pain because it is an escape character in > JSON, so examples in the spec are confusing if nothing else! Changing > it > to $ would make the system keywords consistent with the IANA > registered > keywords, which I believe will be less confusing for developers coming > in without an IMAP background. The only issue would be what to do if > someone has added "$Flagged" etc. user keywords on an IMAP server. > This > seems unlikely to be much of a real-world occurrence to me, on the > basis > it would have been very confusing, but I think we can just specify > that > these keywords are not visible over JMAP. If you choose to map \System to $System, I'd suggest making the JMAP specification IANA considerations section register the four $System flags in the IMAP keyword registry as "names reserved for use by JMAP; use in IMAP not recommended". I'd also suggest renaming the registry to "IMAP/JMAP keywords" or "IMAP keywords and JMAP flags" (depending on terminology you want to use). - Chris From nobody Mon May 1 10:48:21 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2B1294F5 for ; Mon, 1 May 2017 10:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 D1XvAzaF4VzM for ; Mon, 1 May 2017 10:48:18 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 E73EE1243FE for ; Mon, 1 May 2017 10:44:56 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v41Hiumb047674 for ; Mon, 1 May 2017 13:44:56 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 2a68uyhmbk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 01 May 2017 13:44:55 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v41HiraQ022436 for ; Mon, 1 May 2017 13:44:53 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v41HimV6022336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 1 May 2017 13:44:51 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Mon, 1 May 2017 17:44:40 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.29]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0319.002; Mon, 1 May 2017 13:44:40 -0400 From: "HANSEN, TONY L" CC: "jmap@ietf.org" Thread-Topic: [Jmap] Adding the Message::isForwarded property Thread-Index: AQHSwptp/3qBlL4ysEWf00twd7gFhqHfwAAA Date: Mon, 1 May 2017 17:44:40 +0000 Message-ID: References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> <1A7624AF-2FD9-4FE8-A29D-23BFADEED04B@apple.com> <1493360522.1171603.959013464.217C003E@webmail.messagingengine.com> <9FA9B645-EAE3-412C-923A-77B0987E70B4@oracle.com> In-Reply-To: <9FA9B645-EAE3-412C-923A-77B0987E70B4@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.122.222] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-01_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705010113 Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 17:48:20 -0000 T24gNS8xLzE3LCAxMjo1MCBQTSwgIkptYXAgb24gYmVoYWxmIG9mIENocmlzIE5ld21hbiIgPGpt YXAtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXMubmV3bWFuQG9yYWNsZS5jb20+ IHdyb3RlOg0KDQogICAgT24gMjcgQXByIDIwMTcsIGF0IDIzOjIyLCBOZWlsIEplbmtpbnMgd3Jv dGU6DQogICAgPiBGaXJzdGx5LCBJIHRoaW5rIHdlIHNob3VsZCBtYXAgdGhlIDQgXFN5c3RlbSBm bGFncyB0byAkU3lzdGVtIGluIEpNQVAuDQogICAgPiBVc2luZyBiYWNrc2xhc2ggaXMgYSByZWFs IHBhaW4gYmVjYXVzZSBpdCBpcyBhbiBlc2NhcGUgY2hhcmFjdGVyIGluDQogICAgPiBKU09OLCBz byBleGFtcGxlcyBpbiB0aGUgc3BlYyBhcmUgY29uZnVzaW5nIGlmIG5vdGhpbmcgZWxzZSEgQ2hh bmdpbmcgDQogICAgPiBpdA0KICAgID4gdG8gJCB3b3VsZCBtYWtlIHRoZSBzeXN0ZW0ga2V5d29y ZHMgY29uc2lzdGVudCB3aXRoIHRoZSBJQU5BIA0KICAgID4gcmVnaXN0ZXJlZA0KICAgID4ga2V5 d29yZHMsIHdoaWNoIEkgYmVsaWV2ZSB3aWxsIGJlIGxlc3MgY29uZnVzaW5nIGZvciBkZXZlbG9w ZXJzIGNvbWluZw0KICAgID4gaW4gd2l0aG91dCBhbiBJTUFQIGJhY2tncm91bmQuIFRoZSBvbmx5 IGlzc3VlIHdvdWxkIGJlIHdoYXQgdG8gZG8gaWYNCiAgICA+IHNvbWVvbmUgaGFzIGFkZGVkICIk RmxhZ2dlZCIgZXRjLiB1c2VyIGtleXdvcmRzIG9uIGFuIElNQVAgc2VydmVyLiANCiAgICA+IFRo aXMNCiAgICA+IHNlZW1zIHVubGlrZWx5IHRvIGJlIG11Y2ggb2YgYSByZWFsLXdvcmxkIG9jY3Vy cmVuY2UgdG8gbWUsIG9uIHRoZSANCiAgICA+IGJhc2lzDQogICAgPiBpdCB3b3VsZCBoYXZlIGJl ZW4gdmVyeSBjb25mdXNpbmcsIGJ1dCBJIHRoaW5rIHdlIGNhbiBqdXN0IHNwZWNpZnkgDQogICAg PiB0aGF0DQogICAgPiB0aGVzZSBrZXl3b3JkcyBhcmUgbm90IHZpc2libGUgb3ZlciBKTUFQLg0K ICAgIA0KICAgIElmIHlvdSBjaG9vc2UgdG8gbWFwIFxTeXN0ZW0gdG8gJFN5c3RlbSwgSSdkIHN1 Z2dlc3QgbWFraW5nIHRoZSBKTUFQIA0KICAgIHNwZWNpZmljYXRpb24gSUFOQSBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uIHJlZ2lzdGVyIHRoZSBmb3VyICRTeXN0ZW0gDQogICAgZmxhZ3MgaW4gdGhl IElNQVAga2V5d29yZCByZWdpc3RyeSBhcyAibmFtZXMgcmVzZXJ2ZWQgZm9yIHVzZSBieSBKTUFQ OyANCiAgICB1c2UgaW4gSU1BUCBub3QgcmVjb21tZW5kZWQiLiBJJ2QgYWxzbyBzdWdnZXN0IHJl bmFtaW5nIHRoZSByZWdpc3RyeSB0byANCiAgICAiSU1BUC9KTUFQIGtleXdvcmRzIiBvciAiSU1B UCBrZXl3b3JkcyBhbmQgSk1BUCBmbGFncyIgKGRlcGVuZGluZyBvbiANCiAgICB0ZXJtaW5vbG9n eSB5b3Ugd2FudCB0byB1c2UpLg0KDQpDb25jdXIuIE5vdGU6IHRoaXMgd291bGQgYWxzbyBhZGQg YW4g4oCcVXBkYXRlczogNTc4OOKAnSB0byB0aGUgc3BlYy4NCg0KCVRvbnkNCg0K From nobody Mon May 1 14:55:58 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA90512EB3F for ; Mon, 1 May 2017 14:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDFwPDTj0VeQ for ; Mon, 1 May 2017 14:55:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 7C7B6127058 for ; Mon, 1 May 2017 14:53:26 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v41LrNHC004035 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 1 May 2017 21:53:23 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v41LrMpb028665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 May 2017 21:53:23 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v41LrKV3012088; Mon, 1 May 2017 21:53:21 GMT Received: from [10.145.239.190] (/10.145.239.190) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 May 2017 14:53:20 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: jmap@ietf.org Date: Mon, 01 May 2017 14:53:18 -0700 Message-ID: In-Reply-To: <1493358386.1136069.958999408.285D03F1@webmail.messagingengine.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> <1493358386.1136069.958999408.285D03F1@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 21:55:58 -0000 On 27 Apr 2017, at 22:46, Neil Jenkins wrote: > On Thu, 27 Apr 2017, at 02:06 AM, Chris Newman wrote: >> Well, if you believe that and I don't believe that, > > Then clearly we need to discover where the divergence in mental models > is occurring. Here's my guess at the root cause: * You're trying to mirror a particular client UI model in the mail store server design. * I'm trying to minimize the necessary server infrastructure to support popular UI models (including yours), particularly when the server is RFC 4865 standards-based already. I see the following divergence as a result of these perspectives: 1. I believe there are four message types involved in this discussion: * draft messages * client-side outbox * future release RFC 4865 submitted * other submitted messages I believe we agree the protocol should make it simple to separate and count these classes of messages for UI display. However, I strongly prefer a design where the latter two message types are treated the same on the server because it reduces the necessary server infrastructure (and, in particular, it avoids conflating mail store and mail queue semantics). 2. I believe that mixing client-side outbox and future release messages is a poor UI that will confuse users. Client-side outbox messages have not been submitted and will not move forward if the client is offline or the client removes the message from the outbox. Future release messages have been submitted and will move forward when the client/MUA is offline, even if the message is removed by the client when offline. These messages can only be stopped by an explicit online "unsend" MTA operation. This is why I believe mixing these messages will be confusing. You apparently do not agree with me on that point. As with all UI design, at some point there will be disagreements between reasonable people that are not resolvable. I suspect this is one of those cases. To me that suggests the resolution is a protocol that doesn't constrain the UI choices in this area. 3. I view "submit" and "unsend" as MTA actions that should not be confused or conflated with mail store operations. I'm opposed to protocol designs where a message move, delete or flag changes triggers MTA actions as a side-effect. Instead, I propose JMAP have explicit "submit" and "unsend" commands that first perform the MTA action but can also trigger mail store actions (like move message or flag change) if the MTA action succeeds. 4. I believe the "unsend" MTA operation can be applied to any submitted message, not just future release messages. It's more likely to succeed on a future release message, but there are plenty of proprietary systems that allow unsend to work at least until the message has been seen by the recipient so we shouldn't disallow that behavior in the JMAP protocol design. >> * Every server that supports future release and unsend will provide >> the same interface to the client. No need for the "always empty >> outbox" alternative server behavior that you'll see with the outbox >> model. > > The server will have to advertise whether it supports scheduled send > regardless of the mechanics underneath. For servers that do not > support > scheduled send, I agree that an always-empty outbox mailbox may feel a > little superfluous, however the point is to, as you say, always > provide > the same interface to the client regardless. The client will know from > the capabilities that it must always be empty, so will probably hide > it > in the sidebar or equivalent navigation mechanism (in fact I expect > clients will probably hide the outbox when empty regardless of > scheduled > send support). Our server already supports scheduled send via RFC 4865 and a proprietary 'unsend/recall' mechanism. However, with the server-side outbox model we'll not expose those capabilities to JMAP clients because our mail store has no access to mail queues and that is an intentional and deliberate design choice for security and scalability reasons. I've proposed a design where existing RFC 4865 standards based servers can transparently expose those capabilities without constraining possible MUA designs. >> * This does not unnecessarily constrain server implementation, and >> permits simpler server designs. > > I do not believe this to be the case, as I will explain below. If an "outbox" is a mail queue (which it is, by definition, if there is a daemon that accesses a message from the outbox and passes it forward in the delivery system), then a server-side-outbox unnecessarily constrains server design. >> * This preserves clean mail store and mail queue separation including >> the security and operational benefits that provides. > > This is I think where the confusion lies. The outbox really isn't a > mail > queue, and no one is suggesting you merge it with your mail store. > > You clearly have existing infrastructure that supports holding > scheduled > messages inside your mail queue and possibly cancelling them from > that. > You wish to reuse this infrastructure, of course! That's fine. To do > so, > when the message is moved to the outbox, you would *also* submit it > into > your mail queue. The copy in the outbox would be the representation in > JMAP land, not part of your mail queue. This implementation approach includes properties of the following anti-patterns: "database-as-IPC", "race hazard" and "action at a distance". https://en.wikipedia.org/wiki/Anti-pattern It raises questions like this: Should the shadow copy in the outbox have the received header that is present on the message in the submission queue? What happens if an MUA deletes the copy of the message in the server-side shadow outbox and the link between MUA and mail queue is down when that action is performed? Does the delete fail with a special error or does the delete succeed and then generate a new DSN-like message saying the attempt to unsend that message failed? Are both of those behaviors allowed? Anyway, this has reinforced my point about putting unnecessary constraints on server design. This proposal requires complex linkages between the JMAP server, the mail store and the mail queue (creating a three-party system with object aliasing that will have unintended consequences). On the flip side, my proposal was neutral on the matter of client UI. If your client wants to create a virtual outbox view for already-submitted future release messages and offer the unsend operation only on those messages, that's fine. > When the message is sent to the > next hop and can no longer be recalled, These two things don't necessarily happen at the same time. For our implementation, a message can be recalled as long as the message lives in a queue in one of our MTAs. It can pass to the next hop MTA and still be unsent. Many proprietary systems allow message recall until the message has been seen by a recipient. JMAP's design shouldn't disallow that. > you then move the JMAP message > from outbox to sent, and remove the `\Draft` keyword. Why require the addition of a new signaling infrastructure from MTA queues to mail store and add new churn to the mail store when the same MUA UI can be achieved without physically moving the message between folders at the future release time? > Other systems may choose to implement it differently, not passing it > to > the mail queue until the scheduled time is reached. As has been > pointed > out already, many systems such as Gmail, FastMail etc. already have > infrastructure to do this kind of thing since it is also used for > deleting messages that are X days old from the trash, supporting > snoozed > mail, etc. Actually, my proposal makes this server design approach simpler. There's just an internal flag in the sent folder to indicate if the message has been passed forward. The mail queue daemon that operates on the mail store sent folder, can transfer the message to the next hop MTA and set that flag at the future release time. No need to move the message between folders. > The outbox protocol is agnostic to how you wish to implement this. > Your > proposal constrains you to only the option *you* already have > implemented. My proposal makes more server approaches possible, while being agnostic from the client UI side (clients can present a virtual outbox for future release messages or not as they choose). >> * This makes it clear when the message enters the submission system. >> There's no confusion as one has with an outbox model where a >> message >> in the outbox may be submitted (if it's on the server) or maybe not >> (if the client is offline when the message moves to the outbox). > > This is clearly up to the client to distinguish, but I strongly > disagree > this is a confusion. For the user, there is the outbox, which > represents > the messages that are yet to be sent. If they open the outbox, I > expect > most MUAs would label why they have not yet been sent (e.g. waiting > for > internet connection, scheduled for time X). See 2 above. >> * Submission can have semantics fully compatible with existing >> infrastructure, making this easier/faster to deploy. > > As mentioned above, a lot of systems already have infrastructure for > "do > action X in folder Y when time Z is reached", or you can alternatively > use your SMTP-queue-scheduled-send to implement the outbox model, so > this is actually *more* compatible with existing infrastructure than > your proposal. It's not "my SMTP-queue-scheduled-send". It's the IETF standards track scheduled send mechanism, RFC 4865. >> * The "outbox" model constrains unsend to only work if the message is >> in the outbox. This model has no such constraint and works the same >> regardless of where a message that can be "unsent" lives in the >> infrastructure. > > When composing and sending a message, it goes through 2 or 3 states. > These need to be represented in the mail store (and thus the protocol) > so that users can understand what is going on, and what actions are > available to them. > > Two of these we (I believe) agree on, since they are from IMAP: > > (1) The message is still being composed. It SHOULD be in the > "drafts" mailbox and MUST have the "\Draft" keyword. This is the > same as IMAP. Agreed. > (2) The message has been sent, cannot be recalled. These two statements are not synonyms; see my item 4 above. > It SHOULD be in the > "sent" mailbox (although services may provide means for users to > ask > it to go somewhere else, for example we have a few users that > prefer > their sent mail to in the same mailbox as the message they were > replying to). > > The third (new) state is for "scheduled" messages. We have two options > for how this is represented: > > 1. By its presence in the "outbox". Moving it out is therefore the > logical thing to unschedule it. I disagree. Unsend is a separate operation with different success/fail consequences from the move message operation. I object to confusing these two operations; see my item 3 above. > 2. By a keyword. This permits it to be in any mailbox, although we > would > probably add an outbox mailbox to our server for holding these > messages by default. Removing the keyword would probably be a > logical > way to unschedule it. This option is quite a bit less efficient at > the protocol level, as without a Mailbox object (which has a > precalculated total count), the client will have to issue a search > every single time there's a state change to see if there are any > scheduled messages. I disagree. Unsend is a separate operation with different success/fail consequences from the change flag/keyword operation. I object to confusing these two operations; see my item 3 above. My proposal is to have future release sent messages tagged with their future release date. The MUA can create a virtual folder for future release messages with a future date. Whether the server caches a count for the messages in that virtual folder is a server design optimization choice. If enough clients request that count that it helps server scalability to cache that count, then servers will cache that count. The count of future release messages is thus not relevant to the issue under debate. > I'm presuming you are not advocating for option (3), which is no > representation in the mail store, since this would be terrible for the > user experience, and your proposal explicitly said "Add a way to > search/select messages in the Sent folder that may be possible to > unsend", which would indicate there must be some kind of state > representing this status. Per my item 3 above, I view "submit" and "unsend" as MTA actions. There are two ways to reflect successful MTA actions in the mail store: A. When the submit action succeeds, the message is moved from draft folder to sent folder, the \draft flag is removed (if set), and an envelope annotation (including future release date if there is one) is added if not already present. When unsend succeeds, the message is moved from the sent folder back to the draft folder. The unsend operation can be applied regardless of whether the message is a future release message. B. When the submit action succeeds, the \draft flag is removed, a $submitted flag is set and an envelope annotation (including future release date if there is one) is added if not already present. When the unsend succeeds, the $submitted flags is removed and a \draft flag is added. I slightly favor option A, but have no strong opinion on this matter. It's even possible to design the submit & unsend actions so both of these are possible (always make the flag change and make the folder-move-on-success an optional feature of the MTA actions). > So however you implement it, you need to trigger some state change on > the JMAP server for each logical step so that clients can represent > this, and update its local model as changes occur. The choice of > representation is mainly down to what will map more easily to how > clients wish to represent the set of scheduled messagese to users. I disagree. The protocol design has peer goals on this matter: make popular UI paradigms straightforward and minimize necessary server infrastructure. > UX designers seem to have overwhelmingly decided that putting these > scheduled messages in an outbox rather than mixing them in with sent > items or elsewhere is a clearer model for users to understand. I > provided 5 example products in the previous email that do this, but if > that's insufficient I noice we have representatives from Apple, Google > and AOL on this list; perhaps they can ask their respective UI teams > to > comment on what they would recommend? I do not contest that client-side outbox is a popular UI model. I further agree the protocol design should allow the presentation of a server-side outbox UI. So I don't think there's a point of contention here. - Chris From nobody Mon May 1 17:32:09 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB567128616 for ; Mon, 1 May 2017 17:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=at1qDig/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QiPOx4D+ 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 HzvQCSbu0o8K for ; Mon, 1 May 2017 17:32:06 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC5212EB5A for ; Mon, 1 May 2017 17:29:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F1A70207A8 for ; Mon, 1 May 2017 20:29:51 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Mon, 01 May 2017 20:29:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= 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=fm1; bh=7WxwG4wSHVkf1mzEelFn4Bwht/QwT 5KHzqW1h1SkM3g=; b=at1qDig/7SKaeX1tsMwssnmBEfSLtXSb97gq1yDGGimTD 2wlQ7nrWmdm1h0bZmiTqBhLN7sruW+j7f1BhLYkE9zuoz7/QHKmCqPm8uH0OLr/3 zAqUxX8DpKA5bKE1Pqr98oEYDPHqUFfSO0FZBCyTWvJdoeqrdCSc6FiELrCU3Hsj 2b7F+zYion+04jbD5kjWLAedXoM9Ew9nGISsMt7QiPPAvfIZ+NpidygMe/tvHDhw Q74qKCDTTtnbzF86yBQGxyUl9uRuU11gyJWmcwe6EZnbxRbXUP24JGD2MnpQ7xER QKQy4IHC0rLUzKgMO3/hiNAtqCzPXuHRlsihMg3eQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=7WxwG4 wSHVkf1mzEelFn4Bwht/QwT5KHzqW1h1SkM3g=; b=QiPOx4D+7eNKTwIp8c4mA3 ditu92cJm4LR6V/1+uUfP11EslHVwQfmpbq8FdgOX7/FPwv8qB20wNiqCYVOIkyW /+i+m8oP6tfV2UPwgbd3Xz0quW8MXj1vjBXhAXZvDeUQr0+khYEdmsqaVyGawLrt y8u7pYhgE5tal/L/nBu+x//X0pPd42zaOi8HQJL4DvgEmlbwji4R8PlW/qvG8Ul5 6NacEoiCEd5WQCxGWjIf49qgi1pVNGJq8awaHtxzp/q68MSxRuBH0ftrOGsUKLk/ TCGaISKuw8FpdckjyDSV+tipXGyiE1jRKVXQpzGe7OabxeZjCbPeOASzAu2Eohng == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C809162704; Mon, 1 May 2017 20:29:51 -0400 (EDT) Message-Id: <1493684991.1823524.962425856.6AFAFD99@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-88a795dc In-Reply-To: Date: Tue, 02 May 2017 10:29:51 +1000 References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <9eb1fd3c-8868-9d24-6c30-46d333b69fef@isode.com> <3c1711a2-46dd-db1c-506e-5e1ad89ce56d@linagora.com> <92769755-62c6-7257-ce3d-7d0b5699735d@isode.com> <27c62cc8-68e0-49b5-4900-34c26d7b4c6a@linagora.com> <1492581452.3025596.948906456.71780673@webmail.messagingengine.com> <1A7624AF-2FD9-4FE8-A29D-23BFADEED04B@apple.com> <1493360522.1171603.959013464.217C003E@webmail.messagingengine.com> <9FA9B645-EAE3-412C-923A-77B0987E70B4@oracle.com> Archived-At: Subject: Re: [Jmap] Adding the Message::isForwarded property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 00:32:09 -0000 On Tue, 2 May 2017, at 03:44, HANSEN, TONY L wrote: > On 5/1/17, 12:50 PM, "Jmap on behalf of Chris Newman" wrote: >=20 > On 27 Apr 2017, at 23:22, Neil Jenkins wrote: > > Firstly, I think we should map the 4 \System flags to $System in JM= AP. > > Using backslash is a real pain because it is an escape character in > > JSON, so examples in the spec are confusing if nothing else! Changi= ng=20 > > it > > to $ would make the system keywords consistent with the IANA=20 > > registered > > keywords, which I believe will be less confusing for developers com= ing > > in without an IMAP background. The only issue would be what to do if > > someone has added "$Flagged" etc. user keywords on an IMAP server.= =20 > > This > > seems unlikely to be much of a real-world occurrence to me, on the= =20 > > basis > > it would have been very confusing, but I think we can just specify= =20 > > that > > these keywords are not visible over JMAP. >=20=20=20=20=20 > If you choose to map \System to $System, I'd suggest making the JMAP= =20 > specification IANA considerations section register the four $System=20 > flags in the IMAP keyword registry as "names reserved for use by JMAP= ;=20 > use in IMAP not recommended". I'd also suggest renaming the registry = to=20 > "IMAP/JMAP keywords" or "IMAP keywords and JMAP flags" (depending on= =20 > terminology you want to use). >=20 > Concur. Note: this would also add an =E2=80=9CUpdates: 5788=E2=80=9D to t= he spec. Have added comments to the effect of both of these things to the ticket abo= ut keywords: https://github.com/jmapio/jmap/issues/73 Bron. --=20 Bron Gondwana brong@fastmail.fm From nobody Wed May 3 01:00:12 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D024129C6B for ; Wed, 3 May 2017 01:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=VkPXcR6i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rAdSZf+5 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 H3yJegEh3Lk8 for ; Wed, 3 May 2017 01:00:05 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7950F12E03A for ; Wed, 3 May 2017 00:57:24 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id DE28020C21; Wed, 3 May 2017 03:57:23 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 03 May 2017 03:57:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.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=fm1; bh=xDoo6zysMsYCB9LprwCnmhLJ3G8Bg eT4uCXci6NTUKU=; b=VkPXcR6iff9kxjweDLgWBlvVJL56qbVYRvVmliERCbJQj 4HrRFwCr7tznxWOWFLHuvU89bglSxlBP6EHagPJQWADLIOYCtTnyLRfoTluLaBE6 cbw7SbBHUoYhxs2A0pqg8Jw4yN5/WfmvgFz9yUN0ODIjj/ZCVos4jGO4IDSs9DpT 7oP9BBGuFnUQrpNbSLtQNAdhjWEBm9VAXVfwY0NuXvgKXLinCCHIyJ6ffBpwKG25 3DNQZtgW1y115OPaSqG3z4dCwFDIL3YwR55zJgbQiZXQzUxQBrjhhpPLcyrYBw8b qlIknX5jB6D/JGMkJXfru3t9L1BvWqWKVJwp5GPgA== 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=fm1; bh=xDoo6z ysMsYCB9LprwCnmhLJ3G8BgeT4uCXci6NTUKU=; b=rAdSZf+51wLAoGKbqKV5Dn pqIqpPd365RPBgVJ+MQ7nyO+FFPssjsaZvj5o4Y2La72O8vF366GmWZTYLdkl0HO NPl34ybvQk5c4aIQ/BCqYULkAggV/hni8xxQOZb8WxQc/2eoi/JibvnoPW15vxC4 Zm4Qh790UX7f6ZXOaQN1jU67+weOq7njyRN0imv7YK3kroqZgymjMgOg6AUZJJqw +HmQu0SSIgwgzHbxwNO0H4vfvGNSKeFvmAr0r9j2YOErrVhHCiC8Sr0MGOVICOR/ r2hyTWLslLEoSwIuJqhOE+e354LJneMn9YsFQYWW+9k+hhvgFNFl72Pq1L4khWFg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9D4F9E264D; Wed, 3 May 2017 03:57:23 -0400 (EDT) Message-Id: <1493798243.3361851.964066360.38B8043E@webmail.messagingengine.com> From: Neil Jenkins To: Chris Newman Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149379824333618510" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e94d03aa In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> <1493358386.1136069.958999408.285D03F1@webmail.messagingengine.com> Date: Wed, 03 May 2017 07:57:23 +0000 Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 08:00:11 -0000 This is a multi-part message in MIME format. --_----------=_149379824333618510 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 1 May 2017, at 09:53 PM, Chris Newman wrote: > Here's my guess at the root cause: > * You're trying to mirror a particular client UI model in the mail > store server design. I'm trying to ensure that the API exposes the data clients need to present common UI patterns in an efficient way, while also allowing the most flexibility in server implementation. I think we're both aiming for the same thing! > 1. I believe there are four message types involved in this discussion:> * draft messages > * client-side outbox > * future release RFC 4865 submitted > * other submitted messages I agree, although I don't think the client-side outbox is particularly relevant to this discussion, as it should not affect the API design. I'm sorry I brought this up as it side-tracked the discussion somewhat. My main point was that many existing systems assign submitted "future release" messages to a separate mailbox on the *server*, and clients present them to the user distinctly to those that have been released. What I misunderstood from your proposal, is that rather than marking messages that can be recalled/cannot be recalled, you propose a client just look at the "release date" annotation instead. Although you also say this: > Actually, my proposal makes this server design approach > simpler. There's> just an internal flag in the sent folder to indicate if the > message has> been passed forward. The mail queue daemon that operates on the mail > store sent folder, can transfer the message to the next hop MTA and > set> that flag at the future release time. No need to move the message > between folders. So the mail queue daemon *does* perform an action on the message in the mail store when it is sent? I previously thought you were advocating for a model where these can be completely separate and so this is not possible. Could you please clarify? I think we've got various issues conflated a bit over these discussions, so I'll clarify what I think are the separate questions: How, if at all, are "future release" messages (that have yet to be released) marked over the API? Is there a change in the state when they are released? I agree this may not correspond exactly with whether a message can be unsent, especially for internal corporate mail systems, so a related question is: how, if at all, are messages marked that can be unsent? (This is potentially a tristate: can (almost) definitely unsend, can definitely not unsend, may be able to unsend). I think if we can agree on answers to these questions, the rest will fall out fairly easily. > 3. I view "submit" and "unsend" as MTA actions that should not be > confused or conflated with mail store operations. I'm opposed to > protocol designs where a message move, delete or flag changes triggers> MTA actions as a side-effect. > Instead, I propose JMAP have explicit "submit" and "unsend" commands > that first perform the MTA action but can> also trigger mail store actions (like move message or flag change) if > the MTA action succeeds. Yes, this is a perfectly fine approach; I'm not opposed to adding explicit sendMessages/unsendMessages calls. If the call can optionally set which mailbox(es)/keywords to set upon successful send, then this is functionally equivalent. > My proposal is to have future release sent messages tagged with their> future release date. The MUA can create a virtual folder for future > release messages with a future date. Whether the server caches a count> for the messages in that virtual folder is a server design > optimization> choice. If enough clients request that count that it helps server > scalability to cache that count, then servers will cache that > count. The> count of future release messages is thus not relevant to the > issue under> debate. What's relevant is how this count is exposed over the API. If there is a mailbox, then the synchronisation of mailbox objects will ensure the client is "pushed" the count; because count changes are common and clients need to know them to present the most common UI paradigm for mail, synchronisation of mailbox counts is optimised for in the JMAP protocol. One proposal that might satisfy everyone: an "outbox" or "futurerelease" mailbox role is added (this is the IMAP SPECIAL-USE representation in JMAP). Servers can *optionally* have a mailbox with this role; if it does, clients SHOULD place future-release messages in here, but like "sent" *can* put the message in any mailbox(es). Servers that have this mailbox MUST move messages from this mailbox to the sent mailbox at future release time (which may just be based upon the future-release date, or may be actually based on releasing it to the mail queue). Neil. --_----------=_149379824333618510 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 1 May 2017, at 09:53 PM, Chris Newman wrote:
Here's my guess at the root cause:
* You're trying to mirror a particular client UI model in the mail store server design.

I'm trying to ensure that the API exposes the data clients need to present common UI patterns in an efficient way, while also allowing the most flexibility in server implementation. I think we're both aiming for the same thing!

1. I believe there are four message types involved in this discussion:
  * draft messages
  * client-side outbox
  * future release RFC 4865 submitted
  * other submitted messages

I agree, although I don't think the client-side outbox is particularly relevant to this discussion, as it should not affect the API design. I'm sorry I brought this up as it side-tracked the discussion somewhat. My main point was that many existing systems assign submitted "future release" messages to a separate mailbox on the server, and clients present them to the user distinctly to those that have been released.

What I misunderstood from your proposal, is that rather than marking messages that can be recalled/cannot be recalled, you propose a client just look at the "release date" annotation instead. Although you also say this:

Actually, my proposal makes this server design approach simpler. There's
just an internal flag in the sent folder to indicate if the message has
been passed forward. The mail queue daemon that operates on the mail
store sent folder, can transfer the message to the next hop MTA and set
that flag at the future release time. No need to move the message
between folders.

So the mail queue daemon does perform an action on the message in the mail store when it is sent? I previously thought you were advocating for a model where these can be completely separate and so this is not possible. Could you please clarify?

I think we've got various issues conflated a bit over these discussions, so I'll clarify what I think are the separate questions:

How, if at all, are "future release" messages (that have yet to be released) marked over the API? Is there a change in the state when they are released? I agree this may not correspond exactly with whether a message can be unsent, especially for internal corporate mail systems, so a related question is: how, if at all, are messages marked that can be unsent? (This is potentially a tristate: can (almost) definitely unsend, can definitely not unsend, may be able to unsend).

I think if we can agree on answers to these questions, the rest will fall out fairly easily.

3. I view "submit" and "unsend" as MTA actions that should not be
confused or conflated with mail store operations. I'm opposed to
protocol designs where a message move, delete or flag changes triggers
MTA actions as a side-effect.
Instead, I propose JMAP have explicit "submit" and "unsend" commands that first perform the MTA action but can
also trigger mail store actions (like move message or flag change) if the MTA action succeeds.

Yes, this is a perfectly fine approach; I'm not opposed to adding explicit sendMessages/unsendMessages calls. If the call can optionally set which mailbox(es)/keywords to set upon successful send, then this is functionally equivalent.

My proposal is to have future release sent messages tagged with their
future release date. The MUA can create a virtual folder for future
release messages with a future date. Whether the server caches a count
for the messages in that virtual folder is a server design optimization
choice. If enough clients request that count that it helps server
scalability to cache that count, then servers will cache that count. The
count of future release messages is thus not relevant to the issue under
debate.

What's relevant is how this count is exposed over the API. If there is a mailbox, then the synchronisation of mailbox objects will ensure the client is "pushed" the count; because count changes are common and clients need to know them to present the most common UI paradigm for mail, synchronisation of mailbox counts is optimised for in the JMAP protocol.

One proposal that might satisfy everyone: an "outbox" or "futurerelease" mailbox role is added (this is the IMAP SPECIAL-USE representation in JMAP). Servers can optionally have a mailbox with this role; if it does, clients SHOULD place future-release messages in here, but like "sent" can put the message in any mailbox(es). Servers that have this mailbox MUST move messages from this mailbox to the sent mailbox at future release time (which may just be based upon the future-release date, or may be actually based on releasing it to the mail queue).

Neil.
--_----------=_149379824333618510-- From nobody Wed May 3 09:44:19 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A5B129442 for ; Wed, 3 May 2017 09:44:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 rZZaYdDB7yaf for ; Wed, 3 May 2017 09:44:15 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628EB129408 for ; Wed, 3 May 2017 09:41:52 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id c45so142264970qtb.1 for ; Wed, 03 May 2017 09:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2UqtrM3YQdv9PiprgqpQaHhTGD3cNBHT5ImEJ1OgWBg=; b=pGGMnzDtfXbmlfoomkFNDMUOrP0O9rIG7623q+UvJTEdTbdGSmnrcEO56JvTXhyrej nLYEew8Ios+wuF3/0lmOl/l20hOAUk1xVY5EpB6UH1ar0IlCWFElU7ixdcOVtWOOLfKi IjBrqYoSvlquUY/q4hDtJ2pYGjU0u0jC5Mb00mC+jVZjuC1Gv7WdnzZb+yc2yK7Oop8f 6syx4Pe+NaS1bsDiv6S7YrgJFDxPavVPVVA1xgI1ZunV0YLAkgtfb/WpJPNMzbLbOCKI 5rCDh2rvpbWy7Yx39PUt7y8OF2EGxutHW2cHJZyzb27peh9MGbn4MUq3xQhnjuaoAnvD Zuiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2UqtrM3YQdv9PiprgqpQaHhTGD3cNBHT5ImEJ1OgWBg=; b=qM2dlVYYmRlnFtnTEiiOEUcb6CQBok76Wt6WvG/LIc4/5cDBhyuOtml7Nq8noQtnTF zNi4DU6f/XQfpfWWB9F4KbSRxe5O8TE4A1ARvRxDQFUt4nvVRPCUfn/SMd9QfYB+bbai 66d8S9Y5utwnFNErRb8VtZvQ605AKU/NYefQAm9GpE0QWFy56bqkizyc9psv3bs0i1Js NOv3jirneKH2iGyQShXw6WMBzelPNwlI8Gw6cu/mOjlH+duTtItwVDaICMzJ0qmEhuYC 5l0G0C/oxvfaZpwzl3VFCqxZiQQ9fT+LOf/Dd8VxOVTPCNKBLbqMgEWghdV0FYZ6Tn4U aKPA== X-Gm-Message-State: AN3rC/7/CF6JLbHL2+8CJAr+MKBi50BbYHulh8JWvjWvk+ReN3YRPlzY hTqrogHOkATy7g== X-Received: by 10.237.42.29 with SMTP id c29mr35327061qtd.113.1493829711530; Wed, 03 May 2017 09:41:51 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id d9sm17038359qte.0.2017.05.03.09.41.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 09:41:50 -0700 (PDT) From: Ted Lemon Message-Id: <40BE5694-03AB-446F-B22A-6BFE2C6FA9E8@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_228A2FBF-4CE5-49CF-B592-0E3CDA1ED1C6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 3 May 2017 12:41:49 -0400 In-Reply-To: <1493798243.3361851.964066360.38B8043E@webmail.messagingengine.com> Cc: Chris Newman , jmap@ietf.org To: Neil Jenkins References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> <1493358386.1136069.958999408.285D03F1@webmail.messagingengine.com> <1493798243.3361851.964066360.38B8043E@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:44:17 -0000 --Apple-Mail=_228A2FBF-4CE5-49CF-B592-0E3CDA1ED1C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2017, at 3:57 AM, Neil Jenkins wrote: > I agree, although I don't think the client-side outbox is particularly = relevant to this discussion, as it should not affect the API design. I'm = sorry I brought this up as it side-tracked the discussion somewhat. My = main point was that many existing systems assign submitted "future = release" messages to a separate mailbox on the server, and clients = present them to the user distinctly to those that have been released. The problem with a client-side outbox is not that it affects API design, = but that it creates bad UX. Any state that is not synchronized produces = surprising results: I can see somethings in one MUA that I use, but not = in another. It may be that the problem being solved here needs to be solved in a way = that doesn't use the outbox as a queue, but I felt the need to reiterate = this point, which I have made before: having different outboxes on = different clients is a bad idea. If the submission mechanism winds up = requiring an un-synchronized client-side outbox, either explicitly or = implicitly, we have made a serious mistake. > One proposal that might satisfy everyone: an "outbox" or = "futurerelease" mailbox role is added (this is the IMAP SPECIAL-USE = representation in JMAP). Servers can optionally have a mailbox with this = role; if it does, clients SHOULD place future-release messages in here, = but like "sent" can put the message in any mailbox(es). Servers that = have this mailbox MUST move messages from this mailbox to the sent = mailbox at future release time (which may just be based upon the = future-release date, or may be actually based on releasing it to the = mail queue). This presumes that the semantics of the "sent" mailbox are that messages = that have been queued but not yet left the local queue go in "sent," not = in "outbox" or "futurerelease." That's probably correct, but it = doesn't quite match the semantics implied by the name "sent." I realize that both of these observations are a bit nit-picky, but I = felt a bit of unease with both of the above quotes, so I wanted to try = to figure out and express what was behind it. --Apple-Mail=_228A2FBF-4CE5-49CF-B592-0E3CDA1ED1C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On May 3, 2017, at 3:57 AM, Neil Jenkins <neilj@fastmail.com> = wrote:
I = agree, although I don't think the client-side outbox is particularly = relevant to this discussion, as it should not affect the API design. I'm = sorry I brought this up as it side-tracked the discussion somewhat. My = main point was that many existing systems assign submitted "future = release" messages to a separate mailbox on the server, = and clients present them to the user distinctly to those that have been = released.

The problem = with a client-side outbox is not that it affects API design, but that it = creates bad UX.  Any state that is not synchronized produces = surprising results: I can see somethings in one MUA that I use, but not = in another.

It may be that the = problem being solved here needs to be solved in a way that doesn't use = the outbox as a queue, but I felt the need to reiterate this point, = which I have made before: having different outboxes on different clients = is a bad idea.   If the submission mechanism winds up requiring an = un-synchronized client-side outbox, either explicitly or implicitly, we = have made a serious mistake.

One proposal = that might satisfy everyone: an "outbox" or "futurerelease" mailbox role = is added (this is the IMAP SPECIAL-USE representation in JMAP). Servers = can optionally have a mailbox with this = role; if it does, clients SHOULD place future-release messages in here, = but like "sent" can put the message in any = mailbox(es). Servers that have this mailbox MUST move messages from this = mailbox to the sent mailbox at future release time (which may just be = based upon the future-release date, or may be actually based on = releasing it to the mail queue).

This presumes that the semantics of the "sent" = mailbox are that messages that have been queued but not yet left the = local queue go in "sent," not in "outbox" or "futurerelease."   = That's probably correct, but it doesn't quite match the semantics = implied by the name "sent."

I realize = that both of these observations are a bit nit-picky, but I felt a bit of = unease with both of the above quotes, so I wanted to try to figure out = and express what was behind it.

= --Apple-Mail=_228A2FBF-4CE5-49CF-B592-0E3CDA1ED1C6-- From nobody Wed May 3 14:18:12 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC16129576 for ; Wed, 3 May 2017 14:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 b_D1hAZdQNvW for ; Wed, 3 May 2017 14:18:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 EF0C01296C9 for ; Wed, 3 May 2017 14:16:46 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v43LGhGh020117 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 May 2017 21:16:43 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v43LGgcc014492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 May 2017 21:16:42 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v43LGevN008581; Wed, 3 May 2017 21:16:40 GMT Received: from [10.145.239.194] (/10.145.239.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 May 2017 14:16:40 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: jmap@ietf.org Date: Wed, 03 May 2017 14:16:37 -0700 Message-ID: In-Reply-To: <1493798243.3361851.964066360.38B8043E@webmail.messagingengine.com> References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> <1493358386.1136069.958999408.285D03F1@webmail.messagingengine.com> <1493798243.3361851.964066360.38B8043E@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:18:10 -0000 On 3 May 2017, at 0:57, Neil Jenkins wrote: > On Mon, 1 May 2017, at 09:53 PM, Chris Newman wrote: >> Here's my guess at the root cause: >> * You're trying to mirror a particular client UI model in the mail >> store server design. > I'm trying to ensure that the API exposes the data clients need to > present common UI patterns in an efficient way, while also allowing > the > most flexibility in server implementation. I think we're both aiming > for > the same thing! >> 1. I believe there are four message types involved in this >> discussion:> * draft messages >> * client-side outbox >> * future release RFC 4865 submitted >> * other submitted messages > > I agree, although I don't think the client-side outbox is particularly > relevant to this discussion, as it should not affect the API design. An important factor in protocol/API design is to avoid misleading the consumers. So in this respect the distinction between client-side outbox and server-side future release messages is important. We don't want protocol/API consumers to confuse those two classes of messages because they behave differently when the client is offline. > I'm sorry I brought this up as it side-tracked the discussion > somewhat. My > main point was that many existing systems assign submitted "future > release" messages to a separate mailbox on the *server*, and clients > present them to the user distinctly to those that have been released. > What I misunderstood from your proposal, is that rather than marking > messages that can be recalled/cannot be recalled, you propose a > client just look at the "release date" annotation instead. Although > you also say this: >> Actually, my proposal makes this server design approach >> simpler. There's> just an internal flag in the sent folder to >> indicate if the >> message has> been passed forward. The mail queue daemon that operates >> on the mail >> store sent folder, can transfer the message to the next hop MTA and >> set> that flag at the future release time. No need to move the >> message >> between folders. > > So the mail queue daemon *does* perform an action on the message in > the > mail store when it is sent? I previously thought you were advocating > for > a model where these can be completely separate and so this is not > possible. Could you please clarify? I advocate an implementation model where the mail queue and mail store can be separate in the server implementation. I accept that some server implementations may choose not to do this and the protocol design shouldn't constrain potentially reasonable implementation choices. In the quote above, I was explaining one way a server implementation that mixes mail queue and mail store could work with the protocol model I proposed. > I think we've got various issues conflated a bit over these > discussions, > so I'll clarify what I think are the separate questions: > How, if at all, are "future release" messages (that have yet to be > released) marked over the API? Is there a change in the state when > they > are released? I agree this may not correspond exactly with whether a > message can be unsent, especially for internal corporate mail systems, > so a related question is: how, if at all, are messages marked that can > be unsent? (This is potentially a tristate: can (almost) definitely > unsend, can definitely not unsend, may be able to unsend). > I think if we can agree on answers to these questions, the rest will > fall out fairly easily. I prefer a protocol model where it is possible for the client to easily identify "future release date is in the future" messages and to apply an "unsend" action to those messages. I further believe the model shouldn't limit the "unsend" action so it can only be used with that set of messages. And I'd prefer a model where there is no explicit state change in the mail store when a "future release" message is released as that keeps the mail queue and mail store components independent. I'm ok if the base JMAP spec requires implementation of future release and unsend for future release messages. I'd prefer to leave details about message tracking (including whether a message can unsent) and unsend for other messages to a JMAP extension. Things get complicated for the other cases. First, it's actually a four state problem: "future release in the future", "unsend not possible", "unsend maybe possible", "no information about whether unsend is possible". And there's the question of whether tracking is an action (as it is for RFC 3887), or we require an MTA to mail store notification path for all messages to indicate whether a sent message can be unsent. The latter probably results in a better UI but I think it's too much to require in the JMAP base spec if we want JMAP to deploy quickly. >> 3. I view "submit" and "unsend" as MTA actions that should not be >> confused or conflated with mail store operations. I'm opposed to >> protocol designs where a message move, delete or flag changes >> triggers> MTA actions as a side-effect. >> Instead, I propose JMAP have explicit "submit" and "unsend" commands >> that first perform the MTA action but can> also trigger mail store >> actions (like move message or flag change) if >> the MTA action succeeds. > Yes, this is a perfectly fine approach; I'm not opposed to adding > explicit sendMessages/unsendMessages calls. If the call can optionally > set which mailbox(es)/keywords to set upon successful send, then this > is > functionally equivalent. Great, we have an approach we both support. >> My proposal is to have future release sent messages tagged with >> their> future release date. The MUA can create a virtual folder for >> future >> release messages with a future date. Whether the server caches a >> count> for the messages in that virtual folder is a server design >> optimization> choice. If enough clients request that count that it >> helps server >> scalability to cache that count, then servers will cache that >> count. The> count of future release messages is thus not relevant to >> the >> issue under> debate. > > What's relevant is how this count is exposed over the API. If there > is a mailbox, then the synchronisation of mailbox objects will ensure > the client is "pushed" the count; because count changes are common > and clients need to know them to present the most common UI paradigm > for mail, synchronisation of mailbox counts is optimised for in the > JMAP protocol. Virtual/smart mailboxes are a common mail UI feature. As a mail user, I'd like my virtual mailboxes to look the same in different mail clients to the extent possible. So the way to get more consistent behavior is to have a server-side-virtual mailbox model. I'd very much like JMAP to have the ability to create a virtual/smart mailbox that behaves like a regular mailbox in most ways (including optimized counts). That's a significant value-add that could be implemented in the JMAP layer. IMAP has primitives that can help (like RFC 5466, and RFC 5267) but nothing that enables smart mailbox behavior consistency across clients. > One proposal that might satisfy everyone: an "outbox" or > "futurerelease" > mailbox role is added (this is the IMAP SPECIAL-USE representation in > JMAP). Servers can *optionally* have a mailbox with this role; if it > does, clients SHOULD place future-release messages in here, but like > "sent" *can* put the message in any mailbox(es). Servers that have > this > mailbox MUST move messages from this mailbox to the sent mailbox at > future release time (which may just be based upon the future-release > date, or may be actually based on releasing it to the mail queue). This is something I could implement easily as long as there's no requirement that the mail store verify the message was actually released from the mail queue at the future release time. But I'm not sure it's a good design as it raises some issues... Messages in the futurerelease mailbox have been submitted/sent, so should that mailbox also have the \Sent special use? And if we then end up with more than one mailbox with \Sent special use, will mail clients need code to prefer the one without the "futurerelease" special use for sent messages that aren't future release? I think a futurerelease virtual mailbox (based on the sent mailbox) is a cleaner way to do this (and optionally a sentandreleased virtual mailbox for clients desiring that). - Chris From nobody Fri May 5 01:00:28 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402C612943D for ; Fri, 5 May 2017 01:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 j0WInw2HsWOW for ; Fri, 5 May 2017 01:00:23 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.95.39]) by ietfa.amsl.com (Postfix) with ESMTP id E9670126CF6 for ; Fri, 5 May 2017 01:00:21 -0700 (PDT) Received: From 202.157.83.50[202.157.83.50] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20170505/13/73864.06540176153(1493971218158); Fri, 5 May 2017 08:00:18 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 77870.53970563477(1493971216193); Fri, 5 May 2017 08:00:16 +0000 Date: Fri, 5 May 2017 13:30:16 +0530 (IST) From: ajay@xgenplus.com To: `chris newman` , `neil jenkins` Cc: jmap@ietf.org Message-ID: <1858642791.84031493971216190.JavaMail.root@power0.dil.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8401_549535213.1493971216188" XMessage-Id: XGenPlusMessageID:14939712161505220 X-Mailer: XGen Plus INSTANT MESSAGING SYSTEM X-ScheduledMail: FALSE X-ScheduledDate: 05/05/2017 08:00:00 X-Followup: false X-FollowupTotal: 0 X-PersonalisedTag: FALSE X-Signature: FALSE X-ReplyAwaited: FALSE X-SendType: REPLYALL X-SentFromIP: 202.157.76.122 X-SentFromDate: 05/05/2017 08:00:00 X-BrowserType: Google Chrome X-Priority: 3 X-Right: X_XGEN_DLP: NO X_Xgen_Delivery_Report: no Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 08:00:27 -0000 ------=_Part_8401_549535213.1493971216188 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. Sorry for my late comments. But if it is useful, we have been offeri= ng scheduled email ( future delivery ) via webmail since last 15 years now. While sending email user can set date and time of the delivery of this emai= l. In our system we have time for every email to be delivered. So if it is = not scheduled , It`s automatic set as NOW and otherwise user defined time. No further action is required by user. We have a server level Outbox ( not user level ) so that all the scheduled = email can be seen by Queue processor without worrying about each users outb= ox. Note: This has also impact on storage quota , user mail quota limits, expir= y etc. Recurring email on fixed date and time. Like birthday reminders, gre= etings etc. Hope it helps. Thanks Ajay Data =20 =20 =20 From: "Chris Newman" MailId : [68715573]To: "Neil Jenkins" Cc: jmap@ietf.= orgSubject: Re: [Jmap] simpler future release & unsend without outbox (w= as Re: Best vs Good enough - adoption of JMAP)Date: 04 May 2017 02:48:30 AM= On 3 May 2017, at 0:57, Neil Jenkins wrote:> On Mon, 1 May 2017, at 09:5= 3 PM, Chris Newman wrote:>> Here`s my guess at the root cause:>> * You`re t= rying to mirror a particular client UI model in the mail>> store server des= ign.> I`m trying to ensure that the API exposes the data clients need to> = present common UI patterns in an efficient way, while also allowing > the= > most flexibility in server implementation. I think we`re both aiming > = for> the same thing!>> 1. I believe there are four message types involved = in this >> discussion:> * draft messages>> * client-side outbox>> * future = release RFC 4865 submitted>> * other submitted messages>> I agree, althoug= h I don`t think the client-side outbox is particularly> relevant to this d= iscussion, as it should not affect the API design.An important factor in pr= otocol/API design is to avoid misleading the consumers. So in this respect = the distinction between client-side outbox and server-side future release m= essages is important. We don`t want protocol/API consumers to confuse those= two classes of messages because they behave differently when the client is= offline.> I`m sorry I brought this up as it side-tracked the discussion >= somewhat. My> main point was that many existing systems assign submitted= "future> release" messages to a separate mailbox on the *server*, and cli= ents> present them to the user distinctly to those that have been released= > What I misunderstood from your proposal, is that rather than marking> = messages that can be recalled/cannot be recalled, you propose a> client ju= st look at the "release date" annotation instead. Although> you also say t= his:>> Actually, my proposal makes this server design approach>> simpler. T= here`s> just an internal flag in the sent folder to >> indicate if the>> me= ssage has> been passed forward. The mail queue daemon that operates >> on t= he mail>> store sent folder, can transfer the message to the next hop MTA a= nd>> set> that flag at the future release time. No need to move the >> mess= age>> between folders.>> So the mail queue daemon *does* perform an action= on the message in > the> mail store when it is sent? I previously though= t you were advocating > for> a model where these can be completely separa= te and so this is not> possible. Could you please clarify?I advocate an im= plementation model where the mail queue and mail store can be separate in t= he server implementation. I accept that some server implementations may cho= ose not to do this and the protocol design shouldn`t constrain potentially = reasonable implementation choices. In the quote above, I was explaining one= way a server implementation that mixes mail queue and mail store could wor= k with the protocol model I proposed.> I think we`ve got various issues co= nflated a bit over these > discussions,> so I`ll clarify what I think are= the separate questions:> How, if at all, are "future release" messages (t= hat have yet to be> released) marked over the API? Is there a change in th= e state when > they> are released? I agree this may not correspond exactl= y with whether a> message can be unsent, especially for internal corporate= mail systems,> so a related question is: how, if at all, are messages mar= ked that can> be unsent? (This is potentially a tristate: can (almost) def= initely> unsend, can definitely not unsend, may be able to unsend).> I th= ink if we can agree on answers to these questions, the rest will> fall out= fairly easily.I prefer a protocol model where it is possible for the clien= t to easily identify "future release date is in the future" messages and to= apply an "unsend" action to those messages. I further believe the model sh= ouldn`t limit the "unsend" action so it can only be used with that set of m= essages. And I`d prefer a model where there is no explicit state change in = the mail store when a "future release" message is released as that keeps th= e mail queue and mail store components independent.I`m ok if the base JMAP = spec requires implementation of future release and unsend for future releas= e messages. I`d prefer to leave details about message tracking (including w= hether a message can unsent) and unsend for other messages to a JMAP extens= ion. Things get complicated for the other cases. First, it`s actually a fou= r state problem: "future release in the future", "unsend not possible", "un= send maybe possible", "no information about whether unsend is possible". An= d there`s the question of whether tracking is an action (as it is for RFC 3= 887), or we require an MTA to mail store notification path for all messages= to indicate whether a sent message can be unsent. The latter probably resu= lts in a better UI but I think it`s too much to require in the JMAP base sp= ec if we want JMAP to deploy quickly.>> 3. I view "submit" and "unsend" as = MTA actions that should not be>> confused or conflated with mail store oper= ations. I`m opposed to>> protocol designs where a message move, delete or f= lag changes >> triggers> MTA actions as a side-effect.>> Instead, I propose= JMAP have explicit "submit" and "unsend" commands>> that first perform the= MTA action but can> also trigger mail store >> actions (like move message = or flag change) if>> the MTA action succeeds.> Yes, this is a perfectly fi= ne approach I`m not opposed to adding> explicit sendMessages/unsendMessage= s calls. If the call can optionally> set which mailbox(es)/keywords to set= upon successful send, then this > is> functionally equivalent.Great, we = have an approach we both support.>> My proposal is to have future release s= ent messages tagged with >> their> future release date. The MUA can create = a virtual folder for >> future>> release messages with a future date. Wheth= er the server caches a >> count> for the messages in that virtual folder is= a server design>> optimization> choice. If enough clients request that cou= nt that it >> helps server>> scalability to cache that count, then servers = will cache that>> count. The> count of future release messages is thus not = relevant to >> the>> issue under> debate.>> What`s relevant is how this co= unt is exposed over the API. If there> is a mailbox, then the synchronisat= ion of mailbox objects will ensure> the client is "pushed" the count becau= se count changes are common> and clients need to know them to present the = most common UI paradigm> for mail, synchronisation of mailbox counts is op= timised for in the> JMAP protocol.Virtual/smart mailboxes are a common mai= l UI feature. As a mail user, I`d like my virtual mailboxes to look the sam= e in different mail clients to the extent possible. So the way to get more = consistent behavior is to have a server-side-virtual mailbox model. I`d ver= y much like JMAP to have the ability to create a virtual/smart mailbox that= behaves like a regular mailbox in most ways (including optimized counts). = That`s a significant value-add that could be implemented in the JMAP layer.= IMAP has primitives that can help (like RFC 5466, and RFC 5267) but nothin= g that enables smart mailbox behavior consistency across clients.> One pro= posal that might satisfy everyone: an "outbox" or > "futurerelease"> mail= box role is added (this is the IMAP SPECIAL-USE representation in> JMAP). = Servers can *optionally* have a mailbox with this role if it> does, client= s SHOULD place future-release messages in here, but like> "sent" *can* put= the message in any mailbox(es). Servers that have > this> mailbox MUST m= ove messages from this mailbox to the sent mailbox at> future release time= (which may just be based upon the future-release> date, or may be actuall= y based on releasing it to the mail queue).This is something I could implem= ent easily as long as there`s no requirement that the mail store verify the= message was actually released from the mail queue at the future release ti= me. But I`m not sure it`s a good design as it raises some issues... Message= s in the futurerelease mailbox have been submitted/sent, so should that mai= lbox also have the \Sent special use? And if we then end up with more than = one mailbox with \Sent special use, will mail clients need code to prefer t= he one without the "futurerelease" special use for sent messages that aren`= t future release?I think a futurerelease virtual mailbox (based on the sent= mailbox) is a cleaner way to do this (and optionally a sentandreleased vir= tual mailbox for clients desiring that). - Chris___________________________= ____________________Jmap mailing listJmap@ietf.orghttps://www.ietf.org/mail= man/listinfo/jmap.Do not Remove:[HID]20170504024829484[-HID] [XGENFOOTER] [-XGENFOOTER]=00 ------=_Part_8401_549535213.1493971216188 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello. Sorry for my late comments. But if it is useful, we have been off= ering scheduled email ( future delivery ) via webmail since last 15 years n= ow.

While sending email user can set date and time of the delivery of this e= mail. In our system we have time for every email to be delivered. So if it = is not scheduled , It`s automatic set as NOW and otherwise user defined tim= e.

No further action is required by user.

We have a server level Outbox ( not user level ) so that all the schedul= ed email can be seen by Queue processor without worrying about each users o= utbox.

Note: This has also impact on storage quota , user mail quota limits, ex= piry etc. Recurring email on fixed date and time. Like birthday reminders, = greetings etc.

Hope it helps.

Thanks

Ajay Data
 
 
 
From: "Chris Newman" <chris.newman@oracle.com>=   Mail= Id : [68715573]
To: "Neil Jenkins" <neilj@f= astmail.com>
Cc: jmap@ietf.org
Subjec= t: Re: [Jmap] simpler future release & unsend without outbox (= was Re: Best vs Good enough - adoption of JMAP)
Date:= 04 May 2017 02:48:30 AM

On 3 May 2017, at 0:57, Neil Jenkins = wrote:
>  On Mon, 1 May 2017, at 09:53 PM, Chris Newman wrote:=
>> Here`s my guess at the root cause:
>> * You`re tr= ying to mirror a particular client UI model in the mail
>> store= server design.
>  I`m trying to ensure that the API exposes t= he data clients need to
>  present common UI patterns in an ef= ficient way, while also allowing
>  the
>  most = flexibility in server implementation. I think we`re both aiming
>&= nbsp; for
>  the same thing!
>> 1. I believe there = are four message types involved in this
>> discussion:> * dr= aft messages
>> * client-side outbox
>> * future rele= ase RFC 4865 submitted
>> * other submitted messages
>>  I agree, although I don`t think the client-side outbox is pa= rticularly
>  relevant to this discussion, as it should not af= fect the API design.

An important factor in protocol/API design = is to avoid misleading the
consumers. So in this respect the distinct= ion between client-side outbox
and server-side future release message= s is important. We don`t want
protocol/API consumers to confuse those= two classes of messages because
they behave differently when the cli= ent is offline.

>  I`m sorry I brought this up as it sid= e-tracked the discussion
>  somewhat. My
>  main= point was that many existing systems assign submitted "future
>&nb= sp; release" messages to a separate mailbox on the *server*, and clients>  present them to the user distinctly to those that have been r= eleased.
>  What I misunderstood from your proposal, is that r= ather than marking
>  messages that can be recalled/cannot be = recalled, you propose a
>  client just look at the "release da= te" annotation instead. Although
>  you also say this:
&g= t;> Actually, my proposal makes this server design approach
>>= ; simpler. There`s> just an internal flag in the sent folder to
&g= t;> indicate if the
>> message has> been passed forward. T= he mail queue daemon that operates
>> on the mail
>>= store sent folder, can transfer the message to the next hop MTA and
&= gt;> set> that flag at the future release time. No need to move the <= br />>> message
>> between folders.
>
>&nb= sp; So the mail queue daemon *does* perform an action on the message in >  the
>  mail store when it is sent? I previously = thought you were advocating
>  for
>  a model wh= ere these can be completely separate and so this is not
>  pos= sible. Could you please clarify?

I advocate an implementation mo= del where the mail queue and mail store
can be separate in the server= implementation. I accept that some server
implementations may choose= not to do this and the protocol design
shouldn`t constrain potential= ly reasonable implementation choices. In
the quote above, I was expla= ining one way a server implementation that
mixes mail queue and mail = store could work with the protocol model I
proposed.

>&= nbsp; I think we`ve got various issues conflated a bit over these
>= ;  discussions,
>  so I`ll clarify what I think are the s= eparate questions:
>  How, if at all, are "future release" mes= sages (that have yet to be
>  released) marked over the API? I= s there a change in the state when
>  they
>  ar= e released? I agree this may not correspond exactly with whether a
>= ;  message can be unsent, especially for internal corporate mail syste= ms,
>  so a related question is: how, if at all, are messages = marked that can
>  be unsent? (This is potentially a tristate:= can (almost) definitely
>  unsend, can definitely not unsend,= may be able to unsend).
>  I think if we can agree on answers= to these questions, the rest will
>  fall out fairly easily.<= br />
I prefer a protocol model where it is possible for the client to= easily
identify "future release date is in the future" messages and = to apply an
"unsend" action to those messages. I further believe the = model shouldn`t
limit the "unsend" action so it can only be used with= that set of
messages. And I`d prefer a model where there is no expli= cit state change
in the mail store when a "future release" message is= released as that
keeps the mail queue and mail store components inde= pendent.

I`m ok if the base JMAP spec requires implementation of= future release
and unsend for future release messages. I`d prefer to= leave details
about message tracking (including whether a message ca= n unsent) and
unsend for other messages to a JMAP extension. Things g= et complicated
for the other cases. First, it`s actually a four state= problem: "future
release in the future", "unsend not possible", "uns= end maybe possible",
"no information about whether unsend is possible= ". And there`s the
question of whether tracking is an action (as it i= s for RFC 3887), or we
require an MTA to mail store notification path= for all messages to
indicate whether a sent message can be unsent. T= he latter probably
results in a better UI but I think it`s too much t= o require in the JMAP
base spec if we want JMAP to deploy quickly.
>> 3. I view "submit" and "unsend" as MTA actions that shoul= d not be
>> confused or conflated with mail store operations. I`= m opposed to
>> protocol designs where a message move, delete or= flag changes
>> triggers> MTA actions as a side-effect.
>> Instead, I propose JMAP have explicit "submit" and "unsend" comm= ands
>> that first perform the MTA action but can> also trigg= er mail store
>> actions (like move message or flag change) if<= br />>> the MTA action succeeds.
>  Yes, this is a perfe= ctly fine approach; I`m not opposed to adding
>  explicit send= Messages/unsendMessages calls. If the call can optionally
>  s= et which mailbox(es)/keywords to set upon successful send, then this
= >  is
>  functionally equivalent.

Great, we= have an approach we both support.

>> My proposal is to ha= ve future release sent messages tagged with
>> their> future= release date. The MUA can create a virtual folder for
>> futur= e
>> release messages with a future date. Whether the server cac= hes a
>> count> for the messages in that virtual folder is a= server design
>> optimization> choice. If enough clients req= uest that count that it
>> helps server
>> scalabili= ty to cache that count, then servers will cache that
>> count. T= he> count of future release messages is thus not relevant to
>&= gt; the
>> issue under> debate.
>
>  Wha= t`s relevant is how this count is exposed over the API. If there
>&= nbsp; is a mailbox, then the synchronisation of mailbox objects will ensure=
>  the client is "pushed" the count; because count changes ar= e common
>  and clients need to know them to present the most = common UI paradigm
>  for mail, synchronisation of mailbox cou= nts is optimised for in the
>  JMAP protocol.

Virtu= al/smart mailboxes are a common mail UI feature. As a mail user,
I`d = like my virtual mailboxes to look the same in different mail clients
= to the extent possible. So the way to get more consistent behavior is to have a server-side-virtual mailbox model. I`d very much like JMAP to have the ability to create a virtual/smart mailbox that behaves like a =
regular mailbox in most ways (including optimized counts). That`s a <= br />significant value-add that could be implemented in the JMAP layer. IMA= P
has primitives that can help (like RFC 5466, and RFC 5267) but noth= ing
that enables smart mailbox behavior consistency across clients.
>  One proposal that might satisfy everyone: an "outbox" = or
>  "futurerelease"
>  mailbox role is added (= this is the IMAP SPECIAL-USE representation in
>  JMAP). Serve= rs can *optionally* have a mailbox with this role; if it
>  do= es, clients SHOULD place future-release messages in here, but like
>= ;  "sent" *can* put the message in any mailbox(es). Servers that have =
>  this
>  mailbox MUST move messages from this = mailbox to the sent mailbox at
>  future release time (which m= ay just be based upon the future-release
>  date, or may be ac= tually based on releasing it to the mail queue).

This is somethi= ng I could implement easily as long as there`s no
requirement that th= e mail store verify the message was actually released
from the mail q= ueue at the future release time. But I`m not sure it`s a
good design = as it raises some issues... Messages in the futurerelease
mailbox hav= e been submitted/sent, so should that mailbox also have the
\Sent spe= cial use? And if we then end up with more than one mailbox with
\Sent= special use, will mail clients need code to prefer the one without
t= he "futurerelease" special use for sent messages that aren`t future
r= elease?

I think a futurerelease virtual mailbox (based on the se= nt mailbox) is a
cleaner way to do this (and optionally a sentandrele= ased virtual mailbox
for clients desiring that).

- Chris<= br />
_______________________________________________
Jmap mailin= g list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap.

Do not Remove:
[HID]20170504024829484[-HID]
=
[XGENFOOTER]

= [-XGENFOOTER]
=00 ------=_Part_8401_549535213.1493971216188-- From xn--l1b0cxc@xn--c2bd1gb.xn--h2brj9c Thu May 4 11:39:46 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78991200C1 for ; Thu, 4 May 2017 11:39:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uGz0FJ3ntvHW for ; Thu, 4 May 2017 11:39:40 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.95.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5769D129431 for ; Thu, 4 May 2017 11:39:34 -0700 (PDT) Received: From 202.157.83.50[202.157.83.50] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20170505/00/10805.028291977314(1493923171174); Thu, 4 May 2017 18:39:31 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 2581.1560461859062(1493923169547); Thu, 4 May 2017 18:39:29 +0000 Received: From[856a035bc4b07f9f3840e67d84bff8b5] [202.157.76.62] with SMTP id 71415.42578156965(1493923138323); Thu, 4 May 2017 18:38:58 +0000 Date: Fri, 5 May 2017 00:08:58 +0530 From: To: chris.newman@oracle.com Cc: neilj@fastmail.com, jmap@ietf.org Message-ID: X-SentFromIP: 192.168.0.102 X_Xgen_Device_Id: BE2B7A71-BDCD-47C7-9F46-A10BB9D168C7 X-SentFromDate: 2017-05-04 18:38:58 +0000 X-Mailer: XgenPlus IOS Mail APP X_Xgen_Delivery_Report: YES X-Priority: 3 X-BrowserType: iPhone 10.3.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="590b7542_6b8b4567_1d6" Archived-At: X-Mailman-Approved-At: Fri, 05 May 2017 02:59:03 -0700 Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 02:24:12 -0000 --590b7542_6b8b4567_1d6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello. Sorry for my late comments. But if it is useful, we have been offering scheduled email ( future delivery ) via webmail since last 15 years now. While sending email user can set date and time of the delivery of this email. In our system we have time for every email to be delivered. So if it is not scheduled , It's automatic set as NOW and otherwise user defined time. No further action is required by user. We have a server level Outbox ( not user level ) so that all the scheduled email can be seen by Queue processor without worrying about each users outbox. This has also impact on storage quota , user mail quota limits, expiry etc. Recurring email on fixed date and time. Like birthday reminders, greetings etc. Hope it helps. Thanks On 04-May-2017, 02:46:37 Chris Newman 'chris.newman@oracle.com' wrote: From: Chris Newman To: Neil Jenkins Cc: jmap@ietf.org Subject: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) Date: 4 May 2017 at 02:46:37 IST On 3 May 2017, at 0:57, Neil Jenkins wrote: > On Mon, 1 May 2017, at 09:53 PM, Chris Newman wrote: > > > Here's my guess at the root cause: > > > > * You're trying to mirror a particular client UI model in the mail > > > > store server design. > > I'm trying to ensure that the API exposes the data clients need to > > present common UI patterns in an efficient way, while also allowing > > the > > most flexibility in server implementation. I think we're both aiming > > for > > the same thing! > > > 1. I believe there are four message types involved in this > > > > discussion:> * draft messages > > > > * client-side outbox > > > > * future release RFC 4865 submitted > > > > * other submitted messages > > > > I agree, although I don't think the client-side outbox is particularly > > relevant to this discussion, as it should not affect the API design. An important factor in protocol/API design is to avoid misleading the consumers. So in this respect the distinction between client-side outbox and server-side future release messages is important. We don't want protocol/API consumers to confuse those two classes of messages because they behave differently when the client is offline. > I'm sorry I brought this up as it side-tracked the discussion > > somewhat. My > > main point was that many existing systems assign submitted "future > > release" messages to a separate mailbox on the *server*, and clients > > present them to the user distinctly to those that have been released. > > What I misunderstood from your proposal, is that rather than marking > > messages that can be recalled/cannot be recalled, you propose a > > client just look at the "release date" annotation instead. Although > > you also say this: > > > Actually, my proposal makes this server design approach > > > > simpler. There's> just an internal flag in the sent folder to > > > > indicate if the > > > > message has> been passed forward. The mail queue daemon that operates > > > > on the mail > > > > store sent folder, can transfer the message to the next hop MTA and > > > > set> that flag at the future release time. No need to move the > > > > message > > > > between folders. > > > > So the mail queue daemon *does* perform an action on the message in > > the > > mail store when it is sent? I previously thought you were advocating > > for > > a model where these can be completely separate and so this is not > > possible. Could you please clarify? I advocate an implementation model where the mail queue and mail store can be separate in the server implementation. I accept that some server implementations may choose not to do this and the protocol design shouldn't constrain potentially reasonable implementation choices. In the quote above, I was explaining one way a server implementation that mixes mail queue and mail store could work with the protocol model I proposed. > I think we've got various issues conflated a bit over these > > discussions, > > so I'll clarify what I think are the separate questions: > > How, if at all, are "future release" messages (that have yet to be > > released) marked over the API? Is there a change in the state when > > they > > are released? I agree this may not correspond exactly with whether a > > message can be unsent, especially for internal corporate mail systems, > > so a related question is: how, if at all, are messages marked that can > > be unsent? (This is potentially a tristate: can (almost) definitely > > unsend, can definitely not unsend, may be able to unsend). > > I think if we can agree on answers to these questions, the rest will > > fall out fairly easily. I prefer a protocol model where it is possible for the client to easily identify "future release date is in the future" messages and to apply an "unsend" action to those messages. I further believe the model shouldn't limit the "unsend" action so it can only be used with that set of messages. And I'd prefer a model where there is no explicit state change in the mail store when a "future release" message is released as that keeps the mail queue and mail store components independent. I'm ok if the base JMAP spec requires implementation of future release and unsend for future release messages. I'd prefer to leave details about message tracking (including whether a message can unsent) and unsend for other messages to a JMAP extension. Things get complicated for the other cases. First, it's actually a four state problem: "future release in the future", "unsend not possible", "unsend maybe possible", "no information about whether unsend is possible". And there's the question of whether tracking is an action (as it is for RFC 3887), or we require an MTA to mail store notification path for all messages to indicate whether a sent message can be unsent. The latter probably results in a better UI but I think it's too much to require in the JMAP base spec if we want JMAP to deploy quickly. > > > 3. I view "submit" and "unsend" as MTA actions that should not be > > > > confused or conflated with mail store operations. I'm opposed to > > > > protocol designs where a message move, delete or flag changes > > > > triggers> MTA actions as a side-effect. > > > > Instead, I propose JMAP have explicit "submit" and "unsend" commands > > > > that first perform the MTA action but can> also trigger mail store > > > > actions (like move message or flag change) if > > > > the MTA action succeeds. > > Yes, this is a perfectly fine approach; I'm not opposed to adding > > explicit sendMessages/unsendMessages calls. If the call can optionally > > set which mailbox(es)/keywords to set upon successful send, then this > > is > > functionally equivalent. Great, we have an approach we both support. > > > My proposal is to have future release sent messages tagged with > > > > their> future release date. The MUA can create a virtual folder for > > > > future > > > > release messages with a future date. Whether the server caches a > > > > count> for the messages in that virtual folder is a server design > > > > optimization> choice. If enough clients request that count that it > > > > helps server > > > > scalability to cache that count, then servers will cache that > > > > count. The> count of future release messages is thus not relevant to > > > > the > > > > issue under> debate. > > > > What's relevant is how this count is exposed over the API. If there > > is a mailbox, then the synchronisation of mailbox objects will ensure > > the client is "pushed" the count; because count changes are common > > and clients need to know them to present the most common UI paradigm > > for mail, synchronisation of mailbox counts is optimised for in the > > JMAP protocol. Virtual/smart mailboxes are a common mail UI feature. As a mail user, I'd like my virtual mailboxes to look the same in different mail clients to the extent possible. So the way to get more consistent behavior is to have a server-side-virtual mailbox model. I'd very much like JMAP to have the ability to create a virtual/smart mailbox that behaves like a regular mailbox in most ways (including optimized counts). That's a significant value-add that could be implemented in the JMAP layer. IMAP has primitives that can help (like RFC 5466, and RFC 5267) but nothing that enables smart mailbox behavior consistency across clients. > One proposal that might satisfy everyone: an "outbox" or > > "futurerelease" > > mailbox role is added (this is the IMAP SPECIAL-USE representation in > > JMAP). Servers can *optionally* have a mailbox with this role; if it > > does, clients SHOULD place future-release messages in here, but like > > "sent" *can* put the message in any mailbox(es). Servers that have > > this > > mailbox MUST move messages from this mailbox to the sent mailbox at > > future release time (which may just be based upon the future-release > > date, or may be actually based on releasing it to the mail queue). This is something I could implement easily as long as there's no requirement that the mail store verify the message was actually released from the mail queue at the future release time. But I'm not sure it's a good design as it raises some issues... Messages in the futurerelease mailbox have been submitted/sent, so should that mailbox also have the \Sent special use? And if we then end up with more than one mailbox with \Sent special use, will mail clients need code to prefer the one without the "futurerelease" special use for sent messages that aren't future release? I think a futurerelease virtual mailbox (based on the sent mailbox) is a cleaner way to do this (and optionally a sentandreleased virtual mailbox for clients desiring that). - Chris _______________________________________________ Jmap mailing list Jmap@ietf.org https://www.ietf.org/mailman/listinfo/jmap --590b7542_6b8b4567_1d6-- From nobody Fri May 5 02:59:13 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15C8127097 for ; Fri, 5 May 2017 00:59:13 -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_FONT_LOW_CONTRAST=0.001, 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 50q7TogMEaKG for ; Fri, 5 May 2017 00:59:09 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.95.37]) by ietfa.amsl.com (Postfix) with ESMTP id E214D126CF6 for ; Fri, 5 May 2017 00:59:06 -0700 (PDT) Received: From 202.157.83.50[202.157.83.50] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20170505/13/66032.50095896106(1493971143259); Fri, 5 May 2017 07:59:03 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 6190.323884067206(1493971141570); Fri, 5 May 2017 07:59:01 +0000 Date: Fri, 5 May 2017 13:29:01 +0530 (IST) From: To: `chris newman` , `neil jenkins` Cc: jmap@ietf.org Message-ID: <1351849391.84011493971141531.JavaMail.root@power0.dil.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8399_1692691600.1493971141529" XMessage-Id: XGenPlusMessageID:14939711412485624 X-Mailer: XGen Plus INSTANT MESSAGING SYSTEM X-ScheduledMail: FALSE X-ScheduledDate: 05/05/2017 07:59:00 X-Followup: false X-FollowupTotal: 0 X-PersonalisedTag: FALSE X-Signature: FALSE X-ReplyAwaited: FALSE X-SendType: REPLYALL X-SentFromIP: 202.157.76.122 X-SentFromDate: 05/05/2017 07:59:00 X-BrowserType: Google Chrome X-Priority: 3 X-Right: X_XGEN_DLP: NO X_Xgen_Delivery_Report: no Archived-At: X-Mailman-Approved-At: Fri, 05 May 2017 02:59:03 -0700 Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 07:59:14 -0000 ------=_Part_8399_1692691600.1493971141529 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. Sorry for my late comments. But if it is useful, we have been offeri= ng scheduled email ( future delivery ) via webmail since last 15 years now. While sending email user can set date and time of the delivery of this emai= l. In our system we have time for every email to be delivered. So if it is = not scheduled , It`s automatic set as NOW and otherwise user defined time. No further action is required by user. We have a server level Outbox ( not user level ) so that all the scheduled = email can be seen by Queue processor without worrying about each users outb= ox. This has also impact on storage quota , user mail quota limits, expiry etc.= Recurring email on fixed date and time. Like birthday reminders, greetings= etc. Hope it helps. Thanks Ajay Data From: "Chris Newman" MailId : [68715573]To: "Neil Jenkins" Cc: jmap@ietf.= orgSubject: Re: [Jmap] simpler future release & unsend without outbox (w= as Re: Best vs Good enough - adoption of JMAP)Date: 04 May 2017 02:48:30 AM= On 3 May 2017, at 0:57, Neil Jenkins wrote:> On Mon, 1 May 2017, at 09:5= 3 PM, Chris Newman wrote:>> Here`s my guess at the root cause:>> * You`re t= rying to mirror a particular client UI model in the mail>> store server des= ign.> I`m trying to ensure that the API exposes the data clients need to> = present common UI patterns in an efficient way, while also allowing > the= > most flexibility in server implementation. I think we`re both aiming > = for> the same thing!>> 1. I believe there are four message types involved = in this >> discussion:> * draft messages>> * client-side outbox>> * future = release RFC 4865 submitted>> * other submitted messages>> I agree, althoug= h I don`t think the client-side outbox is particularly> relevant to this d= iscussion, as it should not affect the API design.An important factor in pr= otocol/API design is to avoid misleading the consumers. So in this respect = the distinction between client-side outbox and server-side future release m= essages is important. We don`t want protocol/API consumers to confuse those= two classes of messages because they behave differently when the client is= offline.> I`m sorry I brought this up as it side-tracked the discussion >= somewhat. My> main point was that many existing systems assign submitted= "future> release" messages to a separate mailbox on the *server*, and cli= ents> present them to the user distinctly to those that have been released= > What I misunderstood from your proposal, is that rather than marking> = messages that can be recalled/cannot be recalled, you propose a> client ju= st look at the "release date" annotation instead. Although> you also say t= his:>> Actually, my proposal makes this server design approach>> simpler. T= here`s> just an internal flag in the sent folder to >> indicate if the>> me= ssage has> been passed forward. The mail queue daemon that operates >> on t= he mail>> store sent folder, can transfer the message to the next hop MTA a= nd>> set> that flag at the future release time. No need to move the >> mess= age>> between folders.>> So the mail queue daemon *does* perform an action= on the message in > the> mail store when it is sent? I previously though= t you were advocating > for> a model where these can be completely separa= te and so this is not> possible. Could you please clarify?I advocate an im= plementation model where the mail queue and mail store can be separate in t= he server implementation. I accept that some server implementations may cho= ose not to do this and the protocol design shouldn`t constrain potentially = reasonable implementation choices. In the quote above, I was explaining one= way a server implementation that mixes mail queue and mail store could wor= k with the protocol model I proposed.> I think we`ve got various issues co= nflated a bit over these > discussions,> so I`ll clarify what I think are= the separate questions:> How, if at all, are "future release" messages (t= hat have yet to be> released) marked over the API? Is there a change in th= e state when > they> are released? I agree this may not correspond exactl= y with whether a> message can be unsent, especially for internal corporate= mail systems,> so a related question is: how, if at all, are messages mar= ked that can> be unsent? (This is potentially a tristate: can (almost) def= initely> unsend, can definitely not unsend, may be able to unsend).> I th= ink if we can agree on answers to these questions, the rest will> fall out= fairly easily.I prefer a protocol model where it is possible for the clien= t to easily identify "future release date is in the future" messages and to= apply an "unsend" action to those messages. I further believe the model sh= ouldn`t limit the "unsend" action so it can only be used with that set of m= essages. And I`d prefer a model where there is no explicit state change in = the mail store when a "future release" message is released as that keeps th= e mail queue and mail store components independent.I`m ok if the base JMAP = spec requires implementation of future release and unsend for future releas= e messages. I`d prefer to leave details about message tracking (including w= hether a message can unsent) and unsend for other messages to a JMAP extens= ion. Things get complicated for the other cases. First, it`s actually a fou= r state problem: "future release in the future", "unsend not possible", "un= send maybe possible", "no information about whether unsend is possible". An= d there`s the question of whether tracking is an action (as it is for RFC 3= 887), or we require an MTA to mail store notification path for all messages= to indicate whether a sent message can be unsent. The latter probably resu= lts in a better UI but I think it`s too much to require in the JMAP base sp= ec if we want JMAP to deploy quickly.>> 3. I view "submit" and "unsend" as = MTA actions that should not be>> confused or conflated with mail store oper= ations. I`m opposed to>> protocol designs where a message move, delete or f= lag changes >> triggers> MTA actions as a side-effect.>> Instead, I propose= JMAP have explicit "submit" and "unsend" commands>> that first perform the= MTA action but can> also trigger mail store >> actions (like move message = or flag change) if>> the MTA action succeeds.> Yes, this is a perfectly fi= ne approach I`m not opposed to adding> explicit sendMessages/unsendMessage= s calls. If the call can optionally> set which mailbox(es)/keywords to set= upon successful send, then this > is> functionally equivalent.Great, we = have an approach we both support.>> My proposal is to have future release s= ent messages tagged with >> their> future release date. The MUA can create = a virtual folder for >> future>> release messages with a future date. Wheth= er the server caches a >> count> for the messages in that virtual folder is= a server design>> optimization> choice. If enough clients request that cou= nt that it >> helps server>> scalability to cache that count, then servers = will cache that>> count. The> count of future release messages is thus not = relevant to >> the>> issue under> debate.>> What`s relevant is how this co= unt is exposed over the API. If there> is a mailbox, then the synchronisat= ion of mailbox objects will ensure> the client is "pushed" the count becau= se count changes are common> and clients need to know them to present the = most common UI paradigm> for mail, synchronisation of mailbox counts is op= timised for in the> JMAP protocol.Virtual/smart mailboxes are a common mai= l UI feature. As a mail user, I`d like my virtual mailboxes to look the sam= e in different mail clients to the extent possible. So the way to get more = consistent behavior is to have a server-side-virtual mailbox model. I`d ver= y much like JMAP to have the ability to create a virtual/smart mailbox that= behaves like a regular mailbox in most ways (including optimized counts). = That`s a significant value-add that could be implemented in the JMAP layer.= IMAP has primitives that can help (like RFC 5466, and RFC 5267) but nothin= g that enables smart mailbox behavior consistency across clients.> One pro= posal that might satisfy everyone: an "outbox" or > "futurerelease"> mail= box role is added (this is the IMAP SPECIAL-USE representation in> JMAP). = Servers can *optionally* have a mailbox with this role if it> does, client= s SHOULD place future-release messages in here, but like> "sent" *can* put= the message in any mailbox(es). Servers that have > this> mailbox MUST m= ove messages from this mailbox to the sent mailbox at> future release time= (which may just be based upon the future-release> date, or may be actuall= y based on releasing it to the mail queue).This is something I could implem= ent easily as long as there`s no requirement that the mail store verify the= message was actually released from the mail queue at the future release ti= me. But I`m not sure it`s a good design as it raises some issues... Message= s in the futurerelease mailbox have been submitted/sent, so should that mai= lbox also have the \Sent special use? And if we then end up with more than = one mailbox with \Sent special use, will mail clients need code to prefer t= he one without the "futurerelease" special use for sent messages that aren`= t future release?I think a futurerelease virtual mailbox (based on the sent= mailbox) is a cleaner way to do this (and optionally a sentandreleased vir= tual mailbox for clients desiring that). - Chris___________________________= ____________________Jmap mailing listJmap@ietf.orghttps://www.ietf.org/mail= man/listinfo/jmap.Do not Remove:[HID]20170504024829484[-HID] [XGENFOOTER] [-XGENFOOTER]=00=00 ------=_Part_8399_1692691600.1493971141529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello. Sorry for my late comments. But if it is useful, we have been off= ering scheduled email ( future delivery ) via webmail since last 15 years n= ow.

While sending email user can set date and time of the delivery of this e= mail. In our system we have time for every email to be delivered. So if it = is not scheduled , It`s automatic set as NOW and otherwise user defined tim= e.

No further action is required by user.

We have a server level Outbox ( not user level ) so that all the schedul= ed email can be seen by Queue processor without worrying about each users o= utbox.

This has also impact on storage quota , user mail quota limits, expiry e= tc. Recurring email on fixed date and time. Like birthday reminders, greeti= ngs etc.

Hope it helps.

Thanks

Ajay Data

From: "Chris Newman" <chris.newman@oracle.com>=   MailId : [68715573]
To: "Nei= l Jenkins" <neilj@fastmail.com>
Cc: jmap@ietf.o= rg
Subject: Re: [Jmap] simpler future release & u= nsend without outbox (was Re: Best vs Good enough - adoption of JMAP)
= Date: 04 May 2017 02:48:30 AM

On 3 May 2017, = at 0:57, Neil Jenkins wrote:
>  On Mon, 1 May 2017, at 09:53 P= M, Chris Newman wrote:
>> Here`s my guess at the root cause:
>> * You`re trying to mirror a particular client UI model in the ma= il
>> store server design.
>  I`m trying to ensure = that the API exposes the data clients need to
>  present commo= n UI patterns in an efficient way, while also allowing
>  the=
>  most flexibility in server implementation. I think we`re b= oth aiming
>  for
>  the same thing!
>&g= t; 1. I believe there are four message types involved in this
>>= ; discussion:> * draft messages
>> * client-side outbox
= >> * future release RFC 4865 submitted
>> * other submitte= d messages
>
>  I agree, although I don`t think the cl= ient-side outbox is particularly
>  relevant to this discussio= n, as it should not affect the API design.

An important factor i= n protocol/API design is to avoid misleading the
consumers. So in thi= s respect the distinction between client-side outbox
and server-side = future release messages is important. We don`t want
protocol/API cons= umers to confuse those two classes of messages because
they behave di= fferently when the client is offline.

>  I`m sorry I bro= ught this up as it side-tracked the discussion
>  somewhat. M= y
>  main point was that many existing systems assign submitte= d "future
>  release" messages to a separate mailbox on the *s= erver*, and clients
>  present them to the user distinctly to = those that have been released.
>  What I misunderstood from yo= ur proposal, is that rather than marking
>  messages that can = be recalled/cannot be recalled, you propose a
>  client just l= ook at the "release date" annotation instead. Although
>  you = also say this:
>> Actually, my proposal makes this server design= approach
>> simpler. There`s> just an internal flag in the s= ent folder to
>> indicate if the
>> message has> = been passed forward. The mail queue daemon that operates
>> on = the mail
>> store sent folder, can transfer the message to the n= ext hop MTA and
>> set> that flag at the future release time.= No need to move the
>> message
>> between folders.<= br />>
>  So the mail queue daemon *does* perform an action= on the message in
>  the
>  mail store when it = is sent? I previously thought you were advocating
>  for
>  a model where these can be completely separate and so this is n= ot
>  possible. Could you please clarify?

I advocat= e an implementation model where the mail queue and mail store
can be = separate in the server implementation. I accept that some server
impl= ementations may choose not to do this and the protocol design
shouldn= `t constrain potentially reasonable implementation choices. In
the qu= ote above, I was explaining one way a server implementation that
mixe= s mail queue and mail store could work with the protocol model I
prop= osed.

>  I think we`ve got various issues conflated a bi= t over these
>  discussions,
>  so I`ll clarify = what I think are the separate questions:
>  How, if at all, ar= e "future release" messages (that have yet to be
>  released) = marked over the API? Is there a change in the state when
>  t= hey
>  are released? I agree this may not correspond exactly w= ith whether a
>  message can be unsent, especially for interna= l corporate mail systems,
>  so a related question is: how, if= at all, are messages marked that can
>  be unsent? (This is p= otentially a tristate: can (almost) definitely
>  unsend, can = definitely not unsend, may be able to unsend).
>  I think if w= e can agree on answers to these questions, the rest will
>  fa= ll out fairly easily.

I prefer a protocol model where it is poss= ible for the client to easily
identify "future release date is in the= future" messages and to apply an
"unsend" action to those messages. = I further believe the model shouldn`t
limit the "unsend" action so it= can only be used with that set of
messages. And I`d prefer a model w= here there is no explicit state change
in the mail store when a "futu= re release" message is released as that
keeps the mail queue and mail= store components independent.

I`m ok if the base JMAP spec requ= ires implementation of future release
and unsend for future release m= essages. I`d prefer to leave details
about message tracking (includin= g whether a message can unsent) and
unsend for other messages to a JM= AP extension. Things get complicated
for the other cases. First, it`s= actually a four state problem: "future
release in the future", "unse= nd not possible", "unsend maybe possible",
"no information about whet= her unsend is possible". And there`s the
question of whether tracking= is an action (as it is for RFC 3887), or we
require an MTA to mail s= tore notification path for all messages to
indicate whether a sent me= ssage can be unsent. The latter probably
results in a better UI but I= think it`s too much to require in the JMAP
base spec if we want JMAP= to deploy quickly.

>> 3. I view "submit" and "unsend" as = MTA actions that should not be
>> confused or conflated with mai= l store operations. I`m opposed to
>> protocol designs where a m= essage move, delete or flag changes
>> triggers> MTA actions= as a side-effect.
>> Instead, I propose JMAP have explicit "sub= mit" and "unsend" commands
>> that first perform the MTA action = but can> also trigger mail store
>> actions (like move messa= ge or flag change) if
>> the MTA action succeeds.
> = ; Yes, this is a perfectly fine approach; I`m not opposed to adding
&g= t;  explicit sendMessages/unsendMessages calls. If the call can option= ally
>  set which mailbox(es)/keywords to set upon successful = send, then this
>  is
>  functionally equivalent=

Great, we have an approach we both support.

>>= ; My proposal is to have future release sent messages tagged with
>= ;> their> future release date. The MUA can create a virtual folder fo= r
>> future
>> release messages with a future date. = Whether the server caches a
>> count> for the messages in th= at virtual folder is a server design
>> optimization> choice.= If enough clients request that count that it
>> helps server>> scalability to cache that count, then servers will cache that<= br />>> count. The> count of future release messages is thus not r= elevant to
>> the
>> issue under> debate.
&g= t;
>  What`s relevant is how this count is exposed over the AP= I. If there
>  is a mailbox, then the synchronisation of mailb= ox objects will ensure
>  the client is "pushed" the count; be= cause count changes are common
>  and clients need to know the= m to present the most common UI paradigm
>  for mail, synchron= isation of mailbox counts is optimised for in the
>  JMAP prot= ocol.

Virtual/smart mailboxes are a common mail UI feature. As a= mail user,
I`d like my virtual mailboxes to look the same in differe= nt mail clients
to the extent possible. So the way to get more consis= tent behavior is to
have a server-side-virtual mailbox model. I`d ver= y much like JMAP to
have the ability to create a virtual/smart mailbo= x that behaves like a
regular mailbox in most ways (including optimiz= ed counts). That`s a
significant value-add that could be implemented = in the JMAP layer. IMAP
has primitives that can help (like RFC 5466, = and RFC 5267) but nothing
that enables smart mailbox behavior consist= ency across clients.

>  One proposal that might satisfy = everyone: an "outbox" or
>  "futurerelease"
>  m= ailbox role is added (this is the IMAP SPECIAL-USE representation in
&= gt;  JMAP). Servers can *optionally* have a mailbox with this role; if= it
>  does, clients SHOULD place future-release messages in h= ere, but like
>  "sent" *can* put the message in any mailbox(e= s). Servers that have
>  this
>  mailbox MUST mo= ve messages from this mailbox to the sent mailbox at
>  future= release time (which may just be based upon the future-release
>&nb= sp; date, or may be actually based on releasing it to the mail queue).

This is something I could implement easily as long as there`s no requirement that the mail store verify the message was actually released=
from the mail queue at the future release time. But I`m not sure it`= s a
good design as it raises some issues... Messages in the futurerel= ease
mailbox have been submitted/sent, so should that mailbox also ha= ve the
\Sent special use? And if we then end up with more than one ma= ilbox with
\Sent special use, will mail clients need code to prefer t= he one without
the "futurerelease" special use for sent messages that= aren`t future
release?

I think a futurerelease virtual ma= ilbox (based on the sent mailbox) is a
cleaner way to do this (and op= tionally a sentandreleased virtual mailbox
for clients desiring that)=

- Chris

__________________________________________= _____
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/m= ailman/listinfo/jmap
.

Do not Remove:
[HID]20170= 504024829484[-HID]

[XGENFOOTER]

[= -XGENFOOTER]
=00=00 ------=_Part_8399_1692691600.1493971141529-- From nobody Sun May 7 04:06:56 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6C51279E5 for ; Sun, 7 May 2017 04:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=GXv4NabP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PznuiJDB 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 hva_-ZEodq8D for ; Sun, 7 May 2017 04:06:54 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5358912751F for ; Sun, 7 May 2017 04:06:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C611C207C7 for ; Sun, 7 May 2017 07:06:53 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Sun, 07 May 2017 07:06:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=ejEInF/oIZxv7U7gX9AlaXmjytYaUdccqrz3Z+CKqTk=; b=GXv4NabP Tzjr2ZvB961D2zQWc03FkX4FXcUFuj1hAWZOUTWYzFR8gAt5whynHUA6CkDeoM4q wn41Tkaw5kqNvi3eRqQEFWxxZkYQWKeoYnbkCAqJ/7A0rllrxvZPxWtpCkRVHAG8 l3At8n96SZ7lWQLnCOyDm5af7GnNAez6kGb0YDcR9DSqaujR4y4vydZu1jqV+8B9 ZT8hP++SrGWf5IFaiBMaNVLQUI7mPNpT4pgsrnPjVp/9umYx2IGdMd5azUTuJct/ smWnXgegDVS8FUWtLqcwnF2rHFGtzHrg/62TofVeVi2S9VMWhHSf36B2qIzptdYC sWEInZWt87dQHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ejEInF/oIZxv7U7gX9AlaXmjytYaU dccqrz3Z+CKqTk=; b=PznuiJDBajktn0Svj1e/1QN/DqOLH8OZjlwODmcjvBsqL B2f0GXu8QeoGfn3qsgR62O8lGNicZdnCJkoWTQAy4Eja15wAARpS9pvHFd9L4iE7 zNEAQ4PbrQTtmGW231TIuCDkJWAIi7nhrxg847JMM/74d0w4MA6xwqWu4Ce94I/C 8hOneFmWOl2H5iV9H3frhUu5Vvn/epbwe8XT69enwFWTdtIn0wvjsWfHbmyvy7j1 nFywpI9x8kDHgHzNfy+uDzAn0cpNK5xDRVtYWsH3QWsk86TTp3BwBBeQ7JLveK5J mD75sx0IHWMXTNH160eHDJtylqo2WW3pYTgrbK7FQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A1AC9BAB6F; Sun, 7 May 2017 07:06:53 -0400 (EDT) Message-Id: <1494155213.3081934.968406608.5F9E8767@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1 Date: Sun, 07 May 2017 21:06:53 +1000 Archived-At: Subject: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 11:06:56 -0000 https://news.ycombinator.com/item?id=14284526 It's a rather silly discussion that went off onto a tangent, that's HN for you. The key interesting point is this: A quick look at the protocol looks like in order to get a list of mailboxes, you have to ask for them all. In IMAP, you can say, show me top level mailboxes, show me direct child mailboxes of mailbox x, etc. In a previous role, I was responsible for working on a mail archiving solution which had a large hierarchy of folders (into the thousands IIRC) in a single account. Access to the archive was via IMAP. Looks to me that JMAP here would require the client to potentially fetch megabytes of data just to start showing a list of folders, where the solution we had with IMAP probably took a couple of kilobytes at most to get started. ... and the followup: > Of course nothing stops you storing thousands of mailboxes in a non-heirarchical layout and making IMAP have large LIST fetches too. Yes. I would issue the LIST command, and as the IMAP server started streaming the results to the client, I would immediately process each mailbox as soon as it was down, rather than waiting for them all to be retrieved. I fear that with a JSON based protocol, most server and client implementations wouldn't deal with streaming (although they technically could), and would just deal with completed blobs. ... I think it is worth discussing the tradeoffs in terms of additional complexity to offer paging, tree filtering (parentIds: [...]) or both in the standard. The pro side, you can access potentially millions of mailboxes without needing to know all the folder ids up front. On the con side, it's more complexity for the server (client can always just fetch everything anyway if it doesn't care) - and most clients seem to fetch the entire tree anyway, so it just means more round trips for them. Bron. -- Bron Gondwana brong@fastmail.fm From jmap@lists.grepular.com Sun May 7 05:39:57 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F6C1200CF for ; Sun, 7 May 2017 05:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_IADB_DK=-0.095, RCVD_IN_IADB_LISTED=-0.001, RCVD_IN_IADB_RDNS=-0.235, RCVD_IN_IADB_SENDERID=-0.001, RCVD_IN_IADB_SPF=-0.059, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lists.grepular.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 rCLQjwK_Jb_N for ; Sun, 7 May 2017 05:39:54 -0700 (PDT) Received: from frank.grepular.com (frank.grepular.com [164.132.228.175]) (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 15FEF1242F7 for ; Sun, 7 May 2017 05:39:54 -0700 (PDT) Received: by snake.grepular.com (Postfix, from userid 1000) id 3BD841081444; Sun, 7 May 2017 13:39:12 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.grepular.com; s=glue2; t=1494160791; bh=nHOiyclKE+Hlnhr8qDOoha68XKUnU6Uezzm6a2D7FvA=; h=Date:From:To:Subject:In-Reply-To:From; b=28Fc+NtZfuekWwnyyiCfYvECwPbuvdFBgILRq73Yr2pcvHR015YCde1XUd68mqlAo 9TRKtqArLKbRHE4CtjeJx/CvR6C178/UEXnoJ5ThSMvYg3xoyluADlHANwNiJ6iyyG 3uisd0YuZR+szqgm2cnNv0L3ffJaf8zrnmyc2qxk= X-Hashcash: 1:26:170507:jmap@ietf.org::5kTtCQanAy0QH0nN:nINEk Date: Sun, 7 May 2017 13:39:12 +0100 From: Mike Cardwell To: jmap@ietf.org Message-ID: <20170507123912.GA22520@snake.grepular.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <1494155213.3081934.968406608.5F9E8767@webmail.messagingengine.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 12:42:05 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > https://news.ycombinator.com/item?id=3D14284526 >=20 > It's a rather silly discussion that went off onto a tangent, that's HN for > you. I am the person who is responsible for that silly discussion and also ironi= cally the person who said he wasn't invested in the success of JMAP enough to bri= ng it to this very list. Well, here I am. > Me: > A quick look at the protocol looks like in order to get a list of mailbo= xes, > you have to ask for them all. In IMAP, you can say, show me top level > mailboxes, show me direct child mailboxes of mailbox x, etc. In a previo= us > role, I was responsible for working on a mail archiving solution which h= ad a > large hierarchy of folders (into the thousands IIRC) in a single account. > Access to the archive was via IMAP. Looks to me that JMAP here would req= uire > the client to potentially fetch megabytes of data just to start showing a > list of folders, where the solution we had with IMAP probably took a cou= ple > of kilobytes at most to get started. > and the followup: > Bron: > Of course nothing stops you storing thousands of mailboxes in a > non-heirarchical layout and making IMAP have large LIST fetches too. > Me: > Yes. I would issue the LIST command, and as the IMAP server started > streaming the results to the client, I would immediately process each ma= ilbox > as soon as it was down, rather than waiting for them all to be retrieved= =2E I > fear that with a JSON based protocol, most server and client implementat= ions > wouldn't deal with streaming (although they technically could), and woul= d just > deal with completed blobs. > I think it is worth discussing the tradeoffs in terms of additional compl= exity > to offer paging, tree filtering (parentIds: [...]) or both in the standar= d. > The pro side, you can access potentially millions of mailboxes without ne= eding > to know all the folder ids up front. On the con side, it's more complexi= ty for > the server (client can always just fetch everything anyway if it doesn't = care) > - and most clients seem to fetch the entire tree anyway, so it just means= more > round trips for them. I know it's from a different time, but in the RFC for IMAP implementation recommendations, it says the following: https://tools.ietf.org/html/rfc2683 Some servers present Usenet newsgroups to IMAP users. Newsgroups, and other such hierarchical mailbox structures, can be very numerous but may have only a few entries at the top level of hierarchy. Also, some servers are built against mail stores that can, unbeknownst to the server, have circular hierarchies - that is, it's possible for "a/b/c/d" to resolve to the same file structure as "a", which would then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy will never end. The LIST response in this case will be unlimited. Clients that will have trouble with this are those that use C: 001 LIST "" * to determine the mailbox list. Because of this, clients should not use an unqualified "*" that way in the LIST command. A safer approach is to list each level of hierarchy individually, allowing the user to traverse the tree one limb at a time IMAP can essentially work with folders of infinite depth when clients don't request the full list of folders up front. It can also work with slow backends. What if you had a giant mail store backed by Amazon S3? Your data could be spread over multiple buckets. Why wait for all buckets to be retrieved before you start sending data to the client? IMAP also lets you present a dynamically generated folder structure where each new level is calculated on demand. Perhaps someone will want to stick a dynamic JMAP frontend in front of the https://www.mail-archive.com/ website where the folder structure is "List Name/Post Year/Post month". That would be a lot of folders. I posit that allowing you to request a complete list of all folders in one go was a mistake in IMAP, and one that shouldn't be repeated in JMAP. --=20 Mike Cardwell https://www.grepular.com OpenPGP Key DF70 D8E5 FBD6 8519 9257 C44C 0DA6 8B1E 1801 A332 XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGGBAEBCgBwBQJZDxVwMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGlu Z0BwZ3AuY29tcGdwbWltZTgUgAAAAAAVABpwa2EtYWRkcmVzc0BnbnVwZy5vcmdt aWtlLmNhcmR3ZWxsQGdyZXB1bGFyLmNvbQAKCRDRXjsWQOa7rRgICADNBkFCrIwR 4BEU8eFmGxSyyZVX4CEAS1a3gHiy3FzKCZo29FpD3/FA/MQW2CAO4jr109ahYeRX 8FswsFmsk1WFAz2SHDRe087pDpeb8DybwjzyrZD48NWWOQ8VAka3OPEXk+uT+QYw 0JGck/Iika9z3DQ3D1oyfMw369gL4dGse1gZmMIiCMP/FMRKLTIosZHkoB6xE+ls vKTtZrRQyOI9MTWCBGhgvU2P3jNUzMvaCq0q6VZQcn4upcRU5TU93AK7po/8MeZ9 bvoy44dYKMmpUcl0jENjEpk5FqDGwO4dpFVdUteVwgcCPnpg8ZdA069ZPjMGdrZm fGh2Qg0aMf1R =9thY -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From nobody Sun May 7 09:14:54 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEBF126CE8 for ; Sun, 7 May 2017 09:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 zlwJCV5TyCfN for ; Sun, 7 May 2017 09:14:51 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E19124D6C for ; Sun, 7 May 2017 09:14:51 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id u75so36172601qka.3 for ; Sun, 07 May 2017 09:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G+l+rRyZNyksP+BH5XVyJP6rTD+IOL3GX+9SY/cRWAA=; b=SjNqsF52ecr7zyRPtwXDXDM7mxDl43OUKfhhLoAlh1T7v45lAIXlXgPVYd/e67c9X3 dtZ2o72poTH81OZ2E0KDYwAkhPv6O9ecY/8dKwqxS7KToRCpm5tRP36pp+RkysKTp9GS KS0qIc9z3lQLId5iJFyhmyXvYC5jkzLBbVhrqeo5sy/pEmvOGFWXuvf7wIJF9qNwRllH lR3OTROH6KkwcSj1ey/Dh1ogLnFI4W9TAzp0Vj/5Wpj9hDxRjwgKsA5kPGCGX1+Gjkn4 LBxbgGXmx4SnlT17CaV6ctEwFgcZvQxArQIhYtHrUf5mm2+aeMi30rph/kdZmhgqWi3a 8yIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G+l+rRyZNyksP+BH5XVyJP6rTD+IOL3GX+9SY/cRWAA=; b=Iw0op81yH73IoESZzy/x42niFln4ifkjLz6FPnw3yiK0RYBdWiDIAcDbFm+n55zfH8 +bSOXtg53seEwYdfq8PMU04eCnybuQBy9lMjibE0eVEMM8pX9/CqJZvCb8VYo3IXH9b6 eehFB0habsK25hu+ZHr18uaJWC0R4C32d59HFtSIqSGnBNz6NgfVzMhcCwwfMUQQs0NU AQmP7McGzHxTSzCEpHdFv4klVyyqGSduh+atdmYbyLIe8e2sUzoE1fujE48h8vo7a9FZ +VyHFSyTE9G+wfw8vyoZmwbg6ATUNHs5H/nCQW0w2njPOCXn1rkN0DHX5tZku+ZIgK5e aO/g== X-Gm-Message-State: AODbwcByX3lWWAzUop7k5F2ZJJJ2T+ubiXzVsX6gPHK7V7vBFFMFziKb p2mc0v2eUKheBmCPDRA= X-Received: by 10.55.214.76 with SMTP id t73mr24007349qki.279.1494173690312; Sun, 07 May 2017 09:14:50 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b130sm8643908qka.0.2017.05.07.09.14.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 May 2017 09:14:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <20170507123912.GA22520@snake.grepular.com> Date: Sun, 7 May 2017 12:14:47 -0400 Cc: jmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170507123912.GA22520@snake.grepular.com> To: Mike Cardwell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 16:14:53 -0000 I tend to think that folders are only notionally hierarchical, so I = don't love the idea of hierarchy as the mechanism for hiding folders = that are no longer relevant. Why not just have an archived flag? = Clients that care about archived folders can sync that list; clients = that do not, do not have to. The archived flag could be done = automatically: "flag anything that hasn't had any new messages added to = it in the past year as archived". Or "flag anything that is = hierarchically below this folder as archived" for your use case. You = could even have an "archived-when" modifier. If there are to be bazillions of folders, the folder list could also be = treated as a versioned entity and traded about using diffs. From nobody Sun May 7 12:35:57 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B871286CA for ; Sun, 7 May 2017 12:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 beQ80TkqYUTL for ; Sun, 7 May 2017 12:35:55 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 11675127201 for ; Sun, 7 May 2017 12:35:55 -0700 (PDT) Received: from [192.168.1.189] (c-71-205-242-38.hsd1.co.comcast.net [71.205.242.38]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v47JcKgk009558 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 7 May 2017 12:38:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1494185900; bh=1ris30nHUldt3x8vCaDJduYA8HEWun6fCzPrrFzqrws=; h=To:Reply-To:From:Subject:Date:From; b=IjiE/HyQ9s17vdfHzmsIvCocLPw7sEKoChC+qPp952mqKCEORzcC161dCZDdDPVye 55MNzF71qZdLKCuMYX0uW8fn6Z6KcpiGQPSx2Y74ShwLihGf1osHZTlayZVkDqxeHC kgzyvHd4SYku5YeF3hwCax4Wbd6Sj+9O2xGDCBHI= To: jmap@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 7 May 2017 13:35:42 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Jmap] IMAP transition X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 19:35:56 -0000 After 19 Years CMU Discontinues Cyrus IMAP In Favor Of Microsoft Exchange And Gmail https://tech.slashdot.org/story/17/05/06/1726259/after-19-years-cmu-discontinues-cyrus-imap-in-favor-of-microsoft-exchange-and-gmail Discussion about jmap has been about improvements over imap. Perhaps it should include a wider scope to improve likelihood of adoption? (To the extent that folk think the existing jmap targets already achieve that, it would be useful to document and explain the details.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun May 7 15:19:52 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB53126CC7 for ; Sun, 7 May 2017 15:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAGlPBGysyw1 for ; Sun, 7 May 2017 15:19:49 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04283124BE8 for ; Sun, 7 May 2017 15:19:48 -0700 (PDT) Received: (qmail 75122 invoked from network); 7 May 2017 22:19:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 May 2017 22:19:47 -0000 Date: 7 May 2017 22:19:25 -0000 Message-ID: <20170507221925.16868.qmail@ary.lan> From: "John Levine" To: jmap@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] IMAP transition X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 22:19:50 -0000 In article you write: > > After 19 Years CMU Discontinues Cyrus IMAP In Favor Of Microsoft >Exchange And Gmail > > >https://tech.slashdot.org/story/17/05/06/1726259/after-19-years-cmu-discontinues-cyrus-imap-in-favor-of-microsoft-exchange-and-gmail Keep in mind that Exchange and Gmail both provide IMAP servers for people who want them, and that Google apps for education is free. So this is a decision to stop running their own data center, not one to give up on IMAP. R's, John From nobody Sun May 7 23:00:23 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061D8124281 for ; Sun, 7 May 2017 23:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=AwU9rOJY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RKg8OISM 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 jl8r27pAgnkt for ; Sun, 7 May 2017 23:00:20 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22EB126CBF for ; Sun, 7 May 2017 23:00:20 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 2452720864; Mon, 8 May 2017 02:00:20 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 08 May 2017 02:00:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.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=fm1; bh=9RO3fgFzSzy5vM9KmaLZJB21Q2PXz FrmEKE1PzYbUBY=; b=AwU9rOJYDXPPuyzfrTaJIjGb/r3AdFYHA0dppRVqSVj3E 2uFjvvb5gSLnsTMknYD+yD+Ko6hoawIRZKJzwe75z5DON6nCDOarRCKefgUlXzSe dn8W4bY9TjAAbsJAWcjRnUIb1gjGS+kYq7sc4QO2dORcc3mF2CKbeW+T0IO7Kyg4 /9HcrMI2UNw8riCYXEbbpTPrC8k7zMMkCasTJbN8WvDeDcdAsLQrZaKcVyKDYkjH j9ojQg1PAP3RVchZlQwN3tD997WbcPVUKCBGmikGOBL6mNfFmQlqLaqOjIOqQ7Y1 vElsUbvAMLbI83Xb7LZP0QIGV3KiNQSEPMzhxExIw== 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=fm1; bh=9RO3fg FzSzy5vM9KmaLZJB21Q2PXzFrmEKE1PzYbUBY=; b=RKg8OISMw5yRKT3R1GbPLK 8SAfuE8N7aC0Y/9cCrTgMSod5JYE53Ms8NkC1W/03+F4sw/1XNA2iWxthhnQExJk kWXu98v1vjhXgZLqXC5jKpFg1TxZgnhuVUrLyJuWqqln61qaOGLC/TzLeZg4ZxWK kt0nu4kMK8mQYhOwN+KdRHlA0SDn31+uvow/HY2stF07VBOJGBi8p4T56QsKte/E WoOaoc48pvoRmkahEEGtvbTHevV3B3VGd6R/zO8UBkkmozbAMgz/1pomHxsuaw3T WFa3E4SssaMZCbXY/5Dx+euIOXkH1mT/psccth5En/3Z/KXyNLD8UDt87GCEX2Xg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C784FE2689; Mon, 8 May 2017 02:00:19 -0400 (EDT) Message-Id: <1494223219.1429910.969023384.0FB0A74C@webmail.messagingengine.com> From: Neil Jenkins To: Chris Newman Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149422321914299103" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e7edfd09 Date: Mon, 08 May 2017 16:00:19 +1000 In-Reply-To: References: <46F700A6-C2B1-488B-A8B4-6ACD45B03C31@oracle.com> <1493099769.3023399.955193288.6D0312CC@webmail.messagingengine.com> <33553450-82F4-4CB4-8679-C9F52D8A8839@oracle.com> <1493163974.4122214.956244160.6735E49C@webmail.messagingengine.com> <1493185260.709114.956477904.75CB343B@webmail.messagingengine.com> <1493248332.1295949.957537688.05443911@webmail.messagingengine.com> <1493358386.1136069.958999408.285D03F1@webmail.messagingengine.com> <1493798243.3361851.964066360.38B8043E@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 06:00:22 -0000 This is a multi-part message in MIME format. --_----------=_149422321914299103 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 4 May 2017, at 07:16 AM, Chris Newman wrote: > I prefer a protocol model where it is possible for the client > to easily> identify "future release date is in the future" messages and to > apply an> "unsend" action to those messages. I further believe the model > shouldn't> limit the "unsend" action so it can only be used with that set of > messages. I agree. > And I'd prefer a model where there is no explicit state change > in the mail store when a "future release" message is released as that> keeps the mail queue and mail store components independent. I think this is the one real disagreement left, but I certainly take your point that you would prefer not to have to do this, so we should try to find a solution where this is optional. > I'm ok if the base JMAP spec requires implementation of future release> and unsend for future release messages. I'm not actually sure we should mandate servers implement future release in order to claim base JMAP support, but we should have the interface specified for servers that do support it. > I'd prefer to leave details about message tracking (including whether > a message can unsent) and unsend for other messages to a JMAP > extension. Agreed. > Virtual/smart mailboxes are a common mail UI feature. As a mail user,> I'd like my virtual mailboxes to look the same in different > mail clients> to the extent possible. I agree these are very useful, and it would be great if they were exposed at the protocol layer so they could be synchronised between clients. I'm not sure whether it's a good idea to try to put them in the base JMAP Mail spec though; depends how much we think they will slow down implementation, and whether they're strictly necessary. If the counts are optional then they should be pretty easy to implement, but every extra "optional" is of course more effort to maintain down the line. >> One proposal that might satisfy everyone: a "futurerelease" >> mailbox role is added (this is the IMAP SPECIAL-USE representation in>> JMAP). Servers can **optionally** have a mailbox with this >> role; if it>> does, clients SHOULD place future-release messages in here, but like>> "sent" **can** put the message in any mailbox(es). Servers that >> have this>> mailbox MUST move messages from this mailbox to the sent mailbox at >> future release time (which may just be based upon the future-release>> date, or may be actually based on releasing it to the mail queue). > > This is something I could implement easily as long as there's no > requirement that the mail store verify the message was actually > released> from the mail queue at the future release time. But I'm not > sure it's a> good design as it raises some issues... Messages in the futurerelease> mailbox have been submitted/sent, so should that mailbox also have the> \Sent special use? No, I'd say it would just have a "futurerelease" role. I think this is reasonable; clients which understand this role have all the information they need from this, and clients that don't may be confused by two mailboxes with the "sent" role. > I think a futurerelease virtual mailbox (based on the sent > mailbox) is a> cleaner way to do this (and optionally a sentandreleased > virtual mailbox> for clients desiring that). The issue with this is synchronising changes with the server. The results of a message list (a sorted query on the set of messages) normally only change in response to some kind of state change on the server. If futurerelease were a *virtual* mailbox, the results would change depending on *when* you fetch the query, even if there is no change in server state. So this would require a new mechanism to notify the client of when the query results might have changed (presuming you want a client to be able to be always up to date without polling everything, which I think is a reasonable requirement). Neil. --_----------=_149422321914299103 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 4 May 2017, at 07:16 AM, Chris Newman wrote:
I prefer a protocol model where it is possible for the client to easily
identify "future release date is in the future" messages and to apply an
"unsend" action to those messages. I further believe the model shouldn't
limit the "unsend" action so it can only be used with that set of
messages.

I agree.

And I'd prefer a model where there is no explicit state change
in the mail store when a "future release" message is released as that
keeps the mail queue and mail store components independent.

I think this is the one real disagreement left, but I certainly take your point that you would prefer not to have to do this, so we should try to find a solution where this is optional.

I'm ok if the base JMAP spec requires implementation of future release
and unsend for future release messages.

I'm not actually sure we should mandate servers implement future release in order to claim base JMAP support, but we should have the interface specified for servers that do support it.

I'd prefer to leave details about message tracking (including whether a message can unsent) and unsend for other messages to a JMAP extension.

Agreed.

Virtual/smart mailboxes are a common mail UI feature. As a mail user,
I'd like my virtual mailboxes to look the same in different mail clients
to the extent possible.

I agree these are very useful, and it would be great if they were exposed at the protocol layer so they could be synchronised between clients. I'm not sure whether it's a good idea to try to put them in the base JMAP Mail spec though; depends how much we think they will slow down implementation, and whether they're strictly necessary. If the counts are optional then they should be pretty easy to implement, but every extra "optional" is of course more effort to maintain down the line.

One proposal that might satisfy everyone: a "futurerelease"
mailbox role is added (this is the IMAP SPECIAL-USE representation in
JMAP).  Servers can *optionally* have a mailbox with this role; if it
does, clients SHOULD place future-release messages in here, but like
"sent" *can* put the message in any mailbox(es). Servers that have this
mailbox MUST move messages from this mailbox to the sent mailbox at
future release time (which may just be based upon the future-release
date, or may be actually based on releasing it to the mail queue).

This is something I could implement easily as long as there's no
requirement that the mail store verify the message was actually released
from the mail queue at the future release time. But I'm not sure it's a
good design as it raises some issues... Messages in the futurerelease
mailbox have been submitted/sent, so should that mailbox also have the
\Sent special use?

No, I'd say it would just have a "futurerelease" role. I think this is reasonable; clients which understand this role have all the information they need from this, and clients that don't may be confused by two mailboxes with the "sent" role.

I think a futurerelease virtual mailbox (based on the sent mailbox) is a
cleaner way to do this (and optionally a sentandreleased virtual mailbox
for clients desiring that).

The issue with this is synchronising changes with the server. The results of a message list (a sorted query on the set of messages) normally only change in response to some kind of state change on the server. If futurerelease were a virtual mailbox, the results would change depending on when you fetch the query, even if there is no change in server state. So this would require a new mechanism to notify the client of when the query results might have changed (presuming you want a client to be able to be always up to date without polling everything, which I think is a reasonable requirement).

Neil.
--_----------=_149422321914299103-- From nobody Sun May 7 23:19:09 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACE41252BA for ; Sun, 7 May 2017 23:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=uMJ5Wg5M; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ei+Beuxu 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 si0d1YHu_oj9 for ; Sun, 7 May 2017 23:19:05 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F3C124281 for ; Sun, 7 May 2017 23:19:05 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 0794720595 for ; Mon, 8 May 2017 02:19:05 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 08 May 2017 02:19:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= 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=fm1; bh=ONPH8N903d/zlT28yYgWH2VS/xr96 zmVVf45/QA/rVo=; b=uMJ5Wg5M3cOdJAdu0IcUHa2OhqgjoDBeQsuAuhuv4gbuI rn7SC4TWqNKDsmQB+U6MlFGzrr0Pw5qzLXcmWlkmGLk5V1QQ/Cdi/rFzfQWFWvbW dVuIdDeaoLKeRUAZHnqlRGbyLIVlLCWwWgy4yKm0LfkC8FbVnof2X/exSQtgk7s1 Jyyw4h3xucYYzRj6s0swjrD5dHKniRqK2wGlk7Jb21ipKPSUXm47PDS/Ki5Z2US/ 5WeYzG5U9f3N2WqKfJmPbUVIgxKY8/j+199vY/od0vTaKoeXMBn7ppa9RDQFmOWV akqBAIdBdvNSYZRRKQlpLkM7hthKiaWBWsGEaW2tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ONPH8N 903d/zlT28yYgWH2VS/xr96zmVVf45/QA/rVo=; b=Ei+BeuxuY2N5BZRThbDUf2 GfOZmdVqBxA7SjjkA0a3DRzSvfEaPmvKW9DKOgroOBXTXJpBStn0hf3KFM1UkNTA Oolir9d51Rfl1wbVt6BYLHca94XIzagtKUjqaPAsd2dKEyzoX8UNIKL41AFuhAZh hdCCXGVeS8xD/ps6AOqZIJ14WlW+uWlUKJvVdfnzvJzkBCtmCg0Z9lRz+hdG8ehs xeQY/M0SClFnNPQ8qvXlOIhd+aXY39toOrQ5j0Xug+GpA42amwHsEn+9Xud3cttp +mHkOWCXM2bcLe12OuehKw9f73sx2NylNGSyijmHOdjzTRMw3X21ABOJBQKWrTLA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B83C4E2AAC; Mon, 8 May 2017 02:19:04 -0400 (EDT) Message-Id: <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149422434414472451" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e7edfd09 References: <20170507123912.GA22520@snake.grepular.com> In-Reply-To: Date: Mon, 08 May 2017 16:19:04 +1000 Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 06:19:07 -0000 This is a multi-part message in MIME format. --_----------=_149422434414472451 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" When considering this before, I've tended to observe the following points: * Standard mail clients generally fetch all mailboxes up front, and indeed often need to before they will display a (non-loading) UI. * The vast majority of users have very few folders (from what I remember last time we ran the stats at FastMail, well over 90% of users never created a single extra folder beyond the defaults). So I therefore left out querying mailboxes (and so being able to fetch them in pages) from the initial JMAP draft. The main case for this seems to be presenting access to usenet groups or other non-strictly-email stuff. There is always a question of whether we want to support every use case, at the expense of making implementation more onerous. Having said that, there's a standard mechanism in JMAP for doing querying/sorting/paging of a record type (getFooList[1]), so if we do decide we want this capability it is mostly obvious how it should be specified. We'd include a filter option for *parentId* so you could easily fetch as a hierarchy if you want, and it would be easy to add an isArchived flag or similar later and filter on that if desired. As long as we still allow *getMailboxes* to be called with a null *ids* argument (therefore returning all mailboxes), clients can still just ignore all this if they always need to fetch the whole set up front. It's mainly therefore an extra burden on server implementations. So is it worth the tradeoff? Thoughts? Neil. Links: 1. http://jmap.io/spec-core.html#querying-data --_----------=_149422434414472451 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
When considering this before, I've tended to observe the following points:
  • Standard mail clients generally fetch all mailboxes up front, and indeed often need to before they will display a (non-loading) UI.
  • The vast majority of users have very few folders (from what I remember last time we ran the stats at FastMail, well over 90% of users never created a single extra folder beyond the defaults).

So I therefore left out querying mailboxes (and so being able to fetch them in pages) from the initial JMAP draft. The main case for this seems to be presenting access to usenet groups or other non-strictly-email stuff. There is always a question of whether we want to support every use case, at the expense of making implementation more onerous.

Having said that, there's a standard mechanism in JMAP for doing querying/sorting/paging of a record type (getFooList), so if we do decide we want this capability it is mostly obvious how it should be specified. We'd include a filter option for parentId so you could easily fetch as a hierarchy if you want, and it would be easy to add an isArchived flag or similar later and filter on that if desired.

As long as we still allow getMailboxes to be called with a null ids argument (therefore returning all mailboxes), clients can still just ignore all this if they always need to fetch the whole set up front. It's mainly therefore an extra burden on server implementations. So is it worth the tradeoff? Thoughts?

Neil.
--_----------=_149422434414472451-- From nobody Mon May 8 06:14:33 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B208512946C for ; Mon, 8 May 2017 06:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=MA0nQvoW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gDm4A3Wx 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 i8oINfYNqweN for ; Mon, 8 May 2017 06:14:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6528A129467 for ; Mon, 8 May 2017 06:14:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CA8BA208D8 for ; Mon, 8 May 2017 09:14:29 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 08 May 2017 09:14:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= 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=fm1; bh=4Xa+1ufnlYGjjQ6yjPv/w+tgaorB3 puppCpIRDSM134=; b=MA0nQvoW1l3Y57NCRFBh1yY/LSreTn4liwIYz1tdng8F+ o/SIfMEL/C15AxFEXlb7x16ITLYVTgnpPYvIwNmfFhb0+y6R1eOX79r04jjtepX0 b/drpGAIo+h3EWG49DpikPDjOiB1tg6KVNZiElkWhk/kQAqUQNLP9JjPOT7DzAKV X6E+qMH3pyEw/RWvS9FqHcMfUHKNfYXeSIcNwVT8beAyXdjBdvm2YQ5LT/Xh830Y VH7eUzV4lfVhpfuOy2IdvN2OmJMm2wuEUArA9aBBtKP3c7UEyY0qHQQqX6dN5IGQ /67NuDFfmfHrg4L0SL9wjfqakudWOEmpMDyETgd+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4Xa+1u fnlYGjjQ6yjPv/w+tgaorB3puppCpIRDSM134=; b=gDm4A3WxkM12JVvS0iucoJ WpplgRxO3Nh8gpr3qUXYYTNZS7t9kGE37352b5EPQxXW1MYT75tGF6banmdw+osW gJ+6kR5VVII8sXxbFcEV0okYP9RwCQGqrzLsaZFvitqKpCAkZK75h40T7289OId3 qw5JMhe6anutNTLDcOK3i5jwcSBKqmxDhK4pZaTw4yqMQFNI42f7mNQpUHWx6l74 d8lC0VWZJBsHeI0kI214fXPn3gOKUYkxfZN/GH1clUsCXuBoa8Yc8p9QBnmsdLG5 IRnNYl/GUS42bqCDiCgvO4UYeve/68sUP7BM7/p+6NwRf5vweY4ohd0keIva2Trg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 89C36BAB6F; Mon, 8 May 2017 09:14:29 -0400 (EDT) Message-Id: <1494249269.88461.969397104.25D88F0A@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1494249269884610" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1 In-Reply-To: <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com> References: <20170507123912.GA22520@snake.grepular.com> <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com> Date: Mon, 08 May 2017 23:14:29 +1000 Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:14:31 -0000 This is a multi-part message in MIME format. --_----------=_1494249269884610 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 8 May 2017, at 16:19, Neil Jenkins wrote: > Having said that, there's a standard mechanism in JMAP for doing > querying/sorting/paging of a record type (getFooList[1]), so if we do > decide we want this capability it is mostly obvious how it should be > specified. We'd include a filter option for *parentId* so you could > easily fetch as a hierarchy if you want, and it would be easy to add > an isArchived flag or similar later and filter on that if desired.> > As long as we still allow *getMailboxes* to be called with a null > *ids* argument (therefore returning all mailboxes), clients can still > just ignore all this if they always need to fetch the whole set up > front. It's mainly therefore an extra burden on server > implementations. So is it worth the tradeoff? Thoughts? It makes sense to me to have a way to do paging/limiting. It should be easy enough for a server implementation. We wouldn't even need getMailboxes with a null ids, just a getMailboxList with a search/sort that matches everything and a fetchRecords. The tricky bit is that Mailboxes is a tree rather than a list, so the I'm not sure how you would sort! Simplest of course is to not do any sorting, or to sort the entire list lexically by full path with the part separator being a null so it always sorts by full name: A A/foo A/foo/bar A/foo bar (that's super easy for me to do on the server, and to page into. Can also page just within a single parent level - which gets you both "*" and "%" list equivalents from IMAP) Bron. -- Bron Gondwana brong@fastmail.fm Links: 1. http://jmap.io/spec-core.html#querying-data --_----------=_1494249269884610 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 8 May 2017, at 16:19, Neil Jenkins wrote:
Having said that, there's a standard mechanism in JMAP for doing querying/sorting/paging of a record type (getFooList), so if we do decide we want this capability it is mostly obvious how it should be specified. We'd include a filter option for parentId so you could easily fetch as a hierarchy if you want, and it would be easy to add an isArchived flag or similar later and filter on that if desired.

As long as we still allow getMailboxes to be called with a null ids argument (therefore returning all mailboxes), clients can still just ignore all this if they always need to fetch the whole set up front. It's mainly therefore an extra burden on server implementations. So is it worth the tradeoff? Thoughts?

It makes sense to me to have a way to do paging/limiting.  It should be easy enough for a server implementation.  We wouldn't even need getMailboxes with a null ids, just a getMailboxList with a search/sort that matches everything and a fetchRecords.

The tricky bit is that Mailboxes is a tree rather than a list, so the I'm not sure how you would sort!  Simplest of course is to not do any sorting, or to sort the entire list lexically by full path with the part separator being a null so it always sorts by full name:

A
A/foo
A/foo/bar
A/foo bar

(that's super easy for me to do on the server, and to page into.  Can also page just within a single parent level - which gets you both "*" and "%" list equivalents from IMAP)

Bron.

--
  Bron Gondwana
  brong@fastmail.fm


--_----------=_1494249269884610-- From nobody Mon May 8 06:15:37 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2FD129467 for ; Mon, 8 May 2017 06:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=aBq3V+2v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bD++M2Pz 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 vjNUOwhNx4EY for ; Mon, 8 May 2017 06:15:34 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3DC12946C for ; Mon, 8 May 2017 06:15:34 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 379B0209C0 for ; Mon, 8 May 2017 09:15:34 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 08 May 2017 09:15:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= 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=fm1; bh=YGKCdpG8x0+isl57PSB21UlLrTmF7 d2FckaVAjMkCAQ=; b=aBq3V+2vx4+nLJ79gSLbFp7asSgA+gEHB6I4+xF2+5M2X SrwyssYLFBYcwWvLWCAshd2zlfcqolLQglK7PiH8jWytmhM1mmJsjlYjn+Q1sqew A+ZQtO76lbWFac48L+PDdEk178bnccLzzEQXsjTOGVvwEDsBgckrn6pJhStKXolB W8oQfImX5cZuBV3feDBG1xoXMq4aBbq2sqP9GAMV0VskJ2KnlB+Ho5jLIiLZghge /PDTOK4TYwv0DY9oJxA53+ZSbDeusyD4C7zrKGBql6fnn/NhpDOqW5uK+muoKR2H 3ODYxbN/nxkaNP0FgFDTEPKnPj4As5X/ngpTBWKqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=YGKCdp G8x0+isl57PSB21UlLrTmF7d2FckaVAjMkCAQ=; b=bD++M2Pz+qTq1vH48uggHw nTU0FG/hdJfSrJ/kmqUB/42HsY1Wvv2fPsNFQ+rj9mqjJkLMNDVEBBai6VSFcl9Y OKj3Ewlep3lFKNLByJ5wazXU16nv88HxpcQmhdAxynNALhwS7+1g8fZgVBSl3dIn UQDNdNYov7wHEEc00Rr+BrRNaZdf93B/5vHh0UtPvYwjH3ubmasWlRAWmLQzbxY7 aGx1ZSYrISBhiHcEKuJwsTbiJqptqQw6P0Asuh/yAcmUh2okG0Xvark3ARdAg5em Vqvz4I37t3ZYri2VhkM8YriUn4nwQP3EMZU3ti1JH2/ZvkjV8pBtn1ZAzn1JrxYQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0849ABAB70; Mon, 8 May 2017 09:15:34 -0400 (EDT) Message-Id: <1494249333.88554.969416232.37D727E4@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1 Date: Mon, 08 May 2017 23:15:33 +1000 References: <20170507123912.GA22520@snake.grepular.com> In-Reply-To: <20170507123912.GA22520@snake.grepular.com> Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:15:36 -0000 On Sun, 7 May 2017, at 22:39, Mike Cardwell wrote: > > https://news.ycombinator.com/item?id=14284526 > > > > It's a rather silly discussion that went off onto a tangent, that's HN for > > you. > > I am the person who is responsible for that silly discussion and also ironically > the person who said he wasn't invested in the success of JMAP enough to bring it > to this very list. Well, here I am. Hello and welcome. Thanks for making the time to contribute :) It is a topic worth discussing. Cheers, Bron. -- Bron Gondwana brong@fastmail.fm From nobody Mon May 8 06:26:57 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2A2129473 for ; Mon, 8 May 2017 06:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 W5pAmpbCDgXS for ; Mon, 8 May 2017 06:26:55 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 A281A129467 for ; Mon, 8 May 2017 06:26:55 -0700 (PDT) Received: from [192.168.1.189] (c-71-205-242-38.hsd1.co.comcast.net [71.205.242.38]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v48DTMxc007602 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 May 2017 06:29:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1494250163; bh=Y49zwqYF1E0s1v07irLl5W00Dw4EfMtLGkgNWNgNtPM=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=O1cq5CIEfUa4IX2mZGZzeXnHKP1yn+OFcXXuZkgPtF0teCofdeLPUMWEtQDTWtYYg Dw+JokwTa+bnPfi5yZZUq1ZqpRXOTpZeJ4rSTDpxJX0bGjYcKS1j+cMRzhVjO7WyYd utjCzFo7XsPY+TgOzu2xJlQFX1NcTjfz4yP7QmH4= To: John Levine , jmap@ietf.org References: <20170507221925.16868.qmail@ary.lan> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <406fb88e-6360-675a-0965-da67d2ec6548@dcrocker.net> Date: Mon, 8 May 2017 07:26:40 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170507221925.16868.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] IMAP transition X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:26:56 -0000 On 5/7/2017 4:19 PM, John Levine wrote: > Keep in mind that Exchange and Gmail both provide IMAP servers for > people who want them, and that Google apps for education is free. So > this is a decision to stop running their own data center, not one to > give up on IMAP. Sorry I was not clear enough. My question to the list was: > Discussion about jmap has been about improvements over imap. Perhaps it should include a wider scope to improve likelihood of adoption? The CMU event was intended as a trigger to the question: There is a market for mail server access that is larger than IMAP, involving one or more other protocols. Perhaps the jmap effort should consider features considered important in that larger market, in order to make jmap more broadly appealing (and useful)? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon May 8 06:31:32 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECDF129478 for ; Mon, 8 May 2017 06:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBXpC2Ln4eWO for ; Mon, 8 May 2017 06:31:30 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5EC129473 for ; Mon, 8 May 2017 06:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494250289; d=isode.com; s=june2016; i=@isode.com; bh=2JTAfSKbimib7imzHzWFyKUwkBfzqHjZboHpCc5L1dM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Nt9ngPU4KSpAmS6q47uOt85eFbcgadBfcXpHLPjt0VtYMs9zCoiDcirEf6BCYK57znjPCV j3WY3Dr6O6PimAS51LNQ06D0Z6CX6rp+ZiIauXB2bNwGe72IuD/Ytx1XmrN8BXm4uEPOqo 2sAkBjjbegzH2ojidOP3xNvBvOoQnqk=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 8 May 2017 14:31:29 +0100 To: Neil Jenkins , jmap@ietf.org References: <20170507123912.GA22520@snake.grepular.com> <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <3e948365-a783-adc5-13c4-906628159dc6@isode.com> Date: Mon, 8 May 2017 14:31:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------498C66627DE1DF267F6BFA6A" Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:31:32 -0000 --------------498C66627DE1DF267F6BFA6A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Neil, On 08/05/2017 07:19, Neil Jenkins wrote: > When considering this before, I've tended to observe the following points: > > * Standard mail clients generally fetch all mailboxes up front, and > indeed often need to before they will display a (non-loading) UI. > * The vast majority of users have very few folders (from what I > remember last time we ran the stats at FastMail, well over 90% of > users never created a single extra folder beyond the defaults). > > > So I therefore left out querying mailboxes (and so being able to fetch > them in pages) from the initial JMAP draft. The main case for this > seems to be presenting access to usenet groups or other > non-strictly-email stuff. There is always a question of whether we > want to support every use case, at the expense of making > implementation more onerous. Isode implemented a client that listed mailboxes level by level, due to constraint bandwidth. We also have several thousands of shared mailboxes (they have nothing to do with Usenet), I think some enterprise type deployments will be similar. So having a way of listing direct children and all descendants of a mailbox would be very useful for us. > Having said that, there's a standard mechanism in JMAP for doing > querying/sorting/paging of a record type (getFooList > ), so if we do decide we > want this capability it is mostly obvious how it should be specified. > We'd include a filter option for /parentId/ so you could easily fetch > as a hierarchy if you want, and it would be easy to add an isArchived > flag or similar later and filter on that if desired. > > As long as we still allow /getMailboxes/ to be called with a null > /ids/ argument (therefore returning all mailboxes), clients can still > just ignore all this if they always need to fetch the whole set up > front. It's mainly therefore an extra burden on server > implementations. So is it worth the tradeoff? Thoughts? I already wrote the server code for IMAP, so not much of a burden on the server side. --------------498C66627DE1DF267F6BFA6A Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi Neil,

On 08/05/2017 07:19, Neil Jenkins wrote:

When considering this before, I've tended to observe the following points:
  • Standard mail clients generally fetch all mailboxes up front, and indeed often need to before they will display a (non-loading) UI.
  • The vast majority of users have very few folders (from what I remember last time we ran the stats at FastMail, well over 90% of users never created a single extra folder beyond the defaults).

So I therefore left out querying mailboxes (and so being able to fetch them in pages) from the initial JMAP draft. The main case for this seems to be presenting access to usenet groups or other non-strictly-email stuff. There is always a question of whether we want to support every use case, at the expense of making implementation more onerous.
Isode implemented a client that listed mailboxes level by level, due to constraint bandwidth.

We also have several thousands of shared mailboxes (they have nothing to do with Usenet), I think some enterprise type deployments will be similar. So having a way of listing direct children and all descendants of a mailbox would be very useful for us.

As long as we still allow getMailboxes to be called with a null ids=A0argument (therefore returning all mailboxes), clients can still just ignore all this if they always need to fetch the whole set up front. It's mainly therefore an extra burden on server implementations. So is it worth the tradeoff? Thoughts?
I already wrote the server code for IMAP, so not much of a burden on the server side.



--------------498C66627DE1DF267F6BFA6A-- From nobody Mon May 8 07:14:29 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BC412948A for ; Mon, 8 May 2017 07:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 plwU386xXWBn for ; Mon, 8 May 2017 07:14:26 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934E2128961 for ; Mon, 8 May 2017 07:14:26 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 493B2FA0018; Mon, 8 May 2017 14:14:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1494252864; bh=18EEEtVGXv8s6gQf8S2nhIFr0e57oY/gxkOLCNAecTE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I4WowCSrOzKD2S444ffP8K68yyKEg8m6nSXq2dooA7qFCxa5kJR2koJ+KsJhclDBK EYlw+JouUsSxCYoJx2lJM7jRXz/chCo8t1fFvklslJBmivtM4dVPoUgxLp9i7HmLCI 4SA52wXOKeKH9pAQa5CmdEXlqrmWvWJFTMdegOv4= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1494252863-18908-21192/11/1; Mon, 8 May 2017 14:14:23 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 8 May 2017 15:14:23 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: <1494249269.88461.969397104.25D88F0A@webmail.messagingengine.com> References: <20170507123912.GA22520@snake.grepular.com> <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com> <1494249269.88461.969397104.25D88F0A@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 14:14:29 -0000 It's not clear that mailboxes really need to be hierarchical, and we've seen that the hierarchy stuff wasn't really well implemented by IMAP clients. It seems plausible that polling the complete list oftenish is unacceptable for at least some users, but an IMAP-like hierarchy is not the only way to cut bandwidth usage. Retrieving it once and then asking for updates would work too, like JMAP's in-mailbox updates. Servers that don't have a global modseq or some other generation counter would have to fall back to sending all/many mailboxes. Arnt From nobody Mon May 8 17:29:15 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE724126DEE for ; Mon, 8 May 2017 17:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=gaLduroC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gkENJvH7 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 O6ffkw3Yj99U for ; Mon, 8 May 2017 17:29:12 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61011126BF0 for ; Mon, 8 May 2017 17:29:12 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D379A2037D for ; Mon, 8 May 2017 20:29:11 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Mon, 08 May 2017 20:29:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= 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=fm1; bh=cAZbVPpLWJpeS3vxYtM/6HXFRZPVn eW1a/gmeomliM0=; b=gaLduroChUQxbIzEzIk2fmZo98NcDa4hz0rm1yxfGn7Gl YweuJBaehXCawY7ruqumrslUjwGLj+VL6KRhgcOsn+6B4NQYKwOQl9TPCUUjPrPH tavnfSdIPwFDn7LJDESoRPVu/k8RI35sop3P44HFUvVkW2RxAxrjDIVdlocTaB0/ Dfox98AVcjtcFg10XNju9XTOgkneCom4MgySHsniEqUvOSkGoPwnHLI9jYj4XqNw vk+i015aptDg1sAs+7V88W0lf72qqmJga2a9IqP7vPNX/zZvcKIhw4/73Hi9mWuZ 7sNRGYQJw4xxoIUNCgz7zb4zgM3S1AIjle9QbGg+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cAZbVP pLWJpeS3vxYtM/6HXFRZPVneW1a/gmeomliM0=; b=gkENJvH7Qa+chDBGtJpegY vMJW1qUC3f0w5Uuqbs0+8foBGnWN5rioZSei/sRpHFgbILRoTpZfgu6ZLDJRY8K0 N1K2V0EM1VLD8PjROiW7IE73xi6pETqIft8VXllo98XuhRXIXOX4rYU3yHkNabgh sp7jdQ2YOrNUhEV1y9c2TxFAsdOC0r0We3rLWXkDAw/b0kU+2wi0PmHxZWTYiYDJ xo7giV0iUfN1jrsZ/HxrcRqf1RXOu2Mvidu4Xus9GfoW/wc8tfoEZlgXXesx5JO2 KbAyc6Tnf1/z+RK7Vbv12mrIJ5eZmKHxGuFEix5uRKxNDudHZYiRy7qQT+JLJGMA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AC67862704; Mon, 8 May 2017 20:29:11 -0400 (EDT) Message-Id: <1494289751.131921.970152157.2A520058@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1 References: <20170507123912.GA22520@snake.grepular.com> <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com> <1494249269.88461.969397104.25D88F0A@webmail.messagingengine.com> In-Reply-To: Date: Tue, 09 May 2017 10:29:11 +1000 Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 00:29:14 -0000 On Tue, 9 May 2017, at 00:14, Arnt Gulbrandsen wrote: > It's not clear that mailboxes really need to be hierarchical, and we've > seen that the hierarchy stuff wasn't really well implemented by IMAP > clients. > > It seems plausible that polling the complete list oftenish is unacceptable > for at least some users, but an IMAP-like hierarchy is not the only way to > cut bandwidth usage. Retrieving it once and then asking for updates would > work too, like JMAP's in-mailbox updates. > > Servers that don't have a global modseq or some other generation counter > would have to fall back to sending all/many mailboxes. So if we have just a single sort (fullpath) and an optional filter on parentId plus windowing we can handle either nested or flat folder structures very easily and handle upteen million mailboxes comfortably as well. It seems viable to implement this even if you're doing depth-first traversal of a folder listing on a filesystem with no other smarts required, you can always use the path of the folder as the "id", though it will obviously not survive renames, so you miss that benefit. Bron. -- Bron Gondwana brong@fastmail.fm From nobody Mon May 8 23:21:26 2017 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FA3129AF2 for ; Mon, 8 May 2017 23:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=3byqTSnF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PMA7PBPY 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 DlCsPcXeo6UJ for ; Mon, 8 May 2017 23:21:15 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC1B129AF3 for ; Mon, 8 May 2017 23:21:15 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 6254D209CA for ; Tue, 9 May 2017 02:21:14 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 09 May 2017 02:21:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= 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=fm1; bh=dwfOl3i+ZqkOX2dsRXAjk2t4CItAe 16j4UeGDgvZaDM=; b=3byqTSnFWYUmH9N6O9CC/WHQols0YwBlcUxgenYCL8s1r G/+PUEgOd5Eo6pBkIAhFb48wWsQlhwJmtj9Q5kjrs1n3+4/N8p8v3IiR2aJThXM9 BQexqTDpJbG/Ghhqd5TuApjKSUu3NIC03UuCPW3+qLrdHNumQyOPeLNyQ+dUmmIb oqnY0k1jVfpvYPI9f1SWEQEeCxd9s7bbSvXCdiGJMHFMTGTcgIluQokrUhQkZ2/6 SA40HuTrKkwJ2glOup9nUO9i5EpDZBoqlzK6W4vI6WqfPfEGyIciE3vOLRWYZAmT WIdilncmijYC5JxPvkH2k2EkfGojyEXq6F9QzFS8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dwfOl3 i+ZqkOX2dsRXAjk2t4CItAe16j4UeGDgvZaDM=; b=PMA7PBPYEC8m3pfGFWV5/2 2ABFfllMCUmDQh2mTC24n621cE+2EbCpJKcKvLGHplzItYEPyIjUuWqelU8N4Vqt GksM/ppLIqjUsRq0OLAquNIvw5ZaczMwsew8K8qpxc8Ho0FlMSNPGBQOSwop846e V5Nblpy8wNgMuWn/l0C7u7INFFjK0C6A6iQRNMOr95wYj1PBYZRFv2QrEbs9H8On novYDAf9l771JZMiEmW4drj7W6SWd65pDWl7nJ/cpE8az7LdifUKucLOKITw/a8Q k9njdRl9OJ76AloAgtOmQoBz3ZIs7BNb3ehTQQC8m8Y7ruovCzogG+nkj1Wxx3hQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 21820E2689; Tue, 9 May 2017 02:21:14 -0400 (EDT) Message-Id: <1494310874.2734294.970377357.2792F254@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149431087427342940" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e7edfd09 In-Reply-To: <1494289751.131921.970152157.2A520058@webmail.messagingengine.com> References: <20170507123912.GA22520@snake.grepular.com> <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com> <1494249269.88461.969397104.25D88F0A@webmail.messagingengine.com> <1494289751.131921.970152157.2A520058@webmail.messagingengine.com> Date: Tue, 09 May 2017 16:21:14 +1000 Archived-At: Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 06:21:25 -0000 This is a multi-part message in MIME format. --_----------=_149431087427342940 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" OK, there seems to be some agreement that this ability is desirable and not going to cause significant downsides, so I'll put together a pull request for the spec for people to review. Neil. --_----------=_149431087427342940 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
OK, there seems to be some agreement that this ability is desirable and not going to cause significant downsides, so I'll put together a pull request for the spec for people to review.

Neil.
--_----------=_149431087427342940-- From nobody Wed May 31 05:03:26 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB04C1275AB; Tue, 30 May 2017 21:15:03 -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: jmap@ietf.org, brong@fastmail.fm, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149620410389.19925.11594802298189159020.idtracker@ietfa.amsl.com> Date: Tue, 30 May 2017 21:15:03 -0700 Archived-At: X-Mailman-Approved-At: Wed, 31 May 2017 05:03:25 -0700 Subject: [Jmap] jmap - New Meeting Session Request for IETF 99 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 04:15:04 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 60 Conflicts to Avoid: First Priority: calext People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Flipcharts: please specify number in Special Requests field Special Requests: 1 flipchart would be useful for drafting ideas --------------------------------------------------------- From nobody Wed May 31 05:34:32 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A35129BDD; Wed, 31 May 2017 05:34:30 -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: jmap@ietf.org, jmap-chairs@ietf.org, barryleiba@gmail.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149623406997.19805.5724637469398179973.idtracker@ietfa.amsl.com> Date: Wed, 31 May 2017 05:34:29 -0700 Archived-At: Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 99 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 12:34:30 -0000 An update to a meeting session request has just been submitted by Barry Leiba, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 60 Conflicts to Avoid: First Priority: calext dmarc dcrup uta dispatch People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Special Requests: 1 flipchart would be useful for drafting ideas ---------------------------------------------------------