From nobody Mon Nov 5 15:30:38 2018 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 3FDB9128D09 for ; Mon, 5 Nov 2018 15:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oALxjOdBxVOP for ; Mon, 5 Nov 2018 15:30:35 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 52DCF128CE4 for ; Mon, 5 Nov 2018 15:30:35 -0800 (PST) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id C5B2E2B3C91 for ; Tue, 6 Nov 2018 01:30:30 +0200 (EET) To: IETF JMAP Mailing List From: Stephan Bosch Message-ID: Date: Tue, 6 Nov 2018 00:30:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Jmap] Review of draft-ietf-jmap-core-09 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 23:30:37 -0000 Hi, Here are some of the comments and suggestions I collected while reading draft-ietf-jmap-core-09. Much of it is editorial, but there are some substantive comments as well. I have no more comments beyond these and I like how my previous comments were processed. However, I am mostly a protocol guy in this case, and I don't have much experience with the actual implementation of (IMAP) storage, mail thread handling, indexing, caching, state handling, searching, sorting etc. So, such concerns will not be covered well by my reviews. As before, text from the document itself is pasted here as-is. My comments are prefixed with "-> ". I am not sure I'll be able to provide a final review of mail-09 as well before the meeting, nor am I sure I can attend the meeting in the first place (remotely). Regards, Stephan. ## Section 2: -> The description of the *state* field could use reference to Section 3.3. ## Section 3.2, 3.3: -> The descriptions of the *createdIds* field can use a reference to Section 5.8. ## Section 3.3: -> The description of the sessionState field can use a reference to Section 2. ## Section 3.5.2: -> The "accountNotSupportedByMethod" error seems backward; the method is not supported by the account ## Section 4: -> Is it really useful to have a completely random (and arbitrarily complex) content for the echo request that the server must return? Why not just a single string field? ## Section 5.1: The following additional error may be returned instead of the _Foo/ get_ response: "requestTooLarge": The number of _ids_ requested by the client exceeds the maximum number the server is willing to process in a single method call. -> What if the _ids_ field is actually a back reference to something that yields a lot of ids (i.e. more than the limit)? This is pretty much the complicated example in Section 3.6. Is there some means to limit the number of results from the back reference (or specify an offset, to get results in multiple requests)? Or should the client then (somehow) use a /query instead? That could be difficult for this example. Or am I just making this more complicated than it needs to be? ## Section 5.3: Some record objects may hold references to others (foreign keys). When records are created or modified, they may reference other records being created _in the same API request_ by using the creation id prefixed with a "#".  The order of the method calls in the request by the client MUST be such that the record being referenced is created in the same or an earlier call. -> This can use an explicit reference to Section 3.2/3.3. ## Section 5.5, 5.6: -> Why do these methods echo back certain (potentially quite complex) fields back to the client? ## Section 7.2: -> The TypeState object could use a reference to the previous section. Any other "4xx" or "5xx" response code MUST be considered a *permanent failure* and the push subscription SHOULD be destroyed. -> How would a client get to know about this? Could a useful error message somehow be retrieved by the client? ## Section 7.3: Refer to the JMAP Session resource section of this spec for details on how to get the URL for the event-source resource. -> This could use an explicit section reference From nobody Mon Nov 5 23:45:53 2018 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 C55A1127133 for ; Mon, 5 Nov 2018 23:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=nGgweluv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r9LXtN/a 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 EiKC3im9oO2x for ; Mon, 5 Nov 2018 23:45:49 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3B812007C for ; Mon, 5 Nov 2018 23:45:49 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2CBFE22362; Tue, 6 Nov 2018 02:45:48 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 06 Nov 2018 02:45:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=3AcoDGNbd7vDTJwd22Vsv5MlKht9 n3LplyduV6y97+w=; b=nGgweluvsBmrM7AwvVyngcyumsqXHjYXg7NkX3cKkwWs 0t37Dmmdog/x29VzuwVwXd3ScL8TNxxQK18HPb+pqz58gyjdmFYkUBsYdmcd/1M+ 9C6KokNZURmrQVD354IuB9YV78pdeyLCjID53fvt0wswNfYBkLCAHENUDw0z7V3O uti0efegweVcIaCC5C47xg9xHSaI+CVdQmaeWVAAeLT9jKJqGOq8TStP31r/bcqN nTwvGL7Uc2elL2SgnOqSU4f4XYex3UnUnGPyOQXgjqrGei4JDGI3OPJBLmz2TatS dHn039wgXI2f8Jy6n2KCtl3nbDKc16AkW4UcPjYsGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3AcoDGNbd7vDTJwd2 2Vsv5MlKht9n3LplyduV6y97+w=; b=r9LXtN/aahwfO9J8cR5fuBb0u2TaHAGJ0 BM1/Z8DFoM4emHOCEJk8oV6SsHKAxn/lYG31NLvbIFSh72LsFvZxVqu+x51RbPfZ dotC8ppnbJD/G6uWLOY/e8+r9CM6yZhV4od/9EkGlVCL6YOt83vKlkwbWb6iDOxy 2/a0W55coasvoOC3x1ZR0kz4GWDeyY2y08smS9p1evd53BJtdjKzUlQtzlSXyPNG ZLbtgPWmYiSd13lMuGSW/mxLRfJuRGdTX2oQZ0x/KopRJy311x47q8cIGH5tStQm MIFuV1N3xDpSHi2z+VUPTpZjh0Bi69bq7RlW+wnxa4KFpYzIE6yqA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5CC8020207; Tue, 6 Nov 2018 02:45:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <7c4695e1-8c82-46d7-924b-58e3946120ea@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 In-Reply-To: References: Date: Tue, 06 Nov 2018 02:45:46 -0500 From: "Neil Jenkins" To: "Stephan Bosch" , "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=82c07a0ba0d14d86953a83c4fe8ab6b0 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-09 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 07:45:51 -0000 --82c07a0ba0d14d86953a83c4fe8ab6b0 Content-Type: text/plain Thanks for the further review Stephan. > -> The description of the *state* field could use reference to Section 3.3. > -> The descriptions of the *createdIds* field can use a reference to > Section 5.8. > -> The description of the sessionState field can use a reference to > Section 2. All sounds reasonable, done. > -> The "accountNotSupportedByMethod" error seems backward; the method is not > supported by the account Yeh, I guess it's a bit more the other way. The advantage of the current construction is all those errors beginning with "account" look similar, and probably mean a similar thing in the end (your account data is out-of-date, otherwise you wouldn't have made this request). I'm happy to change, but don't see a great need to. > -> Is it really useful to have a completely random (and arbitrarily complex) > content for the echo request that the server must return? Why not just a > single string field? I don't know about useful but I actually think echoing back the whole arguments object is simpler. Presumably you will have parsed the JSON into some representation using some standard library; you then just put this representation straight into the output. If anything, forcing it to have a single string argument would be more complex as you'd have to then add code for checking that the object structure matched this rather than just passing it through. > -> What if the _ids_ field is actually a back reference to something > that yields a lot of ids (i.e. more than the limit)? Then this would be rejected by the server; as the spec states, the back reference is just a syntactical substitution, the method is then processed as normal. > Is there some means to limit the number of results from > the back reference (or specify an offset, to get results in multiple > requests)? Presuming your back reference is to a query you give a limit on the number of results to return at a time. When fetching the messages that belong to a thread via a back reference, yes, you don't know exactly how many results there will be. But from our service I can tell you that for most users the mean number of messages in a thread is slightly over 1, so you are unlikely to run into this in practice, and even if you do (for example opening some mailing list archives might do it), the client should handle the error and re-request in smaller batches. The previous method call (to get the threads and the list of message ids in the threads) will still have succeeded, so the client has all the information it needs to then request the messages themselves in smaller chunks in further requests. > ## Section 5.3: > -> This can use an explicit reference to Section 3.2/3.3. Added. > ## Section 5.5, 5.6: > -> Why do these methods echo back certain (potentially quite complex) fields > back to the client? The original idea was that it gave you the full information on what the query results were for. But you're right, the client already has this information from the request so it's a waste of bandwidth to send them back again. I've removed the sort/filter/upToId arguments from the responses to these methods. I've kept oldQueryState (which mirrors /changes oldState) because it's small and it's very useful when looking at the network traffic to be able to see these together to see which states the response is taking you from and to. > ## Section 7.2: > -> The TypeState object could use a reference to the previous section. Added. > Any other "4xx" or "5xx" response code MUST be considered a *permanent > failure* and the push subscription SHOULD be destroyed. > -> How would a client get to know about this? Could a useful error message > somehow be retrieved by the client? The only way they can know is to check the push subscriptions and see that they don't have one. I guess we could instead introduce an error state to the PushSubscription object, although I'm not sure exactly what we would want to pass back or how useful it would be to the client. We could pass the HTTP error code? And maybe the response text? Probably don't want to pass back the whole body (we don't even know what media type the body is going to be for an error). We'd probably still want the server to be able to remove subscriptions if they are left in the error state for a while. Do people think this would be worthwhile? > ## Section 7.3: > -> This could use an explicit section reference Added. I also read through both of the specs myself yesterday and fixed a number of nits. I will publish new drafts today incorporating those changes and the fixes for your comments. Cheers, Neil. --82c07a0ba0d14d86953a83c4fe8ab6b0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks for the = further review Stephan.

-> The description of the *state* field= could use reference to Section 3.3.
-> The description= s of the *createdIds* field can use a reference to
Section= 5.8.
-> The description of the sessionState field can = use a reference to 
Section 2.
=

All sounds reasonable, done.

-> The "accoun= tNotSupportedByMethod" error seems backward; the method is not
=
supported by the account

= Yeh, I guess it's a bit more the other way. The advantage of the current= construction is all those errors beginning with "account" look similar,= and probably mean a similar thing in the end (your account data is out-= of-date, otherwise you wouldn't have made this request). I'm happy to ch= ange, but don't see a great need to.

-> Is it really useful to = have a completely random (and arbitrarily complex)
content= for the echo request that the server must return? Why not just a <= br>
single string field?

=
I don't know about useful but I actually think echoing back the who= le arguments object is simpler. Presumably you will have parsed the JSON= into some representation using some standard library; you then just put= this representation straight into the output. If anything, forcing it t= o have a single string argument would be more complex as you'd have to t= hen add code for checking that the object structure matched this rather = than just passing it through.

-> What if the _ids_ field is actu= ally a back reference to something 
that yields a lot= of ids (i.e. more than the limit)?

Then this would be rejected by the server; as the spec states, the= back reference is just a syntactical substitution, the method is then p= rocessed as normal.

Is there some means to limit the number of&nb= sp;results from
the back reference (or specify an offset, = to get results in multiple 
requests)?

Presuming your back reference is to a query = you give a limit on the number of results to return at a time. When fetc= hing the messages that belong to a thread via a back reference, yes, you= don't know exactly how many results there will be. But from our service= I can tell you that for most users the mean number of messages in a thr= ead is slightly over 1, so you are unlikely to run into this in practice= , and even if you do (for example opening some mailing list archives mig= ht do it), the client should handle the error and re-request in smaller = batches. The previous method call (to get the threads and the list of me= ssage ids in the threads) will still have succeeded, so the client has a= ll the information it needs to then request the messages themselves in s= maller chunks in further requests.

## Section 5.3:
-= > This can use an explicit reference to Section 3.2/3.3.

Added.

## Section 5.5, 5.6:
-> Why do these methods echo back certain (potentially quite co= mplex) fields
back to the client?

The original idea was that it gave you the full inform= ation on what the query results were for. But you're right, the client a= lready has this information from the request so it's a waste of bandwidt= h to send them back again. I've removed the sort/filter/upToId arguments= from the responses to these methods. I've kept oldQueryState (which mir= rors /changes oldState) because it's small and it's very useful when loo= king at the network traffic to be able to see these together to see whic= h states the response is taking you from and to.

## Section 7.2:
-> The TypeState object could use a reference to the pre= vious section.

Added.

An= y other "4xx" or "5xx" response code MUST be considered a *permanent&nbs= p;
failure* and the push subscription SHOULD be destroyed.=
-> How would a client get to know about this? Could a = useful error message
somehow be retrieved by the client?

The only way they can know is t= o check the push subscriptions and see that they don't have one. I guess= we could instead introduce an error state to the PushSubscription objec= t, although I'm not sure exactly what we would want to pass back or how = useful it would be to the client. We could pass the HTTP error code? And= maybe the response text? Probably don't want to pass back the whole bod= y (we don't even know what media type the body is going to be for an err= or). We'd probably still want the server to be able to remove subscripti= ons if they are left in the error state for a while.

<= /div>
Do people think this would be worthwhile?

<= /div>
## Section 7.= 3:
-> This could use an explicit section reference
<= /div>

Added.

I also read through both of the specs myself yesterday and fixed a num= ber of nits. I will publish new drafts today incorporating those changes= and the fixes for your comments.

Cheers,
Neil.
--82c07a0ba0d14d86953a83c4fe8ab6b0-- From nobody Tue Nov 6 01:32:37 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33347130DFF; Tue, 6 Nov 2018 01:32:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154149674917.30729.14639730720689830554@ietfa.amsl.com> Date: Tue, 06 Nov 2018 01:32:29 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-10.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:32:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSON Meta Application Protocol Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-core-10.txt Pages : 70 Date : 2018-11-06 Abstract: This document specifies a protocol for clients to access JSON-based data objects efficiently, with support for push and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-10 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 6 01:33:53 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F6C128A5C; Tue, 6 Nov 2018 01:33:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154149682720.30762.2538650685353260412@ietfa.amsl.com> Date: Tue, 06 Nov 2018 01:33:47 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-10.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:33:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Mail Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-mail-10.txt Pages : 88 Date : 2018-11-06 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-10 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 6 01:36:37 2018 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 332BB130DC5 for ; Tue, 6 Nov 2018 01:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=AjPYA9od; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=szB/fngV 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 KzNx7D4DaaEi for ; Tue, 6 Nov 2018 01:36:32 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395F3130F34 for ; Tue, 6 Nov 2018 01:36:32 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 54109222AE for ; Tue, 6 Nov 2018 04:36:31 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 06 Nov 2018 04:36:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=0sJypHozB0hpOPdDWq6IFX/TB5hOXeyOrffrZQ3 ll00=; b=AjPYA9odRvkjTeKdDroXINScLY5q6Cznmy8N8W36zXvAafCu9MDFnnZ yNaeQXiuC8KVSRkj5NpZFj1QBHa/+Kj+DE+DX3lQ1vC5+Z6bwYGi7Ckg0Fh50Nfe lYTyXhwoeV4Qet8340JKhPsQA070O3YToSSfNu2kq35qnc/fzfeX60fPde4vjvzS YYP25yYCzvftUoP7fgV1Jz/Zbb655DXeKRSQKoQkbDN+DapUFN8q/leDfsXzKrzA uLan1T0zxWBwFLQraT4/4VuPxlbE/murhP3elKHNFBuwj9ceVqRM1rXiBDUpDhtm ByP0vql30cNjCNXQWcer9VfYUmCS1UA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=0sJypHozB0hpOPdDWq6IFX/TB5hOXeyOrffrZQ3ll00=; b=szB/fngV umaBqgrjYjqNP6W3RnSKsmdrHuZXq9bmEOec2XO3344AwCf7/bWA9gNRso3h4EG7 fzsf6GN0rrhZeEWLmgQQ3XvuYfiFgR9H9tlW2MTFKsEEu89PpQDqUQ89wK5JzRZ0 ADIl3siK7IQ2QdHEjc4/4htkBM27+P1g0VrOqNw8Ui+Db4g+UiRQ5Oitv3il5NhI O8jLNwW4wjKlM5VBgWJo8by5nf9LFNH9HbQn2YRpgPp1m47zIyz3G5hPhs1IvdMB 4oKy7ByYWSxBulgVliSgYfaDH7RGBjewoEZr/hCT4L/+4etqC9htJ339zZNfTxWn uibChA6PyhYLPQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D3C1420207; Tue, 6 Nov 2018 04:36:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <8ed8392b-9bcc-48ca-85c0-937423216b51@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Tue, 06 Nov 2018 04:36:30 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=fcbbfc5bc99441229dabcbfdfb663a30 Archived-At: Subject: [Jmap] Proposed new charter X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:36:35 -0000 --fcbbfc5bc99441229dabcbfdfb663a30 Content-Type: text/plain Here's a first draft at the text. I've kept bits of the existing charter, chopped out a lot of the stuff which was just constraints on the -mail work, since that one is basically done, and kept it fairly open ended about which extensions can be accepted so long as the group agrees that the work is in scope for either email or related things which would plausibly be part of a client which also does email. I've put the master copy in git at: https://github.com/jmapio/jmap/blob/master/charter.txt Please give feedback here, or at the session tomorrow at IETF103. I will speak to the charter there and expect to do at least one round of discussion and edits before submitting this. Cheers, Bron --- A number of JSON-based email access protocols have been developed that are proprietary, non-standard, and incompatible with each other. These protocols are proliferating due to existing standards being insufficient or poorly suited to the environments they are operating in, particularly mobile and webmail. The use of multiple protocols to perform actions within a single application creates significant support challenges, as users may get a variety of partial failure modes (for example, can receive email but cannot send new messages). This is further exacerbated if the different protocols are authenticated separately. JMAP specifies the interactions between email clients and mail stores, providing an alternative to IMAP and SMTP submission. The JMAP working group will specify a mechanism to allow clients to both view and send email from a server over a single HTTPS channel with minimal round trips. A single protocol for receipt and submission will resolve long- standing difficulties users face setting up clients to talk to servers. The protocol will support push notification of changes using the mechanism defined in RFC 8030. This will give mobile clients benefits in terms of battery life and network usage. It will also support push notifications via server-sent events (https://www.w3.org/TR/eventsource/) for direct connection to clients that can support persistent TCP connections. Once draft-ietf-jmap-core and draft-ietf-jmap-mail have been completed, taking into account the value to client software of having a single authentication method and single endpoint for all its interactions with a server, the working group will work on other extension for related data types, including (but not limited to) calendars, contacts and files. Other extensions may be created to allow for access to advanced features provided by some mail servers, for example any additional parts of SIEVE, IMAP, SMTP submission, as well as for transport of JMAP over different protocols than https. Work on JMAP extensions will be bound by the following constraints: 1) The work of this group is limited to developing a protocol for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 2) Object models will use existing IETF work where possible, for example the JSCalendar work being done in the CALEXT working group will for the basis for jmap-calendar. 3) JMAP Extensions will be built following the core principles: 3.1) The server will not be required to perform work not explicitly requested by the client, and the default SHOULD always be the mode which requires the least server work. 3.2) The client can discover limits enforced by the server on any resources or request complexity. 3.3) Where side effects generated by the server are optional, the protocol will default to no side effects, and the client must explicitly request that those side effects happen (for example: sending a calendar invitation or reply when updating an event) The working group will deliver the following: - a specification based on JSCalendar for JMAP access to calendars - a specification for JMAP access to contacts, either defining a new JSON format for contacts, or working with another working group on developing the format first. - a specification for JMAP access to a filesystem tree which can be integrated with the jmap-core upload mechanism. - other extensions which the working group considers related to email and compatible with the constraints listed above. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --fcbbfc5bc99441229dabcbfdfb663a30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Here's a first draft at the text.  I've kept bits of = the existing charter, chopped out a lot of the stuff which was just cons= traints on the -mail work, since that one is basically done, and kept it= fairly open ended about which extensions can be accepted so long as the= group agrees that the work is in scope for either email or related thin= gs which would plausibly be part of a client which also does email.
<= /div>

=
Please give feedback here, o= r at the session tomorrow at IETF103.  I will speak to the charter = there and expect to do at least one round of discussion and edits before= submitting this.

<= div style=3D"font-family:Arial;">Cheers,

Bron

---

A number of JSON-base= d email access protocols have been developed that
are proprietary, non-standard, and incompatible wit= h each other. These
protocols= are proliferating due to existing standards being insufficient
or poorly suited to the environments = they are operating in, particularly
mobile and webmail.
The use of multiple protocols = to perform actions within a single
application creates significant support challenges, as users may g= et a
variety of partial failu= re modes (for example, can receive email but
cannot send new messages). This is further exacerbated i= f the different
protocols are= authenticated separately.
JMAP specifies the interaction= s between email clients and mail stores,
providing an alternative to IMAP and SMTP submission. The JM= AP working
group will specify= a mechanism to allow clients to both view and send
email from a server over a single HTTPS channel wit= h minimal round
trips. A sing= le protocol for receipt and submission will resolve long-
standing difficulties users face setting up= clients to talk to servers.
=
The protocol will support pu= sh notification of changes using the
mechanism defined in RFC 8030. This will give mobile clients ben= efits in
terms of battery lif= e and network usage. It will also support push
notifications via server-sent events
(https://www.w3.org/TR/eventsource/) for direct connection to clien= ts
that can support persisten= t TCP connections.

=
Once draft-ietf-jmap-core and draft-ie= tf-jmap-mail have been completed,
taking into account the value to client software of having a single=
authentication method and si= ngle endpoint for all its interactions with
a server, the working group will work on other extension = for related data
types, inclu= ding (but not limited to) calendars, contacts and files.

= Other extensions may be created to allow for access to advanced features=
provided by some mail server= s, for example any additional parts of SIEVE,
IMAP, SMTP submission, as well as for transport of JMAP= over different
protocols tha= n https.

Work on JMAP extensions will be bound by the fol= lowing constraints:

1) The work of this group is limited = to developing a protocol for a
   client synchronising data with a server. Any server-to-se= rver issues
   are = out of scope for this working group.

2) Object models wil= l use existing IETF work where possible, for
   example the JSCalendar work being done in t= he CALEXT working group
 = ;  will for the basis for jmap-calendar.

3) JMAP Ext= ensions will be built following the core principles:

&nbs= p; 3.1) The server will not be required to perform work not explicitly
     =   requested by the client, and the default SHOULD always be the
=
     &n= bsp; mode which requires the least server work.

  3.= 2) The client can discover limits enforced by the server on any
       = resources or request complexity.

  3.3) Where side e= ffects generated by the server are optional, the
       protocol will d= efault to no side effects, and the client must
       explicitly reques= t that those side effects happen (for example:
       sending a calenda= r invitation or reply when updating an event)

The working= group will deliver the following:

- a specification base= d on JSCalendar for JMAP access to calendars

- a specific= ation for JMAP access to contacts, either defining a new
   JSON format for contacts, or wo= rking with another working group on
   developing the format first.

- a spec= ification for JMAP access to a filesystem tree which can be
   integrated with the jmap-cor= e upload mechanism.

- other extensions which the working = group considers related to email
   and compatible with the constraints listed above.


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


--fcbbfc5bc99441229dabcbfdfb663a30-- From nobody Tue Nov 6 01:39:38 2018 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 A3005130E39 for ; Tue, 6 Nov 2018 01:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=QI8dlNg8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KqsN/RKE 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 gP4C8V4Ktono for ; Tue, 6 Nov 2018 01:39:35 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4799A130DFF for ; Tue, 6 Nov 2018 01:39:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 50DE621E5A for ; Tue, 6 Nov 2018 04:39:33 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 06 Nov 2018 04:39:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=PwccviFVCrEJW9Z6zVwEDGjoIZrBbDbhveBr70o GzXs=; b=QI8dlNg87iVg2UmtC1xhF6lu5eebHgrTNxyXBb8Qncw6pwdnuZgOZHN YQHdiU0+QWvylru9yfQsQ863ZShsG0fzjQxkz1FTnfhbStS0eUveBQjrKTJ9wFcO dgNN4fevuRAkG2hA3ZM9oPzMvj1H9mQMFVt5pzTzES96jgBIKOo6t4+EN30/cIRV h1Q3Ws98VtC+dfuMHpgD40c0Wa+tAnV2R9ZdGTXNvC2745wvbVKGlnpe5yUuYM97 t0SJsCSeVRuEz5IarcLLh/zIkLiougcLHwgPGI8IKE3+m1U6ITu3WBGT+0KVcpxX QL5gPOpsnDZAh/68QSL0sFUVww190HQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=PwccviFVCrEJW9Z6zVwEDGjoIZrBbDbhveBr70oGzXs=; b=KqsN/RKE ksACS0WT4krndwbZU+kQkcjXXGzAbShcuOIIwPxNZIWZcl/E5KLNIHqXMA3YWk9Y 0HW10cFPCeWl8hG5LTr4q5Vp4w5gp2Rv9BXHGDr45/OOwqRCeq3ohfodLX/qefB9 1A5W+Ns0q2Qap3lybpcUTgGpi4/OKl336lmu3VJS4ITcnk+zigB5BAesscHhGeXm 7BW1geXTqZHtJcTAAfo/heh9HW9TFFlalYfXKikavO/kh8NS7b6LeBJzVMMQKAKS +tP5e3hvznnJQA/p5QaGJAbQJ0Mm1cX/Uy5tCaTrlNRyqhJv80EPE1ITH9zg7DqG RVjCNN0/l/zwKQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 09DFE20207; Tue, 6 Nov 2018 04:39:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <74e10916-d598-4537-91c2-6c0d1fcfde66@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 Date: Tue, 06 Nov 2018 04:39:32 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=dee73dcdbea145eab96d8064b911158e Archived-At: Subject: [Jmap] New drafts released X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:39:36 -0000 --dee73dcdbea145eab96d8064b911158e Content-Type: text/plain Hello all, I've just published rev 10 drafts for core/mail. There's a lot of minor changes to fix grammatical errors, spelling mistakes, JSON syntax errors etc. to get it all into a solid final shape. It also includes the changes made in response to Stephan's review. I know it's the day before the JMAP session here at IETF 103, but if you've read 09 you're really still up to date on all the substantive changes. Cheers, Neil. --dee73dcdbea145eab96d8064b911158e Content-Type: text/html
Hello all,

I've just published rev 10 drafts for core/mail. There's a lot of minor changes to fix grammatical errors, spelling mistakes, JSON syntax errors etc. to get it all into a solid final shape. It also includes the changes made in response to Stephan's review. I know it's the day before the JMAP session here at IETF 103, but if you've read 09 you're really still up to date on all the substantive changes.

Cheers,
Neil.
--dee73dcdbea145eab96d8064b911158e-- From nobody Tue Nov 6 07:45:45 2018 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 171DA12D7F8 for ; Tue, 6 Nov 2018 07:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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=smtpcorp.com header.b=DV9tN/RG; dkim=pass (2048-bit key) header.d=linagora.com header.b=JNDs8co9 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 QpdHPKKfeaMw for ; Tue, 6 Nov 2018 07:45:39 -0800 (PST) Received: from e2i64.smtp2go.com (e2i64.smtp2go.com [103.2.140.64]) (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 79358128BCC for ; Tue, 6 Nov 2018 07:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a1-4; h=Feedback-ID:X-Smtpcorp-Track:Date:Message-ID: Subject:To:Reply-To:Sender:From:List-Unsubscribe; bh=b1vFLz4g/8xmrXvtCXZ/uAeqB00pkc3CYN4g/SA8cpw=; b=DV9tN/RGg2n3nI/+z+JwBp4jHD K3RgVfhTQfJ9OvwYWJdIA4z8EC49zBx8NttoUvWGnl3AQcH3FitX6DxwmCJ7ivQVV1tlxM5ppv34Q nq1aJZR/Ov1YNsGzyU3FZf0x70K/XtWmBYGtlpGMu7RfSsHfwwMxCpNKzbw6U1RunTeaPpaU6Xyls GbqFahFfiE5Ob3Nda6e5CSzkU7JSwebN/nenHD9ZCOSiyi/CyJXBw0yyebntgFw3rpMxfmSh8JJK8 cqflfHgUZjJKfNmAI61Iw5AExIUZEl4gNMCHlbmad2Y2M1/W9vw11Ha2onszKxrPKk2nKIruKfO4S KfO2ZBTg==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linagora.com; i=@linagora.com; q=dns/txt; s=s266739; t=1541519139; h=from : subject : to : message-id : date; bh=b1vFLz4g/8xmrXvtCXZ/uAeqB00pkc3CYN4g/SA8cpw=; b=JNDs8co9rBWPDID7MhAW7opPAoh/ErqTbUWMoTA8pD4RNyZArkWy4zL4fwc/XfPBjj31tG kVG0Im15IdcE9TbJgiFIzLA/xWhh4fS/yfX7ytSdxyqDdpvjgXEd0UKTTIcCalZV/QkkLuK7 qJCRm1XsN5Dz4TEhP5NDhvmo3Zw8QDV0e4fu9/DvgE30+zW4bY9VIfsK9XwBaEwsmIle7NNk qkUAiHqr1TRo6O2liBkFtGKhRlji/fXXC6kxiGkWV+vduumo3pyEtM9LII0TgtGngXrv+ZhO 9oJPPlwTATb+7kiGpqaWel/8tLndaLCd29yFPsH/As7qyweo5gSN+0Ug== Received: from [10.45.79.71] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1gK3Xm-cp4RJT-5P; Tue, 06 Nov 2018 15:45:30 +0000 Received: from [10.54.36.8] (helo=smtp.linagora.com) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1gK3Xj-Duuf3L-Ul; Tue, 06 Nov 2018 15:45:28 +0000 Received: from linagora.com (openpaas-prod.linagora.dc2 [172.24.64.40]) by smtp.linagora.com (Postfix) with ESMTP id 08144409B7; Tue, 6 Nov 2018 16:45:25 +0100 (CET) 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: IETF JMAP Mailing List , Neil Jenkins Message-ID: Date: Tue, 6 Nov 2018 15:45:24 +0000 References: X-Smtpcorp-Track: 1gK3bMDIIf3Ll_.4QcVLjjK9 Feedback-ID: 266739m:266739aja3LFS:266739sQP6PVcWaF X-Report-Abuse: Please forward a copy of this message, including all headers, to Archived-At: Subject: Re: [Jmap] Reminder: last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 15:45:44 -0000

That's a bit of a late remark but I think it would be blocking for our u= se of JMAP @Linagora=2E=2E=2E

As far as I remember the way to handle = mailbox sharing (Bob gets Alice the right to see his mailbox "teamwo= rk-with-alice") is to let Alice execute requests using Bob account id=2E

The JMAP client has to pass 2 distinct JMAP method calls (potentially i= n the same request) then aggregate the results=2E

Then the client ca= n not rely on the server for relevance/ordering of items (and offset/limits= as well)=2E

To get back to our concrete exemple, we do currently exe= cute Email/search on all accessible emails and display (server) aggregat= ed results in a unified infinite list, regardless of which mailbox the = message is in (shared or not)=2E I fear that, when switching to an *acco= unt implementation of sharing*, we won't be able to propose such a unif= ied view=2E

Any thoughts regarding this issue?

Cheers,

= Benoit Tellier

On Oct 23, 2018 16:18, from neilj@fastmailteam=2Eco= m
<= div>Hi all,

Just a reminder that we're in last= call for the JMAP core + mail specs; I've just uploaded new revisions with= some minor changes based on the feedback so far=2E With IETF103 less than = 2 weeks away, now would be a great time to do your final review so we can d= iscuss any outstanding items at the meeting before the last call closes on = 16th November=2E

Latest spec links again:
<= /div>


Cheers,
Neil=2E=
From nobody Tue Nov 6 09:03:26 2018 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 2CA7812F1A5 for ; Tue, 6 Nov 2018 09:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 KN-z0t7SwBs7 for ; Tue, 6 Nov 2018 09:03:23 -0800 (PST) Received: from st13p97im-ztdg18291001.me.com (st13p97im-ztdg18291001.me.com [17.41.193.146]) (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 E097E12D4EB for ; Tue, 6 Nov 2018 09:03:22 -0800 (PST) Received: from process-dkim-sign-daemon.st13p97im-ztdg18291001.me.com by st13p97im-ztdg18291001.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PHS001006WJ7400@st13p97im-ztdg18291001.me.com> for jmap@ietf.org; Tue, 06 Nov 2018 17:03:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1541523801; bh=XzdjndVbNjMDnPctWbdOW2ff9oVNu5bMa8qG0n8pvdc=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=pTeZV1Yql0OCRfHBTDqmFNvZ28ltNy90t9VWf7tOY2ymFY0udU/Dvi4yLz1mkdQY2 rYzEDNdzX3av4LrDwT6cMMxs4K5bKgoUcYf7/5m9rJa5mTBcUsVi4BEsA3e+8D0Eq5 geMoULVbQrz28cUm8h4Ym5L3cibWJq5C4xHecJ4Wpnmb9MPQgF9755kkRAqZKRiLMq y91YZJiJ013CCLUryMvtFFF+PGqtqbrBJt3uc+grv5yow6lJ0ws6zlS9+OeO50wkjd RhBvWut5zP0BzrI6hxK+EHQTvHhN7J8BnP+12/yvza+J2XCE+LybgVTBtqHSlxkzik Kln0laaxx7b7g== Received: from icloud.com ([127.0.0.1]) by st13p97im-ztdg18291001.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PHS00KB67DJKD40@st13p97im-ztdg18291001.me.com>; Tue, 06 Nov 2018 17:03:21 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-06_07:,, signatures=0 From: Sudi Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_D782787B-404E-4733-B250-B4935F240DA8" MIME-version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 06 Nov 2018 09:03:17 -0800 In-reply-to: <8ed8392b-9bcc-48ca-85c0-937423216b51@sloti7d1t02> Cc: jmap@ietf.org To: Bron Gondwana References: <8ed8392b-9bcc-48ca-85c0-937423216b51@sloti7d1t02> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Jmap] Proposed new charter X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 17:03:25 -0000 --Apple-Mail=_D782787B-404E-4733-B250-B4935F240DA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Per a previous conversation with the group, I=E2=80=99ve learnt to see = JMAP (JSON Meta Application Protocol) as a generic protocol; and JMAP = Mail, JMAP Contacts, JMAP Calendar, etc as specific implementations for = said applications. Would it be possible to distinguish JMAP vs JMAP XXX in the writeup = below? It seems to imply JMAP as equivalent to JMAP Mail. For example: > JMAP specifies the interactions between email clients and mail stores, = providing an alternative to IMAP and SMTP submission.=20 -Sudi=20 > On Nov 6, 2018, at 1:36 AM, Bron Gondwana = wrote: >=20 > Here's a first draft at the text. I've kept bits of the existing = charter, chopped out a lot of the stuff which was just constraints on = the -mail work, since that one is basically done, and kept it fairly = open ended about which extensions can be accepted so long as the group = agrees that the work is in scope for either email or related things = which would plausibly be part of a client which also does email. >=20 > I've put the master copy in git at: = https://github.com/jmapio/jmap/blob/master/charter.txt = >=20 > Please give feedback here, or at the session tomorrow at IETF103. I = will speak to the charter there and expect to do at least one round of = discussion and edits before submitting this. >=20 > Cheers, >=20 > Bron >=20 > --- >=20 > A number of JSON-based email access protocols have been developed that > are proprietary, non-standard, and incompatible with each other. These > protocols are proliferating due to existing standards being = insufficient > or poorly suited to the environments they are operating in, = particularly > mobile and webmail. >=20 > The use of multiple protocols to perform actions within a single > application creates significant support challenges, as users may get a > variety of partial failure modes (for example, can receive email but > cannot send new messages). This is further exacerbated if the = different > protocols are authenticated separately. >=20 > JMAP specifies the interactions between email clients and mail stores, > providing an alternative to IMAP and SMTP submission. The JMAP working > group will specify a mechanism to allow clients to both view and send > email from a server over a single HTTPS channel with minimal round > trips. A single protocol for receipt and submission will resolve long- > standing difficulties users face setting up clients to talk to = servers. >=20 > The protocol will support push notification of changes using the > mechanism defined in RFC 8030. This will give mobile clients benefits = in > terms of battery life and network usage. It will also support push > notifications via server-sent events > (https://www.w3.org/TR/eventsource/ = ) for direct connection to clients > that can support persistent TCP connections. >=20 > Once draft-ietf-jmap-core and draft-ietf-jmap-mail have been = completed, > taking into account the value to client software of having a single > authentication method and single endpoint for all its interactions = with > a server, the working group will work on other extension for related = data > types, including (but not limited to) calendars, contacts and files. >=20 > Other extensions may be created to allow for access to advanced = features > provided by some mail servers, for example any additional parts of = SIEVE, > IMAP, SMTP submission, as well as for transport of JMAP over different > protocols than https. >=20 > Work on JMAP extensions will be bound by the following constraints: >=20 > 1) The work of this group is limited to developing a protocol for a > client synchronising data with a server. Any server-to-server = issues > are out of scope for this working group. >=20 > 2) Object models will use existing IETF work where possible, for > example the JSCalendar work being done in the CALEXT working group > will for the basis for jmap-calendar. >=20 > 3) JMAP Extensions will be built following the core principles: >=20 > 3.1) The server will not be required to perform work not explicitly > requested by the client, and the default SHOULD always be the > mode which requires the least server work. >=20 > 3.2) The client can discover limits enforced by the server on any > resources or request complexity. >=20 > 3.3) Where side effects generated by the server are optional, the > protocol will default to no side effects, and the client must > explicitly request that those side effects happen (for example: > sending a calendar invitation or reply when updating an event) >=20 > The working group will deliver the following: >=20 > - a specification based on JSCalendar for JMAP access to calendars >=20 > - a specification for JMAP access to contacts, either defining a new > JSON format for contacts, or working with another working group on > developing the format first. >=20 > - a specification for JMAP access to a filesystem tree which can be > integrated with the jmap-core upload mechanism. >=20 > - other extensions which the working group considers related to email > and compatible with the constraints listed above. >=20 >=20 > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com >=20 >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap = --Apple-Mail=_D782787B-404E-4733-B250-B4935F240DA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Per a previous conversation with the group, I=E2=80=99ve = learnt to see JMAP (JSON Meta Application Protocol) as a generic = protocol; and JMAP Mail, JMAP Contacts, JMAP Calendar, etc as specific = implementations for said applications.

Would it be possible to distinguish = JMAP vs JMAP XXX in the writeup below? It seems to imply JMAP as = equivalent to JMAP Mail.  For example:

JMAP specifies the = interactions between email clients and mail stores, providing an = alternative to IMAP and SMTP = submission. 

-Sudi 



On Nov = 6, 2018, at 1:36 AM, Bron Gondwana <brong@fastmailteam.com> wrote:

Here's a first = draft at the text.  I've kept bits of the existing charter, chopped = out a lot of the stuff which was just constraints on the -mail work, = since that one is basically done, and kept it fairly open ended about = which extensions can be accepted so long as the group agrees that the = work is in scope for either email or related things which would = plausibly be part of a client which also does email.

I've put the master copy in git = at: https://github.com/jmapio/jmap/blob/master/charter.txt

Please give feedback here, or at = the session tomorrow at IETF103.  I will speak to the charter there = and expect to do at least one round of discussion and edits before = submitting this.

Cheers,

Bron

---

A number of JSON-based email = access protocols have been developed that
are proprietary, = non-standard, and incompatible with each other. These
protocols are proliferating due to existing standards = being insufficient
or poorly suited to the = environments they are operating in, particularly
mobile and = webmail.

The use of = multiple protocols to perform actions within a single
application creates significant support challenges, = as users may get a
variety of partial failure modes = (for example, can receive email but
cannot send new = messages). This is further exacerbated if the different
protocols are authenticated separately.

JMAP specifies the interactions = between email clients and mail stores,
providing an = alternative to IMAP and SMTP submission. The JMAP working
group will specify a mechanism to allow clients to = both view and send
email from a server over a single = HTTPS channel with minimal round
trips. A single = protocol for receipt and submission will resolve long-
standing difficulties users face setting up clients = to talk to servers.

The protocol will = support push notification of changes using the
mechanism defined = in RFC 8030. This will give mobile clients benefits in
terms of battery life and network usage. It will also = support push
notifications via server-sent = events
(https://www.w3.org/TR/eventsource/) for direct connection = to clients
that can support persistent TCP = connections.

Once = draft-ietf-jmap-core and draft-ietf-jmap-mail have been completed,
taking into account the value to client software of = having a single
authentication method and single = endpoint for all its interactions with
a server, the = working group will work on other extension for related data
types, including (but not limited to) calendars, = contacts and files.

Other extensions = may be created to allow for access to advanced features
provided by some mail servers, for example any = additional parts of SIEVE,
IMAP, SMTP submission, as well as = for transport of JMAP over different
protocols than = https.

Work on JMAP = extensions will be bound by the following constraints:

1) The work of this group is = limited to developing a protocol for a
   = client synchronising data with a server. Any server-to-server issues
   are out of scope for this working = group.

2) Object models = will use existing IETF work where possible, for
   = example the JSCalendar work being done in the CALEXT working group
   will for the basis for jmap-calendar.

3) JMAP Extensions will be built = following the core principles:

  3.1) The server will not be required to = perform work not explicitly
      = requested by the client, and the default SHOULD always be the
       mode which = requires the least server work.

  3.2) The client can discover limits enforced = by the server on any
      = resources or request complexity.

  3.3) Where side effects generated by the = server are optional, the
      = protocol will default to no side effects, and the client must
       explicitly = request that those side effects happen (for example:
       sending a = calendar invitation or reply when updating an event)

The working group will deliver the = following:

- a specification = based on JSCalendar for JMAP access to calendars

- a specification for JMAP access to contacts, either = defining a new
   JSON format for = contacts, or working with another working group on
   developing the format first.

- a specification for JMAP access = to a filesystem tree which can be
   = integrated with the jmap-core upload mechanism.

- other extensions which the working group considers = related to email
   and compatible with = the constraints listed above.


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


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

= --Apple-Mail=_D782787B-404E-4733-B250-B4935F240DA8-- From nobody Tue Nov 6 20:37:20 2018 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 DADE91277D2 for ; Tue, 6 Nov 2018 20:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=zlSlJHQB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BaxThlz+ 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 xZHEk0T4Wt7l for ; Tue, 6 Nov 2018 20:37:16 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA63127148 for ; Tue, 6 Nov 2018 20:37:16 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 99DFB21FED; Tue, 6 Nov 2018 23:37:15 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 06 Nov 2018 23:37:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=yp8yvt1nV+2vmqeAYRV/gSZq4syk 29Wy9gIL1U3+efI=; b=zlSlJHQBOzF4iLuoZ99VGkT601q9aq88N1lpGUctEktK FX3Aar8a3D6VNN2o8XGMBRoxLtZpHXo5peTmm/TiF4NynB9ZxuC3cj+lMPNA50vR 7VpvVRrosOuYvZUTxTsvwr+qSvrAXRSRuZkKbNHOeplAvkikiUI8IJH8V0dZdZJu hOicTy70Kpz8h/kkh1pHg5ujwQXVIgSkEVUyTi6MSE98hu+fE5X+lqA98PA8j/sS 3TFXZ1BuALbXA98VLA5oPNmSStqXG/PyBOWn5lt7yjTFHJWGDZp/AxNqCpWIhv28 G5ju5XYkyBKIAOJZKKmBduCy6y2uxEI/WLbVLd0YVg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=yp8yvt1nV+2vmqeAY RV/gSZq4syk29Wy9gIL1U3+efI=; b=BaxThlz+n/ueqM+n7iM98X4tR69eTisoI 0wqrUVZJKkpn6l41RWcmYLPVSiZ9btq7I5WY3ijxl1pBGq1OnIZuhOHEsoN8xZIE aRt7SeGrlxB0Agugjv6MBHYBfxmE0IatzE9BXhxfr8Ra2JxEoQoAQwICkpsSLbHV ol5bKugQWEpR3hmMOE0hBHelttEBR1RgvWAuVj9CiMBfjziouAW/FjOh4i8DldRn mTCEt25ifDtVa28LPtgjVXSaeB8KDCGTkYAXmeuUKtJ6j5xnRTEENt00tz2xvXp9 kgWYj0x7f7qormVxdhmiTCW78DsU39QYxtH+72/WEf+kTWTHI5h5g== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 00E6B2030A; Tue, 6 Nov 2018 23:37:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 In-Reply-To: References: Date: Tue, 06 Nov 2018 23:37:14 -0500 From: "Neil Jenkins" To: =?UTF-8?Q?Beno=C3=AEt_Tellier?= , "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=a4a867d863ce4783a0b38c5196839963 Archived-At: Subject: Re: [Jmap] Reminder: last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 04:37:19 -0000 --a4a867d863ce4783a0b38c5196839963 Content-Type: text/plain An account in JMAP is an isolation guarantee. For example, threading happens just for messages within an account, ids need be unique only within an account, state strings are for the set of records within an account etc. This is important for scalability. Being able to shard accounts easily lets you scale to very large numbers of users across a distributed system much more easily. So, I think for your use-case there are two options: 1. If Bob and Alice are always going to be part of the same "team", you could make the JMAP account encompass the whole team. Essentially, you would use a single shared account for the team, with each user having different permissions to view a different subset of items within it. This works, although you might have a few weird things like giving different mailboxes the inbox/sent etc. role depending on the user viewing the account. 2. (This is probably the better option). We define an extension for server aggregation of Email/query across multiple accounts. It would return a list of { accountId, emailId } tuples rather than a list of email ids. Some more thought would be required if we wanted to make back-references work to fetch the email objects in the same request. (Option 3 is of course to just aggregate in the client: you can interleave the results of Email/query to various accounts. But I'm presuming this is not an option for you for some reason.) I'll propose we add this to the agenda for the meeting this afternoon during the agenda bash at the beginning. :) Cheers, Neil. --a4a867d863ce4783a0b38c5196839963 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
An account= in JMAP is an isolation guarantee. For example, threading happens just = for messages within an account, ids need be unique only within an accoun= t, state strings are for the set of records within an account etc.

This is important for scalability. Being able to= shard accounts easily lets you scale to very large numbers of users acr= oss a distributed system much more easily.

= So, I think for your use-case there are two options:

<= /div>
1. If Bob and Alice are always going to be part of the same "t= eam", you could make the JMAP account encompass the whole team. Essentia= lly, you would use a single shared account for the team, with each user = having different permissions to view a different subset of items within = it. This works, although you might have a few weird things like giving d= ifferent mailboxes the inbox/sent etc. role depending on the user viewin= g the account.

2. (This is probably the bet= ter option). We define an extension for server aggregation of Email/quer= y across multiple accounts. It would return a list of { accountId, email= Id } tuples rather than a list of email ids. Some more thought would be = required if we wanted to make back-references work to fetch the email ob= jects in the same request.

(Option 3 is of = course to just aggregate in the client: you can interleave the results o= f Email/query to various accounts. But I'm presuming this is not an opti= on for you for some reason.)

I'll propose we ad= d this to the agenda for the meeting this afternoon during the agenda ba= sh at the beginning. :)

Cheers,
Neil.
--a4a867d863ce4783a0b38c5196839963-- From nobody Tue Nov 6 22:37:20 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C055130E16 for ; Tue, 6 Nov 2018 22:37:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154157263830.30831.2478889689897810262.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2018 22:37:18 -0800 From: IETF Secretariat Archived-At: Subject: [Jmap] Milestones changed for jmap WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 06:37:18 -0000 Changed milestone "Submit document describing generic protocol and data structures (Standards Track)", resolved as "Done". Changed milestone "Submit document describing mail data model and protocol (Standards Track)", resolved as "Done". URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Tue Nov 6 22:38:24 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7267A130DEA for ; Tue, 6 Nov 2018 22:38:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154157270246.30758.11079609572307039739.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2018 22:38:22 -0800 From: IETF Secretariat Archived-At: Subject: [Jmap] Milestones changed for jmap WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 06:38:23 -0000 Changed milestone "Submit detailed problem statement, if desired by the WG (Informational)", resolved as "Unwanted". URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Tue Nov 6 23:21:09 2018 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 518B112D4F2 for ; Tue, 6 Nov 2018 23:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 FFq_isfAKFgr for ; Tue, 6 Nov 2018 23:21:07 -0800 (PST) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com [209.85.166.172]) (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 283D2127333 for ; Tue, 6 Nov 2018 23:21:07 -0800 (PST) Received: by mail-it1-f172.google.com with SMTP id d6so21559306itl.4 for ; Tue, 06 Nov 2018 23:21:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QrW2K8/OoB91fvHrA/mERoAqNzPC13XPg+xBcnyVA4o=; b=qLAIXsMGriWUlm6fiKzJqSox4VKT7SMh8JXL0MHMsfPIA35MPPwuFVzoDomfldBezN bdSDF7GYv4dheIbGIcnQOuZPcsBIB4Hb4V8FRTmsmXCZ16us4wSACdJU7PORU//F+fcR 8aYBMyotvLQWfL6BtEmHiEgegawXwsF5Qkn3IoGJxb9aYJGa4HQDEtL+0eyD6jXyrTcb dg6hADxvRHd3bFiIC4UbNZl6NUkqAsxm0iWDSJDesDj4oOEcwBXu6rUiw3qJ/k+Ij6uB RF0s5wU/ZcuJ7wLM9b8RKrxPd/+2e4k5JAdGAOJ9VF5hheRBC8KZeVkuZ+j+lSv2iYZi Jpcg== X-Gm-Message-State: AGRZ1gLYKRByqvlWDGZjGbL3GGydUFZmnpNK18P5i4zpi93zybn1Le2w VrOs8H/leZe0TsJcbnqrsqDYGgWlg20T05sfZU2wPaoZ X-Google-Smtp-Source: AJdET5diA7GZ7pKRr8myU3JmOYiRdBRe8nHYPb8NJiuHlzMua9vZSgjnfCspO+XcH3Iu86mL9Q4ap8cxXCcvKByy+0w= X-Received: by 2002:a02:56d3:: with SMTP id u80-v6mr619389jad.88.1541575265558; Tue, 06 Nov 2018 23:21:05 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Wed, 7 Nov 2018 14:20:54 +0700 Message-ID: To: jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Jmap] draft-murchison-jmap-websocket as a JMAP working product X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 07:21:08 -0000 In the JMAP session at IETF 103, we have just had no objections to accepting the subject document. Are there any objections here on the mailing list? Please voice objections by 16 November; if we hear none, the chairs will approve draft-ietf-jmap-websocket-00 for posting. Barry From nobody Tue Nov 6 23:35:47 2018 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 B7F58130E61 for ; Tue, 6 Nov 2018 23:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_QUOTING=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 t7iHeEEdDbXE for ; Tue, 6 Nov 2018 23:35:41 -0800 (PST) Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687BC128D68 for ; Tue, 6 Nov 2018 23:35:40 -0800 (PST) Received: by mail-ed1-f44.google.com with SMTP id w25so6705707edx.6 for ; Tue, 06 Nov 2018 23:35:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cmhzPcCXPAjLn96e/fXbrmqlrgW/JYESVUneCcYY1D8=; b=Umn0tzqItKYylxpkz+M/izet1wCE/Ta02O5RW6t4nueZlCz+3gdI6a4ztu1/PL31RZ NpCrNgXDj/sKrPMNE3RVENNaONne4lQoUa/25C3IBC82UVKnTBmBYmrVJ7YocbEi2as0 hjAAMlnCVse62zZms+dRnJ+gDhON9I+6QvIiuUi0gDHplYwOEawGQnBHtfQ5UrRkslyz oY0wgO78ppvbeCiE73haQ2iOl7zv5o/W5MHp2kdILCvcb9lO6ZuRRfvTxWyzTS+orUaN miPKAPIybsJaZxG7y5LnuKcuh6AGYAaIT6o4St1Ev7syC6EQTFqV8J/fes+ejnEoGJ1k K1GA== X-Gm-Message-State: AGRZ1gIWB59b8AjrYyF/GfTHM6TkeAvbYcQrZYCWXNb05S3R/orLYzQH hFOVkRdujfedLCooYiyn36+C68D3WnYcqb1DcwfIO985i9g= X-Google-Smtp-Source: AJdET5fFUu9sGE9F1q+TeL97aHH7EAbioJ9xxQLE4VGvf+nzquPeOQl901HsOOVczZceEir0Odf+tKxHrrYugpFGfdM= X-Received: by 2002:a17:906:2d4a:: with SMTP id e10-v6mr939995eji.105.1541576138460; Tue, 06 Nov 2018 23:35:38 -0800 (PST) MIME-Version: 1.0 References: <74eab43a-6bed-ea06-14d6-a43a37503d87@isode.com> In-Reply-To: <74eab43a-6bed-ea06-14d6-a43a37503d87@isode.com> From: Barry Leiba Date: Wed, 7 Nov 2018 14:35:26 +0700 Message-ID: To: Alexey Melnikov Cc: IETF JMAP Mailing List Content-Type: multipart/mixed; boundary="00000000000020af66057a0e2aa9" Archived-At: Subject: Re: [Jmap] Early draft on S/MIME signature verification to JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 07:35:45 -0000 --00000000000020af66057a0e2aa9 Content-Type: text/plain; charset="UTF-8" In the JMAP session at IETF 103, we have just had no objections to accepting the subject document (not posted to the datatracker, but attached again below). Are there any objections here on the mailing list? Please voice objections by 16 November; if we hear none, the chairs will approve draft-ietf-jmap-smime-00 for posting. On Tue, Mar 6, 2018 at 12:12 AM Alexey Melnikov wrote: > > Hi, > > I wrote a very early draft on how a JMAP server can return S/MIME > signature verification status to a JMAP client. I would like to submit > it as a working group document as a concrete proposal to start to a > proper discussion. > > Comments are welcome! > > > Best Regards, > > Alexey > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --00000000000020af66057a0e2aa9 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-jmap-smime-00.txt" Content-Disposition: attachment; filename="draft-ietf-jmap-smime-00.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jo6ukekx0 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBLiBNZWxuaWtvdgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBJc29kZSBMdGQKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCA1LCAyMDE4CkV4cGly ZXM6IFNlcHRlbWJlciA2LCAyMDE4CgoKICAgICAgICAgIEV4dGVuc2lvbnMgdG8gSk1BUCBmb3Ig Uy9NSU1FIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24KICAgICAgICAgICAgICAgICAgICAgICAgZHJh ZnQtaWV0Zi1qbWFwLXNtaW1lLTAwCgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgZXh0ZW5zaW9uIHRvIEpNQVAgZm9yIHJldHVybmluZyBTL01JTUUKICAgc2lnbmF0dXJlIHZl cmlmaWNhdGlvbiBzdGF0dXMuCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0 LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zp c2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtp bmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJ RVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFm dHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0 IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAg bWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3Mu IgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIgNiwgMjAx OC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxOCBJRVRGIFRydXN0IGFu ZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxs IHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzgg YW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRG IERvY3VtZW50cwogICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4g ZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQ bGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3Jp YmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBk b2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11 c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJv dmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UuCgoKCgoKCk1lbG5pa292ICAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDYsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgIEpNQVAgZXh0ZW5zaW9uIGZvciBTL01JTUUgICAgICAgICAgICAgTWFyY2ggMjAxOAoKClRh YmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIENvbnZlbnRpb25zIFVzZWQg aW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDMuICBF eHRlbnNpb24gdG8gZ2V0TWVzc2FnZXMgZm9yIFMvTUlNRSBzaWduYXR1cmUgdmVyaWZpY2F0aW9u ICAuICAgMgogICA0LiAgT3BlbiBJc3N1ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDYuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAog ICA3LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDQKICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CgoxLiAgSW50cm9kdWN0aW9uCgogICBKTUFQ IFtJLUQuaWV0Zi1qbWFwLWNvcmVdIGlzIGEgZ2VuZXJpYyBwcm90b2NvbCBmb3Igc3luY2hyb25p c2luZwogICBkYXRhLCBzdWNoIGFzIG1haWwsIGNhbGVuZGFycyBvciBjb250YWN0cywgYmV0d2Vl biBhIGNsaWVudCBhbmQgYQogICBzZXJ2ZXIuICBJdCBpcyBvcHRpbWlzZWQgZm9yIG1vYmlsZSBh bmQgd2ViIGVudmlyb25tZW50cywgYW5kIGFpbXMgdG8KICAgcHJvdmlkZSBhIGNvbnNpc3RlbnQg aW50ZXJmYWNlIHRvIGRpZmZlcmVudCBkYXRhIHR5cGVzLgogICBbSS1ELmlldGYtam1hcC1tYWls XSBidWlsZHMgb24gdG9wIG9mIEpNQVAgYW5kIGRlZmluZXMgaG93IHRvIHBlcmZvcm0KICAgZW1h aWwgc3luY2hyb25pemF0aW9uLgoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gZXh0ZW5z aW9uIHRvIEpNQVAgTWFpbCBmb3IgcmV0dXJuaW5nCiAgIFMvTUlNRSBbUkZDNTc1MV0gc2lnbmF0 dXJlIHZlcmlmaWNhdGlvbiBzdGF0dXMsIHdpdGhvdXQgcmVxdWlyaW5nIGEKICAgSk1BUCBjbGll bnQgdG8gZG93bmxvYWQgdGhlIHNpZ25hdHVyZSBhbmQgYWxsIHNpZ25lZCBib2R5IHBhcnRzLgoK Mi4gIENvbnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudAoKICAgVGhlIGtleSB3b3JkcyAi TVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05B TCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFtSRkMyMTE5XS4KCjMuICBFeHRlbnNpb24gdG8gZ2V0TWVzc2FnZXMgZm9yIFMvTUlNRSBz aWduYXR1cmUgdmVyaWZpY2F0aW9uCgogICBbSS1ELmlldGYtam1hcC1tYWlsXSBkZWZpbmVzIGdl dE1lc3NhZ2VzIG1ldGhvZCBmb3IgcmV0cmlldmluZwogICBtZXNzYWdlIHNwZWNpZmljIGluZm9y bWF0aW9uLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcKICAgcHNldWRvIHZh bHVlcyBpbiB0aGUgX3Byb3BlcnRpZXNfIGFyZ3VtZW50OgogICBvICpzbWltZVN0YXR1cyo6IElm ICIic21pbWVTdGF0dXMiIiBpcyBpbmNsdWRlZCBpbiB0aGUgbGlzdCBvZgogICByZXF1ZXN0ZWQg cHJvcGVydGllcywgaXQgTVVTVCBiZSBpbnRlcnByZXRlZCBieSB0aGUgc2VydmVyIGFzIGEKICAg cmVxdWVzdCB0byByZXR1cm4gIiJzbWltZVN0YXR1cyIiIHByb3BlcnR5LgoKICAgKnNtaW1lU3Rh dHVzKjogIlN0cmluZ3xudWxsIi4gbnVsbCBzaWduaWZpZXMgdGhhdCB0aGUgbWVzc2FnZSBkb2Vz bid0CiAgIGNvbnRhaW4gYW55IHNpZ25hdHVyZS4gIFBvc3NpYmxlIHN0cmluZyB2YWx1ZXMgb2Yg dGhlIHByb3BlcnR5IGFyZQogICBsaXN0ZWQgYmVsb3cuICBTZXJ2ZXJzIE1BWSByZXR1cm4gb3Ro ZXIgdmFsdWVzIG5vdCBkZWZpbmVkIGJlbG93LgogICBDbGllbnQgTVVTVCB0cmVhdCB1bnJlY29n bml6ZWQgdmFsdWVzIGFzICJ1bmtub3duIjoKCiAgICAgIHVua25vd24gLSBTL01JTUUgbWVzc2Fn ZSwgYnV0IGl0IGlzIG5laXRoZXIgc2lnbmVkLCBub3IgZW5jcnlwdGVkLgogICAgICBUaGlzIGNh biBhbHNvIGJlIHJldHVybmVkIGZvciBhIG11bHRpcGFydC9zaWduZWQgbWVzc2FnZSB3aGljaAog ICAgICBjb250YWlucyB1bnJlY29nbml6ZWQgc2lnbmluZyBwcm90b2NvbCAoZm9yIGV4YW1wbGUg T3BlblBHUCkuCgoKCgpNZWxuaWtvdiAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA2 LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBK TUFQIGV4dGVuc2lvbiBmb3IgUy9NSU1FICAgICAgICAgICAgIE1hcmNoIDIwMTgKCgogICAgICBz aWduZWQgLSBTL01JTUUgc2lnbmVkIG1lc3NhZ2UsIGJ1dCB0aGUgc2lnbmF0dXJlIHdhcyBub3Qg eWV0CiAgICAgIHZlcmlmaWVkLiAgU29tZSBzZXJ2ZXJzIG1pZ2h0IG5vdCBhdHRlbXB0IHRvIHZl cmlmeSBzaWduYXR1cmUKICAgICAgdW50aWwgYSBwYXJ0aWN1bGFyIG1lc3NhZ2UgaXMgcmVxdWVz dGVkIGJ5IHRoZSBjbGllbnQuCgogICAgICBzaWduZWQvdmVyaWZpZWQgLSBTL01JTUUgc2lnbmVk IG1lc3NhZ2UgYW5kIHRoZSBzZW5kZXIncyBzaWduYXR1cmUKICAgICAgd2FzIHN1Y2Nlc3NmdWxs eSB2ZXJpZmllZCwgc2VuZGVyIG1hdGNoZXMgdGhlIEZyb20gaGVhZGVyIGZpZWxkCiAgICAgIGFu ZCB0aGUgc2VuZGVyJ3MgY2VydGlmaWNhdGUgKGFuZCB0aGUgY2VydGlmaWNhdGUgY2hhaW4pIGlz CiAgICAgIHRydXN0ZWQgZm9yIHNpZ25pbmcuCgogICAgICBzaWduZWQvZmFpbGVkIC0gUy9NSU1F IHNpZ25lZCBtZXNzYWdlLCBidXQgdGhlIHNpZ25hdHVyZSBmYWlsZWQgdG8KICAgICAgdmVyaWZ5 LiAgVGhpcyBtaWdodCBiZSBhIHBvbGljeSByZWxhdGVkIGRlY2lzaW9uIChtZXNzYWdlIHNpZ25l cgogICAgICBkb2Vzbid0IG1hdGNoIHRoZSBGcm9tIGhlYWRlciBmaWVsZCksIG1lc3NhZ2Ugd2Fz IG1vZGlmaWVkLCBldGMuCgogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgZGVtb25zdHJhdGVzIGEg cmVxdWVzdCBmb3IgUy9NSU1FIHN0YXR1cy4KCgogICAgICBbImdldE1lc3NhZ2VzIiwgewogICAg ICAiaWRzIjogWyAiZjEyM3U5ODciIF0sCiAgICAgICJwcm9wZXJ0aWVzIjogWyAibWFpbGJveElk cyIsICJmcm9tIiwgInN1YmplY3QiLCAiZGF0ZSIsICJzbWltZVN0YXR1cyIgXQogICAgICB9LCAi IzEiXQoKVGhpcyB3aWxsIHJlc3VsdCBpbiB0aGUgZm9sbG93aW5nIHJlc3BvbnNlOgoKICAgICAg WyJtZXNzYWdlcyIsIHsKICAgICAgICAgImFjY291bnRJZCI6ICJhYmMiLAogICAgICAgICAic3Rh dGUiOiAiNDEyMzQxMjMyMzEiLAogICAgICAgICAibGlzdCI6IFsKICAgICAgICAgICB7CiAgICAg ICAgICAgICBpZDogImYxMjN1NDU3IiwKICAgICAgICAgICAgIG1haWxib3hJZHM6IHsgImYxMjMi OiB0cnVlIH0sCiAgICAgICAgICAgICBmcm9tOiBbe25hbWU6ICJKb2UgQmxvZ2dzIiwgZW1haWw6 ICJqb2VAYmxvZ2dzLmNvbSJ9XSwKICAgICAgICAgICAgIHN1YmplY3Q6ICJEaW5uZXIgb24gVGh1 cnNkYXk/IiwKICAgICAgICAgICAgIGRhdGU6ICIyMDEzLTEwLTEzVDE0OjEyOjAwWiIsCiAgICAg ICAgICAgICBzbWltZVN0YXR1czogInNpZ25lZC92ZXJpZmllZCIKICAgICAgICAgICB9CiAgICAg ICAgIF0KICAgICAgfSwgIiMxIl0KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBF eGFtcGxlCgo0LiAgT3BlbiBJc3N1ZXMKCiAgIFtbVGhpcyBzZWN0aW9uIHNob3VsZCBiZSBlbXB0 eSBiZWZvcmUgcHVibGljYXRpb25dXQoKCgoKCgoKCk1lbG5pa292ICAgICAgICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDYsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgIEpNQVAgZXh0ZW5zaW9uIGZvciBTL01JTUUgICAgICAgICAgICAgTWFy Y2ggMjAxOAoKCjUuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUQkQuCgo2LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMKCiAgIFRCRC4KCjcuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0kt RC5pZXRmLWptYXAtY29yZV0KICAgICAgICAgICAgICBKZW5raW5zLCBOLiwgIkpTT04gTWV0YSBB cHBsaWNhdGlvbiBQcm90b2NvbCIsIGRyYWZ0LWlldGYtCiAgICAgICAgICAgICAgam1hcC1jb3Jl LTA0ICh3b3JrIGluIHByb2dyZXNzKSwgTWFyY2ggMjAxOC4KCiAgIFtJLUQuaWV0Zi1qbWFwLW1h aWxdCiAgICAgICAgICAgICAgSmVua2lucywgTi4sICJKTUFQIGZvciBNYWlsIiwgZHJhZnQtaWV0 Zi1qbWFwLW1haWwtMDQKICAgICAgICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDIw MTguCgogICBbUkZDMjA0NV0gIEZyZWVkLCBOLiBhbmQgTi4gQm9yZW5zdGVpbiwgIk11bHRpcHVy cG9zZSBJbnRlcm5ldCBNYWlsCiAgICAgICAgICAgICAgRXh0ZW5zaW9ucyAoTUlNRSkgUGFydCBP bmU6IEZvcm1hdCBvZiBJbnRlcm5ldCBNZXNzYWdlCiAgICAgICAgICAgICAgQm9kaWVzIiwgUkZD IDIwNDUsIERPSSAxMC4xNzQ4Ny9SRkMyMDQ1LCBOb3ZlbWJlciAxOTk2LAogICAgICAgICAgICAg IDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIwNDU+LgoKICAgW1JGQzIxMTld ICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAg ICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAg ICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAogICAgICAgICAgICAgIDxo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgW1JGQzU3NTFdICBS YW1zZGVsbCwgQi4gYW5kIFMuIFR1cm5lciwgIlNlY3VyZS9NdWx0aXB1cnBvc2UgSW50ZXJuZXQK ICAgICAgICAgICAgICBNYWlsIEV4dGVuc2lvbnMgKFMvTUlNRSkgVmVyc2lvbiAzLjIgTWVzc2Fn ZQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBSRkMgNTc1MSwgRE9JIDEwLjE3NDg3L1JG QzU3NTEsIEphbnVhcnkKICAgICAgICAgICAgICAyMDEwLCA8aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmM1NzUxPi4KCkF1dGhvcidzIEFkZHJlc3MKCiAgIEFsZXhleSBNZWxuaWtv dgogICBJc29kZSBMdGQKICAgMTQgQ2FzdGxlIE1ld3MKICAgSGFtcHRvbiwgTWlkZGxlc2V4ICBU VzEyIDJOUAogICBVSwoKICAgRU1haWw6IEFsZXhleS5NZWxuaWtvdkBpc29kZS5jb20KCgoKCgoK CgoKTWVsbmlrb3YgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgNiwgMjAxOCAgICAg ICAgICAgICAgIFtQYWdlIDRdCg== --00000000000020af66057a0e2aa9-- From nobody Wed Nov 7 02:22:13 2018 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 326F112D4E8 for ; Wed, 7 Nov 2018 02:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=QoWBbkn1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jYPGTW/D 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 azBjx457GcO6 for ; Wed, 7 Nov 2018 02:22:08 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D61A129C6B for ; Wed, 7 Nov 2018 02:22:08 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5FF0921FED for ; Wed, 7 Nov 2018 05:22:07 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 07 Nov 2018 05:22:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=s1pT5M1aRrMqmBYbQgx/g/5YbHumGQ4RugD1j4N O7ow=; b=QoWBbkn1tqnNxelQuDmEjir4TUSG7X/4aEkFjVIdBFOY53Vr5VlHOHP 5/s7Q0vo4lyrGQqlB07rFohzK3nmC53BacSYthXyX/rZu0eLpwtCnJVpez1X132j yXg1xoq7KZJxlN0treBGSF+Zptne1RVGPi/NiDbO2PfF+MjEFap7l9vG9NKrIa/Y kzpRpBKTx10pJvuSmZPMiZ8hq/cCDTLYkvVJEOERjBN43kDldjRG+F0zUlqU/kFO jhjMPxKdMV+nCiyCRR47nxBMIUMJJHrdswy0l7VnpHwM3aPHo/ou07iflP7VjgWi akN5l0v9z+fGet26CW0bhLjkJp7t2KA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=s1pT5M1aRrMqmBYbQgx/g/5YbHumGQ4RugD1j4NO7ow=; b=jYPGTW/D ZZkR/bBDrCblI+EOJ7uCd+J01uZCVXLYqaTB4PKemNJ1aWztfNqyuQXnJawo5uCJ NBR+bAxzLY3mvrJtJYpfcDl2EgPcuzUdgx35rRaHgzKr3+tBY96wStr4LCF2z6a5 End9budzsAc4zbbJDi9EAD1GVePUoTPArOdpTLhivCZ24tVZ80ZVszIZbrYV0ezW ileS0plVIJeAHWThpzXdEPEd3W1OjgRqWETliUSojCRGwQECx5q1VIXNfa7tpcK2 wGBj8kdYnUXVlGgKpGYG72OKReyuDo1oZHX0CF+SnP42GOZSn+oRXSnJIXtc5aOZ FP/jgX50CSVlLQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DD11D2030B; Wed, 7 Nov 2018 05:22:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <0b426c0e-b96a-4a07-9c88-9d36c5c08ed3@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Wed, 07 Nov 2018 05:22:06 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=dfb30c948699471682c93cf969f81bcd Archived-At: Subject: [Jmap] Minutes for IETF103 meeting uploaded X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 10:22:10 -0000 --dfb30c948699471682c93cf969f81bcd Content-Type: text/plain As always, please reply here with any corrections/clarifications! Thanks :) Bron. --- MINUTES - JMAP@IETF103 - Bangkok 7-Nov-2018 13:50 Chairs: Barry Leiba and Bron Gondwana Thanks to dkg for jabber scribing and note taking. draft-ietf-jmap-core: * Q: has JMAP core been assessed for suitability outside email, since it's designed as a general transport - A: we're using it at FastMail for calendar, contacts, files, etc already as well as some specialist extensions which aren't mail related. The model works well, and reviewers have been favourable. * Q: what about queries across multiple accounts, should that be addressed in core? - A: let's talk about it later * Expecting minor nits changes based on reviews, but nothing major left, expect to submit for publication at the end of WGLC on Nov 16. draft-ietf-jmap-mail: * No issues raised in the room * Expecting minor nits changes based on reviews, but nothing major left, expect to submit for publication at the end of WGLC on Nov 16. multiple account queries: * Problem statement, want to aggregate sort across multiple "accountId"s, for example - sort by search relevance and all accounts are on the same server so use the same scoring system. * note: this has been requested by a few different client authors who have user requests for a "combined INBOX" or similar. * observation: might be useful inside a single system, but a client which is aggregating mailboxes from multiple external sources is going to have to deal with this regardless, we can't make the whole world into a single namespace! * suggestion: add a fetch property to an object like SearchSnippet which can be used to combine the sorted lists on the client. * suggestion: have the server combine multiple users' email into a single "accountId" (doesn't fix observation above, but might be enough for some use cases) * suggestion: have server produce a combined "/query" result which merges data from multiple accounts into some kind of list of tuples of [accountId emailid] rather than just a list of emailIds. * observation: core and mail specs are already complex enough, this would be much better as an extension rather than part of core/mail proper. ACTION: Benoit from Linagora to write up a proposal for an extension based on their use-case. draft-ietf-jmap-mdn: * Concept has broad support * There are some nits in terms of JMAP-style * Needs to wait on core/mail standards in terms of process through IETF, but may very well land at the same time (cluster!) ACTION: Neil to provide nits to the author for a new draft. draft-murchison-jmap-websocket: * Q: should multiple concurrent requests be allowed? - A: yes! - note: it may be necessary to add an identifier to requests and responses to allow correlating reponses to their requests, since responses could come back out of order. - note: draft already shows JMAP over Websockets over http/2. - note: QUIC can be considered separately/later. * Q: should we support push via the same channel? - A: yes! We will need to tag it to distinguish it from responses * No objections to adoption within the room ACTION: Barry will mail list asking for objections to adoption before Nov 16th. ACTION: Neil will give feedback on questions to Ken (author) for an updated draft. draft-ietf-jmap-smime: * Posted by Alexey to the list, but looks like it wasn't uploaded (can't find it in the datatracker) * suggestion: add an extra property giving the fingerprint or similar for the key that matched * discussion: most UIs only care about "signed/verified" and "unknown", anything not verified should be treated as "no comment"/"unknown". * note: some environments might require everything to be signed. * No objections to adoption within the room ACTION: Barry will mail list asking for objections to adoption before Nov 16th. new extension: quota * Benoit from Linagora proposed a new extension for quota * discussion: complexity with different servers including other things inside quota, not just mail. * note: most MUAs just care about showing a total, and a "you have used X%" of your total. Exactness doesn't matter so much. * matches an IMAP data item, so clearly in scope * no objection from within the room ACTION: Benoit to post a proposal to the mailing list to form the basis for a call for adoption Rechartering discussion: * Based on email thread from yesterday * Q: is the term "extension" overused - e.g. both extending existing specs and adding new data types - suggestion: say "data model" instead. - suggestion: "capability" (but overloaded from IMAP meaning) * note: need to be clear about sequencing, this could open a floodgate of work and don't want to overload group without clear priorities set. * Alexey as AD: don't recharter until existing docs have been through IESG review, it would be a distraction. * warning: there's a danger of introducing circular dependencies if we work on too many related documents at once. * suggestion: limit this recharter to just calendars and contacts, and recharter again once those are done. ACTION: Bron to keep refining text with an eye to rechartering in January. Miletones: * Bron has updated existing milestones, except IMAP/JMAP compatibility document which Alexey was going to work on. * suggestion: leave doc in the milestones, but change the target date to December 2020 to put it behind other work. * this document is less urgent now that the EXTRA working group has added many things to IMAP which will help. * Alexey is happy if someone else wants to take up work on this document. ACTION: Bron to update milestone date There being no other business, the meeting was concluded after roughly 1 hour. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --dfb30c948699471682c93cf969f81bcd Content-Type: text/html Content-Transfer-Encoding: quoted-printable
As always, please reply here with any corrections/clarific= ations!  Thanks :)

<= /div>
Bron.

---

MINUTES - JMAP@IETF103 - Bangkok 7-Nov-2018 13:50

= Chairs: Barry Leiba and Bron Gondwana

Thanks to dkg for j= abber scribing and note taking.

draft-ietf-jmap-core:
=
* Q: has JMAP core been assessed= for suitability outside email, since
  it's designed as a general transport
  - A: we're using it at FastMail for calen= dar, contacts, files, etc already
    as well as some specialist extensions which aren= 't mail related.  The
&n= bsp;   model works well, and reviewers have been favourable.
* Q: what about queries across= multiple accounts, should that be addressed
  in core?
  - A: let's talk about it later
* Expecting minor nits changes based on reviews, but nothing= major left,
  expect to= submit for publication at the end of WGLC on Nov 16.

dra= ft-ietf-jmap-mail:
* No issue= s raised in the room
* Expect= ing minor nits changes based on reviews, but nothing major left,
  expect to submit for publicat= ion at the end of WGLC on Nov 16.

multiple account querie= s:
* Problem statement, want = to aggregate sort across multiple "accountId"s,
  for example - sort by search relevance and all= accounts are on the same
&nb= sp; server so use the same scoring system.
* note: this has been requested by a few different client = authors who
  have user = requests for a "combined INBOX" or similar.
* observation: might be useful inside a single system, bu= t a client which
  is ag= gregating mailboxes from multiple external sources is going to have
<= /div>
  to deal with this regardle= ss, we can't make the whole world into a single
  namespace!
* suggestion: add a fetch property to an object like SearchSnipp= et which
  can be used t= o combine the sorted lists on the client.
* suggestion: have the server combine multiple users' email= into a single
  "accoun= tId" (doesn't fix observation above, but might be enough for some
  use cases)
* suggestion: have server produce a combined "= /query" result which
  m= erges data from multiple accounts into some kind of list of tuples of
  [accountId emailid] rath= er than just a list of emailIds.
* observation: core and mail specs are already complex enough, this = would
  be much better a= s an extension rather than part of core/mail proper.

ACTI= ON: Benoit from Linagora to write up a proposal for an extension
      =   based on their use-case.


draft-ietf-jmap-mdn:
* Concept has broad support
* There are some nits in terms of JMAP-style
* Needs to wait on core/mail standards in term= s of process through
  I= ETF, but may very well land at the same time (cluster!)

A= CTION: Neil to provide nits to the author for a new draft.


draft-murchison-jmap-webso= cket:
* Q: should multiple co= ncurrent requests be allowed?
  - A: yes!
  - no= te: it may be necessary to add an identifier to requests and responses
    to allow co= rrelating reponses to their requests, since responses could
    come back out of order= .
  - note: draft alread= y shows JMAP over Websockets over http/2.
  - note: QUIC can be considered separately/later.
=
* Q: should we support push via = the same channel?
  - A:= yes!  We will need to tag it to distinguish it from responses
<= /div>
* No objections to adoption withi= n the room

ACTION: Barry will mail list asking for object= ions to adoption before
 = ;       Nov 16th.
ACTION: Neil will give feedback on questions to Ken (= author) for an
  &n= bsp;     updated draft.


draft-ietf-jmap-smime:
* Posted by Alexey to the list, but looks like = it wasn't uploaded (can't
&nb= sp; find it in the datatracker)
* suggestion: add an extra property giving the fingerprint or similar= for
  the key that matc= hed
* discussion: most UIs on= ly care about "signed/verified" and "unknown",
  anything not verified should be treated as "no = comment"/"unknown".
* note: s= ome environments might require everything to be signed.
* No objections to adoption within the room

ACTION: Barry will mail list asking for objections to adop= tion before
   = ;     Nov 16th.


new extension: quota
* Benoit from Linagora proposed a new extension for quota
* discussion: complexity with = different servers including other things
  inside quota, not just mail.
* note: most MUAs just care about showing a total, an= d a "you have used X%"
 = of your total.  Exactness doesn't matter so much.
* matches an IMAP data item, so clearly in sc= ope
* no objection from withi= n the room

ACTION: Benoit to post a proposal to the maili= ng list to form the
 &nb= sp;      basis for a call for adoption


Rechartering discussi= on:
* Based on email thread f= rom yesterday
* Q: is the ter= m "extension" overused
 = - e.g. both extending existing specs and adding new data types
  - suggestion: say "data model"= instead.
  - suggestion= : "capability" (but overloaded from IMAP meaning)
* note: need to be clear about sequencing, this cou= ld open a floodgate
  of= work and don't want to overload group without clear priorities set.
=
* Alexey as AD: don't recharter = until existing docs have been through
  IESG review, it would be a distraction.
* warning: there's a danger of introducing ci= rcular dependencies if we
&nb= sp; work on too many related documents at once.
* suggestion: limit this recharter to just calendars = and contacts, and
  rech= arter again once those are done.

ACTION: Bron to keep ref= ining text with an eye to rechartering in January.


Miletones:
* Bron has updated existing milestones, except IMAP/J= MAP compatibility
  docu= ment which Alexey was going to work on.
* suggestion: leave doc in the milestones, but change the tar= get date to
  December 2= 020 to put it behind other work.
* this document is less urgent now that the EXTRA working group has = added
  many things to I= MAP which will help.
* Alexey= is happy if someone else wants to take up work on this document.

ACTION: Bron to update milestone date


=
There being no other business, the mee= ting was concluded after roughly 1 hour.

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


--dfb30c948699471682c93cf969f81bcd-- From nobody Wed Nov 7 18:09:35 2018 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 E3FBD1292F1 for ; Wed, 7 Nov 2018 18:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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=smtpcorp.com header.b=yT3sY9yo; dkim=pass (2048-bit key) header.d=linagora.com header.b=FrGVgV5c 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 er1n8U4OGr-i for ; Wed, 7 Nov 2018 18:09:30 -0800 (PST) Received: from e2i64.smtp2go.com (e2i64.smtp2go.com [103.2.140.64]) (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 17D741277BB for ; Wed, 7 Nov 2018 18:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a1-4; h=Feedback-ID:X-Smtpcorp-Track:Date:Message-ID: Subject:To:Reply-To:Sender:From:List-Unsubscribe; bh=39e/EgulqrCCcWww6YuiD5d14bpOaBWk/5q0fdAwrzI=; b=yT3sY9yoIPyxZ+hgzsmS2LqbZD 4yzRqZeShGHBole4+2yMg2n9s1Rn6ViVPcoD5P8Ut0ka+kBMMhYAHD+mc42pIhDt7jpY7V6KcvUfb oZcsmYZETnP77mvZ5d+LysGj0MO3s1ORGaa8LiBI8Cg3RtNN4r0zS9/Q0EOBLNxclKOfY/yJiGoQu SJFjPSMn6VtCYNr5GneoA0tCvqJAqyR4QSk7qm7OBixjapXrNaiI9QtKGiXxfFnTuLoIuC4bWWevC mGDfqqbYbOWX4EgIedmfATe3+vNuqcI6vJMo6EyuePrKLkUrLvWzvZmV7B6wYUsV0FRlNDM0znxb2 R2qP6zTQ==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linagora.com; i=@linagora.com; q=dns/txt; s=s266739; t=1541642970; h=from : subject : to : message-id : date; bh=39e/EgulqrCCcWww6YuiD5d14bpOaBWk/5q0fdAwrzI=; b=FrGVgV5cBLw9eRP/D00C+PTvTKpTXdOxu867J4zgI9KmqT9DtlVxBGis/rQHq8JIV1aVG3 8UfpURwiEu4uG9vWPK9xX6erz7g1maOxndYyoOjWPJw0YzXTYHO+d7l/aLsqe0C5f1AXAaZp 4zUQ8mhj0vvxCLphsGddMtKKFdPTvreI5bg5OMFpTYh68bGGT/kAJExqwFnzPSLUYmM/jmdY lgIRX/nFyaOqWSGy+gDm0giVL4CKqTNc/BfUj/o+aqBvRvxGT6aSbeJkUp/5d1lVbkfXMO16 8KYsYGAm+xT67YEjzdZLBt1oUE/EwwsBdhLTBP6LxhfftjQexDE+WiTw== Received: from [10.45.33.53] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1gKZl4-cp4Slg-W5; Thu, 08 Nov 2018 02:09:22 +0000 Received: from [10.54.36.8] (helo=smtp.linagora.com) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1gKZl3-rlZG2b-3q; Thu, 08 Nov 2018 02:09:21 +0000 Received: from linagora.com (openpaas-prod.linagora.dc2 [172.24.64.40]) by smtp.linagora.com (Postfix) with ESMTP id 1290B40631; Thu, 8 Nov 2018 03:09:18 +0100 (CET) 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: IETF JMAP Mailing List , Neil Jenkins Message-ID: Date: Thu, 8 Nov 2018 02:09:17 +0000 References: X-Smtpcorp-Track: 1gKZ_3r_ZG2P3q.4yrTt_I8p Feedback-ID: 266739m:266739aja3LFS:266739sQP6PVcWaF X-Report-Abuse: Please forward a copy of this message, including all headers, to Archived-At: Subject: Re: [Jmap] Reminder: last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 02:09:33 -0000

Hi Neil,

I will quickly answer this message, that I did not see b= efore I arrived at IETF-103

On Nov 7, 2018 11:37, from neilj@fastm= ailteam=2Ecom
An account in JMAP is an i= solation guarantee=2E For example, threading happens just for messages with= in an account, ids need be unique only within an account, state strings are= for the set of records within an account etc=2E

This is important for scalability=2E Being able to shard accounts easily= lets you scale to very large numbers of users across a distributed system = much more easily=2E

So, I think for your use-c= ase there are two options:

1=2E If Bob and Ali= ce are always going to be part of the same "team", you could make the JMAP = account encompass the whole team=2E Essentially, you would use a single sha= red account for the team, with each user having different permissions to vi= ew a different subset of items within it=2E This works, although you might = have a few weird things like giving different mailboxes the inbox/sent etc= =2E role depending on the user viewing the account=2E

= This is not doable as there will be name conflicts (both Bob & Alice ha= ve an Inbox mailbox, etc=2E=2E=2E)


2=2E = (This is probably the better option)=2E We define an extension for server a= ggregation of Email/query across multiple accounts=2E It would return a lis= t of { accountId, emailId } tuples rather than a list of email ids=2E Some = more thought would be required if we wanted to make back-references work to= fetch the email objects in the same request=2E

This i= s what was decided during IETF-103=2E

(Option 3 is of c= ourse to just aggregate in the client: you can interleave the results of Em= ail/query to various accounts=2E But I'm presuming this is not an option fo= r you for some reason=2E)

The big issue here is that a= ll notion of relevance/sort order is lost as we represent the results only = as an Id=2E

On complex sorts (like text search relevance) the client= can not infer this easily=2E Thus it can not reliably merge the two sorted= lists of ids into one=2E


I'll propose w= e add this to the agenda for the meeting this afternoon during the agenda b= ash at the beginning=2E :)

Cheers,
Neil=2E


Cheers, Benoit

From nobody Wed Nov 14 21:13:00 2018 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 CC16A1271FF for ; Wed, 14 Nov 2018 21:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KwQipvkY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZIY69HRx 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 5tFSyyht2VzU for ; Wed, 14 Nov 2018 21:12:57 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0317312426A for ; Wed, 14 Nov 2018 21:12:56 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CCCEE21E00 for ; Thu, 15 Nov 2018 00:12:55 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 15 Nov 2018 00:12:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=POxOgDN7AC1Xso9+MwKqxtwkegGyrul8RpnWrvL LjLA=; b=KwQipvkYit09hBlED3M3nZLrTowtIiWy2nkF59FwfPRjfv2+voAwwnV p/VfgisHL00nlU/9tV5y3VqVbtPzZrUOTdGCzMj7lDi8Y+6fFIFpj1qG/nD1zLk3 qb772V1eiUBwSNac1Np4Gg2IDlAkI5SBnEPhPVdYxHJ9AwBYr5MnWFgBAriIsnoZ y3UQdqDfuZW5khkJ2u1faIsCsmIyub+lhYqb2oMQtnWlB6dg2f9lgCk+qeo9WTrU LihVPt1DUkRaxZMQ21b86gEvzl/CKBWSGULlG4lLKXzHmcnWhhSOrUI9CCTNRvhP TcORWe2PiSUeFGzlaVe/yWZJGBHpgwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=POxOgDN7AC1Xso9+MwKqxtwkegGyrul8RpnWrvLLjLA=; b=ZIY69HRx 5hjci4psl8cpf/g3avDisaTlewtJ9iN8Kn/cxT+BneQV69DZXAMNsVnYiTTC1cvc ExM6cKqhbaRO0ZlPc5mhi8rpAA3xK4TjsZcqzwAZcVxeJHHQw2v1/vENXXt9zvR8 30YskIjvzHRJFfgCT7iSTGMQPUg6bsG/QPqI3q8V0+IymtOGaVmyntaJJyUYZQXl TEFB1OHpGPXThC85M0jn243d6KpL3RqFifvf7+wCuecgWGcPRFNzhEeN+nDXisk6 8pa03Zd669QiBK9ccJgo/D6KBKBeTmyNNzDYBAgOQEdMqXZY8JhtP/KaFTUsvxPq NvR/YV8rElHkvA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 280732030C; Thu, 15 Nov 2018 00:12:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <0e63904a-6c4e-42d4-a140-f1ca99bafca3@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 15 Nov 2018 00:12:54 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=d4e7f7878d504ffe8f015cf972f0995b Archived-At: Subject: [Jmap] Review: draft-ietf-jmap-core-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 05:13:00 -0000 --d4e7f7878d504ffe8f015cf972f0995b Content-Type: text/plain Finally... sorry this has taken so long. I actually sat down and did a real read through... *1.2: integer type ranges* I queried the inclusive vs exclusiveness of the ends of the ranges. Neil assured me that 53 bits can be inclusive at both ends while being exact in JSON. (https://github.com/stedolan/jq/issues/143) *1.3 Date types* Fractional seconds are probably going to arrive via Calendar datatypes. I recommend "MUST NOT include time-secfrac if the fractional seconds part is zero". Reword to be less clunky, but that concept. Since mail currently doesn't have fractional seconds, it won't change it, but it will be more forward compatible. *1.6 Ids* Please mention RFC8474 and duplicate or reference the advice on choosing IDs which are filesystem, commandline, spreadsheet, etc-safe. *2. Session resource* *maxCallsInRequest* has a "MUST" of 32. None of the others have limits defined, and that seems quite a large limit for a MUST. I'd be happy to have SHOULD of 32 there, but not force every server to support 32. None of the other fields provide guidelines at all. It would be good to document recommended minimum limits for each of them. *3.2 Request object* Not just here, but in a bunch of places there are arbitrary strings like "client id". These need a max length. Discussion with Neil suggested making them of "Id" type, which is defined as 255 bytes from the safe range of 64 allowed bytes back in 1.6. Likewise "accountId". Thought maybe we will hit issues if people want to use foo@example.com as an accountId and don't want to base64 it... *[ASIDE] I will probably write up a draft called something like draft-gondwana-jmap-errorinjection which adds a Core/error method and/or optional parameters to method calls which allow you to test a client framework by causing a supporting server to throw different errors to otherwise well-formed requests.* * * *5.3 /set* returns: created/updated/destroyed which are either an object with 1+ items or null. Why not just require an empty object consistent with /changes responses? Likewise with the "not$X". Either that or allow omitting them entirely which is the same as the default value of empty/null. *5.4 /copy* For full state mangling consistency, this requires a ifFromInState or similar. So the logic would be: 1. check fromAccountId account Foo state matches ifFromInState (if specified) 2. generate a consistent snapshot of data out of fromAccount 3. check accountId account Foo state matches ifInState (if specified) 4. /import the snapshotted data into accountId. 5. check fromAccountId account Foo state again, this time for matching destroyFromIfInState (I would rename this destroyIfFromInState actually) - (if specified) 6. /set#destroy the source IDs on fromAccountId Obviously, if the state of fromAccount change during the copy, you could wind up with both the source and destination messages present at once, and would have to clean up. Or a server which could do the whole thing atomically could reject the whole request of course, knowing that it couldn't resolve all the states. Presumably ifFromInState and destroyFromIfInState would always be identical, but it still makes sense to allow specifying just one or just the other. *5.5 /query* What happens if you don't give a limit and don't ask for total to be calculated, but the server decides to limit the number of records returned? > If "null", no limit presumed. The server MAY choose to enforce a maximum "limit" argument. In this case, if a greater value is given (or if it is "null"), the limit is clamped to the maximum; since the total number of results in the query is returned, the client can determine if it has received all the results. Since we now support calculateTotal, we need to double check how those two interact. *6. Binary Data* This is probably the most difficult part of the spec as someone used to implementing IMAP. Uploaded blobs are like temporary files. > Except where quota restrictions force early deletion, an unreferenced blob MUST NOT be deleted for at least 1 hour from the time of upload What does that even mean? I'd say that if a blob has been uploaded an ACCEPTED by the server, then it has to be there for an hour (modulo server failures). Otherwise if you upload 10 blobs and then try to use them but 9 have been quotaed out, that would suck. Better to reject the last 9 uploads. Or if that's really going to be a concern, we need a Blob/query to list unreferences blobs and a Blob/set#destroy to remove them. Or at the very least, a Blob/cleanup method which wipes all unreferenced blobs, or maybe just unreferenced blobs, or at least unreferenced blobs created by this session, to clear up space when you get near quota. Also: some advice around access control and blobs would be useful here. For the Files/* methods at FastMail we create blobs in a special folder if you upload them to an account shared with somebody else, such that they have a folder ACL which contains the uploader and the account owner. Likewise we're planning to add similar ACLs to our Cyrus server for mail, such that it's uploader and account owner only that are allowed to add a reference to an referenced blob. I could also see an argument for "only uploader" and the owner only gets to see the blob once the reference gets created. See above for quota considerations though - if the owner's quota is being billed, then the owner needs a way to clear them. 7.2 Push subscriptions > If the response code is "503" (Service Unavailable), the JMAP server MAY try again later, but may also just drop the event. If the response code is "429" (Too Many Requests) the JMAP server SHOULD attempt to reduce the frequency of pushes to that URL. Any other "4xx" or "5xx" response code MUST be considered a *permanent failure* and the push subscription SHOULD be destroyed. I'd like some advice from HTTP people about whether this is the right approach. It feels like it could lead to some pretty flaky feeling push subscription loss for clients in the face of legitimate network reality between different systems. .... And I think that's it! Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --d4e7f7878d504ffe8f015cf972f0995b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Finally... sorry this has taken so long.  I actu= ally sat down and did a real read through...

1.2: inte= ger type ranges

I queried the inclusive vs exclusiven= ess of the ends of the ranges.  Neil assured me that 53 bits can be= inclusive at both ends while being exact in JSON.  (https://github= .com/stedolan/jq/issues/143)
=
1.3 Date types

Fractional seconds are probably going to arrive via Calendar da= tatypes.  I recommend "MUST NOT include time-secfrac if the fractio= nal seconds part is zero".  Reword to be less clunky, but that conc= ept.  Since mail currently doesn't have fractional seconds, it won'= t change it, but it will be more forward compatible.

1= .6 Ids

Please mention RFC8474 and duplicate or refere= nce the advice on choosing IDs which are filesystem, commandline, spread= sheet, etc-safe.

2. Session resource

maxCallsInRequest has a "MUST" of 32.  None of the others = have limits defined, and that seems quite a large limit for a MUST. = ; I'd be happy to have SHOULD of 32 there, but not force every server to= support 32.

None of the other fields provide guidelines = at all.  It would be good to document recommended minimum limits fo= r each of them.

3.2 Request object

= Not just here, but in a bunch of places there are arbitrary strings like= "client id".  These need a max length.  Discussion with Neil = suggested making them of "Id" type, which is defined as 255 bytes from t= he safe range of 64 allowed bytes back in 1.6.

Likewise "= accountId".  Thought maybe we will hit issues if people want to use= foo@example.com as an accountId = and don't want to base64 it...

[ASIDE] I will probably= write up a draft called something like draft-gondwana-jmap-errorinjecti= on which adds a Core/error method and/or optional parameters to method c= alls which allow you to test a client framework by causing a supporting = server to throw different errors to otherwise well-formed requests.<= br>

5.3 /set

returns: created/upd= ated/destroyed which are either an object with 1+ items or null.  W= hy not just require an empty object consistent with /changes responses?&= nbsp; Likewise with the "not$X".  Either that or allow omitting the= m entirely which is the same as the default value of empty/null.

5.4 /copy

=
For full state mangling consiste= ncy, this requires a ifFromInState or similar.  So the logic would = be:

1. check fromAccountId account Foo state matches ifFr= omInState (if specified)
2. g= enerate a consistent snapshot of data out of fromAccount
3. check accountId account Foo state matches= ifInState (if specified)
4. = /import the snapshotted data into accountId.
5. check fromAccountId account Foo state again, this tim= e for matching destroyFromIfInState (I would rename this destroyIfFromIn= State actually) - (if specified)
6. /set#destroy the source IDs on fromAccountId

Obvious= ly, if the state of fromAccount change during the copy, you could wind u= p with both the source and destination messages present at once, and wou= ld have to clean up.  Or a server which could do the whole thing at= omically could reject the whole request of course, knowing that it could= n't resolve all the states.  Presumably ifFromInState and destroyFr= omIfInState would always be identical, but it still makes sense to allow= specifying just one or just the other.

5.5 /query=

What happens if you don't give a limit and don't ask for= total to be calculated, but the server decides to limit the number of r= ecords returned?

If "null", no limit presumed.  The server M=
AY choose to
enforce a maximum "limit" argument.  In this case, if a greater
value is given (or if it is "null"), the limit is clamped to the
maximum; since the total number of results in the query is
returned, the client can determine if it has received all the
results.

Since we now support calculateTota= l, we need to double check how those two interact.

6. B= inary Data

This is probably the most difficult part o= f the spec as someone used to implementing IMAP.  Uploaded blobs ar= e like temporary files.

<= /div>
Except where quota restrictions forc=
e early deletion, an
unreferenced blob MUST NOT be deleted for at least 1 hour from the
time of upload
<= br>
What does that even mean?&nbs= p; I'd say that if a blob has been uploaded an ACCEPTED by the server, t= hen it has to be there for an hour (modulo server failures).  Other= wise if you upload 10 blobs and then try to use them but 9 have been quo= taed out, that would suck.  Better to reject the last 9 uploads.

Or if that's really going to be a concern, we need a Blob/q= uery to list unreferences blobs and a Blob/set#destroy to remove them.

Or at the very least, a Blob/cleanup method which wipes al= l unreferenced blobs, or maybe just unreferenced blobs, or at least unre= ferenced blobs created by this session, to clear up space when you get n= ear quota.

Also: some advice around access control and bl= obs would be useful here.  For the Files/* methods at FastMail we c= reate blobs in a special folder if you upload them to an account shared = with somebody else, such that they have a folder ACL which contains the = uploader and the account owner.  Likewise we're planning to add sim= ilar ACLs to our Cyrus server for mail, such that it's uploader and acco= unt owner only that are allowed to add a reference to an referenced blob= .  I could also see an argument for "only uploader" and the owner o= nly gets to see the blob once the reference gets created.  See abov= e for quota considerations though - if the owner's quota is being billed= , then the owner needs a way to clear them.

7.2 Push subs= criptions

If the response code is "503" (Service Unavailable=
), the JMAP server
MAY try again later, but may also just drop the event.  If the
response code is "429" (Too Many Requests) the JMAP server SHOULD
attempt to reduce the frequency of pushes to that URL.  Any other
"4xx" or "5xx" response code MUST be considered a *permanent failure*
and the push subscription SHOULD be destroyed.

I'd like some advice from HTTP people about whether this is the right= approach.  It feels like it could lead to some pretty flaky feelin= g push subscription loss for clients in the face of legitimate network r= eality between different systems.

....

And= I think that's it!

Bron.

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


--d4e7f7878d504ffe8f015cf972f0995b-- From nobody Wed Nov 14 22:46:04 2018 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 A7407128CFD for ; Wed, 14 Nov 2018 22:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ibsXe77M; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=u++agUqq 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 BgWz0iulhydo for ; Wed, 14 Nov 2018 22:46:00 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCDE127133 for ; Wed, 14 Nov 2018 22:46:00 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 414DC21B84 for ; Thu, 15 Nov 2018 01:45:59 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 15 Nov 2018 01:45:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=to/NRzJLS4mgQJHJ0aWa3xYhD58bw0vk9cq98UH hnUA=; b=ibsXe77M3fAQD0rXv0OgwzpMz7pxYaTaPxIhTaYzlU4hd91c0UiNFnp aCmXRQTPg0lz7694KIg6FJx8WJi6joYxN2tKuA0J3HuVuk3NJ6SpVoNAyoQT5dgO qv1ndo5/QUzxdhU5yYNMrGZ4gij5RgcG7GQHcfbTY7s3iTg/myLPHDUHrM/0FYlj 6Db4dD/G+1j/nkptMLMOzWzdA4mO1f2szqmos5babD24k6+okVXtTEYLBjALl2Du BwKEDFtweRufWhAg8SRgsYxew/Tl46RHz8fteT53NmgfR6YYKhh237AlaRHkZHxC OiB1SDdAvpCxXMeDE74FlJ1cdzPOAmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=to/NRzJLS4mgQJHJ0aWa3xYhD58bw0vk9cq98UHhnUA=; b=u++agUqq kwqcc4FMivj/jajgcxY2b2bfAWU35PnsgyHo71kU5h8mobGGDlVRCOR7vmYq31c+ 9LYGoxnNYu3nQnPHlh/Sv8iRW+ZbbX5hpycdY8UyzQqnRukR5R/9EFy/Ik2qGE68 PEcYYok/znjgJLu6AApv1K2QfqjS4MORzsr0L6QU2cdQTl/sPIbUyKvA+IGrRrZq s6/bwVel4KABj94LXkbLnbKiWL+sv1MxMV1VZn7AKzaI4pJ5P5wxky6opJU4UuQG 5SbU5sfXdLkm0XoBRf0HG7xf6ZOKooGicovSy0IkudoQ3OlR2whSb7vYsMIVT7Na MX9EJUwPb3l4Dw== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B88E02030C; Thu, 15 Nov 2018 01:45:58 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Thu, 15 Nov 2018 01:45:58 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=79b34e34fa4b4fbda527d8692ef99b36 Archived-At: Subject: [Jmap] Review: draft-ietf-jmap-mail-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 06:46:03 -0000 --79b34e34fa4b4fbda527d8692ef99b36 Content-Type: text/plain here's my belated readthrough and comments on jmap-mail. * * *1.3.1 **urn:ietf:params:jmap:mail* maxMailboxDepth - do you mean "one more than the maximum number of ancestors"? Aka, "1" means no tree, all toplevel. > *maxSizeMailboxName*: "PositiveInt" The maximum length, in (UTF-8) octets, allowed for the name of a mailbox. This MUST be >= 255. This might actually be quite hard for some servers. 255 is a long name! I'd recommend a lower minimum of say 100 octets, though recommend that servers allow more. *1.3.2 **urn:ietf:params:jmap:submission** * > By default, the JMAP server should show only known safe- to-expose EHLO capabilities in this field, and hide EHLO capabilities that are only relevant to the JMAP server. What does this actually mean? I find this sentence confusing about relevance. * * *1.5 Push* > In addition, servers MUST support a psuedo-type called "EmailDelivery" in the push mechanisms. The state string for this MUST change whenever a new Email is added to the store, but SHOULD NOT change upon any other change to the Email objects. Is that really something that should be a MUST? I guess it can just be a copy of "Email" if you can't tell if something was a new message. *2. Mailbox* This should probably cross-reference RFC8474 OBJECTID at least as an informative reference. isSubscribed should reference the IMAP property that it's cloning. *3. Mailbox/set* Do we also want an onDestroyRemoveChildren argument to match onDestroyRemoveMessages? *4.1.4 Body parts * {I admit I skim-read over the email format parsing stuff - I've read it before,and it all seems sane}, except maybe: *preview*: see the discussion in extra@ietf.org about IMAP previews and making them consistent. I can see an argument for making the size of this be in characters rather than octets. I do feel strongly that we should make the limits exactly consistent between JMAP and IMAP, since we have that opportunity right now. There also needs to be text here about the flexible immutability of this field. It's derived and the algorithm might change, but the value is still considered "correct" and doesn't need to be updated by the client. * * *4.2 Email/get* > Where a specific header is requested as a property, the capitalization of the property name in the response MUST be identical to that used in the request. Does this mean that a request for "From:asRaw" and "from:asRaw" returns both of them separately? *4.4.1: Filtering* > o *inMailbox*: "String" A mailbox id. An email must be in this mailbox to match the condition. o *inMailboxOtherThan*: "String[]" A list of mailbox ids. An email must be in at least one mailbox not in this list to match the condition. This is to allow messages solely in trash/spam to be easily excluded from a search. Just a reminder to change the "String" here to "Id" per the core changes... > o *header*: "String[]" The array MUST contain either one or two elements. The first element is the name of the header field to match against. The second (optional) element is the text to look for in the header field value. If not supplied, the message matches simply if it _has_ a header field of the given name. This looks like a pain to use because you can only do one per filtercondition, but I guess that's the same as the keyword items above. *4.8. Email/import* > The _Email/import_ method adds [RFC5322] messages to the set of emails in an account. The messages must first be uploaded as files using the standard upload mechanism. It takes the following arguments: I think this should say "must first be uploaded as blobs" to be consistent. Same remember to update mailboxIds type map applies. I'd be tempted to define a type for keywords as well, and have "keywords: Keyword[Boolean]" in the spec just to memoralise that it's a restricted string type. *4.9 Email/parse* Just echoing my comments in the core review about the difference between > o *created*: "String[Email]" A map of the creation id to an object containing the _id_, _blobId_, _threadId_ and _size_ properties for each successfully imported Email. o *notCreated*: "String[SetError]" A map of creation id to a SetError object for each Email that failed to be created. The possible errors are defined above. and > o *parsed*: "String[Email]|null" A map of blob id to parsed Email representation for each successfully parsed blob, or "null" if none. > > o *notParsable*: "String[]|null" A list of ids given that corresponded to blobs that could not be parsed as emails, or "null" if none. If feels like the types of response to different methods and the null vs empty behaviour is inconsistent and weird - they should all be the same, and possibly the lists of ids should all be maps of { id : true } for deletion, etc - just because the ordering doesn't matter, and lists imply ordering. *5. Search snippets* Some language about caching might be required here? Basically immutability along the same lines as preview (expected to remain correct, but bytes might change as implementation is updated) *7. Email submission* Why does this include threadId when you can always get it with a backreferences fetch against emailId? Feels like duplication of data for dubious benefit. I assume it's for hooking submissions into the display for their matching thread, but a backreference lookup on fetch would get you that too. Ahh yeah, handy for filtering I guess... *7.5 EmailSubmission/set* Given that we're updating Emails with side effect subrequests from this, should there be a way to latch this against the Email state? ifInEmailState or something? ... That'll do. Mostly just tiny editorial nits. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --79b34e34fa4b4fbda527d8692ef99b36 Content-Type: text/html Content-Transfer-Encoding: quoted-printable 
here's my belat=
ed readthrough and comments on jmap-mail.

1.3.1= urn:ietf:params:jmap:mail

maxMailboxDepth - do =
you mean "one more than the maximum number of ancestors"?  Aka, "1" mean=
s no tree, all toplevel.

= 
*maxSizeMailboxName*: "PositiveInt"=
 The maximum length, in (UTF-8)
octets, allowed for the name of a mailbox.  This MUST be >=3D 255.

This might actually be quite hard for some ser= vers.  255 is a long name!  I'd recommend a lower minimum of s= ay 100 octets, though recommend that servers allow more.

= 1.3.2 urn:ietf:params:jmap:submission<= /span> 

By default, the JMAP server should show only known safe=
-
to-expose EHLO capabilities in this field, and hide EHLO
capabilities that are only relevant to the JMAP server.

What does this actually mean?  I find this sentence con= fusing about relevance.
1.5 Push
<= div style=3D"font-family:Arial;">
In addition, servers MUST support a psuedo-type called "EmailDelivery" in the push mechanisms. The state string for this MUST change whenever a new Email is added to the store, but SHOULD NOT change upon any other change to the Email objects.

Is that really something that should be a MUST?  I guess= it can just be a copy of "Email" if you can't tell if something was a n= ew message.

2. Mailbox

This should = probably cross-reference RFC8474 OBJECTID at least as an informative ref= erence.

isSubscribed should reference the IMAP property tha= t it's cloning.

3. Mailbox/set

Do w= e also want an onDestroyRemoveChildren argument to match onDestroyRemove= Messages?

4.1.4 Body parts

{I admit I skim-read over the email format par= sing stuff - I've read it before,and it all seems sane}, except maybe:

*preview*: see the discussion in extra@ietf.org about IMAP previews and making them co= nsistent. I can see an argument for making the size of this be in chara= cters rather than octets.  I do feel strongly that we should make t= he limits exactly consistent between JMAP and IMAP, since we have that o= pportunity right now.

There also needs to be text here ab= out the flexible immutability of this field.  It's derived and the = algorithm might change, but the value is still considered "correct" and = doesn't need to be updated by the client.

4.2 E= mail/get

Where a specific header is requested as a prope=
rty, the
capitalization of the property name in the response MUST be identical
to that used in the request.

Does this mean = that a request for "From:asRaw" and "from:asRaw" returns both of them se= parately?

4.4.1: Filtering

   o  *inMa=
ilbox*: "String" A mailbox id.  An email must be in this
      mailbox to match the condition.

   o  *inMailboxOtherThan*: "String[]" A list of mailbox ids.  An email
      must be in at least one mailbox not in this list to match the
      condition.  This is to allow messages solely in trash/spam to be
      easily excluded from a search.

Just a = reminder to change the "String" here to "Id" per the core changes...
= 

   o  *header*: "String[]" The array MUST contain either one or=
 two
      elements.  The first element is the name of the header field to
      match against.  The second (optional) element is the text to look
      for in the header field value.  If not supplied, the message
      matches simply if it _has_ a header field of the given name.

This looks like a pain to use because you can only = do one per filtercondition, but I guess that's the same as the keyword i= tems above.

4.8. Email/import

   The _Em=
ail/import_ method adds [RFC5322] messages to the set of
   emails in an account.  The messages must first be uploaded as files
   using the standard upload mechanism.  It takes the following
   arguments:
I think this should say "must = first be uploaded as blobs" to be consistent.

Same rememb= er to update mailboxIds type map applies. I'd be tempted to define a typ= e for keywords as well, and have "keywords: Keyword[Boolean]" in the spe= c just to memoralise that it's a restricted string type.

= 4.9 Email/parse

Just echoing my comments in the co= re review about the difference between 
   o  *created*: "String[Email]" A map of the creation id to an =
object
      containing the _id_, _blobId_, _threadId_ and _size_ properties
      for each successfully imported Email.
   o  *notCreated*: "String[SetError]" A map of creation id to a
      SetError object for each Email that failed to be created.  The
      possible errors are defined above.

and= 

   o  *parsed*: "String[Email]|null" A map of blob id to par=
sed Email
      representation for each successfully parsed blob, or "null" if
      none.

   o  *notParsable*: "String[]|null" A list of ids given =
that
      corresponded to blobs that could not be parsed as emails, or
      "null" if none.

If feel= s like the types of response to different methods and the null vs empty = behaviour is inconsistent and weird - they should all be the same, and p= ossibly the lists of ids should all be maps of { id : true } for deletio= n, etc - just because the ordering doesn't matter, and lists imply order= ing.

5. Search snippets

Some langua= ge about caching might be required here? Basically immutability along th= e same lines as preview (expected to remain correct, but bytes might cha= nge as implementation is updated)

7. Email submission<= /b>

Why does this include threadId when you can always ge= t it with a backreferences fetch against emailId?  Feels like dupli= cation of data for dubious benefit.  I assume it's for hooking subm= issions into the display for their matching thread, but a backreference = lookup on fetch would get you that too.  Ahh yeah, handy for filter= ing I guess...

7.5 EmailSubmission/set

Given that we're updating Emails with side effect subrequests from t= his, should there be a way to latch this against the Email state? ifInEm= ailState or something?

...

That'll do.&nbs= p;  Mostly just tiny editorial nits.

Bron.
=

--
  Bron Gondwana, CEO, Fa= stMail Pty Ltd
  brong@fastmailte= am.com


--79b34e34fa4b4fbda527d8692ef99b36-- From alh@fastmailteam.com Tue Nov 20 06:14:30 2018 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 A589F1274D0 for ; Tue, 20 Nov 2018 06:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=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=BY+tqeq4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=deoic7Ef 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 5tLhUG_a5wUs for ; Tue, 20 Nov 2018 06:14:27 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6331286E3 for ; Tue, 20 Nov 2018 06:14:27 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9B949C21 for ; Tue, 20 Nov 2018 09:14:26 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Tue, 20 Nov 2018 09:14:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:date:subject; s=fm1; bh= QoOMWzW2a0Rk8GqAbPp5inIttWTrlIShiYGBcwHtt2U=; b=BY+tqeq4k5HdfWaB Pa8O4yXQIxM3qH8s5TFcfLtgiLmLTwh4j7ZUN04wsuROD/Pj/1Z8DHbGKWdhLQv8 w9XsLuCc7snN1Vcfb1rtF5UY/OALQRPmVexdWf1RVGJlKenfwFtKJCJkLBXczYti T69N0TuQJlBmx/FbXqfmRyEWEPB1vASAW9i1nwmeYxfml7CttFPXq7dRuiCF8wW6 C3ekpaDxYtyV2vBDH8Q9IlPJOm4W/x/ZQdJS8FwTN7AJwSjUNA/nuh9mqZFYo122 uhjcrN0ElxgBL0S26uR5suoKaj5OfmlAcqy4M22jehY4hQAGhEeKct4mExVqAF8L hURUFg== 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-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QoOMWz W2a0Rk8GqAbPp5inIttWTrlIShiYGBcwHtt2U=; b=deoic7EfqilobSbryQVKoj nJT2MGefGx3vBjPPzf/FcWrsTmUrjxF8392OSjogVBf7EjlSo0ZKc3pRX1qOd71t u+DJdnNP3LllxDbc4CoyYVbgjAV/QHaNXsqv3cTQQ8azlwGcOXAcdawS8G6NzWm9 660LD+9Pxn61KWWDeGCLALzUjRS/0hZ+zRqWcseGySH4Wy/L10F9MNYo7RjNgC44 qK49piOVglfzUAeuNpyJ6BPUfyKQNNqJX3eTle96b/JW8/cjoLEIKhPD2vY/u2yy U57cv7jx4jsLB0CRzJHdYKYpP7Ajosy3PR6MnJY04611SKPiT/AQYeGYLo8ast2w == X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 713FA622C6; Tue, 20 Nov 2018 09:14:25 -0500 (EST) Message-Id: <1542723265.3210673.1583202440.55F67E9C@webmail.messagingengine.com> From: Matthew Horsfall To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b Date: Tue, 20 Nov 2018 09:14:25 -0500 Archived-At: Subject: [Jmap] Review: draft-ietf-jmap-core-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 14:15:25 -0000 Feedback on https://datatracker.ietf.org/doc/draft-ietf-jmap-core/?include_text=1 > 1.2. The Int and PositiveInt data types > Where "Int" is given as a data type, it means an integer in the range > -2^53 <= value <= 2^53 (the maximum integer that may be reliably > stored in a floating-point double), represented as a JSON "Number". > > Where "PositiveInt" is given as a data type, it means an "Int" where > the value MUST be in the range 0 <= value <= 2^53. The ranges look wrong to me. RFC 7159 states: Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. > 1.4. JSON as the data encoding format > > JSON is a text-based data interchange format as specified in > [RFC7159]. The I-JSON format defined in [RFC7493] is a strict subset > of this, adding restrictions to avoid potentially confusing scenarios > (for example, it mandates that an object MUST NOT have two properties > with the same key). Nit: "properties" and "keys" are not terms used by the JSON spec, instead "members" and "name/value" pairs. > 1.5.2 Accounts: > > In the event of a severe internal error, a server may have to > reallocate ids or do something else that violates standard JMAP data > constraints for an account. In this situation, the data on the > server is no longer compatible with cached data the client may have > from before. The server MUST treat this as though the account has > been deleted and then recreated with a new account id. Clients will > then be forced to throw away any data with the old account id and > refetch all data from scratch. This section is concerning to me. If accountIds can change, how would a consumer know that happened? Furthermore, how could an external service rely on a JMAP store if it can't use a reliable identifier to query/store that data? > 1.6 Ids > > Ids are always "String"s. An id MUST be at least 1 character in > length and maximum 255 octets in size, Nit: Mixing character and octet here seems strange > 2. The JMAP Session Resource 1. The URL for the JMAP Session resource. This may be requested directly from the user, or discovered automatically based on a username domain (see Service Autodiscovery section below). Maybe link to a section identifier (2.2 vs 8.3) since there are two of these and it makes jumping around easier. > 2.2 Service Autodiscovery > 8.3 Service autodiscovery Use consistent case > 2. The JMAP Session Resource: > > * *maxObjectsInSet*: "PositiveInt" The maximum number of objects > the client may send to create, update or destroy in a single > "/set" type method call. Maybe clarify that if the max is, say, 10, that means you can only have 5 creates, 4 updates, and 1 destroy, or it means you can have 10 of each. > 2.1. Example > > In the following example JMAP Session object, the user has access to > his own mail and contacts via JMAP, as well as read-only access to > shared mail from another user. I'm not sure where RFCs stand on gender neutrality but I think 'their' is a fine replacement for 'his'. This seems to be the only gendered bit in the whole document. > 3.5 > > "invalidResultReference": The method used a back reference for one of > its arguments (see the next section), but this failed to resolve. "see the next section" would be more useful as "see section 3.6" for quickly searching/jumping/linking to the proper section. > 3.6 References to previous result methods The complicated example shows 4 api calls, 2 of which use '*', Thread/get and Email/get, but we gloss over the Thread/get and explain the Email/get. Probably fine... > 5.4 Copy > > o *accountId*: "String" The id of the account to copy records to. > This MUST be different to the "fromAccountId". Seems like this should be toAccountId since for every other call 'accountId' is the account being operated on. Not sure. I guess you'd always be copying to *this* (the authenticated) account? > o *ifInState*: "String|null" This is a state string as returned by > the _Foo/get_ method. If supplied, the string must match the > current state of the account referenced by the accountId, > otherwise the method will be aborted and a "stateMismatch" error > returned. If "null", any changes will be applied to the current > state. Hrm, so for Foo/Copy, you can say "Only copy from X to Y if Y is currently in a specific state". Seems weird? > o *fromAccountId*: "String" The id of the account records were > copied from. > > o *accountId*: "String" The id of the account records were copied > to. > > o *oldState*: "String|null" The state string that would have been > returned by _Foo/get_ on this account before making the requested > changes, or "null" if the server doesn't know what the previous > state string was. > > o *newState*: "String" The state string that will now be returned by > _Foo/get_ on this account. Which account is "this account"? The one being copied from, or to? I guess to. > 5.8 Proxy Considerations > > 1. It must pass a "createdIds" property with each subrequest. If > this is not given by the client, an empty object should be used > for the first subrequest. The "createIds" property of each > subresponse should be passed on in the next subrequest. CreateIds -> CreatedIds > 6. Binary Data > > o *type*: "String" The media type of the file (as specified in > [RFC6838], section 4.2) as set in the Content-Type header of the > upload HTTP request. Why is 'type' returned for an Upload response when we say: "The blobId solely represents the raw bytes of data, not any associated metadata such as a file name or content type. " Also it's just returning what was set in the Content-Type header of the request? > As the data for a particular blobId is immutable, and thus the > response in the generated download URL is too, implementors are > recommended to set long cache times for successful responses, for > example "Cache-Control: private, max-age=31536000". What if someone wants to delete a message and ensure its blob is no longer downloadable? With this recommendation, that data might continue to be served up for a very long time. > 7.1 The StateChange Object > > o *changed*: "String[TypeState]" A map of _account id_ to an object > encoding the state of data... Should _account id_ be _accountId_ for consistency? > 7.1.1 Example > > In this example, the server has almalgamated a few changes together > across two different accounts the user has access to, before pushing > the following StateChange object to the client: almalgamated -> amalgamated (or use a simpler word) > 7.2 Push Subscription > > * *p256dh*: the P-256 ECDH Diffie-Hellman public key as described > in [RFC8291], encoded in URL-safe Base64 representation as > defined in [RFC4648]. > > * *auth*: the authentication secret as described in [RFC8291], > encoded in URL-safe base64 representation as defined in > [RFC4648]. We should use consistent case for 'base64' > When these credentials are not time bounded (e.g. [RFC7617] Basic > Authentication), the server SHOULD set an expiry time for the push > subscription if none given, and limit the expiry time if set too far > in the future. This maximum expiry time MUST be at least 48 hours in > the future and SHOULD be at least 7 days in the future. Why 48 hours / 7 days (explain?) Cheers, -- Matthew Horsfall (alh) From nobody Thu Nov 22 18:35:38 2018 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 AEECB126BED for ; Thu, 22 Nov 2018 18:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=GDOb3aRf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z5cNOuot 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 mqekslW0EM0B for ; Thu, 22 Nov 2018 18:35:34 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC0112D4E7 for ; Thu, 22 Nov 2018 18:35:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6C4B421E00 for ; Thu, 22 Nov 2018 21:35:33 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 22 Nov 2018 21:35:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=zlsT9BsVaikai3Q0wylgwtsYNfah npkRlm0XKbwtlkQ=; b=GDOb3aRfHKPe6F5wV0G+2DglYdtW+bnzyMT9jizFFp/Z QRs1dZ6K3m0ef0Rpv1MZxxB/uqdZEuP0Bc+TQ2XKrewap6bahDK4Dnqc6NNDCG77 vvUbZO3ByiR4T1FNC7tQmiWr2HQif8tYIb0G1H/cMOxwJc7hEo3yhkEhcL2Gs9rF mna+2qnFEKCCwdKzL0Lq3U/mGPHxVfm3sNjzG7uhCbc2t6YQDvwG2XxBb+UK+JTQ a7ucTNaZyLjQxuYRut6OPc2CAvPpdwE1REfe3VIyjK1d0xyfcOZkdDr+Njef8HfM dJgzQAiOAf4CpkT/THykLdofuR36XE6jPnTeodxHIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=zlsT9BsVaikai3Q0w ylgwtsYNfahnpkRlm0XKbwtlkQ=; b=Z5cNOuot+YFT3A4bVf6ER06c5Mg5JbjGA gsRs2B73MGIWLv3dwxi+ins6fRXMrxzDlS4JZE1/Kg29hputlDgH8SCVRzSFU6pn C7xGzb6KKLPrFCaOm6O/at0w9qqYChO/ncU6IAKHS7ZgqxHTfu7nrvoQKu9RcUzf XvqJNE5R9ik/tDtoTOsOrofMVr0Mp7Pt/S53MNzNFcuFCfvMwpJylt7spQAYPEXR ERsCN/n/CMrVaB9YkvNpl374MLhLTfvxYuCQShYCyymV4kRWywYpPAvJL0eiHPg3 EIu7vIoYoFLCWFOzjXK/UZz8yR9TsT3MzSu8uGajtagrOORgXXeMQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F35DC204DC; Thu, 22 Nov 2018 21:35:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 In-Reply-To: <1542723265.3210673.1583202440.55F67E9C@webmail.messagingengine.com> References: <1542723265.3210673.1583202440.55F67E9C@webmail.messagingengine.com> Date: Thu, 22 Nov 2018 21:35:28 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=3f4836b10b3a4c8eb8d039bdfd3eaf30 Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-core-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 02:35:37 -0000 --3f4836b10b3a4c8eb8d039bdfd3eaf30 Content-Type: text/plain Thanks Matt, I've fixed the issues you raised. A few comments and answers to questions: On Wed, 21 Nov 2018, at 1:15 AM, Matthew Horsfall wrote: > > Where "PositiveInt" is given as a data type, it means an "Int" where > > the value MUST be in the range 0 <= value <= 2^53. > > The ranges look wrong to me. > > RFC 7159 states: > > Note that when such software is used, numbers that are integers and > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > sense that implementations will agree exactly on their numeric > values. I've changed this to match RFC7159. I think there's a slight difference in opinion on what's considered "safe" but it's better to follow existing convention (and it makes no practical difference anyway). 2^53 can be stored exactly, however 2^53+1 cannot and so 2^53+1 == 2^53 in IEEE754 arithmetic, hence I guess why you might consider it "unsafe". > > 1.5.2 Accounts: > > > > In the event of a severe internal error, a server may have to > > reallocate ids or do something else that violates standard JMAP data > > constraints for an account. In this situation, the data on the > > server is no longer compatible with cached data the client may have > > from before. The server MUST treat this as though the account has > > been deleted and then recreated with a new account id. Clients will > > then be forced to throw away any data with the old account id and > > refetch all data from scratch. > > This section is concerning to me. > > If accountIds can change, how would a consumer know that happened? The point of this is there's a catastrophic change, e.g. you lose all the ids you have assigned to objects and have to assign everything a new one. This would be so utterly confusing to clients, even if you return cannotCalculateChange errors for `/changes` calls etc., that it's better to pretend you have a whole new account and force the client to resync everything from scratch and throw away all assumptions. This should be a very, very rare occurrence, but it's a recommendation of what you must do to handle this scenario should you need. > > 6. Binary Data > > > > o *type*: "String" The media type of the file (as specified in > > [RFC6838], section 4.2) as set in the Content-Type header of the > > upload HTTP request. > > Why is 'type' returned for an Upload response when we say: > > "The blobId solely represents > the raw bytes of data, not any associated metadata such as a file > name or content type. " > > Also it's just returning what was set in the Content-Type header of > the request? Because in browser contexts the Content-Type header may be set by the browser automatically and you want to know what it sent. > > As the data for a particular blobId is immutable, and thus the > > response in the generated download URL is too, implementors are > > recommended to set long cache times for successful responses, for > > example "Cache-Control: private, max-age=31536000". > > What if someone wants to delete a message and ensure its blob is no > longer downloadable? With this recommendation, that data might continue > to be served up for a very long time. Hmm, yes this is a consideration. It depends where your caching layers are I guess whether this is likely to be a problem. `Cache-Control: private` means that the response is intended for a single user and MUST NOT be cached by a shared cache like a proxy server, but a local client might still keep this cached for some time after the last reference is deleted. Don't know if this needs a comment in the spec; anyone got an opinion? > > When these credentials are not time bounded (e.g. [RFC7617] Basic > > Authentication), the server SHOULD set an expiry time for the push > > subscription if none given, and limit the expiry time if set too far > > in the future. This maximum expiry time MUST be at least 48 hours in > > the future and SHOULD be at least 7 days in the future. > > Why 48 hours / 7 days (explain?) I've added this text to the end of the paragraph: *An app running on a mobile device may only be able to refresh the push subscription lifetime when it is in the foreground, and so this gives a reasonable timeframe to allow this to happen.* Neil. --3f4836b10b3a4c8eb8d039bdfd3eaf30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Matt, I'= ve fixed the issues you raised. A few comments and answers to questions:=

On Wed, 21 Nov 2018, at 1:15 AM, Matthew H= orsfall wrote:
>   Where "PositiveInt" is given as a data type, it m= eans an "Int" where
>   the value MUST be in = the range 0 <=3D value <=3D 2^53.

The= ranges look wrong to me.

RFC 7159 states:<= br>

Note that when such software is used, numbe= rs that are integers and
   are in the range [-(= 2**53)+1, (2**53)-1] are interoperable in the
  = sense that implementations will agree exactly on their numeric
   values.

I'v= e changed this to match RFC7159. I think there's a slight difference in = opinion on what's considered "safe" but it's better to follow existing c= onvention (and it makes no practical difference anyway). 2^53 can be sto= red exactly, however 2^53+1 cannot and so 2^53+1 =3D=3D 2^53 in IEEE754 = arithmetic, hence I guess why you might consider it "unsafe".
<= div>
>= 1.5.2 Accounts:
>
>   In th= e event of a severe internal error, a server may have to
&= gt;   reallocate ids or do something else that violates standa= rd JMAP data
>   constraints for an account.&= nbsp; In this situation, the data on the
>   = server is no longer compatible with cached data the client may have
<= /div>
>   from before.  The server MUST treat this= as though the account has
>   been deleted a= nd then recreated with a new account id.  Clients will
>   then be forced to throw away any data with the old ac= count id and
>   refetch all data from scratc= h.

This section is concerning to me.

If accountIds can change, how would a consumer kn= ow that happened?

The point of= this is there's a catastrophic change, e.g. you lose all the ids you ha= ve assigned to objects and have to assign everything a new one. This wou= ld be so utterly confusing to clients, even if you return cannotCalculat= eChange errors for /changes calls etc., that it's better to preten= d you have a whole new account and force the client to resync everything= from scratch and throw away all assumptions. This should be a very, ver= y rare occurrence, but it's a recommendation of what you must do to hand= le this scenario should you need.

> 6. Binary Data
>
>   o  *type*: "String" The media= type of the file (as specified in
>   &= nbsp;  [RFC6838], section 4.2) as set in the Content-Type header of= the
>      upload HTTP reques= t.

Why is 'type' returned for an Upload res= ponse when we say:

"The blobId solely repre= sents
the raw bytes of data, not any associated metadata s= uch as a file
name or content type. "

Also it's just returning what was set in the Content-Type heade= r of
the request?

Because in browser contexts the Content-Type header may be set by the = browser automatically and you want to know what it sent.
<= br>
> = ;  As the data for a particular blobId is immutable, and thus the
>   response in the generated download URL is = too, implementors are
>   recommended to set = long cache times for successful responses, for
> &= nbsp; example "Cache-Control: private, max-age=3D31536000".

What if someone wants to delete a message and ensure it= s blob is no
longer downloadable? With this recommendation= , that data might continue
to be served up for a very long= time.

Hmm, yes this is a cons= ideration. It depends where your caching layers are I guess whether this= is likely to be a problem. Cache-Control: private means that=  the response is intended for a single user and MUST NOT be cached= by a shared cache like a proxy server, but a local client might still k= eep this cached for some time after the last reference is deleted. Don't= know if this needs a comment in the spec; anyone got an opinion?

= >   When these credentials are not time bounded (e.g. = [RFC7617] Basic
>   Authentication), the ser= ver SHOULD set an expiry time for the push
>  = ; subscription if none given, and limit the expiry time if set too far
>   in the future.  This maximum expiry t= ime MUST be at least 48 hours in
>   the futu= re and SHOULD be at least 7 days in the future.

=
Why 48 hours / 7 days (explain?)

I've added this text to the end of the paragraph: An app= running on a mobile device may only be able to refresh the push subscri= ption lifetime when it is in the foreground, and so this gives a reasona= ble timeframe to allow this to happen.

= Neil.
--3f4836b10b3a4c8eb8d039bdfd3eaf30-- From nobody Thu Nov 22 20:03:12 2018 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 34A20126CC7 for ; Thu, 22 Nov 2018 20:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=hFVtlsN6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N1HCwhtC 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 JPLrXR7CcSGO for ; Thu, 22 Nov 2018 20:03:09 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04478126BED for ; Thu, 22 Nov 2018 20:03:08 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BB14D21B74 for ; Thu, 22 Nov 2018 23:03:07 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 22 Nov 2018 23:03:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=NXXV7akBaqPboohZrvQa1e67ztnF /cP69PnHDmZrQ9A=; b=hFVtlsN6Lu4j/lpCfyipK7tTjgFJTsn/5bpRT6nGCTWK mEuhlZ/RQeH7mkHGTuhhzQSgfmG5AMZKBNtdjxvPWmcgYWQI0Sqs9UvxsnEwr8tP IbdNYde0F79/0nRWdNK6orZuZrQIBhiQkX26b/O6Yal/wkvUMIZe8NnkzU+4eERB lZm23R74Zu0PeBBZZzUveOI8D7b4Un8k6MH77VdCYX7DecxENidwJxF2PFXkNiRw CKFIV+YdVCLlveZi0hfEfhtvw0ElfG5VvHnsWdYUrJEB+WS4dHWoufeLPiov/ndf OXO6xBWn1xp690KBZC1d2reSL3mMZ8kkV2ie77P5hg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=NXXV7akBaqPboohZr vQa1e67ztnF/cP69PnHDmZrQ9A=; b=N1HCwhtC27l2by1LDd7/ANkL64DDxIUyW KY7XgNyuAE+4puut1iOxB5ZB6HqKp+9HaYcZKHr/WjAj5DptJ0/JIG8WXzucZj8s DhhV7NpcFDA93x3Bghendp1h/jH0KSsqse2YVCE3UF8JISaXczS4jmg/12R5ndWs UNUlTnIOg021zxiEYrCN/29yugTy6zYy47gwZ/teiFT6C0T7MRwxW1x/l4Z+ExXi /Al77AKvyNKAJc2n73HYYnGQrKUlj8f0w9+hxAO6XzkFecr0DxGoWX74CDRklpys HYjN+zpCqfgIJn4NIUsYNytJi4NP5J72IcAkZGWOGp+pU1DPl7bNg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E75CD204DC; Thu, 22 Nov 2018 23:03:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 In-Reply-To: <0e63904a-6c4e-42d4-a140-f1ca99bafca3@sloti7d1t02> References: <0e63904a-6c4e-42d4-a140-f1ca99bafca3@sloti7d1t02> Date: Thu, 22 Nov 2018 23:02:53 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=facefd9a09b54cf9aa556bd0a88ec965 Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-core-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 04:03:11 -0000 --facefd9a09b54cf9aa556bd0a88ec965 Content-Type: text/plain Thanks for the comments, I've fixed these issues. A few comments and answers: On Thu, 15 Nov 2018, at 4:13 PM, Bron Gondwana wrote: > *5.3 /set* > > returns: created/updated/destroyed which are either an object with 1+ items or null. Why not just require an empty object consistent with /changes responses? Likewise with the "not$X". Either that or allow omitting them entirely which is the same as the default value of empty/null. Request and response arguments may already be omitted if the default value, and any nullable argument automatically has a default of `null`, so these arguments may be omitted. > *5.5 /query* > > What happens if you don't give a limit and don't ask for total to be calculated, but the server decides to limit the number of records returned? > Since we now support calculateTotal, we need to double check how those two interact. Good catch, I've now made it so the server returns the limit if it was set or modified by the server. > *6. Binary Data* > > This is probably the most difficult part of the spec as someone used to implementing IMAP. Uploaded blobs are like temporary files. > >> Except where quota restrictions force early deletion, an unreferenced blob MUST NOT be deleted for at least 1 hour from the time of upload > > What does that even mean? It means clients should have a reasonable expectation that the blob will still be there if they upload it and then try to reference it within a reasonable time frame. However, the server needs to also be able to stop a malicious client from trying to bypass quota restrictions by uploading a load of unreferenced content. In general it's meant to work like this: * The server has some kind of unreferenced blob quota, let's say 250 MB. * The maximum size message a client can send is 50 MB. * The client uploads some blobs to be able to use them as attachments. These now count towards the unreferenced quota and will be deleted by the server after 24h (say) if still unreferenced. * The client saves a draft referencing the blobs it has uploaded (this usually happens pretty much immediately after the upload finishes). The blobs are no longer unreferenced so they are now part of regular quota and no longer a concern. * Rinse and repeat. So the only time you should get anywhere close to the unreferenced blob quota limit under normal operation would be if you had lots of parallel uploads happening and something waiting for them all to finish uploading to use, or something like that I guess. This is really just a safety net. I think the current behaviour is reasonable, but I've added the following text to remind clients that an edge case exists that they should handle: *Clients should use the blobId returned in a timely manner. Under rare circumstances the server may have deleted the blob before the client uses it; the client should keep a reference to the local file so it can upload it again in such a situation.* > Also: some advice around access control and blobs would be useful here. I've added: *As access controls are often determined by the object holding the reference to a blob, unreferenced blobs MUST only be accessible to the uploader, even in shared accounts.* > 7.2 Push subscriptions > >> If the response code is "503" (Service Unavailable), the JMAP server MAY try again later, but may also just drop the event. If the response code is "429" (Too Many Requests) the JMAP server SHOULD attempt to reduce the frequency of pushes to that URL. Any other "4xx" or "5xx" response code MUST be considered a *permanent failure* and the push subscription SHOULD be destroyed. > > I'd like some advice from HTTP people about whether this is the right approach. It feels like it could lead to some pretty flaky feeling push subscription loss for clients in the face of legitimate network reality between different systems. This was really about security concerns, so I've removed this paragraph and added a discussion in the security considerations section about the issues with connecting to unknown 3rd party servers. Neil. --facefd9a09b54cf9aa556bd0a88ec965 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks for= the comments, I've fixed these issues. A few comments and answers:
<= /div>

On Thu, 15 Nov 2018, at 4:13 PM, Bron Gondwana = wrote:
5.3 /set

returns: creat= ed/updated/destroyed which are either an object with 1+ items or null.&n= bsp; Why not just require an empty object consistent with /changes respo= nses?  Likewise with the "not$X".  Either that or allow omitti= ng them entirely which is the same as the default value of empty/null.

Request and response arguments = may alread= y be omitted if the default value, and any nullable argument automat= ically has a default of null, so these arguments may be omitted.

=
5.5 /query

What ha= ppens if you don't give a limit and don't ask for total to be calculated= , but the server decides to limit the number of records returned?
Since we now support calculateTotal= , we need to double check how those two interact.
=

Good catch, I've now made it so the server returns t= he limit if it was set or modified by the server.

6. Binary Data

This is probably the m= ost difficult part of the spec as someone used to implementing IMAP.&nbs= p; Uploaded blobs are like temporary files.

Except where quo=
ta restrictions force early deletion, an
unreferenced blob MUST NOT be deleted for at least 1 hour from the
time of upload
<= br>
What does that even mean?
=

It means clients should have a re= asonable expectation that the blob will still be there if they upload it= and then try to reference it within a reasonable time frame. However, t= he server needs to also be able to stop a malicious client from trying t= o bypass quota restrictions by uploading a load of unreferenced content.=

In general it's meant to work like this:

  • The server has some kind of unreferenced = blob quota, let's say 250 MB.
  • The maximum size message a cli= ent can send is 50 MB.
  • The client uploads some blobs to be a= ble to use them as attachments. These now count towards the unreferenced= quota and will be deleted by the server after 24h (say) if still unrefe= renced.
  • The client saves a draft referencing the blobs it ha= s uploaded (this usually happens pretty much immediately after the uploa= d finishes). The blobs are no longer unreferenced so they are now part o= f regular quota and no longer a concern.
  • Rinse and repeat.

So the only time you should get anywhere clo= se to the unreferenced blob quota limit under normal operation would be = if you had lots of parallel uploads happening and something waiting for = them all to finish uploading to use, or something like that I guess. Thi= s is really just a safety net. I think the current behaviour is reasonab= le, but I've added the following text to remind clients that an edge cas= e exists that they should handle:

Client= s should use the blobId returned in a timely manner. Under rare circumst= ances the server may have deleted the blob before the client uses it; th= e client should keep a reference to the local file so it can upload it a= gain in such a situation.

Also: so= me advice around access control and blobs would be useful here. 

I've added:

<= /div>
As access controls are often determined by the object holdi= ng the reference to a blob, unreferenced blobs MUST only be accessible t= o the uploader, even in shared accounts.

7.2 Push subscriptions

If the response code is "503"=
 (Service Unavailable), the JMAP server
MAY try again later, but may also just drop the event.  If the
response code is "429" (Too Many Requests) the JMAP server SHOULD
attempt to reduce the frequency of pushes to that URL.  Any other
"4xx" or "5xx" response code MUST be considered a *permanent failure*
and the push subscription SHOULD be destroyed.

I'd like some advice from HTTP people about whether this is the right= approach.  It feels like it could lead to some pretty flaky feelin= g push subscription loss for clients in the face of legitimate network r= eality between different systems.

<= div>This was really about security concerns, so I've removed this paragr= aph and added a discussion in the security considerations section about = the issues with connecting to unknown 3rd party servers.
<= br>
Neil.
--facefd9a09b54cf9aa556bd0a88ec965-- From nobody Thu Nov 22 20:58:46 2018 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 85CA7126DBF for ; Thu, 22 Nov 2018 20:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wh0kzEjv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KprVIDOO 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 0vqb2aWptl8F for ; Thu, 22 Nov 2018 20:58:43 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBB8126CC7 for ; Thu, 22 Nov 2018 20:58:43 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3424222038 for ; Thu, 22 Nov 2018 23:58:42 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 22 Nov 2018 23:58:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=QzEdOKzXxGjiaMsrWSiTLRapu8j7 GdnkarWTC4E7TtY=; b=wh0kzEjv04MbPqD9IalInE3a7PdM0KHPNqEDqCerjXKo TcGMolD6IhmgdlJAUvo9e3rciuNKXPbF4omOGuxBErXuRXnSAaZJSkMcKJN74841 h21vLEP2U6vuhrSVaeOlDWL+uwrGLqhy6pNo5zi7UKnnImm/His1U+SGkgF2vqiT EhkE1Bbg7S/TsibXi0C4WmIe+GK37Na+vd8klsgzZaL6b0yd5SbOQEhJSXpx/l4s UWfb99vw3ZHLie9/lcrkiVysr7/bA/Z6676MQ6VuoGoWGLvxdlJ9WqnlPvc0IhHO FOhGHa263Fjj6DiBCU3GrC9Clgya9nAi5/24t/tBwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QzEdOKzXxGjiaMsrW SiTLRapu8j7GdnkarWTC4E7TtY=; b=KprVIDOO1EiFP/F9w2Kp1NnJo+dj3M1XP iKk65GFdRzE5Ne40wl5lmH8z1O88quLPM0I2gttP3D9ZFSnsq9l4BuU50K3CG45x jxtO6kI79UhjULh3YleuRzcZjFUt+JAUtW5d9OklL+kzR6yVIRjStlOFLl1jz7xL H+diI1RAgTWH2Dk1Sc8Dy0r0+EV+oCI4flR7wXebgjZsIXPdV53PcUBPAgp4rBiT 4f2o9HGyfTi5m/B0qYiIz0VBYNN0qFKftdt0qpDE602UU7zszTB2JrWG5CNkm3zk 837IyO+Rb0h7VkjKtNLpflGKCNqOYVCEmnEbBs35etFG+FgWGooaQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 83A54204DC; Thu, 22 Nov 2018 23:58:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 In-Reply-To: References: Date: Thu, 22 Nov 2018 23:58:41 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=e4fadf39200544b7be4fd38cb75b2804 Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mail-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 04:58:45 -0000 --e4fadf39200544b7be4fd38cb75b2804 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 15 Nov 2018, at 5:46 PM, Bron Gondwana wrote:=20 > *1.3.1 **urn:ietf:params:jmap:mail* > maxMailboxDepth - do you mean "one more than the maximum number of anc= estors"? Aka, "1" means no tree, all toplevel. =20 Yes, good catch. =20 > *1.3.2 **urn:ietf:params:jmap:submission** *=20 > =20 >> By default, the JMAP server should show only known safe- to-expose EHLO capabilities in this field, and hide EHLO capabilities that are only relevant to the JMAP server. > =20 > What does this actually mean? I find this sentence confusing about rel= evance.=20 =20 I've changed it to: *By default, the JMAP server should hide EHLO capabi= lities that are to do with the transport mechanism and thus are only rel= evant to the JMAP server (for example PIPELINING, *CHUNKING, *or STARTTL= S).* =20 Is that clear? =20 > *1.5 Push*=20 > =20 >> In addition, servers MUST support a psuedo-type called "EmailDelivery" in the push mechanisms. The state string for this MUST change whenever a new Email is added to the store, but SHOULD NOT change upon any other change to the Email objects. > =20 > Is that really something that should be a MUST? I guess it can just be= a copy of "Email" if you can't tell if something was a new message.=20 =20 Yes, this is trivial and spec compliant, and will result in correct clie= nt behaviour at the expense of some efficiency. I think therefore it's b= etter to make it a MUST than to force the client to have two pathways to= handle whether it's there or not. =20 > *2. Mailbox*=20 > =20 > This should probably cross-reference RFC8474 OBJECTID at least as an i= nformative reference.=20 =20 I've added an *Ids* subsection to the intro and written this:=20 =20 *If a JMAP Mail server also provides an IMAP interface to the data and s= upports [@!RFC8474] IMAP Extension for Object Identifiers, the ids SHOUL= D be the same for mailbox, thread, and email objects in JMAP.** * =20 Is that what you were looking for, or something more? =20 > *3. Mailbox/set*=20 > Do we also want an onDestroyRemoveChildren argument to match onDestroy= RemoveMessages?=20 =20 I would say no. It's much easier for the client to explicitly destroy th= e children mailboxes than the children messages, and we'd have to be car= eful about the interaction of this with rate limits, with destroying mes= sages inside the child folders and the ordering and locking that might i= nvolve, etc. I think it would add quite a bit of complexity for not a lo= t of gain.=20 =20 > *4.1.4 Body parts*=20 > *preview*: see the discussion in extra@ietf.org about IMAP previews an= d making them consistent. I can see an argument for making the size of t= his be in characters rather than octets. I do feel strongly that we shou= ld make the limits exactly consistent between JMAP and IMAP, since we ha= ve that opportunity right now.=20 =20 I agree; I'm not sure if we have a final conclusion there, but when we d= o I'll make sure this is the same. =20 > *4.2 Email/get*=20 > =20 >> Where a specific header is requested as a property, the capitalization of the property name in the response MUST be identical to that used in the request. > =20 > Does this mean that a request for "From:asRaw" and "from:asRaw" return= s both of them separately?=20 =20 Yes, although that wouldn't be a very useful request to make. =20 > *7. Email submission*=20 > =20 > Why does this include threadId =E2=80=A6 Ahh yeah, handy for filtering= I guess...=20 =20 Exactly. =20 > *7.5 EmailSubmission/set*=20 > Given that we're updating Emails with side effect subrequests from thi= s, should there be a way to latch this against the Email state? ifInEmai= lState or something?=20 =20 I don't think this is needed. It's only operating on immutable propertie= s of the email so it's of limited utility, and would add considerable co= mplexity again.=20 =20 Neil.=20 --e4fadf39200544b7be4fd38cb75b2804 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, 15= Nov 2018, at 5:46 PM, Bron Gondwana wrote:
1.3.1 urn:ietf:params:jmap:mail
maxMai=
lboxDepth - do you mean "one more than the maximum number of ancestors"?=
  Aka, "1" means no tree, all toplevel.

<= /div>
Yes, good catch.

1.3.2 <= span class=3D"fastmail-quoted-m_h">urn:ietf:params:jmap:submission 

By default, the JMAP server should show onl=
y known safe-
to-expose EHLO capabilities in this field, and hide EHLO
capabilities that are only relevant to the JMAP server.

What does this actually mean?  I find this sentence con= fusing about relevance.

I've c= hanged it to: By default, the JMAP server should hide EHLO capab= ilities that are to do with the transport mechanism and thus are only re= levant to the JMAP server (for example PIPELINING, CHUNKING, or STARTTLS).

Is that clear?
1.5 Push

In addition, servers MUST =
support a psuedo-type called
"EmailDelivery" in the push mechanisms.  The state string for this
MUST change whenever a new Email is added to the store, but SHOULD
NOT change upon any other change to the Email objects.

Is that really something that should be a MUST?  I guess= it can just be a copy of "Email" if you can't tell if something was a n= ew message.

Yes, this is trivi= al and spec compliant, and will result in correct client behaviour at th= e expense of some efficiency. I think therefore it's better to make it a= MUST than to force the client to have two pathways to handle whether it= 's there or not.

2. Mailbox

This should probably cross-reference RFC8474 OBJECTID at least = as an informative reference.

I= 've added an Ids subsection to the intro and written this:

If a JMAP Mail server also provides an IMAP in= terface to the data and supports [@!RFC8474] IMAP Extension for Object I= dentifiers, the ids SHOULD be the same for mailbox, thread, and email ob= jects in JMAP.

Is that what you = were looking for, or something more?

3= . Mailbox/set
Do we also = want an onDestroyRemoveChildren argument to match onDestroyRemoveMessage= s?

I would say no. It's much e= asier for the client to explicitly destroy the children mailboxes than t= he children messages, and we'd have to be careful about the interaction = of this with rate limits, with destroying messages inside the child fold= ers and the ordering and locking that might involve, etc. I think it wou= ld add quite a bit of complexity for not a lot of gain.
4.1.4 Body parts
*preview*: see the discussion in extra@ietf.org about IMAP previews and making them consiste= nt. I can see an argument for making the size of this be in characters = rather than octets.  I do feel strongly that we should make the lim= its exactly consistent between JMAP and IMAP, since we have that opportu= nity right now.

I agree; I'm n= ot sure if we have a final conclusion there, but when we do I'll make su= re this is the same.

4.2 Email/get= 

Where a specific header is requested as a property, the
capitalization of the property name in the response MUST be identical
to that used in the request.

Does this mean = that a request for "From:asRaw" and "from:asRaw" returns both of them se= parately?

Yes, although that w= ouldn't be a very useful request to make.

7. Email submission

Why does this include threadId  =E2=80=A6  Ahh yeah= , handy for filtering I guess...

Exactly.

7.5 EmailSubmission/set
Given that we're updating Emails with side effect sub= requests from this, should there be a way to latch this against the Emai= l state? ifInEmailState or something?
<= br>
I don't think this is needed. It's only operating on immut= able properties of the email so it's of limited utility, and would add c= onsiderable complexity again.

Neil.
--e4fadf39200544b7be4fd38cb75b2804-- From nobody Thu Nov 22 21:56:57 2018 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 8AEE6127B92 for ; Thu, 22 Nov 2018 21:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=XmEdCNHM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IotkfGc6 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 mTvkLLS4D5xf for ; Thu, 22 Nov 2018 21:56:55 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9FE1252B7 for ; Thu, 22 Nov 2018 21:56:55 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4242222112; Fri, 23 Nov 2018 00:56:54 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 23 Nov 2018 00:56:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=3Fb+HE8gIUstFCF5lqJN7n7M9 ubgsh6x2xUzadFAXJs=; b=XmEdCNHMoa4V4gSFcyto6fhZ3Mvs3R9DogUwbSJDx Gi8xr/GfCQ7Hc/y0oxx52qWbFBsjdvGYIUetTbb8djUChGHbbn0esjHvXREH3TxB eCcmyIULL0swPcHbLLTl49FdqQwXckDM9HSgprfsQVVE7Mx+puVdYuIaZtb6UdWR 2blviWXDclOh/xYcETtX74S7kVPatmVuXCkmCQM3rHrbQn5JzYxnwwvdZJpEU9x7 sZDTvzu/vOyOYMnPnALg/B6U0OU8jGIbTVm8kqvifKRqQZ9+s65Zk0U47qYVqNpU xFf/aqPWY4GoC9FlLpVQJzyAggPQZJxUyVD6ZOeVlR1Fg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3Fb+HE8gIUstFCF5l qJN7n7M9ubgsh6x2xUzadFAXJs=; b=IotkfGc6t/uC7/px4OO+9PLA7mz4AWHiP jArTMKzJT3f4YmoigyWwfbQPWei9zG45F1/9evBUajumuURyUZGt9ClXxWWE4mOb SScNCP7lIOl8J/N/oZhtJqJUHZfgdS4u02Ez4WGrxZDdAIIE9YM3zwulVZio1Eg1 46US4B2wQvaoOBn7NYIJ1GSgWowuN45Z7hyGHILF2wDqix6H3RNe2jigQE4apeN4 aD5/eKFr3pFSbAaq0F+DsF54Rt6vXHUVj+ou0w+mw4KWNlxiRWe0nNKJizFyca/w xC9JKrv8vdaQQCvDjb/wbLNb1sOYSNIqtxGerDmmV+Tuzk7JzJAgA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C767C204DC; Fri, 23 Nov 2018 00:56:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <265ec3f1-75b8-43e3-8c52-276b6f6077c6@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 In-Reply-To: References: Date: Fri, 23 Nov 2018 00:56:53 -0500 From: "Neil Jenkins" To: "Ken Murchison" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=9b29347889aa43c0a93a32e02fb1143e Archived-At: Subject: Re: [Jmap] draft-murchison-jmap-websocket as a JMAP working product X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 05:56:57 -0000 --9b29347889aa43c0a93a32e02fb1143e Content-Type: text/plain We also discussed the open issues at the JMAP session in IETF 103: > o Should we allow push notifications over the WS connection? The consensus in the room was "yes", we should use the connection we already have. We would therefore need to: * Add a tag to each JSON object sent through the socket so we know what it is. I would suggest an `@type` property with values of `"Request"` (sent by the client to the server), `"Response"` and `"StateChange"` (sent by the server for API responses and pushes respectively). (These are the names of the objects in the JMAP spec.) > o Should we allow out of order processing of requests? Again the consensus was "yes"; you can use a single WebSocket connection as the equivalent to parallel HTTP API requests. This means we also need an `id` property on Request and Response objects so they can be correlated by the client. We probably also need to clarify that the core `maxConcurrentRequests` limit is applies to inflight requests over the WebSocket. We may need a new limit (exposed in the capability object) for establishing concurrent WebSocket connections (although a client shouldn't really need more than 1; that's the point)? Ken, are you able to update the spec and we can publish a new version as a JMAP working group product? Thanks. Neil. --9b29347889aa43c0a93a32e02fb1143e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
We also discuss= ed the open issues at the JMAP session in IETF 103:

   o  Should we allow = push notifications over the WS connection?
The consensus in the room was "yes", we should use the conn= ection we already have. We would therefore need to:
  • Add= a tag to each JSON object sent through the socket so we know what = it is. I would suggest an @type property with values of "Request" (sent by the client to the server), "Response" and "StateChan= ge" (sent by the server for API responses and pushes respectively= ). (These are the names of the objects in the JMAP spec.)
<= div>
   o  Should= we allow out of order processing of requests?

Again the consensus was "yes"; you can use a single Web= Socket connection as the equivalent to parallel HTTP API requests. This = means we also need an id property on Request and Response obj= ects so they can be correlated by the client.

<= div>We probably also need to clarify that the core maxConcurrentRequ= ests limit is applies to inflight requests over the WebSocket. We= may need a new limit (exposed in the capability object) for establishin= g concurrent WebSocket connections (although a client shouldn't rea= lly need more than 1; that's the point)?

Ken, a= re you able to update the spec and we can publish a new version as a JMA= P working group product? Thanks.

Neil.
<= /div> --9b29347889aa43c0a93a32e02fb1143e-- From nobody Fri Nov 23 04:38:50 2018 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 A3D3012E043 for ; Fri, 23 Nov 2018 04:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=n8ljxRrd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HYil1dP3 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 qovKmgMephwv for ; Fri, 23 Nov 2018 04:38:45 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6715712958B for ; Fri, 23 Nov 2018 04:38:45 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 538EE21D2A; Fri, 23 Nov 2018 07:38:44 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 23 Nov 2018 07:38:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type; s=fm1; bh=iKZqElqxL Mdkn6uQaFGFjsqaMRCLVOyj+EZdaD+WNd4=; b=n8ljxRrdW1PVW3/IEava9LvBx w56rxktKx4/XJLzJmSC1t75+n44ea82kshaRog5KmUfm00AkYfTd3+yBpDtCD1qr Ypnc8z0CzvU28NRrcAj7uRPkNzKqRuOGMWW44J855q8dYEz/yaY5rKxUBOuWI7bg EtrQIDU7QWhu4CK2T0OKW5ZLCE17itXMNm/sGkNjsl9AkUmgTo9Q615q7hOmJmpc D6FvhFHu9ODaJwmQxx4RlHSIzw/eU1n20Dxsjaqvsf7JhaxIGfcm1h0e6+FGDdLH VMvql9xePisdQZZ2y0mj6hKnFkVWFUmJrXAa9AtrC0W+S8iRmATErVW77/zBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=iKZqEl qxLMdkn6uQaFGFjsqaMRCLVOyj+EZdaD+WNd4=; b=HYil1dP38TPaHuDeLINIx7 xMmYyypjyHTxkWTe7NzRtXWIYQ4iMIP3z4RWU2qnpIcRYW81E/7YdTbt6CzEcHaw NKlaQQLNwGn6hrDL/ddfewydEnMEajHYf+E4zyZXUH7H9PD8aR5nwVraM00CP+Cj zQvN2bOxwqQeSPcHQyoorz6yOdY74QgjYcltwZWrkEKbxS34hczji5c8XgJi+31F wtN9cFlTkWfdCb0rYJ7L0EItlMMQfN9JadxMbk1728f5S3OHW1EGBmdvOO7WR89O Z822JuSXBpTMK9cqRtPMBaJ0h7G/f+Lv8f33o2c0I7oWmEsQU6loCk8CbOPmTwWQ == X-ME-Sender: X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 6D256102E4; Fri, 23 Nov 2018 07:38:43 -0500 (EST) To: Neil Jenkins Cc: IETF JMAP Mailing List References: <265ec3f1-75b8-43e3-8c52-276b6f6077c6@sloti7d1t02> From: Ken Murchison Organization: FastMail US LLC Message-ID: <262a4f53-9f8c-b07d-eeb1-df1f77712f7c@fastmailteam.com> Date: Fri, 23 Nov 2018 07:38:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <265ec3f1-75b8-43e3-8c52-276b6f6077c6@sloti7d1t02> Content-Type: multipart/alternative; boundary="------------5FAE2FB341BD4D1336C460EB" Content-Language: en-US Archived-At: Subject: Re: [Jmap] draft-murchison-jmap-websocket as a JMAP working product X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 12:38:48 -0000 This is a multi-part message in MIME format. --------------5FAE2FB341BD4D1336C460EB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/18 12:56 AM, Neil Jenkins wrote: > We also discussed the open issues at the JMAP session in IETF 103: > >>    o  Should we allow push notifications over the WS connection? > > The consensus in the room was "yes", we should use the connection we > already have. We would therefore need to: > > * Add a tag to each JSON object sent through the socket so we know > what it is. I would suggest an |@type| property with values of > |"Request"| (sent by the client to the server), |"Response"| and > |"StateChange"| (sent by the server for API responses and pushes > respectively). (These are the names of the objects in the JMAP spec.) > Se already have @type in the problem details object returned for a request level error.  Can't the client simply check the response object for "methodResponses" , or "changed", or "type"? Otherwise, perhaps "responseType". > >>    o  Should we allow out of order processing of requests? > > Again the consensus was "yes"; you can use a single WebSocket > connection as the equivalent to parallel HTTP API requests. This means > we also need an |id| property on Request and Response objects so they > can be correlated by the client. Should we make this "requestId" to be a little more descriptive? Or perhaps steal "tag" from IMAP? > > We probably also need to clarify that the core |maxConcurrentRequests| > limit is applies to inflight requests over the WebSocket. We may need > a new limit (exposed in the capability object) for establishing > concurrent WebSocket connections (although a client shouldn't really > need more than 1; that's the point)? > > Ken, are you able to update the spec and we can publish a new version > as a JMAP working group product? Thanks. Sure. -- Ken Murchison Cyrus Development Team FastMail US LLC --------------5FAE2FB341BD4D1336C460EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/23/18 12:56 AM, Neil Jenkins wrote:
We also discussed the open issues at the JMAP session in IETF 103:

   o  Should we allow push notifications over the WS connection?

The consensus in the room was "yes", we should use the connection we already have. We would therefore need to:
  • Add a tag to each JSON object sent through the socket so we know what it is. I would suggest an @type property with values of "Request" (sent by the client to the server), "Response" and "StateChange" (sent by the server for API responses and pushes respectively). (These are the names of the objects in the JMAP spec.)


Se already have @type in the problem details object returned for a request level error.  Can't the client simply check the response object for "methodResponses" , or "changed", or "type"?  Otherwise, perhaps "responseType".



   o  Should we allow out of order processing of requests?

Again the consensus was "yes"; you can use a single WebSocket connection as the equivalent to parallel HTTP API requests. This means we also need an id property on Request and Response objects so they can be correlated by the client.


Should we make this "requestId" to be a little more descriptive?  Or perhaps steal "tag" from IMAP?




We probably also need to clarify that the core maxConcurrentRequests limit is applies to inflight requests over the WebSocket. We may need a new limit (exposed in the capability object) for establishing concurrent WebSocket connections (although a client shouldn't really need more than 1; that's the point)?

Ken, are you able to update the spec and we can publish a new version as a JMAP working group product? Thanks.


Sure.


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------5FAE2FB341BD4D1336C460EB-- From nobody Fri Nov 23 04:45:05 2018 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 B931D128766 for ; Fri, 23 Nov 2018 04:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=TLZpcuaa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ECw0VDBv 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 Jl_OlTiSlttN for ; Fri, 23 Nov 2018 04:45:00 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E6B124D68 for ; Fri, 23 Nov 2018 04:45:00 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EEA7D22131; Fri, 23 Nov 2018 07:44:58 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 23 Nov 2018 07:44:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=subject:from:to:cc:references:message-id :date:mime-version:in-reply-to:content-type; s=fm1; bh=R9OsdfOnN EX8qliVG25ghXTJDBEWTHcPP4lQxhB1aF0=; b=TLZpcuaaa6CGJ5Lmii9ZJWodW utV0iOLSEtbLl8UhnBXPtzbez1XqwGmg3HhLO6//foG6FKRsYf5dYZ+zQExGdIK7 i4cxdCEd9WWSewP5Lvuiq+iLOW6y1pRJwiwMPJ4U18eQVPYAe3/NkQIMF+7jD+LI GlJnNuSXu5ashbfBiLDSqD61Qh2Otoj4Fanwl/24/t/T/5ey5LHrTCNzxCP74PkX IbbNZu3aGH2Ugcev+WmzTGw7nkfuRLznDnhGX02b12Ksqc0UAyXLvmuTI4M5qtrn rEYQxXJLhN9hy0nkG0t38+0KPtmjpc9bi82kUYMbRoTRNtHzNjMXXnMqux4NA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=R9Osdf OnNEX8qliVG25ghXTJDBEWTHcPP4lQxhB1aF0=; b=ECw0VDBvgTiIIaIyp9MkHh XNL9FxrGyXOlWwIl8JMLmJK3E2aPnTa5tyYxn1n4cZPbubwpHETjPquEptuJ+9lZ ptNWwAIWKmV1cgfUKPsE+qaezJLVAiheDcfsSjPfDuNnVgTJh2Bomqd1EyvmrJt0 FGgYuzp38VwLh5sfXyXzhH2Yyb8AYHkXbfr66X/DpqQL11xNshLsy3XZYGC/Oubq lhSnL4Z62LUH1VmCnMAMcTXiJ8UpzMzQEhf4iwjR3grhkwfetModMuSA2bn54pAS djWISBS8Cq02lFga0V5eIWFvn2gdwJAZiQzaK0yaXycUJj95pDfiutRHUZIn3mlg == X-ME-Sender: X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E6F5102A0; Fri, 23 Nov 2018 07:44:58 -0500 (EST) From: Ken Murchison To: Neil Jenkins Cc: IETF JMAP Mailing List References: <265ec3f1-75b8-43e3-8c52-276b6f6077c6@sloti7d1t02> <262a4f53-9f8c-b07d-eeb1-df1f77712f7c@fastmailteam.com> Organization: FastMail US LLC Message-ID: Date: Fri, 23 Nov 2018 07:44:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <262a4f53-9f8c-b07d-eeb1-df1f77712f7c@fastmailteam.com> Content-Type: multipart/alternative; boundary="------------4EC3B19C51AA5A1C47712D42" Content-Language: en-US Archived-At: Subject: Re: [Jmap] draft-murchison-jmap-websocket as a JMAP working product X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 12:45:03 -0000 This is a multi-part message in MIME format. --------------4EC3B19C51AA5A1C47712D42 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/18 7:38 AM, Ken Murchison wrote: > > > On 11/23/18 12:56 AM, Neil Jenkins wrote: >> We also discussed the open issues at the JMAP session in IETF 103: >> >> >>>    o  Should we allow out of order processing of requests? >> >> Again the consensus was "yes"; you can use a single WebSocket >> connection as the equivalent to parallel HTTP API requests. This >> means we also need an |id| property on Request and Response objects >> so they can be correlated by the client. > > > Should we make this "requestId" to be a little more descriptive?  Or > perhaps steal "tag" from IMAP? > Is "clientId" in the request not sufficient for correlation? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------4EC3B19C51AA5A1C47712D42 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/23/18 7:38 AM, Ken Murchison wrote:


On 11/23/18 12:56 AM, Neil Jenkins wrote:
We also discussed the open issues at the JMAP session in IETF 103:


   o  Should we allow out of order processing of requests?

Again the consensus was "yes"; you can use a single WebSocket connection as the equivalent to parallel HTTP API requests. This means we also need an id property on Request and Response objects so they can be correlated by the client.


Should we make this "requestId" to be a little more descriptive?  Or perhaps steal "tag" from IMAP?


Is "clientId" in the request not sufficient for correlation?



-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------4EC3B19C51AA5A1C47712D42-- From nobody Fri Nov 23 07:05:40 2018 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 D392F130E09 for ; Fri, 23 Nov 2018 07:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=k09LBbi/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uH70jHHP 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 Uidx5lwNB9xq for ; Fri, 23 Nov 2018 07:05:36 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46399130DCE for ; Fri, 23 Nov 2018 07:05:36 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2DA9D220D8; Fri, 23 Nov 2018 10:05:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 23 Nov 2018 10:05:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type; s=fm1; bh=uFWqqKxxH jtCLPNEV775HFNFdOvctueQsmk5BmhF684=; b=k09LBbi/SEKWsb1utV/FJyA45 sWHdKTnl5m8oMifl35eH0r5z+SUSV9eBYCR+XL+XepmX4KqUXmtOApnm1W8Cr2Dq QV2uqDVE8iNwgIF3As57vJd0d+PZRbk35hvjF249N5fPGdEs7asys3ODHu1027zP ScX2qjbamo3HvmbzbqdFxZoZRF+rT8rYuCunX0fJ9TmwQOBlQEyYqzmwoRNKOdRH ofkjr4lqW7Dgt53IBwNN7kI8/kY2Z4OD1IO0OmrvAFMglvylwEBNux44YPLzs+qG 6LtL/JvwvhkJlvGAoIQH0f0+usCJUmi+6TmKydWZCScDYBEUqsQg6Z/WxP82g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=uFWqqK xxHjtCLPNEV775HFNFdOvctueQsmk5BmhF684=; b=uH70jHHPn2ndrYfZLY2YuE YC+hLkaBryb2NeyYDNT95IEQ+Wa0CrvqCdpiV0EdeGf+XIxSOlFB1SbdA/VZ/SMf TZ0hh183/YaraJyjzOx8YGMF3Z7w6g0cuPF8LV6CEzf83TTdCxU1BKjMDDLwyLbB 2pcy6Bi5SdCkpeMxD7iJ79h97I+tNeZnfqld2rTA/H7nnICVLXxR2hnj89drMjmj ejnBO9uzAy9C+FD+NUG3FoCavE2DrS+int9cPwwrjObXg/kzLM5M+/dqJkKGkPwP heJUnKI/ZTbe4OWr7EPxCKBMPC9cMaGz38tW1KOgpLi69PukY4dIsRBDce4xKw6Q == X-ME-Sender: X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 28673E49EC; Fri, 23 Nov 2018 10:05:34 -0500 (EST) To: Neil Jenkins Cc: IETF JMAP Mailing List References: <265ec3f1-75b8-43e3-8c52-276b6f6077c6@sloti7d1t02> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Fri, 23 Nov 2018 10:05:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <265ec3f1-75b8-43e3-8c52-276b6f6077c6@sloti7d1t02> Content-Type: multipart/alternative; boundary="------------00960547616EC984C0CAD7CB" Content-Language: en-US Archived-At: Subject: Re: [Jmap] draft-murchison-jmap-websocket as a JMAP working product X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 15:05:38 -0000 This is a multi-part message in MIME format. --------------00960547616EC984C0CAD7CB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/18 12:56 AM, Neil Jenkins wrote: > We also discussed the open issues at the JMAP session in IETF 103: > >>    o  Should we allow push notifications over the WS connection? > > The consensus in the room was "yes", we should use the connection we > already have. We would therefore need to: > > * Add a tag to each JSON object sent through the socket so we know > what it is. I would suggest an |@type| property with values of > |"Request"| (sent by the client to the server), |"Response"| and > |"StateChange"| (sent by the server for API responses and pushes > respectively). (These are the names of the objects in the JMAP spec.) > Do we push ALL notifications or do we allow the client to subscribe to notifications for certain object types? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------00960547616EC984C0CAD7CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/23/18 12:56 AM, Neil Jenkins wrote:
We also discussed the open issues at the JMAP session in IETF 103:

   o  Should we allow push notifications over the WS connection?

The consensus in the room was "yes", we should use the connection we already have. We would therefore need to:
  • Add a tag to each JSON object sent through the socket so we know what it is. I would suggest an @type property with values of "Request" (sent by the client to the server), "Response" and "StateChange" (sent by the server for API responses and pushes respectively). (These are the names of the objects in the JMAP spec.)


Do we push ALL notifications or do we allow the client to subscribe to notifications for certain object types?


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------00960547616EC984C0CAD7CB-- From nobody Sun Nov 25 15:29:24 2018 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 5136B124BF6 for ; Sun, 25 Nov 2018 15:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=EwGvyDXb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=M20yzEMa 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 P5wsqh7EtO_w for ; Sun, 25 Nov 2018 15:29:21 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC926126C01 for ; Sun, 25 Nov 2018 15:29:21 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CC75425979 for ; Sun, 25 Nov 2018 18:29:20 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 25 Nov 2018 18:29:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=GNuLYGVJiLYbdsmPkq9uOx3slJVlnXfg9IGnpVe sDqI=; b=EwGvyDXbW1GNRPZyFFaJVbI0w8zNcK68LZAFmx5MAjSC26dx/oK6FSL U2c68+dMYAALgrxMvffZd62Tyreccsh3V/IeSyKj25YSxeHnujPbcAGQLbOGucmq fFlaeNliE848/026svWJFmYY32a4brPjBZgijmqGO5/i4nF1DKw2cKcTxtnpLTcD gRKzIAtth5lEzf3S4QYi3TI7dj8QWTGZABrJVGRG9/LqZGrFml6zs6HTExSaZoJu nh9OdltChV63dd+vQTEHcVfSu8UzVDS5gombHAF5aytpV3cmgwGARnEFhVZziouv izLFDvqhOPPJ8r8qAuoVSe7ZE/B+7Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=GNuLYGVJiLYbdsmPkq9uOx3slJVlnXfg9IGnpVesDqI=; b=M20yzEMa XzG0kNvf6u5ADyJxBKxU4iJzqw4PJGV4YeHU++fFqu9suklVLo7wZMM+KuLFvWHh fL0XQDbu+Ho+rG+FUxiKLi+KEI6nYt8ek3Zx/4BzTZStITwJ0LZeoh68OR6gRK4R TAkls5h22KF+/WPLGRDVGogZxrKEFH24h0utWioRg4ZJ2eFDRRz6SB9eUMpXOeDw f9bJVmogzz3F+VBuyoKikmLH3VcKTPUzFU63gT8ARunbxGK90PqZxVkXNAXk3/wx RzwgMFb+5BkuST7Nz1U/va8wBCAPHhbrozxQ2bSkGtInI6ATPlGtQrxXIcU9BETU QU4NNa1wDnlIUQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 43640204DC; Sun, 25 Nov 2018 18:29:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <4f74cfdc-dc4a-4b4d-b295-540893d55ccb@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 Date: Sun, 25 Nov 2018 18:29:19 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=87ce2b5fa21e44979185c1d271c93303 Archived-At: Subject: [Jmap] JMAP document status X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 23:29:23 -0000 --87ce2b5fa21e44979185c1d271c93303 Content-Type: text/plain Hi all, Thanks for your patience as we get the JMAP documents into shape for submission! Neil is working on a final round of edits based on the feedback received during last call and I'm preparing the shepherding documents. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --87ce2b5fa21e44979185c1d271c93303 Content-Type: text/html
Hi all,

Thanks for your patience as we get the JMAP documents into shape for submission!  Neil is working on a final round of edits based on the feedback received during last call and I'm preparing the shepherding documents.

Cheers,

Bron.

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


--87ce2b5fa21e44979185c1d271c93303-- From nobody Sun Nov 25 15:35:52 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8B7124BF6; Sun, 25 Nov 2018 15:35:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154318895091.24405.16949067903829407230@ietfa.amsl.com> Date: Sun, 25 Nov 2018 15:35:50 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-11.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 23:35:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSON Meta Application Protocol Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-core-11.txt Pages : 72 Date : 2018-11-25 Abstract: This document specifies a protocol for clients to access JSON-based data objects efficiently, with support for push and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-11 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 25 15:38:18 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5021B126C01; Sun, 25 Nov 2018 15:38:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154318909028.24389.261470777247861682@ietfa.amsl.com> Date: Sun, 25 Nov 2018 15:38:10 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-11.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 23:38:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Mail Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-mail-11.txt Pages : 88 Date : 2018-11-25 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-11 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 25 15:41:53 2018 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 46A3A127B4C for ; Sun, 25 Nov 2018 15:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=g5x1FnVM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OC/CuYE3 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 m5k458f3etAu for ; Sun, 25 Nov 2018 15:41:50 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF408126C01 for ; Sun, 25 Nov 2018 15:41:49 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8823F202F2 for ; Sun, 25 Nov 2018 18:41:48 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 25 Nov 2018 18:41:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=M3Xovvx8FBHVpvz5iIjF1T01TBgG 64tqWntJrJ+CIKc=; b=g5x1FnVMCaZorV+9vrp6kdvEp6zUB9D26ktBSyByN6XD jdFC0sZNXgNUbJJhWMWBuQq7lT7Daq74CeBgU6X85JLBGucLWkuR3R2cQTZY8W5i VXeMRn2ucQ9u66HnJ0q4XPsRfI8h4EhccVqi2CfD1z/PFB9EL0MIIX/6FMX8jGuF 4bXr2xE9ReT38rAIJDRygC4M64LnFdVwPqLonPfyOYMHa7lt6HWvtPDrGomHLkhL EHV6gBwTup9qv6qsZI+mID2t5fVqUSRxrGaD9QDU8DzZ3eYyctnn3+ZnxyHIr3E1 YrR/urBuY8abcARcOMOtp1fKR0slWZ8+Y0Qz2r9lZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=M3Xovvx8FBHVpvz5i IjF1T01TBgG64tqWntJrJ+CIKc=; b=OC/CuYE31dD+nJuTTQ/FdP77kV9KHw+nC 57ulZsBIga0jiQi2YTo4VG6gDkZArn1Z5QL4h9R2HRXXG7vown+HuTSZH85qhs/C dxGtOUc1lcKp7fsYM6eQzZ5hxgbkkyvQeNcWSdn2flHOfaGYQdTCQbAbVNqgzkjO nGPGek6OB0+rrW2ihvDFi1Q6NTcZHpyBnYqEFbXnr96Co2+H7EZLeJcdQzjytWV1 wN7ufj50IdyHrqJEg7FDzP+AJek1aeEZzstqpCkB2B8drrLwxBkZ7jzfkWF5A9So NnkWs9XtE12baAISxZDsAKuBDobpGZuQkuVZdS4e5GEBVMY9xvPLg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1D6CE204DC; Sun, 25 Nov 2018 18:41:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 64588216 In-Reply-To: <4f74cfdc-dc4a-4b4d-b295-540893d55ccb@sloti7d1t02> References: <4f74cfdc-dc4a-4b4d-b295-540893d55ccb@sloti7d1t02> Date: Sun, 25 Nov 2018 18:41:47 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=c748716e88ff4f15be8973c4df95a7b9 Archived-At: Subject: Re: [Jmap] JMAP document status X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 23:41:51 -0000 --c748716e88ff4f15be8973c4df95a7b9 Content-Type: text/plain On Mon, 26 Nov 2018, at 10:29 AM, Bron Gondwana wrote: > Neil is working on a final round of edits based on the feedback received during last call As you will have seen on the list, I have now published v11 drafts incorporating all the feedback received during last call. Cheers, Neil. --c748716e88ff4f15be8973c4df95a7b9 Content-Type: text/html
On Mon, 26 Nov 2018, at 10:29 AM, Bron Gondwana wrote:
Neil is working on a final round of edits based on the feedback received during last call

As you will have seen on the list, I have now published v11 drafts incorporating all the feedback received during last call.

Cheers,
Neil.
--c748716e88ff4f15be8973c4df95a7b9-- From nobody Mon Nov 26 14:20:16 2018 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 8A5C613103C for ; Mon, 26 Nov 2018 14:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=lewCRkDI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r3mmgmWY 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 jALMpYubdVEC for ; Mon, 26 Nov 2018 14:20:12 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A7E130E61 for ; Mon, 26 Nov 2018 14:20:12 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7216A222AE for ; Mon, 26 Nov 2018 17:20:11 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 26 Nov 2018 17:20:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=RAi9QFSZ7SFdjPFSsN7K2GimiLvJ 23Y4PHB/SkK62d4=; b=lewCRkDIQQMlmb/ZaXS6CdGAGe8gDQc94j1UuMxhjfEb f9szAXc+h9qMHyH6SZyibZzFfaXRSwjok9dP6cRX0f68r9+emWqqxLS+RLxnmpMg qpmi+8HGKn07dOPcO4C8MuIEnumovGFzIgzlOn9mvZgoSk7KjpP9FOKJYqDwwAIF FDTcaWQ5UwLv+LQCkpBRWDM3EwUAPyEq8TlqPn5nyesP8qSXULvFiwvFHExtHPng DPgyY8fJWvaRq6/RY0PJIcrXtN1Mdm+kxJZ0xbIfjkvHS9GGFAXmzRbeRNNSzYJo K46FxSiuzrPAolfdMomWpmbqKMlamhXNKdZB6ILzcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RAi9QFSZ7SFdjPFSs N7K2GimiLvJ23Y4PHB/SkK62d4=; b=r3mmgmWYUIpb1p6oX5MDxUJ8L1DxHw1E2 yo4jLmzYZf/6a+AdT5xWHHxdTsR2+30lP0cOVjrxzItaqleew0+U9d9oAkUSsAgs Au6RjyWRSOCaQxINsSEOpw4B9qkHdtGcg4gGxdB1n3lrRrc7MaQygTLbzDOuOoEZ g6yjoM5W9wVlYNO92uaLA1UJy4i4MCwV/KT9ZRsGUNEKlUv+f5uuhh3cxI/mGgNb tGSqd1N3OYOZkV1+LIsKSrYkMQMzjBl6/OhPF2sFNQ7wmTpfgVKWAp7NQg0vkXTz 6hcDSdn88j8wrwiQHlORP677r2hy6LddU9ZQFrv1GwQ5qaFXvHAHA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AB34B204DF; Mon, 26 Nov 2018 17:20:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <4779846a-4f2f-479c-9b0a-098b6cff1f34@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-656-g84f879f-fmstable-20181126v1 X-Me-Personality: 56629417 In-Reply-To: References: <0e63904a-6c4e-42d4-a140-f1ca99bafca3@sloti7d1t02> Date: Mon, 26 Nov 2018 17:20:10 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=59ef60ca021649c0b2146b8e1b7e6891 Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-core-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 22:20:15 -0000 --59ef60ca021649c0b2146b8e1b7e6891 Content-Type: text/plain Thanks - I've read the diffs and I'm happy with all these updates. On Fri, Nov 23, 2018, at 15:03, Neil Jenkins wrote: > Thanks for the comments, I've fixed these issues. A few comments and answers: > > On Thu, 15 Nov 2018, at 4:13 PM, Bron Gondwana wrote: >> *5.3 /set* >> >> returns: created/updated/destroyed which are either an object with 1+ items or null. Why not just require an empty object consistent with /changes responses? Likewise with the "not$X". Either that or allow omitting them entirely which is the same as the default value of empty/null. > > Request and response arguments may already be omitted if the default value, and any nullable argument automatically has a default of `null`, so these arguments may be omitted. > >> *5.5 /query* >> >> What happens if you don't give a limit and don't ask for total to be calculated, but the server decides to limit the number of records returned? >> Since we now support calculateTotal, we need to double check how those two interact. > > Good catch, I've now made it so the server returns the limit if it was set or modified by the server. > >> *6. Binary Data* >> >> This is probably the most difficult part of the spec as someone used to implementing IMAP. Uploaded blobs are like temporary files. >> >>> Except where quota restrictions force early deletion, an unreferenced blob MUST NOT be deleted for at least 1 hour from the time of upload >> >> What does that even mean? > > It means clients should have a reasonable expectation that the blob will still be there if they upload it and then try to reference it within a reasonable time frame. However, the server needs to also be able to stop a malicious client from trying to bypass quota restrictions by uploading a load of unreferenced content. > > In general it's meant to work like this: > > * The server has some kind of unreferenced blob quota, let's say 250 MB. > * The maximum size message a client can send is 50 MB. > * The client uploads some blobs to be able to use them as attachments. These now count towards the unreferenced quota and will be deleted by the server after 24h (say) if still unreferenced. > * The client saves a draft referencing the blobs it has uploaded (this usually happens pretty much immediately after the upload finishes). The blobs are no longer unreferenced so they are now part of regular quota and no longer a concern. > * Rinse and repeat. > > So the only time you should get anywhere close to the unreferenced blob quota limit under normal operation would be if you had lots of parallel uploads happening and something waiting for them all to finish uploading to use, or something like that I guess. This is really just a safety net. I think the current behaviour is reasonable, but I've added the following text to remind clients that an edge case exists that they should handle: > > *Clients should use the blobId returned in a timely manner. Under rare circumstances the server may have deleted the blob before the client uses it; the client should keep a reference to the local file so it can upload it again in such a situation.* > >> Also: some advice around access control and blobs would be useful here. > > I've added: > > *As access controls are often determined by the object holding the reference to a blob, unreferenced blobs MUST only be accessible to the uploader, even in shared accounts.* > >> 7.2 Push subscriptions >> >>> If the response code is "503" (Service Unavailable), the JMAP server MAY try again later, but may also just drop the event. If the response code is "429" (Too Many Requests) the JMAP server SHOULD attempt to reduce the frequency of pushes to that URL. Any other "4xx" or "5xx" response code MUST be considered a *permanent failure* and the push subscription SHOULD be destroyed. >> >> I'd like some advice from HTTP people about whether this is the right approach. It feels like it could lead to some pretty flaky feeling push subscription loss for clients in the face of legitimate network reality between different systems. > > This was really about security concerns, so I've removed this paragraph and added a discussion in the security considerations section about the issues with connecting to unknown 3rd party servers. > > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --59ef60ca021649c0b2146b8e1b7e6891 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks - I've read the diffs and I'm happy with all t= hese updates.

On Fri, Nov 23, 2018, at 15:03, Neil Jenkin= s wrote:
= Thanks for the comments, I've fixed these issues. A few comments and ans= wers:

On Thu, 15 Nov 2018, at 4:13 PM, Bron= Gondwana wrote:
5.3 /set
=

returns: created/updated/destroyed which are either an objec= t with 1+ items or null.  Why not just require an empty object cons= istent with /changes responses?  Likewise with the "not$X".  E= ither that or allow omitting them entirely which is the same as the defa= ult value of empty/null.

Reque= st and response arguments may already be omitted if the default value, and any= nullable argument automatically has a default of null, so these arguments may be omitted.

5.5 /query

What happen= s if you don't give a limit and don't ask for total to be calculated, bu= t the server decides to limit the number of records returned?
<= div style=3D"font-family:Arial;">Since we now support calculateTotal, we= need to double check how those two interact.

Good catch, I've now made it so the server returns the l= imit if it was set or modified by the server.

6. Binary Data

This is pr= obably the most difficult part of the spec as someone used to implementi= ng IMAP.  Uploaded blobs are like temporary files.

Exce=
pt where quota restrictions force early deletion, an
unreferenced blob MUST NOT be deleted for at least 1 hour from the
time of upload
<= br>
What does that even mean?
=

It means clients should have a re= asonable expectation that the blob will still be there if they upload it= and then try to reference it within a reasonable time frame. However, t= he server needs to also be able to stop a malicious client from trying t= o bypass quota restrictions by uploading a load of unreferenced content.=

In general it's meant to work like this:

  • The server has some kind of unreferenced = blob quota, let's say 250 MB.
  • The maximum size message a cli= ent can send is 50 MB.
  • The client uploads some blobs to be a= ble to use them as attachments. These now count towards the unreferenced= quota and will be deleted by the server after 24h (say) if still unrefe= renced.
  • The client saves a draft referencing the blobs it ha= s uploaded (this usually happens pretty much immediately after the uploa= d finishes). The blobs are no longer unreferenced so they are now part o= f regular quota and no longer a concern.
  • Rinse and repeat.

So the only time you should get anywhere= close to the unreferenced blob quota limit under normal operation would= be if you had lots of parallel uploads happening and something waiting = for them all to finish uploading to use, or something like that I guess.= This is really just a safety net. I think the current behaviour is reas= onable, but I've added the following text to remind clients that an edge= case exists that they should handle:

Cl= ients should use the blobId returned in a timely manner. Under rare circ= umstances the server may have deleted the blob before the client uses it= ; the client should keep a reference to the local file so it can upload = it again in such a situation.

Also: some advice around access control and blobs would be = useful here. 

I've added= :

As access controls are often determine= d by the object holding the reference to a blob, unreferenced blobs MUST= only be accessible to the uploader, even in shared accounts.

7.2 Push subscriptions
<= /div>

If the response code is "503" (Service Unavailable), the JMAP se=
rver
MAY try again later, but may also just drop the event.  If the
response code is "429" (Too Many Requests) the JMAP server SHOULD
attempt to reduce the frequency of pushes to that URL.  Any other
"4xx" or "5xx" response code MUST be considered a *permanent failure*
and the push subscription SHOULD be destroyed.

I'd like some advice from HTTP people about whether this is the right= approach.  It feels like it could lead to some pretty flaky feelin= g push subscription loss for clients in the face of legitimate network r= eality between different systems.

<= div>This was really about security concerns, so I've removed this paragr= aph and added a discussion in the security considerations section about = the issues with connecting to unknown 3rd party servers.
<= br>
Neil.
______________________________________= _________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

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

--59ef60ca021649c0b2146b8e1b7e6891-- From nobody Mon Nov 26 14:26:22 2018 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 B50B413103C for ; Mon, 26 Nov 2018 14:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=zp8dLBsZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TNY3im6O 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 aIocHRUxiKyD for ; Mon, 26 Nov 2018 14:26:18 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4877130DFC for ; Mon, 26 Nov 2018 14:26:17 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E3CEA223C7 for ; Mon, 26 Nov 2018 17:26:16 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 26 Nov 2018 17:26:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=Eds8BLj2i6u1pUOCn5UXhAXZFu+3 Jwdf9eNuRfYJqPo=; b=zp8dLBsZk4sBYpQh+c7R+XycHTZL1rq7/9CbOxYCRdmK wUOTf6hkeDT2l5zyRWYlYE8Osc9cbpNaKV5q4fv/dMevBYgzq0B0K/xlYjRvceN8 DmNRxtGTyQ0K7PCRPR3LxgriINqCbG3FZGrk+EEC87FklohD3yqq82JJ8HIwg+hV ahTZ6mS1obdOzvDC41XMoEO8rAnY6rIUL114rMgUiYgdoBV/MTPceIjNGsQuPLhM 78U3Xx5YEe41Y0jmJ4rtAS1bC64YSkTlauIkVSoU4iQcXxVJscIDkQAycjTRI4ED 8jddS0/oR23G9dUbrwN7rAATBnCo7NVo2fZ9b0QQ7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Eds8BLj2i6u1pUOCn 5UXhAXZFu+3Jwdf9eNuRfYJqPo=; b=TNY3im6OEyoUEDMU4P1kn1cF+2m5FVv4K zJzrrYvSBVb3W9/x1U8RHAA1ImALRcq+9A9OxQgVpxYyZ0jcffGo7FQhgtqfc5XM 4D+HHISZx2QxDuJ+y7+ocotF3bslKf8Kv9SqLLJ0qRDbgPZkP/oMObyPlf/rWu4G MWvhfWiUdNXykJIUfZht2Bba7WgTkXg11vsnGcGXUsy190ZafZhPTXp5Buz72/Hg aI+Yp46Y1gSDnAzOt6N/xUvW73ZMF8cQpJVLKb0KPT7ROzacaWc15uLJJrhyIAaK 3q0I3BydtGiyRo9G0jdxg8WwR+aJghxI6muXyh4Vb/hV2YfLuZQeQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 46336204DF; Mon, 26 Nov 2018 17:26:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-656-g84f879f-fmstable-20181126v1 X-Me-Personality: 56629417 In-Reply-To: References: Date: Mon, 26 Nov 2018 17:26:15 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=7afdbc1594c94db4b8fca384758ee0c4 Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mail-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 22:26:20 -0000 --7afdbc1594c94db4b8fca384758ee0c4 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 23, 2018, at 15:58, Neil Jenkins wrote:=20 > On Thu, 15 Nov 2018, at 5:46 PM, Bron Gondwana wrote:=20 >> *1.3.1 **urn:ietf:params:jmap:mail* >> maxMailboxDepth - do you mean "one more than the maximum number of an= cestors"? Aka, "1" means no tree, all toplevel. > =20 > Yes, good catch.=20 > =20 >> *1.3.2 **urn:ietf:params:jmap:submission** *=20 >> =20 >>> By default, the JMAP server should show only known safe- to-expose EHLO capabilities in this field, and hide EHLO capabilities that are only relevant to the JMAP server. >> =20 >> What does this actually mean? I find this sentence confusing about re= levance.=20 > =20 > I've changed it to: *By default, the JMAP server should hide EHLO capa= bilities that are to do with the transport mechanism and thus are only r= elevant to the JMAP server (for example PIPELINING, *CHUNKING, *or START= TLS).*=20 > =20 > Is that clear?=20 =20 Yep, that's good.=20 =20 > =20 >> *1.5 Push*=20 >> =20 >>> In addition, servers MUST support a psuedo-type called "EmailDelivery" in the push mechanisms. The state string for this MUST change whenever a new Email is added to the store, but SHOULD NOT change upon any other change to the Email objects. >> =20 >> Is that really something that should be a MUST? I guess it can just b= e a copy of "Email" if you can't tell if something was a new message.=20= > =20 > Yes, this is trivial and spec compliant, and will result in correct cl= ient behaviour at the expense of some efficiency. I think therefore it's= better to make it a MUST than to force the client to have two pathways = to handle whether it's there or not.=20 =20 Makes sense.=20 =20 >> *2. Mailbox*=20 >> =20 >> This should probably cross-reference RFC8474 OBJECTID at least as an = informative reference.=20 > =20 > I've added an *Ids* subsection to the intro and written this:=20 > =20 > *If a JMAP Mail server also provides an IMAP interface to the data and= supports [@!RFC8474] IMAP Extension for Object Identifiers, the ids SHO= ULD be the same for mailbox, thread, and email objects in JMAP.***=20 > =20 > Is that what you were looking for, or something more?=20 =20 That's fine - just a cross reference to make people aware that it exists= and should be congruent.=20 =20 >> *3.. Mailbox/set*=20 >> Do we also want an onDestroyRemoveChildren argument to match onDestro= yRemoveMessages?=20 > =20 > I would say no. It's much easier for the client to explicitly destroy = the children mailboxes than the children messages, and we'd have to be c= areful about the interaction of this with rate limits, with destroying m= essages inside the child folders and the ordering and locking that might= involve, etc. I think it would add quite a bit of complexity for not a = lot of gain.=20 =20 Ok, fair.=20 =20 >> *4.1.4 Body parts*=20 >> *preview*: see the discussion in extra@ietf.org about IMAP previews a= nd making them consistent. I can see an argument for making the size of = this be in characters rather than octets. I do feel strongly that we sho= uld make the limits exactly consistent between JMAP and IMAP, since we h= ave that opportunity right now.=20 > =20 > I agree; I'm not sure if we have a final conclusion there, but when we= do I'll make sure this is the same.=20 =20 This is the one thing which is maybe blocking us right now in terms of c= onsistency...=20 =20 >> *4.2 Email/get*=20 >> =20 >>> Where a specific header is requested as a property, the capitalization of the property name in the response MUST be identical to that used in the request. >> =20 >> Does this mean that a request for "From:asRaw" and "from:asRaw" retur= ns both of them separately?=20 > =20 > Yes, although that wouldn't be a very useful request to make.=20 > =20 >> *7. Email submission*=20 >> =20 >> Why does this include threadId =E2=80=A6 Ahh yeah, handy for filterin= g I guess...=20 > =20 > Exactly.=20 > =20 >> *7.5 EmailSubmission/set*=20 >> Given that we're updating Emails with side effect subrequests from th= is, should there be a way to latch this against the Email state? ifInEma= ilState or something?=20 > =20 > I don't think this is needed. It's only operating on immutable propert= ies of the email so it's of limited utility, and would add considerable = complexity again.=20 =20 So the main question is whether the email still exists, or whether it's = still in the same folder.=20 =20 AKA: can we guarantee to avoid duplicate sending?=20 =20 I guess you can use EmailSubmission state to make sure that multiple sub= missions don't happen concurrently somehow.=20 =20 Bron.=20 =20 --=20 Bron Gondwana, CEO, FastMail Pty Ltd=20 brong@fastmailteam.com=20 =20 =20 --7afdbc1594c94db4b8fca384758ee0c4 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 23, 2018, at 15:58, Neil Jenkins wrote:
On Thu, 15= Nov 2018, at 5:46 PM, Bron Gondwana wrote:
1.3.1 urn:ietf:params:jmap:mail=

maxMailboxDepth - do you mean "one more than t=
he maximum number of ancestors"?  Aka, "1" means no tree, all toplevel.<=
br>

Yes, good catch.

1.3.2 urn:ietf:params:jmap:submission 

By default, the JMAP server should show only kn=
own safe-
to-expose EHLO capabilities in this field, and hide EHLO
capabilities that are only relevant to the JMAP server.

What does this actually mean?  I find this sentence con= fusing about relevance.

I've c= hanged it to: By default, the JMAP server should hide EHLO capab= ilities that are to do with the transport mechanism and thus are only re= levant to the JMAP server (for example PIPELINING, CHUNKING, or STARTTLS).

Is that clear?
=

Yep, that's good.

=
1.5 Push

In addi=
tion, servers MUST support a psuedo-type called
"EmailDelivery" in the push mechanisms.  The state string for this
MUST change whenever a new Email is added to the store, but SHOULD
NOT change upon any other change to the Email objects.

Is that really something that should be a MUST?  I guess= it can just be a copy of "Email" if you can't tell if something was a n= ew message.

Yes, this is trivi= al and spec compliant, and will result in correct client behaviour at th= e expense of some efficiency. I think therefore it's better to make it a= MUST than to force the client to have two pathways to handle whether it= 's there or not.

Makes sense.

2. Mailbox

This should probably cross-reference RFC8474 OBJECTID at least as an i= nformative reference.

I've add= ed an Ids subsection to the intro and written this:

If a JMAP Mail server also provides an IMAP interface= to the data and supports [@!RFC8474] IMAP Extension for Object Identifi= ers, the ids SHOULD be the same for mailbox, thread, and email objects i= n JMAP.

Is that what you were lo= oking for, or something more?

That's fine - = just a cross reference to make people aware that it exists and should be= congruent.

= 3.. Mailbox/set
Do we als= o want an onDestroyRemoveChildren argument to match onDestroyRemoveMessa= ges?

I would say no. It's much= easier for the client to explicitly destroy the children mailboxes than= the children messages, and we'd have to be careful about the interactio= n of this with rate limits, with destroying messages inside the child fo= lders and the ordering and locking that might involve, etc. I think it w= ould add quite a bit of complexity for not a lot of gain.

Ok, fair.

<= /div>
4.1.4 Body parts
*preview*: see the discussion in e= xtra@ietf.org about IMAP previews and making them consistent. I can= see an argument for making the size of this be in characters rather tha= n octets.  I do feel strongly that we should make the limits exactl= y consistent between JMAP and IMAP, since we have that opportunity right= now.

I agree; I'm not sure if= we have a final conclusion there, but when we do I'll make sure this is= the same.

<= /div>
This is the one thing which is ma= ybe blocking us right now in terms of consistency...

4.2 Email/get

W=
here a specific header is requested as a property, the
capitalization of the property name in the response MUST be identical
to that used in the request.

Does this mean = that a request for "From:asRaw" and "from:asRaw" returns both of them se= parately?

Yes, although that w= ouldn't be a very useful request to make.

7. Email submission

Why does this include thr= eadId  =E2=80=A6  Ahh yeah, handy for filtering I guess...
=

Exactly.

=
<= div id=3D"fastmail-quoted-fastmail-quoted-sig56629417">
7.5 EmailSubmission/set
Given that we're updating Emails with side effect sub= requests from this, should there be a way to latch this against the Emai= l state? ifInEmailState or something?
<= br>
I don't think this is needed. It's only operating on immut= able properties of the email so it's of limited utility, and would add c= onsiderable complexity again.

So the main qu= estion is whether the email still exists, or whether it's still in the s= ame folder.

AKA: can we guarantee to avoid duplicate send= ing?

I guess you can use EmailSubmission state to make su= re that multiple submissions don't happen concurrently somehow.

Bron.

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


<= /html> --7afdbc1594c94db4b8fca384758ee0c4-- From nobody Mon Nov 26 14:29:39 2018 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 C494013105D for ; Mon, 26 Nov 2018 14:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STYLE_GIBBERISH=1.453] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KNSx6+G4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aXv+VjcX 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 xPfngypCxyRv for ; Mon, 26 Nov 2018 14:29:36 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0AB130DFC for ; Mon, 26 Nov 2018 14:29:36 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DABCE6E8 for ; Mon, 26 Nov 2018 17:29:35 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 26 Nov 2018 17:29:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=dnRSpiChtD6qSydO0ukiKeAiCD1m 7lQx3dnjO5lnZCo=; b=KNSx6+G4ddZn0yMQikd7hlcM7uxpdaDlJHnSIZWDKfgU iy4BBA/0YtsEvTgu8DAm66dTBM/bAynyHbHYEnXG+54cauXGkGA2v7M8q7uxDySu p+qWWcy/ZgE60wo2MIY8qhOST+T944TiY1tAXotX7y8ayMx5uDL42xS6NSP3r+Hy 9emTK0kxCNFuvojidRU2hyYjEiAX7RtNnT93DwpvRkUiXEUlKhCeEyQQnKOW0KlA yxCYX2pvnEeMaiWD2wztJXeCP3NPC4gsibtXQyib0yHu5e5gg4hOAXiSAJAkG+Q7 YIAxmFo5zduf9F6VaHJGvXzvRIkmch33hY6q8N9Nug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dnRSpiChtD6qSydO0 ukiKeAiCD1m7lQx3dnjO5lnZCo=; b=aXv+VjcXYMbiAaAlBh1DXoS2R2d4U1pzz 8Yo2pko1fQaEKjPJIgN9BAfK9IxaB7wukM/7sKoyFz+VucPimwQRaMDYWBC66MPI 3Bt4w4llb2014HiT3kNayaLmKBac0HzbRjLMvr0AWtsy70UI5YN7LD2aN73/HJG8 YVhwWhSbCkcbPRIGPlCH6tcYet873TFo3+nU3zeW9T4xiAlQBFA8xSY7FaHb1a6h JBCl/g0BLb4iULfsgLtg+HbvRn1VWU2C3Mn5Ljw/Rr7GbTGt1MegL8t6KVcEmlMu PYUGwRPX1xnd+b8R4k8gAjUVARBwJpxP2j7UZNaCk8hMP1ApVT0Lg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E7879204DF; Mon, 26 Nov 2018 17:29:34 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: User-Agent: Cyrus-JMAP/3.1.5-656-g84f879f-fmstable-20181126v1 X-Me-Personality: 64588216 In-Reply-To: References: Date: Mon, 26 Nov 2018 17:29:34 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=b492dec416b4439ca4e711c46c3c4459 Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mail-10 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 22:29:38 -0000 --b492dec416b4439ca4e711c46c3c4459 Content-Type: text/plain On Tue, 27 Nov 2018, at 9:26 AM, Bron Gondwana wrote: >>> *7.5 EmailSubmission/set* >>> Given that we're updating Emails with side effect subrequests from this, should there be a way to latch this against the Email state? ifInEmailState or something? >> >> I don't think this is needed. It's only operating on immutable properties of the email so it's of limited utility, and would add considerable complexity again. > > So the main question is whether the email still exists, or whether it's still in the same folder. > > AKA: can we guarantee to avoid duplicate sending? The EmailSubmission type's state is what you would use to prevent duplicate sending, so I still don't think we need a separate ifInEmailState. Neil. --b492dec416b4439ca4e711c46c3c4459 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 27= Nov 2018, at 9:26 AM, Bron Gondwana wrote:
7.5= EmailSubmission/set
Give= n that we're updating Emails with side effect subrequests from this, sho= uld there be a way to latch this against the Email state? ifInEmailState= or something?

I don't t= hink this is needed. It's only operating on immutable properties of the = email so it's of limited utility, and would add considerable complexity = again.

So the main question is whether the e= mail still exists, or whether it's still in the same folder.

AKA: can we guarantee to avoid duplicate sending?

The EmailSubmission type's state is what you wou= ld use to prevent duplicate sending, so I still don't think we need a se= parate ifInEmailState.

Neil.
--b492dec416b4439ca4e711c46c3c4459-- From nobody Fri Nov 30 01:02:52 2018 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 CE3A012F18C for ; Fri, 30 Nov 2018 01:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=SV3DLwSs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VMI4BcdP 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 EoVfP6wSrMqE for ; Fri, 30 Nov 2018 01:02:43 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943A6130DCC for ; Fri, 30 Nov 2018 01:02:43 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BCB2123180; Fri, 30 Nov 2018 04:02:42 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 30 Nov 2018 04:02:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=x5W5VKNOFAaST9jpm0U+GOVjJ v3Fy0fUEoL/dZRrP8k=; b=SV3DLwSsOHtr9pQMfGdJP+rRhirbyW+CEijRmuopw eldInzsbVl1yIubQxJznHDkQy2++PnlWUn/e3L29dSztbhV1LRta4KObe54z+fdl B1Qn71Kk04Xt1tZD3gJHO2ep2sshpsygE1T6nmAhQb7aXPSWdRT9JcQ3IE3+pYID tzqDfvHNNjsKgnSRed/3Xu7oqubv8BJ1C4olY9RCIQkjnJD3s9OlwfY8z+qbAgnH 7QQrKHyPY+j11m9FIfGo9hW3u2LeW2vP6RjZDgO1Pa32UathGFHe3ZlID+0bmiPU K3PQ5EJwNQMvu0LgJ06huqxPoovNqjtYCu8gfKFuzCZrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=x5W5VKNOFAaST9jpm 0U+GOVjJv3Fy0fUEoL/dZRrP8k=; b=VMI4BcdPig0nqkj3qRQ0+eE6OyRtju/Fh EEO3H6Ea6dBNFxFdEdAjxIAQL+9K/sI4ggOzIoKQdq9P8GTjbmkQIpWDXpoFpid8 AO3fCMLCYMFis7sN8RZSTHtZy8H7QfIkh3l5IfDuQsnadRlHX0vtLaCO4YEGUh+t AnPghopVFA/fovKjagLoFvkPHaY8W482dWe6hq1r6DmLcoWYhmq/3mv5KzlvXqAK bKnhy9+1ZADBicRmwHpR0Lr7hpKFFxauC855QhL0U3AYLUA48H/MfwQzmU45aANZ pYuLyb3NaEN3iV24b3FL2Ppm0iUY2aEBn74du8PHSoBKrYJSEnhxw== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F311E20322; Fri, 30 Nov 2018 04:02:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <48fc1d7e-ab93-4af8-a672-36876979fbd5@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-656-g84f879f-fmstable-20181126v1 X-Me-Personality: 64588216 In-Reply-To: References: <265ec3f1-75b8-43e3-8c52-276b6f6077c6@sloti7d1t02> Date: Fri, 30 Nov 2018 04:02:30 -0500 From: "Neil Jenkins" To: "Ken Murchison" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=ff25edfdb0574acaba77a8c062ffbb62 Archived-At: Subject: Re: [Jmap] draft-murchison-jmap-websocket as a JMAP working product X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 09:02:51 -0000 --ff25edfdb0574acaba77a8c062ffbb62 Content-Type: text/plain On Fri, 23 Nov 2018, at 11:38 PM, Ken Murchison wrote: > Se already have @type in the problem details object returned for a request level error. Can't the client simply check the response object for "methodResponses" , or "changed", or "type"? Otherwise, perhaps "responseType". There's a `type` property on the problem details object but not an `@type` property. This object would also need an `@type` property with a value probably of `"error"` (or maybe `"RequestError"` would be better actually). The client can then simply look at this property on the object it receives to know what type of object it is and how to dispatch it. That's simpler and cleaner than looking for certain properties which should be on one type of object but not another (which you could easily screw up in the future by adding an extra property with a common name). >>> o Should we allow out of order processing of requests? >> >> Again the consensus was "yes"; you can use a single WebSocket connection as the equivalent to parallel HTTP API requests. This means we also need an `id` property on Request and Response objects so they can be correlated by the client. > Should we make this "requestId" to be a little more descriptive? Or perhaps steal "tag" from IMAP? We could, but in general with JMAP if a property is an id of the object it is on, that property is always just called "id". If it's a reference to an id of another object, then it gets prefixed with a description of what's being referenced. So I think `id` is probably more consistent on the `Request` object, but maybe name it `requestId` on the `Response` object to show that is what it is referencing. > Is "clientId" in the request not sufficient for correlation? Yes, except what if the Request object returns a `RequestError` problem details object (as discussed above)? We need to know which request generated the error, so I think need to have a matching `requestId` property on this object. > Do we push ALL notifications or do we allow the client to subscribe to notifications for certain object types? We should allow clients to choose what types they want push notifications for, like we do with the other two push mechanisms. I guess we define an API method to configure this that affects the push channel it's sent down. Neil. --ff25edfdb0574acaba77a8c062ffbb62 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, 23= Nov 2018, at 11:38 PM, Ken Murchison wrote:

Se already have @type in the prob= lem details object returned for a request level error.  Can't the client simply check the res= ponse object for "methodResponses" , or "changed", or "type"?  Otherwise, perhaps "responseType".

<= br>
There's a type property on the problem details = object but not an @type property. This object would also need= an @type property with a value probably of "error" (or mayb= e "RequestError" would be better actually). The client can then si= mply look at this property on the object it receives to know what type o= f object it is and how to dispatch it. That's simpler and cleaner than l= ooking for certain properties which should be on one type of object but = not another (which you could easily screw up in the future by adding an = extra property with a common name).

<= /div>
   o  Should we allow out of = order processing of requests?

=
Again the consensus was "yes"; you can use a single WebSocket= connection as the equivalent to parallel HTTP API requests. This= means we also need an id property on Request and Response objects so they can be correlated by the= client.

Should we make this "requestId"= to be a little more descriptive?  Or perhaps steal "tag" from IMAP?


We could, but in general with JMAP if a property is an id of the= object it is on, that property is always just called "id". If it's a re= ference to an id of another object, then it gets prefixed with a descrip= tion of what's being referenced. So I think id is probably more co= nsistent on the Request object, but maybe name it requestId = on the Response object to show that is what it is referencing.
=

Is "clientId" = in the request not sufficient for correlation?

Yes, except what if the Request object returns a Request= Error problem details object (as discussed above)? We need to kno= w which request generated the error, so I think need to have a matching = r= equestId property on this object.

Do we push ALL notifications or do we allow the = client to subscribe to notifications for certain object types?

We should allow clients to choose what type= s they want push notifications for, like we do with the other two push m= echanisms. I guess we define an API method to configure this that affect= s the push channel it's sent down.

Neil. --ff25edfdb0574acaba77a8c062ffbb62--