From nobody Sun Sep 3 18:14: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 56F27132705 for ; Sun, 3 Sep 2017 18:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=jYr75xfA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UDyfM3eB 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 tGntlHToeMT0 for ; Sun, 3 Sep 2017 18:14:24 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15BC132494 for ; Sun, 3 Sep 2017 18:14:23 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 03E0F20A83; Sun, 3 Sep 2017 21:14:23 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 03 Sep 2017 21:14:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0Vijpg R8lThy6SQGp+Ac+WWEzmTgucyCJ1z1RpQFsgk=; b=jYr75xfAVs6tAlqidh+ShG JpkVeQNt/UvZhrdy1XmIVDha9F6XzVzWTXwG7zkQ4QzVN6lNWU5WXVxmPQ7CxGAO wJDbITNA+Mv258Yrkd6BxIUAamLfBRlMYL6/wPjdtnzySHLUCyJvRi26X3c7KlbZ fQsdOuSbr5qToYCafgZQwlkZ78WkQgAF4C/40rUYiY4Vj50MTuKRQ6CIspXveabA 8jlBVWp9+qHt9somwS5eUXwJt0Sb+duzJo+Fv7KLqpteqI8PRZs7qJnk1IGup04C rPjx3K6am4WPjh2dswovkL9chBFuwgUxg0cAI6cvdlX+fhYxVWn1S7IelwrwjOsw == 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=0Vijpg R8lThy6SQGp+Ac+WWEzmTgucyCJ1z1RpQFsgk=; b=UDyfM3eB6YVHV3A8y6SVzw bFQg9ZQt5H211vBx3HTYp+zmt1ebfjxHI/1GBweiI2pnUOtAzbCMynxgTrxhSA65 NoWlw4FAFaFFtdH+oh0mkOUA31RENGiBHuacT038409mCN1aK9oy3KXIVfJgMaFr nZ/1MDodYms2p6cIAfIjv4Z5K0kIUvyR8a2d8HCTZ6b9toC2LR+B4J3om2Fgw8ry eey/Rax6+UwYMoeIYenxhLq0+0+tjgrjgo3J6C0XPnluXruNYAfAgF/Xzxu6JKWA jZaRhyYE+gvYW+OI/0XdUDXbWOmrlB3P97+UgejpYgW3lqUwnlg1eJufRPdluNZw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A4F44E25A5; Sun, 3 Sep 2017 21:14:22 -0400 (EDT) Message-Id: <1504487662.1436862.1094151112.22E0C8DB@webmail.messagingengine.com> From: Neil Jenkins To: Chris Newman Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150448766214368621" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 Date: Mon, 04 Sep 2017 11:14:22 +1000 References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <0F44D4FC-52D0-47B2-A412-95B739B8FA85@oracle.com> <1504142657.4136419.1090521048.0D0A3C8E@webmail.messagingengine.com> <2B534D34-C93A-4D04-86B9-0989C97F18AB@oracle.com> <1504161087.242402.1090702816.36084ECD@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [Jmap] MessageSubmission last call 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, 04 Sep 2017 01:14:25 -0000 This is a multi-part message in MIME format. --_----------=_150448766214368621 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 1 Sep 2017, at 03:56 AM, Chris Newman wrote: > Actually, the "status" and "diagnostic" fields in the DSN are a > new SMTP> reply so I presumed that would replace the old one. If you just want > to> save only the SMTP submission reply, or only SMTP replies seen by the> local ADMD the field definition needs to say that. Ah right, yes I presumed the *smtpReply* field would only be the last reply seen before it left your local network. But actually, it probably makes sense to also update this if you receive the DSN. Anyone got a good argument either way? If not, I'll make the spec say it should be updated from the DSN. >>> So is that DSN left in the INBOX because the final-recipient doesn't>>> match a RCPT TO address, or does it get correlated into the >>> MessageSubmission DSNs field based on the original-recipient field?>> I would say this should be correlated based on the original-recipient>> field, so this would be considered a successful delivery. > > Yes, but which address is used as the key in the map? Does the status> appear under both addresses, or just the original recipient? The map is from the email addresses that was supplied as the RCPT TO to the current delivery status, so this means only the original recipient address appears. Neil. --_----------=_150448766214368621 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 1 Sep 2017, at 03:56 AM, Chris Newman wrote:
Actually, the "status" and "diagnostic" fields in the DSN are a new SMTP
reply so I presumed that would replace the old one. If you just want to
save only the SMTP submission reply, or only SMTP replies seen by the
local ADMD the field definition needs to say that.

Ah right, yes I presumed the smtpReply field would only be the last reply seen before it left your local network. But actually, it probably makes sense to also update this if you receive the DSN. Anyone got a good argument either way? If not, I'll make the spec say it should be updated from the DSN.

So is that DSN left in the INBOX because the final-recipient doesn't
match a RCPT TO address, or does it get correlated into the
MessageSubmission DSNs field based on the original-recipient field?
I would say this should be correlated based on the original-recipient
field, so this would be considered a successful delivery.

Yes, but which address is used as the key in the map? Does the status
appear under both addresses, or just the original recipient?

The map is from the email addresses that was supplied as the RCPT TO to the current delivery status, so this means only the original recipient address appears.

Neil.
--_----------=_150448766214368621-- From nobody Sun Sep 3 18: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 DEEAF1328EA for ; Sun, 3 Sep 2017 18:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=nBITxHzV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d6rRIMoR 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 ww5VuojH9IO2 for ; Sun, 3 Sep 2017 18:39:53 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6B6132803 for ; Sun, 3 Sep 2017 18:39:52 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 512B320997 for ; Sun, 3 Sep 2017 21:39:52 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 03 Sep 2017 21:39:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=TDYvx/ZeXsMchNZsa +If/+8AYTEGxTp/hInT1Ff5GS0=; b=nBITxHzVmIX5Z7FtqofmOZX6cAG2vuG/g 1b85DUijJkNz4xOKwlhafPM9xI2XwNgSGd7iz/V4jVfRVw4uD0gh/+iuqSWHqryk StWzAEErYHWc8S32UglbveydwcQ6oR4zIrxINtRKI3H2Qc0oTlAAR8dIZS7RYS41 qFaNr/8oxke+Fnghhpnymavv7/OWUmDaHlCbHvyzRn+hqfFAGRftVQP3y8psoTOL DoRLmu9gl1HL9WbkrORmIZg9h/9RgeR3YgyNIidngbYCzDwMytMrJ9zzD4IHpaQO F15PFv4cqH5Vvy9JBKpqeAt31gSa71bKsDc7wjdNE0khhdkekm0WQ== 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=TDYvx/ ZeXsMchNZsa+If/+8AYTEGxTp/hInT1Ff5GS0=; b=d6rRIMoRQhiPYyUZ24suVE nkEYFEaTYStCZuF8rqQE4QUbHKc7qFtgr7fZ87zBjuEmlP27Yekf3gFZQAIbtYac HMBk6yR1TuUp7Cm/uPNDWyXhdjW8xr++tx0bI8iFY2/WDyMN+oKrfPMy3UOCiGdZ YPr/5O4gBkKE4TZzfpw/Lm7s20eDsIKhh13QinH5PPrqcyV+whWkHdw0qVqP2OFi vcPdmjKD9uIKFlj9VKlXza0YDKajoFOHAhI4FjDaNymFzSvHcf4MjEWGb1Q3twqd cr0iJjpZUX9kACWWuMwDxLhbC53TNsbV+4X8oubSvbB1+ehYgNts804rU8+w5Rrg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F2433E25A5; Sun, 3 Sep 2017 21:39:51 -0400 (EDT) Message-Id: <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150448919114650210" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 References: <20170726141022.GA1352@meili> In-Reply-To: <20170726141022.GA1352@meili> Date: Mon, 04 Sep 2017 11:39:51 +1000 Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 04 Sep 2017 01:39:55 -0000 This is a multi-part message in MIME format. --_----------=_150448919114650210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Sorry for the very late response to this. I'm back on JMAP spec work at least every Monday now, so I hope to crack through the emails and issues in the run up to IETF 100 in Singapore. On Thu, 27 Jul 2017, at 12:10 AM, Josef 'Jeff' Sipek wrote: > Why is accountId required in the [download] URL? I don't see a reason > why a server> couldn't use blobIds that either have internal structure to= correctly> determine the accountId, or to not care about accountId at all. All ids in JMAP are scoped to a particular account, and this includes blobIds. Depending on how your server works, you probably need to know the account in which to look for a particular blob, so it needs to be in the URL. You could just include it in every blobId, but why make all the ids longer when you don't really need to? > I'd expect the spec to say that the URL MAY contain accountId We could make the accountId optional in the download URL; it should pretty much make no difference to the client. Then if you don't need it on the server you can just exclude it from the URL template. > Should the spec provide some guidance how far into the future the > expiration date should be? Yes, it should. Probably 24h is a reasonable minimum. > Should it explicitly point out that the timestamp is purely > advisory, and> the blob may disappear at any time for a variety of other = reasons? Probably yes! I've created Issue #140[1] for these two comments. > If identical binary content is uploaded, the same __blobId__ SHOULD be > returned. If the same blobId is returned, should the expiration date > be bumped as if it were the first upload of the blob? First off, I'm going to change that SHOULD to a MAY. It's more efficient to dedup, but easier not to. I think this is legitimately a choice for the server based on its architecture. Regarding the expiration date bump, probably yes again. > Once a blobId is used by an object (e.g., via setMessages), is it > supposed to be still accessible via the same blobId? Or can the > server move the> data associated with the blobId out of the "pending blob" > storage into a> more permanent place and in the process generate a new bl= obId? The former option is more efficient (and certainly what I would do if building a new server from scratch). However, I think we need to allow the latter for ease of implementation on existing systems; this will require a few changes to the spec, but I don't think it's too awkward. Basically in response to a standard create/update, the server returns any properties that it changed that the client didn't explicitly specify, so if the server needs to change the blobId it can return the new one, but otherwise the client can presume it's unchanged. I've created #141[2] for this. > it is easy to run into a ugly scenario where a client wants to save a > draft with two large attachments with quota enabled.> [=E2=80=A6] > I think it would be good for jmap all requests to either succeed or > fail in a way that tell the client what can be done to get more > forward progress (even if it is sub-optimal) or that there is no way > forward. In this particular example, the issue is that the > invalidProperties error returned from setMessages covers multiple > situations. At least some of them are:>=20 > (1) client error: the client didn't upload the attachment before > trying> to reference it > (2) blob expired: the server removed the blob because it remained > unreferenced for too long > (3) blob evicted: the server removed the blob early because of over- > quota> situation, etc. Both (1) and (2) of course just mean the client has to upload the attachment. But yes, I agree the eviction case is problematic. The way I was thinking about it was that eviction is an edge case just specified to allow the server to stop abusive behaviour. I was presuming your temp space has a separate quota to your regular space, which should make your issue very unlikely. If you had a (say 250 MB) temp space quota (and we presume a message has a max 50MB attachments limit), you're unlikely to get eviction unless the client is doing something either malicious or stupid. If I note this in the spec, does this resolve your concern? If not, do you have another suggestion for how to provide limits that stop malicious/broken behaviour from causing issues? > By the way, a number of the HTTP status code descriptions > include: "There> is no content in the response." Is that saying that the= response body> SHOULD be ignored? Or that the responses' Content-Length M= UST be 0? I was presuming Content-Length MUST be 0. But it might be helpful for servers to return diagnostic text here, so I'm happy to just change it to "Clients SHOULD ignore the response body". Do you think this is better? Cheers, Neil. Links: 1. https://github.com/jmapio/jmap/issues/140 2. https://github.com/jmapio/jmap/issues/141 --_----------=_150448919114650210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Sorry for the very late response to this. I'm back on JMAP spec = work at least every Monday now, so I hope to crack through the emails and i= ssues in the run up to IETF 100 in Singapore.

On Thu, 27 Jul 2017, at 12:10 AM, Josef 'Jeff' Sipek wrote:
Why is accountId required in the [download] = URL?  I don't see a reason why a server
couldn't use blobIds that either have internal structure to correctly<= br>
determine the accountId, or to not care about accountId at all.

All ids in JMAP are scoped to a particular account, and this includes = blobIds. Depending on how your server works, you probably need to know the = account in which to look for a particular blob, so it needs to be in the UR= L. You could just include it in every blobId, but why make all the ids long= er when you don't really need to?

I'd expect the spec to say that the URL MAY = contain accountId

We could make the accountId optional in the download URL; it should pr= etty much make no difference to the client. Then if you don't need it on th= e server you can just exclude it from the URL template.

Should the spec provide some guidance how fa= r into the future the
expiration date should be?

Yes, it should. Probably 24h is a reasonable minimum.

Should it explicitly point out that the time= stamp is purely advisory, and
the blob may disappear at any time for a variety of other reasons?
=

Probably yes! I've created Issue #140 for these two comments.

If identical binary content is uploaded, the= same _blobId_ SHOULD be returned. If the same blobId is returned, s= hould the expiration date be bumped as if it were the first upload of the b= lob?

First off, I'm going to change that SHOULD to a MAY. It's more efficie= nt to dedup, but easier not to. I think this is legitimately a choice for t= he server based on its architecture. Regarding the expiration date bump, pr= obably yes again.

Once a blobId is used by an object (e.g., vi= a setMessages), is it
supposed to be still accessible via the same blobId?  Or can the = server move the
data associated with the blobId out of the "pending blob" storage into= a
more permanent place and in the process generate a new blobId?

The former option is more efficient (and certainly what I would do if = building a new server from scratch). However, I think we need to allow the = latter for ease of implementation on existing systems; this will require a = few changes to the spec, but I don't think it's too awkward. Basically in r= esponse to a standard create/update, the server returns any properties that= it changed that the client didn't explicitly specify, so if the server nee= ds to change the blobId it can return the new one, but otherwise the client= can presume it's unchanged. I've created #141 for this.

it is easy to run into a ugly scenario where= a client wants to save a draft with two large attachments with quota enabl= ed. 
[=E2=80=A6]
I think it would be good for jmap all requests to either succeed or fa= il in a way that tell the client what can be done to get more forward progr= ess (even if it is sub-optimal) or that there is no way forward.  In t= his particular example, the issue is that the invalidProperties error retur= ned from setMessages covers multiple situations.  At least some of the= m are:

(1) client error: the client didn't upload the attachment before tryin= g
to reference it
(2) blob expired: the server removed the blob because it remained
<= /div>
    unreferenced for too long
(3) blob evicted: the server removed the blob early because of over-qu= ota
    situation, etc.

Both (1) and (2) of course just mean the client has to upload the atta= chment. But yes, I agree the eviction case is problematic. The way I was th= inking about it was that eviction is an edge case just specified to allow t= he server to stop abusive behaviour. I was presuming your temp space has a = separate quota to your regular space, which should make your issue very unl= ikely.

If you had a (say 250 MB) temp space quota (and we presume a message h= as a max 50MB attachments limit), you're unlikely to get eviction unless th= e client is doing something either malicious or stupid.

If I note this in the spec, does this resolve your concern? If not, do= you have another suggestion for how to provide limits that stop malicious/= broken behaviour from causing issues?

By the way, a number of the HTTP status code= descriptions include: "There
is no content in the response."  Is that saying that the response= body
SHOULD be ignored?  Or that the responses' Content-Length MUST be= 0?

I was presuming Content-Length MUST be 0. But it might be helpful for = servers to return diagnostic text here, so I'm happy to just change it to "= Clients SHOULD ignore the response body". Do you think this is better?
<= /div>

Cheers,
Neil.
--_----------=_150448919114650210-- From nobody Sun Sep 3 21:54: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 4A233124207 for ; Sun, 3 Sep 2017 21:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=qtcUY5yG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D3TFrrgt 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 jBqKEp0koQ5h for ; Sun, 3 Sep 2017 21:54:14 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E81F1204DA for ; Sun, 3 Sep 2017 21:54:14 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id C5C7D20977 for ; Mon, 4 Sep 2017 00:54:13 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 04 Sep 2017 00:54:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=ZQHsh6623ZBGJPs9tLMc+cAle/PqIxkK+klkvwQWz TM=; b=qtcUY5yGTTCPgiVa5wmq8C+sx1oC3OQjJKp9XnPSyY31uClc1MXBeTUV9 QHXbdrsKccdRGq+cWxXzkNtCE61oP7XLQJ/Mi3O3+347g2Y2VQUd3h6S7PlkXDM/ 04vH1EqUkVe33uTXDjqWhDt8bXwx0UiASDnpeJwVkgagnzshXeu25aLXH647HQ5I Q7B8IwC3rLFzC6sBj7ectxjNJc0bAnnr7p2L0wS+CgM/r996xo784FML6wms3MXS XZuihp3bL84LiXnisnC0CZjYAl9GkCdr+jFCF/xC5KPGw6iv3HNuuzjrX4Ikgulw ru0TlEjp9mShh+sKf1RZGL26SGACQ== 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=ZQHsh6623ZBGJPs9tLMc+cAle/PqI xkK+klkvwQWzTM=; b=D3TFrrgt44mO0g7fNFCF+IP5j1s92TRpgYPnQHmN45595 HTJ7XLsUYvlXT2v7Oo7oV7zrFxZwdctpmCLskrdx+Cnc9cT64ePSAn04wm+fmHXR dKDNDvRDOqhKlzT8hrk2SWWLE/x8pNX/b3MhHMub7oRm2xwbU67BdZLmMrHw00Om QLxu+94DYs23wIejlAE3bWyVwb3xziGxdyTGhlC+kDY2a5F2bkpwQLa8MqP9hX6F 2mfngNcBn+8hNT9xUOF7QFHWNkQIOW3KWEGOgOWXfnS87mthxXhTzFEHT3Uk8r1s 63hgtyRD7kNT+WAkymhYCSUoBkIMqhJUCOFSZRRGQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 84316E24A8; Mon, 4 Sep 2017 00:54:13 -0400 (EDT) Message-Id: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150450085316310390" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 Date: Mon, 04 Sep 2017 14:54:13 +1000 Archived-At: Subject: [Jmap] Destroying mailboxes: how this affects messages 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, 04 Sep 2017 04:54:16 -0000 This is a multi-part message in MIME format. --_----------=_150450085316310390 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" As per #69[1], this needs some discussion. If a mailbox has messages in it and the client tries to destroy it, what should happen? The spec currently says this must be rejected with an error, following the general JMAP philosophy that changes made by the client must be explicit rather than implicit. The IMAP model is of course different: the messages in the mailbox would be implicitly removed from this mailbox, and if not in any other mailbox they would also be permanently destroyed. This is why I think this model is dangerous. In a system where messages can belong to multiple mailboxes, removing a mailbox (deleting a label) makes sense, but you don't want the message to be destroyed. However, for IMAP compatibility we require all messages in JMAP to be in at least one mailbox. So if this was the only mailbox the message was in, the message must also be either destroyed or automatically added to another mailbox (which I think is even more problematic). Making it an error requires the client to deal with this situation first in an appropriate way. Opinions on the right action here? Neil. Links: 1. https://github.com/jmapio/jmap/issues/69 --_----------=_150450085316310390 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
As per #69, this needs some discussion. If a mailbox has messages in it and the client tries to destroy it, what should happen? The spec currently says this must be rejected with an error, following the general JMAP philosophy that changes made by the client must be explicit rather than implicit.

The IMAP model is of course different: the messages in the mailbox would be implicitly removed from this mailbox, and if not in any other mailbox they would also be permanently destroyed. This is why I think this model is dangerous. In a system where messages can belong to multiple mailboxes, removing a mailbox (deleting a label) makes sense, but you don't want the message to be destroyed. However, for IMAP compatibility we require all messages in JMAP to be in at least one mailbox. So if this was the only mailbox the message was in, the message must also be either destroyed or automatically added to another mailbox (which I think is even more problematic). Making it an error requires the client to deal with this situation first in an appropriate way.

Opinions on the right action here?

Neil.
--_----------=_150450085316310390-- From nobody Sun Sep 3 23:04: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 B6EED1201F8 for ; Sun, 3 Sep 2017 23:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=efY6c/lk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G1pDD9Hw 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 nMNqN0tHitUQ for ; Sun, 3 Sep 2017 23:04:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B869124239 for ; Sun, 3 Sep 2017 23:04:29 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 6183C20B90 for ; Mon, 4 Sep 2017 02:04:27 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 04 Sep 2017 02:04:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=9LdAAal/Qd9fq/NRp 9C75b9rGPzTPTbM+Bet6BOCsaM=; b=efY6c/lkUg715hblaOZNqA4epLM+cTN1k rl4iG/8Uan1ykADVTW89YCVeOloucFIvsxNDN8CAOnkeQIvldvImYBRJUGr2J4yo FDJZ1K3zN9rKqeLqpDcujrJm+EsFhOnarD1HQGs+LKVIG9CvrYZU6eBPO3yU5Vtz jA5NxQnXfo/mffq9XWZpMiUd3J5i4dAAGUYjIVYp8baaHTWZtYEk/IbvDvMvrkvy zMr/2cnsxaIVKTg+3TD3jaUuXlu8Odf9S6ucg/6sECd+8dw1a0RVp4D7lWkAAMne +IVrNvFTaiVxZ5Jhzv/K3+LOfRaOIDJYF1ZQoNsHMwe6Ge2GghPsg== 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=9LdAAa l/Qd9fq/NRp9C75b9rGPzTPTbM+Bet6BOCsaM=; b=G1pDD9HwEYV9+7NwZ9RRpT 5MEpPKQ/j0M0913ojYxK7JQaufKHf/a2eaAag6mLg6URz+aikaBH+zjQtjaxlY7c xW3Bc2+uNPafbp1DwKaDbobY9kLBMCTBcoAmGgjuAJMKYCj55Kb6cU6JJQdi3cRj +td5ZhVidChPa9j4FEdZgMYYCPuAxuz8yMT/4oRghzCPA29WB3HZFGnTa0e96K0S Dk4HXfdYfpapQKhYB6PpeCHSunnnYpREqYP0V+0vCq87Zo4vFBZCdbzT1hVZ/mkY gZfGt1h8MaUCVkjG5c7DmgDKei0Zh+un14+kcR19A1w5+O8xuCUkbQKWON+22k5A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1BA8AE24A8; Mon, 4 Sep 2017 02:04:27 -0400 (EDT) Message-Id: <1504505067.1680508.1094305688.5D5D1247@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150450506716805080" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> In-Reply-To: <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> Date: Mon, 04 Sep 2017 16:04:27 +1000 Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 04 Sep 2017 06:04:31 -0000 This is a multi-part message in MIME format. --_----------=_150450506716805080 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I've created https://github.com/jmapio/jmap/pull/142 to address the concerns raised in this thread; please review and add comments directly on the pull request or via the mailing list. Thanks! Neil. --_----------=_150450506716805080 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I've created https://github.com/jmapio/jmap/pull/142 to address the concerns raised in this thread; please review and add comments directly on the pull request or via the mailing list.

Thanks!
Neil.
--_----------=_150450506716805080-- From nobody Mon Sep 4 05:33:39 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 4AC1013293F for ; Mon, 4 Sep 2017 05:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Mkg8Bq2IOBvn for ; Mon, 4 Sep 2017 05:33:36 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 0420E13293A for ; Mon, 4 Sep 2017 05:33:36 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id b82so1234707qkc.4 for ; Mon, 04 Sep 2017 05:33:35 -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=iY6GD2s7F/brBR2dj4IlYboCRelCCFE49q5Mbhho4P0=; b=yXl2fyCFMZxnyRKjKt5e1Bi2cztTP3VFuyZ8IRbl/k82VkXPgxYKnTIHlNGIwIsjWQ EBuIoFKAllLTTjt+YbO0+/nA7DIH2MLDu2hPmjLJQWt0kGNXSASs6Vd8mVaNheVDMO1G 5/DVfI1JoB2mMSLeKNuX0kGQq5K+aFYhnjd09TTpN96cwCSCwkHh6k4N/AHpCRK2HZDE U140fLRl9zMvB1SKM2At4x8WM8kxxdHpyMF67toXt3Xv0Q9wkYS6fRtuUWMZ0lcraiGs F+g4+SGF+3ISrK5RiTEnMtfmdFlonsXo29HSkFIXyNSdFyzSgXo88TiwxO7PXmES8udI tZFA== 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=iY6GD2s7F/brBR2dj4IlYboCRelCCFE49q5Mbhho4P0=; b=paystVjDkmEBB7SVqTq0MNFFHxN+8KOwqGTFhCKLeX0FGPmYDgVMhrA3m0nKGC5aUe W30TONNYFw342igIpyN1yj/JNsMmfDOF96e8U+h/iMxdkDlXPHxOK9OJpip0q54YxwPD nKsdtumhhZWXKoToU1/m/CNDuzIXMls/vb+bwbj38khnlSF+9j2V+kYmpHzGZYuZtvJF uwNiwuVqLUrqE7FwN3xZ+1YDwwW5RNZPhNkNMFjkNwsz9hBKa76Pmz5pMe3vEUaFgsJ5 0mwl+75QX/X9tshyChallm2iVE1Npc/kZhpljS484bIp06Bbvn+GvK9XLuHf0RshfOie R4MQ== X-Gm-Message-State: AHPjjUh48JMmv07Yo6RrjE6sYM8ARwpwXB1wK/ZeyCKs104VZMNNxGbR PYAEXq5cUc8/LzQSptHvMQ== X-Google-Smtp-Source: ADKCNb7NBOtBJyKjUpVrYDrKnXR73+Jck2hv9RS6ksTGkn9WYxithnRZ107sPeOTqY6syaNY0460iw== X-Received: by 10.55.133.68 with SMTP id h65mr537134qkd.15.1504528414728; Mon, 04 Sep 2017 05:33:34 -0700 (PDT) Received: from [10.1.41.114] (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id a12sm4883777qta.90.2017.09.04.05.33.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 05:33:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5368a) In-Reply-To: <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> Date: Mon, 4 Sep 2017 08:33:32 -0400 Cc: IETF JMAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> To: Neil Jenkins Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 04 Sep 2017 12:33:38 -0000 On Sep 3, 2017, at 9:39 PM, Neil Jenkins wrote: > First off, I'm going to change that SHOULD to a MAY. It's more efficient t= o dedup, but easier not to. I think this is legitimately a choice for the se= rver based on its architecture. Regarding the expiration date bump, probably= yes again. Are you sure this is a good idea? This sounds like a gateway to the kind of= inconsistency that plagues users of imap: the mua can=E2=80=99t depend on s= ome useful behavior of the server without creating weird ui artifacts. I ha= ven=E2=80=99t been able to follow this in enough detail to be sure it=E2=80=99= s a problem here, but it sounds like one. Isn=E2=80=99t it useful for the mu= a to be able to count on the id being unique?= From nobody Mon Sep 4 05:41:24 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 E26B91326FE for ; Mon, 4 Sep 2017 05:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ebk9nzzW2m5Y for ; Mon, 4 Sep 2017 05:41:21 -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 7D19113293F for ; Mon, 4 Sep 2017 05:41:21 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id i50so1518599qtf.0 for ; Mon, 04 Sep 2017 05:41:21 -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=82EQPGHFyAnnn0immX6zSY5QF9xhUXy8cbF/68rDEMQ=; b=ESu1EO33wJup7xmAlZIAVaRtWJj8rUBvQAsKlEHqAULHm3eukfRNImpEspdc8QlGSz MMeXJcPj1C9V8bXmkRtulYDBWS6djMe4wJ28LR8qs69HqcanKqHy2Tc20kk4GCrxBPsw JBOiPcC+ZtF6zW5752kREXSRHbvPjk+nPMwHAodk3al+xJjS/A3UPCXAXZnrH5BZzJPU o/4rIqfqsFXM0K/mQDoXPA1a1idPcO59iJFijBedEMrC2kFOytAdSIwePjVpR4BvI8qH Fi9VDR8hmG/tnnjAIIL8/geNvOLtoI2JCfblgbC1ozZwK9kzYqk9m8QhkLQNm2YLLvuO nb9w== 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=82EQPGHFyAnnn0immX6zSY5QF9xhUXy8cbF/68rDEMQ=; b=FZGh6pu15wZA8GspTOaZFv8lWlBIMv57i0+uLPktwHDiw4yOyKvaLtbsbyrn0nonKN Rj22xhZICivX/FQydswvk7hGuLKVXI01k4WHsdg6QopAQqpBeXCYdL3zNk8Ek1wLiX8b QUGASXX1j1UdlZ5bD09U8okrRM97MRf2Mk02ONrcirotgQb7IFLlQk86qCnrjbZht8Jd CDQ5TC+0Pt92tBoGS6SEZC89dD/URNzPq0MITwGAu1YURgHo+wWmIZwWHfDaw+VX+BGI RnxRp/OQoc4DxAzgqkkZGkzBeZ+gI4roSjpNaxhyZEv1eKlnCagIIOfx3SJhBg8LmqZ5 nBtA== X-Gm-Message-State: AHPjjUjUfQv7HKB4q2f1TJAdhbQVUrCIZH6d7KWMZu8O+GvJsuVt2UJo K6GpKWhAwfXhJWzrv0DOrA== X-Google-Smtp-Source: ADKCNb6GFGNXqwR/khSo7pmqPMTGexuHkw5H/otMpJRCkOx/+yVoTE+3tutrrXMy6Ba52BNhVDCsVQ== X-Received: by 10.200.47.16 with SMTP id j16mr376876qta.161.1504528880174; Mon, 04 Sep 2017 05:41:20 -0700 (PDT) Received: from [10.1.41.114] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id m3sm3488371qkb.93.2017.09.04.05.41.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 05:41:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5368a) In-Reply-To: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> Date: Mon, 4 Sep 2017 08:41:18 -0400 Cc: IETF JMAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> To: Neil Jenkins Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 04 Sep 2017 12:41:23 -0000 On Sep 4, 2017, at 12:54 AM, Neil Jenkins wrote: > Opinions on the right action here? Have a mailbox called "all" that every message is always in. Or, as you say,= make it an error to delete a non-empty mailbox. But I prefer "all" because e= nforcing that restriction could be incompatible with a label-based inbox par= adigm, where we would expect labels to potentially be quite ephemeral.=20= From nobody Mon Sep 4 05:44:08 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 1F7D21326FE for ; Mon, 4 Sep 2017 05:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=M/C8xrUb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N9zszHko 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 GiScltuxPI4K for ; Mon, 4 Sep 2017 05:44:04 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9958A132992 for ; Mon, 4 Sep 2017 05:44:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E3CF320C77 for ; Mon, 4 Sep 2017 08:44:03 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 04 Sep 2017 08:44:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=NYovoOWYmDetXL8s4 MZon+E17SN/m2DL079VfFtBxYQ=; b=M/C8xrUbPp4R1kNMsGjKdy08IpZ0C2L8E C/N/dLI18QdvY9JqTUJowALq02QY5tML8G9OF+Qj270DkeIF/4elbI0lD058/XfS 593Klm8OSurKWZVzjHqjNcBEQ/pRbYkesuMvOFr5T4ZcjRa5sI0iLZau1GFrCON/ 5GdHvEm+BH96qzXpZKFxGl3Bc+8gMWTt8sq9rZCUtcq8/S+EnbjshAEmfIK17JMr dmj8rhZv1vIYvjfgyTujvmq/TJADE+j2kGG6dGiPSgxbqNenDAxR+m28mPeYRgHi nB+UMfXg0zHtMmZH5fFxSt+wcsVnrJgiOjn7ikuU/DlqFI+HbYyOQ== 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=NYovoO WYmDetXL8s4MZon+E17SN/m2DL079VfFtBxYQ=; b=N9zszHko/ZNpUqRgOgpuOf Hi4GrQMNYGiTG9hJV0VgYptF3bQNYYW3EjkZIzCM48yB1uxiXc80TBEeMdNzgSjD FwAqiyZfMkn85NwVHxVlFCbZwEvYgw1CefFucacuPMdSyNFSzNpmyt2Tv8yGaWEu YBdEOjESHEUn7kX3d44pbxwz4qVdrw3hjk8AB53mz0dTnc51pC8fmbYrTfM2qcbB kTu6BvJAjInJuJdHupFjHhLsu/y5KKXCi7E8FYV6Ki3W3huuEbg3n51ewIfLhpG5 1E/S1lK/JyR8tf9fqAoX+uQAhKtbMwoI/7XXji85UZm46zcAvjjo6CjjauBA9l/w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B4B68BAB76; Mon, 4 Sep 2017 08:44:03 -0400 (EDT) Message-Id: <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150452904324960900" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f7b75467 Date: Mon, 04 Sep 2017 22:44:03 +1000 In-Reply-To: <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 04 Sep 2017 12:44:07 -0000 This is a multi-part message in MIME format. --_----------=_150452904324960900 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Mon, 4 Sep 2017, at 22:33, Ted Lemon wrote: > On Sep 3, 2017, at 9:39 PM, Neil Jenkins > wrote:>> First off, I'm going to change that SHO= ULD to a MAY. It's more >> efficient to dedup, but easier not to. I think this is legitimately a >> choice for the server based on its architecture. Regarding the >> expiration date bump, probably yes again.>=20 > Are you sure this is a good idea? This sounds like a gateway to > the kind> of inconsistency that plagues users of imap: the mua can=E2=80= =99t > depend on some> useful behavior of the server without creating weird ui a= rtifacts. I> haven=E2=80=99t been able to follow this in enough detail to = be sure it=E2=80=99s a > problem here, but it sounds like one. Isn=E2=80=99t it useful for the > mua to be> able to count on the id being unique? The idea is that if you upload exactly the same bytes, you can get the same ID, allowing you to cache just a single copy of the content. It's particularly nice in cases like with Cyrus IMAP now, where we haven't quite got single-copy storage of attachments on the backend, but we can give you the same ID if the bytes are identical, so if you have a copy of something that's been attached and forwarded around, a JMAP client could download that blob once. I'd be happy for the wording to say MUST NOT ever use the same blobId for different bytes. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150452904324960900 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Mon, 4 Sep 2017, at 22:33, Ted L= emon wrote:
On Sep 3, 2017, at 9:39 PM, Neil Jenkins <= ;neilj@fastmailteam.com> w= rote:
First off, I'm going to change that SHOULD to a MAY. It's = more efficient to dedup, but easier not to. I think this is legitimately a = choice for the server based on its architecture. Regarding the expiration d= ate bump, probably yes again.

Are you sure this is a good idea?  This sounds like a gateway to = the kind
of inconsistency that plagues users of imap: the mua can=E2=80=99t dep= end on some
useful behavior of the server without creating weird ui artifacts.&nbs= p; I
haven=E2=80=99t been able to follow this in enough detail to be sure i= t=E2=80=99s a
problem here, but it sounds like one. Isn=E2=80=99t it useful for the = mua to be
able to count on the id being unique?

The idea is that if you upload exactly th= e same bytes, you can get the same ID, allowing you to cache just a single = copy of the content.  It's particularly nice in cases like with Cyrus = IMAP now, where we haven't quite got single-copy storage of attachments on = the backend, but we can give you the same ID if the bytes are identical, so= if you have a copy of something that's been attached and forwarded around,= a JMAP client could download that blob once.

I'd be happy for the wording to say MUST = NOT ever use the same blobId for different bytes.

Bron.

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


--_----------=_150452904324960900-- From nobody Mon Sep 4 05:47:20 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 DF53E1329AB for ; Mon, 4 Sep 2017 05:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=K7vP2eol; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hbtMGPLe 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 324LL2shZJz1 for ; Mon, 4 Sep 2017 05:47:17 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D4E132992 for ; Mon, 4 Sep 2017 05:47:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BC0F520E56 for ; Mon, 4 Sep 2017 08:47:16 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 04 Sep 2017 08:47:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=BpqZeLLv6iWQmqwjB IB+KbygIpn9wTOHkh6FCxJFHOQ=; b=K7vP2eol4IdCUNdFRm0S584dDUttQmimU FjhY9/RR43dxycBN2SCenwkROmPyakwwMQNAg4bX0IcvEJqrtzxEMZS8s+O+gaVT qNthMzq/Iz5/2I86rnEiWFAY6nyO/EN+/Bci/Qhw9qX+ea0Ur/j4kGZMjWQ4XGqW bQBA0fh9fZORWe1J3WXtulWpoC3vDIA/QC5+mFfzFMmyeJv5KaxT8sp/cWyuRPkH 5VDVlGIbhnzj0Kk10ZBgZVIHBs0yFZB0ISTwZIE/6rh7UBvgJGDk2+P9Mhi8Sl6w yr8iwT/Z5QtTYBYL9FVxgyr0ccQ4mPnDac8/t47hED0wknROv3AIg== 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=BpqZeL Lv6iWQmqwjBIB+KbygIpn9wTOHkh6FCxJFHOQ=; b=hbtMGPLe2nWouP3Qz6OnRQ kbSsxIsciDu26cv7Q/8gCKuBNZiCSDH8Q7y//STzM4epC/USPRsF9iwhmWOqe4mg BOQjbZNpGwkJOTN6EibEHF3EaBvFE5nRFrJdf2o4NuIppOufaBLiTzjKjJkWnGDc 73NGMks9ug0r7a/AZVW0SjFBE6geo7Jy0KcOyPhBC5Le2qI/C+aRBEp9VJ/m8jsB TMDvHCU7KzD76BKTquqAYtA3PyjSi+rWo3P9dfjVx4yr1zwCnI3eTYhofOwXIqL/ iT3zrB+g0bmTajNLRUa+uau4ALgfBMpD6meYRIOg7snIxRKgCy97JkTlSSkoYXNw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9AAFABAB76; Mon, 4 Sep 2017 08:47:16 -0400 (EDT) Message-Id: <1504529236.2496831.1094625000.5F6534EF@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150452923624968310" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f7b75467 In-Reply-To: <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> Date: Mon, 04 Sep 2017 22:47:16 +1000 References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 04 Sep 2017 12:47:19 -0000 This is a multi-part message in MIME format. --_----------=_150452923624968310 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 4 Sep 2017, at 22:41, Ted Lemon wrote: > On Sep 4, 2017, at 12:54 AM, Neil Jenkins > wrote:>> Opinions on the right action here? > > Have a mailbox called "all" that every message is always in. > Or, as you> say, make it an error to delete a non-empty mailbox. But I > prefer "all"> because enforcing that restriction could be incompatible with a > label-based inbox paradigm, where we would expect labels to > potentially> be quite ephemeral. If I was building a client and wanted to allow removing a label, I'd search for the list of all ids for the messages with that label. The client would also say "removing label from messages, as you sure", and then if you said yes, it would do a setMessages to remove the label from those messages followed by a setMailboxes to delete the label. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150452923624968310 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 4 Sep 2017, at 22:41, Ted Lemon wrote:
On Sep 4, 2017, at 12:54 AM, Neil Jenkins <neilj@fastmailteam.com> wrote:
Opinions on the right action here?

Have a mailbox called "all" that every message is always in. Or, as you
say, make it an error to delete a non-empty mailbox. But I prefer "all"
because enforcing that restriction could be incompatible with a
label-based inbox paradigm, where we would expect labels to potentially
be quite ephemeral.

If I was building a client and wanted to allow removing a label, I'd search for the list of all ids for the messages with that label.  The client would also say "removing label from <n> messages, as you sure", and then if you said yes, it would do a setMessages to remove the label from those messages followed by a setMailboxes to delete the label.

Bron.

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


--_----------=_150452923624968310-- From nobody Mon Sep 4 07:49:08 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 A1B3E13219F for ; Mon, 4 Sep 2017 07:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 RXyCnpZGOrwc for ; Mon, 4 Sep 2017 07:49:05 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D587129C41 for ; Mon, 4 Sep 2017 07:49:03 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 420A9FA0116; Mon, 4 Sep 2017 14:49:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1504536541; bh=P9+n/awUfL1XVafUCc+L/5ReA4lpxwLUzFd7vIEA1kA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KI3tYvySYeq2iHRw1TKO/1NE233Ekaw/D+W90zABN5oxMN+Oci8tNA0o/l4oUqHnx 32QMN3iGF0LPOrTMnTmQzPW4n424ffqfp5oWYD2fcsRozr9/ZZBuRzNwR1BweSSirL dSjbn1pRpmq0FWRPCYgIzsYPIRpKQlYKgAC46R/4= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1504536540-16050-21127/11/11; Mon, 4 Sep 2017 14:49:00 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 4 Sep 2017 15:49:00 +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: <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 04 Sep 2017 14:49:07 -0000 Ted Lemon writes: > Or, as you say, make it an error to delete a non-empty mailbox. Or make it an error to delete a mailbox if that involves actually deleting a message. That seems to be the heart of the matter, why not put it like that in the spec? Arnt From nobody Mon Sep 4 08:50: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 ACC4E1321C4 for ; Mon, 4 Sep 2017 08:50:09 -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 j3tQPhkCexLm for ; Mon, 4 Sep 2017 08:50:07 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 9FDEA1321A5 for ; Mon, 4 Sep 2017 08:50:07 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id v66so2190298pgb.5 for ; Mon, 04 Sep 2017 08:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VCn45y8HYvnqZulnlXihhLzHj2RD0ieBpGp8lYj6QqA=; b=uhara8TluvZAPVltyzGfqx8c5zOfERAqLjVNHn6pgQxy0kAqM5hVOGle174MdeOyNp /RPG/iFVfk4ZwTZh9PT3laCyIqofONNiO+cSXtbe4HWkV5+gbAnMXE7SvEqR1FjnYShJ arOdQnKsCvCUWw+IIo5dxwcqSrdncBBwAXtirrv7Cs6lV6RDBhePGIcYLPsVIkX8dPVj Nylqkr714+U4rcosTsvsya+oUNMmFz9LDlIknly7VZcPvQWJXMxERzrjYNnfQNxQpaUZ k4gjvplsFjuD5P2SHYloz+ZUzTHC17TGbPBT6NfjKd/zPjB84GQ3wETnnXm0WqqwIkhm tdoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VCn45y8HYvnqZulnlXihhLzHj2RD0ieBpGp8lYj6QqA=; b=SUSpP2OrS1+QxAFhUX6t8bgQvSMoimoslzsKeTBPyWOcUF44+TEjAYWle/Dku4nkQs PGkKGxocSM8HmGDknmm/WPHKfuhY6KdSveMDDar3/OHWt9Cghpthk2h52tDBF8FtFs5O kLPOvk6/nLu/ud3vLTa7DzKu5mvFGhS38fROtj7RlP7fNRDty5Bk7xkUcXgA+ay2P875 QDNEAFwToYD4hhP1PdOJKy+Da3kbfkganPuK8bvmRgwAcy0X/TrjkG1shi2eW2ruIdZz do80zF8hwZ/5gNSxAA48PZ7GEiKg104kBa+XEtAA3sWfm7rrqF5svsLcbmUA8VC9n8Lg eCHA== X-Gm-Message-State: AHPjjUgLrcQxherCKjE2kodPGDGg7Qcc1rFM1pJ2SM1ZstMeEXFWi5HO nzbIdU+dZz5DdqBWAV+fyEJ6m/wJPt4m X-Google-Smtp-Source: ADKCNb5g9fF4px1gXYFrDOdWh4GWYO1AV7PrtBA5xRhyibeiE8hsf8x7PXrQB2x3UYQ1WrKrvLpmymylB0ewpVRcXrE= X-Received: by 10.99.143.89 with SMTP id r25mr925473pgn.224.1504540207081; Mon, 04 Sep 2017 08:50:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.152.98 with HTTP; Mon, 4 Sep 2017 08:50:06 -0700 (PDT) Received: by 10.100.152.98 with HTTP; Mon, 4 Sep 2017 08:50:06 -0700 (PDT) In-Reply-To: References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> From: Ted Lemon Date: Mon, 4 Sep 2017 11:50:06 -0400 Message-ID: To: Arnt Gulbrandsen Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary="94eb2c1b6ca697fcc705585f10a6" Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 04 Sep 2017 15:50:10 -0000 --94eb2c1b6ca697fcc705585f10a6 Content-Type: text/plain; charset="UTF-8" Because that perpetuates the idea that mailboxes are containers. And it still requires the behavior that Bron was describing: the client has to have a full inventory of the set of messages to which that label has been applied. On Sep 4, 2017 10:49, "Arnt Gulbrandsen" wrote: Ted Lemon writes: > Or, as you say, make it an error to delete a non-empty mailbox. > Or make it an error to delete a mailbox if that involves actually deleting a message. That seems to be the heart of the matter, why not put it like that in the spec? Arnt _______________________________________________ Jmap mailing list Jmap@ietf.org https://www.ietf.org/mailman/listinfo/jmap --94eb2c1b6ca697fcc705585f10a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Because that perpetuates the idea that mailboxes are= containers.=C2=A0 And it still requires the behavior that Bron was describ= ing: the client has to have a full inventory of the set of messages to whic= h that label has been applied.=C2=A0

On Sep 4, 2017 10:49, "Arnt Gulbrandsen" &= lt;arnt@gulbrandsen.priv.no= > wrote:
Ted Lemon writes:
Or, as you say, make it an error to delete a non-empty mailbox.

Or make it an error to delete a mailbox if that involves actually deleting = a message. That seems to be the heart of the matter, why not put it like th= at in the spec?

Arnt


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--94eb2c1b6ca697fcc705585f10a6-- From nobody Mon Sep 4 12:28: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 39984126D0C for ; Mon, 4 Sep 2017 12:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 qXowRGtgJ58T for ; Mon, 4 Sep 2017 12:28:26 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBB512421A for ; Mon, 4 Sep 2017 12:28:25 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3E2C7CEC011; Mon, 4 Sep 2017 19:28:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1504553304; bh=ZfVSVXGSkbu/xFRx8rtx3brdUaBNTTple40FWY8ip14=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lAmxAGuICRUPyijE+dir4tfFaBMuCZsUVokNE2GZJc5vk8kQE3HvCjaTcibHeiajp sb7OredYLPApawb47dMIz3QPafE/ezCIhc9NpVLAR0hBtGukOTxYFEDG+32KakI9IZ zUuMbK/pI/f48BGPXX6bh8tIYjv3MT5/r/AV+aAo= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1504553303-16050-21127/11/12; Mon, 4 Sep 2017 19:28:23 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 4 Sep 2017 20:28:22 +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: <59ab4296-6ff9-4f32-be42-635b0958f195@gulbrandsen.priv.no> In-Reply-To: References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 04 Sep 2017 19:28:28 -0000 Ted Lemon writes: > Because that perpetuates the idea that mailboxes are > containers. That's not what I intended to suggest. Rather, that (some?) containers are going to be visible as mailboxes, most importantly "all mail", and that precisely this is the reason to deny delete. > And it still requires the behavior that Bron was > describing: the client has to have a full inventory of the set > of messages to which that label has been applied. That's programmerthink: Corner cases are exciting, let's spend most of the text discussing them! ;) Does JMAP really, really need to specify things like "all mail"? Isn't it enough to say that the server shouldn't delete a mailbox if that requires actually deleting messages, and that if clients are not urged to try to provide this capacity, lest a misclick cost users all their mail because the thing the user _wanted_ to click was the line below "all mail". Arnt From nobody Mon Sep 4 15:39:38 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 F2B641321A0 for ; Mon, 4 Sep 2017 15:39:37 -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 M_pF4qqJ5I6M for ; Mon, 4 Sep 2017 15:39:36 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 EAE9D132192 for ; Mon, 4 Sep 2017 15:39:35 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id v66so4232950pgb.5 for ; Mon, 04 Sep 2017 15:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XacFTcDBnuvkehgnyiM3slGUEZKpDkPRyAcJQcdQR14=; b=vOeYAW2/IqDedN4845hsl/wLx10rd7GtGv8A4+Is3ecxdFSVvQFYzbD/G8nHUix2cu hmBBqZHxylJaB85jvTFOVGIYOVIZLtB85Z/CY36R+1RpLlrzREZuTH6grHsLClEXBQGk ehcvIbEhWkjs2D3uEFAI1wqGSvBXhrhRi7dqHMWmTGOQvaQTygk8FX9nHLDcnarEjYph YeVWuXcvxUoyMO4P2+1j1fp+aRwDYp6moLA2XoSP1E69CIZdMwkMMF0bTARyvzoerveq JrVP+TmznpE7YGSiNJhvySLqHllI26T52dAiMnmp7Q91EZLwms+T8t2zHngq4hzMonMX ytog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XacFTcDBnuvkehgnyiM3slGUEZKpDkPRyAcJQcdQR14=; b=iuYtCf2lVcuLoBVLFvG4F/+HNi/gVvG4wp9v2nKDux2RsxjMazIsrt6np3TXFA6es+ vsy+KBpItAdF3kZ3qJL+ofLelbIMceJ4+YYOoND/1xjqfPY9La0nrRgfUKx6RnVMACDn to2g9cFC4diGGgrKv33Ap1Rsz7cD0ha5ovft/54GhwcdorypcTW0WPFLdn59voi2kJuf JZpI0gtJZhz/9bCUDoZO0irKvjMtG4ItUXCvjYrkADwtKLjGEFWcydY7EO9Ac/Ue2F7y GP+aapKz/KEIRV69U7y1DEZfnpGUEJPriLs8eNK7MzHwv96fnzCLP97Vbb3FwK3V/WZX +bUQ== X-Gm-Message-State: AHPjjUiRpzMfVO7uL0orwq/CtzTqGMHuqKaDxo4ZqIXmvu0RsYKZQ5xA G2RtFLXEiR9JzOJj8q4KX+yBLeo+nt7f X-Google-Smtp-Source: ADKCNb5rGL2iDPMerj7ft3ifLYHrdZarrsRMTU5GC7GwGLya0CB/YkRQj1hPUgle2pf2deUoFGNC/CdBedlj90clarg= X-Received: by 10.99.181.23 with SMTP id y23mr1862997pge.177.1504564775436; Mon, 04 Sep 2017 15:39:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.152.98 with HTTP; Mon, 4 Sep 2017 15:39:34 -0700 (PDT) Received: by 10.100.152.98 with HTTP; Mon, 4 Sep 2017 15:39:34 -0700 (PDT) In-Reply-To: <59ab4296-6ff9-4f32-be42-635b0958f195@gulbrandsen.priv.no> References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> <59ab4296-6ff9-4f32-be42-635b0958f195@gulbrandsen.priv.no> From: Ted Lemon Date: Mon, 4 Sep 2017 18:39:34 -0400 Message-ID: To: Arnt Gulbrandsen Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary="94eb2c1b8a8afb6d9b055864c883" Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 04 Sep 2017 22:39:38 -0000 --94eb2c1b8a8afb6d9b055864c883 Content-Type: text/plain; charset="UTF-8" Why would deleting the last label that applies to a message have the semantics that the message should be deleted? On Sep 4, 2017 3:28 PM, "Arnt Gulbrandsen" wrote: > Ted Lemon writes: > >> Because that perpetuates the idea that mailboxes are containers. >> > > That's not what I intended to suggest. Rather, that (some?) containers are > going to be visible as mailboxes, most importantly "all mail", and that > precisely this is the reason to deny delete. > > And it still requires the behavior that Bron was describing: the client >> has to have a full inventory of the set of messages to which that label has >> been applied. >> > > That's programmerthink: Corner cases are exciting, let's spend most of the > text discussing them! ;) > > Does JMAP really, really need to specify things like "all mail"? Isn't it > enough to say that the server shouldn't delete a mailbox if that requires > actually deleting messages, and that if clients are not urged to try to > provide this capacity, lest a misclick cost users all their mail because > the thing the user _wanted_ to click was the line below "all mail". > > Arnt > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > --94eb2c1b8a8afb6d9b055864c883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why would deleting the last label that applies to a messa= ge have the semantics that the message should be deleted?

On Sep 4, 2017 3:28 PM, &qu= ot;Arnt Gulbrandsen" <a= rnt@gulbrandsen.priv.no> wrote:
Ted Lemon writes:
Because that perpetuates the idea that mailboxes are containers.

That's not what I intended to suggest. Rather, that (some?) containers = are going to be visible as mailboxes, most importantly "all mail"= , and that precisely this is the reason to deny delete.

And it still requires the behavior that Bron was describing: the client has= to have a full inventory of the set of messages to which that label has be= en applied.

That's programmerthink: Corner cases are exciting, let's spend most= of the text discussing them! ;)

Does JMAP really, really need to specify things like "all mail"? = Isn't it enough to say that the server shouldn't delete a mailbox i= f that requires actually deleting messages, and that if clients are not urg= ed to try to provide this capacity, lest a misclick cost users all their ma= il because the thing the user _wanted_ to click was the line below "al= l mail".

Arnt

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--94eb2c1b8a8afb6d9b055864c883-- From nobody Mon Sep 4 17:55:06 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 550151321A6 for ; Mon, 4 Sep 2017 17:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=D/7SPClk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rZqNej0y 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 FwzjIkAybSVr for ; Mon, 4 Sep 2017 17:55:03 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739561321BB for ; Mon, 4 Sep 2017 17:55:03 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id CEF5320BD7 for ; Mon, 4 Sep 2017 20:55:02 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 04 Sep 2017 20:55:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=R4rvABsWy2ziNQNDX nROlz6vAtbF3CDiyOb9xoaVK7g=; b=D/7SPClkgVe8jP5iYjpZCvtzkZmr6iBZn DLzAUdfWwktE5Un2IIPWT4rwd8KeN7Hox+PMBtTANuPD2o2rXf4t6UbtG1r0iBM4 0N/t9zh9W13jJDmEtFvxr0pzEyqzsP0Y9t512G+4L7fivXMSfuqBTOXaNk4YurKY ijiesVHWBfiQXffqKSxpka7agp87n2yB2B67hQ6LMGZNBb4MzQftP/XBavAF5M59 hP8yDF0iHEWsYCGZJyf/oEqjGOZK3RBJic0x7kWF0vVb5J1jXyatFAx4+D5fQwZG YpjYF4xCYUyBhMhj5mBlOGffsMHsV1h/eJN1baPU35EeSiOGYxJIQ== 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=R4rvAB sWy2ziNQNDXnROlz6vAtbF3CDiyOb9xoaVK7g=; b=rZqNej0yJ+4Fk0ouAEERl3 /0/q8DRgimAxGfNlPAc/QE6D53NGs1WFKfxQIld+rebezqsrylPG9JsI4CKCtnOX LHTuZeUVI70ZjXY8p/pE9ENKcui/Jd8NqJH8C+/DKPshGf+G8YfbPdeKGaliQ/uc gSM2cS7qHeLCksjkFstVDYl58iul6gkNFSltvECZq75sHbm1+SfkODT2ocsZaCkk 67Qr7x5OrsMu+OrKna7He7nvFiPhxJWUbeQUTj1HAAjkWI6CHWv+Kq6PBKimifAE 9oEBpidvFNglQcsEywNpBvzVuKCV5270Rjf4fd8R85uLVdzAGYGERbFPOodcBjxQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 96174E2584; Mon, 4 Sep 2017 20:55:02 -0400 (EDT) Message-Id: <1504572902.2656720.1095137656.219BF3C9@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150457290226567200" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> <59ab4296-6ff9-4f32-be42-635b0958f195@gulbrandsen.priv.no> In-Reply-To: Date: Tue, 05 Sep 2017 10:55:02 +1000 Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 05 Sep 2017 00:55:05 -0000 This is a multi-part message in MIME format. --_----------=_150457290226567200 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 5 Sep 2017, at 08:39 AM, Ted Lemon wrote: > Why would deleting the last label that applies to a message have the > semantics that the message should be deleted? One of the goals of JMAP, and I think this is important to allow for migration, is that a server should be able to serve up both an IMAP and JMAP view of a mail store and these are consistent, so a user might simultaneously use an IMAP and a JMAP client. Suppose a message X is in both Foo and Bar. Over IMAP this is exposed as two different messages, but in JMAP they can be exposed as a single message in two mailboxes. Deleting the Foo mailbox via IMAP deletes all the messages in it. In JMAP you would see the Foo mailbox disappear, and an update to message X that removed the Foo from its list of mailbox ids. If you now deleted Bar via IMAP, the message would no longer be in any mailbox so therefore deleted in JMAP as well. So if we just matched IMAP behaviour, deleting the last "label" would have the semantics of deleting the message. I really don't like the idea of mandating an "All mail" mailbox that every message must belong to. Either you have to expose this via IMAP (which Gmail does, and it causes all sorts of issues if the IMAP clients are not specially coded to deal with it as that's not how IMAP is expected to work), or if you don't expose it via IMAP that means you now have mail that can only be accessed via JMAP, breaking the goal of allowing dual use for easier migration. I think I lean towards the current spec, which simply makes it an error to try to remove a mailbox that has messages in it, and forces the client to deal with them first. This is easy to implement, and doesn't break IMAP compatibility. Neil. --_----------=_150457290226567200 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 5 Sep 2017, at 08:39 AM, Ted Lemon wrote:
Why would deleting the last label that applies to a message have the semantics that the message should be deleted?

One of the goals of JMAP, and I think this is important to allow for migration, is that a server should be able to serve up both an IMAP and JMAP view of a mail store and these are consistent, so a user might simultaneously use an IMAP and a JMAP client.

Suppose a message X is in both Foo and Bar. Over IMAP this is exposed as two different messages, but in JMAP they can be exposed as a single message in two mailboxes. Deleting the Foo mailbox via IMAP deletes all the messages in it. In JMAP you would see the Foo mailbox disappear, and an update to message X that removed the Foo from its list of mailbox ids. If you now deleted Bar via IMAP, the message would no longer be in any mailbox so therefore deleted in JMAP as well.

So if we just matched IMAP behaviour, deleting the last "label" would have the semantics of deleting the message.

I really don't like the idea of mandating an "All mail" mailbox that every message must belong to. Either you have to expose this via IMAP (which Gmail does, and it causes all sorts of issues if the IMAP clients are not specially coded to deal with it as that's not how IMAP is expected to work), or if you don't expose it via IMAP that means you now have mail that can only be accessed via JMAP, breaking the goal of allowing dual use for easier migration.

I think I lean towards the current spec, which simply makes it an error to try to remove a mailbox that has messages in it, and forces the client to deal with them first. This is easy to implement, and doesn't break IMAP compatibility.

Neil.
--_----------=_150457290226567200-- From nobody Mon Sep 4 18:24: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 E6D911321AC for ; Mon, 4 Sep 2017 18:24:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 2p-RD_6ygKuL for ; Mon, 4 Sep 2017 18:24:24 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 C9A841321C7 for ; Mon, 4 Sep 2017 18:24:23 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id b52so2758774qtb.3 for ; Mon, 04 Sep 2017 18:24:23 -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=jd83RFf79sr9mTqVquNSmoO5E7tRy7J4apJOiaLgPSk=; b=HTWMsyQi4J7HjdMnaQICOqLAZsi198Xsrv+E0pVVEdHTfsfMtMiTSIbAk+Hl5KhMTx uRSdtUS+G5iIOH8wl4lgitvk19SM9uIjG+j8jm6YhkICyvAytpqbEOo5YEoxC69M8+NJ BSMZN0ID0FIqpPdzY7VhgPtFEVZLJVgR5vsOzHB5fXK3QDxvi5jadmeIS8Nmkv4oDyY0 mt59vc1BHvC2pVUxCHzk+qSTZEH7sLLMZ+Ie1WJHfBj2vDQ/mcIW+KkkeQO45+7Anbdt pGIkOfYqo6eqG+ZAJQpR8fFywTZP6feBwNM+aGktIozdc54HHxEmc2gY6QOmjZgm8lSN slVQ== 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=jd83RFf79sr9mTqVquNSmoO5E7tRy7J4apJOiaLgPSk=; b=dIdwlFb/xMdFjD5Qer8St+8IMBiXAlwobyW69ALJwyFHz+f6cnb/j/2qK+uCOyRCYi y4mlFYGMeU1GWRowSm+lBmGD2sw7vTQBUcj8NMrJJGcaooEWn+rrxSPxbXzlHxpxcIlO csXafxMcClhxOGFtgiFSBwRKUsKto87+BsM0tLLpEWI6AAhFaHESCxw/NJ/ApSO5LeDm EeCTxz0AWEFNUeEolqFc5IKEMq2TOHyUbLUuQQ6qSzJRBycTNOQtMFxVedb8qG2D3c6z M58qYAk9i+uJMndBvPtixBDqxS012YO7gmtKipqU7E+ejfSrQuDF/3e4F5a3pzR6UtnV +CAQ== X-Gm-Message-State: AHPjjUgTVgJP0xKxbt2PiINPsHsxDEfHAym0rveSuXG4EzDfhzcwYPRj MPprQhVXqyhsNuYHfuEU9Q== X-Google-Smtp-Source: ADKCNb58u87Ij+eyDuQXirxnwgjbU53Yfu8pj7BDGyqbe6a/2kPkNDO8rXmBc1/QEwT/vGZ6sPA4aw== X-Received: by 10.237.41.35 with SMTP id s32mr3266409qtd.126.1504574662789; Mon, 04 Sep 2017 18:24:22 -0700 (PDT) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id c38sm3967117qtc.11.2017.09.04.18.24.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 18:24:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <1504572902.2656720.1095137656.219BF3C9@webmail.messagingengine.com> Date: Mon, 4 Sep 2017 21:24:20 -0400 Cc: IETF JMAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <5E6D7FFA-9188-4917-88EF-1639B9F68131@fugue.com> References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <84876DC4-14E4-44E0-9D48-A19C6F546ADD@fugue.com> <59ab4296-6ff9-4f32-be42-635b0958f195@gulbrandsen.priv.no> <1504572902.2656720.1095137656.219BF3C9@webmail.messagingengine.com> To: Neil Jenkins X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 05 Sep 2017 01:24:26 -0000 Hm. I will freely admit that I think IMAP compatibility in the sense = of perfectly compatible back-ends is a waste of time, and IMAP as a = first-class client is also a bit of a waste. So that may be why I see = this differently. To my mind, it seems perfectly reasonable to say = that the behavior for IMAP clients isn't consistent. This is what IMAP = users are already accustomed to. I think it's more important to get = the semantics of JMAP right than to perfectly mirror IMAP. I realize that I may be being overly idealistic, but if it were up to = me, that would be my preference. I do not have a problem with the way = IMAP works on gmail. I use it every day=E2=80=94indeed I'm using it to = write this message=E2=80=94my mail server is G Suite. =46rom that perspective, I think that the semantics of an "all mail" = mailbox are perfectly acceptable, and meet the mandate to support IMAP = for the purposes of migration. After all, if the experience on IMAP is = perfectly fine, but the experience on JMAP is better, that's going to be = a minor but still probably significant driver in conversions over time. > On Sep 4, 2017, at 8:55 PM, Neil Jenkins = wrote: >=20 > On Tue, 5 Sep 2017, at 08:39 AM, Ted Lemon wrote: >> Why would deleting the last label that applies to a message have the = semantics that the message should be deleted? >=20 > One of the goals of JMAP, and I think this is important to allow for = migration, is that a server should be able to serve up both an IMAP and = JMAP view of a mail store and these are consistent, so a user might = simultaneously use an IMAP and a JMAP client. >=20 > Suppose a message X is in both Foo and Bar. Over IMAP this is exposed = as two different messages, but in JMAP they can be exposed as a single = message in two mailboxes. Deleting the Foo mailbox via IMAP deletes all = the messages in it. In JMAP you would see the Foo mailbox disappear, and = an update to message X that removed the Foo from its list of mailbox = ids. If you now deleted Bar via IMAP, the message would no longer be in = any mailbox so therefore deleted in JMAP as well. >=20 > So if we just matched IMAP behaviour, deleting the last "label" would = have the semantics of deleting the message. >=20 > I really don't like the idea of mandating an "All mail" mailbox that = every message must belong to. Either you have to expose this via IMAP = (which Gmail does, and it causes all sorts of issues if the IMAP clients = are not specially coded to deal with it as that's not how IMAP is = expected to work), or if you don't expose it via IMAP that means you now = have mail that can only be accessed via JMAP, breaking the goal of = allowing dual use for easier migration. >=20 > I think I lean towards the current spec, which simply makes it an = error to try to remove a mailbox that has messages in it, and forces the = client to deal with them first. This is easy to implement, and doesn't = break IMAP compatibility. >=20 > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Tue Sep 5 00:39: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 48E3913263F for ; Tue, 5 Sep 2017 00:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_nsLiDDxtwo for ; Tue, 5 Sep 2017 00:39:20 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 289A2132397 for ; Tue, 5 Sep 2017 00:39:20 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id D88552AEF40; Tue, 5 Sep 2017 10:40:03 +0300 (EEST) Date: Tue, 5 Sep 2017 10:39:06 +0300 From: Josef 'Jeff' Sipek To: Bron Gondwana Cc: jmap@ietf.org Message-ID: <20170905073906.GA1284@meili> References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 05 Sep 2017 07:39:21 -0000 On Mon, Sep 04, 2017 at 22:44:03 +1000, Bron Gondwana wrote: ... > I'd be happy for the wording to say MUST NOT ever use the same blobId > for different bytes. Sounds good. Specifically: * if the bytes are different, the server MUST NOT use the same blobId * if the bytes are the same, the server MAY use the same blobId Jeff. -- Research, n.: Consider Columbus: He didn't know where he was going. When he got there he didn't know where he was. When he got back he didn't know where he had been. And he did it all on someone else's money. From nobody Tue Sep 5 01:46: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 3B1E313271E for ; Tue, 5 Sep 2017 01:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, INVALID_MSGID=0.568, MIME_HTML_ONLY=0.723, MSGID_SHORT=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_DoR6Ztl9eb for ; Tue, 5 Sep 2017 01:46:53 -0700 (PDT) Received: from smtp-out10-fallback.linagora.com (smtp-out10-fallback.linagora.com [109.197.179.15]) by ietfa.amsl.com (Postfix) with ESMTP id 47E801328DB for ; Tue, 5 Sep 2017 01:46:52 -0700 (PDT) Received: from smtp.linagora.com (smtp.linagora.dc1 [172.16.18.53]) by smtp-out10-fallback.linagora.com (Postfix) with ESMTP id 1FB241005DCF; Tue, 5 Sep 2017 10:42:25 +0200 (CEST) Received: from linagora.com (openpaas-prod.linagora.dc1 [172.16.18.236]) by smtp.linagora.com (Postfix) with ESMTP id 9F54165A; Tue, 5 Sep 2017 10:46:45 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Beno=EEt_TELLIER?= Sender: =?ISO-8859-1?Q?Beno=EEt_TELLIER?= Reply-To: btellier@linagora.com To: Neil Jenkins , Ted Lemon Cc: IETF JMAP Mailing List Message-ID: 1504601206574 Date: Tue, 5 Sep 2017 08:45:46 +0000 Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 05 Sep 2017 08:46:55 -0000

Hi,


At Linagora, we have a "All mail" mailbox displa= yed in our front-end=2E We simply get this using a GetMessageList request (= hence the mailbox do not exist, we can say the "all mail" mailbox is virtua= l)=2E

It solves the "All Mail" problem without enforcing any server = specific behaviour, just requires a little bit smarter client=2E


=

Cheers=2E

-- 
Tellier Benoi=
t

Software engineer dedicated to OpenPaaS at Linagora
PMC of the Apache JA=
MES project
VIE in Vietnam

https://twitter=2Ecom/AwesomePaaS
https://mediu=
m=2Ecom/linagora-engineering

(I'm proud to tell you this e-mail is JAMES a=
nd OpenPaaS powered)
On Sep 4, 2017 7:41 PM, from mellon@fugue= =2Ecom
On Sep 4, 2017, at 12:54 AM, Neil Jenkins wrote:
> Opinions on the right action here?
Have a mailbox called "all" that every message is always in=2E Or, as you = say, make it an error to delete a non-empty mailbox=2E But I prefer "all" b= ecause enforcing that restriction could be incompatible with a label-based = inbox paradigm, where we would expect labels to potentially be quite epheme= ral=2E
_______________________________________________
Jmap mailing = list
Jmap@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/jmap

From nobody Tue Sep 5 03:15:45 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 894EC13243E for ; Tue, 5 Sep 2017 03:15:44 -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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Hpuqu9aZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FYuCbfST 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 ER0NlqQPxXz5 for ; Tue, 5 Sep 2017 03:15:42 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD20C1323B8 for ; Tue, 5 Sep 2017 03:15:41 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id B671C20C2E; Tue, 5 Sep 2017 06:15:40 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 05 Sep 2017 06:15:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc: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=U/cRAsgDPuaBzmR22TamlGhCsN9CB pXmlHBam6lvi4I=; b=Hpuqu9aZf1bgU5h3wc07vWWzCb21bcx8hTfwffoWlMO9X ncMHnxr9gEEyEYBvRE1DVOqxBGwPGozYEjLHfZGtA76aO9b2B1M1ih/0xZNax53/ eWK5TeG96kjJzgNJOA+7FRoRugcx1Mmm+taytix7cWgV2RZB/X4gM57maTmkoDFw O2n9HUTtrXk0FzdYAyUKwolQb/fI1KsGBccdrtWTsAuHcvff4HxqP44zEnjFkxJ3 qfcIbo0O4SvAjxL70YPu++zOFl0n1aqFXbuuVwx/YiLQcuJek6kx96rJrXhAJnpF vw7DkTaAY1ig1l955JDMMZILVPG86znj/Bj4EHruA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=U/cRAsgDPuaBzmR22TamlGhCsN9CB pXmlHBam6lvi4I=; b=FYuCbfSTcyg5UYTrlbT2TiZIOM9XIUs3KG+81LzR5Ekgw FuzpUiZ3xgpU1oYX+3TrpeIO4g73OMlXhFGfbvcm7nufeaa2u5SCWCPOOJzuXlu6 yZ5qhMZs7dnf5fgATvLGCy30CYu/hRgQbsEgoGXR9AwYDYXlDCYI9P2AHJQDN/0x XXeoBWltNYhQ3Jw+K0X3yiQHVcLVhxaJQteyaq0EQ+7qruhN7nUfoEUpflKEf28q J+8d7gfYWD6NW7WN9lHmKE2bIdUfE9XJiuEy0yF9cyDZnbd9jB0BMsK2Wm4lubt8 Z2OeEXxKhFry8dfMLktNrzT/ExC3nZjcHs/5oFtqQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 68725E2744; Tue, 5 Sep 2017 06:15:40 -0400 (EDT) Message-Id: <1504606540.3169111.1095557024.6EF92E43@webmail.messagingengine.com> From: Neil Jenkins To: =?utf-8?Q?Beno=C3=AEt=20TELLIER?= , Ted Lemon Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150460654031691111" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cd116a3f Date: Tue, 05 Sep 2017 20:15:40 +1000 Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 05 Sep 2017 10:15:44 -0000 This is a multi-part message in MIME format. --_----------=_150460654031691111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Yes, there's no need for an All Mail mailbox; if we wanted to go this route, we just relax the requirement that a message must be in at least one mailbox and allow messages to exist that aren't in any mailboxes. The main trouble with this is such a message would be completely invisible via IMAP, so mandating this behaviour would be very awkward to implement if you want to keep compatibility with both (which I reiterate is, I believe, vital for smooth migration). And if it's optional that just adds extra complexity and still leaves the problem of what to do in systems that don't allow zero mailboxes. Regards, Neil. PS Beno=C3=AEt: your MUA seems to have set neither an In-Reply-To nor a References header, so your reply did not thread. Would be great if you could fix that. On Tue, 5 Sep 2017, at 06:45 PM, Beno=C3=AEt TELLIER wrote: > Hi, >=20 >=20 > At Linagora, we have a "All mail" mailbox displayed in our front-end. > We simply get this using a GetMessageList request (hence the mailbox > do not exist, we can say the "all mail" mailbox is virtual).>=20 > It solves the "All Mail" problem without enforcing any server specific > behaviour, just requires a little bit smarter client.>=20 > Cheers. > -- Tellier Benoit Software engineer dedicated to OpenPaaS at Linagora > PMC of the Apache JAMES project VIE in Vietnam > https://twitter.com/AwesomePaaS > https://medium.com/linagora-engineering (I'm proud to tell you this > e-mail is JAMES and OpenPaaS powered)> On Sep 4, 2017 7:41 PM, from mello= n@fugue.com >> On Sep 4, 2017, at 12:54 AM, Neil Jenkins wrote: >> > Opinions on the right action here? >>=20 >> Have a mailbox called "all" that every message is always in. Or, as >> you say, make it an error to delete a non-empty mailbox. But I prefer >> "all" because enforcing that restriction could be incompatible with a >> label-based inbox paradigm, where we would expect labels to >> potentially be quite ephemeral.>> ______________________________________= _________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap --_----------=_150460654031691111 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Yes, there's no need for an All Mail mailbox; if we wanted to go= this route, we just relax the requirement that a message must be in at lea= st one mailbox and allow messages to exist that aren't in any mailboxes. Th= e main trouble with this is such a message would be completely invisible vi= a IMAP, so mandating this behaviour would be very awkward to implement if y= ou want to keep compatibility with both (which I reiterate is, I believe, v= ital for smooth migration). And if it's optional that just adds extra compl= exity and still leaves the problem of what to do in systems that don't allo= w zero mailboxes.

Regards,
Neil.

PS Beno=C3=AEt: your MUA seems to have set neither an In-Reply-To= nor a References header, so your reply did not thread. Would be great if y= ou could fix that.


On Tue, 5 Sep 2017, at 06:45 PM, Beno=C3=AEt TELLIER wrote:

Hi,



At Li= nagora, we have a "All mail" mailbox displayed in our front-end. We simply = get this using a GetMessageList request (hence the mailbox do not exist, we= can say the "all mail" mailbox is virtual).

It solves the "All Mail" problem without enforcing any server specific= behaviour, just requires a little bit smarter client.


Cheers.

--
Tellier Benoit

Software engineer dedicated to OpenPaaS at Linagora
PMC of the Apache JAMES project
VIE in Vietnam

https://twitter.com/AwesomePaaS
https://medium.com/linagora-engineering

(I'm proud to tell you this e-mail is JAMES and OpenPaaS powered)
=
On Sep 4, 2017 7:41 PM, from mellon@fugue.com
On Sep 4, 2017, at 12:54 AM, Neil Jenkins wrote:
> Opinions on the right action here?

Have a mailbox called "all" that every message is always in. Or, as yo= u say, make it an error to delete a non-empty mailbox. But I prefer "all" b= ecause enforcing that restriction could be incompatible with a label-based = inbox paradigm, where we would expect labels to potentially be quite epheme= ral.
_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--_----------=_150460654031691111-- From nobody Tue Sep 5 04:07:47 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 8406B13292E for ; Tue, 5 Sep 2017 04:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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 obK46iCVx8EC for ; Tue, 5 Sep 2017 04:07:44 -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 6C71413292C for ; Tue, 5 Sep 2017 04:07:44 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4E26CCEC011; Tue, 5 Sep 2017 11:07:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1504609662; bh=RTGfHS1XXeYAM2eqzw6SF7UUA2PDX/+//H2T7aQgNuM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=r49zp8fZgpauEI07bbTW5airheDuzyTEaR6RLttYcgq/FyBxG/UkDTb+wXMQQEwvv jG7Hl1IQ0Uqgs4SgoGiTCCG6cP9xCxppSITfpDhaBBL6IkWEPPNmvmlZWpnxVu9o0b 94RIBnh4r02ArCO79af3KS6ciQC+pi2BL9ylf9+M= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1504609661-17563-21127/11/11; Tue, 5 Sep 2017 11:07:41 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Tue, 5 Sep 2017 12:07:40 +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: <1504606540.3169111.1095557024.6EF92E43@webmail.messagingengine.com> References: <1504606540.3169111.1095557024.6EF92E43@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 05 Sep 2017 11:07:46 -0000 Neil Jenkins writes: > if we wanted to > go this route, we just relax the requirement that a message must > be in at least one mailbox and allow messages to exist that > aren't in any mailboxes. Because of this requirement, (some) mailboxes are (individually or collectively) containers. IMO it's a fine requirement. Fits users' mental model of how gmail works, and that's the MSB. Saying "mailboxes can be deleted only if that doesn't require deleting messages" is a restatement of the same requirement, not something new. It implies that if clients want to delete mailboxes with messages, they have to do work O(mailboxes+messages), but isn't that OK? Does anything justify striving for sublinear performance there? I don't see anything. I'll probably resume lurking now. I've said my piece. Arnt From nobody Tue Sep 5 06:01:11 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 499561329C0 for ; Tue, 5 Sep 2017 06:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 roRqXjl-CkN4 for ; Tue, 5 Sep 2017 06:01:07 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 785E61329AD for ; Tue, 5 Sep 2017 06:01:05 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id q8so7233277qtb.5 for ; Tue, 05 Sep 2017 06:01:05 -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=67N62r0MsLXp4i+A2aDt6VsPEIz27zSenR1pCnZrtxY=; b=cgF9I8awMDEGw/isT6ddP4Ju4kR6nsrYQf2Wl0IJPzeeIRzZnT+yHkR5+kplsjVa5t oWXxqBQsQC76O3ZjXxHnrMZgUWIG0rwLk5iNF2Je+jTQz2VYHW+hVCUz7LDs/exSP+R6 jB8eBiRKQfWWdza21mUgXKgSC1FN+oA6IaTRrbmAbo6yXu/k/UzpSgTVQqluNVIyXcE7 HKhCiSJZ5KHoWVN9XZCI9Jb7HwnjsdsNK9eBtCwC1nXjL0gNI9xxSsGML8qphagDG7m2 4rr3BigzFKXC9EZL5UqTjaFIEjO8/HlxvgNCx84TDnej8QtfCsTukukV8Ka//OjYi1cv Dw5Q== 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=67N62r0MsLXp4i+A2aDt6VsPEIz27zSenR1pCnZrtxY=; b=qcFkemf/e6SZUXkkOKxJcOR70bXhLC2kKITZNNLedvsWJq71JxI3dXFQRHJmmjOm8t a5HlvQ4QPghl+PdJX6XkrUL4EwA3ZjABm1Up4Vg1AMcsTRsnJXIUYn5LjRazR5QBQ7Mm l5LKJjkpHLEyiLayjV5LBVycAZD6NuENNwoKWyDNlq0WexM8bQ28sOw/ZH2Op63uyWDc YQRCQ99w+ezv+rRKUencdf4xaooM2myHO4MgAUA/jYSB0zwIJGpL/MMd9hF8UKFqOWgt 38xba3zXp5Bv3Z0/kCAMSOKGXrGcWcUQ5moeNH02Hi1lmRnjWTFC5jHMyu2iwtoJ/Yr8 wpZw== X-Gm-Message-State: AHPjjUiQ+JRr7X4UYT0AfbWThZCoLQ9p1Glp59+0y7Ri1uyLh8Kr7rwI Eoz1jPskCGlbHYIi8F5FSQ== X-Google-Smtp-Source: ADKCNb4+56/jeWRyiRkgrIzWSPnqoydRUCvR8t2wV77E0FKjK2eEJVLIi09XiovxAWgZ5yEjue8Bhg== X-Received: by 10.200.2.72 with SMTP id o8mr4902634qtg.63.1504616464257; Tue, 05 Sep 2017 06:01:04 -0700 (PDT) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id o38sm347143qto.10.2017.09.05.06.01.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 06:01:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: Date: Tue, 5 Sep 2017 09:01:02 -0400 Cc: jmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1504606540.3169111.1095557024.6EF92E43@webmail.messagingengine.com> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 05 Sep 2017 13:01:10 -0000 Hm. Well, this has been a clarifying discussion for me=E2=80=94I = realize that the reason I'm arguing in the direction I am isn't quite = what I expressed. Let me state the problem from my perspective, = understanding that my perspective isn't necessarily correct, but just = where I am coming from. =46rom my perspective the data store is a collection of messages, plus a = collection of labels. Each label is a list of message IDs, plus a = label name. We can talk about "all messages," but it's not really a = label=E2=80=94it's just an artifact of the data store. "All messages" = is the list of all message IDs in the data store, and can be constructed = automatically if the index is lost. This is really important to me=E2=80= =94I want to be able to reconstruct the data store if the index is lost. Similarly each label is both the list of message IDs (the index) and = also the label as it's stored on the message. If these indices are = lost, they can be reconstructed by scanning the data store. If part of = the data store is lost, the data store can still be reconstructed along = with its indices. Also, in my way of thinking, "deleting" a message is something you do = only if the message is literally garbage, e.g. spam. Otherwise it = remains in the data store even if it's no longer presented to the end = user. This makes sense for auditability; the opposite might make sense = for user privacy, so I can see where that focus might be what is = preferred by providers who are selling mail to non-enterprise, = non-government end users. The point is that with this model, the idea that deleting a label would = delete the message is completely artificial. And that's why I'm = reacting the way I am to this proposal. This proposal is addressing a = very particular use case. The other reason I am reacting the way I am is that I've been burned so = many times by IMAP's model of "mailbox as container" that I really want = to make that go away. There is no reason at all to tie the concept of = "label" and "container" together in this way. It's totally = artificial, just an artifact of history, of how IMAP used to work. As = Google has demonstrated, it's perfectly possible to run a data store = that works the way I'm describing, and have that appear to the end user = as an IMAP server. So there is no need, for the goal of compatibility, = to have this artificial association between "present in at least one = label" and "not deleted". It would be no trouble for me to implement this particular paradigm on = top of my data store; the problem is that it doesn't make sense to me to = do so. I don't want this behavior=E2=80=94it's not consistent with my = use model. To use the old X11 motto, this is policy, not mechanism. From nobody Tue Sep 5 08:21: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 D21F1132D52 for ; Tue, 5 Sep 2017 08:21:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 gQIfPC_-ikNT for ; Tue, 5 Sep 2017 08:21:29 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 8A55D132D5E for ; Tue, 5 Sep 2017 08:21:29 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id d8so9978952pgt.4 for ; Tue, 05 Sep 2017 08:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zk/X/acFoQYL6gtHUCGhqNcZQgg37fWAQdvBGaCcN0k=; b=o8tdw6BE/aHTpJqHGGFDda+X2Aa1IZMVIxi5WYCQpln37oQ1sEi6GYo0/a6xM0ULHL pry9UvAb241UJ9vKVzrCgzxHClRTx7CAfHJuIe6vJna/0NLShlP9qxKA3ryVLAhxKoeA v2jUsnjZFSaswysqoEW69w4ORaFAxwi1ip384SL276rui2A5K2n+NfsRsIbyHePZOkvg 17ebWk+EPm7gS3BQKJt3v7LPjoin4gbBEPUAeHqenpIdzTlcXa+Kl6x27VXQjd77CO/t 5kUAUa989p5OI9Km1CqErGDjCIqldYKBrMjsjiQNq2lwP+u9MNJhzAo4SzNFrMf6V1k/ 9s5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zk/X/acFoQYL6gtHUCGhqNcZQgg37fWAQdvBGaCcN0k=; b=qoDLAcCIz3vlJZCokzLCgUmEYMriDpUcDgG2VgGKONO1G+IsA2Q8MopoduIko2w77e Cn/KPijbYPBxlLpbAlvHTpDlXbBu6LlxLFmupuyE6lHNyjFR6VdFM5VGzlgGxDCMhDAn v8UCUjFOM40RPUL3iOmOR1agQGWciS1HuJ0jJJRpJsDxC3eQY15j0XpaO8tb9EQd224y 88dYcqBJBrP5K4EuvnwgWLG7YuSrW0uzjSXm/jr7M6TFn8xJA2Bed+dCfkx5fdn8vMex 4vfJmKzW4flo6LWKufwy4lSwwbaf4Wqm2QvrGlCQ80DdujSOoPMkIubjMt4JVP/FxMo4 Wd+A== X-Gm-Message-State: AHPjjUj2eN7z3jUrK0ND22r1zj56CBLb2PpmsELY7uyw8gMxYHWbyOkC htbCInWF2g3SsMmDRZG87wx57fi6xb0m X-Google-Smtp-Source: ADKCNb4S4nOTMbSVZGuY/20VGR6hmf9zwgmBM30r0DpQAcoHLv8CvtR9KjELnC4k7EK3HxqbM3P/W4L4712cWtWijwY= X-Received: by 10.84.210.161 with SMTP id a30mr1020753pli.220.1504624889043; Tue, 05 Sep 2017 08:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.152.98 with HTTP; Tue, 5 Sep 2017 08:21:28 -0700 (PDT) Received: by 10.100.152.98 with HTTP; Tue, 5 Sep 2017 08:21:28 -0700 (PDT) In-Reply-To: <20170905073906.GA1284@meili> References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> From: Ted Lemon Date: Tue, 5 Sep 2017 11:21:28 -0400 Message-ID: To: "Josef 'Jeff' Sipek" Cc: Bron Gondwana , IETF JMAP Mailing List Content-Type: multipart/alternative; boundary="001a114d5232083082055872c86c" Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 05 Sep 2017 15:21:32 -0000 --001a114d5232083082055872c86c Content-Type: text/plain; charset="UTF-8" ISTM that if you do not require that the same bits have the same blob id, you are asking for there to be subtle implementation differences that will be inexplicable to the end user. ISTM also that the time when you want this to happen is when you want to be able to hang different metadata off the same bits in different contexts. So it's not that we should choose on behavior or the other. Both are valid. They just mean different things. Leaving this up to the implementation is therefore asking for interop woes. On Sep 5, 2017 3:39 AM, "Josef 'Jeff' Sipek" wrote: > On Mon, Sep 04, 2017 at 22:44:03 +1000, Bron Gondwana wrote: > ... > > I'd be happy for the wording to say MUST NOT ever use the same blobId > > for different bytes. > > Sounds good. > > Specifically: > > * if the bytes are different, the server MUST NOT use the same blobId > * if the bytes are the same, the server MAY use the same blobId > > Jeff. > > -- > Research, n.: > Consider Columbus: > He didn't know where he was going. > When he got there he didn't know where he was. > When he got back he didn't know where he had been. > And he did it all on someone else's money. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > --001a114d5232083082055872c86c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ISTM that if you do not require that the same bits have t= he same blob id, you are asking for there to be subtle implementation diffe= rences that will be inexplicable to the end user. =C2=A0
<= br>
ISTM also that the time when you want this to ha= ppen is when you want to be able to hang different metadata off the same bi= ts in different contexts. So it's not that we should choose on behavior= or the other. Both are valid. They just mean different things. Leaving thi= s up to the implementation is therefore asking for interop woes.=C2=A0

On Sep 5, = 2017 3:39 AM, "Josef 'Jeff' Sipek" <jeff.sipek@dovecot.fi> wrote:
On Mon, Sep 04, 2017 at 22:44:03 +1= 000, Bron Gondwana wrote:
...
> I'd be happy for the wording to say MUST NOT ever use the same blo= bId
> for different bytes.

Sounds good.

Specifically:

* if the bytes are different, the server MUST NOT use the same blobId
* if the bytes are the same, the server MAY use the same blobId

Jeff.

--
Research, n.:
=C2=A0 Consider Columbus:
=C2=A0 =C2=A0 He didn't know where he was going.
=C2=A0 =C2=A0 When he got there he didn't know where he was.
=C2=A0 =C2=A0 When he got back he didn't know where he had been.
=C2=A0 =C2=A0 And he did it all on someone else's money.

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--001a114d5232083082055872c86c-- From nobody Tue Sep 5 17:23:51 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 E5BA1132E2E for ; Tue, 5 Sep 2017 17:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=rIJmiRil; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HXPBC7eg 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 Sp0Ne1LW2yZS for ; Tue, 5 Sep 2017 17:23:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4FE1321A4 for ; Tue, 5 Sep 2017 17:23:48 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id A4E2C20F4D for ; Tue, 5 Sep 2017 20:23:47 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 05 Sep 2017 20:23:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=5lMytBqzAfWRiWxxq LWQt/kjQGtrWByx8P8qgOa5miM=; b=rIJmiRilPs8Q3WRwt11gnL6yPe2oy3i4n K53uy7LLatEQriui9RCC8os2j2BMusPcc34sV7N0NyqKipBwN3mLObhZ58F3ABiZ rqbOuoAgDPwKTPRzwmvvmBJdLO8tqsBeQgbFlCtbVqcqqPW1QgkRj6cexc+zlTWZ soyQE4/4LCxAiN92pMSvrMtFwqI2+K9GXML3/+WVbrMBEku9V2CaiJ4QnrMGmWNG S8f10yezHqt33NLT0vcZ531ald+p/q4nPQV0/X1kTXT4SbhvIrBmtkAVDouCCtiR 9tmcbD2DxZfFrZo46qARAGnnY7pQqAIePM9DpmG7iGJkegDSQaNBA== 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=5lMytB qzAfWRiWxxqLWQt/kjQGtrWByx8P8qgOa5miM=; b=HXPBC7egGD5b+MwfW5jQO4 SSXgbJIeFvCDfTDDK9p7XpDJXeCvbjmIjmTbiTYGc16YhDqk34mVDL1REumuLL8r d37aFD61K1qF0Q8m+z8FUBDoiSrnEE1XufMlSmsuLLp9uWNQYXLW7nM0XYPsRvP1 uBK2t2hMYvI+NYq0nGnW5wbyLIuqYfxDXjyN4oble5gjJNuEUdZxBR7+7Op9G7lH eOdF5p672tCTdoiDEB+Bg/2rlBdGQSpZ+iSKGbXBsE9HKe8Lo0jgLbwgVYm9Hj79 jI/nYBe6mw83E7Jbt5esDyojGvwexQP3OrjmMMrnfFACG2vev4zcyB9zv4w146Cg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 64E6DE2744; Tue, 5 Sep 2017 20:23:47 -0400 (EDT) Message-Id: <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150465742739803800" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cd116a3f In-Reply-To: Date: Wed, 06 Sep 2017 10:23:47 +1000 References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 06 Sep 2017 00:23:50 -0000 This is a multi-part message in MIME format. --_----------=_150465742739803800 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 6 Sep 2017, at 01:21 AM, Ted Lemon wrote: > ISTM that if you do not require that the same bits have the same blob > id, you are asking for there to be subtle implementation differences > that will be inexplicable to the end user. I don't see how any of this is visible to the end user. > ISTM also that the time when you want this to happen is when you want > to be able to hang different metadata off the same bits in different > contexts. No. The blobId *only* refers to the binary data, not any metadata. > So it's not that we should choose on behavior or the other. Both are > valid. They just mean different things. Leaving this up to the > implementation is therefore asking for interop woes. I don't think there are likely to be interop issues here. Getting the same blobId for the same binary data can make things a little more efficient, as you don't have to redownload a file you already have, but other than that the client doesn't really have to care. The only difference is it has to be able to handle the blob id potentially changing when the blob is referenced from a new location, but there is already a standard mechanism in JMAP for the server to let the client know of properties that it changed during a create/update, and the client should be able to understand this already. Neil. --_----------=_150465742739803800 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 6 Sep 2017, at 01:21 AM, Ted Lemon wrote:
ISTM that if you do not require that the same bits have the same blob id, you are asking for there to be subtle implementation differences that will be inexplicable to the end user.

I don't see how any of this is visible to the end user.

ISTM also that the time when you want this to happen is when you want to be able to hang different metadata off the same bits in different contexts.

No. The blobId only refers to the binary data, not any metadata.

So it's not that we should choose on behavior or the other. Both are valid. They just mean different things. Leaving this up to the implementation is therefore asking for interop woes. 

I don't think there are likely to be interop issues here. Getting the same blobId for the same binary data can make things a little more efficient, as you don't have to redownload a file you already have, but other than that the client doesn't really have to care. The only difference is it has to be able to handle the blob id potentially changing when the blob is referenced from a new location, but there is already a standard mechanism in JMAP for the server to let the client know of properties that it changed during a create/update, and the client should be able to understand this already.

Neil.
--_----------=_150465742739803800-- From nobody Tue Sep 5 17:37:22 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 38FF81321A4 for ; Tue, 5 Sep 2017 17:37:20 -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 Qm3BIwi3KnS9 for ; Tue, 5 Sep 2017 17:37:18 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 773CC1321A0 for ; Tue, 5 Sep 2017 17:37:18 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z143so15996295qkb.3 for ; Tue, 05 Sep 2017 17:37:18 -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=eDxuzhzLfMufwcPOwxecq3EHVdBviFf8r6i4UDY1yyU=; b=Ig38ng0UilZjqepzobTwPgPvGvTXN8/CBtu0QBZv1lPk9h1VZRdEv91sS5+aRGef9E mpdP8uZtXZ53tei3tEvbVCGWrLUR86EdgwTVP4bja9cuv3V4l6L4V4uGVLwg2HOFwJLp y30heQbYFIGY3WTTQFL9ieVHqjpZUAoa5mn1OKM8WIrdFtKu4BlJXeDtS8FsMeAn+Ens asxGAfZPIaOtDtuqJvPtYiF7xS2uw/DUbTkV/HA4Mp/dui1USfMi00JYuL4YzZNw6WQ+ 03poy6+BqM/eXLvBOOCvk9BwTY28GYvYLbeD7PjpFp2fuo1yQzZuSck+nW1bmJHIlRkQ 5yCA== 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=eDxuzhzLfMufwcPOwxecq3EHVdBviFf8r6i4UDY1yyU=; b=G9TaQllR/I5fhKy5fDxdymks1ljpzBmp+f40UlKXF7f0yeFCkB8d+e7n/P+wbXnpIJ a3VWL0qBH6/UUX2WsQaU6ZzuRLbIl8VztSrkovgGJaVwu3NrhqW6eKXBWdPItGFFMjSe +bVLRRwwHiCbrLAeB9VqR00TkyCqdLfm1Opmu7Is2kdZuKLB9SYSdaTB4kVOGll+QX1O uzJFJPeH9bMoyKXoHlJy/o43B8p5TpeQNEDQzj7Pe5ccv37YVJEsTdqA21U56fq7F9kv Z7T6V/6PHHaPUqyN2B9iP+8qLZIn93gKthED1gZbod7HIIon/qTIWb1lz8WLxCCq/YTB 5d9g== X-Gm-Message-State: AHPjjUjNHyuBaWe8ETydGt2gdR34N/PTrm2Boyy4BhVY63VOWy45KwsY 0SbOjOZh9ov3soJk X-Google-Smtp-Source: ADKCNb5Ust4fEtECG62Dg+dvaM7i0keBEy5/6asY6RfmQDkewaR+z+nXJdOHp7zGoDNg70rzHOZKaQ== X-Received: by 10.55.23.13 with SMTP id i13mr1131134qkh.237.1504658237612; Tue, 05 Sep 2017 17:37:17 -0700 (PDT) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id q204sm1416712qke.37.2017.09.05.17.37.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 17:37:16 -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: <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> Date: Tue, 5 Sep 2017 20:37:15 -0400 Cc: jmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <11664872-01E9-4F76-A621-3BE075CC5970@fugue.com> References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> To: Neil Jenkins X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 06 Sep 2017 00:37:20 -0000 An example of how two blob IDs for the same blob would be visible to the = end user would be an inexplicable excessive use of data, for example, = which is one of the problems I have run into with IMAP implementations = in the past. For example, suppose you got a different blob ID per = mailbox, for the same message. If you have any sort of automatic = sorting that results in messages being moved, suddenly there's going to = be a lot of unnecessary data being re-transferred. This exact failure = mode is something that's made IMAP untenable when I am in a situation = where I have limited data. Granted, this would seem like a contrived = example, but I was pretty surprised when IMAP did this, too. From nobody Wed Sep 6 00:58:27 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 958461323F7 for ; Wed, 6 Sep 2017 00:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noQGKvwEvt-F for ; Wed, 6 Sep 2017 00:58:24 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5B71323B0 for ; Wed, 6 Sep 2017 00:58:24 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 79DB02B3CD0; Wed, 6 Sep 2017 10:59:08 +0300 (EEST) Date: Wed, 6 Sep 2017 10:58:15 +0300 From: Josef 'Jeff' Sipek To: Ted Lemon Cc: Neil Jenkins , jmap@ietf.org Message-ID: <20170906075815.GA1420@meili> References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> <11664872-01E9-4F76-A621-3BE075CC5970@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11664872-01E9-4F76-A621-3BE075CC5970@fugue.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 06 Sep 2017 07:58:26 -0000 On Tue, Sep 05, 2017 at 20:37:15 -0400, Ted Lemon wrote: > An example of how two blob IDs for the same blob would be visible to the > end user would be an inexplicable excessive use of data, for example, > which is one of the problems I have run into with IMAP implementations in > the past. For example, suppose you got a different blob ID per mailbox, > for the same message. If you have any sort of automatic sorting that > results in messages being moved, suddenly there's going to be a lot of > unnecessary data being re-transferred. I'm not sure if you are talking about re-downloading or re-uploading... Re-downloading: The client that initiated the move will get the new blobId for the mail. So, it can do whatever local cache update it deems necessary. The other clients aren't so fortunate, but I'd argue that vast majority of them will not need (at least immediately) the whole raw message, and therefore they will use the getMessages call to get whatever subset of the mail they need. Note that if you do automatic sorting via sieve, the delivery happens before any client has a chance to download the mail from the "old" mailbox, so this isn't a concern at all. Re-uploading: Any jmap client that moves messages by downloading and uploading again is broken and needs to be fixed. > This exact failure mode is > something that's made IMAP untenable when I am in a situation where I have > limited data. Granted, this would seem like a contrived example, but I > was pretty surprised when IMAP did this, too. The discussion here is specifically about uploading of binary data. This API is used for upload of attachments or importing of messages. If a user does either of these actions on a link with limited bandwidth, I consider it an implicit agreement to use the bandwidth. If, for example, a user decides to upload a 25 MB attachment, the user should expect >=25 MB to be transferred. After uploading the attachment, the client can issue a setMessages call to actually consume the attachment. The result of the setMessages call will be the new blobId (if different), so the client can make local cache adjustments. So, if all goes well, the client would have uploaded about 25 MB (assuming the body of the email is negligible in size), and downloaded approximately 0 since the responses are rather tiny. Editing the draft with a non-buggy client does *not* require the client to reupload attachments. This is one improvement over IMAP. Finally, when sending the draft, the jmap submission API can reference the draft email by messageId resulting in essentially 0 upload. In other words, to compose, edit, and submit an email with a 25 MB attachment the client can expect to upload a little over 25 MB and download essentially nothing. I think this is significantly better than what IMAP + SMTP give us today (which would use 25 MB * (2 + number of edits) of upload bandwidth). Jeff. From nobody Wed Sep 6 02:35:08 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 9C4861326FE for ; Wed, 6 Sep 2017 02:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 cQm9tw18pY5W for ; Wed, 6 Sep 2017 02:35:06 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id A87C01323B4 for ; Wed, 6 Sep 2017 02:35:05 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id F420B2B3D30 for ; Wed, 6 Sep 2017 12:35:49 +0300 (EEST) Date: Wed, 6 Sep 2017 12:35:01 +0300 From: Josef 'Jeff' Sipek To: jmap@ietf.org Message-ID: <20170906093501.GC1420@meili> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 06 Sep 2017 09:35:08 -0000 On Mon, Sep 04, 2017 at 11:39:51 +1000, Neil Jenkins wrote: ... > On Thu, 27 Jul 2017, at 12:10 AM, Josef 'Jeff' Sipek wrote: > > Why is accountId required in the [download] URL? I don't see a reason > > why a server> couldn't use blobIds that either have internal structure to correctly > > determine the accountId, or to not care about accountId at all. > > All ids in JMAP are scoped to a particular account, and this includes > blobIds. Depending on how your server works, you probably need to know > the account in which to look for a particular blob, so it needs to be in > the URL. You could just include it in every blobId, but why make all the > ids longer when you don't really need to? Agreed. > > I'd expect the spec to say that the URL MAY contain accountId > > We could make the accountId optional in the download URL; it should > pretty much make no difference to the client. Then if you don't need it > on the server you can just exclude it from the URL template. Exactly. That's what I expected when I started reading the draft. ... > > it is easy to run into a ugly scenario where a client wants to save a > > draft with two large attachments with quota enabled.> […] > > I think it would be good for jmap all requests to either succeed or > > fail in a way that tell the client what can be done to get more > > forward progress (even if it is sub-optimal) or that there is no way > > forward. In this particular example, the issue is that the > > invalidProperties error returned from setMessages covers multiple > > situations. At least some of them are:> > > (1) client error: the client didn't upload the attachment before > > trying> to reference it > > (2) blob expired: the server removed the blob because it remained > > unreferenced for too long > > (3) blob evicted: the server removed the blob early because of over- > > quota> situation, etc. > > Both (1) and (2) of course just mean the client has to upload the > attachment. But yes, I agree the eviction case is problematic. The way I > was thinking about it was that eviction is an edge case just specified > to allow the server to stop abusive behaviour. I was presuming your temp > space has a separate quota to your regular space, which should make your > issue very unlikely. Hrm... I haven't considered a separate temp space quota. I'll have to think about this a bit more, since it doesn't obviously make me convinced that the client can distinguish between (1) and (3) above. > If you had a (say 250 MB) temp space quota (and we presume a message has > a max 50MB attachments limit), you're unlikely to get eviction unless > the client is doing something either malicious or stupid. Agreed. (5 clients uploading 50 MB each at the same time can make the 250 MB disappear in no time, but I think that's not something we can or should address.) > If I note this in the spec, does this resolve your concern? If not, do > you have another suggestion for how to provide limits that stop > malicious/broken behaviour from causing issues? I was thinking about somehow trying to inform the client so it can distinguish the there cases. E.g., something like: (1) client error: return invalidProperties + CLIENTBUG (2) blob expired: return invalidProperties + BLOBTIMEOUT (3) blob evicted: return invalidProperties + OVERQUOTA This way, the client can make a better decission how to handle the error. For example, when the QVERQUOTA case is encountered, the client can avoid retrying (which would only waste bandwidth), and either just tell the user or for some clients try to sell the user more storage (which presumably would have a larger temp space quota as well). This is the kind of thing that I'm thinking about. (FWIW, it's still not fully formed in my head.) > > By the way, a number of the HTTP status code descriptions > > include: "There> is no content in the response." Is that saying that the response body> SHOULD be ignored? Or that the responses' Content-Length MUST be 0? > > I was presuming Content-Length MUST be 0. But it might be helpful > for servers to return diagnostic text here, so I'm happy to just > change it to "Clients SHOULD ignore the response body". Do you think > this is better? Yes. Of course there is the whole argument about abuse of HTTP status codes. I don't have an opinion about this myself (and I haven't looked into this in detail), so I'm merely relaying the concern. I've been told that jmap should follow the advice in: https://tools.ietf.org/html/draft-nottingham-bcp56bis-00#section-4.6 Thanks, Jeff. -- It used to be said [...] that AIX looks like one space alien discovered Unix, and described it to another different space alien who then implemented AIX. But their universal translators were broken and they'd had to gesture a lot. - Paul Tomblin From nobody Wed Sep 6 05:47:25 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 80A90132EC0 for ; Wed, 6 Sep 2017 05:47:23 -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 SnOgFLJVXnDS for ; Wed, 6 Sep 2017 05:47:21 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 952E8132EC6 for ; Wed, 6 Sep 2017 05:47:14 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id m35so19335623qte.1 for ; Wed, 06 Sep 2017 05:47:14 -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=lFy5mYvrjr6r2rW8HOdSvW9cwJ7qOgOP8w/oslaqiIk=; b=s39pIiq0//2vps9GCTCzApPD75m79u5aBWF4vIagtZVOvUovFrQonLiEna9S0dMxfP UlyGifp2NHyLBPiLT6K+sJp95b4YCTsV4lpsR4mgolstCj8QmtGs+QQ8cg/CPUTpY2bw kH8pA+W1NUFJ9LBY2cXzYgTLy/ZIgSDUVJCgOWHI1w0QP4knX+bvL9alSVk4lPYJkBN8 BGBy7qFNEpm14XyTq6AkTwmXgKsTacToh36dUPGMPOHXvIHM8X+MYZTlihV+ukGSU6TF bwqfRkwBPuhBoKB1wIilcOwkokPtrkACWryxEZQKHsOcLD8/HXo2qXruiXmfYknR0dg3 kxdA== 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=lFy5mYvrjr6r2rW8HOdSvW9cwJ7qOgOP8w/oslaqiIk=; b=CkardOBXOfa0mDYSQoQdy0tMbczhBPg2Kn7COVS4CUUCGxtmlvPBWrQah3trRImRta cdFtqFVJZ1wt+TAE1ogTCRdXQbmMpQuq3X4DzKFP+dpi02A/Sma8PxYYGAi8Xy5Pgdj0 2e4xGwYirFtEHoJ+IVFAOIiloi/S6gElZjz4AXzVRLT+lNE0KZ6WI5YJFkoSLxaBry8y DQBAc1rilusxePXXCb1S24yQYFXQyMImQaL95Wkamv9vliW3AHf1hEx9xQvX/ZFCvCE/ uOVipOZvOnHtqECzIz8Qgj/fJ4RRtOb8Os5Qpv6gbKqruDRphZzb0fccEQpridnrClz+ XGGQ== X-Gm-Message-State: AHPjjUi8FIIS10bAJ6iX5oZQ7ZgW/4N7Mujn30RkWFGibJGMdCWo/BcE P/Jrd8KTHYzXWSw2BnHrVA== X-Google-Smtp-Source: ADKCNb4dKYv2tAs5CKPRtkk2RbzKnvIBrH5v1y9fDLK2w0skS+tU8G7lV88vGcCenBisiP++gX4mtg== X-Received: by 10.237.61.221 with SMTP id j29mr3616044qtf.282.1504702033781; Wed, 06 Sep 2017 05:47:13 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id s90sm2154793qkl.81.2017.09.06.05.47.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Sep 2017 05:47:13 -0700 (PDT) From: Ted Lemon Message-Id: <2B94C90D-3CFF-4828-9AA3-27741F226E57@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C68A7C6-75B9-48C4-A969-24B6EF319527" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 6 Sep 2017 08:47:10 -0400 In-Reply-To: <20170906075815.GA1420@meili> Cc: Neil Jenkins , jmap@ietf.org To: Josef 'Jeff' Sipek References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> <11664872-01E9-4F76-A621-3BE075CC5970@fugue.com> <20170906075815.GA1420@meili> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 06 Sep 2017 12:47:23 -0000 --Apple-Mail=_0C68A7C6-75B9-48C4-A969-24B6EF319527 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 6, 2017, at 3:58 AM, Josef 'Jeff' Sipek = wrote: > I'm not sure if you are talking about re-downloading or = re-uploading... Ah, I'm talking about when there are multiple clients. This probably = isn't an issue if you have only one, at least for the most part. But = e.g. a server-side automatic mail sorter would count as a client, and = might create a great deal of activity. A personal task manager might = as well. And yes, my concern is about downloads, not uploads. --Apple-Mail=_0C68A7C6-75B9-48C4-A969-24B6EF319527 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Sep 6, 2017, at 3:58 AM, Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi> wrote:
I'm not sure if you are talking about = re-downloading or re-uploading...

Ah, = I'm talking about when there are multiple clients.   This probably = isn't an issue if you have only one, at least for the most part.   = But e.g. a server-side automatic mail sorter would count as a client, = and might create a great deal of activity.   A personal task = manager might as well.

And yes, my concern is about downloads, not = uploads.

= --Apple-Mail=_0C68A7C6-75B9-48C4-A969-24B6EF319527-- From nobody Wed Sep 6 07:15:51 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 D31E6132D77 for ; Wed, 6 Sep 2017 07:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=GZeD3W2K; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g3qf9dME 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 1bAznZYr5JDO for ; Wed, 6 Sep 2017 07:15:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5303F132A0D for ; Wed, 6 Sep 2017 07:15:47 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A20C2211E7 for ; Wed, 6 Sep 2017 10:15:46 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Wed, 06 Sep 2017 10:15:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=ShwhLKjy/qAMUaEJB hhPqObjkG4dipjsn3g3kG3kqJU=; b=GZeD3W2Ks0Fw0KmxojzKbulZWTjP2HEXe KfIfLg8WVNRzeVNPWFSPMGrpKQaoCVbvyWazs0609NgcrhSspG1AT8+EdEl4KkLz sJqCjukjAFZSHjwwj4k42yGFThz5LYEDD7fY2O5QEs830oON/VnSpSSvWrwjOqLc xhlQzXtrygUVQvh3q7gcWdkYq9X0fN0eGzOwQRINoJX9WJRlU6jNGrn5cOdSvwB1 elydHQmB4tRSGxqEWGC6WQnbc2McZU0tWVyKEfieJ/oKmERH0nm6esk940rpkVuL dL4Hs1+wEeU5pFtKg+5zxtQa56M8eBfi+dQHMJUT1LPqGI3kxznbw== 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=ShwhLK jy/qAMUaEJBhhPqObjkG4dipjsn3g3kG3kqJU=; b=g3qf9dMENrFHtzmbctJDnL 26dm2h03LVyBuGF+r4OhpkIjGiw8weB5X2glNdpEzbNgZQf112epVNAJDVDSCrKj d/U2VgK77mWtvg5aWZBwIyEEgSJHfMEbvfByc8QibZIapcLAZyN/hKpJ0OVARvfl jpXWoMCnwczffExTgse/j7R/UtdWwF+EoKtBoeGrj885qrEtlPJDE996GEjWMY3g NmV6Rd6alkyEQ2nUCipBCoYVcWUOBvsMi7P6HBbJ2Hs2hc4rglvoxWAksuOmqbue Lfykljw7EqttzqHxKcj7lzontgmDNM2UepOb8yRJiKTZV91R0Qg0Gw3uv+X+We8w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 81D6BBAB76; Wed, 6 Sep 2017 10:15:46 -0400 (EDT) Message-Id: <1504707346.2685505.1097120200.23CAA64D@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150470734626855055" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f7b75467 Date: Thu, 07 Sep 2017 00:15:46 +1000 In-Reply-To: <2B94C90D-3CFF-4828-9AA3-27741F226E57@fugue.com> References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> <11664872-01E9-4F76-A621-3BE075CC5970@fugue.com> <20170906075815.GA1420@meili> <2B94C90D-3CFF-4828-9AA3-27741F226E57@fugue.com> Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 06 Sep 2017 14:15:50 -0000 This is a multi-part message in MIME format. --_----------=_150470734626855055 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" The most common case I imagine IDs changing is when the upload creates a temporary blobId which gets replaced by the real blobId when the persistent message gets created. The blobId might then be "emailid[mimepart]" for example, which won't change again while the message persists. The trickier part is things like deduplication of attachments, where your server receives two messages which have byte-for-byte identical attachments on them. Depending on your server architecture, you may not want to parse the message, convert the attachments to binary and calculate the digest to deduplicate before returning a blobId, which is what you're talking about requiring if you require that there are never two blobIds which result in the same bytes. Bron. On Wed, 6 Sep 2017, at 22:47, Ted Lemon wrote: > On Sep 6, 2017, at 3:58 AM, Josef 'Jeff' Sipek > wrote:>> I'm not sure if you are talking about re-downloading or re- >> uploading...> > Ah, I'm talking about when there are multiple clients. This probably > isn't an issue if you have only one, at least for the most part. But > e.g. a server-side automatic mail sorter would count as a client, and > might create a great deal of activity. A personal task manager might > as well.> > And yes, my concern is about downloads, not uploads. > > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150470734626855055 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
The most common case I imagine IDs changing is when the upload creates a temporary blobId which gets replaced by the real blobId when the persistent message gets created.  The blobId might then be "emailid[mimepart]" for example, which won't change again while the message persists.

The trickier part is things like deduplication of attachments, where your server receives two messages which have byte-for-byte identical attachments on them.  Depending on your server architecture, you may not want to parse the message, convert the attachments to binary and calculate the digest to deduplicate before returning a blobId, which is what you're talking about requiring if you require that there are never two blobIds which result in the same bytes.

Bron.


On Wed, 6 Sep 2017, at 22:47, Ted Lemon wrote:
On Sep 6, 2017, at 3:58 AM, Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi> wrote:
I'm not sure if you are talking about re-downloading or re-uploading...

Ah, I'm talking about when there are multiple clients.   This probably isn't an issue if you have only one, at least for the most part.   But e.g. a server-side automatic mail sorter would count as a client, and might create a great deal of activity.   A personal task manager might as well.

And yes, my concern is about downloads, not uploads.

_______________________________________________
Jmap mailing list

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


--_----------=_150470734626855055-- From nobody Wed Sep 6 07:32: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 647A1132C2C for ; Wed, 6 Sep 2017 07:32:31 -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 uGjfajJekJit for ; Wed, 6 Sep 2017 07:32:30 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 CB12C132A85 for ; Wed, 6 Sep 2017 07:32:29 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id h15so20171432qta.4 for ; Wed, 06 Sep 2017 07:32:29 -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=CJUM0rc0L7jwVSLt36Y/LGju/3ByxFegM3yt4VEnZBE=; b=jOgkYSj8lWWHXrMMf35eb1GXBaBbPIiu8vvOdPOWPGnMO8bHIspinuQ5NCbn6wP1eV MNOoh/JCuFt2Bxcq9/Sknk4cL+EaDJlxjjuNkFqUaJInqHDLEZCXiguh1lUR+pFvq0ca YJRWzqkQ+PWF8J+L8gifgsZgCi9lS+1o3yF8EJRD5E5SmzdJ+m66nXnlKKn5ETXXJq72 tSHY8X2mvHqQdM5MfgS+9KFcyQD2GUZ7rXwkgVuaLBDUuhtHy/NJq+Zgb9hQ6aenmcn7 sOgCHsSwZXMhFpaIMaIzwcoPehu4/pK5RhskEqHxOYdgRmOFnCecgoibaLaIfqxYbR8x y92A== 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=CJUM0rc0L7jwVSLt36Y/LGju/3ByxFegM3yt4VEnZBE=; b=h09hQm3FatGuGaN9aTymYsevDj6AjHOx2HDvjleIlYhYasowOGrm9ZwTzg00SFJ92S EJa58Da2H3Q9bOtVAIqo3+PeopKb7Uo8v4Yl52Xmn0EIRC+rE7im5be0VrVyC0PJwvlO UaAbLoguWr7KeMbmOiaWbx4WtKKds17ho5ivWjn220e/VkpfzC4eQBEopLQHMjOq0A7M DIqJGxtNKDjYqTNW2UqDRI6HWuYQ1aohxSAbj7NaB0fmlzUK9OLBWli5lKq1HBYFPXOc 3htQ8UL35MS2Jq19UZVwDGAYETrzAOk2IwpHs5UuQM4CmlBl6SV8kfYdPNvYrixN2egF CSIQ== X-Gm-Message-State: AHPjjUis/kRYEviIe0XxQfxaW9KMsw/0eEdp1iHTMxSm3aGE5PPfaYTh kZG+MiHKfmWgzfefhVQuzw== X-Google-Smtp-Source: AOwi7QCIcK82AHmR/xk3gFlieVAo/iL8EPdAadJCugDyJYXGLn7cE4ZjX35lcb6xVnGdAlbS0Ji2rg== X-Received: by 10.200.49.88 with SMTP id h24mr3961574qtb.335.1504708348760; Wed, 06 Sep 2017 07:32:28 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id e6sm2391606qka.49.2017.09.06.07.32.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Sep 2017 07:32:27 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DC9028DF-1A7E-4DE0-9218-E40A2B6ED98A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 6 Sep 2017 10:32:25 -0400 In-Reply-To: <1504707346.2685505.1097120200.23CAA64D@webmail.messagingengine.com> Cc: jmap@ietf.org To: Bron Gondwana References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> <11664872-01E9-4F76-A621-3BE075CC5970@fugue.com> <20170906075815.GA1420@meili> <2B94C90D-3CFF-4828-9AA3-27741F226E57@fugue.com> <1504707346.2685505.1097120200.23CAA64D@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 06 Sep 2017 14:32:31 -0000 --Apple-Mail=_DC9028DF-1A7E-4DE0-9218-E40A2B6ED98A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 6, 2017, at 10:15 AM, Bron Gondwana = wrote: > The most common case I imagine IDs changing is when the upload creates = a temporary blobId which gets replaced by the real blobId when the = persistent message gets created. The blobId might then be = "emailid[mimepart]" for example, which won't change again while the = message persists. Right, but isn't this actually a problem? If it's implemented this = way, the MUA is _always_ going to wind up re-downloading the attachment. > The trickier part is things like deduplication of attachments, where = your server receives two messages which have byte-for-byte identical = attachments on them. Depending on your server architecture, you may not = want to parse the message, convert the attachments to binary and = calculate the digest to deduplicate before returning a blobId, which is = what you're talking about requiring if you require that there are never = two blobIds which result in the same bytes. It seems to me that if your server is implemented in this way, you're = really arguing for lazy evaluation: don't compute the blobId until = someone asks for it. In that case, when you compute the blobId, you = can do the deduplication as well. If you haven't parsed the message, = you don't even have an occasion to produce a blobId. --Apple-Mail=_DC9028DF-1A7E-4DE0-9218-E40A2B6ED98A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Sep 6, 2017, at 10:15 AM, Bron Gondwana <brong@fastmailteam.com> wrote:
The most = common case I imagine IDs changing is when the upload creates a = temporary blobId which gets replaced by the real blobId when the = persistent message gets created.  The blobId might then be = "emailid[mimepart]" for example, which won't change again while the = message persists.

Right, but isn't this actually a problem?   If = it's implemented this way, the MUA is _always_ going to wind up = re-downloading the attachment.

The trickier part is things like = deduplication of attachments, where your server receives two messages = which have byte-for-byte identical attachments on them.  Depending = on your server architecture, you may not want to parse the message, = convert the attachments to binary and calculate the digest to = deduplicate before returning a blobId, which is what you're talking = about requiring if you require that there are never two blobIds which = result in the same bytes.

It seems to me that if your server is implemented in this = way, you're really arguing for lazy evaluation: don't compute the blobId = until someone asks for it.   In that case, when you compute the = blobId, you can do the deduplication as well.   If you haven't = parsed the message, you don't even have an occasion to produce a = blobId.

= --Apple-Mail=_DC9028DF-1A7E-4DE0-9218-E40A2B6ED98A-- From nobody Fri Sep 8 21:43: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 6D419132703 for ; Fri, 8 Sep 2017 21:43:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E0 hex): From: "\340\244\205\340\244\234\340\244\257@\340\244\241\340\244\276[...] X-Spam-Flag: NO X-Spam-Score: 3.947 X-Spam-Level: *** X-Spam-Status: No, score=3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_ILLEGAL_CHARS=0.036, FROM_MISSP_XPRIO=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_SPAM=2.5] 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 WyhuYx0dpmlY for ; Fri, 8 Sep 2017 21:43:41 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.72.18]) by ietfa.amsl.com (Postfix) with ESMTP id D7D2B1326DF for ; Fri, 8 Sep 2017 21:43:38 -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/20170909/10/62484.84525486037(1504932212523); Sat, 9 Sep 2017 04:43:32 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 52343.07060123846(1504932209418); Sat, 9 Sep 2017 04:43:29 +0000 Date: Sat, 9 Sep 2017 10:13:29 +0530 (IST) From: "अजय@डाटा.भारत" To: jmap@ietf.org Message-ID: <1911633283.31291504932209416.JavaMail.root@power0.dil.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3129_43045525.1504932209414" XMessage-Id: XGenPlusMessageID:15049322092971978 X-Mailer: XGen Plus INSTANT MESSAGING SYSTEM X-ScheduledMail: FALSE X-ScheduledDate: 09/09/2017 04:43: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: 09/09/2017 04:43:00 X-BrowserType: Google Chrome X-Priority: 3 X-Right: X_XGEN_DLP: NO X-Alias-Id: xn--l1b0cxc@xn--c2bd1gb.xn--h2brj9c X_Xgen_Delivery_Report: no Archived-At: Subject: [Jmap] Alias and Downgrading in Action 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: Sat, 09 Sep 2017 04:43:45 -0000 ------=_Part_3129_43045525.1504932209414 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I think it may be good idea to also consider Email Alias, Single Mail Box for multiple IDs and Downgrading. I am attaching few videos and links to explain features in brief and would be happy to discuss further.1. Alias/ Merged Mail BoxDescription: http://support.xgenplus.com/aliasVideo: https://www.youtube.com/watch?time_continue=101&v=qv5dkgQhWXI2. Downgrading (Advanced)Description: http://support.xgenplus.com/alias (See Auto Downgrading Section)Video: https://www.youtube.com/watch?v=eSIb0FFmuS8Happy to discuss further. RegardsAjay [XGENFOOTER] [-XGENFOOTER] Do not Remove: [HID]20170830014011564[-HID] ------=_Part_3129_43045525.1504932209414 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit I think it may be good idea to also consider Email Alias, Single Mail Box for multiple IDs and Downgrading.  I am attaching few videos and links to explain features in brief and would be happy to discuss further.

1. Alias/ Merged Mail Box
Description: http://support.xgenplus.com/alias
Video: https://www.youtube.com/watch?time_continue=101&v=qv5dkgQhWXI

2. Downgrading (Advanced)
Description: http://support.xgenplus.com/alias (See Auto Downgrading Section)
Video: https://www.youtube.com/watch?v=eSIb0FFmuS8

Happy to discuss further. 

Regards

Ajay

[XGENFOOTER]

[-XGENFOOTER]

Do not Remove:
[HID]20170830014011564[-HID]
------=_Part_3129_43045525.1504932209414-- From nobody Sat Sep 9 16:58:39 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 C1B7413292B for ; Sat, 9 Sep 2017 16:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=HcIUIjTl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mMfksIIq 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 EyU51sRSnNf2 for ; Sat, 9 Sep 2017 16:58:36 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E85132705 for ; Sat, 9 Sep 2017 16:58:36 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 6F53D20D39 for ; Sat, 9 Sep 2017 19:58:35 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sat, 09 Sep 2017 19:58:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=RbMNSoUZT9878slHJ 2z2CCD5KCci0py8xqqO0utDGIA=; b=HcIUIjTl06wfH3HbtZiB26AqGawKmVZhD 2W05J/VrMOpoTrU90pDPNPnsX/48i+hOksIkZnSGUxKdBTn9pkKSyczUvZBaKZmD Ygof6aEck9TEiIzazwjF6imXvMOhVpn+K0BZtdHKazGifcN26Q+itqSSQ+VdPHn5 WMa49P6Taen/AhulQWff/J/mHMUw3LLBnZuk0bYaCnQxaPX72CU8p96/JAsDqBE7 YsYcVESZTq3kENs7pQe8DvqNqFt6TTyXosaUopq1T9sGpuqb0UcRbKKNRYsAOHLI /dhHFLo8GD50KjD/5dh4bTda32dS3/ryf7sjt4cpaN2bnRH86d0ow== 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=RbMNSo UZT9878slHJ2z2CCD5KCci0py8xqqO0utDGIA=; b=mMfksIIqs5pPe04w0ZKcoN xmuxAggrFa0yNWZ/4hQrAVGNTKmjh59IrAFlh0GwLOZOZBKFbi1G6plChs4c5qt+ sPUzNXbwaW5AAtN91nzkAU2wG90jp83e/nfHcWo6NKDmFN0ZNmYweJ73E9TNx79A RKcK5WDLb1mdqVVVRE4euKCi/645wSOZJ5jiuOvehII7dc7BB5VOImAvZxk3MAVW 9gAOkmULAC0GjjyygkrjD0nqlmkwWfNdQnKM4ySc0yP45IXG0EqHZIK4XJyORCU1 QmCRqf2I2SP1qZsrfAgoC1tWbtWx7jn1CxYrECaolHwAhnS97k1w8pd3B3l1hQqw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2C094E2625; Sat, 9 Sep 2017 19:58:35 -0400 (EDT) Message-Id: <1505001515.325606.1100847040.7A5DF00A@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15050015153256061" X-Mailer: MessagingEngine.com Webmail Interface - ajax-eaa98f8c References: <1911633283.31291504932209416.JavaMail.root@power0.dil.in> Date: Sun, 10 Sep 2017 09:58:35 +1000 In-Reply-To: <1911633283.31291504932209416.JavaMail.root@power0.dil.in> Archived-At: Subject: Re: [Jmap] Alias and Downgrading in Action 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: Sat, 09 Sep 2017 23:58:38 -0000 This is a multi-part message in MIME format. --_----------=_15050015153256061 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Ajay, On Sat, 9 Sep 2017, at 02:43 PM, =E0=A4=85=E0=A4=9C=E0=A4=AF@=E0=A4=A1=E0= =A4=BE=E0=A4=9F=E0=A4=BE.=E0=A4=AD=E0=A4=BE=E0=A4=B0=E0=A4=A4 wrote: > I think it may be good idea to also consider Email Alias, Single Mail > Box for multiple IDs and Downgrading. I am attaching few videos and > links to explain features in brief and would be happy to discuss > further. I believe creating/modifying aliases is too service-specific to be worth having in the JMAP Mail spec. You need to know what restrictions there are on the mailbox part, what domain names can be used, what addresses are available, whether the alias can target other users too etc. etc. Neil. --_----------=_15050015153256061 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Ajay,

I think it may be good idea to also consider= Email Alias, Single Mail Box for multiple IDs and Downgrading.  I am = attaching few videos and links to explain features in brief and would be ha= ppy to discuss further.

I believe creating/modifying aliases is too service-specific to be wor= th having in the JMAP Mail spec. You need to know what restrictions there a= re on the mailbox part, what domain names can be used, what addresses are a= vailable, whether the alias can target other users too etc. etc.

Neil.
--_----------=_15050015153256061-- From nobody Sun Sep 10 09:36: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 09F2F132EC2 for ; Sun, 10 Sep 2017 09:36:31 -0700 (PDT) X-Quarantine-ID: <7PPXn3TirnG6> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E0 hex): From: "\340\244\205\340\244\234\340\244\257@\340\244\241\340\244\276[...] X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_ILLEGAL_CHARS=0.036, FROM_MISSP_XPRIO=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PPXn3TirnG6 for ; Sun, 10 Sep 2017 09:36:27 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.72.18]) by ietfa.amsl.com (Postfix) with ESMTP id E8116132D6D for ; Sun, 10 Sep 2017 09:36:23 -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/20170910/22/85895.34607384613(1505061380633); Sun, 10 Sep 2017 16:36:20 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 4227.241091657142(1505061377506); Sun, 10 Sep 2017 16:36:17 +0000 Date: Sun, 10 Sep 2017 22:06:17 +0530 (IST) From: "अजय@डाटा.भारत" To: neil jenkins , ietf jmap mailing list Message-ID: <279120178.59611505061377503.JavaMail.root@power0.dil.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5961_1425581851.1505061377502" XMessage-Id: XGenPlusMessageID:1505061377415531 X-Mailer: XGen Plus INSTANT MESSAGING SYSTEM X-ScheduledMail: FALSE X-ScheduledDate: 10/09/2017 16:36:00 X-Followup: false X-FollowupTotal: 0 X-PersonalisedTag: FALSE X-Signature: FALSE X-ReplyAwaited: FALSE X-SendType: REPLYALL X-SentFromIP: 210.212.102.65 X-SentFromDate: 10/09/2017 16:36:00 X-BrowserType: Google Chrome X-Priority: 3 X-Right: X_XGEN_DLP: NO X-Alias-Id: xn--l1b0cxc@xn--c2bd1gb.xn--h2brj9c X_Xgen_Delivery_Report: no Archived-At: Subject: Re: [Jmap] Alias and Downgrading in Action 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, 10 Sep 2017 16:36:31 -0000 ------=_Part_5961_1425581851.1505061377502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Neil,, though I raised this point at very last stage.. but I thought "bette= r late than never" .I would like to point only two points to consider.. 1. = There may be a need to authenticate users using Alias ID on jmap.2. There m= ay be a need to use Different FROM ID (Alias) while sending mail. This may= be more important in case EAI is being used. How Alias gets implement at s= erver it surely an issue, . but if jmap supports that, I believe it will ha= ve better adoption in future. thanks.=20 =20 =20 From: Neil Jenkins MailId : [73196612]To: IETF JMAP Mailing List Subject:= Re: [Jmap] Alias and Downgrading in ActionDate: 10 Sep 2017 05:28:53 AM=20 Hi Ajay, =20 On Sat, 9 Sep 2017, at 02:43 PM, =E0=A4=85=E0=A4=9C=E0=A4=AF@=E0=A4=A1=E0= =A4=BE=E0=A4=9F=E0=A4=BE.=E0=A4=AD=E0=A4=BE=E0=A4=B0=E0=A4=A4 wrote: I think it may be good idea to also consider Email Alias, Single Mail Box f= or multiple IDs and Downgrading. I am attaching few videos and links to ex= plain features in brief and would be happy to discuss further. =20 I believe creating/modifying aliases is too service-specific to be worth ha= ving in the JMAP Mail spec. You need to know what restrictions there are on= the mailbox part, what domain names can be used, what addresses are availa= ble, whether the alias can target other users too etc. etc. =20 Neil. _______________________________________________Jmap mailing listJmap@ietf.o= rghttps://www.ietf.org/mailman/listinfo/jmapDo not Remove:[HID]201709100528= 50644[-HID] [XGENFOOTER] [-XGENFOOTER]=00 ------=_Part_5961_1425581851.1505061377502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Neil,, though I raised this point at very last stage.. but I thought "= better late than never" .

I would like to point only two points = to consider.. 

1. There may be a need to authenticate users= using Alias ID on jmap.
2. There may be a need to use Different FROM = ID (Alias) while sending mail.  This may be more important in case EAI= is being used. 

How Alias gets implement at server it sure= ly an issue, . but if jmap supports that, I believe it will have better ado= ption in future. 

thanks. 
 
 

From: Neil Jenkins <neilj@fastmailteam.com>&nb= sp; MailId = : [73196612]
To: IETF JMAP Mailing List <jm= ap@ietf.org>
Subject: Re: [Jmap] Alias and Downgra= ding in Action
Date: 10 Sep 2017 05:28:53 AM
Hi Ajay,
 
I think it may be good idea to also consider Email Alias, Single Mail = Box for multiple IDs and Downgrading.  I am attaching few videos and l= inks to explain features in brief and would be happy to discuss further.
 
I believe creating/modifying aliases is too service-specific to be wor= th having in the JMAP Mail spec. You need to know what restrictions there a= re on the mailbox part, what domain names can be used, what addresses are a= vailable, whether the alias can target other users too etc. etc.
 
Neil.
_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

<= span style=3D"color: #ffffff; font-family: arial; font-size: xx-small;">Do = not Remove:
[HID]20170910052850644[-HID]

[XGENFOOTER]

[-XGENFOOTER]
=00 ------=_Part_5961_1425581851.1505061377502-- From nobody Sun Sep 10 18:20:42 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 8728A132811 for ; Sun, 10 Sep 2017 18:20:40 -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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Hnf236/M; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hwgNhf4G 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 YEO7MlLJvOLO for ; Sun, 10 Sep 2017 18:20:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4681328EA for ; Sun, 10 Sep 2017 18:20:38 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id BE04A213BD for ; Sun, 10 Sep 2017 21:20:37 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 10 Sep 2017 21:20:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=OpboLTNTBW+XXE9bd aHuV+TJuyZbgpT22zNEmLWCuzc=; b=Hnf236/M62TU7KnxpG+9KLFikGf6yqVxN g7yNSCxiZZtrenkRSO5oHDPiitTSSiGDYj2niRRH3MwZZuIDdAqP/zg8ah4/5vzE w9MynblqUyWzpCAj36RRd6NJ8OZvzu2vb/ha2e+EPziOyXug3EOGWFPIzg33eeo2 tmGOFIbZa5n6yBuPwqd+h0vznD8KQ8WbAqDm8Ofj0LOuXnrnGcvG4NIQOmi5+xvq FvhETTEpdL3tJQ9e6qpiAinVA8oiNYuCiB3UTYpAP/O6FM+FWnlOuske9LuIIbF+ m3lnoe4EjFc6lpusmN69G+X2hLCFxgSe5eknPbHMaCPhoIDek9d3A== 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=OpboLT NTBW+XXE9bdaHuV+TJuyZbgpT22zNEmLWCuzc=; b=hwgNhf4GM3KafQH7hdSNkM znq8z2baMdZGuj6ypxFrYw3dHAvxiwJyy0B6WIumu4TnL+sg8h6L7o2HJKwS+MKV zNMY2gsP9MKc6mIEjXoqFegMFyF3uIc2g9cfA6l1KUyOIP9U5GNAb5RXlQ6uQhN9 T21urhwPSNXOqAieaD/LimC+8lLNEwnypagxd6uRMJwa6xA/Yyg3NEB9plrr9I3K 6lMwKy4GbsDgFrEKR7cAthfNI5c/dvFx2u17EsEJMCDWAgYrgJreUWM/F8O4YWSa PhCY7ZThYsQPQIaUKhsZANVUdxzBbwHf1Y723p7GGoIyee8Fu1toI7hbA7rZz9mw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7A05FE2514; Sun, 10 Sep 2017 21:20:37 -0400 (EDT) Message-Id: <1505092837.1450415.1101577504.65F1CC06@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150509283714504150" X-Mailer: MessagingEngine.com Webmail Interface - ajax-eaa98f8c Date: Mon, 11 Sep 2017 11:20:37 +1000 In-Reply-To: <279120178.59611505061377503.JavaMail.root@power0.dil.in> References: <279120178.59611505061377503.JavaMail.root@power0.dil.in> Archived-At: Subject: Re: [Jmap] Alias and Downgrading in Action 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, 11 Sep 2017 01:20:40 -0000 This is a multi-part message in MIME format. --_----------=_150509283714504150 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Mon, 11 Sep 2017, at 02:36 AM, =E0=A4=85=E0=A4=9C=E0=A4=AF@=E0=A4=A1=E0= =A4=BE=E0=A4=9F=E0=A4=BE.=E0=A4=AD=E0=A4=BE=E0=A4=B0=E0=A4=A4 wrote: > 1. There may be a need to authenticate users using Alias ID on jmap. Authentication is a whole big area still to be resolved, but even with the current proposal there is nothing to stop the server from accepting an alias for login (and returning the "real" username with the auth data at the end of successful authentication). > 2. There may be a need to use Different FROM ID (Alias) while sending > mail. This may be more important in case EAI is being used. This is covered already by the Identities[1] section of the JMAP Mail spec. Regards, Neil. Links: 1. http://jmap.io/spec-mail.html#identities --_----------=_150509283714504150 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
1. There may be a need to authenticate = users using Alias ID on jmap.

Authentication is a whole big area still to be resolved, but even with= the current proposal there is nothing to stop the server from accepting an= alias for login (and returning the "real" username with the auth data at t= he end of successful authentication).

2. There may be a need to use Different= FROM ID (Alias) while sending mail.  This may be more important in ca= se EAI is being used. 

This is covered already by the Identities section of the JMAP Mail spec.

Regards,
Neil.
--_----------=_150509283714504150-- From nobody Sun Sep 10 18:55: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 AB10A132F8F for ; Sun, 10 Sep 2017 18:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=cVxMVua9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A05WlAc6 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 5ne011Dktv2e for ; Sun, 10 Sep 2017 18:55:16 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73915132F8E for ; Sun, 10 Sep 2017 18:55:16 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 9F2BB20FEB for ; Sun, 10 Sep 2017 21:55:15 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 10 Sep 2017 21:55:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=woFwag4y3aQ2qOs5v u9TwHA9xn6PaLcr+7L/8xbF+5E=; b=cVxMVua9BryYPIyumZATL172ekji/+PDf wuTNbVvLB5lmnEFLVXXyhuDGJpLutWxbfUshvbMcX2aX7wVD07+EWF0hnSBU55f+ GpGeFWQWk13+mzH1/yWZLiNLlCqJQkkewU7z11V6JtAh9h14FT4p6KWELikcEQmg T1r1v4wWIr0N6c8s66kZbLyefF6KqW70v/GFdtO8/zmn2yISAnaJ2xAuEGYY8UAB C7P9ulDdY92nxencWtahY3hejBZWQeNydf/IU6iUdIphUBwBHSjLqbaVTc7HWpvW zIimKXhOCaquAEgGuDzr3WxYyromn1ogF46aytCsP2lL+tC0g5E4g== 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=woFwag 4y3aQ2qOs5vu9TwHA9xn6PaLcr+7L/8xbF+5E=; b=A05WlAc60ob8/s4laNOgPc W8e1/eIdFBG2mB5QIEp9bBuJ9AL9gMRaBeUW1vY30U3ipSzvxNPC2Jz5QcbDP1Rl KQ40X17DZ89anF/Pu+keWRlIP4If84gk3BRtzmEkZ8CsZPT6k8PkJd5Co6LMlSv1 zfBiRCYJYXl5P7yFwzLsfEm7ZnWsZ09zF9qGMiqw/DYLJAVT6pPQNv53voSL1i9X Qql+/a4FTg/ycN692H4q74kjEDP3vv6Y40LQND5Jt6CPTQw2EEfSbNUp8ikmnyRD mZqas5pME0STi4+hQlDIlN+HeI6w6oFUg9nUYG6jvoY/dADRjDrkYEOzPo5ciKmg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5A4DAE2514; Sun, 10 Sep 2017 21:55:15 -0400 (EDT) Message-Id: <1505094915.1469660.1101589824.06680A28@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150509491514696604" X-Mailer: MessagingEngine.com Webmail Interface - ajax-eaa98f8c In-Reply-To: References: <1504606540.3169111.1095557024.6EF92E43@webmail.messagingengine.com> Date: Mon, 11 Sep 2017 11:55:15 +1000 Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 11 Sep 2017 01:55:18 -0000 This is a multi-part message in MIME format. --_----------=_150509491514696604 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 5 Sep 2017, at 11:01 PM, Ted Lemon wrote: > From my perspective the data store is a collection of messages, plus a > collection of labels. This is a perfectly reasonable model, and in designing JMAP I have tried to allow servers to support this behaviour with the one slight quirk that all messages must be in at least one mailbox (have at least one "label"). The transition from IMAP to JMAP cannot happen overnight and providing a smooth transition path is really important to give it a chance of happening at all. If you mandate in JMAP that messages MUST be allowed to exist without any mailboxes, then you have the situation where users can see some mail only if they connect to their server with a JMAP client, and not if they use an IMAP client (unless you start mapping them in via a virtual mailbox, which is doable but has significant quirks and fundamentally I think requiring you to change your IMAP implementation if you want to add JMAP as well is likely to be a barrier to adoption). If you made it *optional* for servers to allow 0-mailbox messages, then you're increasing complexity for the spec and clients, and you still have the problem of what to do when deleting a mailbox for servers that opt not to allow 0-mailbox messages. I think that the current spec of returning an error, thus forcing the client to deal with it if there are existing messages in the mailbox you are trying to destroy, seems to be the least problematic solution. Does anyone else want to weigh in with an opinion on this? Neil. --_----------=_150509491514696604 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 5 Sep 2017, at 11:01 PM, Ted Lemon wrote:
From my perspective the data store is a collection of messages, plus a collection of labels.

This is a perfectly reasonable model, and in designing JMAP I have tried to allow servers to support this behaviour with the one slight quirk that all messages must be in at least one mailbox (have at least one "label").

The transition from IMAP to JMAP cannot happen overnight and providing a smooth transition path is really important to give it a chance of happening at all. If you mandate in JMAP that messages MUST be allowed to exist without any mailboxes, then you have the situation where users can see some mail only if they connect to their server with a JMAP client, and not if they use an IMAP client (unless you start mapping them in via a virtual mailbox, which is doable but has significant quirks and fundamentally I think requiring you to change your IMAP implementation if you want to add JMAP as well is likely to be a barrier to adoption).

If you made it optional for servers to allow 0-mailbox messages, then you're increasing complexity for the spec and clients, and you still have the problem of what to do when deleting a mailbox for servers that opt not to allow 0-mailbox messages.

I think that the current spec of returning an error, thus forcing the client to deal with it if there are existing messages in the mailbox you are trying to destroy, seems to be the least problematic solution.

Does anyone else want to weigh in with an opinion on this?

Neil.
--_----------=_150509491514696604-- From nobody Sun Sep 10 19: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 C8097132F8D for ; Sun, 10 Sep 2017 19:00:25 -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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ARGlo9dL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SOekEVZJ 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 DX8jTFnyl70O for ; Sun, 10 Sep 2017 19:00:24 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A2D12895E for ; Sun, 10 Sep 2017 19:00:24 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id BA82620F77 for ; Sun, 10 Sep 2017 22:00:23 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 10 Sep 2017 22:00:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=oR8ezF4eVAnt5pN8Y ujOs7eMSP/ZhZnOu9YEv3XDsJ8=; b=ARGlo9dL8Cwp5fI+7x3KuYXO75fY8jGcZ Ay71TbqJKt0f8qUtXR5pCBTZRpkU1szKX+Hk4jsr23eziEltrlH8XmAF6E1qAAoX 9IRbDVgCPDcA6xCy+CGtDljHlczwzS4hfQ283C+kRdp+JVoIUsNriKUt8ywb/J+B f4VN3xMCQ+s/J29CbVfQH/9olIOH+RvQWxlDBQpqdkzlFG0S4eC/BRYeSYYh8i5p pn4q17xw4gISlZs9lVsTulqDhD1Oj1NsCxnhMi/W9KD/AFq0u+CFEpJrWDbV135c 8uNiQq7aYtBOzYw4oeY35Ikn5r5XTW2CPmkGVe39qD2g1g0qTyLWw== 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=oR8ezF 4eVAnt5pN8YujOs7eMSP/ZhZnOu9YEv3XDsJ8=; b=SOekEVZJgoGK2gDlYqiOlg juxvJ4WAttNEhHXpbWLfIG2tk+cqix6zKLe4jLTcjM+Z7p1Ny7xYJ8A8RBuvdR6U C2Amr2FDD4O7y8KcwQcUzdx7LyMgLpIlQ/kO5rmh2ZksyQqIvt3lIIhYl8XykDIB RDllTembZen1UvELrtSxvHa2MtwKf2MZ+upe+BTNuZoIoxes6xp5XQGSIxPhVtB9 CfynHLcuG9M/tooI/iuugUTUOCWdMVxC4tjOcLpklNW0v4iyuTd87el5pOHhIJtR L2jTkFQDdGCwipVDbSS1CPY09lMOYnrj2gW/haeGfOKliSAvFwzrdwbDMv2jPV0g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 85264E2514; Sun, 10 Sep 2017 22:00:23 -0400 (EDT) Message-Id: <1505095223.1473342.1101603192.1648073A@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150509522314733421" X-Mailer: MessagingEngine.com Webmail Interface - ajax-eaa98f8c References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> <11664872-01E9-4F76-A621-3BE075CC5970@fugue.com> <20170906075815.GA1420@meili> <2B94C90D-3CFF-4828-9AA3-27741F226E57@fugue.com> <1504707346.2685505.1097120200.23CAA64D@webmail.messagingengine.com> In-Reply-To: Date: Mon, 11 Sep 2017 12:00:23 +1000 Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 11 Sep 2017 02:00:26 -0000 This is a multi-part message in MIME format. --_----------=_150509522314733421 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 7 Sep 2017, at 12:32 AM, Ted Lemon wrote: > On Sep 6, 2017, at 10:15 AM, Bron Gondwana > wrote:>> The most common case I imagine IDs changing is when the upload >> creates a temporary blobId which gets replaced by the real blobId >> when the persistent message gets created. The blobId might then be >> "emailid[mimepart]" for example, which won't change again while the >> message persists.> Right, but isn't this actually a problem? If it's implemented this > way, the MUA is _always_ going to wind up re-downloading the > attachment. Why? The client that uploaded the file will send the original blobId in the setMessages request and get back the new on in the messagesSet response, so can update its internal cache without downloading it again. Other clients cannot see it until the message is created anyway. In either case, there's no need for the same file to be downloaded again. Neil. --_----------=_150509522314733421 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 7 Sep 2017, at 12:32 AM, Ted Lemon wrote:
On Sep 6, 2017, at 10:15 AM, Bron Gondwana <brong@fastmailteam.com> wrote:
The most common case I imagine IDs changing is when the upload creates a temporary blobId which gets replaced by the real blobId when the persistent message gets created.  The blobId might then be "emailid[mimepart]" for example, which won't change again while the message persists.
Right, but isn't this actually a problem?   If it's implemented this way, the MUA is _always_ going to wind up re-downloading the attachment.

Why? The client that uploaded the file will send the original blobId in the setMessages request and get back the new on in the messagesSet response, so can update its internal cache without downloading it again. Other clients cannot see it until the message is created anyway. In either case, there's no need for the same file to be downloaded again.

Neil.
--_----------=_150509522314733421-- From nobody Sun Sep 10 19:05:38 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 2B193132F90 for ; Sun, 10 Sep 2017 19:05:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 91uCKWkdXwXX for ; Sun, 10 Sep 2017 19:05:36 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 6097E132F8E for ; Sun, 10 Sep 2017 19:05:36 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id v36so4555075ioi.1 for ; Sun, 10 Sep 2017 19:05:36 -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=TiN7cWy71WYinO4Uf+f5o+R8UFIn8/ygvZ2PYuUrM0I=; b=b8xPfdTyZBDW+etRpu6oooegQUdCojw74Th0GLg5a+RPOLMQ2AiUi+Wd3DQkgwYjzl gtv7s5wNsAxzoRhsnCrRZkCKGs7b3PQUESOxfQCUt8bo8qK/tZAVBnF3iVqAu2AJ1ckd j0Rwm9ksRuAAO1PlukD62I+wzwdY6ewoIC0X9oNG4blp/FNbX7/J3Knyk0H3j10b/81d tWkNOQPDSm+HCk871um3nYlz2gs+IzDjmgEWVnL7+zI/GZR/FJI8qHh20hUxqoH/R4xz uGJqJkSngx2rQkVEu6aJ9YCkSUbc9tpgaXD7ZpJ9NXfTw9ejFJY3d2p+8y5QQPRBVfqr GWvQ== 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=TiN7cWy71WYinO4Uf+f5o+R8UFIn8/ygvZ2PYuUrM0I=; b=ZKUsWtH8dXSM93ZocHfU6qhW/I3ivHS39Wy1I1wuu6tK4QwyKNFy+yGPN7Xo/SY0eA PqX0YGD5PZtxAfj5xT6WiCFkIAksO+P1rh+CFt7D1Jpu7mFQAmCEeTXA8tG11Ks0WTcV x27qk+w5QOr2dnX5QJhQ1BnA/o6iJUImOIVq5Ca9ctN6T8kpstX3dfyvs7ZFMvvmOWjW ig21zrg7yJRYai7pUshKa+mk/gdjqeyWNjrsKx4FkZt8iifPWmhOy/bdTAWB2G5aBjY3 JBAUlAMm+KYFvYqTAA04enGOPh1Ple1c5zkTylB6708iqiQzy9pz66fRF+NrEcgnCUv2 cZRQ== X-Gm-Message-State: AHPjjUiKXMWyCVHLqS5/R/DikagrdOumxI2JPd0jcMUdYDbjj0vY3G2g 7/JZamUGw5cblOQejoyA4g== X-Google-Smtp-Source: AOwi7QALvT4VBFFRyd0RHZsL8UzSEn/hmh3QtX3ReGmuCKFBHoFZXMMssWTJG7eUXlhOMZBj1GpBmA== X-Received: by 10.202.236.3 with SMTP id k3mr9477823oih.27.1505095535465; Sun, 10 Sep 2017 19:05:35 -0700 (PDT) Received: from [192.168.6.48] ([50.235.123.18]) by smtp.gmail.com with ESMTPSA id s133sm8582097oih.25.2017.09.10.19.05.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Sep 2017 19:05:34 -0700 (PDT) From: Ted Lemon Message-Id: <8918AA93-D813-47FC-B0F5-EEC8BA885B80@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CE901E9E-71B5-4B80-8627-D5D798AF01B1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 10 Sep 2017 22:05:30 -0400 In-Reply-To: <1505094915.1469660.1101589824.06680A28@webmail.messagingengine.com> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <1504606540.3169111.1095557024.6EF92E43@webmail.messagingengine.com> <1505094915.1469660.1101589824.06680A28@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 11 Sep 2017 02:05:38 -0000 --Apple-Mail=_CE901E9E-71B5-4B80-8627-D5D798AF01B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 10, 2017, at 9:55 PM, Neil Jenkins = wrote: > Does anyone else want to weigh in with an opinion on this? Acknowledging that you were not asking me to weigh in again, I just want = to clarify that I do not think that "messages with zero labels" are = necessary. I do think that an "all" mailbox is sufficient to address = this issue: every message is always labeled "all," or, if you are using = a JMAP skin over an IMAP server, then every message is always in the = "all" mailbox as well as whatever other mailboxes, if any, it may be in. --Apple-Mail=_CE901E9E-71B5-4B80-8627-D5D798AF01B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Sep 10, 2017, at 9:55 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:
Does = anyone else want to weigh in with an opinion on = this?

Acknowledging = that you were not asking me to weigh in again, I just want to clarify = that I do not think that "messages with zero labels" are necessary. =   I do think that an "all" mailbox is sufficient to address this = issue: every message is always labeled "all," or, if you are using a = JMAP skin over an IMAP server, then every message is always in the "all" = mailbox as well as whatever other mailboxes, if any, it may be = in.


= --Apple-Mail=_CE901E9E-71B5-4B80-8627-D5D798AF01B1-- From nobody Sun Sep 10 19:08: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 348C9132F90 for ; Sun, 10 Sep 2017 19:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Z_1zLQMuLk94 for ; Sun, 10 Sep 2017 19:08:31 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 03C4F1201F8 for ; Sun, 10 Sep 2017 19:08:31 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id a128so16005173qkc.5 for ; Sun, 10 Sep 2017 19:08:30 -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=f8/PjaMNhUf3ObGuG626ZygLrPi6dTrjyeCeLzsiJIY=; b=Op4eG5UkAwjcwkhGJRhrLyMjrX2c/gkZKG+1s3WMVoDw2ITokNkpxQrR9UV/rbvNyV p7uKli7r1vJAdvxNKj3C+4t4PUYy29qiqW35PT+wZLGb/qwxVNJHNlUAf2oz0keRLbFS d7jChuH7uhl1npoXJhLwFQAj+J+OluEwD+aba08JxGWy/fQIaN3dXSdlV7GFhlGvj9VW w+0B63tCBZoFzBLHJuQgWRFcEwwz3gWD4Ey81uSSrKQvWKk4gh53c3GuamUURMiyE+zs 0Z5fNFKlsY+rMkc1hhYHlNumC19Aggzr3YcJxS0e6ZiGdq1UVq3Um9xISpNyKbbeGzdK beBw== 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=f8/PjaMNhUf3ObGuG626ZygLrPi6dTrjyeCeLzsiJIY=; b=iMcyQ5Yg5WGYQlrnmHC81xWlP/Yrpmh39ywNlxUbpVbMbLpig4BbmPbbO5xasc78S3 Yqj8WzDfcRIskyli8j9tG8Mw07/spiAgmMivEZMuoLdkawC3C2HLUjmFpGGJUWVwnCEs M6cIJwzOt5+o9RZidV9DJzlY7Eb/+nXA4zL39EOCLb1Wj1uq35kjN7jWf7srAQZzWdMU 2vQP5Uh0GSqw8/jkrcQ+GzLMx0IhahmK5wAKiXIuZfseIo7js1ZR0B7E6NKGbnsngSaO 5WLAjcT7+18lwI9LyU1247odUZPd71ndo3pCZEkNC1jnzQunEZpYxg3hn0tPlgJ8iNQ9 IFtg== X-Gm-Message-State: AHPjjUi6X8BswSOH33prEBI2czajEWzxB8nWkihSezYkGDi+Lxipz22J h7L9AE1LEKHQlhCoNlKChw== X-Google-Smtp-Source: AOwi7QAsDJaja9Na49lLd4e9RqvwHM++amvwCNWfkn0fUcFNmI6AFsHvJqd8p3+HMNpLJpAlfW74XQ== X-Received: by 10.55.109.66 with SMTP id i63mr12451155qkc.19.1505095710007; Sun, 10 Sep 2017 19:08:30 -0700 (PDT) Received: from [192.168.6.48] ([50.235.123.18]) by smtp.gmail.com with ESMTPSA id s3sm5410863qtg.79.2017.09.10.19.08.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Sep 2017 19:08:28 -0700 (PDT) From: Ted Lemon Message-Id: <3739A822-F18C-4B13-9E88-DCD87C2F7E6E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_62C64ED5-1F8D-4A7D-90CD-7D1A2F140776" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 10 Sep 2017 22:08:26 -0400 In-Reply-To: <1505095223.1473342.1101603192.1648073A@webmail.messagingengine.com> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili> <1504657427.3980380.1096460312.448C3D7C@webmail.messagingengine.com> <11664872-01E9-4F76-A621-3BE075CC5970@fugue.com> <20170906075815.GA1420@meili> <2B94C90D-3CFF-4828-9AA3-27741F226E57@fugue.com> <1504707346.2685505.1097120200.23CAA64D@webmail.messagingengine.com> <1505095223.1473342.1101603192.1648073A@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01 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, 11 Sep 2017 02:08:32 -0000 --Apple-Mail=_62C64ED5-1F8D-4A7D-90CD-7D1A2F140776 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 10, 2017, at 10:00 PM, Neil Jenkins = wrote: > Why? The client that uploaded the file will send the original blobId = in the setMessages request and get back the new on in the messagesSet = response, so can update its internal cache without downloading it again. = Other clients cannot see it until the message is created anyway. In = either case, there's no need for the same file to be downloaded again. Okay, that's a good point=E2=80=94if there's no way for another client = to see the blobID, then we don't have that problem. But we still do = have the problem that the client has to do more than it would have to do = if the blobID didn't change. But I will admit that that is a much = smaller problem. --Apple-Mail=_62C64ED5-1F8D-4A7D-90CD-7D1A2F140776 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 10, 2017, at 10:00 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:
Why? The client that uploaded the file = will send the original blobId in the setMessages request and get back = the new on in the messagesSet response, so can update its internal cache = without downloading it again. Other clients cannot see it until the = message is created anyway. In either case, there's no need for the same = file to be downloaded again.

Okay, that's a good point=E2=80=94if there's = no way for another client to see the blobID, then we don't have that problem.   But we still do have the = problem that the client has to do more than it would have to do if the = blobID didn't change.   But I will admit that = that is a much smaller problem.

= --Apple-Mail=_62C64ED5-1F8D-4A7D-90CD-7D1A2F140776-- From nobody Mon Sep 11 12:56:30 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 1C29F132F32 for ; Mon, 11 Sep 2017 12:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 zY3T6KNSC7qe for ; Mon, 11 Sep 2017 12:56:26 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBBE132339 for ; Mon, 11 Sep 2017 12:56:26 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 44660FA0081; Mon, 11 Sep 2017 19:56:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1505159784; bh=1xG10kI0rsygV7+mBsTYPvEZL0RghtFdeVej9FhKkeE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iDmpXBkBaF8Q4rhHHKAbXeQjedRSM5TfMPxaRvrWZzql7828qlz7wJRk2roKw86/O teokY2xz7tLpWjQYMZAFgwNqHsmX66nZkgm9f7rpyZYTMIgG2dUYQfZpoJnioXu4eH xTen5xV5BEpRuBZbO34yE+b2Ues89RFMfizBwUmo= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1505159783-21613-21127/11/9; Mon, 11 Sep 2017 19:56:23 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 11 Sep 2017 20:56: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: <1505094915.1469660.1101589824.06680A28@webmail.messagingengine.com> References: <1504606540.3169111.1095557024.6EF92E43@webmail.messagingengine.com> <1505094915.1469660.1101589824.06680A28@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 11 Sep 2017 19:56:29 -0000 Neil Jenkins writes: > Does anyone else want to weigh in with an opinion on this? I'll weigh in with another. It's a minor advantage if the text chosen permits moving forward with=20 zero-mailbox messages at some future time (e.g. when world peace breaks=20 out, people stop using pop3 or both of the above). At this time, imap compatibility is an effective requirement. But that = may=20 not remain true =E2=80=94 lots of new clients are gmail-only now, a few = jmap-only=20 clients could change the picture in a handful of years. You've seen the rule I proposed. I think that permits moving forward. Arnt From nobody Mon Sep 11 13:36:40 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 BCED6132351 for ; Mon, 11 Sep 2017 13:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=mailforce.net header.b=LlVkDJDp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VtL0ar2R 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 7N8TCP8XhcL4 for ; Mon, 11 Sep 2017 13:36:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F392F132D6A for ; Mon, 11 Sep 2017 13:36:36 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7051220E21 for ; Mon, 11 Sep 2017 16:36:36 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 11 Sep 2017 16:36:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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:x-sasl-enc; s=fm1; bh=K9l3qDQ93o2I/1dAyR yHYI6JXcBeQ2ERRQNfkrv9szA=; b=LlVkDJDpJ1s1KbhkAiiuolk36zQDYmrB/K x+6kI8omG0N/npYSzW2l0bzokeS8BPS7/pmhSVndxPom3iq6bMS6nXf3P/IoI5hv cdCP1hguD7ysct/0q0oONjciCz/5Sal80nhgKZkxAnNwceci1yWy0VWArMaYOwmY BLlhDxvVeTmM0fpd3UZ/49Urqjx14nXWgMK3izh8VjwRhu+CWiaAzHPho7Nb/G3T VUdhK5S0/CBW/zZ3bsavt6SRq/6CLUqVOZOoOTTJFfgX4BJacVNQ9lekYsZNtgQ7 U0e9L0fVN/bIsRrFJ58+/lVPPacc/qWmAjqXJ8qnLjusaOMzYLkg== 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:x-sasl-enc; s= fm1; bh=K9l3qDQ93o2I/1dAyRyHYI6JXcBeQ2ERRQNfkrv9szA=; b=VtL0ar2R d9PkV6GIIxTh8Xl83MMdFcOMp7ev5jaidFwATOCEiASZh0l+a3GJkmZ75m/hqT8O TRPlt3t3JH1BeJUf6Ze9L1ffp4I/8bP/85aMAgw0I+B+h88sP8M4cUd3j+7SFO+8 2zfXzRlSSs+bdmYnjdxJ7V1xdwgaO1urq+umnavVXEac8r4aPTgO2L6W384Eo3I8 EMfH3LxxlFDvUmJkb9NAQDaIBSxD2bxCwFAWrM42eajlyGzVEM2XaEjUcu09M1Ox C1NPNQTSbMzyy13SEXKdeTYFVDPj6oQyB052KVDutt1MF985k1W/G42gIAyKuMFP 5CUtVcR0v5mMwg== X-ME-Sender: X-Sasl-enc: 7GQXizSFsZpXdzZyU9flNoVXmf5xYbTkkSQs07gdqk6i 1505162195 Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id F1BEC7F982 for ; Mon, 11 Sep 2017 16:36:35 -0400 (EDT) References: <1504606540.3169111.1095557024.6EF92E43@webmail.messagingengine.com> <1505094915.1469660.1101589824.06680A28@webmail.messagingengine.com> From: Stan Kalisch Content-Type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (13G36) In-Reply-To: Message-Id: <7D83006F-84B9-4A47-8D43-A0496397B872@glyphein.mailforce.net> Date: Mon, 11 Sep 2017 16:36:34 -0400 To: jmap@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 11 Sep 2017 20:36:39 -0000 For my two cents, I was going to propose roughly the same thing, so +1. Stan > On Sep 11, 2017, at 3:56 PM, Arnt Gulbrandsen w= rote: >=20 > Neil Jenkins writes: >> Does anyone else want to weigh in with an opinion on this? >=20 > I'll weigh in with another. >=20 > It's a minor advantage if the text chosen permits moving forward with zero= -mailbox messages at some future time (e.g. when world peace breaks out, peo= ple stop using pop3 or both of the above). >=20 > At this time, imap compatibility is an effective requirement. But that may= not remain true =E2=80=94 lots of new clients are gmail-only now, a few jma= p-only clients could change the picture in a handful of years. >=20 > You've seen the rule I proposed. I think that permits moving forward. >=20 > Arnt >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Tue Sep 12 03:08:44 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 8A9DD133323 for ; Tue, 12 Sep 2017 03:08:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E0 hex): From: "\340\244\205\340\244\234\340\244\257@\340\244\241\340\244\276[...] X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_ILLEGAL_CHARS=0.036, FROM_MISSP_XPRIO=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7_WuH3k7ZLy for ; Tue, 12 Sep 2017 03:08:39 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.72.20]) by ietfa.amsl.com (Postfix) with ESMTP id 74DCB133011 for ; Tue, 12 Sep 2017 03:08:35 -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/20170912/15/21227.14392663527(1505210911685); Tue, 12 Sep 2017 10:08:31 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 30360.8373726888(1505210908504); Tue, 12 Sep 2017 10:08:28 +0000 Date: Tue, 12 Sep 2017 15:38:28 +0530 (IST) From: "अजय@डाटा.भारत" To: neil jenkins , ietf jmap mailing list Message-ID: <436170702.20081505210908502.JavaMail.root@power0.dil.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2008_1301140129.1505210908501" XMessage-Id: XGenPlusMessageID:15052109084728020 X-Mailer: XGen Plus INSTANT MESSAGING SYSTEM X-ScheduledMail: FALSE X-ScheduledDate: 12/09/2017 10:08: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: 12/09/2017 10:08:00 X-BrowserType: Google Chrome X-Priority: 3 X-Right: X_XGEN_DLP: NO X-Alias-Id: xn--l1b0cxc@xn--c2bd1gb.xn--h2brj9c X_Xgen_Delivery_Report: no Archived-At: Subject: Re: [Jmap] Alias and Downgrading in Action 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, 12 Sep 2017 10:08:42 -0000 ------=_Part_2008_1301140129.1505210908501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you Neil. Sounds like it has been already taken care.. Great.. !!Tha= nks.=20 =20 From: Neil Jenkins MailId : [73232073]To: IETF JMAP Mailing List Subject:= Re: [Jmap] Alias and Downgrading in ActionDate: 11 Sep 2017 06:50:58 AM=20 On Mon, 11 Sep 2017, at 02:36 AM, =E0=A4=85=E0=A4=9C=E0=A4=AF@=E0=A4=A1=E0= =A4=BE=E0=A4=9F=E0=A4=BE.=E0=A4=AD=E0=A4=BE=E0=A4=B0=E0=A4=A4 wrote: 1. There may be a need to authenticate users using Alias ID on jmap. =20 Authentication is a whole big area still to be resolved, but even with the = current proposal there is nothing to stop the server from accepting an alia= s for login (and returning the "real" username with the auth data at the en= d of successful authentication). =20 2. There may be a need to use Different FROM ID (Alias) while sending mail.= This may be more important in case EAI is being used.=20 =20 This is covered already by the Identities section of the JMAP Mail spec. =20 Regards, Neil. _______________________________________________Jmap mailing listJmap@ietf.o= rghttps://www.ietf.org/mailman/listinfo/jmapDo not Remove:[HID]201709110650= 541[-HID] [XGENFOOTER] [-XGENFOOTER]=00=00 ------=_Part_2008_1301140129.1505210908501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Neil.  Sounds like it has been already taken care..&nbs= p;

Great.. !!

Thanks. 
 

From: Neil Jenkins <neilj@fastmailteam.com>&nb= sp; MailId = : [73232073]
To: IETF JMAP Mailing List <jm= ap@ietf.org>
Subject: Re: [Jmap] Alias and Downgra= ding in Action
Date: 11 Sep 2017 06:50:58 AM
1. There may be a need to authenticate users using Alias ID on jmap.
 
Authentication is a whole big area still to be resolved, but even with= the current proposal there is nothing to stop the server from accepting an= alias for login (and returning the "real" username with the auth data at t= he end of successful authentication).
 
2. There may be a need to use Different FROM ID (Alias) while sending = mail.  This may be more important in case EAI is being used. 
 
This is covered already by the Identities section of the JMAP Mail spec.
 
Regards,
Neil.
_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

<= span style=3D"color: #ffffff; font-family: arial; font-size: xx-small;">Do = not Remove:
[HID]201709110650541[-HID]

[XGENFOOTER]

[-XGENFOOTER]
=00=00 ------=_Part_2008_1301140129.1505210908501-- From nobody Tue Sep 12 20:45:39 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 29D6E132939 for ; Tue, 12 Sep 2017 20:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 9uwJIL1FsqpZ for ; Tue, 12 Sep 2017 20:45:36 -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 686DB120720 for ; Tue, 12 Sep 2017 20:45:36 -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 v8D3jVqD016626 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 03:45:32 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v8D3jVnG024085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 03:45:31 GMT Received: from ubhmp0005.oracle.com (ubhmp0005.oracle.com [156.151.24.58]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8D3jVEw009949; Wed, 13 Sep 2017 03:45:31 GMT Received: from [10.159.148.27] (/10.159.148.27) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Sep 2017 03:45:30 +0000 From: "Chris Newman" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Tue, 12 Sep 2017 20:45:29 -0700 Message-ID: <01CCF1A2-A709-412C-90F7-6DAC3A71AD39@oracle.com> In-Reply-To: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_69F503EB-21EC-4784-B7DB-02C24093D2F8_=" Embedded-HTML: [{"HTML":[2224, 1501], "plain":[809, 1442], "uuid":"79CBD742-A09C-4CA2-9792-3E4888438308"}] X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 13 Sep 2017 03:45:38 -0000 --=_MailMate_69F503EB-21EC-4784-B7DB-02C24093D2F8_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable There are a bunch of useful goals I'd want this to address: * make the behavior explicit * retain compatibility with an IMAP mail store (within reason), as = required by the WG charter * make it easy for clients to use * don't constrain client model unnecessarily (a mistake made with IMAP = \Deleted model) So how about adding "onLastReferenceMoveTo" attribute with a mailbox ID = value to setMailboxes? If that attribute is omitted, the destroy mailbox action fails if it = would leave any message unreferenced (as Arnt suggested). If there's a = mailbox with "all messages" role, the client can use that if it wants to = delete a label in that class of message store. Otherwise inbox or trash = or archive are reasonable options, depending on the client UI. - Chris On 3 Sep 2017, at 21:54, Neil Jenkins wrote: > As per #69[1], this needs some discussion. If a mailbox has messages = > in > it and the client tries to destroy it, what should happen? The spec > currently says this must be rejected with an error, following the > general JMAP philosophy that changes made by the client must be = > explicit > rather than implicit. > The IMAP model is of course different: the messages in the mailbox = > would > be implicitly removed from this mailbox, and if not in any other = > mailbox > they would also be permanently destroyed. This is why I think this = > model > is dangerous. In a system where messages can belong to multiple > mailboxes, removing a mailbox (deleting a label) makes sense, but you > don't want the message to be destroyed. However, for IMAP = > compatibility > we require all messages in JMAP to be in at least one mailbox. So if > this was the only mailbox the message was in, the message must also be > either destroyed or automatically added to another mailbox (which I > think is even more problematic). Making it an error requires the = > client > to deal with this situation first in an appropriate way. > Opinions on the right action here? > > Neil. > > Links: > > 1. = > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_jmapi= o_jmap_issues_69&d=3DDwICaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK= 10&r=3DQBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3DRAwHDp1kpF_qCXknEQ= gF9flzE1a_zDj2fMKZXuWf0OY&s=3D_8zDKKoAppv1qycFv1Lz0LmKGMX7HyjZ3eWm1Vo1wOE= &e=3D > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_jmap&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DQBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3DRAwHDp1kpF_qCXkn= EQgF9flzE1a_zDj2fMKZXuWf0OY&s=3D_ky66Mm_D36c0LWpy3lHH7LgxMyUtcRXxj3BbMs3g= SM&e=3D --=_MailMate_69F503EB-21EC-4784-B7DB-02C24093D2F8_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

There are a bunch of useful goal= s I'd want this to address:
* make the behavior explicit
* retain compatibility with an IMAP mail store (within reason), as requir= ed by the WG charter
* make it easy for clients to use
* don't constrain client model unnecessarily (a mistake made with IMA= P \Deleted model)

So how about adding "onLastReferenceMoveTo" att= ribute with a mailbox ID value to setMailboxes?

If that attribute is omitted, the destroy mailbox action = fails if it would leave any message unreferenced (as Arnt suggested). If = there's a mailbox with "all messages" role, the client can = use that if it wants to delete a label in that class of message store. Ot= herwise inbox or trash or archive are reasonable options, depending on th= e client UI.

- Chris

On 3 Sep 2017, at 21:54, Neil Jenkins wrote:

As per #69, this needs some discussion. If a mai= lbox has messages in it and the client tries to destroy it, what should h= appen? The spec currently says this must be rejected with an error, follo= wing the general JMAP philosophy that changes made by the client must be = explicit rather than implicit.

The IMAP model is of course different: the messages in the mailbox w= ould be implicitly removed from this mailbox, and if not in any other mai= lbox they would also be permanently destroyed. This is why I think this m= odel is dangerous. In a system where messages can belong to multiple mail= boxes, removing a mailbox (deleting a label) makes sense, but you don't w= ant the message to be destroyed. However, for IMAP compatibility we requi= re all messages in JMAP to be in at least one mailbox. So if this was the= only mailbox the message was in, the message must also be either destroy= ed or automatically added to another mailbox (which I think is even more = problematic). Making it an error requires the client to deal with this si= tuation first in an appropriate way.

Opinions on the right action here?

Neil.
--=_MailMate_69F503EB-21EC-4784-B7DB-02C24093D2F8_=-- From nobody Sun Sep 17 18:28: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 AD9861201F8 for ; Sun, 17 Sep 2017 18:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=fDXrRoZw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RsIvyAmQ 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 DFkcUVHZUPSW for ; Sun, 17 Sep 2017 18:28:52 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC1E132620 for ; Sun, 17 Sep 2017 18:28:52 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id CA95220AF8 for ; Sun, 17 Sep 2017 21:28:51 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 17 Sep 2017 21:28:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=rTx3uN+tpN8m8eiwL IaCTZsp/aSN39lbXFeWGBAu3dA=; b=fDXrRoZwchegOsBd7hjf1R8DONcoGfCck BK5zekw7TVpCwQOVjcLZ99NWCBTJ+hRN/T5qKb5OMrZr9UTEo9bWyhdesDRcZ3Vb 3bDbP3dOBj+TmWKxpbJidtwGEglc1mLW7m8tKmr9HWtexPfgzbmNYdOLBI3MMr3W fTZWmITC8vOMc9VeGGBvLnft/QBjG3UD3SZlAYqfvTSnSLTj+0PcLtKHIlAN1bbn MZlEh+Mft8M4JteoS8vbPsyg4CK9KfGt+fe7ZD8eVbHNJmozUGd5SZBS8gmoDtrL IiTTAEiUUOZBgn9y830gXeYyfdLij5gXObLl0diIo6o6jeh3k2+yg== 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=rTx3uN +tpN8m8eiwLIaCTZsp/aSN39lbXFeWGBAu3dA=; b=RsIvyAmQot5Xv7LqBJN14O Bl7RyB3GdJQtBvdoy9ZwsgFHJvkxYwImEfisgFeqqzz/Hhd9JE+FaprgIOb6Q8Sr +SpNUAcWPHQOZVVOQMGkYoFKP7BEXAQaBfzrdOJlVW8deeSN4AEUy8+vrm94OcUl RSgwATp+vyTufXd6RO7Jr6wbh37r1WrkpL+TWrbRNhiRrV8bZEhEfB++28bNz9KE 3L0Q6E5A7xeTmHg29sJJEusAk3mArqMNIVawc5HOd9zRmjo7EK9qeJA4vhWZIG5B T/U4Ae4o395JdSlpFHeJjiu0mwy90DCHW7YtozUGHl29RHe3Sy7XvmURn1i1h9Xw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 86625E251B; Sun, 17 Sep 2017 21:28:51 -0400 (EDT) Message-Id: <1505698131.2041914.1109222872.6A22DCE0@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150569813120419147" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2fd676b4 In-Reply-To: <01CCF1A2-A709-412C-90F7-6DAC3A71AD39@oracle.com> Date: Mon, 18 Sep 2017 11:28:51 +1000 References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <01CCF1A2-A709-412C-90F7-6DAC3A71AD39@oracle.com> Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 18 Sep 2017 01:28:57 -0000 This is a multi-part message in MIME format. --_----------=_150569813120419147 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 13 Sep 2017, at 01:45 PM, Chris Newman wrote: > So how about adding "onLastReferenceMoveTo" attribute with a mailbox > ID value to setMailboxes? The "special-case"ness of this annoys me slightly, but the functionality is useful. How does this look to people: https://github.com/jmapio/jmap/pull/145? Cheers, Neil. --_----------=_150569813120419147 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 13 Sep 2017, at 01:45 PM, Chris Newman wrote:
So how about adding "onLastReferenceMoveTo" attribute with a mailbox ID value to setMailboxes?


Cheers,
Neil.
--_----------=_150569813120419147-- From nobody Sun Sep 17 18:34:04 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 95FFD132EA7 for ; Sun, 17 Sep 2017 18:34:03 -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, 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 3ZRxDcrRjkcF for ; Sun, 17 Sep 2017 18:34:00 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 8A37712426E for ; Sun, 17 Sep 2017 18:34:00 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o77so6038764qke.9 for ; Sun, 17 Sep 2017 18:34:00 -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=K/9kGZGLbBJHvXV9eJoUu119iMextvQTW5E/iUSW6Xw=; b=rFzrhEFsLQnc6BobxvnWcaiRLZfx40LfbW7ari2toj86ciJNN4m7SQjBEYoCYBb4l3 B6mXLG8z0uqHaS/0UiHe2zLCSne1Kvl8ziiBJfIiMCFaq7FSvbeTewnYsEfPsPn8ZQCR ux1wDDexlZZN/SwttnpCHZz5Mq7Ywa4e/nPAYQx8YH405MUmX7yHe8XaDC5q2m6Kz6ON fWf08OmKFx8mEWBjZjm0Th0S1J2gk2aeyE5Te8x7Zgx2sEZBWfuCFcHNnw+moMw6PkoS F5nt3bgMVae4qJ366a3U+jACv0+LP1jUPDaDupRX/H2TVydn+d+oRgFLm5zZzQCj0yWU r4yg== 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=K/9kGZGLbBJHvXV9eJoUu119iMextvQTW5E/iUSW6Xw=; b=oEYd9sjBC8zxbUuyWA/TzePF3TIdZVShFYVt6v00u553xWKc3LkHNrkdWpVr3Lvbgp JAPSSXXUqwDZCeL3PawUpPjVdxtlL9piu88wYbkaUMRQehuUxdmP2/MsrqlyYVXMwJRh +HMkMNJ6bNrs3iUSM7p+LhPpWHVJSfOiWngPwyF2jhozGV585LUgTIYf/P8fj447nygA Yj9NIyFsnTe8L9dw7mZonrpf9C3Hq0+nj1ZawCM7ycZWEos+VoKkqvuRHRcaJ5qmsjwx gGuVJcP75wo4TT7UnZ/v51BNokXwFI2z5S7JR6IRAw+c1d1KLVkGVW/ilvJ6shNAn+q1 gDZQ== X-Gm-Message-State: AHPjjUg+jmnfZoOt8/en5ioZ8jEgy67luNlhiHSI5t5qRjqjiH36tShO X33G0xvEmP8nudmssfgQ4A== X-Google-Smtp-Source: AOwi7QClWVf6SG2zHNXc0drJ5J6xa49AJlEGtBlhOxnNRdfoT8hqRj6Lya1f84d9UQJY3KAitCU/lQ== X-Received: by 10.55.139.65 with SMTP id n62mr17304900qkd.94.1505698439701; Sun, 17 Sep 2017 18:33:59 -0700 (PDT) Received: from cavall.w50.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id b27sm4483537qtc.78.2017.09.17.18.33.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Sep 2017 18:33:58 -0700 (PDT) From: Ted Lemon Message-Id: <49FEE67A-747A-447B-840C-675E2EE23101@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E868C0CD-B3F6-4F12-B9B8-00A7381A9171" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 17 Sep 2017 21:33:54 -0400 In-Reply-To: <1505698131.2041914.1109222872.6A22DCE0@webmail.messagingengine.com> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <01CCF1A2-A709-412C-90F7-6DAC3A71AD39@oracle.com> <1505698131.2041914.1109222872.6A22DCE0@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages 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, 18 Sep 2017 01:34:03 -0000 --Apple-Mail=_E868C0CD-B3F6-4F12-B9B8-00A7381A9171 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 17, 2017, at 9:28 PM, Neil Jenkins = wrote: > The "special-case"ness of this annoys me slightly, but the = functionality is useful. How does this look to people: = https://github.com/jmapio/jmap/pull/145? = LGTM! --Apple-Mail=_E868C0CD-B3F6-4F12-B9B8-00A7381A9171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Sep 17, 2017, at 9:28 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:
The = "special-case"ness of this annoys me slightly, but the functionality is = useful. How does this look to people: https://github.com/jmapio/jmap/pull/145?

LGTM!


= --Apple-Mail=_E868C0CD-B3F6-4F12-B9B8-00A7381A9171-- From nobody Sun Sep 17 21:37: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 1DBB2132A89 for ; Sun, 17 Sep 2017 21:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=Tkq8VsFy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o+Qqm5Xu 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 pix45hrViFlm for ; Sun, 17 Sep 2017 21:37:18 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C3D126B7E for ; Sun, 17 Sep 2017 21:37:18 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id A469420C2B for ; Mon, 18 Sep 2017 00:37:17 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 18 Sep 2017 00:37:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=1nYYajcqy6bKGcOYzDg7fgKe32lif/TMF8tAVH7hb 5E=; b=Tkq8VsFyoOBpYUGWQEI1w4hq+9hvAgtCCmzrwb7hs2XzoprDa4w8ra6jO Bon3LIJ1pxMVZvI+ZqIrnWmGWHTRYybTVNidnZV96M/wfrk6/y5PhJGoN4SU4P+K 7W7rVjXRgGIcbzOfGCnbeM4LXh9WhMNBdPAPvO+ftTIzY28E5QoD659G3mijraWs TApCLL78R8fKqTOnguwJ1R02y8pNBjCd5NdkrmNFdaQdZXczN9fazXVpsHucmV1l LSB+uRYCqfz61M9B98aPRt6HcHYJe0m+E57ovzLH+WSs1CdGhdgQU/wmO11whWa3 4kDab6qoWksE9eTQnKct8yeuj2ntQ== 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=1nYYajcqy6bKGcOYzDg7fgKe32lif /TMF8tAVH7hb5E=; b=o+Qqm5Xud+59HEniii/mHWZqGo0+FcHvll3lSQy5bMvmX +MzCnAExIXNEwhn4ajJm1vAKlpk9E1fQ0ATPS1ZJTV6h+Nm48wQ56ub7j0oy1Pfs t8gun66jAN6yvzeyu253Nsr/IM2viF5WLtMg8Fzrfqz9u5RW2AZltEsvVUnANlem HDNuUZ+dMD+26qxJZZxAwQsVWVj/x1F8Td3GPKZAM2ac+DHEkoa1DKGe/1ykcAWr i1d77HqTyilI5nc/TtooAoaJftgtWHZ8Alz0aEdboZOJKRjswFm8hsdot0ZN1HFr M8kL8y0TUMd5UB9S8K1/YJuLH7bYoos1OfJiLptWA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5EE5AE2244; Mon, 18 Sep 2017 00:37:17 -0400 (EDT) Message-Id: <1505709437.2183546.1109331544.21752C4F@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150570943721835460" X-Mailer: MessagingEngine.com Webmail Interface - ajax-17f53ed8 Date: Mon, 18 Sep 2017 14:37:17 +1000 Archived-At: Subject: [Jmap] Push specification 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, 18 Sep 2017 04:37:20 -0000 This is a multi-part message in MIME format. --_----------=_150570943721835460 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I've got a pull request[1] I'd like to merge this week, addressing the concerns that were raised about the push specification at the previous IETF conference. I think this is just about ready to merge (thanks to Martin Thomson for several rounds of expert review so far), so this is a last call if you want to review this and provide any further feedback on this change. The changes are mostly editorial, to make the spec clearer. More substantive changes are: * Changes to HTTP headers sent with web callback to make it conform with the use of a push endpoint by an Application Server as defined in RFC8030. * Support for encryption of the push data (as per https://tools.ietf.org/html/draft-ietf-webpush-encryption-09, but will be an RFC before JMAP so we'll update the reference when this is done). * Change of method name to set/get URL to match RFC8030 terminology. * Ability to use event-source in long-polling mode by setting a query parameter, and to set a custom ping time (in another query parameter) to help clients detect if buffering proxies mean long- poll mode is required. The only outstanding comment I believe I currently have from Martin is to define when encryption may be omitted. If the push server is controlled by the same entity as the JMAP server then there is clearly no benefit in encrypting the payload (presuming the connection between the client and the push server is itself encrypted anyway). In the case of a 3rd-party push server, is encryption a SHOULD or a MUST? Opinions? Regards, Neil. Links: 1. https://github.com/jmapio/jmap/pull/100 --_----------=_150570943721835460 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I've got a pull request I'd like to merge this week, addressing the concerns that were raised about the push specification at the previous IETF conference. I think this is just about ready to merge (thanks to Martin Thomson for several rounds of expert review so far), so this is a last call if you want to review this and provide any further feedback on this change.

The changes are mostly editorial, to make the spec clearer. More substantive changes are:
  • Changes to HTTP headers sent with web callback to make it conform with the use of a push endpoint by an Application Server as defined in RFC8030.
  • Support for encryption of the push data (as per https://tools.ietf.org/html/draft-ietf-webpush-encryption-09, but will be an RFC before JMAP so we'll update the reference when this is done).
  • Change of method name to set/get URL to match RFC8030 terminology.
  • Ability to use event-source in long-polling mode by setting a query parameter, and to set a custom ping time (in another query parameter) to help clients detect if buffering proxies mean long-poll mode is required.

The only outstanding comment I believe I currently have from Martin is to define when encryption may be omitted. If the push server is controlled by the same entity as the JMAP server then there is clearly no benefit in encrypting the payload (presuming the connection between the client and the push server is itself encrypted anyway). In the case of a 3rd-party push server, is encryption a SHOULD or a MUST? Opinions?

Regards,
Neil.
--_----------=_150570943721835460-- From nobody Sun Sep 17 21:49:42 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 72BB6132025 for ; Sun, 17 Sep 2017 21:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=UDwprlks; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OOMc919R 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 I0gTTCLuZL7Z for ; Sun, 17 Sep 2017 21:49:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A50E126B7E for ; Sun, 17 Sep 2017 21:49:39 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 8519420985 for ; Mon, 18 Sep 2017 00:49:38 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 18 Sep 2017 00:49:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.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=+lduUbOhAB5is0Pvz j5pMFBRhf0K2R+KnDlWaL1utgk=; b=UDwprlksyiWkMVTOdGJ1Hb8vC5j1zwNQy 8zucFDNhoqg/QVYHYB4tPHeHIsbKomiqV45I+n2V+gvmzuhS+BKXS5NhuKN0PBSv D/Q+2zumLJHlHsgIyde4hsMa5EHPqjSugcq+LL80WrubIgfp4P8sWXdOGtgyRpZM /crMHkNnn0pxucVd1aA6Sq/JPYH45Mrg8ZgWh/AmR1ibM96iJWa/+b2RuBG3QBqT 8lrWbPFAqagLRPw4Un8FdDdRyZWxqu6eJ9TnGMOrQ8d1hVXgJ9PyacRazqVJWK6J aMOnhoDe6M3Do1btuXorZ4NsEdr2mp6ycq5m/d09QmUTyAQ2SbsCA== 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=+lduUb OhAB5is0Pvzj5pMFBRhf0K2R+KnDlWaL1utgk=; b=OOMc919RroQjZnRh8lakiS Q8YlGiwIZcZOlWX+ZVDnXMNF7m4I5MKH3YvNus4J0XJP766dYpo56Rol15U/4W8K 4mMOlwTcTMyNlBnjHNRMHNbrT8hiVmIi9qOztDZSYxugICnagaR1dmQsIq4X+GPl lEF6L9kTQPB4KZfPHXgdGjTqUeqfp0Y4LkzY5ZUG+ZIfHXej20rvpIBYO2PyF2QJ 7CUQatBL95j7YLO/qKX3RsLgGuesfYPDEx0DCepPFF6lbq0sl+wP+XOdbkHYfZkO HypvgS/7BuN7MK1/abdVssBvzEr0eA3gLq0inzvwGmSxbDfcrgA3dOxH8xCwabrQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4F1CCE2244; Mon, 18 Sep 2017 00:49:38 -0400 (EDT) Message-Id: <1505710178.2195138.1109350864.506C3C50@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150571017821951380" X-Mailer: MessagingEngine.com Webmail Interface - ajax-17f53ed8 Date: Mon, 18 Sep 2017 14:49:38 +1000 References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <0F44D4FC-52D0-47B2-A412-95B739B8FA85@oracle.com> <1504142657.4136419.1090521048.0D0A3C8E@webmail.messagingengine.com> <2B534D34-C93A-4D04-86B9-0989C97F18AB@oracle.com> <1504161087.242402.1090702816.36084ECD@webmail.messagingengine.com> <1504487662.1436862.1094151112.22E0C8DB@webmail.messagingengine.com> In-Reply-To: <1504487662.1436862.1094151112.22E0C8DB@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] MessageSubmission last call 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, 18 Sep 2017 04:49:40 -0000 This is a multi-part message in MIME format. --_----------=_150571017821951380 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I've updated the spec to say DSNs update the smtpReply and merged this (hurray! thanks everyone!). Any further issues or comments, please raise a new GitHub issue[1]. Cheers, Neil. Links: 1. https://tools.ietf.org/html/draft-ietf-webpush-encryption-09 --_----------=_150571017821951380 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I've updated the spec to say DSNs update the smtpReply and merged this (hurray! thanks everyone!). Any further issues or comments, please raise a new GitHub issue.

Cheers,
Neil.
--_----------=_150571017821951380--