From nobody Fri Jun 1 07:22:12 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 401D812D875; Fri, 1 Jun 2018 07:22:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, jmap-chairs@ietf.org, barryleiba@gmail.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152786293019.15304.18262427954502104284.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2018 07:22:10 -0700 Archived-At: Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 102 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 14:22:11 -0000 An update to a meeting session request has just been submitted by Barry Leiba, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: extra dispatch uta artarea dmarc iasa2 saag oauth dcrup doh Second Priority: tls httpbis ace lamps core t2trg People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Special Requests: Neil Jenkins will present remotely from Australia. 4pm Montreal = 6am Australia, so please no earlier than that! Also not Thursday or Friday; in particular, one chair will be missing on Friday. --------------------------------------------------------- From nobody Thu Jun 7 17:34:33 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 EA6D0130FFC for ; Thu, 7 Jun 2018 17:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikNKESopVKvG for ; Thu, 7 Jun 2018 17:34:24 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 3CA78130FCF for ; Thu, 7 Jun 2018 17:34:24 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w580QWdY184128; Fri, 8 Jun 2018 00:34:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=N5BZ+nhmF8URk2gbB6dBNqc+Zu43ardoXh9uKtsN3Xw=; b=mziw6JQi4dc61lUBZPpFzBAO0o3dORw615/HVQwJe80Vf9foRp235R74cJdzVNLIi1RW FQolHLhevgnWydFAQuFhMgQMiBEke2Y/ttreXwhyvidxZ+LAZS8QTEtGRlFhH4ewbgor KExFC4d1uEl5Kgn7wERAHp5s/AUhdBzR1Pui3htddGuPwC5CKGB+R7ITQj30/8GoUfCj NZeLxXR6w+risQwHhHtrQwZxE34HtBaVnKhr7NyhSEfn4KZJ4+70AK2A4h81pmVmKum3 eIdU7UJaEyfixKHSUPkYUI9yYjqkXyFHxRimcNyJ+SENydEPARR0g8RI2XVASsy7aghm Mg== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2jbvyptyw6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Jun 2018 00:34:19 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w580YJGn006388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 8 Jun 2018 00:34:19 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w580YIVF028262; Fri, 8 Jun 2018 00:34:18 GMT Received: from [172.31.99.199] (/47.51.42.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Jun 2018 17:34:18 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: jmap@ietf.org Date: Thu, 07 Jun 2018 17:34:17 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <087AC92D-E44B-46FF-BFF1-CE735FC50A9F@oracle.com> In-Reply-To: <1527744396.19460.1391345832.3A4034F6@webmail.messagingengine.com> References: <1527744396.19460.1391345832.3A4034F6@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8917 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806080003 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 00:34:31 -0000 On 30 May 2018, at 22:26, Bron Gondwana wrote: > On Thu, May 31, 2018, at 13:46, Neil Jhaveri wrote: >> Hi all, >> >> Here are some comments from my latest reading of = >> draft-ietf-jmap-core- >> 05. Apologies if I=E2=80=99m revisiting anything already discussed! > (FYI Neil is on leave for a bit) > >> *Questions / Needs Discussion* >> ** >> >>> 3.2.1. Example request >>> { >>> "using": [ "*urn:ietf:params:jmap:core*", >>> "urn:ietf:params:jmap:mail" ],> Can the JMAP Core capability just = >>> be assumed? Any good reasons to >> actually have this listed out? > This seems reasonable to me - you can't do JMAP without core. I lean slightly towards keeping the ":core" explicit. If you make = incompatible changes to the core in the future, it's much cleaner to add = a urn:ietf:params:jmap:core2 and then advertise one or both depending on = whether the implementation is backwards compatible with the original = core. I note we're about to do something like this with IMAP4rev2 so = this is not theoretical. - Chris >>> 4.2. /changes >>> =E2=80=A6 >>> o *changed*: "String[]" An array of ids for records which have >>> been>> *created or modified* but not destroyed since the = >>> oldState. >> >> Could =E2=80=9Ccreations=E2=80=9D and =E2=80=9Cmodifications=E2=80=9D = be separated into = >> separate array >> properties? A common resynchronization case is a small number of >> creations, without any modifications, and it may be more efficient = >> for >> some clients to process creations than modifications. > I'm OK with this so long as if the server can't tell, it's allowed to > put things into modified even if they're new. >> For instance, an iOS app using Core Data could then create new >> objects and immediately save them off, rather than having to first do >> an initial fetch to see if it already has an existing record with >> that ID.> >> By comparison to IMAP + CONDSTORE, I think you can infer if something >> is created vs. modified if a fetch response's UID is greater than = >> your >> last-cached UIDNEXT. Since IDs in JMAP seem to be opaque, it might be >> nice to do this separation to afford this possibility again.> >> >>> 4.2. /changes >>> ... >>> >>> o *newState*: "String" This is the state the client will be in >>> after applying the set of changes to the old state.> If an = >>> offline client is resynchronizing after being disconnected and >> there are a lot of changes, the way that /changes is set up seems to >> imply that if the changes don=E2=80=99t all fit in 1 response, the seq= uence = >> of >> responses will be ordered oldest-to-newest. Is that true? > This isn't enforced. Good point. > >> If so, and assuming most clients are fairly naive and just = >> immediately >> dispatch /get=E2=80=99s on IDs that they retrieve (perhaps by = >> back-reference), >> that isn=E2=80=99t ideal for a UI that shows objects in newest-to-olde= st >> order, potentially resulting in a user experience of =E2=80=9Chere are= new >> objects from 5 days ago=E2=80=9D, followed by =E2=80=9Chere are new ob= jects from = >> 4 >> days ago=E2=80=9D, and so on. When really, the user ideally would pref= er to >> see =E2=80=9Chere are objects from right now=E2=80=9D as the first scr= een update = >> =E2=80=94 at >> least for e-mail, I think this is the case.> >> Have we had any discussion around handling pages of changes in a >> different way? For instance, the Gmail API[1] has a Users.history : >> list resource, which takes a =E2=80=9CstartHistoryId=E2=80=9D as well = as a >> =E2=80=9CpageToken=E2=80=9D. The response includes a =E2=80=9CnextPage= Token=E2=80=9D, or null = >> if there >> are no additional pages. Clients only update their local = >> =E2=80=9ChistoryId=E2=80=9D >> after fetching all pages.> >> (This admittedly comes at the trade-off of a client not being able to >> checkpoint any changed-ID ingestion until it is fully caught up with >> all changed IDs).> >> A client could do a /query to get the absolute most recent page of >> items, merge that into it=E2=80=99s cache, and then handle /changes = >> normally >> in order, but this seems a little less efficient. > Yeah, it's a bit tricky. Do you have a proposal that would be sane? > >> >>> 4.3. /set >> >>> A *SetError* object has the following properties: >>> ... >>> o *description*: "String|null" A description of the error *to >>> display **to the user*.> Presumably, this error is not localized. = >>> The recommendation to display >> it to the user is not consistent with the document's earlier >> recommendation in 3.6.2. Method-level errors: "A =E2=80=98description'= >> property MAY be present to help debug with an explanation of what the >> problem was. This is a non-localised string, and is not intended to >> be shown directly to end users."> >> Should the same suggestion be made here? >> >> >>> 4.4. /query >>> ... >>> *anchorOffset*: "Number|null" The index of the anchor object = >>> relative >>> to the index of the first result to return. This MAY be negative. >>> For example, "-1" means the first Foo after the anchor Foo should be >>> the first result in the results returned (see below for more >>> details).> FWIW, when reading this, I also made the same scribble = >>> note that >> Matthew H. did almost 3 months ago =E2=80=94 that the anchorOffset see= med >> flipped from what my brain was expecting, and I was confused for a = >> bit >> about why it was negative instead of positive. Re-reading it and the >> previous thread, I get it, and either way is fine since it is just >> stylistic, but I will cast my vote in favor of flipping anchorOffset. > Suits me fine. I think we have a majority for flipping. > >> >>> >>> >>> 4.5. /queryChanges >>> ... >>> The response has the following arguments: >>> ... >>> o *removed*: >>> o *added* >> Is there a reason why there is no modified property? For instance, = >> how >> would a primarily-online mail client realize that certain threads >> became flagged, unread, etc., aside from re-get'ing everything in the >> query window after handling the adds/deletes? > Modified is a property of the item, not the list. So you use /changes > to find items which have changed and /queryChanges to see what's added > to or removed to the list. > If you have all data locally and are sorting locally, you don't need = > to > use query or queryChanges at all. >> >>> 5. Binary data >>> ... >>> A blob that is not referenced by a JMAP object (e.g. as a message >>> attachment), MAY be deleted by the server to free up resources.>> = >>> =E2=80=A6 >>> o Except where quota restrictions force early deletion, an >>> unreferenced blob SHOULD NOT be deleted for at least 24h from the >>> time of upload; if reuploaded, the same blobId MAY be returned, >>> but this SHOULD reset the expiry time.> The way I=E2=80=99m = >>> understanding this garbage-collection policy, it could be >> alarming to a user if they try to delete some blob data they >> accidentally put on the server, but it=E2=80=99s still possible to acc= ess = >> it >> even after deletion because it=E2=80=99s just unreferenced. There is a= = >> trade- >> off between being able to save users when they accidentally delete >> important data, and a user being able to actually delete data = >> they=E2=80=99re >> trying to delete, but I think those sort of data-recovery policies >> should not be totally opaque to JMAP.> >> What would you all think about being a little more explicit here? >> Perhaps defining a =E2=80=9CMUST=E2=80=9D-conformance expiration time = in the spec = >> (N >> minutes)? (The current policy saying SHOULD NOT delete for 24h seems >> excessively generous for API clients to me?) > It sounds like maybe what you want is a deleteBlob operation to clean = > up > unreferenced blobs? >> >> >>> 6.2.1. PushSubscription/set >>> Each *session* may only have a single push subscription registered. >> Can somebody clarify what is meant by session here? Is this meant to >> be a single =E2=80=9Caccount=E2=80=9D?> >> >> *Grammatical Nit-picks* >> ** >> >>> 1.1 Notational Conventions >>> =E2=80=A6 >>> *Types* signatures are given for all JSON objects in this document. >> Should this be =E2=80=9CType=E2=80=9D, rather than =E2=80=9CTypes=E2=80= =9D? >> >> >>> 2. The JMAP Session resource >>> To communicate with a JMAP *server you* need two things to start: >> Is a comma needed between =E2=80=9Cserver=E2=80=9D and =E2=80=9Cyou=E2= =80=9D? >> >>> 5. Binary data >>> ... >>> A blob that is not referenced by a JMAP object (e.g. as a message >>> *attachment), MAY* be deleted by the server to free up resources.> I = >>> think the comma before =E2=80=9CMAY=E2=80=9D is not needed. >> >>> 6.1. The StateChange object >>> o *trigger*: "String" What caused this change. The following >>> causes are defined:>> * "delivery": The arrival of a new = >>> message caused the change.> >> Since JMAP is intended to be the foundation of data types beyond = >> Mail, >> perhaps this should say something besides =E2=80=9Cnew message=E2=80=9D= =E2=80=94 maybe = >> =E2=80=9CThe >> cause of the change is delivery from an external system or user=E2=80=9D= =2E> >> >> *Formatting nit-picks* >> PDF version - page 19 is very small (list of IDs doesn=E2=80=99t wrap)= =2E >> >> - Neil >> >> >> _________________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_jmap&d=3DDwIFaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DtF2smCiqvAjqML7= 2IJKlObw87fo9maXqqizombif_c0&s=3DvDk2QMImzzVf1zaS7iK6jI823oNgxqVb_AgiPzIr= ca8&e=3D > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > Links: > > 1. = > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__developers.googl= e.com_gmail_api_v1_reference_users_history_list&d=3DDwIFaQ&c=3DRoP1YumCXC= gaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2O= OJG3TXfI&m=3DtF2smCiqvAjqML72IJKlObw87fo9maXqqizombif_c0&s=3Dr_HfwTCBhtQH= H4oKJajNaR-6KFMdr1HolfIvyqt7CBA&e=3D > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_jmap&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DtF2smCiqvAjqML72= IJKlObw87fo9maXqqizombif_c0&s=3DvDk2QMImzzVf1zaS7iK6jI823oNgxqVb_AgiPzIrc= a8&e=3D From nobody Fri Jun 8 16:16:59 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 26F58130DD1 for ; Fri, 8 Jun 2018 16:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=VTheR63E; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PQc7Zolq 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 22KjIDnhi7Jz for ; Fri, 8 Jun 2018 16:16:53 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60C1130DC1 for ; Fri, 8 Jun 2018 16:16:53 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2A28E214D6 for ; Fri, 8 Jun 2018 19:16:53 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute6.internal (MEProxy); Fri, 08 Jun 2018 19:16:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=cj5tGN67cF6uSZhtPGvjQIEu60XNG8Yr+c8c6OktA iY=; b=VTheR63EbMDuQYYGjV8jpIDM9Lxv5rLOVMlwgSpqyEdtvknmyRReFMJdI iW7mOnXCdGkHS505To+3Ycui9mlvE9VHiSmowxcWCeB8nx1nO012gnXqqnf4qt1P K+yWPDLFvTp9Q+W0qKwGfBkFpKc7EPx4R4EIQSzmRdbgmqE2DZx3Sz66Jes8dRx/ Z7NjZmKJANdpInorfQLoR3Zbh6kD0CzI/0opxXd9XMFyU7GsUFAirAOq/7MFZiMA l+Y5yno7JAviN5APtB8dW9L1kP9gX6mLl9JYdFc8VGw9jMIYwoSOWOmWaMLbOmJx zYZLJn0ttp4NA3sJFuTg/ERZVqj0Q== 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-sender:x-me-sender :x-sasl-enc; s=fm2; bh=cj5tGN67cF6uSZhtPGvjQIEu60XNG8Yr+c8c6OktA iY=; b=PQc7ZolqPklYGjEBUwKb9G2uq0Ir+GnAmMHEDlPLH8lt5T7CcN5VNJ44d rNrCLnEe03Ki1CX2Jp0E0veqDESoTx5k0ZXD9ArWo9xuNeLnbF6S68fC86VLgXWW bBxmCuFYNUJEzpDA1+1X7KLSZ1f98mPG7jtDx6DghWhrIVn0zBVAByYekFkUCLpq +TZc6HQQRfGxvwll0phVonZiwbIOtO30Sskx7C/ZvYnM2nhXDT8NsYv4FjAV+BBN OcPaMo9lCKy4RB1TNtihtzsJmvpVEhZ/6QtkpgdaUHAVm+GkA3g90knMhYNq/kMi +5G96v2x3jZsAeV1wOvE7pX6vxu5w== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7A1EAC4501; Fri, 8 Jun 2018 19:16:52 -0400 (EDT) Message-Id: <47031250-8479-4a3e-9bd9-24eda1c7ab5a@sloti35d1t03> User-Agent: Cyrus-JMAP/3.1.3-653-gce35ffd-next x-jmap-identity-id: 64588216 In-Reply-To: References: Date: Fri, 08 Jun 2018 19:13:39 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=84a3f0b276064c2f8bf0f68969b74bd0 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 23:16:57 -0000 --84a3f0b276064c2f8bf0f68969b74bd0 Content-Type: multipart/related; boundary=2147d67731f547adafd8cd5380b380df --2147d67731f547adafd8cd5380b380df Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Neil,

=
  "using": [ "urn:ietf:p= arams:jmap:core", "urn:ietf:params:jmap:mail" ],
Can the JMAP Core capability just be assumed? A= ny good reasons to actually have this listed out?
<= /blockquote>

My original reasoning for having it was = as Chris mentioned, to give an update path for a revised version of core= . But on the other hand any future specification could always say presen= ce of its URN implies no "urn:ietf:params:jmap:core", it's just a l= ittle messier. The downside of course is that you're sending this same d= ata with every request, so it's extra overhead. There are probably bette= r ways to deal with that if we thought it was an issue though (some way = of coming up with a token to represent the set of "using" params you wan= t).

Anyone else have an opinion? If not, I'= m slightly inclined to leave it as a specific inclusion.

<= /div>
4.2. = /changes
Could =E2=80=9Ccreations=E2= =80=9D and =E2=80=9Cmodifications=E2=80=9D be separated into separate ar= ray properties?

Th= is is worth discussing. I see the following advantages:
  • The client receives more information, so has more flexib= ility to implement strategies such as always fetching new messages in th= e same request but delaying fetching updates until the next round trip (= and thus can omit fetching these at all if it has a partial cache and th= e changes are for messages it doesn't have cached anyway).
  • I= t mirrors the /set create, update, destroy distinction, which I think ma= kes it more consistent and easier to understand.
  • Your exampl= e of Core Data APIs being more efficient if you don't have to check whet= her you already know about an id to decide whether it's a create or modi= fy
  • You can use this to easily check for ids you care about f= or notifications (new message deliveries), and ignore those that are jus= t changed.

and disadvantages:
=

  • The server must store more state in order to calc= ulate this; for example, if using a modseq system, it now needs to store= a created modseq as well as a modified modseq.
  • You need two= Email/get back-references if you want to fetch both updates and new mes= sages in the single request. This could be less efficient for the server= to process and adds syntax overhead in both directions. The server coul= d certainly make this pretty much as efficient to process by detecting s= uccessive /get calls and processing them together (so it keeps caches op= en rather than closing between method calls etc.), but this does add com= plexity.

So, I'm not sure. It could be = a good change, but I'd like to hear from server authors on whether this = is going to create a significant extra burden to implement. The increase= in upload packet size from potentially needing an extra backreference /= get call may be a concern too?

4.2. /changes
...

<= /blockquote>
   o  *newState*: "String" This is the state the= client will be in after applying the set of changes to the old state.
If an offline client is resyn= chronizing after being disconnected and there are a lot of changes, the = way that /changes is set up seems to imply that if the changes don=E2=80= =99t all fit in 1 response, the sequence of responses will be ordered ol= dest-to-newest. Is that true?
It's technically not required, but it is most likely for eas= e of implementation, yes.

If so, and assuming most clients are fairly naive and just immediatel= y dispatch /get=E2=80=99s on IDs that they retrieve (perhaps by back-ref= erence), that isn=E2=80=99t ideal for a UI that shows objects in newest-= to-oldest order, potentially resulting in a user experience of =E2=80=9C= here are new objects from 5 days ago=E2=80=9D, followed by =E2=80=9Chere= are new objects from 4 days ago=E2=80=9D, and so on. When really, the u= ser ideally would prefer to see =E2=80=9Chere are objects from right now= =E2=80=9D as the first screen update =E2=80=94 at least for e-mail, I th= ink this is the case.

Have we had any discussion around handling pages of changes in a differ= ent way? For instance, the Gmail API&nbs= p;has a Users.history : list resource, which takes a =E2=80=9CstartHisto= ryId=E2=80=9D as well as a =E2=80=9CpageToken=E2=80=9D. The response inc= ludes a =E2=80=9CnextPageToken=E2=80=9D, or null if there are no additio= nal pages. Clients only update their local =E2=80=9ChistoryId=E2=80=9D a= fter fetching all pages.

Just to clarify, the Gmail API pages data in reverse chronologica= l order here?

If you do it in reverse order= you might run into issues like a message being both modified and then d= eleted. If you see the deleted in one page then modified in a future one= , you need to have kept track that the deleted is actually the most rece= nt (so you must have kept some data around for the deleted item). That's= a bit messy. And of course there's also the problem of what happens if = the state on the server changes while you are paging in the data. Not a = problem if you are going in forward chronological order, you just keep g= oing.

A client could do= a /query to get the absolute most recent page of items, merge that into= it=E2=80=99s cache, and then handle /changes normally in order, but thi= s seems a little less efficient.
=
For a client with partial cache (e.g. online client, prob= ably most mobile clients) you will be using /query to determine the sub= set of messages you are interested in. When a change occurs (you get a p= ush notification), the strategy I'm currently using on our FastMail JMAP= UI that's in development is the following:
  • Email/query= Changes the current list in view, max-changes 25
  • Fetch the t= hreads/messages in the "added" response of the /queryChanges result usin= g back references.
  • Email/changes
  • Thread/changes<= br>
  • Mailbox/changes + fetch changed using back references.
This is all bundled in a single JMAP request. This allows n= ew messages to be shown and deleted ones removed, and mailbox unread cou= nts to be updated all in a single round trip. A second round trip fetche= s any flag or mailbox changes for messages in view that the /changes res= ponse indicated are out of date. This is a much smaller visual change an= d generally a little less important than new mail, so delaying one round= trip is reasonable, and allows you to not fetch changes for messages yo= u don't care about.

If there have been more= than 25 changes (the max I specified), the /queryChanges fails and I re= try again this time with a much higher max changes, but without the back= references fetching the messages/threads. Once my list is up to date, I = can then fetch exactly the messages I need in the visible section: total= time 3 round trips (including the failed initial /queryChanges), but fo= r a rare case (especially because we have push, most updates are small).=

If you have a complete cache offline, you = would instead probably use a slightly different strategy. To do the init= ial sync I would start with a single /query with a filter of null, sorte= d date descending. This is your list of all messages in the account. To = do your initial sync, you would fetch the list, probably a page of say 5= 00 ids at a time, and simultaneously start fetching the messages in orde= r (so you get the newest ones first), until you have a complete set.

When a change occurs (you get a push notifica= tion), you can then do:
  • Email/changes (max-changes 25) = + back references to fetch the email headers of the added/modified messa= ges
  • Mailbox/changes + fetch changed using back referenc= es.
  • Email/query filter=3Dnull sort=3Ddate-descending positio= n=3D0 limit=3D50
This will return all the changes to t= he emails if fewer than 25 have changed. If there are more changes, you = can just keep repeating the /changes call until you have them all. To ma= ke sure you present the newest stuff quickly though, the /query fetches = the list of the newest 50 Email ids. You can look at these and start fet= ching from the top any that you don't have before you get to them in the= /changes. It's a little more work, but not that much more work (dependi= ng on your data store architecture I suppose).

<= div>Does this sound reasonable to you? If not, or if it's just suboptima= l, can you detail more what you want to be able to do (and maybe what th= at might look like at the API level)?

<= div class=3D"">
4.3. /set

A *SetError* object has the= following properties:
...
o  *description*: "String|null" A description of the error to display to the user.
Presumably, this error is not localized. The r= ecommendation to display it to the user is not consistent with the docum= ent's earlier recommendation in 3.6.2. Method-level errors: "A =E2=80=98= description' property MAY be present to help debug with an explanation o= f what the problem was.  This is a non-localised string, and is not= intended to be shown directly to end users."
<= br>
Should the same suggestion be made here?

Yeh, this should be the = same. I'll change this.

FWIW, when reading this, I also made the same scribble note that Matthe= w H. did almost 3 months ago =E2=80=94 that the anchorOffset seemed flip= ped from what my brain was expecting, and I was confused for a bit about= why it was negative instead of positive. Re-reading it and the previous= thread, I get it, and either way is fine since it is just stylistic, bu= t I will cast my vote in favor of flipping anchorOffset.
=

OK, seems majority are in favour = of flipping; I will do so.

4.5. /queryChanges
Is there a reason why the= re is no modified property? For instance, how would a primarily-online m= ail client realize that certain threads became flagged, unread, etc., as= ide from re-get'ing everything in the query window after handling the ad= ds/deletes? 

= As Bron mentioned, it uses the Email/changes method, as I described abov= e. This is generally pretty efficient.

5. Binary data
...
A blob that = is not referenced by a JMAP object (e.g. as a message attachment), MAY b= e deleted by the server to free up resources.
=E2=80=A6
   o  Except where quota restrict= ions force early deletion, an unreferenced blob SHOULD NOT be delet= ed for at least 24h from the time of upload; if reuploaded, the sam= e blobId MAY be returned, but this SHOULD reset the expiry time.
The way I=E2=80=99m = understanding this garbage-collection policy, it could be alarming to a = user if they try to delete some blob data they accidentally put on the s= erver, but it=E2=80=99s still possible to access it even after deletion = because it=E2=80=99s just unreferenced. There is a trade-off between bei= ng able to save users when they accidentally delete important data, and = a user being able to actually delete data they=E2=80=99re trying to dele= te, but I think those sort of data-recovery policies should not be total= ly opaque to JMAP.

Wh= at would you all think about being a little more explicit here? Perhaps = defining a =E2=80=9CMUST=E2=80=9D-conformance expiration time in the spe= c (N minutes)? (The current policy saying SHOULD NOT delete for 24h seem= s excessively generous for API clients to me?)

Yeh, I think we can reduce this. Note this = only applies to blobs you directly upload (so have never been referenced= ). If you delete a message for example, the spec only asks that the blob= id remain valid to the end of the API requests (so you can delete a dra= ft and then create a new one referencing the previous attachments).
<= /div>

How about we just reduce the 24h to 1h and make= it a MUST? So it becomes:

Except where = quota restrictions force early deletion, an unreferenced blob MUST NOT b= e deleted for at least 1 hour from the time of upload; if reuploaded, th= e same blobId MAY be returned, but this SHOULD reset the expiry time.

6.2.1. = PushSubscription/set
Each session= may only have a single push subscription registered.
Can somebody clarify what is meant by session he= re? Is this meant to be a single =E2=80=9Caccount=E2=80=9D?

Ah, this dates back to when we= had authentication as part of the spec. That's gone so this may need re= thinking. A session is essentially a set of auth credentials. This presu= mes that the server requires either Oauth or app passwords to log in. Yo= u then were allowed one push subscription, which would last until the cr= edentials were expired or you explicitly cleared it.

<= /div>
Since we don't have this auth requirement in the spec, perhaps= we should change this. I think we would need to do something like:
<= /div>
  • Allow multiple PushSubscriptions (how is this limited?)
    =
  • Make them expire after a set time automatically (can the client= specify a requested length subject to server limit? Or just server pick= s?)
  • The client can renew at any point to reset the time out.=

Does something like that sound reasonable?=

1.1 Notation= al Conventions
=E2=80=A6
Types signatures are given for all JSON objects in = this document.
Should this be =E2=80= =9CType=E2=80=9D, rather than =E2=80=9CTypes=E2=80=9D?

Yes.

2. The JMAP Session resource
To communicate with a JMAP server you need = two things to start:
Is a comma needed betwee= n =E2=80=9Cserver=E2=80=9D and =E2=80=9Cyou=E2=80=9D?

Yes, but I will restructure for simp= lification and clarity instead:

You need= two things to connect to a JMAP server:

A blob that is not referenced by a JMAP object = (e.g. as a message attachment), MAY be deleted by= the server to free up resources.
I think the comma befor= e =E2=80=9CMAY=E2=80=9D is not needed.

Agreed.

<= blockquote class=3D"" type=3D"cite">
6.1. The StateChange= object
   o  *t= rigger*: "String" What caused this change.  The following causes ar= e defined:
      *  "delive= ry": The arrival of a new message caused the change.

Since JMA= P is intended to be the foundation of data types beyond Mail, perhaps th= is should say something besides =E2=80=9Cnew message=E2=80=9D =E2=80=94 = maybe =E2=80=9CThe cause of the change is delivery from an external syst= em or user=E2=80=9D.

I agree, and I actually removed this whole property recently. Instead= , the mail spec now defines the following:

= Push

In addition, servers MUST= support a psuedo-type called "EmailDelivery" in the push mechanisms. Th= e 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= .

Cheers,
Neil.
--2147d67731f547adafd8cd5380b380df-- --84a3f0b276064c2f8bf0f68969b74bd0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Neil, >> =C2=A0 "using": [ "*urn:ietf:params:jmap:core*", "urn:ietf:params:jma= p:mail" ], > Can the JMAP Core capability just be assumed? Any good reasons to actu= ally have this listed out? My original reasoning for having it was as Chris mentioned, to give an u= pdate path for a revised version of core. But on the other hand any futu= re specification could always say presence of its URN implies no=C2=A0"u= rn:ietf:params:jmap:core", it's just a little messier. The downside of c= ourse is that you're sending this same data with every request, so it's = extra overhead. There are probably better ways to deal with that if we t= hought it was an issue though (some way of coming up with a token to rep= resent the set of "using" params you want). Anyone else have an opinion? If not, I'm slightly inclined to leave it a= s a specific inclusion. >> 4.2. /changes > Could =E2=80=9Ccreations=E2=80=9D and =E2=80=9Cmodifications=E2=80=9D = be separated into separate array properties? This is worth discussing. I see the following advantages: * The client receives more information, so has more flexibility to impl= ement strategies such as always fetching new messages in the same reques= t but delaying fetching updates until the next round trip (and thus can = omit fetching these at all if it has a partial cache and the changes are= for messages it doesn't have cached anyway). * It mirrors the /set create, update, destroy distinction, which I thin= k makes it more consistent and easier to understand. * Your example of Core Data APIs being more efficient if you don't have= to check whether you already know about an id to decide whether it's a = create or modify * You can use this to easily check for ids you care about for notificat= ions (new message deliveries), and ignore those that are just changed. and disadvantages: * The server must store more state in order to calculate this; for exam= ple, if using a modseq system, it now needs to store a created modseq as= well as a modified modseq. * You need two Email/get back-references if you want to fetch both upda= tes and new messages in the single request. This could be less efficient= for the server to process and adds syntax overhead in both directions. = The server could certainly make this pretty much as efficient to process= by detecting successive /get calls and processing them together (so it = keeps caches open rather than closing between method calls etc.), but th= is does add complexity. So, I'm not sure. It could be a good change, but I'd like to hear from s= erver authors on whether this is going to create a significant extra bur= den to implement. The increase in upload packet size from potentially ne= eding an extra backreference /get call may be a concern too? >> 4.2. /changes >> ... >>=20 >> =C2=A0 =C2=A0o =C2=A0*newState*: "String" This is the state the clien= t will be in after applying the set of changes to the old state. > If an offline client is resynchronizing after being disconnected and t= here are a lot of changes, the way that /changes is set up seems to impl= y that if the changes don=E2=80=99t all fit in 1 response, the sequence = of responses will be ordered oldest-to-newest. Is that true? It's technically not required, but it is most likely for ease of impleme= ntation, yes. > If so, and assuming most clients are fairly naive and just immediately= dispatch /get=E2=80=99s on IDs that they retrieve (perhaps by back-refe= rence), that isn=E2=80=99t ideal for a UI that shows objects in newest-t= o-oldest order, potentially resulting in a user experience of =E2=80=9Ch= ere are new objects from 5 days ago=E2=80=9D, followed by =E2=80=9Chere = are new objects from 4 days ago=E2=80=9D, and so on. When really, the us= er ideally would prefer to see =E2=80=9Chere are objects from right now=E2= =80=9D as the first screen update =E2=80=94 at least for e-mail, I think= this is the case. >=20 > Have we had any discussion around handling pages of changes in a diffe= rent way? For instance, the=C2=A0Gmail API =C2=A0has a Users.history : = list resource, which takes a =E2=80=9CstartHistoryId=E2=80=9D as well as= a =E2=80=9CpageToken=E2=80=9D. The response includes a =E2=80=9CnextPag= eToken=E2=80=9D, or null if there are no additional pages. Clients only = update their local =E2=80=9ChistoryId=E2=80=9D after fetching all pages.= Just to clarify, the Gmail API pages data in reverse chronological order= here? If you do it in reverse order you might run into issues like a message b= eing both modified and then deleted. If you see the deleted in one page = then modified in a future one, you need to have kept track that the dele= ted is actually the most recent (so you must have kept some data around = for the deleted item). That's a bit messy. And of course there's also th= e problem of what happens if the state on the server changes while you a= re paging in the data. Not a problem if you are going in forward chronol= ogical order, you just keep going. > A client could do a /query to get the absolute most recent page of ite= ms, merge that into it=E2=80=99s cache, and then handle /changes normall= y in order, but this seems a little less efficient. For a client with partial cache (e.g. online client, probably most mobil= e clients) you will be using /query to determine the subset of messages= you are interested in. When a change occurs (you get a push notificatio= n), the strategy I'm currently using on our FastMail JMAP UI that's in d= evelopment is the following: * Email/queryChanges the current list in view, max-changes 25 * Fetch the threads/messages in the "added" response of the /queryChang= es result using back references. * Email/changes * Thread/changes * Mailbox/changes + fetch changed using back references. This is all bundled in a single JMAP request. This allows new messages t= o be shown and deleted ones removed, and mailbox unread counts to be upd= ated all in a single round trip. A second round trip fetches any flag or= mailbox changes for messages in view that the /changes response indicat= ed are out of date. This is a much smaller visual change and generally a= little less important than new mail, so delaying one round trip is reas= onable, and allows you to not fetch changes for messages you don't care = about. If there have been more than 25 changes (the max I specified), the /quer= yChanges fails and I retry again this time with a much higher max change= s, but without the backreferences fetching the messages/threads. Once my= list is up to date, I can then fetch exactly the messages I need in the= visible section: total time 3 round trips (including the failed initial= /queryChanges), but for a rare case (especially because we have push, m= ost updates are small). If you have a complete cache offline, you would instead probably use a s= lightly different strategy. To do the initial sync I would start with a = single /query with a filter of null, sorted date descending. This is you= r list of all messages in the account. To do your initial sync, you woul= d fetch the list, probably a page of say 500 ids at a time, and simultan= eously start fetching the messages in order (so you get the newest ones = first), until you have a complete set.=20 When a change occurs (you get a push notification), you can then do: * Email/changes (max-changes 25) + back references to fetch the email h= eaders of the added/modified messages * Mailbox/changes=C2=A0+ fetch changed using back references. * Email/query filter=3Dnull sort=3Ddate-descending position=3D0 limit=3D= 50 This will return all the changes to the emails if fewer than 25 have cha= nged. If there are more changes, you can just keep repeating the /change= s call until you have them all. To make sure you present the newest stuf= f quickly though, the /query fetches the list of the newest 50 Email ids= . You can look at these and start fetching from the top any that you don= 't have before you get to them in the /changes. It's a little more work,= but not that much more work (depending on your data store architecture = I suppose). Does this sound reasonable to you? If not, or if it's just suboptimal, c= an you detail more what you want to be able to do (and maybe what that m= ight look like at the API level)? >=20 >> 4.3. /set >=20 >> A *SetError* object has the following properties: >> ... >> o =C2=A0*description*: "String|null" A description of the error *to d= isplay=C2=A0**to the user*. > Presumably, this error is not localized. The recommendation to display= it to the user is not consistent with the document's earlier recommenda= tion in 3.6.2. Method-level errors: "A =E2=80=98description' property MA= Y be present to help debug with an explanation of what the problem was. = =C2=A0This is a non-localised string, and is not intended to be shown di= rectly to end users." >=20 > Should the same suggestion be made here? Yeh, this should be the same. I'll change this. > FWIW, when reading this, I also made the same scribble note that Matth= ew H. did almost 3 months ago =E2=80=94 that the anchorOffset seemed fli= pped from what my brain was expecting, and I was confused for a bit abou= t why it was negative instead of positive. Re-reading it and the previou= s thread, I get it, and either way is fine since it is just stylistic, b= ut I will cast my vote in favor of flipping anchorOffset. OK, seems majority are in favour of flipping; I will do so. > 4.5. /queryChanges > Is there a reason why there is no modified property? For instance, how= would a primarily-online mail client realize that certain threads becam= e flagged, unread, etc., aside from re-get'ing everything in the query w= indow after handling the adds/deletes?=C2=A0 As Bron mentioned, it uses the Email/changes method, as I described abov= e. This is generally pretty efficient. > 5. Binary data >> ... >> A blob that is not referenced by a JMAP object (e.g. as a message att= achment), MAY be deleted by the server to free up resources. >> =E2=80=A6 >> =C2=A0 =C2=A0o =C2=A0Except where quota restrictions force early dele= tion, an=C2=A0unreferenced blob SHOULD NOT be deleted for at least 24h f= rom the=C2=A0time of upload; if reuploaded, the same blobId MAY be retur= ned,=C2=A0but this SHOULD reset the expiry time. > The way I=E2=80=99m understanding this garbage-collection policy, it c= ould be alarming to a user if they try to delete some blob data they acc= identally put on the server, but it=E2=80=99s still possible to access i= t even after deletion because it=E2=80=99s just unreferenced. There is a= trade-off between being able to save users when they accidentally delet= e important data, and a user being able to actually delete data they=E2=80= =99re trying to delete, but I think those sort of data-recovery policies= should not be totally opaque to JMAP. >=20 > What would you all think about being a little more explicit here? Perh= aps defining a =E2=80=9CMUST=E2=80=9D-conformance expiration time in the= spec (N minutes)? (The current policy saying SHOULD NOT delete for 24h = seems excessively generous for API clients to me?) Yeh, I think we can reduce this. Note this only applies to blobs you dir= ectly upload (so have never been referenced). If you delete a message fo= r example, the spec only asks that the blob id remain valid to the end o= f the API requests (so you can delete a draft and then create a new one = referencing the previous attachments). How about we just reduce the 24h to 1h and make it a MUST? So it becomes= : *Except where quota restrictions force early deletion, an unreferenced b= lob MUST NOT be deleted for at least 1 hour from the time of upload; if = reuploaded, the same blobId MAY be returned, but this SHOULD reset the e= xpiry time.* >> 6.2.1. PushSubscription/set >> Each *session* may only have a single push subscription registered. > Can somebody clarify what is meant by session here? Is this meant to b= e a single =E2=80=9Caccount=E2=80=9D? Ah, this dates back to when we had authentication as part of the spec. T= hat's gone so this may need rethinking. A session is essentially a set o= f auth credentials. This presumes that the server requires either Oauth = or app passwords to log in. You then were allowed one push subscription,= which would last until the credentials were expired or you explicitly c= leared it. Since we don't have this auth requirement in the spec, perhaps we should= change this. I think we would need to do something like: * Allow multiple PushSubscriptions (how is this limited?) * Make them expire after a set time automatically (can the client speci= fy a requested length subject to server limit? Or just server picks?) * The client can renew at any point to reset the time out. Does something like that sound reasonable? >> 1.1 Notational Conventions >> =E2=80=A6 >> *Types* signatures are given for all JSON objects in this document. > Should this be =E2=80=9CType=E2=80=9D, rather than =E2=80=9CTypes=E2=80= =9D? Yes. >> 2. The JMAP Session resource >> To communicate with a JMAP *server you* need two things to start: > Is a comma needed between =E2=80=9Cserver=E2=80=9D and =E2=80=9Cyou=E2= =80=9D? Yes, but I will restructure for simplification and clarity instead: *You need two things to connect to a JMAP server:* >> A blob that is not referenced by a JMAP object (e.g. as a message=C2=A0= *attachment), MAY* be deleted by the server to free up resources. > I think the comma before =E2=80=9CMAY=E2=80=9D is not needed. Agreed. >> 6.1. The StateChange object >> =C2=A0 =C2=A0o =C2=A0*trigger*: "String" What caused this change. =C2= =A0The following causes are defined: >> =C2=A0 =C2=A0 =C2=A0 * =C2=A0"delivery": The arrival of a new message= caused the change. >=20 > Since JMAP is intended to be the foundation of data types beyond Mail,= perhaps this should say something besides =E2=80=9Cnew message=E2=80=9D= =E2=80=94 maybe =E2=80=9CThe cause of the change is delivery from an ex= ternal system or user=E2=80=9D. I agree, and I actually removed this whole property recently. Instead, t= he mail spec now defines the following: **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 c= hange to the Email objects.* Cheers, Neil. --84a3f0b276064c2f8bf0f68969b74bd0-- From nobody Fri Jun 8 23:45:41 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 424F31310D7 for ; Fri, 8 Jun 2018 23:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=rotJFBTR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=W7X2Tg22 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 xd07ns6E4gGO for ; Fri, 8 Jun 2018 23:45:34 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BEB130DEF for ; Fri, 8 Jun 2018 23:45:33 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 66E1421B71 for ; Sat, 9 Jun 2018 02:45:33 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute6.internal (MEProxy); Sat, 09 Jun 2018 02:45:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Wl3FBcQcw0NZ9LkIEwXXnZAt/JMyKblDdIQu6RdWs yk=; b=rotJFBTRu92vHnMVK68bdhSLMwvuRuKiwwJyb3/o4LG//3wqjVLtBcLqW BCCSLAgz5baa+lx3QNFKcsWTNHZXP0GcGnz6A58rHmElB5QGtfWCFdfh1Pc0l1De M7UENj+Wxxqxg8lM1heqBndBq4V0ycRSOlcwucV6VGqYeWxGmGNpCpTObVMNOXHh SRT9UlqQnG9qIGMQ0eXdDKxgEV9X9fhIoitaTER5R2MsREfejAmDxI29M8eJclKT Qt4FVNSLMjZo8g+IvsHRolz8k+/klvzyCuvljufVdR2SGo01Quths6CAn6rmQoWP w5OAfQApLvaNixjUrvVK7ExQnyJIg== 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-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Wl3FBcQcw0NZ9LkIEwXXnZAt/JMyKblDdIQu6RdWs yk=; b=W7X2Tg22spQktXf0FBRT0BBHSR8HRaaIL7dxErSeETiJP2hnKSkTiEVIh f8ggjLmgK7vWsKkHf9K+6B5nj5BwvG6SNPc6CaZU3+JEoxWa4zSDJchdzJnEKKFx wc1R8GIOaq3zg5NegTTZiSWOfrd/6Hp0Dpdj97vxVgb7bKZxFTkj4tbBxWxhe2nU dg5vkyWfn6Z90mJGzhMM/ojbJuj0lfPrFjt/tT8HKphMDtlTN3vD+V2WVPYiZJrZ 1RO0WjDreZOAFburWJitClbOBK8FoW+CQF2Ug/YisNdg+RzM3QfOqsUUMkyJ9ELN reTk+0XIcUbXR7f+EzmvP4bZtqfpw== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C3FD2C4501; Sat, 9 Jun 2018 02:45:32 -0400 (EDT) Message-Id: <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> User-Agent: Cyrus-JMAP/3.1.3-653-gce35ffd-next x-jmap-identity-id: 64588216 In-Reply-To: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> Date: Sat, 09 Jun 2018 02:45:32 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=8725623ddd944ce3ad37dfe3580f4397 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 06:45:37 -0000 --8725623ddd944ce3ad37dfe3580f4397 Content-Type: multipart/related; boundary=319245515d0e4cd19ad148e87c04c8a7 --319245515d0e4cd19ad148e87c04c8a7 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, 31= May 2018, at 4:25 PM, Neil Jhaveri wrote:
Types signatures are given for all JSON objects in this docume= nt=E2=80=A6
Since this document is= presumably dependent upon JMAP Core, can we reference it and avoid repe= ating the same 4 conventions?  Something like "Type signatures are = given for all JSON objects in this document. The conventions follow thos= e in Section 1 of [RFC XXXX]=E2=80=9D.

Sure, sounds reasonable. I'll do that.

=
2. Mailboxes
=E2=80= =A6
Servers SHOUL= D forbid sibling Mailboxes with the same name.
Should this be be a MUST? I thought this is expressly forbid= den in IMAP - RFC 3501 6.3.3. says "It is an error to attempt to create = INBOX or a mailbox with a name that refers to an extant mailbox=E2=80=9D= .

For compatibility with IMAP = it needs to be a MUST =E2=80=93 so yes, I'll change it.
The current definition of EmailAd= dress object doesn=E2=80=99t seem sufficient to cover an RFC 5322 Group = Address? e.g.:
To: A Group:Ed Jo= nes <c@a.test>,joe@where.test,John <jdoe@one.test>;

The current mapping would= be:

[
    { "name": "A Group", email: nul= l },
    = { "name": "Ed Jones", email: "c@a.test" },
    { "name": "John", email: "jdoe@one.test" }<= /span>
]
<= br>
This gives the group name, but doesn't give the position o= f the end of the group. I believe the thinking was groups are normally u= sed for the whole set, so the end wasn't important. However, we could ad= d an end marker (name=3Dnull and email=3Dnull?)

=
I would really prefer this stayed a flat list rather than a hierarc= hical structure though (and remember you are not allowed to have nested = groups).

Thoughts?

=
4.1.2. Header fields
=E2= =80=A6
 =  Any syntactically correct [RFC2047] encoded sections with a known= encoding MUST be decoded, following the same rules as for the _Text_ fo= rm...
It looks to me like the inde= ntation of this entire section is 1 level too low?  The same issue = applies to the comment right after the *MessageIds* property definition.= Ditto for *URLs*.

Yeh, I got = the markdown indentation wrong. Will fix.

4.1.2. Header fields   
...
In addition, the client may request/send= properties representing individual header fields of the form:
=

        &n= bsp;               header:{header-fie= ld-name}

Where "{head= er-field-name}" means any series of one or more printable ASCII characte= rs (i.e. characters that have values between 33 and 126, inclusive), exc= ept colon. 
I am not re= ally sure what the conventions are... would this be better expressed wit= h ABNF, or is this textual explanation sufficient?

I don't know; I'll see what more experienced editor= s say. My view is as long as it's clear to the average interested person= reading the document, it's OK.

When I first read this, I was a little confuse= d by the text =E2=80=9Cincluding sub parts=E2=80=9D, and thought maybe i= t meant that the tree of parts was flattened into a single array. If oth= ers also found this confusing, maybe it could be clarified into somethin= g like this:
This is the full MIME structure of the message body, represented as a= n array of the message=E2=80=99s top-level MIME parts, without recursing= into =E2=80=9Cmessage/rfc822=E2=80=9D or =E2=80=9Cmessage/global=E2=80=9D= parts. Note that EmailBodyParts may have subParts if they are type =E2=80= =9Cmultipart/*=E2=80=9D.

Sounds good, will do.

   = ;o  *bodyValues*: "String[BodyValue]" (immutable)= This is a map of...
Should this be EmailBodyValue = instead of BodyValue?

Ye= s, will fix.

4.1.= 3. Body parts
...
MIME structures are arbi= trary nested trees of documents, but the majority of email clients prese= nt a model of an email body...
This entire section is a solid in-depth explanation, = but it comes after the property definitions, so it read a little bit con= fusing to me, and felt like the properties were being re-defined. I thin= k it might be worthwhile considering an edit where the high-level explan= ation of MIME-tree-flattening comes before the list of Email properties,= and then in each property, add more detail as to what each one is, so t= hat it reads a bit more linearly and each property definition is a bit m= ore self-contained. Thoughts?

Yes, I think it needs to be moved to the very top of the Email des= cription, providing a non-normative overview of the structure before the= actual specification. I'll do this.

I personally think it may be w= orthwhile considering consolidating back down to a single attachedFiles = property rather than having to have two properties and merge them. Thoug= hts?

Yes, I agree. Looking at = it again, this is simpler to understand and gives you the full ordering.= I'll do this (and name the property just "attachments").
=
4.2. Email/get
=E2=80=A6
   The following propertie= s are expected to be fast to fetch in a quality implementation:
Resent-XX are commonly shown by 
=

=E2=80=A6 by what?! And importantly, ar= e they commonly shown in the mailbox listing or when you open the messag= e (because the latter will be fetched with the body so doesn't have to b= e fast)?

4.7. Email/import
...
The server MAY forbid two email = objects with the same exact [RFC5322] content, or even just with the sam= e [RFC5322] Message-ID, to coexist within an account.  In this case= , it MUST reject attempts to import an email considered a duplicate with= an "alreadyExists" SetError.  
Allowing a rejection purely based on a Message-ID match seems a littl= e bit restrictive to me =E2=80=94 it=E2=80=99s author-generated, so I ha= ve seen the global-uniqueness requirement violated by naively written sc= ripts. 

This text is ther= e because I believe Gmail does this (but please correct me if I'm wrong;= maybe it's only on delivery, not append?). It's a MAY, so it's up to th= e server to define what it wants to do, but the spec needs to be compati= ble as much as possible with existing systems.

<= blockquote type=3D"cite">
5. Email Submission
=E2=80=A6
   o  *identityId*: "String= " (immutable) The id of the identity to associate with this submission.<= br>
It=E2=80=99s a little bit confusing tha= t Identity is used here before it=E2=80=99s defined in section 6. Maybe = a slight note? 

I think I= 'll just reorder it so the Identity section comes before EmailSubmission= . That should read better.

5. Email Submi= ssion
  *  *mailFrom*= : The email in the _Sender_ header, if present, otherwise the _From_ hea= der, if present, and no parameters.  If multiple addresses are pres= ent in one of these headers, or there is more than one _Sender_/_From_ h= eader, the server SHOULD reject the email as invalid but otherwise MUST = take the first address in the last _Sender_/_From_ header in the [RFC532= 2] version of the message.  If the address found from= this is not allowed by the identity associated with this submission, th= e _email_ property from the identity MUST be used instead.
=
Instead of silently swapping the user= =E2=80=99s requested _From_ to the identity address, I'd prefer returnin= g a "forbiddenFrom=E2=80=9D error and give the user a chance to correct = their mistake. Thoughts?

This = is the RFC5321 SMTP envelope From remember, not the RFC5322 message From= . This passage of spec is also only referring to what to do when the cli= ent doesn't explicitly set an envelope. I think therefore this passage i= s OK, but you raise a good point that we probably need a separate error = for a forbidden RFC5321 From in the envelope. I'll add:
- `forbiddenMailFrom` =E2=80=93 The server does not pe= rmit the user to send an email
  with the [@!RFC5321]= envelope From.

which is in addition to:

- `forbiddenFrom` =E2=80=93 The server d= oes not permit the user to send an email
  with the [= @!RFC5322] From header of the email to be sent.

=
5. Email Submission
=E2=80=A6 
<= /div>
         F= or emails relayed via an alternative to SMTP, the server MAY
         generate a synthetic str= ing representing the status instead.
  &nb= sp;      If it does this, the string MUST be of the follo= wing form:

  &nb= sp;      +  A 3-digit SMTP reply code, as defined in= [
RFC5321], section
  =        +  Then an SMTP Enhanced Mail System Sta= tus Code as defined in [RFC3463], with a registry defined in [RFC5248].<= br>
         +  Then = a single space character.
      =    +  Then an implementation-specific information string = with a human readable explanation of the response.
Not very familiar with the conventions here, but would ABNF = be more appropriate to specify this?

Again, happy to take advice from more experienced editors here.

5.5 EmailSubmission/set
   Standard _/set_ method, with the fol= lowing two extra arguments:
   o &nbs= p;*onSuccessUpdateEmail*:...
I think a lot of clients will want to move the message from Draft to Se= nt using this block. It might be worth explicitly calling that out, or e= ven giving a full example.  Thoughts?
Yes, that's exactly what it's for. I'll add an example.
=

7. Search Snippets
= =E2=80=A6
   o  = *attachments*: "String|null" If text from the filter matches the text ex= tracted from an attachment, this is the relevant section of the attachme= nt (converted to plain text), with matching words/phrases wrapped in "&l= t;mark></mark>" tags.  It MUST NOT be bigger than 255 octe= ts in size.  If it does not match, this is "null".
<= /blockquote>
I could imagine a MUA wanting to present to = the user exactly which attachment the search string was found in, so it = might be worth including an attachment ID property. Thoughts? 
<= /div>

That does sound like a useful feat= ure to me. It will probably have to be optional, any suggestions on the = best way to represent this? Could make the property a map of partId to m= atching section, but then what to do if the server doesn't know which pa= rt had the match?

8. Vacation Response
The *VacationResponse* object rep= resents the state of vacation-response related settings for an account. =  It has the following properties:
= I=E2=80=99m not too knowledgeable about prior work here, but:
<= div class=3D"">
1. Exchange Server offers the ability to configure a= separate =E2=80=9CInternal" and =E2=80=9CExternal" vacation response =E2= =80=94 which is useful if you work in a large organization and want to h= ave your internal reply include things like =E2=80=9Cyou can contact my = manager at XXX=E2=80=9D, but you want your external client-facing respon= se to expose less information.
2. I also think = that there may need to be some mention of loop prevention =E2=80=94 so t= hat two accounts with vacation responses don=E2=80=99t continuously repl= y to each other. 

T= he spec here was not intended to provide a complete consideration of eve= rything that should be considered when building a vacation response syst= em (which is already covered in previous RFCs), merely a mechanism by wh= ich it can be configured by the client. The functionality was chosen as = a common subset supported by most major systems, to make adoption feasib= le. Individual systems (including Exchange, Gmail, FastMail etc.) will h= ave extended options for vacation responses, but then which options do y= ou support in the spec, and how do you make it so other systems can be c= ompliant? Lots of optional features are a pain for everyone. The real qu= estion is whether being able to configure the common subset from arbitra= ry 3rd party clients is useful or not?

I am starting to think = this should be deferred to a JMAP extension, so that prior work in this = area can be more carefully considered (such as RFC 5230). Thoughts?
<= /div>

So, I agree the vacation res= ponse could be neatly separated into a separate specification rather tha= n part of the core mail. The main reason to include it here is to make s= ure there is concrete extra functionality that an existing IMAP client i= mplementing JMAP would be able to provide that it couldn't with just IMA= P. This (sadly) can make it an easier sell to management than just "it w= ill make everything work faster, more efficiently and more reliably than= before". However, I'm very interested to hear if you don't think this i= s likely to be so useful a hook based on your previous employment experi= ence.

Neil.
--319245515d0e4cd19ad148e87c04c8a7-- --8725623ddd944ce3ad37dfe3580f4397 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 31 May 2018, at 4:25 PM, Neil Jhaveri wrote: >> Types signatures are given for all JSON objects in this document=E2=80= =A6 > Since this document is presumably dependent upon JMAP Core, can we ref= erence it and avoid repeating the same 4 conventions? =C2=A0Something li= ke "Type signatures are given for all JSON objects in this document. The= conventions follow those in Section 1 of [RFC XXXX]=E2=80=9D. Sure, sounds reasonable. I'll do that. >> 2. Mailboxes >> =E2=80=A6 >> Servers *SHOULD* forbid sibling Mailboxes with the same name. > Should this be be a MUST? I thought this is expressly forbidden in IMA= P - RFC 3501 6.3.3. says "It is an error to attempt to create INBOX or a= mailbox with a name that refers to an extant mailbox=E2=80=9D. For compatibility with IMAP it needs to be a MUST =E2=80=93 so yes, I'll= change it. > The current definition of EmailAddress object doesn=E2=80=99t seem suf= ficient to cover an RFC 5322 Group Address? e.g.: >> To: A Group:Ed Jones ,joe@where.test,John ; The current mapping would be: [ =C2=A0=C2=A0=C2=A0 { "name": "A Group", email: null }, =C2=A0=C2=A0=C2=A0 { "name": "Ed Jones", email: "c@a.test" }, =C2=A0=C2=A0=C2=A0 { "name": "John", email: "jdoe@one.test" } ] This gives the group name, but doesn't give the position of the end of t= he group. I believe the thinking was groups are normally used for the wh= ole set, so the end wasn't important. However, we could add an end marke= r (name=3Dnull and email=3Dnull?) I would really prefer this stayed a flat list rather than a hierarchical= structure though (and remember you are not allowed to have nested group= s). Thoughts? >> 4.1.2. Header fields >> =E2=80=A6 >> =C2=A0 =C2=A0Any syntactically correct [RFC2047] encoded sections wit= h a known encoding MUST be decoded, following the same rules as for the = _Text_ form... > It looks to me like the indentation of this entire section is 1 level = too low? =C2=A0The same issue applies to the comment right after the *Me= ssageIds* property definition. Ditto for *URLs*. Yeh, I got the markdown indentation wrong. Will fix. >> 4.1.2. Header fields =C2=A0=C2=A0 >> ... >> In addition, the client may request/send properties representing indi= vidual header fields of the form: >>=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 header:{header-field-name} >>=20 >> Where "{header-field-name}" means any series of one or more printable= ASCII characters (i.e. characters that have values between 33 and 126, = inclusive), except colon.=C2=A0 > I am not really sure what the conventions are... would this be better = expressed with ABNF, or is this textual explanation sufficient? I don't know; I'll see what more experienced editors say. My view is as = long as it's clear to the average interested person reading the document= , it's OK. > When I first read this, I was a little confused by the text =E2=80=9Ci= ncluding sub parts=E2=80=9D, and thought maybe it meant that the tree of= parts was flattened into a single array. If others also found this conf= using, maybe it could be clarified into something like this: >> This is the full MIME structure of the message body, represented as a= n array of the message=E2=80=99s top-level MIME parts, without recursing= into =E2=80=9Cmessage/rfc822=E2=80=9D or =E2=80=9Cmessage/global=E2=80=9D= parts. Note that EmailBodyParts may have subParts if they are type =E2=80= =9Cmultipart/*=E2=80=9D. Sounds good, will do. >> =C2=A0 =C2=A0o =C2=A0*bodyValues*: "String[*BodyValue*]" (immutable) = This is a map of... > Should this be EmailBodyValue instead of BodyValue? Yes, will fix. > 4.1.3. Body parts >> ... >> MIME structures are arbitrary nested trees of documents, but the majo= rity of email clients present a model of an email body... > This entire section is a solid in-depth explanation, but it comes afte= r the property definitions, so it read a little bit confusing to me, and= felt like the properties were being re-defined. I think it might be wor= thwhile considering an edit where the high-level explanation of MIME-tre= e-flattening comes before the list of Email properties, and then in each= property, add more detail as to what each one is, so that it reads a bi= t more linearly and each property definition is a bit more self-containe= d. Thoughts? Yes, I think it needs to be moved to the very top of the Email descripti= on, providing a non-normative overview of the structure before the actua= l specification. I'll do this. > I personally think it may be worthwhile considering consolidating back= down to a single attachedFiles property rather than having to have two = properties and merge them. Thoughts? Yes, I agree. Looking at it again, this is simpler to understand and giv= es you the full ordering. I'll do this (and name the property just "atta= chments"). >> 4.2. Email/get >> =E2=80=A6 >> =C2=A0 =C2=A0The following properties are expected to be fast to fetc= h in a quality implementation: > Resent-XX are commonly shown by=C2=A0 =E2=80=A6 by what?! And importantly, are they commonly shown in the mail= box listing or when you open the message (because the latter will be fet= ched with the body so doesn't have to be fast)? >> 4.7. Email/import >> ... >> The server MAY forbid two email objects with the same exact [RFC5322]= content, or even just with the same [RFC5322] Message-ID, to coexist wi= thin an account. =C2=A0In this case, it MUST reject attempts to import a= n email considered a duplicate with an "alreadyExists" SetError. =C2=A0 > Allowing a rejection purely based on a Message-ID match seems a little= bit restrictive to me =E2=80=94 it=E2=80=99s author-generated, so I hav= e seen the global-uniqueness requirement violated by naively written scr= ipts.=C2=A0 This text is there because I believe Gmail does this (but please correct= me if I'm wrong; maybe it's only on delivery, not append?). It's a MAY,= so it's up to the server to define what it wants to do, but the spec ne= eds to be compatible as much as possible with existing systems. >> 5. Email Submission >> =E2=80=A6 >> =C2=A0 =C2=A0o =C2=A0*identityId*: "String" (immutable) The id of the= identity to associate with this submission. > It=E2=80=99s a little bit confusing that Identity is used here before = it=E2=80=99s defined in section 6. Maybe a slight note?=C2=A0 I think I'll just reorder it so the Identity section comes before EmailS= ubmission. That should read better. >> 5. Email Submission >> =C2=A0 * =C2=A0*mailFrom*: The email in the _Sender_ header, if prese= nt, otherwise the _From_ header, if present, and no parameters. =C2=A0If= multiple addresses are present in one of these headers, or there is mor= e than one _Sender_/_From_ header, the server SHOULD reject the email as= invalid but otherwise MUST take the first address in the last _Sender_/= _From_ header in the [RFC5322] version of the message. =C2=A0*If the add= ress found from this is not allowed by the identity associated with this= submission, the _email_ property from the identity MUST be used instead= *. > Instead of silently swapping the user=E2=80=99s requested _From_ to th= e identity address, I'd prefer returning a "forbiddenFrom=E2=80=9D error= and give the user a chance to correct their mistake. Thoughts? This is the RFC5321 SMTP envelope From remember, not the RFC5322 message= From. This passage of spec is also only referring to what to do when th= e client doesn't explicitly set an envelope. I think therefore this pass= age is OK, but you raise a good point that we probably need a separate e= rror for a forbidden RFC5321 From in the envelope. I'll add: - `forbiddenMailFrom` =E2=80=93=C2=A0The server does not permit the user= to send an email =C2=A0 with the [@!RFC5321] envelope From. which is in addition to: - `forbiddenFrom` =E2=80=93=C2=A0The server does not permit the user to = send an email =C2=A0 with the [@!RFC5322] From header of the email to be sent. >> 5. Email Submission >> =E2=80=A6=C2=A0 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For emails relayed via an alternati= ve to SMTP, the server MAY >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generate a synthetic string represe= nting the status instead. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it does this, the string MUST be= of the following form: >>=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0A 3-digit SMTP reply code, = as defined in [ >> RFC5321],=C2=A0section >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0Then an SMTP Enhanced Mail = System Status Code as defined in [RFC3463], with a registry defined in [= RFC5248]. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0Then a single space charact= er. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0Then an implementation-spec= ific information string with a human readable explanation of the respons= e. > Not very familiar with the conventions here, but would ABNF be more ap= propriate to specify this? Again, happy to take advice from more experienced editors here. >> 5.5 EmailSubmission/set >> =C2=A0 =C2=A0Standard _/set_ method, with the following two extra arg= uments: >> =C2=A0 =C2=A0o =C2=A0*onSuccessUpdateEmail*:... > I think a lot of clients will want to move the message from Draft to S= ent using this block. It might be worth explicitly calling that out, or = even giving a full example. =C2=A0Thoughts? Yes, that's exactly what it's for. I'll add an example. >> 7. Search Snippets >> =E2=80=A6 >> =C2=A0 =C2=A0o =C2=A0*attachments*: "String|null" If text from the fi= lter matches the text extracted from an attachment, this is the relevant= section of the attachment (converted to plain text), with matching word= s/phrases wrapped in "" tags. =C2=A0It MUST NOT be bigger t= han 255 octets in size. =C2=A0If it does not match, this is "null". > I could imagine a MUA wanting to present to the user exactly which att= achment the search string was found in, so it might be worth including a= n attachment ID property. Thoughts?=C2=A0 That does sound like a useful feature to me. It will probably have to be= optional, any suggestions on the best way to represent this? Could make= the property a map of partId to matching section, but then what to do i= f the server doesn't know which part had the match? >> 8. Vacation Response >> The *VacationResponse* object represents the state of vacation-respon= se related settings for an account. =C2=A0It has the following propertie= s: > I=E2=80=99m not too knowledgeable about prior work here, but: > 1. Exchange Server offers the ability to configure a separate =E2=80=9C= Internal" and =E2=80=9CExternal" vacation response =E2=80=94 which is us= eful if you work in a large organization and want to have your internal = reply include things like =E2=80=9Cyou can contact my manager at XXX=E2=80= =9D, but you want your external client-facing response to expose less in= formation. > 2. I also think that there may need to be some mention of loop prevent= ion =E2=80=94 so that two accounts with vacation responses don=E2=80=99t= continuously reply to each other.=C2=A0 The spec here was not intended to provide a complete consideration of ev= erything that should be considered when building a vacation response sys= tem (which is already covered in previous RFCs), merely a mechanism by w= hich it can be configured by the client. The functionality was chosen as= a common subset supported by most major systems, to make adoption feasi= ble. Individual systems (including Exchange, Gmail, FastMail etc.) will = have extended options for vacation responses, but then which options do = you support in the spec, and how do you make it so other systems can be = compliant? Lots of optional features are a pain for everyone. The real q= uestion is whether being able to configure the common subset from arbitr= ary 3rd party clients is useful or not? > I am starting to think this should be deferred to a JMAP extension, so= that prior work in this area can be more carefully considered (such as = RFC 5230). Thoughts? So, I agree the vacation response could be neatly separated into a separ= ate specification rather than part of the core mail. The main reason to = include it here is to make sure there is concrete extra functionality th= at an existing IMAP client implementing JMAP would be able to provide th= at it couldn't with just IMAP. This (sadly) can make it an easier sell t= o management than just "it will make everything work faster, more effici= ently and more reliably than before". However, I'm very interested to he= ar if you don't think this is likely to be so useful a hook based on you= r previous employment experience. Neil. --8725623ddd944ce3ad37dfe3580f4397-- From nobody Fri Jun 8 23:55:14 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 539911310D9 for ; Fri, 8 Jun 2018 23:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=YIePK6rw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GQhux2Cc 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 dhHikWQFcTCS for ; Fri, 8 Jun 2018 23:55:11 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4280130DEF for ; Fri, 8 Jun 2018 23:55:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5EBDC213FC for ; Sat, 9 Jun 2018 02:55:10 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute6.internal (MEProxy); Sat, 09 Jun 2018 02:55:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=z0H6iSKnedsy1h4wTACyAyq6ExEzobL/DUX6jxL7O ns=; b=YIePK6rwsWWdQomYwLSKSzEFoYPJFm+IWv5qxyxby6QRKctIdt6A7ccgD 7JjBIbYkUxWVYWvTCVvlfvXVlm+MxIGWd7CgVBjI8zyd2luoPzGSpw3MDEBmPcWI mZNaAcoPvrHmLoeQG0dTSz2YfcLrw4uhGcQZa4pZIm7NLW1w6V0vo9RHpA6kwX4s AIX/Is5h+H+Z37uBVUa64wBjvfdz5sIQ8pBWj7NXKoTedDVJ3/6uCRxYsjvWWp/Y rBlraEmMv16QXoWOhFuGJInncQNyETMAz2mua2sz+raukrLu5dl6icJl4ytmJLU6 Rw0JQ/WJyvJlBxkor2bn75oneDqfQ== 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-sender:x-me-sender :x-sasl-enc; s=fm2; bh=z0H6iSKnedsy1h4wTACyAyq6ExEzobL/DUX6jxL7O ns=; b=GQhux2CcvgoQ1uL7I1ikqpg/2dWx+5yYlqf1BXdgJzxeTbvMLwdxFc+5q +Dgr/6IWSposUYSnu+w6qWFIggCtZM+IAS//1CY1vbCy2mp93jFOGDWtV4dNe3Ar agVXs1uTSlnV+g7Tyd1sav9nlyrgxPz5Li8zUKjNNIG1uva0Eo8wWnu0rcy0mqQa zwYpKGWITdr17RStYx8hc3T5aMeuib2IA7vTMgMgJ8Gbhx1T61jHDqu+toJAWSiS AlwVOWRQO1tTrn3Aapu6ExGbdTlLbIedsobLDIgnGYFCBFPg/mVFyjCUio69Ls6U zqcn8M1aSZit7nxWdndSAdcJMga1w== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 15655C4501; Sat, 9 Jun 2018 02:55:10 -0400 (EDT) Message-Id: <32a1f0a3-6fb3-4858-82f9-abc27d526f82@sloti35d1t03> User-Agent: Cyrus-JMAP/3.1.3-653-gce35ffd-next x-jmap-identity-id: 64588216 In-Reply-To: <305ecac4-d5cb-2935-a1ef-e3dcc6823e0f@fastmail.com> References: <305ecac4-d5cb-2935-a1ef-e3dcc6823e0f@fastmail.com> <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> <113acf52-6b03-4914-a0f2-7fdf08b1cf98@sloti22d1t06> Date: Sat, 09 Jun 2018 02:55:09 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=c2b9c1e1f5f14e46ab1d870c3396bfe5 Archived-At: Subject: Re: [Jmap] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-murch?= =?utf-8?q?ison-jmap-websocket-00=2Etxt?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 06:55:13 -0000 --c2b9c1e1f5f14e46ab1d870c3396bfe5 Content-Type: multipart/related; boundary=352546d14aed4f95a3d5a8a305b91172 --352546d14aed4f95a3d5a8a305b91172 Content-Type: text/html
On Wed, 30 May 2018, at 11:31 PM, Ken Murchison wrote:
  • Should the server be allowed to advertise a different URL for a websockets API connection as opposed to an HTTP one?
Sure.  I'll add a 'wsUrl' String to the capabilities.

My question was genuine, I don't know whether this should be separate or the same. Does anyone here have experience running an API that's available over either websockets or HTTP? If so, would you normally put the websockets upgrade on the same URL, or a different one? Making it separate certainly gives you more flexibility, so seems like the right option to me, but I'd be interested if anyone has real-world experience.

  • Are responses guaranteed to be in the same order as requests? (Probably not; if you want methods to execute sequentially you should bundle them in a single request object, but then how do you correlate the response objects to the request objects? Probably need to add an id property to the request/response object.)

I had intended that they would be in the same order, but I suppose out of order could be allowed if deemed necessary.

I think you definitely want this. This allows you to do concurrent requests with a single websocket, avoiding the overhead and complexity of creating multiple websocket connections to the server. 



  • I think being able to receive push events over the single websocket connection makes sense, but that means you'd have to be able to distinguish the different message types you might receive (API response or push).

Can't the client distinguish between a Response object and a StateChange object?  If we need a better way, do you have a recommendation?

I would probably add an @type property to each top-level object (Response and StateChange) with the name of the type as the value.

  • What changes are required to rate limiting options for the server? These probably need to be advertised in the capabilities object for this extension.
Are you thinking that we need separate maxSizeRequest, maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and maxObjectsInSet for the WebSocket connection?

No, these would still apply. It's more if you need extra ones: if you don't need to wait for a response to come back before issuing another request down the websocket, is this just counted as concurrent requests so subject to maxConcurrentRequests (I would say yes)? What about having multiple websocket connections at once? That probably needs a separate limit, because the request is no longer the same as the connection. Maybe maxConcurrentSockets or something.

Neil.
--352546d14aed4f95a3d5a8a305b91172-- --c2b9c1e1f5f14e46ab1d870c3396bfe5 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 30 May 2018, at 11:31 PM, Ken Murchison wrote:=20 >> * Should the server be allowed to advertise a different URL for a websockets API connection as opposed to an HTTP one? > Sure.=C2=A0 I'll add a 'wsUrl' String to the capabilities. My question was genuine, I don't know whether this should be separate or= the same. Does anyone here have experience running an API that's availa= ble over either websockets or HTTP? If so, would you normally put the we= bsockets upgrade on the same URL, or a different one? Making it separate= certainly gives you more flexibility, so seems like the right option to= me, but I'd be interested if anyone has real-world experience. >> * Are responses guaranteed to be in the same order as requests? (Probably not; if you want methods to execute sequentially you should bundle them in a single request object, but then how do you correlate the response objects to the request objects? Probably need to add an id property to the request/response object.) >=20 > I had intended that they would be in the same order, but I suppose out of order could be allowed if deemed necessary.=20 I think you definitely want this. This allows you to do concurrent reque= sts with a single websocket, avoiding the overhead and complexity of cre= ating multiple websocket connections to the server.=C2=A0 > =20 > =20 >> * I think being able to receive push events over the single websocket connection makes sense, but that means you'd have to= be able to distinguish the different message types you might receive (API response or push). >=20 > Can't the client distinguish between a Response object and a StateChange object?=C2=A0 If we need a better way, do you have a recommendation? I would probably add an @type property to each top-level object (Respons= e and StateChange) with the name of the type as the value. >> * What changes are required to rate limiting options for the server? These probably need to be advertised in the capabilities object for this extension. > Are you thinking that we need separate maxSizeRequest, maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and maxObjectsInSet for the WebSocket connection? No, these would still apply. It's more if you need extra ones: if you do= n't need to wait for a response to come back before issuing another requ= est down the websocket, is this just counted as concurrent requests so s= ubject to maxConcurrentRequests (I would say yes)? What about having mul= tiple websocket connections at once? That probably needs a separate limi= t, because the request is no longer the same as the connection. Maybe ma= xConcurrentSockets or something. Neil. --c2b9c1e1f5f14e46ab1d870c3396bfe5-- From nobody Sat Jun 9 01:38: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 888C4130E34 for ; Sat, 9 Jun 2018 01:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=staff.atmail.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 Y5EV-NtWfKEb for ; Sat, 9 Jun 2018 01:38:15 -0700 (PDT) Received: from staff70.atmail.com (staff70.atmail.com [204.145.97.70]) (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 45178130E2C for ; Sat, 9 Jun 2018 01:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=staff.atmail.com; s=20160330; h=To:Message-Id:Date:From:Subject: Mime-Version:Content-Type; bh=4VREdCpldhdMMoVJMsiBanMv0GaMjIccMBg/ODB/Oxs=; b=lreeEhkFAz2dXjzjAQgud4q/eQL7nsMOIZ+jyzecPrA8WpaXdGYgf5ILNeohW4PKx4v6foPY11 LU3GNePQHChLjLZNPsEd+zh+fxJXEj5rD42WQTBo896DFMGxi2B9Q6LOdJzV91R0qMyyXVtma/F3T BDY0wbZZxmVyJd2hPXls=; Received: from [1.132.198.146] (helo=[21.144.150.79]) by hc0-dh-ro-aio-001.internal.atmailcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fRZNn-0000QI-H2; Sat, 09 Jun 2018 18:38:00 +1000 Content-Type: multipart/alternative; boundary=Apple-Mail-A3D1F61D-7970-4F5C-A16E-B5C962B6A6FC Mime-Version: 1.0 (1.0) From: Dave Richards X-Mailer: iPhone Mail (15F79) In-Reply-To: <32a1f0a3-6fb3-4858-82f9-abc27d526f82@sloti35d1t03> Date: Sat, 9 Jun 2018 18:36:56 +1000 Cc: IETF JMAP Mailing List , tom.smith@staff.atmail.com, brad@staff.atmail.com Content-Transfer-Encoding: 7bit Message-Id: <4F1C8A0C-C3BA-454B-A85D-3AB37DAC12BE@staff.atmail.com> References: <305ecac4-d5cb-2935-a1ef-e3dcc6823e0f@fastmail.com> <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> <113acf52-6b03-4914-a0f2-7fdf08b1cf98@sloti22d1t06> <32a1f0a3-6fb3-4858-82f9-abc27d526f82@sloti35d1t03> To: Neil Jenkins X-Atmail-Id: dave.richards@staff.atmail.com X-atmail-spam-CA-score: 0 X-atmail-spam-CA-bar: / X-atmail-spam-CA-report: X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: 0 X-CTCH-RefID: str=0001.0A020205.5B1B91F6.0004, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-atmail-spam-score: 0 X-atmail-spam-bar: / Archived-At: Subject: Re: [Jmap] Fwd: New Version Notification for draft-murchison-jmap-websocket-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 08:38:19 -0000 --Apple-Mail-A3D1F61D-7970-4F5C-A16E-B5C962B6A6FC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Tom/Brad, do we do this, or are we pure WS? Dave > On 9 Jun 2018, at 16:55, Neil Jenkins wrote: >=20 > On Wed, 30 May 2018, at 11:31 PM, Ken Murchison wrote:=20 >>> * Should the server be allowed to advertise a different URL > for a websockets API connection as opposed to an HTTP one? >> Sure. I'll add a 'wsUrl' String to the capabilities. >=20 > My question was genuine, I don't know whether this should be separate or t= he same. Does anyone here have experience running an API that's available ov= er either websockets or HTTP? If so, would you normally put the websockets u= pgrade on the same URL, or a different one? Making it separate certainly giv= es you more flexibility, so seems like the right option to me, but I'd be in= terested if anyone has real-world experience. >=20 >>> * Are responses guaranteed to be in the same order as > requests? (Probably not; if you want methods to execute > sequentially you should bundle them in a single request > object, but then how do you correlate the response objects to > the request objects? Probably need to add an id property to > the request/response object.) >>=20 >> I had intended that they would be in the same order, but I suppose > out of order could be allowed if deemed necessary.=20 >=20 > I think you definitely want this. This allows you to do concurrent request= s with a single websocket, avoiding the overhead and complexity of creating m= ultiple websocket connections to the server.=20 >=20 >>=20 >>=20 >>> * I think being able to receive push events over the single > websocket connection makes sense, but that means you'd have to > be able to distinguish the different message types you might > receive (API response or push). >>=20 >> Can't the client distinguish between a Response object and a > StateChange object? If we need a better way, do you have a > recommendation? >=20 > I would probably add an @type property to each top-level object (Response a= nd StateChange) with the name of the type as the value. >=20 >>> * What changes are required to rate limiting options for the > server? These probably need to be advertised in the > capabilities object for this extension. >> Are you thinking that we need separate maxSizeRequest, > maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and > maxObjectsInSet for the WebSocket connection? >=20 > No, these would still apply. It's more if you need extra ones: if you don'= t need to wait for a response to come back before issuing another request do= wn the websocket, is this just counted as concurrent requests so subject to m= axConcurrentRequests (I would say yes)? What about having multiple websocket= connections at once? That probably needs a separate limit, because the requ= est is no longer the same as the connection. Maybe maxConcurrentSockets or s= omething. >=20 > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail-A3D1F61D-7970-4F5C-A16E-B5C962B6A6FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tom/Brad, do we do this, or are we pure WS?=

Dave
<= table width=3D"100%" border=3D"0" align=3D"center" cellpadding=3D"0" cellspa= cing=3D"0" class=3D"">

On 9 Jun 2018, at 16:55,= Neil Jenkins <neilj@fastmailte= am.com> wrote:

On W= ed, 30 May 2018, at 11:31 PM, Ken Murchison wrote:
* Should the server be allowed t= o advertise a different URL
 = ;        for a websockets API connec= tion as opposed to an HTTP one?
Su= re.  I'll add a 'wsUrl' String to the capabilities.

My question was genuine, I don't know whether thi= s should be separate or the same. Does anyone here have experience running a= n API that's available over either websockets or HTTP? If so, would you norm= ally put the websockets upgrade on the same URL, or a different one? Making i= t separate certainly gives you more flexibility, so seems like the right opt= ion to me, but I'd be interested if anyone has real-world experience.=

* Are responses guaranteed to be in the same order as
        &nb= sp;requests? (Probably not; if you want methods to execute
&= nbsp;        sequentially you should= bundle them in a single request
    &n= bsp;    object, but then how do you correlate the respon= se objects to
       &nb= sp; the request objects? Probably need to add an id property to<= br>          the request/= response object.)

I had intended that they would be in= the same order, but I suppose
  &nb= sp;out of order could be allowed if deemed necessary.

I think you definitely want this. This allows you to do concurre= nt requests with a single websocket, avoiding the overhead and complexity of= creating multiple websocket connections to the server. 



<= blockquote type=3D"cite"> * I think being able to receive push events o= ver the single
   =       websocket connection makes sense, but th= at means you'd have to
      =    be able to distinguish the different message types you mig= ht
         re= ceive (API response or push).

Can't the client disting= uish between a Response object and a
 &nb= sp; StateChange object?  If we need a better way, do you have a
   recommendation?

= I would probably add an @type property to each top-level object (Respo= nse and StateChange) with the name of the type as the value.

* Wha= t changes are required to rate limiting options for the
         = ;server? These probably need to be advertised in the
 =         capabilities object for this= extension.
Are you thinking that w= e need separate maxSizeRequest,
  &n= bsp;maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and    maxObjectsInSet for the WebSocket connection?

No, these would still apply. It's more if you n= eed extra ones: if you don't need to wait for a response to come back before= issuing another request down the websocket, is this just counted as concurr= ent requests so subject to maxConcurrentRequests (I would say yes)? What abo= ut having multiple websocket connections at once? That probably needs a sepa= rate limit, because the request is no longer the same as the connection. May= be maxConcurrentSockets or something.

Neil.=
_____________= __________________________________
Jmap mailing list<= br>Jmap@ietf.org
= https://www.ietf.org/= mailman/listinfo/jmap
= --Apple-Mail-A3D1F61D-7970-4F5C-A16E-B5C962B6A6FC-- From nobody Mon Jun 11 16:58:02 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 F20A1130DC6 for ; Mon, 11 Jun 2018 16:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smtpcorp.com header.b=kAkwsCIF; dkim=pass (2048-bit key) header.d=linagora.com header.b=JPCn6NDK 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 DgXoKSGWOon3 for ; Mon, 11 Jun 2018 16:57:57 -0700 (PDT) Received: from e1i145.smtp2go.com (e1i145.smtp2go.com [103.36.108.145]) (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 2BFF1130DC4 for ; Mon, 11 Jun 2018 16:57:56 -0700 (PDT) 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=1TGD7L9txonFa5IHkl/O7ZIvY01nZnCr3k7n7sFp/f8=; b=kAkwsCIFB3DG267CSAGaeyPOQ8 NBnPa+Hot+nAYmqMfl441fq7kMrYMirzx3gCE6Cg5uJlZBKIr9p5d1dDpb4nsGsCc/jbLWAocuu65 ax+KJUVJPVhbAzqkuVc0p4r5yLxVtQLaT3syqTbuhHfTD1LYkxPvtBmvJ83Ws9ALe9O7JVOBnXMgo /O+jEapPqOhrFaiDF5MkwhaxTBlRua3Y1ZTrpfdbbDxMdgyefIMNVLTk4v94fMQK8HJ7sxIgwNvCz tJCVVewhLHTxBOKVIDXX3P/b4Muxna+7ZibWWZTywUVNKF4fTPh17C+qIf10en9+jpGx+KjGtgfSI xyiizl4w==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linagora.com; i=@linagora.com; q=dns/txt; s=s266739; t=1528761477; h=From : Subject : To : Message-Id : Date; bh=1TGD7L9txonFa5IHkl/O7ZIvY01nZnCr3k7n7sFp/f8=; b=JPCn6NDKJN3HKRBcNOYTAvbVRfWPBor678N5U0nHOmib6jRTXjcr6zjktlx+rG7OxFr2Ga +RzAgtHytSK+AgaFT5la2M8oI/NdoLU62pC5bEmHVuFZXb9khgHTEUjT6Vr152JX/Zlt7v1e Q5UCaCgSRaZg2/px9madPs6+7n59I6DWArT+GoPd+bz6JwdOXaoXZaEIc/umaM3KCkTKsj5H Ezi1daUUnWeudVWu8lVwmo1lp8OMM2/io8bTVr+cy+GpJQK8FqfsbSugBoEz8ZxEMvd3zO1R uu0GEMj9XNacburN7leCprXEbMvYG4bxZUw8OjU59VEHr9UF0tyGxCWA== 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 Message-ID: Date: Mon, 11 Jun 2018 23:57:48 +0000 References: X-Smtpcorp-Track: 1fSWh5r_ZCkNKV.H7xAI2UiK Feedback-ID: 266739m:266739aja3LFS:266739sTDq7jD2m1:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 23:58:01 -0000


IMO having the changes events aggregated is a strength=2E It = is easy to implement on the server side as well as provides a full history = to the clients (avoids merging creations, updates & deletions together,= even if this is trivial)=2E


However, I'm doubtful concer= ning implementing state tracking only with the MODSEQ mechanism: the MODSEQ= is a property relative to a MAILBOX and thus is not adapted in response to= a email/get request= that will return email from different mailboxes=2E You could end up with t= wo email in different mailbox having the same MODSEQ=2E Having a MODSEQ glo= bal to the all account seems the only viable way out to achieve this here, = but it is, in my opinion, a very strong assertion=2E


Henc= e, I'd advocate that additional information needs to be stored anyway=2E I = see no obstacles to enhancing /cha= nges response to allow the client to distinguish additions fr= om changes=2E


Best regards,


Benoit Tellie= r


On Jun 9, 2018 6:13 AM, from neilj@fastmailteam=2Ecom=


=
4=2E2=2E /changes
<= /div>
Could =E2=80=9Ccreations=E2=80=9D and =E2= =80=9Cmodifications=E2=80=9D be separated into separate array properties?

This is worth discussi= ng=2E I see the following advantages:

  • The c= lient receives more information, so has more flexibility to implement strat= egies such as always fetching new messages in the same request but delaying= fetching updates until the next round trip (and thus can omit fetching the= se at all if it has a partial cache and the changes are for messages it doe= sn't have cached anyway)=2E
  • It mirrors the /set create, update,= destroy distinction, which I think makes it more consistent and easier to = understand=2E
  • Your example of Core Data APIs being more efficie= nt if you don't have to check whether you already know about an id to decid= e whether it's a create or modify
  • You can use this to easily ch= eck for ids you care about for notifications (new message deliveries), and = ignore those that are just changed=2E

and = disadvantages:

  • The server must store more s= tate in order to calculate this; for example, if using a modseq system, it = now needs to store a created modseq as well as a modified modseq=2E
  • You need two Email/get back-references if you want to fetch both updat= es and new messages in the single request=2E This could be less efficient f= or the server to process and adds syntax overhead in both directions=2E The= server could certainly make this pretty much as efficient to process by de= tecting successive /get calls and processing them together (so it keeps cac= hes open rather than closing between method calls etc=2E), but this does ad= d complexity=2E

So, I'm not sure=2E It cou= ld be a good change, but I'd like to hear from server authors on whether th= is is going to create a significant extra burden to implement=2E The increa= se in upload packet size from potentially needing an extra backreference /g= et call may be a concern to


From nobody Mon Jun 11 17:13:59 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 E5F58127332 for ; Mon, 11 Jun 2018 17:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=staff.atmail.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 1W1zBVqTGxr8 for ; Mon, 11 Jun 2018 17:13:51 -0700 (PDT) Received: from staff72.atmail.com (staff72.atmail.com [204.145.97.72]) (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 60D59130E2B for ; Mon, 11 Jun 2018 17:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=staff.atmail.com; s=20160330; h=Content-Type:MIME-Version:Date:Message-ID: From:To:Subject; bh=WTxLkTH0fBDy6Kpr+6SdKrfzPdRmg7IuGPhW4dbuumY=; b=I/uCADwfi AUj0ap+kdOydRLMnt2jV5EYc1Fl9QOhWepYZqBJef/rnQhvWM5YXjiGz4Py8Hb/tVkcrYVwb5odmc MrC6yG5wAY9dbZ9nKKgQw02ATgntjkU1mOC5c5yvA5M8Nw7biT95oOflgDNuCrf6pNq3/EPtNFX+T 3QHeBXdc=; Received: from 252-220-181-180.cpe.skymesh.net.au ([180.181.220.252] helo=localhost.localdomain) by hc0-dh-ro-aio-002.internal.atmailcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fSWw7-0003jc-06; Tue, 12 Jun 2018 10:13:23 +1000 To: Dave Richards , Neil Jenkins Cc: IETF JMAP Mailing List , brad@staff.atmail.com References: <305ecac4-d5cb-2935-a1ef-e3dcc6823e0f@fastmail.com> <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> <113acf52-6b03-4914-a0f2-7fdf08b1cf98@sloti22d1t06> <32a1f0a3-6fb3-4858-82f9-abc27d526f82@sloti35d1t03> <4F1C8A0C-C3BA-454B-A85D-3AB37DAC12BE@staff.atmail.com> From: Tom Smith Message-ID: Date: Tue, 12 Jun 2018 10:13:42 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <4F1C8A0C-C3BA-454B-A85D-3AB37DAC12BE@staff.atmail.com> Content-Type: multipart/alternative; boundary="------------35C036172BBC5BDE3B57632F" Content-Language: en-US X-Atmail-Id: tom.smith@staff.atmail.com X-atmail-spam-CA-score: 0 X-atmail-spam-CA-bar: / X-atmail-spam-CA-report: X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: 0 X-CTCH-RefID: str=0001.0A020210.5B1F103E.0004, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-atmail-spam-score: -189 X-atmail-spam-bar: ------------------- Archived-At: Subject: Re: [Jmap] Fwd: New Version Notification for draft-murchison-jmap-websocket-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 00:13:54 -0000 This is a multi-part message in MIME format. --------------35C036172BBC5BDE3B57632F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit No, we use Server Sent Events, as per the original spec. https://www.w3schools.com/html/html5_serversentevents.asp Cheers, Tom. On 09/06/18 18:36, Dave Richards wrote: > Tom/Brad, do we do this, or are we pure WS? > > Dave > > > > On 9 Jun 2018, at 16:55, Neil Jenkins > wrote: > >> On Wed, 30 May 2018, at 11:31 PM, Ken Murchison wrote: >>>> * Should the server be allowed to advertise a different URL >>          for a websockets API connection as opposed to an HTTP one? >>> Sure.  I'll add a 'wsUrl' String to the capabilities. >> >> My question was genuine, I don't know whether this should be separate >> or the same. Does anyone here have experience running an API that's >> available over either websockets or HTTP? If so, would you normally >> put the websockets upgrade on the same URL, or a different one? >> Making it separate certainly gives you more flexibility, so seems >> like the right option to me, but I'd be interested if anyone has >> real-world experience. >> >>>> * Are responses guaranteed to be in the same order as >>          requests? (Probably not; if you want methods to execute >>          sequentially you should bundle them in a single request >>          object, but then how do you correlate the response objects to >>          the request objects? Probably need to add an id property to >>          the request/response object.) >>> >>> I had intended that they would be in the same order, but I suppose >>    out of order could be allowed if deemed necessary. >> >> I think you definitely want this. This allows you to do concurrent >> requests with a single websocket, avoiding the overhead and >> complexity of creating multiple websocket connections to the server. >> >>> >>> >>>> * I think being able to receive push events over the single >>          websocket connection makes sense, but that means you'd have to >>          be able to distinguish the different message types you might >>          receive (API response or push). >>> >>> Can't the client distinguish between a Response object and a >>    StateChange object?  If we need a better way, do you have a >>    recommendation? >> >> I would probably add an @type property to each top-level object >> (Response and StateChange) with the name of the type as the value. >> >>>> * What changes are required to rate limiting options for the >>          server? These probably need to be advertised in the >>          capabilities object for this extension. >>> Are you thinking that we need separate maxSizeRequest, >>    maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and >>    maxObjectsInSet for the WebSocket connection? >> >> No, these would still apply. It's more if you need extra ones: if you >> don't need to wait for a response to come back before issuing another >> request down the websocket, is this just counted as concurrent >> requests so subject to maxConcurrentRequests (I would say yes)? What >> about having multiple websocket connections at once? That probably >> needs a separate limit, because the request is no longer the same as >> the connection. Maybe maxConcurrentSockets or something. >> >> Neil. >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap --------------35C036172BBC5BDE3B57632F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

No, we use Server Sent Events, as per the original spec.

https://www.w3schools.com/html/html5_serversentevents.asp


Cheers,

Tom.



On 09/06/18 18:36, Dave Richards wrote:
Tom/Brad, do we do this, or are we pure WS?

Dave


On 9 Jun 2018, at 16:55, Neil Jenkins <neilj@fastmailteam.com> wrote:

On Wed, 30 May 2018, at 11:31 PM, Ken Murchison wrote:
* Should the server be allowed to advertise a different URL
         for a websockets API connection as opposed to an HTTP one?
Sure.  I'll add a 'wsUrl' String to the capabilities.

My question was genuine, I don't know whether this should be separate or the same. Does anyone here have experience running an API that's available over either websockets or HTTP? If so, would you normally put the websockets upgrade on the same URL, or a different one? Making it separate certainly gives you more flexibility, so seems like the right option to me, but I'd be interested if anyone has real-world experience.

* Are responses guaranteed to be in the same order as
         requests? (Probably not; if you want methods to execute
         sequentially you should bundle them in a single request
         object, but then how do you correlate the response objects to
         the request objects? Probably need to add an id property to
         the request/response object.)

I had intended that they would be in the same order, but I suppose
   out of order could be allowed if deemed necessary.

I think you definitely want this. This allows you to do concurrent requests with a single websocket, avoiding the overhead and complexity of creating multiple websocket connections to the server. 



* I think being able to receive push events over the single
         websocket connection makes sense, but that means you'd have to
         be able to distinguish the different message types you might
         receive (API response or push).

Can't the client distinguish between a Response object and a
   StateChange object?  If we need a better way, do you have a
   recommendation?

I would probably add an @type property to each top-level object (Response and StateChange) with the name of the type as the value.

* What changes are required to rate limiting options for the
         server? These probably need to be advertised in the
         capabilities object for this extension.
Are you thinking that we need separate maxSizeRequest,
   maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and
   maxObjectsInSet for the WebSocket connection?

No, these would still apply. It's more if you need extra ones: if you don't need to wait for a response to come back before issuing another request down the websocket, is this just counted as concurrent requests so subject to maxConcurrentRequests (I would say yes)? What about having multiple websocket connections at once? That probably needs a separate limit, because the request is no longer the same as the connection. Maybe maxConcurrentSockets or something.

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

--------------35C036172BBC5BDE3B57632F-- From nobody Mon Jun 11 19:33:55 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 8FE00130DD4 for ; Mon, 11 Jun 2018 19:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=qtQHIjVh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=u1ym7zwk 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 83_AgajdY_aR for ; Mon, 11 Jun 2018 19:33:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02262130DD2 for ; Mon, 11 Jun 2018 19:33:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3F01A21C08; Mon, 11 Jun 2018 22:33:49 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute6.internal (MEProxy); Mon, 11 Jun 2018 22:33:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=bLlU+PUFHIZxyRrydjfqgOuplCP6q5NzcvSN947rY zk=; b=qtQHIjVh37DEQrhtOFA+QWmIDTf9KH6/sZVbLM/Caomv1HcI1YSiWgKjc 6Mca2uX1Z4Dd09SaXyMZb76z3/TyTyO6mdp8s2ewshgdXkHGXB2zTOaaV/tymqn1 3CHcXO2HAIrHUZagFZA2mS7cUmSFvc9xxZPnNMZMiApZz/IWZrWzpxp6zrqgkd4K 6dbTdEd5zIxxy4gNgnsnhrmWxJT0sVgvqkKsI5s1PukRYm4no2zwKm7bnHOt+2I0 LAvWFAaoPKwAzZLHp0fZ7YvvZ+uAkO8Sm9Vz9jbDk9Wx5BOBHhTPHI6UVJ/DK9T7 UyIAQnr69Mq0hAek9mc7zMlo8QNDQ== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=bLlU+PUFHIZxyRrydjfqgOuplCP6q5NzcvSN947rY zk=; b=u1ym7zwkuIcgubCLBkNEjZd7L5GUaOj+aTHxF+jC3EOstH2siSlc3eAd5 ZjV/f9LuXacuYBxrnCCrEmRd3+a00GdTWT3VxryXgUrxPgPdU7mR25EZ2UchpOR7 /CSheGcsEY2p7v8LWg+6HzA4oLT77NcasdaEv2i6Ilpo2X8zzBZLVnTSEDxdM50v Fn8McxlpbrPvegCunDYfe6yIPK7NY7G8uQyD4wjGI3ag4qiG4+NasNhNRWeFUdHN VdM0Fz4Km1zlCDCrDvyAJeYGNorJJoB+wEliMTGou6CRdG4Pvfi5gqPZxDO3mAag DBc4xOYtlYv+KQSF/yLr8HE+KTIdA== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EE9B3C4501; Mon, 11 Jun 2018 22:33:48 -0400 (EDT) Message-Id: <31adb407-2673-4632-b936-74cbf1e4b861@sloti35d1t03> User-Agent: Cyrus-JMAP/3.1.3-653-gce35ffd-next x-jmap-identity-id: 64588216 In-Reply-To: References: <305ecac4-d5cb-2935-a1ef-e3dcc6823e0f@fastmail.com> <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> <113acf52-6b03-4914-a0f2-7fdf08b1cf98@sloti22d1t06> <32a1f0a3-6fb3-4858-82f9-abc27d526f82@sloti35d1t03> <4F1C8A0C-C3BA-454B-A85D-3AB37DAC12BE@staff.atmail.com> Date: Mon, 11 Jun 2018 22:33:34 -0400 From: Neil Jenkins To: Dave Richards , Tom Smith Cc: IETF JMAP Mailing List , brad@staff.atmail.com Content-Type: multipart/alternative; boundary=67ebdcaa84424b138fa8af65f3be182b Archived-At: Subject: Re: [Jmap] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-murch?= =?utf-8?q?ison-jmap-websocket-00=2Etxt?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 02:33:52 -0000 --67ebdcaa84424b138fa8af65f3be182b Content-Type: multipart/related; boundary=f0a14a63f4ca4e529f81885e796f3384 --f0a14a63f4ca4e529f81885e796f3384 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 12 Jun = 2018, at 10:13 AM, Tom Smith wrote:
<= div>No, we use Server Sent Events, as per the original spec.
https://www.w3schools.com/html/html5_serversentevents.asp

That's an interesting data point in wheth= er to send push events down the websocket, but I think the question Dave= was actually passing on was this one:

Does anyone here have experience running an API th= at's available over either websockets or HTTP? If so, would you normally= put the websockets upgrade on the same URL, or a different one? Making = it separate certainly gives you more flexibility, so seems like the righ= t option to me, but I'd be interested if anyone has real-world experienc= e.

Cheers,
Neil.=
--f0a14a63f4ca4e529f81885e796f3384-- --67ebdcaa84424b138fa8af65f3be182b Content-Type: text/plain On Tue, 12 Jun 2018, at 10:13 AM, Tom Smith wrote: > No, we use Server Sent Events, as per the original spec. > https://www.w3schools.com/html/html5_serversentevents.asp That's an interesting data point in whether to send push events down the websocket, but I think the question Dave was actually passing on was this one: > Does anyone here have experience running an API that's available over either websockets or HTTP? If so, would you normally put the websockets upgrade on the same URL, or a different one? Making it separate certainly gives you more flexibility, so seems like the right option to me, but I'd be interested if anyone has real-world experience. Cheers, Neil. --67ebdcaa84424b138fa8af65f3be182b-- From nobody Mon Jun 11 20:10: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 0FD5A130DE2 for ; Mon, 11 Jun 2018 20:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=staff.atmail.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 585tvzIAgkCF for ; Mon, 11 Jun 2018 20:10:15 -0700 (PDT) Received: from staff72.atmail.com (staff72.atmail.com [204.145.97.72]) (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 1AB28130F0F for ; Mon, 11 Jun 2018 20:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=staff.atmail.com; s=20160330; h=Content-Type:MIME-Version:Date:Message-ID: From:To:Subject; bh=fUnguVrtUImHMtWEEFSfxSZIubkzaftYDQbH1eKWZHA=; b=VInBTzIRz wzUEOwyJJme69ZqcUi0Lzmm6RX1Y4c6cQsbT732cfhheY0YY9VQGGKJBLfRdt5CaiCuNxNR9QjR5t LxGMOJraDC3SiZTK6C2A82sqt4r01PQAesCUKIEzFRaZSnndY2sUuOlt7GBZKABZ4UbGtgcqnC+iM FA4Bbghk=; Received: from 35.124.233.220.static.exetel.com.au ([220.233.124.35] helo=[172.16.254.117]) by hc0-dh-ro-aio-002.internal.atmailcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fSZgo-00083m-Iq; Tue, 12 Jun 2018 13:09:47 +1000 To: Neil Jenkins , Dave Richards , Tom Smith Cc: IETF JMAP Mailing List References: <305ecac4-d5cb-2935-a1ef-e3dcc6823e0f@fastmail.com> <42d9cdbc-338b-125b-4164-76dda81c81fa@fastmailteam.com> <152762434119.30187.891281157139219165.idtracker@ietfa.amsl.com> <113acf52-6b03-4914-a0f2-7fdf08b1cf98@sloti22d1t06> <32a1f0a3-6fb3-4858-82f9-abc27d526f82@sloti35d1t03> <4F1C8A0C-C3BA-454B-A85D-3AB37DAC12BE@staff.atmail.com> <31adb407-2673-4632-b936-74cbf1e4b861@sloti35d1t03> From: Brad Kowalczyk Message-ID: <6dda42f4-3a48-10ca-e9c6-a48cfa6284e4@staff.atmail.com> Date: Tue, 12 Jun 2018 13:10:08 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <31adb407-2673-4632-b936-74cbf1e4b861@sloti35d1t03> Content-Type: multipart/alternative; boundary="------------49D29ED80643FF8799B831A8" Content-Language: en-US X-Atmail-Id: brad.kowalczyk@staff.atmail.com X-atmail-spam-CA-score: 0 X-atmail-spam-CA-bar: / X-atmail-spam-CA-report: X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: 0 X-CTCH-RefID: str=0001.0A020212.5B1F3995.0061, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-atmail-spam-score: -189 X-atmail-spam-bar: ------------------- Archived-At: Subject: Re: [Jmap] Fwd: New Version Notification for draft-murchison-jmap-websocket-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 03:10:19 -0000 This is a multi-part message in MIME format. --------------49D29ED80643FF8799B831A8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit We use a separate URL e.g. https://somedomain.com/events for SSE as opposed to https://somedomain.com/api for the core JMAP API Cheers, Brad On 12/06/18 12:33, Neil Jenkins wrote: > On Tue, 12 Jun 2018, at 10:13 AM, Tom Smith wrote: >> No, we use Server Sent Events, as per the original spec. >> https://www.w3schools.com/html/html5_serversentevents.asp > > That's an interesting data point in whether to send push events down > the websocket, but I think the question Dave was actually passing on > was this one: > >> Does anyone here have experience running an API that's available over >> either websockets or HTTP? If so, would you normally put the >> websockets upgrade on the same URL, or a different one? Making it >> separate certainly gives you more flexibility, so seems like the >> right option to me, but I'd be interested if anyone has real-world >> experience. > > Cheers, > Neil. --------------49D29ED80643FF8799B831A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
We use a separate URL

e.g. https://somedomain.com/events for SSE as opposed to https://somedomain.com/api for the core JMAP API

Cheers,

Brad

On 12/06/18 12:33, Neil Jenkins wrote:
On Tue, 12 Jun 2018, at 10:13 AM, Tom Smith wrote:
No, we use Server Sent Events, as per the original spec.

That's an interesting data point in whether to send push events down the websocket, but I think the question Dave was actually passing on was this one:

Does anyone here have experience running an API that's available over either websockets or HTTP? If so, would you normally put the websockets upgrade on the same URL, or a different one? Making it separate certainly gives you more flexibility, so seems like the right option to me, but I'd be interested if anyone has real-world experience.

Cheers,
Neil.

--------------49D29ED80643FF8799B831A8-- From nobody Sun Jun 17 16:04:33 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 C869B130E62 for ; Sun, 17 Jun 2018 16:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ONIzjtCw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wIgmy2wH 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 3RH13Qdh_g-9 for ; Sun, 17 Jun 2018 16:04:29 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D5512F18C for ; Sun, 17 Jun 2018 16:04:28 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 239C221B0F for ; Sun, 17 Jun 2018 19:04:28 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 17 Jun 2018 19:04:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=J/hjpT7zmQ9fL7g9S a6i/FNJo2yMzCxFP1wzeMAs8WQ=; b=ONIzjtCwya9OksAzO8s0ZBor4ii4FNALS vHbj+XtHmAbG7VZEiwP3QoWwXSys9mpYHIB7S7uQGyhh+Y3pd9Nzg7J6YfN6cGXj Mncm0SG7tRGhgJs/kO4BXOaH98rWlmn1a6cfcGFdH440EiFloLhAQvLW0ZmSC/i+ sqV8P+jUKXkCQIqyjMtO5G2ffN3HCkB1RL4+wUhLdqlzfxVdTR5lRy2Hf3otJ5Db g4r1kq48uH0vqiMAv+mxuPTxpLy0d4iwBA6lsif8ImJa/6RSimgqVpkUw5Un45kV joGc2i1tbp+a7II5HkCKmtDsVv9d8utu3VFZhkJK6cCtF+SQvvYKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=J/hjpT 7zmQ9fL7g9Sa6i/FNJo2yMzCxFP1wzeMAs8WQ=; b=wIgmy2wH0MfDFf6CUJWWAx uRQIij4aXUrTeHWlmTDhIm0PPbgJHzqJtGbrmRli7F7xCcJUNNctUbyLbYingSGy IBd5frNWhODI9WPbO3ZkZfJn9cQ2LxF7odIXVIO6vKKb6siH/+DwoXViBhNsche1 aAGT3yHmNejspzClXzXXc4LsTbcJ8s95/THvd/gbWsP0M1SHiyOQI8jqPeoXnauy j3nCtnS/GqSgCGuGabQrktn9vizcPS/aODXokQQyKon6Z/Y7Wq/IhLpMCnx/W8KO M/FBdg2Hrhn+U31oiQhz6Jz7/3Xf4LKSPyBBp4xgr2SckdJqojTKKPAsw3+qXIOQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9F4B09E0B2; Sun, 17 Jun 2018 19:04:27 -0400 (EDT) Message-Id: <1529276667.1505351.1411107456.5AFD49AA@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152927666715053510" X-Mailer: MessagingEngine.com Webmail Interface - ajax-498d70f2 Date: Mon, 18 Jun 2018 09:04:27 +1000 References: In-Reply-To: Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 23:04:32 -0000 This is a multi-part message in MIME format. --_----------=_152927666715053510 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tue, Jun 12, 2018, at 09:57, Beno=C3=AEt TELLIER wrote: >=20 > IMO having the changes events aggregated is a strength. It is easy to > implement on the server side as well as provides a full history to the > clients (avoids merging creations, updates & deletions together, even > if this is trivial).>=20 > However, I'm doubtful concerning implementing state tracking only with > the MODSEQ mechanism: the MODSEQ is a property relative to a MAILBOX > and thus is not adapted in response to a email/get request that will > return email from different mailboxes. You could end up with two email > in different mailbox having the same MODSEQ. Having a MODSEQ global to > the all account seems the only viable way out to achieve this here, > but it is, in my opinion, a very strong assertion. That's why we have a global per-account modseq in Cyrus IMAP now :) It was quite trivial to do, just jumping the per-mailbox highestmodseq each time, for example Mailbox A: HMS:500 EXISTS:20 Mailbox B: HMS:600 EXISTS:5 Global: HMS:700 Append a new message to Mailbox A. New state is: Mailbox A: HMS:701 EXISTS:21 Mailbox B: HMS:600 EXISTS:5 Global HMS:701 I've examined all the assertions in the CONDSTORE and QRESYNC standards and there's nothing that says that modseqs on a particular mailbox need to be contiguous, so this worked well for us :) > Hence, I'd advocate that additional information needs to be stored > anyway. I see no obstacles to enhancing /changes response to allow the > client to distinguish additions from changes. Cool - I'll have a look at what's involved in doing it in Cyrus, or get Robert to when he's back. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152927666715053510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"



On Tue, Jun 12, 2018, at 09:57, Beno=C3=AEt TELLIER wrote:


IMO having the changes events aggre= gated is a strength. It is easy to implement on the server side as well as = provides a full history to the clients (avoids merging creations, updates &= amp; deletions together, even if this is trivial).


How= ever, I'm doubtful concerning implementing state tracking only with the MOD= SEQ mechanism: the MODSEQ is a property relative to a MAILBOX and thus is n= ot adapted in response to a email/get request tha= t will return email from different mailboxes. You could end up with two ema= il in different mailbox having the same MODSEQ. Having a MODSEQ global to t= he all account seems the only viable way out to achieve this here, but it i= s, in my opinion, a very strong assertion.


That's why we have a global per-account m= odseq in Cyrus IMAP now :)  It was quite trivial to do, just jumping t= he per-mailbox highestmodseq each time, for example

Mailbox A: HMS:500 EXISTS:20
Mailbox B: HMS:600 EXISTS:5
Global: HMS:700

Append a new message to Mailbox A.  = New state is:

Mailbox A: HMS:701 EXISTS:21
Mailbox B: HMS:600 EXISTS:5
Global HMS:701

I've examined all the assertions in the C= ONDSTORE and QRESYNC standards and there's nothing that says that modseqs o= n a particular mailbox need to be contiguous, so this worked well for us :)=

Hence, I'd advocate that additional informatio= n needs to be stored anyway. I see no obstacles to enhancing /c= hanges response to allow the client to distinguish additions = from changes.


Cool - I'll have a look at what's involve= d in doing it in Cyrus, or get Robert to when he's back.

Cheers,

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


--_----------=_152927666715053510-- From nobody Wed Jun 20 00:07: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 0FB7212D949 for ; Wed, 20 Jun 2018 00:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=LpXpgMUu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jpB3/1hn 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 lGUECEWfFklZ for ; Wed, 20 Jun 2018 00:07:10 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA380131050 for ; Wed, 20 Jun 2018 00:07:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1EA2221CA1 for ; Wed, 20 Jun 2018 03:07:10 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute6.internal (MEProxy); Wed, 20 Jun 2018 03:07:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Yw7s6Docmc4rqtMc1udHmQSWlv9jjykkcJB043/Fh Gc=; b=LpXpgMUuepvdKOVD4O4kYn4khq0bUm/c/uX28HusOlwelGaIMtQkb2IAH 1ELQUDNXv1uN6axV7qzfI3zCZmaim5IF+vREO6C+R3KqDbky8vtL+6ZTGIMw4SBh 5iEGYNxopsdeXn426Dql9hIQ1HXOkS8/x1x6CsIDb5EiOcMlLtd1zbn6+L54JLXF LdRYdvH8b+QJAwP4aPKsbhDNr8eQxHo4L9D26VOUnZiyFU+afGzuV9ju8bKBc9oR FBaknZpG0fwL/CfCVcbmaxF1Xok9C7yMCQm0jdPZTLcEIFGHck6Rgt+zoyhqgYLj RuwjL9QlyobcCQTxsCl1qneISQhkg== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Yw7s6Docmc4rqtMc1udHmQSWlv9jjykkcJB043/Fh Gc=; b=jpB3/1hn1huDe3ZbhKzjyjQ0NZhzAA1jcxZp6Lmx1hQrg4XKjqQpjYTDZ pV3va1aSpVQ08M9iN+n/l+ZtJImyfsNlAAqCfjfg1AG2RhA8lH5Z6rfpBbSirry6 T+mofstXP1adm0uuWK2s57RZAfGNq6vbZXvafCHXo8+TZrfuBauxa5r0cgfvKwYi gIkvOJC0e+wmRZ2nw21rdcNzax4TwoYHBUaO4W6dW2m8TjYVIpefCjx9ZlncqCMg UP3HIMmTlHSJXVFQJ4gZISmXmuZ8x1pIdYr8KiQEKUVzYpqEVCks8535RTdjGg0r P/FMMjSKnO0ffeMOKq7Vw4JTzYNYQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C95BFC4519; Wed, 20 Jun 2018 03:07:09 -0400 (EDT) Message-Id: <6297656c-332d-4c10-b070-425ac1e8c119@sloti35d1t03> User-Agent: Cyrus-JMAP/3.1.3-653-gce35ffd-next x-jmap-identity-id: 64588216 In-Reply-To: <1529276667.1505351.1411107456.5AFD49AA@webmail.messagingengine.com> References: <1529276667.1505351.1411107456.5AFD49AA@webmail.messagingengine.com> Date: Wed, 20 Jun 2018 03:07:00 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=3c7a0b6f6b1b4a3bad23496527337105 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 07:07:12 -0000 --3c7a0b6f6b1b4a3bad23496527337105 Content-Type: multipart/related; boundary=b4f614e813fc453b8ddef6234b9195f3 --b4f614e813fc453b8ddef6234b9195f3 Content-Type: text/html
Since the consensus seems to be for splitting "changed" into "created" and "updated", I've made a pull request with this. Please review and if there are no objections, I'll merge next week.

Neil.
--b4f614e813fc453b8ddef6234b9195f3-- --3c7a0b6f6b1b4a3bad23496527337105 Content-Type: text/plain Since the consensus seems to be for splitting "changed" into "created" and "updated", I've made a pull request with this . Please review and if there are no objections, I'll merge next week. Neil. --3c7a0b6f6b1b4a3bad23496527337105-- From nobody Tue Jun 26 19:04:33 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 33666126DBF for ; Tue, 26 Jun 2018 19:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=G+jS5B9e; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PdVec6pB 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 VdK0Zcz4H7KT for ; Tue, 26 Jun 2018 19:04:27 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838C9130E72 for ; Tue, 26 Jun 2018 19:04:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B8C3B21E90 for ; Tue, 26 Jun 2018 22:04:26 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Tue, 26 Jun 2018 22:04:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mqktvMVaBfm3DcszY oYEGMh2z1envH7AfVI0Iy6vKG0=; b=G+jS5B9e2bL39glEHCQIEUm5S7OEkAXdF GqMHYIZ6I1lnayvdcTRpXLgJqHgjZWUVIEMwXU0L9N3GBBn4W4ktRjcsD4gp9gT1 pwNUXo4HkM/q8O0Q6Vfv5sUnILBMDKzU3+Ivy5kjc3xsEgK/0eGasMNm6S33//os 7+10MUNxz7NSTOtoin89lvQ3JGSMWIV3x1BBybkWKVRCF2jhnc5JDQ1oiW0r+Xrz 1CqJxBUmkQYlKnmlNtQiHR9RoUwLxIgOjx011zBzgagYPkd9DMyjYihplhMdBEcf On9p3bFYA4HgXkHqKjZ04o5gvJcLSf67nljGrwCF4VMC8IWF07J9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mqktvMVaBfm3Dc szYoYEGMh2z1envH7AfVI0Iy6vKG0=; b=PdVec6pBVfoG88EMXwFuwv/IVPaITp KKDuIpsAvqd64QWbH4IWfe+BbSvpngJSUbwXmuDG+p06SW1SMfJmWTMPylCiLh2v pUp2VFyHh/BpdlJdOTAdq62azyQR9xvh7QEeUg2/klrV/+4aBnBa8nWRIhro79Mk ZEKRjf+unp1NYsHBmNpVVFxh5zO4CIC87mZCMYHgi33r37QZcAcX8M4EBm1ceFc6 hrkLmqZGtAXbjMLuyIqtC7RKpCLz5Xzh+WOq5wJBTPTrdUkLrGbKIQr/9nIgH/re Y+hxFo6Qjo7Kx6FpCeMBhv2AaqpbFSQuetjxLl6wq7p6VFgmnzO7LCGQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 71657CA2C8; Tue, 26 Jun 2018 22:04:26 -0400 (EDT) Message-Id: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-653-gce35ffd-next x-jmap-identity-id: 64588216 Date: Tue, 26 Jun 2018 22:03:56 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=ada88a8f443445789683b1ac176a19bd Archived-At: Subject: [Jmap] PushSubscription lifetimes X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 02:04:30 -0000 --ada88a8f443445789683b1ac176a19bd Content-Type: multipart/related; boundary=149ea8c6ad2d45d7b236261434ef9237 --149ea8c6ad2d45d7b236261434ef9237 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Neil Jhave= ri raised a good point about Push subscriptions: at the moment you can o= nly have a single subscription per "session". The concept of a session h= owever is no longer defined since we took auth out of the spec, so I thi= nk we need to change this.

There is an inte= resting question here of should one client be allowed to see the Push Su= bscription objects created by another client? I would say ideally "no", = both for user privacy and to stop one client interfering with another (y= ou install app B and it deletes all push subscriptions so you no longer = get pushes on app A; that would be weird). This used to be enforced by t= he sessions (each client created its own session when it logged in, and = could only get/set a single push subscription which was tied to the sess= ion). With this no longer the case, I suggest we change this to:
  • PushSubscription becomes a standard type allowing multiple ins= tances, but with no /query and fetching only allowed by specific id (can= 't request all with `ids: null`).
  • Servers MUST ensure ids al= located are random with sufficient entropy to make them hard to guess.&n= bsp;Clients MUST keep track of the id returned when they create a push s= ubscription in order to be able to update or destroy it.
  • Whe= n the credentials set by the client have their own expiry (i.e. it is a = session with a timeout), the server SHOULD NOT set an explicit expiry fo= r the push subscription, but MUST expire it when the session expires.
  • When the credentials are not time bounded (e.g. basic auth), t= he server SHOULD set an expiry time for the push subscription. This MUST= be at least 24h in the future.
  • Clients can do a standard JM= AP update to the expiry time to extend the lifetime of a push subscripti= on.

Some kind of rate limiting needs to= be in place here now it's no longer a single push subscription per sess= ion. Again, the trouble is preventing different clients from interfering= with each other. If you just expire the oldest subscriptions when there= are >X, you can get a single client creating a flood and affecting o= ther clients. Not sure this is avoidable though; I guess just note in th= e spec that when using session-based authentication, the limit should be= per-session to isolate clients behaviour from each other.

Any thoughts, queries, feedback on all this?
<= br>
Neil.
--149ea8c6ad2d45d7b236261434ef9237-- --ada88a8f443445789683b1ac176a19bd Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Neil Jhaveri raised a good point about Push subscriptions: at the moment= you can only have a single subscription per "session". The concept of a= session however is no longer defined since we took auth out of the spec= , so I think we need to change this. There is an interesting question here of should one client be allowed to= see the Push Subscription objects created by another client? I would sa= y ideally "no", both for user privacy and to stop one client interfering= with another (you install app B and it deletes all push subscriptions s= o you no longer get pushes on app A; that would be weird). This used to = be enforced by the sessions (each client created its own session when it= logged in, and could only get/set a single push subscription which was = tied to the session). With this no longer the case, I suggest we change = this to: * PushSubscription becomes a standard type allowing multiple instances,= but with no /query and fetching only allowed by specific id (can't requ= est all with `ids: null`). * Servers MUST ensure ids allocated are random with sufficient entropy = to make them hard to guess.=C2=A0Clients MUST keep track of the id retur= ned when they create a push subscription in order to be able to update o= r destroy it. * When the credentials set by the client have their own expiry (i.e. it= is a session with a timeout), the server SHOULD NOT set an explicit exp= iry for the push subscription, but MUST expire it when the session expir= es. * When the credentials are not time bounded (e.g. basic auth), the serv= er SHOULD set an expiry time for the push subscription. This MUST be at = least 24h in the future. * Clients can do a standard JMAP update to the expiry time to extend th= e lifetime of a push subscription. Some kind of rate limiting needs to be in place here now it's no longer = a single push subscription per session. Again, the trouble is preventing= different clients from interfering with each other. If you just expire = the oldest subscriptions when there are >X, you can get a single client = creating a flood and affecting other clients. Not sure this is avoidable= though; I guess just note in the spec that when using session-based aut= hentication, the limit should be per-session to isolate clients behaviou= r from each other. Any thoughts, queries, feedback on all this? Neil. --ada88a8f443445789683b1ac176a19bd-- From nobody Tue Jun 26 19:13:42 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 E5622130E72 for ; Tue, 26 Jun 2018 19:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=kzwE+avi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qGYTaG70 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 DqbXYzkkUTpf for ; Tue, 26 Jun 2018 19:13:39 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED540126DBF for ; Tue, 26 Jun 2018 19:13:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6038621E5F for ; Tue, 26 Jun 2018 22:13:38 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 26 Jun 2018 22:13:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=oWsRJJn8y5202fl77 3NVqrHNNGZQ0e7Xi77HjW7KJPc=; b=kzwE+aviJQWilZ52nARn4VLZ4GZP49Vgn 6EvmrpxJXeltbvZ9K9K2tI3/vg0E/pz5NMnBeoAlzGcC4rWxnDrzvwvfcq/x/29d LsBq9xgKjF38l8rMQ4P96tRVm6Ng8NR0rz2qOIsSiz57ivfcavxcnGOsry6XpEkC Lu7vWQ3GzHRRkbuQZTB3neIQVr7o1a92Q/1NV6lXHDSLuw0GoLaKsmFhPHqeDVKm sDJIYaBm8ZEj4nL97sw8l4JN2ZUJA6z0NcssXPzISUTRNOQSwi8+Em6RAC8Eoumy aLpf1ShlDGsnhlps9kd6JUlemic2CNQBNyvwnRNrHv8KZHJu6B5Vg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=oWsRJJ n8y5202fl773NVqrHNNGZQ0e7Xi77HjW7KJPc=; b=qGYTaG70P4Tuz3uKU/Jkfe /FG8MtuWVJrl2koKFWfv4pTQZzQFbyuU+FluWwsPHnz8hDPh9u1RXDn0aIS7d+uw BA0yNT0OmL+PKQt528YcKT1yyk3XytZnsnd9dIrPN6SMbXHlIbsDgucgGwyQGybf H3oyOpEkP6KnRxufZGvrHBzqyDFv0ta8SMiou0UnN7PNXgpzWdYegWom7OHxuRsW P9K5ie4TwiZdZNE+4rUPuiqXwgjClxMNQhgmGLGRFbMYQAKioBFbRwBKB+kieH5N A0aZ1zPfgZqc3w24ZLq7KX16DuQq2gH3MIPM1vu3QeGmZc87aT6Ul+pNEXARNHHg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 24FDC621DC; Tue, 26 Jun 2018 22:13:38 -0400 (EDT) Message-Id: <1530065618.868906.1421638008.322AD26E@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15300656188689064" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Wed, 27 Jun 2018 12:13:38 +1000 In-Reply-To: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> References: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> Archived-At: Subject: Re: [Jmap] PushSubscription lifetimes X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 02:13:41 -0000 This is a multi-part message in MIME format. --_----------=_15300656188689064 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, Jun 27, 2018, at 12:03, Neil Jenkins wrote: > Neil Jhaveri raised a good point about Push subscriptions: at the > moment you can only have a single subscription per "session". The > concept of a session however is no longer defined since we took auth > out of the spec, so I think we need to change this.> > There is an interesting question here of should one client be allowed > to see the Push Subscription objects created by another client? I > would say ideally "no", both for user privacy and to stop one client > interfering with another (you install app B and it deletes all push > subscriptions so you no longer get pushes on app A; that would be > weird). This used to be enforced by the sessions (each client created > its own session when it logged in, and could only get/set a single > push subscription which was tied to the session). With this no longer > the case, I suggest we change this to: > * PushSubscription becomes a standard type allowing multiple > instances, but with no /query and fetching only allowed by specific > id (can't request all with `ids: null`). > * Servers MUST ensure ids allocated are random with sufficient > entropy to make them hard to guess. Clients MUST keep track of the > id returned when they create a push subscription in order to be > able to update or destroy it. > * When the credentials set by the client have their own expiry (i.e. > it is a session with a timeout), the server SHOULD NOT set an > explicit expiry for the push subscription, but MUST expire it when > the session expires. > * When the credentials are not time bounded (e.g. basic auth), the > server SHOULD set an expiry time for the push subscription. This > MUST be at least 24h in the future. > * Clients can do a standard JMAP update to the expiry time to extend > the lifetime of a push subscription.> > Some kind of rate limiting needs to be in place here now it's no > longer a single push subscription per session. Again, the trouble is > preventing different clients from interfering with each other. If you > just expire the oldest subscriptions when there are >X, you can get a > single client creating a flood and affecting other clients. Not sure > this is avoidable though; I guess just note in the spec that when > using session-based authentication, the limit should be per-session to > isolate clients behaviour from each other.> > Any thoughts, queries, feedback on all this? If a client loses its local data, this pretty much guarantees there's no way to clean up that push subscription until it times out, and if that's a push to a device, it's going to keep waking said device for every push with no way to fix it :( Personally I think the clients of a single user should use reasonable behaviour to not screw with each other, but the data should be exposed over the protocol such that they can clean up (e.g. putting a device ID and software manufacturer into each push, so clients can find all the pushes for this device and this piece of software). You're already no entirely isolating client behaviour from each other. Clients can do things like create new folders, move messages around in clever ways, auto-tag messages... there's an expectation that software does reasonable things and making push subscriptions hidden in some way seems wrong to me. Set behavioural expectations on clients rather than make it impossible for them to handle lost local storage. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15300656188689064 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, Jun 27, 2018, at 12:03, Neil Jenkins wrote:
Neil Jhaveri raised a good point about Push subscriptions: at the moment you can only have a single subscription per "session". The concept of a session however is no longer defined since we took auth out of the spec, so I think we need to change this.

There is an interesting question here of should one client be allowed to see the Push Subscription objects created by another client? I would say ideally "no", both for user privacy and to stop one client interfering with another (you install app B and it deletes all push subscriptions so you no longer get pushes on app A; that would be weird). This used to be enforced by the sessions (each client created its own session when it logged in, and could only get/set a single push subscription which was tied to the session). With this no longer the case, I suggest we change this to:
  • PushSubscription becomes a standard type allowing multiple instances, but with no /query and fetching only allowed by specific id (can't request all with `ids: null`).
  • Servers MUST ensure ids allocated are random with sufficient entropy to make them hard to guess. Clients MUST keep track of the id returned when they create a push subscription in order to be able to update or destroy it.
  • When the credentials set by the client have their own expiry (i.e. it is a session with a timeout), the server SHOULD NOT set an explicit expiry for the push subscription, but MUST expire it when the session expires.
  • When the credentials are not time bounded (e.g. basic auth), the server SHOULD set an expiry time for the push subscription. This MUST be at least 24h in the future.
  • Clients can do a standard JMAP update to the expiry time to extend the lifetime of a push subscription.

Some kind of rate limiting needs to be in place here now it's no longer a single push subscription per session. Again, the trouble is preventing different clients from interfering with each other. If you just expire the oldest subscriptions when there are >X, you can get a single client creating a flood and affecting other clients. Not sure this is avoidable though; I guess just note in the spec that when using session-based authentication, the limit should be per-session to isolate clients behaviour from each other.

Any thoughts, queries, feedback on all this?

If a client loses its local data, this pretty much guarantees there's no way to clean up that push subscription until it times out, and if that's a push to a device, it's going to keep waking said device for every push with no way to fix it :(

Personally I think the clients of a single user should use reasonable behaviour to not screw with each other, but the data should be exposed over the protocol such that they can clean up (e.g. putting a device ID and software manufacturer into each push, so clients can find all the pushes for this device and this piece of software).

You're already no entirely isolating client behaviour from each other.  Clients can do things like create new folders, move messages around in clever ways, auto-tag messages... there's an expectation that software does reasonable things and making push subscriptions hidden in some way seems wrong to me.  Set behavioural expectations on clients rather than make it impossible for them to handle lost local storage.

Bron.

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


--_----------=_15300656188689064-- From nobody Tue Jun 26 19:28: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 2A5A4130E72 for ; Tue, 26 Jun 2018 19:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=thDnjNWe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ih+7Gf3d 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 fucaB9Z48xm2 for ; Tue, 26 Jun 2018 19:28:18 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351B9126F72 for ; Tue, 26 Jun 2018 19:28:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9C83F20FEF for ; Tue, 26 Jun 2018 22:28:17 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Tue, 26 Jun 2018 22:28:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=GHGO5UOo/0UtLHUwikwJ0obv9zwIq41WZUIT8qOHQ lQ=; b=thDnjNWeoHw1W1V3WBa6o9aA3ERTazq/wwAYJzGMjZnnnc0PFhXB9kEoG +pMm1FvSyNe7yZTGHx+mvWLYlu3ALyR3TN0NLZyc7FSGR0AjdUpSXCFQC5nTR+Q1 +R7QT90ao4BcieWhZiDJd9BLvS5ojpSLHW2l9s/pEsvwk1telTf9tuIzllH6mfUw JvunU5tRKn5r1nNxTniwnQNcoCCYYKajI+IX1CIxNGym8c+bwNm4FIQdJ5+/bsBQ GWxRDBAhYIhW+uZA+Dx5zYzQHRUM0FmZtNxUuzd2aEQeLzidg0IbyfR8CdJ4pqIA fiUsAesEH/3WcXKAjCMJ4hzxrZzBA== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=GHGO5UOo/0UtLHUwikwJ0obv9zwIq41WZUIT8qOHQ lQ=; b=Ih+7Gf3dx84kJho3ZFy8K+Evs2JWbjrTopshPfPBQUlxC/r9e5yBC+vJS LHxKSG1exeUOrYp6Va+IDBaBVeTjMppM6DLOUsCi2BSnbKb6dYCf55Qu27ZUNqWG oql4hLYQJLrL9FiCMF+5XqJ7XFmZjGb84Eji0NrXg0U0mq84M+SJk4SLybS7nLFR zViBnZ8cIf5uVnyhk+LMhuwn9qELGlZgCv1pCEsgzI5s6vxC4Zv3xHroCXkSHNZh y1f3pyHKktosXvU0qUOUlm3SUZ3yxbPq0N+kMhFXR3uvz8vQfp1aw2s5CBOwRJDy nHJETzqbOB/uc+NAIgdxH30SVYA7Q== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 59D0ACA2C8; Tue, 26 Jun 2018 22:28:17 -0400 (EDT) Message-Id: <129d366e-b84f-4d68-b6e1-0a52672f6915@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-653-gce35ffd-next x-jmap-identity-id: 64588216 In-Reply-To: <1530065618.868906.1421638008.322AD26E@webmail.messagingengine.com> References: <1530065618.868906.1421638008.322AD26E@webmail.messagingengine.com> <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> Date: Tue, 26 Jun 2018 22:28:16 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=ec4da485b3af4ce78fb53487839b93e6 Archived-At: Subject: Re: [Jmap] PushSubscription lifetimes X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 02:28:19 -0000 --ec4da485b3af4ce78fb53487839b93e6 Content-Type: multipart/related; boundary=748d7b95bf484466bc1072d3b31b83f7 --748d7b95bf484466bc1072d3b31b83f7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, 27= Jun 2018, at 12:13 PM, Bron Gondwana wrote:
If a cli= ent loses its local data, this pretty much guarantees there's no way to = clean up that push subscription until it times out, and if that's a push= to a device, it's going to keep waking said device for every push with = no way to fix it :(

That's a f= air point.

Personally I think the clients= of a single user should use reasonable behaviour to not screw with each= other, but the data should be exposed over the protocol such that they = can clean up (e.g. putting a device ID and software manufacturer into ea= ch push, so clients can find all the pushes for this device and this pie= ce of software).

A device id w= ould work (something random but persistent from the client). I guess the= question is are the following properties sensitive enough that they sho= uld not be returned (again to stop other clients finding their values):<= br>
  • url (This contains some kind of secret token to = allow you to route a push message to the device that created the subscri= ption).
  • keys (The public key + auth secret for encryp= ting the push; given it's a public key this is probably less of an issue= ?).
This would be doable (you always just return the empty= string for the url if you /get a PushSubscription).

<= /div>
Neil.
--748d7b95bf484466bc1072d3b31b83f7-- --ec4da485b3af4ce78fb53487839b93e6 Content-Type: text/plain On Wed, 27 Jun 2018, at 12:13 PM, Bron Gondwana wrote: > If a client loses its local data, this pretty much guarantees there's no way to clean up that push subscription until it times out, and if that's a push to a device, it's going to keep waking said device for every push with no way to fix it :( That's a fair point. > Personally I think the clients of a single user should use reasonable behaviour to not screw with each other, but the data should be exposed over the protocol such that they can clean up (e.g. putting a device ID and software manufacturer into each push, so clients can find all the pushes for this device and this piece of software). A device id would work (something random but persistent from the client). I guess the question is are the following properties sensitive enough that they should not be returned (again to stop other clients finding their values): * *url* (This contains some kind of secret token to allow you to route a push message to the device that created the subscription). * *keys* (The public key + auth secret for encrypting the push; given it's a public key this is probably less of an issue?). This would be doable (you always just return the empty string for the url if you /get a PushSubscription). Neil. --ec4da485b3af4ce78fb53487839b93e6-- From nobody Tue Jun 26 19:32:27 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 638B6130E7E for ; Tue, 26 Jun 2018 19:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=yp51mFFx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TqH3aqkP 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 I35W__2JjSFl for ; Tue, 26 Jun 2018 19:32:22 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284C2126F72 for ; Tue, 26 Jun 2018 19:32:22 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 83F7721D39 for ; Tue, 26 Jun 2018 22:32:21 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 26 Jun 2018 22:32:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=6MkMKb/YPtiq8P5nV WNb2PcNO+MmW+YOQyBgwP+ADtk=; b=yp51mFFxFyqgoqMRZhSV5JWZJXTfdwKpi /zgjjAu+vw8KZh3+et06q223+J/v6zDdEEMQptSkDZB5ni6sYm//aZ64NjEslB5k acdcAEn5bvnqbJR68HfVGIpwN655arTj+qSbz2dYsmqWnGGNgeoFlD57C645wKvk OFs5Eg19jEN/rXA8U8CbZo10dCxMca6MOsi8verPrgu1EOyXZB7JO1d8ADYC/Svx G6Sk8RWwVqkCERRytms0O+enTymhiPVIe6CnkiJdDRfNidICEuwGSuyANg53UwIV X7CvfEYzU+PloR6pBgpweHr8qTMFMVYW8oIo0//DnFyHy/9ltv6kg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=6MkMKb /YPtiq8P5nVWNb2PcNO+MmW+YOQyBgwP+ADtk=; b=TqH3aqkPyQBzlI02LyXyGR 8oNIYrklfpS25M7Mi+zYRVkwRWFayJ6bzn08igueAGchIfAiB9tLUC3o4nTU9jAQ TifR7rA2t4e3/E8rtQCUY29hzv2kAUjh/qGjlFG3xy8w3aMFaceP3tXIsN3MPCUV S5qvKOliAjuLtl+iA/SsJQQreh9+7aK6uPLazorqNb/PRWpuPIdBzUloUnJKW3hm nlJdgzjcPbu6XxncHF4orEht46xt1Pi+sBY6HYAUPU/X8JSWfO9y1FryUBu+sX5g 3/Ub8nLPrKBHBGf7E6iGdvpSmgVcIlEHPRbzI0ppi1YdQcm9a32q7L0abUVxO96Q == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4C4AD621E6; Tue, 26 Jun 2018 22:32:21 -0400 (EDT) Message-Id: <1530066741.874171.1421652272.148F6D36@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15300667418741710" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c References: <1530065618.868906.1421638008.322AD26E@webmail.messagingengine.com> <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> <129d366e-b84f-4d68-b6e1-0a52672f6915@sloti22d1t06> In-Reply-To: <129d366e-b84f-4d68-b6e1-0a52672f6915@sloti22d1t06> Date: Wed, 27 Jun 2018 12:32:21 +1000 Archived-At: Subject: Re: [Jmap] PushSubscription lifetimes X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 02:32:26 -0000 This is a multi-part message in MIME format. --_----------=_15300667418741710 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, Jun 27, 2018, at 12:28, Neil Jenkins wrote: > On Wed, 27 Jun 2018, at 12:13 PM, Bron Gondwana wrote: >> If a client loses its local data, this pretty much guarantees there's >> no way to clean up that push subscription until it times out, and if >> that's a push to a device, it's going to keep waking said device for >> every push with no way to fix it :(> > That's a fair point. > >> Personally I think the clients of a single user should use reasonable >> behaviour to not screw with each other, but the data should be >> exposed over the protocol such that they can clean up (e.g. putting a >> device ID and software manufacturer into each push, so clients can >> find all the pushes for this device and this piece of software).> > A device id would work (something random but persistent from the > client). I guess the question is are the following properties > sensitive enough that they should not be returned (again to stop other > clients finding their values): You want both a device ID (something that the client can get from the device in a repeatable way) and a software ID (so that if the user has two different clients installed on their device they can avoid trampling each other). The core problem with the client having to store anything locally is that said data can be removed in various circumstances (e.g. private tabs in a browser, e.g. android and "wipe app data"). > * *url* (This contains some kind of secret token to allow you to > route a push message to the device that created the subscription). > * *keys* (The public key + auth secret for encrypting the push; given > it's a public key this is probably less of an issue?).> This would be doable (you always just return the empty string for the > url if you /get a PushSubscription). Definitely hiding anything password-equivalent on get is sensible. Mostly the client just needs to know which ones it can clean up/replace when creating a new push. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15300667418741710 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, Jun 27, 2018, at 12:28, Neil Jenkins wrote:
On Wed, 27 Jun 2018, at 12:13 PM, Bron Gondwana wrote:
If a client loses its local data, this pretty much guarantees there's no way to clean up that push subscription until it times out, and if that's a push to a device, it's going to keep waking said device for every push with no way to fix it :(

That's a fair point.

Personally I think the clients of a single user should use reasonable behaviour to not screw with each other, but the data should be exposed over the protocol such that they can clean up (e.g. putting a device ID and software manufacturer into each push, so clients can find all the pushes for this device and this piece of software).

A device id would work (something random but persistent from the client). I guess the question is are the following properties sensitive enough that they should not be returned (again to stop other clients finding their values):

You want both a device ID (something that the client can get from the device in a repeatable way) and a software ID (so that if the user has two different clients installed on their device they can avoid trampling each other).

The core problem with the client having to store anything locally is that said data can be removed in various circumstances (e.g. private tabs in a browser, e.g. android and "wipe app data").

  • url (This contains some kind of secret token to allow you to route a push message to the device that created the subscription).
  • keys (The public key + auth secret for encrypting the push; given it's a public key this is probably less of an issue?).
This would be doable (you always just return the empty string for the url if you /get a PushSubscription).

Definitely hiding anything password-equivalent on get is sensible.  Mostly the client just needs to know which ones it can clean up/replace when creating a new push.

Bron.

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


--_----------=_15300667418741710-- From nobody Tue Jun 26 19:38:03 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 D2A1C130E7F for ; Tue, 26 Jun 2018 19:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RoVcUFTH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DdIgj2fi 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 NLRPsrhd_3_u for ; Tue, 26 Jun 2018 19:37:59 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6831E126F72 for ; Tue, 26 Jun 2018 19:37:59 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A383621D00 for ; Tue, 26 Jun 2018 22:37:58 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Tue, 26 Jun 2018 22:37:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=mBLZOi4WTij3s+nLi/IeCV4JOanikm/FwJ17frZXu Wk=; b=RoVcUFTHlnZzYBija2KmaNKsWdFeKHVxKv14hpJY+G7ugWWHLpYNhzkJY ltU8EqEn+eyqI4Jdur4yuSWPY+kPfoVHhqFmeq0Ukj/y+M33UO/4CDhf5z9/y2Dg yLGVEipbqY+kytE9CmR0uUvGEFrqZq9ajRpLpQ+5q+/ijNWPCGfzefmQhtSLe2/l BtPEtBzUp7yLzJkrEhmd4DpRRkfGz4JF6wO8bsJ9Efv6puE1/Jn73ZelV6QdU1Tc EQ28uSutGUDsAG24Huk881EZzNp10JbS61LaMFrPMsRl3sviCxbgz01V33754aoZ YCaKv+3K6xAiSZ+zc+TEGjUbrHpTg== 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-sender:x-me-sender :x-sasl-enc; s=fm3; bh=mBLZOi4WTij3s+nLi/IeCV4JOanikm/FwJ17frZXu Wk=; b=DdIgj2fiYbrjflnp4SyD24DfMTvwuf9XngQSzY3gxOvqlL5BdBS/gkhy6 LwjP1/Xmf7WLy4FTRgDk2UBx2f9GgPc6nd1NOanRAN8jbMK1XYwcwYo32RvQ2+aN TZtlDQ+dP2qzFYLPQR2SvfqCaiOis3uw7UVxTBygtJEY4FlOfzKRk2xoeUnXKSvD JW/TwtvIFEvKA55IPgdmpEOFemfS76WRerxWZC2lfDqJ5aSVO8PPoSRw2XS/JQTn esH7XD6SO/W4iEYuWxB0zJikbxWO3W4lT5T6H6hZ/Czp9RhJX3RK9m/NxAIrSCsD gOJOXTPdf5Ci/Cp50vlGfFbSzQD/A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 68541CA2C8; Tue, 26 Jun 2018 22:37:58 -0400 (EDT) Message-Id: <0f84b571-eab0-464b-b665-bd5203ea42e3@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-653-gce35ffd-next x-jmap-identity-id: 64588216 In-Reply-To: <1530066741.874171.1421652272.148F6D36@webmail.messagingengine.com> References: <1530066741.874171.1421652272.148F6D36@webmail.messagingengine.com> <1530065618.868906.1421638008.322AD26E@webmail.messagingengine.com> <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> <129d366e-b84f-4d68-b6e1-0a52672f6915@sloti22d1t06> Date: Tue, 26 Jun 2018 22:37:58 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=6d0a530dfb49434a892ec0ddfd296e7a Archived-At: Subject: Re: [Jmap] PushSubscription lifetimes X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 02:38:02 -0000 --6d0a530dfb49434a892ec0ddfd296e7a Content-Type: multipart/related; boundary=f38d9f6a85044496b27843fbb435106d --f38d9f6a85044496b27843fbb435106d Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, 27= Jun 2018, at 12:32 PM, Bron Gondwana wrote:
You want= both a device ID (something that the client can get from the device in = a repeatable way) and a software ID (so that if the user has two differe= nt clients installed on their device they can avoid trampling each other= ).

I was envisioning the clien= t would generate their JMAP Push device id by something like sha256(devi= ce id . software id) =E2=80=93 it gets you the same uniqueness, but avoi= ds leaking information (at least to clients not on the same device; clie= nts on the same device could enumerate common software ids if they reall= y wanted to).

Neil.
--f38d9f6a85044496b27843fbb435106d-- --6d0a530dfb49434a892ec0ddfd296e7a Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 27 Jun 2018, at 12:32 PM, Bron Gondwana wrote: > You want both a device ID (something that the client can get from the = device in a repeatable way) and a software ID (so that if the user has t= wo different clients installed on their device they can avoid trampling = each other). I was envisioning the client would generate their JMAP Push device id by= something like sha256(device id . software id) =E2=80=93 it gets you th= e same uniqueness, but avoids leaking information (at least to clients n= ot on the same device; clients on the same device could enumerate common= software ids if they really wanted to). Neil. --6d0a530dfb49434a892ec0ddfd296e7a--