From nobody Mon Jul 2 04:15:42 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 2478C130F3E; Mon, 2 Jul 2018 04:15:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053013408.28207.12210215417112931687@ietfa.amsl.com> Date: Mon, 02 Jul 2018 04:15:34 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-06.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 11:15:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSON Meta Application Protocol Author : Neil Jenkins Filename : draft-ietf-jmap-core-06.txt Pages : 56 Date : 2018-07-02 Abstract: This document specifies a protocol for synchronising JSON-based data objects efficiently, with support for push and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-06 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 04:39:14 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 DF2C1129385; Mon, 2 Jul 2018 04:39:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053154788.28003.5633941721443808288@ietfa.amsl.com> Date: Mon, 02 Jul 2018 04:39:07 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-06.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 11:39:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Mail Author : Neil Jenkins Filename : draft-ietf-jmap-mail-06.txt Pages : 75 Date : 2018-07-02 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-06 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 3 09:05:16 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 60073131095; Tue, 3 Jul 2018 09:00:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: jmap@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362238.4893.5987105979562513698.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:22 -0700 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 102 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.26 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:32 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (1:00 requested) Monday, 16 July 2018, Afternoon Session I 1330-1530 Room Name: Notre Dame size: 50 --------------------------------------------- Special Note: 1330 - 1430 iCalendar: https://datatracker.ietf.org/meeting/102/sessions/jmap.ics Request Information: --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: doh dcrup oauth saag iasa2 dmarc artarea uta dispatch extra Second Priority: tls httpbis ace lamps core t2trg People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field 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 Wed Jul 4 18:59:35 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B673130E87 for ; Wed, 4 Jul 2018 18:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmgmNVkHGwsz for ; Wed, 4 Jul 2018 18:59:29 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 8B3A6130E85 for ; Wed, 4 Jul 2018 18:59:29 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id l65-v6so11497pgl.8 for ; Wed, 04 Jul 2018 18:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DEIZyVri+50Oy1XEn7406jIwvRYMTIjN/iy18OsTUTY=; b=LoK8oWZVj7bsqj8Q/ZLa7jWH9LApxQ7mR61bc0xkylHGv7isZeR7pqVHbj+k3PFfng 6cOfpM5S3Sfd2S1BCDAqYib624ve7bVt96HVssepQJLKYItJpuuk9vZzD2OeWLUUz2Ip c54Ej83TiibtvTSY6WAD0IC5mcwU632SEUcFwmUqknzodvUBExg/00kg6olfVOdaz2R0 bd53fbnOCzdwWAfeEenb+S3Il4DV4pa9qOv6KzjxM63ucUBIgpe+z7kIyiWPiWeq+I0c 25ICOk4sqg4EuWjEAE3B54V7mbFsejsiJeK13cjVN0BugB0RkriTfk8p4N0DhHJRCoqK AT8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DEIZyVri+50Oy1XEn7406jIwvRYMTIjN/iy18OsTUTY=; b=V1X8ug/otgW5fB7Zoi6v+kpvad66wHIjhvhwEXm5p/jVUqwbK9KDYwJUgOLe4o4gU0 fmX8ouUSwJfsP55xTgRuvRZVXRs9p6xlT9XkzgDdGM599uxoEMvuzvNxyVReiAe2yfCz Vuxe//a4sydQ3Pcc/UsNVrTP217DYsuKJ5V0ozbXK4tSQ5f+F/oqgZnspS+4EN/xEwji Bvxun7fd1tlvDwkPD1yMuzWnQnqTAnls2JAAmORa/pubXfCw1NlzNM9VJSYbBeAwjSSE ETKmWIbk3U/4/AUKDHR5lsaO6b6w2paQsTvXGvtQAvAh1cBCkwdbH8t3cv/26CQhtOzc XF4Q== X-Gm-Message-State: APt69E3Cbqqor418AEiSFgVNWgHuM5Jfl/ytx6T6Nfs2WCiFzBwkU/D5 u5YDy8ntwl0ZVlQXMvEGh5IIS4xN8FQ= X-Google-Smtp-Source: AAOMgpd0GJZx3/8eaOeuqdBHLfI17T7WHS9izLZ5xW4jkVYRMu1qeEauc7FaVbpjTs1TVYayFyPMtQ== X-Received: by 2002:a65:5a01:: with SMTP id y1-v6mr3727603pgs.125.1530755968823; Wed, 04 Jul 2018 18:59:28 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id h10-v6sm8239233pgn.42.2018.07.04.18.59.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 18:59:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Neil Jhaveri In-Reply-To: <47031250-8479-4a3e-9bd9-24eda1c7ab5a@sloti35d1t03> Date: Wed, 4 Jul 2018 18:59:26 -0700 Cc: IETF JMAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <765A47D8-4CE0-4F4C-BD2E-5253261EEB33@neiljhaveri.com> References: <47031250-8479-4a3e-9bd9-24eda1c7ab5a@sloti35d1t03> To: Neil Jenkins X-Mailer: Apple Mail (2.3445.8.2) 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: Thu, 05 Jul 2018 01:59:33 -0000 Since this thread has gotten a little long, I=E2=80=99ll reply to (1) = the /changes comments and (2) the PushSubscription comments separately. = Other comments with closure are inline. > On Jun 8, 2018, at 7:13 PM, Neil Jenkins = wrote: >=20 > Hi Neil, >=20 >>> "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? >=20 > 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 presence of its URN implies no = "urn:ietf:params:jmap:core", it's just a little messier. The downside of = course 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 = thought it was an issue though (some way of coming up with a token to = represent the set of "using" params you want). >=20 > Anyone else have an opinion? If not, I'm slightly inclined to leave it = as a specific inclusion. Hearing this reasoning from you and Chris, I agree that leaving it in = makes sense and makes things easier. >=20 >>> 4.2. /changes >> Could =E2=80=9Ccreations=E2=80=9D and =E2=80=9Cmodifications=E2=80=9D = be separated into separate array properties? >=20 > This is worth discussing. I see the following advantages: >=20 > * The client receives more information, so has more flexibility to = implement strategies such as always fetching new messages in the 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 the = changes are for messages it doesn't have cached anyway). > * It mirrors the /set create, update, destroy distinction, which I = think 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 = notifications (new message deliveries), and ignore those that are just = changed. >=20 > and disadvantages: >=20 > * The server must store more state 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. > * You need two Email/get back-references if you want to fetch both = updates 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 this does add complexity. >=20 > 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? I=E2=80=99m glad to see this pull request! I noticed that Exchange Web = Services also splits changes out like this. I=E2=80=99ll check it out on GitHub and add any comments there. >=20 >>> 4.2. /changes >>> ... >>>=20 >>> 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 = sequence of responses will be ordered oldest-to-newest. Is that true? >=20 > It's technically not required, but it is most likely for ease of = implementation, yes. >=20 >> 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-oldest 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 objects from 4 days ago=E2=80=9D, and so on. When = really, the user 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 = different way? For instance, the Gmail API = = 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=9CnextPageToken=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. >=20 > Just to clarify, the Gmail API pages data in reverse chronological = order here? >=20 > If you do it in reverse order you might run into issues like a message = being 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 = deleted 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 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 going. >=20 >> 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. >=20 > For a client with partial cache (e.g. online client, probably most = mobile clients) you will be using /query to determine the subset of = messages you are interested in. When a change occurs (you get a push = notification), the strategy I'm currently using on our FastMail JMAP UI = that's in development is the following: > * Email/queryChanges the current list in view, max-changes 25 > * Fetch the threads/messages in the "added" response of the = /queryChanges 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 = to be shown and deleted ones removed, and mailbox unread counts to be = updated all in a single round trip. A second round trip fetches any flag = or mailbox changes for messages in view that the /changes response = indicated 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 reasonable, and allows you to not fetch changes for messages you = don't care about. >=20 > If there have been more than 25 changes (the max I specified), the = /queryChanges fails and I retry again this time with a much higher max = changes, 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, most updates are small). >=20 > If you have a complete cache offline, you would instead probably use a = slightly different strategy. To do the initial sync I would start with a = single /query with a filter of null, sorted 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 500 ids at a time, and = simultaneously start fetching the messages in order (so you get the = newest ones first), until you have a complete set.=20 >=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 = headers of the added/modified messages > * Mailbox/changes + fetch changed using back references. > * Email/query filter=3Dnull sort=3Ddate-descending position=3D0 = limit=3D50 > This will return all the changes to the 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 make 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 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). >=20 > Does this sound reasonable to you? If not, or if it's just suboptimal, = can you detail more what you want to be able to do (and maybe what that = might look like at the API level)? See new thread =E2=80=9CReverse-chronological ordering of changes" >=20 >>=20 >>> 4.3. /set >>=20 >>> 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." >>=20 >> Should the same suggestion be made here? >=20 > Yeh, this should be the same. I'll change this. >=20 >> 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 = seemed 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. >=20 > OK, seems majority are in favour of flipping; I will do so. >=20 >> 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 = became flagged, unread, etc., aside from re-get'ing everything in the = query window after handling the adds/deletes?=20 >=20 > As Bron mentioned, it uses the Email/changes method, as I described = above. This is generally pretty efficient. Okay, both of your explanations make sense to me. This seems reasonable = to leave as-is. >=20 >> 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 = access 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. >>=20 >> 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?) >=20 > 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 draft and then create a new one = referencing the previous attachments). >=20 > How about we just reduce the 24h to 1h and make it a MUST? So it = becomes: >=20 > *Except where quota restrictions force early deletion, an unreferenced = blob 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 = expiry time.* Ah, I see... I didn=E2=80=99t pay close enough attention to the fact = that this is only about newly uploaded unreferenced blobs, and that the = deletion of a message would cascade to delete the attachment blob = immediately. Re-reading it all, I think the new language you=E2=80=99ve come up with = seems reasonable to me. >=20 >>> 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? >=20 > Ah, this dates back to when we had authentication as part of the spec. = That's gone so this may need rethinking. A session is essentially a set = of 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 = cleared it. >=20 > 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 = specify a requested length subject to server limit? Or just server = picks?) > * The client can renew at any point to reset the time out. >=20 > Does something like that sound reasonable? Seems reasonable to me! I think the server just telling the client the expiration time is fine. = =46rom the iOS developer perspective, the timeout should be long enough = that there is a good hook to renew the PushSubscription, even if the = user doesn=E2=80=99t open the app. On these platforms, keeping the = subscription alive for at least 24 hours ought to be enough to use the = =E2=80=9Cbackground app refresh=E2=80=9D mechanism to periodically renew = the PushSubscription, but 48 hours might be a safer choice. For = comparison, with the Gmail API, the server tells the client the = expiration time, and it=E2=80=99s 7 days. It=E2=80=99d be good to get = some input from somebody with Android development experience. Do we also need some mechanism to explicitly cancel a subscription, e.g. = when a client is logging out of an account? I=E2=80=99ll reply more about this on the Push Subscriptions thread you = started. >=20 >>> 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? >=20 > Yes. >=20 >>> 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? >=20 > Yes, but I will restructure for simplification and clarity instead: >=20 > *You need two things to connect to a JMAP server:* >=20 >>> 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. >=20 > Agreed. >=20 >>> 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. >>=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 = external system or user=E2=80=9D. >=20 > I agree, and I actually removed this whole property recently. Instead, = the mail spec now defines the following: >=20 > **Push** >=20 > *In addition, servers MUST support a psuedo-type called = "EmailDelivery" in the push mechanisms. The state string for this MUST = change whenever a new Email is added to the store, but SHOULD NOT change = upon any other change to the Email objects.* Sounds good to me! >=20 > Cheers, > Neil._______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Wed Jul 4 19:00:07 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 4E960130E79 for ; Wed, 4 Jul 2018 19:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5UVHluqXSZN for ; Wed, 4 Jul 2018 18:59:57 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75607130E1B for ; Wed, 4 Jul 2018 18:59:57 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id z24-v6so3942353pfe.7 for ; Wed, 04 Jul 2018 18:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=DxtLvkMRDrVFhjHgjexlVEi4fWl+CKbIj5mCVtFI4GU=; b=1MiIHQv1vKKJJzaNbAob4E2j2X0ix+53h3DklTB9eNBeJsviO7lFsPD3Y9R8quyfNE FDzpsYlz4rwZvCYs+iOtAoD1b0/ZpmqqU0O19tVqN7h38oSOjIm/JhMdR5Wrg5AJv1Ck 7Whvu8E5MXw0tpC4ibSOHzQV/XeNGeI/hdN9Y+UE40bXnfi5rg0lChZbt0esbOPIAnsH W2DsQ838R0C1nOiIE5BBwiIn93tnSQbv2KQ/QBiL4iWmx8WYr6tjmfzfTyjagF1U4c7i OaONzfHMnjGvaRYg06PPsrOMqHjeZEgWRK/sv8xrEdADquq0l41UrH1vr+3/MfaWw6/A 4rVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=DxtLvkMRDrVFhjHgjexlVEi4fWl+CKbIj5mCVtFI4GU=; b=HZlp0ymlIf7iBCZHIP5Pzk+aCgLUbvX22wUCHCSHE79y2KMM1rO25nlBEIZ3zT4NDL Q0OTevuOK8JBNgdwxA3ktPGeyy8rvUIJZ5b93xJMvo3uyZ80eUD0tj6XlqGmxPoswPQ3 bwctSPC3ubKrH5jm+7lvCpQpDAhHbbOm9QCKGPvkK7BT01Llal088wGgGlYMDpy8BRTe Tb64XijG3m8sobRWqGeLApIINQJ7NFVhUBIhnbVmM/weRa09k/kqkpm2O7xYZnkVqLxl 3V/riTJtBJ3FVarBN92FeDGdAcx7ojjzSC02bw3KGaw2gW9jXUvdhgvGUWFfgLpykgcW f4+A== X-Gm-Message-State: APt69E3R5ndcsDVI9x43qbU7IbTwB/KgbjSMPlzJmMsJwasrnoagrGtb xJqCzpKpXkMxy/s/HBbChxYdsjjRIa4= X-Google-Smtp-Source: AAOMgpf1pJy4iSVw3XDyVRMagZkgP4G20ZYz2S4OcUJon0NV/a7yOyGCpKLb5bfg496h07D/Lm330Q== X-Received: by 2002:a63:2b88:: with SMTP id r130-v6mr3718354pgr.170.1530755996694; Wed, 04 Jul 2018 18:59:56 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id h10-v6sm8239233pgn.42.2018.07.04.18.59.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 18:59:56 -0700 (PDT) From: Neil Jhaveri Content-Type: multipart/alternative; boundary="Apple-Mail=_A592EFB3-0E24-4E01-813A-5D514E89A3FD" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <194337F4-8365-4FAC-AB10-48019B5263C4@neiljhaveri.com> Date: Wed, 4 Jul 2018 18:59:55 -0700 To: IETF JMAP Mailing List X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Jmap] Reverse-chronological ordering of pages of /changes? 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: Thu, 05 Jul 2018 02:00:04 -0000 --Apple-Mail=_A592EFB3-0E24-4E01-813A-5D514E89A3FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Continuing the discussion from the prior thread=E2=80=A6 > On Jun 8, 2018, at 7:13 PM, Neil Jenkins wrote: >> On Thu, May 31, 2018, at 13:46, Neil Jhaveri wrote: >>> 4.2. /changes >>> ... >>>=20 >>> 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 = sequence of responses will be ordered oldest-to-newest. Is that true? >=20 > It's technically not required, but it is most likely for ease of = implementation, yes. >=20 >> 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-oldest 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 objects from 4 days ago=E2=80=9D, and so on. When = really, the user 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 = different way? For instance, the Gmail API = = 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=9CnextPageToken=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. >=20 > Just to clarify, the Gmail API pages data in reverse chronological = order here? No, to my disappointment. I=E2=80=99m working on a project that uses it, = and even with push, updates are often really big for desktops/laptops = (which go into sleep and can remain disconnected for a long time), so = the deficiencies of processing changes strictly chronologically becomes = pretty apparent. It=E2=80=99s not as much of an issue in practice on = mobile, since those devices don=E2=80=99t tend to actually disconnect. = My interest in this behavior is specifically driven by past experience = writing for desktop platforms. I just cited the Gmail API as one = possible design that could allow for reverse-chronological paging of = changes, even if their implementation doesn=E2=80=99t do it. There is another production example =E2=80=94 Microsoft=E2=80=99s = Exchange Web Services Managed API return changes in reverse = chronological order inside SyncFolderItems. It=E2=80=99s explicitly = documented = that Microsoft made = this change for Exchange Server 2010 and newer (previously, it was = chronological). They added this functionality and didn=E2=80=99t change = their API of just taking an opaque SyncState string (which can get quite = long, so it=E2=80=99s probably encapsulating all information necessary = to do this). > If you do it in reverse order you might run into issues like a message = being 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 = deleted is actually the most recent (so you must have kept some data = around for the deleted item). That's a bit messy.=20 I think this requirement could be avoided if the server coalesced = changes before returning them from /changes, even if there are multiple = pages. That could be a good optimization in general, because it=E2=80=99s = probably common to see an addition followed by a modification (e.g. = =E2=80=9Cmessage read=E2=80=9D from a phone). Of course, that means the = server has to do additional processing before returning changes. > 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 going. I=E2=80=99ll discuss this a bit more below in the proposal. >=20 >> 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. >=20 > For a client with partial cache (e.g. online client, probably most = mobile clients) you will be using /query to determine the subset of = messages you are interested in. When a change occurs (you get a push = notification), the strategy I'm currently using on our FastMail JMAP UI = that's in development is the following: > * Email/queryChanges the current list in view, max-changes 25 > * Fetch the threads/messages in the "added" response of the = /queryChanges 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 = to be shown and deleted ones removed, and mailbox unread counts to be = updated all in a single round trip. A second round trip fetches any flag = or mailbox changes for messages in view that the /changes response = indicated 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 reasonable, and allows you to not fetch changes for messages you = don't care about. >=20 > If there have been more than 25 changes (the max I specified), the = /queryChanges fails and I retry again this time with a much higher max = changes, 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, most updates are small). >=20 > If you have a complete cache offline, you would instead probably use a = slightly different strategy. To do the initial sync I would start with a = single /query with a filter of null, sorted 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 500 ids at a time, and = simultaneously start fetching the messages in order (so you get the = newest ones first), until you have a complete set.=20 >=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 = headers of the added/modified messages > * Mailbox/changes + fetch changed using back references. > * Email/query filter=3Dnull sort=3Ddate-descending position=3D0 = limit=3D50 > This will return all the changes to the 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 make 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 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). >=20 > Does this sound reasonable to you? Yeah, this is the strategy I was mentioned as an alternative. It works, = and I agree it wouldn=E2=80=99t be that hard for a client to do this, = but there are some downsides without server support: 1. The /query response is ultimately wasted and redundant with ID=E2=80=99= s (eventually) returned by /changes, either in the same or a subsequent = call. 2. I don=E2=80=99t see a way to execute this strategy and also fetch the = first page of messages in a single round trip to the server. If you = fetch the results of the /query with backreferences, you may waste = bandwidth fetching unnecessary messages (e.g. if there=E2=80=99s only 1 = new message). If you fetch the results of /changes with backreferences, = those may be old messages that aren=E2=80=99t the top priority. If you = bandwidth is a concern, you have to do it in 2 round trips. I think in practice, this is more of a concern for the desktop-platform = clients. Mobile platforms tend to always be connected, while desktop = platforms are frequently disconnected for days.=20 > If not, or if it's just suboptimal, can you detail more what you want = to be able to do (and maybe what that might look like at the API level)? To support this, a call to /changes will need to encapsulate: 1. What state the client is coming from 2. What partial state the client has already consumed (so a server can = figure out what=E2=80=99s already been sent to the client) There=E2=80=99s many ways it could be done, but I like the idea of = making it very explicit, and suggest the following API changes (along = with a note mandating the newest=E2=80=94>oldest behavior): 1. Add *untilState*=3D=E2=80=9CString=E2=80=9D|null to the /changes = argument list. 2. Add *pageNumber*=3D=E2=80=9CNumber=E2=80=9D to the /changes argument = list.=20 3. Replace *hasMoreChanges* with *pageCount*. This is how the synchronization flow might work: - When a client makes a request, it makes it with sinceState=3Dx, = untilState=3Dnull, and pageNumber=3D1.=20 - The server then loads all of the relevant changes between x and the = most current state, orders & coalesces them, and returns the first page, = along with a newState property. - When a client receives a /changes response, the *newState* property is = echo=E2=80=99d back in subsequent /changes calls as the *untilState* = parameter, with pageNumber=3D2 (if applicable). The server loads the = changes in the [x, newState] range, repeats the ordering/coalescing = process, and returns the second page of changes. Or more ideally it = draws the page from a cache. This strategy would allow a client to fetch the first page of changes, = ordered newest=E2=80=94>oldest, and also fetch those items by back = reference, all in a single round trip =E2=80=94 executing highly = effective/relevant first round trip in the case that the client has been = disconnected for a while and there are many changes. One issue with this approach, which you noted above, is how to optimally = receive new changes while the client is in the process of paging in = changes. Right now, if a push is received while a client is currently = paging in changes reverse-chronologically, the client would have to just = wait until it finished paging the changes it was working on, and then = request new changes. That=E2=80=99s unfortunate, but actually not any = worse than just consuming changes chronologically. I can=E2=80=99t think = of a solution that isn=E2=80=99t terribly complex at the API level, and = since it seems pretty rare, I would suggest we just live with it. This definitely adds complexity, though. I=E2=80=99m curious if anybody = else thinks this is sufficiently valuable to justify the complexity? --Apple-Mail=_A592EFB3-0E24-4E01-813A-5D514E89A3FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Continuing the discussion from the = prior thread=E2=80=A6

On Jun 8, 2018, at 7:13 PM, Neil Jenkins = wrote:
On Thu, May 31, 2018, at 13:46, Neil Jhaveri wrote:
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 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 implementation, 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-reference), = 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=9Chere 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 user = 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.

Have we had any = discussion around handling pages of changes in a different way? For = instance, the Gmail API <https://developers.google.com/gmail/api/v1/reference/users/hist= ory/list> 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=9CnextPageToken=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?

No, to my = disappointment. I=E2=80=99m working on a project that uses it, and even = with push, updates are often really big for desktops/laptops (which go = into sleep and can remain disconnected for a long time), so the = deficiencies of processing changes strictly chronologically becomes = pretty apparent. It=E2=80=99s not as much of an issue in practice on = mobile, since those devices don=E2=80=99t tend to actually disconnect. = My interest in this behavior is specifically driven by past experience = writing for desktop platforms. I just cited the Gmail API as one = possible design that could allow for reverse-chronological paging of = changes, even if their implementation doesn=E2=80=99t do = it.

There is another production = example =E2=80=94 Microsoft=E2=80=99s Exchange Web Services Managed = API return changes in reverse chronological order inside = SyncFolderItems. It=E2=80=99s explicitly documented that Microsoft made this change for = Exchange Server 2010 and newer (previously, it was chronological). They = added this functionality and didn=E2=80=99t change their API of just = taking an opaque SyncState string (which can get quite long, so it=E2=80=99= s probably encapsulating all information necessary to do = this).

If you do it in reverse order you might run into issues like = a message being 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 deleted is actually the most recent (so you must have kept some = data around for the deleted item). That's a bit = messy. 

I think this = requirement could be avoided if the server coalesced changes before = returning them from /changes, even if there are multiple pages. That = could be a good optimization in general, because it=E2=80=99s probably = common to see an addition followed by a modification (e.g. =E2=80=9Cmessag= e read=E2=80=9D from a phone). Of course, that means the server has to = do additional processing before returning changes.

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 = going.

I=E2=80=99ll discuss this a = bit more below in the proposal.


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.

For a client with partial cache (e.g. online client, probably = most mobile clients) you will be using /query  to determine the = subset of messages you are interested in. When a change occurs (you get = a push notification), the strategy I'm currently using on our FastMail = JMAP UI that's in development is the following:
* = Email/queryChanges the current list in view, max-changes 25
* Fetch the threads/messages in the "added" response of the = /queryChanges 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 to be = shown and deleted ones removed, and mailbox unread counts to be updated = all in a single round trip. A second round trip fetches any flag or = mailbox changes for messages in view that the /changes response = indicated 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 reasonable, 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 /queryChanges fails and I = retry again this time with a much higher max changes, 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, = most updates are small).

If you have a complete cache offline, you = would instead probably use a slightly different strategy. To do the = initial sync I would start with a single /query with a filter of null, = sorted 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 500 ids at a time, and simultaneously start fetching the = messages in order (so you get the newest ones first), until you have a = complete set. 

When a change occurs = (you get a push notification), you can then do:
* = Email/changes (max-changes 25) + back references to fetch the email = headers of the added/modified messages
* = Mailbox/changes + fetch changed using back references.
* Email/query filter=3Dnull sort=3Ddate-descending position=3D0= limit=3D50
This will return all the changes to the 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 make 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 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?

Yeah, this is the strategy I was mentioned as = an alternative. It works, and I agree it wouldn=E2=80=99t be that hard = for a client to do this, but there are some downsides without server = support:
1. The /query response is ultimately wasted and = redundant with ID=E2=80=99s (eventually) returned by /changes, either in = the same or a subsequent call.
2. I don=E2=80=99t see a way to = execute this strategy and also fetch the first page of messages in a = single round trip to the server. If you fetch the results of the /query = with backreferences, you may waste bandwidth fetching unnecessary = messages (e.g. if there=E2=80=99s only 1 new message). If you fetch the = results of /changes with backreferences, those may be old messages that = aren=E2=80=99t the top priority. If you bandwidth is a concern, you have = to do it in 2 round trips.

I = think in practice, this is more of a concern for the desktop-platform = clients. Mobile platforms tend to always be connected, while desktop = platforms are frequently disconnected for = days. 

 If not, or if it's just suboptimal, can = you detail more what you want to be able to do (and maybe what that = might look like at the API level)?

To support this, a call to /changes = will need to encapsulate:
1. What state the client is coming = from
2. What partial state the client has already consumed (so = a server can figure out what=E2=80=99s already been sent to the = client)

There=E2=80=99s many ways it = could be done, but I like the idea of making it very explicit, and = suggest the following API changes (along with a note mandating the = newest=E2=80=94>oldest behavior):

1. Add *untilState*=3D=E2=80=9CString=E2=80=9D|null to = the /changes argument list.
2. Add *pageNumber*=3D=E2=80=9CNumber=E2=80=9D to the = /changes argument list. 
3. Replace *hasMoreChanges* with *pageCount*.

This is how the synchronization flow might = work:
- When a client makes a request, it makes it with = sinceState=3Dx, untilState=3Dnull, and pageNumber=3D1. 
- = The server then loads all of the relevant changes between x and the most = current state, orders & coalesces them, and returns the first page, = along with a newState property.
- When a client receives a = /changes response, the *newState* property is echo=E2=80=99d back in = subsequent /changes calls as the *untilState* parameter, with = pageNumber=3D2 (if applicable). The server loads the changes in the [x, = newState] range, repeats the ordering/coalescing process, and returns = the second page of changes. Or more ideally it draws the page from a = cache.

This strategy would allow a = client to fetch the first page of changes, ordered newest=E2=80=94>olde= st, and also fetch those items by back reference, all in a single round = trip =E2=80=94 executing highly effective/relevant first round trip in = the case that the client has been disconnected for a while and there are = many changes.

One issue with this = approach, which you noted above, is how to optimally receive new changes = while the client is in the process of paging in changes. Right now, if a = push is received while a client is currently paging in changes = reverse-chronologically, the client would have to just wait until it = finished paging the changes it was working on, and then request new = changes. That=E2=80=99s unfortunate, but actually not any worse than = just consuming changes chronologically. I can=E2=80=99t think of a = solution that isn=E2=80=99t terribly complex at the API level, and since = it seems pretty rare, I would suggest we just live with = it.

This definitely adds complexity, = though. I=E2=80=99m curious if anybody else thinks this is sufficiently = valuable to justify the complexity?

= --Apple-Mail=_A592EFB3-0E24-4E01-813A-5D514E89A3FD-- From nobody Thu Jul 5 00:05:49 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 D14CB130DEF for ; Thu, 5 Jul 2018 00:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaWK0otqOVF1 for ; Thu, 5 Jul 2018 00:05:45 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 8B9FE128CF3 for ; Thu, 5 Jul 2018 00:05:45 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id j17-v6so4566050pfn.5 for ; Thu, 05 Jul 2018 00:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LtAoElkVvMYD+aGC8+MysLxb92KhsSAQwiUorkAkKyE=; b=bsxNKZIHJcrRIpCfYhE0pzQaneB1qkaF7+yO9ydNDsT50izZSUI07iSyEOVXf4piES 8OhFar3IXkWmtrRMnX2FXiIIRyABKsMHFPeB3c18yw9F78qrmxt0JfC8kfrU+2xbotxK jb1+EwHg8aJxA4INjMCItMvGb2SoKv4Pol3hu1DSAJ00avMZNKCoqWCXDVdol5vmOK9S +JuBf7CTOjyIlKTpzSHeSCPxydgA3Jt2TNoTsrP/74joxTD4ZFaP66ISuh9Dn3T4+TNr dWhSzce7oi+ovT54lkHgQ7kwFgw/RC4KPrrPyZ3++zFRPkadfxFVvEWHl2c5BiNJRZWT 6t6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LtAoElkVvMYD+aGC8+MysLxb92KhsSAQwiUorkAkKyE=; b=rAkQ40eIPs5qI2zDTMCvXk8xuHVhVYf678ALpMWzDYuEKQw+1DFjVXxfi1mEXlI273 4kcIg0W6i7up+Z164CN+NPiEhSNHcoU00RNhtyJaj2C1xRPGLzz0UA7Svf4LpTZxN+QT Dlmq7vGMa/2sTR4ffNYDDwXIkRMIoOl8JVMFCU0F+Ea4LulL0JBmEOz7TYUYdr4u0vwj 6abb338btO4Rc5R549Ki19JwFfR0DTEXtfeGztLYaJmJf3FIPJf82HoEgFg5aobuvsR6 z3wpdOI9VqK6H45XJ07y6ju8p7cIuWaJLQca9JPS1k1uLREZDK6RkhIkTIdgUwQsGkcE pr6A== X-Gm-Message-State: APt69E04P26tnM+CmD0dVuwt551Jf5jka9yCy0oxwMt3ih8xBhIuuz1i V6+cAVpHyclG4oB/RrwNIoObmzZ9Gwo= X-Google-Smtp-Source: AAOMgpfp7Urfp2T+zBXwsMJdEfboGt7Spzi3M3bETvtXJhMwPim6ZVxnDfVH5Bqy52t330lzT+gHcA== X-Received: by 2002:a63:8f53:: with SMTP id r19-v6mr4360968pgn.17.1530774344856; Thu, 05 Jul 2018 00:05:44 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id o26-v6sm13273024pfi.167.2018.07.05.00.05.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jul 2018 00:05:44 -0700 (PDT) From: Neil Jhaveri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6F350671-26DA-48FD-B20F-48DEEE9EF3C1" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 5 Jul 2018 00:05:42 -0700 In-Reply-To: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> X-Mailer: Apple Mail (2.3445.8.2) 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: Thu, 05 Jul 2018 07:05:48 -0000 --Apple-Mail=_6F350671-26DA-48FD-B20F-48DEEE9EF3C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 26, 2018, at 7:03 PM, Neil Jenkins = wrote: >=20 > 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. >=20 > 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. Per the other discussion in this thread, I support the suggestion that = the client be responsible for generating a unique token, and documenting = in the spec that it should be easy to re-generate, not depend on = persisted state, be different from device to device, and be different = from other vendors.=20 Neil Jenkins' sha256(deviceID, softwareID) suggestion seems like a = reasonable suggested algorithm if the platform doesn=E2=80=99t already = provide something. For instance, on iOS, there is already API to get a = globally unique (device, app) token that needs to be passed back to = Apple push servers, so using this token would be a natural fit. It=E2=80=99= s generated by the system, and not part of an app=E2=80=99s local = storage, so it automatically handles cases like a new device being = restored with content from a backup. Would this token then be an argument to PushSubscription/get? > * 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. When using an expiring credential, I think it would be good to be able = to extend the lifetime of the push subscription beyond the lifetime of = the credential. Is that allowed by your proposal? The scenario I=E2=80=99m= thinking of is a low-traffic account not receiving any new content, a = user not might launch their client, so for instance an iOS developer = would have to use the background app refresh mechanism to extend the = push subscription, and I=E2=80=99d start getting nervous with any = expectation of getting called in less than 24 hours. In addition, is there a maximum limit on the expiration time? I could = easily see an iOS developer wanting a week, or even up to 30 days, to = behave better in cases where the user has disabled background app = refresh. > On Wed, Jun 27, 2018, at 12:28, Neil Jenkins wrote: > 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). Seems fine to not return these on /get.= --Apple-Mail=_6F350671-26DA-48FD-B20F-48DEEE9EF3C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 26, 2018, at 7:03 PM, Neil Jenkins <neilj@fastmailteam.com> 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.

Per = the other discussion in this thread, I support the suggestion that the = client be responsible for generating a unique token, and documenting in = the spec that it should be easy to re-generate, not depend on persisted = state, be different from device to device, and be different from other = vendors. 

Neil Jenkins' = sha256(deviceID, softwareID) suggestion seems like a reasonable = suggested algorithm if the platform doesn=E2=80=99t already provide = something. For instance, on iOS, there is already API to get a globally = unique (device, app) token that needs to be passed back to Apple push = servers, so using this token would be a natural fit. It=E2=80=99s = generated by the system, and not part of an app=E2=80=99s local storage, = so it automatically handles cases like a new device being restored with = content from a backup.

Would this token then be an argument to = PushSubscription/get?

* 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.

When using an expiring credential, I think it = would be good to be able to extend the lifetime of the push subscription = beyond the lifetime of the credential. Is that allowed by your proposal? = The scenario I=E2=80=99m thinking of is a low-traffic account not = receiving any new content, a user not might launch their client, so for = instance an iOS developer would have to use the background app refresh = mechanism to extend the push subscription, and I=E2=80=99d start getting = nervous with any expectation of getting called in less than 24 = hours.

In addition, is there a = maximum limit on the expiration time? I could easily see an iOS = developer wanting a week, or even up to 30 days, to behave better in = cases where the user has disabled background app = refresh.

On Wed, Jun 27, 2018, at 12:28, Neil Jenkins wrote:
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).

Seems fine to not return these on = /get.
= --Apple-Mail=_6F350671-26DA-48FD-B20F-48DEEE9EF3C1-- From nobody Thu Jul 5 10:44:10 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 0B3B6130F0D for ; Thu, 5 Jul 2018 10:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unjllrr6ArA7 for ; Thu, 5 Jul 2018 10:44:05 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 B6732130E66 for ; Thu, 5 Jul 2018 10:44:05 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id z24-v6so6055237pfe.7 for ; Thu, 05 Jul 2018 10:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VC/oKINPB8kqFLPtWfKo5zs0WcsdN4ndtNK9o5hOKKA=; b=TnZiOdn5Gjmp+iG3Mlda2WBdRTd7PTqlbNbx1vveNLwyvGCj+c5cNN6NgXIGSQgHAi XXkiklJ0IaBAjdvc5LTZs9ifb+g4ztdAiboCegnh/398saSXTBWxAcpbp1CxVDgY79zd ZoCVI4wrmLKXkDIng/t5TI3bdUaa+16u1JN2YMc+lAz2ar7f3sR8/l9bjy9qWYZZRDgM 0sQGAl/gnSNuEIGy+7c5Q+p5KmO55fpVj16bHeyivKuaz8DZ4w3baX74M4FMVwGUgmgE EmCz/Uzc4QlxfGiI46DEjnY570ZB3z/NiNXoIH+sU8iZvhnNDU3DbT5FWabx5FOTzn5/ 0OlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VC/oKINPB8kqFLPtWfKo5zs0WcsdN4ndtNK9o5hOKKA=; b=YSdD7ODBVN/7Y9z/HvYeNNlBAArTxalWOAAipLeY3NQPDxgWxN1YGdCZXPeeQfesU9 SutYBMyWV2ottXu9BaPNIwa2L/hqkIjbdFgfuorWhkTlPjz6DQu/vdLjBf0BdeSAz/hO LponxqZwBoqZiRRJtZFH0JYc92kFE/Qtw7cCTLtCfp8OYTGp2DY0Hzv4ahf27IWUgYoY +jKb0F/0HshLL46YIgFiqOylZpTx+DNmwdM1yGUgUJXDHPrJh3y6bbEMuW/WXEObXBjD wigbnkG5csV2D+bQ4KR48a5vVdbPzjbBALeWrygvUWuH3PshWauTGeuub/zqp7InB7s5 XXfw== X-Gm-Message-State: APt69E2KODn4/KlSNWN++/qah5EJd5ok6l8sGKObrjx/8VXUzKnlDh9U 0olUVkfx9hZOFuD85tVukC/l4hfS6EU= X-Google-Smtp-Source: AAOMgpdzcP5eqZpHqDsj2/xgf4LV0DayASaquC/6tSW6+0kLslcQqRuUctQiatMjuXnYfHWmmcRgJQ== X-Received: by 2002:a63:530b:: with SMTP id h11-v6mr404551pgb.139.1530812645148; Thu, 05 Jul 2018 10:44:05 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id g2-v6sm17053588pfd.165.2018.07.05.10.44.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jul 2018 10:44:04 -0700 (PDT) From: Neil Jhaveri Message-Id: <2D462F98-F0C0-41A3-BD98-563C1B29B249@neiljhaveri.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_019521BA-ABFD-4541-B035-262B7EC60E66" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 5 Jul 2018 10:44:03 -0700 In-Reply-To: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> X-Mailer: Apple Mail (2.3445.8.2) 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: Thu, 05 Jul 2018 17:44:09 -0000 --Apple-Mail=_019521BA-ABFD-4541-B035-262B7EC60E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Also, with PushSubscriptions, it might be good to think about how they = could be used with FCM and APNS. (Note, I know nothing about FCM and I = have only done light reading about APNS =E2=80=94 never actually built = anything using it.) Ideally, as an iOS client author, a JMAP server could push directly to = APNS without me needing to deploy any kind of relay service. Last year, I asked engineers at Apple working on APNS if they thought = they could support RFC 8030 semantics, and they said maybe they could = expose the 8030-style push endpoints (as opposed to = hour-life-token-based auth or certificate-based auth funneling to a = single URI). But, I think even if they did that, there would still = likely be a need for custom payload content = , and = potentially custom headers = on = every push. For instance, the payload may need to contain: { =E2=80=9Caps=E2=80=9D : { =E2=80=9Ccontent-available=E2=80=9D : 1 }, = =E2=80=9Cchanges=E2=80=9D : [=E2=80=A6] } Or use the content-modifiable key, since the actual payload will not = contain the full notification content, and the client will have to be = launched/foregrounded on iOS to do some syncing work and generate a = local notification, or modify the existing remote notification.=20 It would be a bit of a shot in the dark, but do we want to support the = ability to add custom payload dictionary content, and custom headers? Does anybody here have experience with FCM, or actual experience = building something end-to-end with APNS? Or do we envision JMAP servers implementing vendor-specific extensions = to support these push servers? > On Jun 26, 2018, at 7:03 PM, Neil Jenkins = wrote: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Any thoughts, queries, feedback on all this? >=20 > Neil._______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail=_019521BA-ABFD-4541-B035-262B7EC60E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Also,= with PushSubscriptions, it might be good to think about how they could = be used with FCM and APNS. (Note, I know nothing about FCM and I have = only done light reading about APNS =E2=80=94 never actually built = anything using it.)

Ideally, as an iOS client author, a JMAP server could push = directly to APNS without me needing to deploy any kind of relay = service.

Last year, I asked engineers at Apple working on APNS if they = thought they could support RFC 8030 semantics, and they said maybe they = could expose the 8030-style push endpoints (as opposed to = hour-life-token-based auth or certificate-based auth funneling to a = single URI). But, I think even if they did that, there would still = likely be a need for custom payload content, and potentially custom headers on every push.
For instance, the payload may need to = contain:
{ =E2=80=9Caps=E2=80=9D : { = =E2=80=9Ccontent-available=E2=80=9D : 1 }, =E2=80=9Cchanges=E2=80=9D : = [=E2=80=A6] }
Or use the = content-modifiable key, since the actual payload will not contain the = full notification content, and the client will have to be = launched/foregrounded on iOS to do some syncing work and generate a = local notification, or modify the existing remote = notification. 

It would be a = bit of a shot in the dark, but do we want to support the ability to add = custom payload dictionary content, and custom headers?

Does anybody here have experience with FCM, or = actual experience building something end-to-end with APNS?

Or do we envision JMAP servers implementing = vendor-specific extensions to support these push servers?

On Jun 26, 2018, at 7:03 PM, Neil Jenkins <neilj@fastmailteam.com> 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?

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

= --Apple-Mail=_019521BA-ABFD-4541-B035-262B7EC60E66-- From nobody Thu Jul 5 17:15:36 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 0839D130FE2 for ; Thu, 5 Jul 2018 17:15:28 -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=Z/IPdTfn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZBd0HK0i 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 ZNpH5j44_7iE for ; Thu, 5 Jul 2018 17:15:26 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDA7130FA9 for ; Thu, 5 Jul 2018 17:15:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 11388239 for ; Thu, 5 Jul 2018 20:15:16 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 05 Jul 2018 20:15:16 -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=ICnBYROTJJWzY0dQlPHKq55e63YcNA54fFy5OgGyU v0=; b=Z/IPdTfntuwjZJgj5Hox5Wgz+MADl9omoBmINNgoqF2ibXeNwstG5fH/u ODA8T5MBrY4G5kRxBw3QstdbkDFI8DWiwf+s0YzOz3nMyDwaip1R6CLwx9BcYgit 4cyVr7VyB5/R3OeiDpCS2HU8cyOs4M1vRu0nmRLkrxxY4WPjJ5mJ0TMRVrBoclcV TC484Iv8AIXnetp8mgv9SoBjAJI0LMw3Toze0CMAQrzdn1v/GjqfgUV4spAT+Irl 1fz4e1x23T60AOIVW+NdZbk9PjW3Ngwkuvf4uwEBm6vqmwXXScBC3o9ErkgmI7Nv FLv0zc/SdK+Hs3zaHCnf1v6lIqh9Q== 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=ICnBYROTJJWzY0dQlPHKq55e63YcNA54fFy5OgGyU v0=; b=ZBd0HK0iQ2TB96ez26huQHaDTuNqMIO2i6gWNs9RWM1YopBLPmA6VtLN9 mA4X5b1m4JVVw3r52sUrS06NnHXYIJ/V7c5dWPXDuyRgkkXXOSkfKEpPJzuf0EOB rhtKVgEKk0zrcItgPqRue4OlWxcG0bBz1kB6XF5lf+xda/HYJwA23+ASv6nJ16YH 2CK47BZu0Ib1OaUWA5i1jObj7NdMu6XMmKlqDAgx0x7xwygYNI4xmCE7hnDSQllg 0axtb90S6Cgh8/KUOBApy8txz18FfrnOJoV9UwxYSf00Q32kcdTvOxDWSWBVZi9u cD0Hh0MfP6xYXTvO04SQ8kq8QD4OQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4ED87CA13D; Thu, 5 Jul 2018 20:15:15 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.3-707-gc22f408-next x-jmap-identity-id: 64588216 In-Reply-To: <194337F4-8365-4FAC-AB10-48019B5263C4@neiljhaveri.com> References: <194337F4-8365-4FAC-AB10-48019B5263C4@neiljhaveri.com> Date: Thu, 05 Jul 2018 20:14:55 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=520be7f2ce3043488352517990fccf46 Archived-At: Subject: Re: [Jmap] Reverse-chronological ordering of pages of /changes? 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, 06 Jul 2018 00:15:34 -0000 --520be7f2ce3043488352517990fccf46 Content-Type: multipart/related; boundary=94e34a4eb8514fe8bcc7767f06866e58 --94e34a4eb8514fe8bcc7767f06866e58 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, 5 = Jul 2018, at 12:00 PM, Neil Jhaveri wrote:
To support this, a call to /changes will need to encapsulate= :
1. What state the client is coming from
2. What= partial state the client has already consumed (so a server can figure o= ut what=E2=80=99s already been sent to the client)
=

You're right, this is not actually diff= icult to do. Thinking about this, because the state string is opaque to = the client there's really nothing to stop a server doing this without ma= king any changes to the API. (It can still be a very short state string = too; I've no idea what MS does to end up with apparently several kilobyt= es long state strings sometimes with Exchange!) I've created a pull request to add the fo= llowing section to the /changes description:

---

If a record has been created AND updated = since the old state, the server SHOULD just return the id in the *create= d* list, but MAY return it in the *updated* list as well.
=
If a record has been updated AND destroyed since the old = state, the server SHOULD just return the id in the *destroyed* list, but= MAY return it in the *updated* list as well.

If a record has been created AND destroyed since the old state, the s= erver SHOULD remove the id from the response entirely, but MAY include i= t in the *destroyed* list, and if so MAY also include it in the *created= * list.

If a *maxChanges* is supplied, or s= et automatically by the server, the server MUST ensure the number of ids= returned across *created*, *updated* and *destroyed* does not exceed th= is limit. If there are more changes than this between the client's state= and the current server state, the server SHOULD generate an update to t= ake the client to an intermediate state, from which the client can conti= nue to call *Foo/changes* until it is fully up to date. If it is unable = to calculate an intermediate state, it MUST return a `cannotCalculateCha= nges` error response instead.

When generati= ng intermediate states, the server may choose how to divide up the chang= es. For many types it will provide a better user experience to return th= e more recent changes first, as this is more likely to be what the user = is most interested in. The client can then continue to page in the older= changes while the user is viewing the newer data. For example, suppose = a server went through the following states:

    A -> B -> C -> D -> E

=
And a client asks for changes from state `B`. The server migh= t first get the ids of records created, updated or destroyed between sta= tes D and E, returning them with:

 &nb= sp;  state: "B-D-E"
    hasMoreChanges= : true

The client will then ask for the cha= nge from state `B-D-E`, and the server can return the changes between st= ates C and D, returning:

   = state: "B-C-E"
    hasMoreChanges: true

Finally the client will request the changes f= rom `B-C-E` and the server can return the changes between states B and C= , returning:

    state: "E"<= br>
    hasMoreChanges: false
Should the state on the server be modified in the middle of = all this (to `F`), the server still does the same but now when the updat= e to state `E` is returned, it would indicate that it still has more cha= nges for the client to fetch.

Where multipl= e changes to a record are split across different intermediate states, th= e server MUST NOT return a record as created in a later response than on= e which gives it as updated or destroyed, and MUST NOT return a record a= s destroyed before a response that gives it as created or updated. The s= erver may have to coalesce multiple changes to a record to satisfy this = requirement.

---

I= prefer this to adding extra arguments to /changes as it keeps the API (= and client implementation) simpler, while giving servers more flexibilit= y (for example, if Gmail were to implement JMAP I'd imagine it would be = easier for them to do so in a way that's closer to their proprietary API= ). For some types, it may also actually make for a better experience to = return oldest changes first.

Does this look= like reasonable to you? Describing this clearly is hard, so any suggest= ions for improving the text are welcome!

Ne= il.
--94e34a4eb8514fe8bcc7767f06866e58-- --520be7f2ce3043488352517990fccf46 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 5 Jul 2018, at 12:00 PM, Neil Jhaveri wrote: > To support this, a call to /changes will need to encapsulate: > 1. What state the client is coming from > 2. What partial state the client has already consumed (so a server can= figure out what=E2=80=99s already been sent to the client) You're right, this is not actually difficult to do. Thinking about this,= because the state string is opaque to the client there's really nothing= to stop a server doing this without making any changes to the API. (It = can still be a very short state string too; I've no idea what MS does to= end up with apparently several kilobytes long state strings sometimes w= ith Exchange!) I've created a pull request to add the following section to the /changes description: --- If a record has been created AND updated since the old state, the server= SHOULD just return the id in the *created* list, but MAY return it in t= he *updated* list as well. If a record has been updated AND destroyed since the old state, the serv= er SHOULD just return the id in the *destroyed* list, but MAY return it = in the *updated* list as well. If a record has been created AND destroyed since the old state, the serv= er SHOULD remove the id from the response entirely, but MAY include it i= n the *destroyed* list, and if so MAY also include it in the *created* l= ist. If a *maxChanges* is supplied, or set automatically by the server, the s= erver MUST ensure the number of ids returned across *created*, *updated*= and *destroyed* does not exceed this limit. If there are more changes t= han this between the client's state and the current server state, the se= rver SHOULD generate an update to take the client to an intermediate sta= te, from which the client can continue to call *Foo/changes* until it is= fully up to date. If it is unable to calculate an intermediate state, i= t MUST return a `cannotCalculateChanges` error response instead. When generating intermediate states, the server may choose how to divide= up the changes. For many types it will provide a better user experience= to return the more recent changes first, as this is more likely to be w= hat the user is most interested in. The client can then continue to page= in the older changes while the user is viewing the newer data. For exam= ple, suppose a server went through the following states: =C2=A0=C2=A0=C2=A0 A -> B -> C -> D -> E And a client asks for changes from state `B`. The server might first get= the ids of records created, updated or destroyed between states D and E= , returning them with: =C2=A0=C2=A0=C2=A0 state: "B-D-E" =C2=A0=C2=A0=C2=A0 hasMoreChanges: true The client will then ask for the change from state `B-D-E`, and the serv= er can return the changes between states C and D, returning: =C2=A0=C2=A0=C2=A0 state: "B-C-E" =C2=A0=C2=A0=C2=A0 hasMoreChanges: true Finally the client will request the changes from `B-C-E` and the server = can return the changes between states B and C, returning: =C2=A0=C2=A0=C2=A0 state: "E" =C2=A0=C2=A0=C2=A0 hasMoreChanges: false Should the state on the server be modified in the middle of all this (to= `F`), the server still does the same but now when the update to state `= E` is returned, it would indicate that it still has more changes for the= client to fetch. Where multiple changes to a record are split across different intermedia= te states, the server MUST NOT return a record as created in a later res= ponse than one which gives it as updated or destroyed, and MUST NOT retu= rn a record as destroyed before a response that gives it as created or u= pdated. The server may have to coalesce multiple changes to a record to = satisfy this requirement. --- I prefer this to adding extra arguments to /changes as it keeps the API = (and client implementation) simpler, while giving servers more flexibili= ty (for example, if Gmail were to implement JMAP I'd imagine it would be= easier for them to do so in a way that's closer to their proprietary AP= I). For some types, it may also actually make for a better experience to= return oldest changes first. Does this look like reasonable to you? Describing this clearly is hard, = so any suggestions for improving the text are welcome! Neil. --520be7f2ce3043488352517990fccf46-- From nobody Thu Jul 5 19:45:31 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 6533C130E6F for ; Thu, 5 Jul 2018 19:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y9NCBdpDy18 for ; Thu, 5 Jul 2018 19:45:27 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25533130E59 for ; Thu, 5 Jul 2018 19:45:27 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id l123-v6so7071023pfl.13 for ; Thu, 05 Jul 2018 19:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vco1rZsmOfAiDEQiUNF7wdu8HAmq+ilrehMUdgZuqYo=; b=D9SLdm0VhFdjtTQ3PMPlkBvHySpI+iCddS0Su3JVYpCV5oFEAyIqPWRppPrILCnweT Pc9RAJpX3IEnLDmYF+AmyR8DobxD2LpDjBPxoX5L6iJKi45AOjT1toNyGzmYINvEDBJF O9ly5HWV4DZkeyaIOCAe2ZxYvZz1U4lOeEQ2lOWHveu4dIG8IQpOqIrCKrzcbl+qogXy +g+Bmt3KjSOpCmpPCYYcaQy8anJmjLKDpI1LDar6gif9HOCZ9ynOA7jv3QPZ6STitmXp 8reJ+L7JWKSyg70Z7wg5Uj+xVuNVhf2MILmP8tSSuST70aPJLcFdHwGwZmtlsWKPxJ5p Y0IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vco1rZsmOfAiDEQiUNF7wdu8HAmq+ilrehMUdgZuqYo=; b=QgWYjON0zABMrjccg08k3RgV5YQr/KPBJzzcW5XzY8KcK091QrJFz6nFzrDZp/fyXB u4QJBh9NZ5dUGyzzEsvZjU0jvoXP1KoUMYZwWwgkVtEShoFZamsK3veyWHUFfkXl0Rj3 01gUI1F9B4vykT+PnOjD4/Eb9tKmxz+jjtWQ0/xEraVqBnuR1PkIrW6CmJ8SHX+9gUro yMDQKj1jDuj/CmmbnWggbneIx42JHmEHOVxR79gDeJvIQfEeq0lwUX8o7zQetKO3jEt8 WQTvKMTtnUk7008ri3d3SldrS9cH2KL1CwGrxGVb55Qfa+XNeE21Yj+B+wivwUs/eZBP Ekkg== X-Gm-Message-State: APt69E1yND3/YJtmXtF2GwSCypT39rByXq4CrgVOTaVtn08iSoLjTXM7 RzKpLiuxJUIZ7OeI81jJy8c7wKweTPI= X-Google-Smtp-Source: AAOMgpdHItSrZwJ+DcFsHmxSe0S/PGpnz/uVrN4eITo7VJuI9PnDDFe9Kfs46U4Thgwh8jblCeeVOA== X-Received: by 2002:a65:468e:: with SMTP id h14-v6mr7551739pgr.89.1530845126419; Thu, 05 Jul 2018 19:45:26 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id d132-v6sm14955723pga.10.2018.07.05.19.45.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jul 2018 19:45:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Neil Jhaveri In-Reply-To: Date: Thu, 5 Jul 2018 19:45:23 -0700 Cc: IETF JMAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <194337F4-8365-4FAC-AB10-48019B5263C4@neiljhaveri.com> To: Neil Jenkins X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Jmap] Reverse-chronological ordering of pages of /changes? 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, 06 Jul 2018 02:45:30 -0000 > On Jul 5, 2018, at 5:14 PM, Neil Jenkins = wrote: >=20 > On Thu, 5 Jul 2018, at 12:00 PM, Neil Jhaveri wrote: >> To support this, a call to /changes will need to encapsulate: >> 1. What state the client is coming from >> 2. What partial state the client has already consumed (so a server = can figure out what=E2=80=99s already been sent to the client) >=20 > You're right, this is not actually difficult to do. Thinking about = this, because the state string is opaque to the client there's really = nothing to stop a server doing this without making any changes to the = API. (It can still be a very short state string too; I've no idea what = MS does to end up with apparently several kilobytes long state strings = sometimes with Exchange!) Okay, that certainly works, and after reading the exact text, I agree = it=E2=80=99s the best way forward. It=E2=80=99s very simple, is = consistent with what EWS is already doing, and it leaves the = possibility for a highly motivated server to solve the =E2=80=9Cnew = update after the client has already started paging in old changes=E2=80=9D= problem, as well, by encoding the exact consumed content into the state = string. So that is good, and I=E2=80=99m very happy with this approach. > I've created a pull request = to add the following section to the /changes description: >=20 > --- >=20 > If a record has been created AND updated since the old state, the = server SHOULD just return the id in the *created* list, but MAY return = it in the *updated* list as well. >=20 > If a record has been updated AND destroyed since the old state, the = server SHOULD just return the id in the *destroyed* list, but MAY return = it in the *updated* list as well. >=20 > If a record has been created AND destroyed since the old state, the = server SHOULD remove the id from the response entirely, but MAY include = it in the *destroyed* list, and if so MAY also include it in the = *created* list. I think that covers all of the coalescing cases nicely. > If a *maxChanges* is supplied, or set automatically by the server, the = server MUST ensure the number of ids returned across *created*, = *updated* and *destroyed* does not exceed this limit. If there are more = changes than this between the client's state and the current server = state, the server SHOULD generate an update to take the client to an = intermediate state, from which the client can continue to call = *Foo/changes* until it is fully up to date. If it is unable to calculate = an intermediate state, it MUST return a `cannotCalculateChanges` error = response instead. >=20 > When generating intermediate states, the server may choose how to = divide up the changes. For many types it will provide a better user = experience to return the more recent changes first, as this is more = likely to be what the user is most interested in. The client can then = continue to page in the older changes while the user is viewing the = newer data. For example, suppose a server went through the following = states: >=20 > A -> B -> C -> D -> E >=20 > And a client asks for changes from state `B`. The server might first = get the ids of records created, updated or destroyed between states D = and E, returning them with: >=20 > state: "B-D-E" > hasMoreChanges: true >=20 > The client will then ask for the change from state `B-D-E`, and the = server can return the changes between states C and D, returning: >=20 > state: "B-C-E" > hasMoreChanges: true >=20 > Finally the client will request the changes from `B-C-E` and the = server can return the changes between states B and C, returning: >=20 > state: "E" > hasMoreChanges: false >=20 > Should the state on the server be modified in the middle of all this = (to `F`), the server still does the same but now when the update to = state `E` is returned, it would indicate that it still has more changes = for the client to fetch. >=20 > Where multiple changes to a record are split across different = intermediate states, the server MUST NOT return a record as created in a = later response than one which gives it as updated or destroyed, and MUST = NOT return a record as destroyed before a response that gives it as = created or updated. The server may have to coalesce multiple changes to = a record to satisfy this requirement. >=20 > --- >=20 > I prefer this to adding extra arguments to /changes as it keeps the = API (and client implementation) simpler, while giving servers more = flexibility (for example, if Gmail were to implement JMAP I'd imagine it = would be easier for them to do so in a way that's closer to their = proprietary API). For some types, it may also actually make for a better = experience to return oldest changes first. >=20 > Does this look like reasonable to you? Describing this clearly is = hard, so any suggestions for improving the text are welcome! Yeah! I think this language works really well and read very cleanly to = me.=20 Thanks, Neil! >=20 > Neil._______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Thu Jul 5 20:09:25 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 77892130E6F for ; Thu, 5 Jul 2018 20:09:22 -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=s+ruWczy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bp3qboMq 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 zdS76kejaQtr for ; Thu, 5 Jul 2018 20:09:20 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DC2130E2B for ; Thu, 5 Jul 2018 20:09:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D9BF1228; Thu, 5 Jul 2018 23:09:19 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 05 Jul 2018 23:09:20 -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=fm3; bh=yJYFAAH+zIfEaxJ7e8mKFkObsWKYufsJKnb0tC1YV 74=; b=s+ruWczyoed+Ef/vdtFiNGi3nFxHcDVhhcVfhYzsOdAGWYdoRGGU0UKk1 Hy7cdJ5Qo3HYrowOv3TPZFiHSw1twUMJN5U9IDhYdVaHHHIMgoPGqcZayaTWlgbT aHGc1cB2maflOmXEv+hGE3/2tMAUGya2XpTs+buxEvWcdqd7F2giJQHZibYdDJPR w23QMQgeYsDYePLr75yTu+MM35dMnCed7VMciKnSrqB1r97NP7ahdfAW0qheuele c80bbOgLNU6JGpqYs6n4jE2/IYThdZqnTrpfo1UPZqqtLc1X0UnCjEi1h5wSlSwU rdEzKzMVbwaxRcJt9VrriwilVEIkA== 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=yJYFAAH+zIfEaxJ7e8mKFkObsWKYufsJKnb0tC1YV 74=; b=bp3qboMqHwtsU7Nq+Pii0iYfcy6yS9MLFO3ol1JAjdpokND5he6t4djbO r4kH1bF82kYcnZLWAopUCWRzev7uzloAk9UYjlHRgUTz8IJhT6ZJpbfrFnjMT9Eq qNGfm4Ewc32URj4uYxPB99nHp0BieVNAGZvJ//8g5wlC8oCjQlcaIZraHnbTddzc fzTH1YmM5Pjyf1ZjEgkG8c2kBUmBhtIfE1zU6sGBElNeGeYQgCEsW2PhVTkWU/Cw 6holwv2srBL8KyKRkcqcW2/bDLh+waxUMsPsbPXw4HWtigYVPd6oyrfdN8Epo3Ae QwsRWqSvX3sdZXHzC+iLR6vEgPGjQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E0C22CA13D; Thu, 5 Jul 2018 23:09:18 -0400 (EDT) Message-Id: <7809a8a9-d60d-424f-8990-06322ad0cd59@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-707-gc22f408-next x-jmap-identity-id: 64588216 In-Reply-To: References: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> Date: Thu, 05 Jul 2018 23:09:18 -0400 From: Neil Jenkins To: Neil Jhaveri Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=525386aa8287436db17833a34a40eb7c 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: Fri, 06 Jul 2018 03:09:23 -0000 --525386aa8287436db17833a34a40eb7c Content-Type: multipart/related; boundary=b4bd528072844c4da2c73f7992fc3c4b --b4bd528072844c4da2c73f7992fc3c4b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, 5 Jul 2= 018, at 5:05 PM, Neil Jhaveri wrote:
Would this token then b= e an argument to PushSubscription/get?

I've made it just a property on the PushSubscriptio= n object. You can fetch the currently active subscriptions and then filt= er out those that don't have the appropriate id.

W= hen using an expiring credential, I think it would be good to be able to= extend the lifetime of the push subscription beyond the lifetime of the= credential. Is that allowed by your proposal?

Yes, this is just a standard "update" to the expi= res property of the subscription object.

In addition, is th= ere a maximum limit on the expiration time? I could easily see an iOS de= veloper wanting a week, or even up to 30 days, to behave better in cases= where the user has disabled background app refresh.

I've made this entirely server dependent, b= ut said it MUST be at least 48h and SHOULD be at least 7 days.
=

= Pull request with proposed changes here, review welcome! In particul= ar, I've specified there are no state strings (and so no /changes method= ) for PushSubscription objects. This feels right to me, as they are not = like standard objects; they may not be in a persistent store, they're no= t tied to a specific account, and the client should only be interested i= n subscriptions it creates itself. But if people think otherwise, pipe u= p!

Cheers,
Neil.
= --b4bd528072844c4da2c73f7992fc3c4b-- --525386aa8287436db17833a34a40eb7c Content-Type: text/plain On Thu, 5 Jul 2018, at 5:05 PM, Neil Jhaveri wrote: > Would this token then be an argument to PushSubscription/get? I've made it just a property on the PushSubscription object. You can fetch the currently active subscriptions and then filter out those that don't have the appropriate id. > When using an expiring credential, I think it would be good to be able to extend the lifetime of the push subscription beyond the lifetime of the credential. Is that allowed by your proposal? Yes, this is just a standard "update" to the expires property of the subscription object. > In addition, is there a maximum limit on the expiration time? I could easily see an iOS developer wanting a week, or even up to 30 days, to behave better in cases where the user has disabled background app refresh. I've made this entirely server dependent, but said it MUST be at least 48h and SHOULD be at least 7 days. Pull request with proposed changes here , review welcome! In particular, I've specified there are no state strings (and so no /changes method) for PushSubscription objects. This feels right to me, as they are not like standard objects; they may not be in a persistent store, they're not tied to a specific account, and the client should only be interested in subscriptions it creates itself. But if people think otherwise, pipe up! Cheers, Neil. --525386aa8287436db17833a34a40eb7c-- From nobody Thu Jul 5 20:19:04 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E770130E60 for ; Thu, 5 Jul 2018 20:19:03 -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=j6XraohD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LIWLALLm 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 wHEdJDoikCjb for ; Thu, 5 Jul 2018 20:19:02 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BA2130E1D for ; Thu, 5 Jul 2018 20:19:02 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 8635921D; Thu, 5 Jul 2018 23:19:01 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 05 Jul 2018 23:19:01 -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=fm3; bh=/aax9Y7nsNJsCNdk+0T3VlLQCkcjlUEnXo7JLCxB8 +I=; b=j6XraohD8A64nue8q7H4wuHbrkzaTlCdIbTtcQfnrucJNpIHyD9i2taET qQxmLkzWL4shO70x8DU01DCfy+rKxMargCXEOBFNH6MWWLPjpYQaOaUbjMH7xfa4 +Bnuhpm1nPcW3HloA1ZZmwn7dnv6RyY/nr6xsX/Gci7I9fRG6oJASnbh1e6Z4/u4 JS4TzPygF/KXleeZBJlTf3MJhe45NCF1Yo0jlF8jh6FNERU2A0DP0A9+GB7kgjKo KKSXCbEX6GFMxGZZ9lLXdAKC9SzD4nNXDz0l1bzqSdpd1VLpB/5nkREa6TuDDG2Q 55NBM+cGLXk0ZbZp+TqkrhUfB6iZw== 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=/aax9Y7nsNJsCNdk+0T3VlLQCkcjlUEnXo7JLCxB8 +I=; b=LIWLALLmjuvRDfhnMc0/O31f5J3Rhgpc2UC9GEUgMh077aUeHnZp0//3c iegNQCUCwCT2oXvW4LQiNQMM/fFyICyLekQ9yMwiKwsbWOqMIeyg03QCftDQWjdP tSyikFZ96hEffjxpZVBNVj+BY5LBJqwrLfUWqj5zQK2rXE1tDidlSmknkFiDAnAm WT/cEp3jF1XJkfQQKHoni5dGXO3VQbk43IborTaHlN7Ru+wvLTTbMJ60HnOhyqWL nbUtf9UqD2m5yKxzdhrXRhdnEyJdlv+QMVfekCOAQ4K0uOwakq5o5RjcGu0AXVUC 2pXC2NcYQjImYiUtljvrGwGWlvkAw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7526CCA13D; Thu, 5 Jul 2018 23:19:00 -0400 (EDT) Message-Id: <9d458346-6062-45f5-9b7a-00f1d1c92585@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-707-gc22f408-next x-jmap-identity-id: 64588216 In-Reply-To: <2D462F98-F0C0-41A3-BD98-563C1B29B249@neiljhaveri.com> References: <2D462F98-F0C0-41A3-BD98-563C1B29B249@neiljhaveri.com> <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> Date: Thu, 05 Jul 2018 23:18:21 -0400 From: Neil Jenkins To: Neil Jhaveri Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=abb20661b3224bfcb39f3cea904037dc 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: Fri, 06 Jul 2018 03:19:03 -0000 --abb20661b3224bfcb39f3cea904037dc Content-Type: multipart/related; boundary=78a048245b7f4d228922d31717e3ca9b --78a048245b7f4d228922d31717e3ca9b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, 6 Jul 2= 018, at 3:44 AM, Neil Jhaveri wrote:
Also, with PushSubscriptions, it might be go= od to think about how they could be used with FCM and APNS. (Note, I kno= w nothing about FCM and I have only done light reading about APNS =E2=80= =94 never actually built anything using it.)
=
My understanding is that you are going to need a lightwei= ght proxy server of your own whatever we do, as you need to authenticate= the connection to APNs using a private certificate that should not be s= hared (so shouldn't be built into the app). Given this, it can trivially= add the other data/headers while authenticating the request.
<= div>
I'm not deeply familiar with APNs (and even less so w= ith FCM), so I might be wrong about this.

Last year, I asked engineers at Apple working on APNS if they thought= they could support RFC 8030 semantics, and they said maybe they could e= xpose the 8030-style push endpoints (as opposed to hour-life-token-based= auth or certificate-based auth funneling to a single URI). But, I think= even if they did that, there would still likely be a need for custom&nb= sp;payload content, and potentially custom headers on every push.

Ah, so they might add something in the future that = would avoid the authentication problem then? If so, it would be nice to = be able to get the JMAP server to push directly without needing a proxy.= However, I'm hesitant to add extra complexity to the spec when we don't= actually know exactly what will be required yet. I think this is probab= ly better left for a future extension when the requirements are known.

If someone with more experience working with= these systems would like to comment, I'd love to hear it.
Neil.
--78a048245b7f4d228922d31717e3ca9b-- --abb20661b3224bfcb39f3cea904037dc Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 6 Jul 2018, at 3:44 AM, Neil Jhaveri wrote: > Also, with PushSubscriptions, it might be good to think about how they= could be used with FCM and APNS. (Note, I know nothing about FCM and I = have only done light reading about APNS =E2=80=94 never actually built a= nything using it.) My understanding is that you are going to need a lightweight proxy serve= r of your own whatever we do, as you need to authenticate the connection= to APNs using a private certificate that should not be shared (so shoul= dn't be built into the app). Given this, it can trivially add the other = data/headers while authenticating the request. I'm not deeply familiar with APNs (and even less so with FCM), so I migh= t be wrong about this. > Last year, I asked engineers at Apple working on APNS if they thought = they could support RFC 8030 semantics, and they said maybe they could ex= pose the 8030-style push endpoints (as opposed to hour-life-token-based = auth or certificate-based auth funneling to a single URI). But, I think = even if they did that, there would still likely be a need for custom=C2=A0= payload content , and potentially=C2=A0custom headers =C2=A0on every push. Ah, so they might add something in the future that would avoid the authe= ntication problem then? If so, it would be nice to be able to get the JM= AP server to push directly without needing a proxy. However, I'm hesitan= t to add extra complexity to the spec when we don't actually know exactl= y what will be required yet. I think this is probably better left for a = future extension when the requirements are known. If someone with more experience working with these systems would like to= comment, I'd love to hear it. Neil. --abb20661b3224bfcb39f3cea904037dc-- From nobody Thu Jul 5 21:41:56 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 616C4130E9B for ; Thu, 5 Jul 2018 21:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=T7FMemcj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X0je7wTe 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 z2PaQ05Bs4Jg for ; Thu, 5 Jul 2018 21:41:53 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0184B130DEC for ; Thu, 5 Jul 2018 21:41:53 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.west.internal (Postfix) with ESMTP id 888B423D for ; Fri, 6 Jul 2018 00:41:52 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 06 Jul 2018 00:41:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=GlfcytOmApPNb4N9pTnQDTCSnXRXcwNDHTqQ8Kbld 20=; b=T7FMemcjjH+Nw8/9XNyMzdp8BDMFdYnfq8BqH8elyOHSc2vzk2ptkMU30 uo33x+azH1hemJ/nvShAU1q+AZdDWCj1r8LP/NbnlGBc2wrV0lEF4arj4GtTJ8mf nrWMlPvh/qXQ/FVZCbnYGuFU15E8B03KWL5XLrEL5geuDolUtjItQW6Q2Px71BYa Flwj4VLn0yl6t0yG61dea3oBP41Lk4nBSl1O0sxJNoN1UHISIHwLpirwHdOH/8uu 3TrJXRJ0QA48UB/gbIX7i9TtieKgIEXHzA8xYK/bQ7mhXosaRH8h0MEt8Am8wqwn oV3G5v8f5MeSb200snrUCUkQIUsAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=GlfcytOmApPNb4N9pTnQDTCSnXRXc wNDHTqQ8Kbld20=; b=X0je7wTeA4jihAsH+h6IBOBhQs0xG7vrdam9umP4Xb8zs CvC0f5GWRa4fmYrXUxnw05h1YgqLzkNXAaJo2F9ywTPPZR+xRjAm3d6vk/iRTCnB 9KlEpKKTZMqMacWCI3s5SDaS13IyuH3TlDuv8t+2VQ5XKPODPcf96euCf5GD2Dnf WVWOi6Qd4TSUyF8DwV2eEDiLu0ziARX6AgYpTPB2ZUozcfep73WIPdoI3zMZLZ3r QsD+SC7UFV0HMTBcdjXiNIM31lzy+yg+wZW5UEUI7p307qPrU3D/VaET2hJAg7Bu NxEqIIciV3HPMzYZAXGE+6sBToRrbR2jGH21c6c0g== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 91AA1E2150; Fri, 6 Jul 2018 00:41:51 -0400 (EDT) Message-Id: <1530852111.810986.1431676088.5720F890@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15308521118109860" X-Mailer: MessagingEngine.com Webmail Interface - ajax-68b46f9b Date: Fri, 06 Jul 2018 14:41:51 +1000 Archived-At: Subject: [Jmap] Draft Montreal Agenda 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, 06 Jul 2018 04:41:55 -0000 This is a multi-part message in MIME format. --_----------=_15308521118109860 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" JMAP IETF102 Montreal / 2018-07-16 13:30-14:30 INTRO & NOTE WELL: 2m CORE: 8m * registry of error types * push subscription * steps to last call! MAIL: 20m * Email groups in addresses * Things that make sense as extensions removed * steps to last call! EXTENSIONS: 20m * do we need to update charter for extensions? * vacation response - neilj * full sieve - who? * MDN - who? * single HTML body - who? * search inside attachments - who? OTHER BUSINESS: 10m Please let me know if I've missed anything you want to talk about, or if the timings are way off. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15308521118109860 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
JMAP IETF102 Montreal / 2018-07-16 13:30-14:30

INTRO & NOTE WELL: 2m
CORE: 8m
  * registry of error types
  * push subscription
  * steps to last call!
MAIL: 20m
  * Email groups in addresses
  * Things that make sense as extensions removed
  * steps to last call!
EXTENSIONS: 20m
  * do we need to update charter for extensions?
  * vacation response - neilj
  * full sieve - who?
  * MDN - who?
  * single HTML body - who?
  * search inside attachments - who?
OTHER BUSINESS: 10m

Please let me know if I've missed anything you want to talk about, or if the timings are way off.

Thanks,

Bron.


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


--_----------=_15308521118109860-- From nobody Fri Jul 6 06:10:37 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8F0130E41 for ; Fri, 6 Jul 2018 06:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1kLMXQjhY5a for ; Fri, 6 Jul 2018 06:10:34 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9A4130E06 for ; Fri, 6 Jul 2018 06:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1530882633; d=isode.com; s=june2016; i=@isode.com; bh=ZbwtL04EIKCYFE2U85+kndxsR//sNXkj34BxP5L7AEA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bPH1CnuQrT6yCeuWdEDuP3jEm6b6FgpGxiz4g/gRC1j3TyrKuoea2qDwAw1CBFDutuRgc5 bsha04TIcTGzJ4t8bBaVD8/RaElM8ZRtrrcdYMcAeRaF+yyqd2o7qMcNTnHc4rpiDnOHvX Tp7yRZ6oeLDVNdXZ8HK9oAmLaUfxOn4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 6 Jul 2018 14:10:33 +0100 To: Bron Gondwana , jmap@ietf.org References: <1530852111.810986.1431676088.5720F890@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: Date: Fri, 6 Jul 2018 14:10:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <1530852111.810986.1431676088.5720F890@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E2312F8E10E20051534DC204" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Draft Montreal Agenda 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, 06 Jul 2018 13:10:36 -0000 --------------E2312F8E10E20051534DC204 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 06/07/2018 05:41, Bron Gondwana wrote: > JMAP IETF102 Montreal / 2018-07-16 13:30-14:30 > > INTRO & NOTE WELL: 2m > CORE: 8m > =C2=A0 * registry of error types > =C2=A0 * push subscription > =C2=A0 * steps to last call! > MAIL: 20m > =C2=A0 * Email groups in addresses > =C2=A0 * Things that make sense as extensions removed > =C2=A0 * steps to last call! > EXTENSIONS: 20m > =C2=A0 * do we need to update charter for extensions? > =C2=A0 * vacation response - neilj > =C2=A0 * full sieve - who? > =C2=A0 * MDN - who? > =C2=A0 * single HTML body - who? > =C2=A0 * search inside attachments - who? > OTHER BUSINESS: 10m With my individual contributor hat on: I would like to discuss=20 draft-murchison-jmap-websocket. --------------E2312F8E10E20051534DC204 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 06/07/2018 05:41, Bron Gondwana wrote:

JMAP IETF102 Montreal / 2018-07-16 13:30-14:30

INTRO & NOTE WELL: 2m
CORE: 8m
=C2=A0 * registry of error types
=C2=A0 * push subscription
=C2=A0 * steps to last call!
MAIL: 20m
=C2=A0 * Email groups in addresses
=C2=A0 * Things that make sense as extensions removed
=C2=A0 * steps to last call!
EXTENSIONS: 20m
=C2=A0 * do we need to update charte= r for extensions?
=C2=A0 * vacation response - neilj
=C2=A0 * full sieve - who?
=C2=A0 * MDN - who?
=C2=A0 * single HTML body - who?
=C2=A0 * search inside attachments - who?
OTHER BUSINESS: 10m

With my individual contributor hat on: I would like to discuss draft-murchison-jmap-websocket.


--------------E2312F8E10E20051534DC204-- From nobody Sat Jul 7 12:40:51 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 C533F130EA5 for ; Sat, 7 Jul 2018 12:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=Yd06hCbW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dY6a8yoN 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 ztZUbOxgedl6 for ; Sat, 7 Jul 2018 12:40:47 -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 248871274D0 for ; Sat, 7 Jul 2018 12:40:47 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8AE8721D6D; Sat, 7 Jul 2018 15:40:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 07 Jul 2018 15:40:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= 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=4jNs5Q/QTrRL8+hF4ZPMVomA70L9DULG5SYl7co21f8=; b=Yd06hCbW m23d7A5gHgxdK/7pGMPNdpAcDNQhThroBg2yCfx2nxnFCIKKLcEVw8bcaq4rJ086 WUCrkYTvc4C8saJpJ5FTuR03Yqb3OWay2jde1oyMyYx7SP7Ay3IY+GzcrmEuy6U0 kPbG1aT60Mq8t6DVavBdRtGSZ1ah9ZXgVTSC3pwj7t+lyGoLcuV2FtHHDI9cect4 qgN/flc3v146sOCmXZD/4tipRCnMahESq5qW4kzZY0kqAE/UcfnIQn+pdtWmFDTU q6mKXnPDmzThapQm9vMIMin7sOL7+sZI5dLtBU4Ckg2NaF7RY3iuNVysmQ4TFTHa ABj3qo4zAEZfgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=4jNs5Q/QTrRL8+hF4ZPMVomA70L9D ULG5SYl7co21f8=; b=dY6a8yoNy5O3Ozl++NaOiExO22ZpciGa+So7XLurY9T4k Of1oSA2dnLESyn/TTofkwyEZVTud5cXnlH91LWVoqi3+94fLI5cVCn+hv8LvAcAa poEuA104dWfmCjGNkRPb2e6v8IybZ1t7OeHRvaeyzHCoZtkZrYDrBYQUJCEgK6i+ 8s0hIsEQYx/UXOtH+iK5W0KwIZOEZWFn42UCIhyiWV+Z0PnijO5l7OCXoXgbnhnD lTWSRguR/4Z+eUhSIVcj0O4yWL7Qns5d79eNtPNI2QliqXfNAYIq3SoZSXy/FUeH 38Wdljg5CMAKhpqJzQz/Ik43efEXOKEljQz/k02rg== X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 925DBE414A; Sat, 7 Jul 2018 15:40:45 -0400 (EDT) To: Alexey Melnikov , Bron Gondwana , jmap@ietf.org References: <1530852111.810986.1431676088.5720F890@webmail.messagingengine.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <7fc82e88-fee1-1305-cfb9-292fc4185b4a@fastmail.com> Date: Sat, 7 Jul 2018 15:40:45 -0400 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: Content-Type: multipart/mixed; boundary="------------A94040C905FD78084BCF26C2" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Draft Montreal Agenda 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, 07 Jul 2018 19:40:49 -0000 This is a multi-part message in MIME format. --------------A94040C905FD78084BCF26C2 Content-Type: multipart/alternative; boundary="------------1040F559DEBA922B76D70FAF" --------------1040F559DEBA922B76D70FAF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07/06/2018 09:10 AM, Alexey Melnikov wrote: > > On 06/07/2018 05:41, Bron Gondwana wrote: > >> JMAP IETF102 Montreal / 2018-07-16 13:30-14:30 >> >> INTRO & NOTE WELL: 2m >> CORE: 8m >>   * registry of error types >>   * push subscription >>   * steps to last call! >> MAIL: 20m >>   * Email groups in addresses >>   * Things that make sense as extensions removed >>   * steps to last call! >> EXTENSIONS: 20m >>   * do we need to update charter for extensions? >>   * vacation response - neilj >>   * full sieve - who? >>   * MDN - who? >>   * single HTML body - who? >>   * search inside attachments - who? >> OTHER BUSINESS: 10m > > With my individual contributor hat on: I would like to discuss > draft-murchison-jmap-websocket. Uh oh!  Is that a good or bad thing?  :) Should I prepare some slides? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------1040F559DEBA922B76D70FAF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 07/06/2018 09:10 AM, Alexey Melnikov wrote:

On 06/07/2018 05:41, Bron Gondwana wrote:

JMAP IETF102 Montreal / 2018-07-16 13:30-14:30

INTRO & NOTE WELL: 2m
CORE: 8m
  * registry of error types
  * push subscription
  * steps to last call!
MAIL: 20m
  * Email groups in addresses
  * Things that make sense as extensions removed
  * steps to last call!
EXTENSIONS: 20m
  * do we need to update charter for extensions?
  * vacation response - neilj
  * full sieve - who?
  * MDN - who?
  * single HTML body - who?
  * search inside attachments - who?
OTHER BUSINESS: 10m

With my individual contributor hat on: I would like to discuss draft-murchison-jmap-websocket.

Uh oh!  Is that a good or bad thing?  :)

Should I prepare some slides?


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------1040F559DEBA922B76D70FAF-- --------------A94040C905FD78084BCF26C2 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------A94040C905FD78084BCF26C2-- From nobody Sat Jul 7 15:10:52 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6CA130EC7 for ; Sat, 7 Jul 2018 15:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1NgO2oLs4Yc for ; Sat, 7 Jul 2018 15:10:50 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id EE28D130EC1 for ; Sat, 7 Jul 2018 15:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1531001449; d=isode.com; s=june2016; i=@isode.com; bh=wW5YCTmT6xr1x2rc7y6JNGLJfSg4gTq3e4mARZELzro=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=pBkAuEPLhAoygHxxc0uRMHhpkUp8TpJWPTn/fsZzvNIq3Tmjojjk4PYUMMFzrYGIaInEmi JBFDol+IIUetHUc8LBOEoK8WsvYSERWdsKjjp56cOlZ6yUXyf0tpQSqhgTuqQ8MwAlrWqx 4qMAJs98FPQK9Bbyui+rc4TnEw7QmH4=; Received: from [10.12.242.110] ((unknown) [85.255.232.138]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 7 Jul 2018 23:10:48 +0100 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov X-Mailer: iPhone Mail (15D60) In-Reply-To: <7fc82e88-fee1-1305-cfb9-292fc4185b4a@fastmail.com> Date: Sat, 7 Jul 2018 23:10:47 +0100 Cc: Bron Gondwana , jmap@ietf.org Message-Id: References: <1530852111.810986.1431676088.5720F890@webmail.messagingengine.com> <7fc82e88-fee1-1305-cfb9-292fc4185b4a@fastmail.com> To: Ken Murchison MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-4167A2DB-7E28-4249-92E7-2EA8233B70D4 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Draft Montreal Agenda 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, 07 Jul 2018 22:10:51 -0000 --Apple-Mail-4167A2DB-7E28-4249-92E7-2EA8233B70D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 7 Jul 2018, at 20:40, Ken Murchison wrote: >=20 >> On 07/06/2018 09:10 AM, Alexey Melnikov wrote: >>> On 06/07/2018 05:41, Bron Gondwana wrote: >>> JMAP IETF102 Montreal / 2018-07-16 13:30-14:30 >>>=20 >>> INTRO & NOTE WELL: 2m >>> CORE: 8m >>> * registry of error types >>> * push subscription >>> * steps to last call! >>> MAIL: 20m >>> * Email groups in addresses >>> * Things that make sense as extensions removed >>> * steps to last call! >>> EXTENSIONS: 20m >>> * do we need to update charter for extensions? >>> * vacation response - neilj >>> * full sieve - who? >>> * MDN - who? >>> * single HTML body - who? >>> * search inside attachments - who? >>> OTHER BUSINESS: 10m >>=20 >> With my individual contributor hat on: I would like to discuss draft-murc= hison-jmap-websocket. >=20 > Uh oh! Is that a good or bad thing? :) I like it :-). > Should I prepare some slides? I think so, but chairs choice. --Apple-Mail-4167A2DB-7E28-4249-92E7-2EA8233B70D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 7 Jul 2018, at 20:40, Ken Murchison <murch@fastmail.com> wrote:

On 07/06/2018 09:10 AM, Alexey Melnikov wrote:

On 06/07/2018 05:41, Bron Gondwana wrote:

JMAP IETF102 Montreal / 2018-07-16 13:30-14:30

INTRO & NOTE WELL: 2m
CORE: 8m
  * registry of error types
  * push subscription
  * steps to last call!
MAIL: 20m
  * Email groups in addresses
  * Things that make sense as extensions removed
  * steps to last call!
EXTENSIONS: 20m
  * do we need to update charter for extensions?
  * vacation response - neilj
  * full sieve - who?
  * MDN - who?
  * single HTML body - who?
  * search inside attachments - who?
OTHER BUSINESS: 10m

With my individual contributor hat on: I would like to discuss draft-murchison-jmap-websocket.

Uh oh!  Is that a good or bad thing?  :)

I like it :-).

Should I prepare some slides?

I think so, but chairs choice.

--Apple-Mail-4167A2DB-7E28-4249-92E7-2EA8233B70D4-- From nobody Sun Jul 8 21:52:15 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 82066130F0F for ; Sun, 8 Jul 2018 21:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwB8cuBCMxqk for ; Sun, 8 Jul 2018 21:52:06 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9E7130F12 for ; Sun, 8 Jul 2018 21:52:05 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id b17-v6so12747280pfi.0 for ; Sun, 08 Jul 2018 21:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jD3sg/0vY9wzKGkSyprKBWIHnwfjgL8ksLQ0EZlqtTI=; b=w4YiZFhcEceXA8jz6+6wW7oQCnp65j/n1OMv18oNEAIzSeVk/KcpOONEibbfPoRmiR 93aNNGNhpi3zN84Bvl2607OkV1NBirkZI/tNAii1EdXFgvMjwe/6e6YSvqLV/rUJtXAY xU+lDcw893S1Sc97k5DiP1RgTqsmZSZb4GYd+k9ATp0TKWlSTsELe7swY69zXLt7EN0a Pkan8/TLlc7RuXMjt8wlAXZQ9Bc7OXxYxYfhiWWLX4hM2e4YpWTf/m4omemdDl7cFkz2 zpohG3Vy3wUZs4gHuBnhKuJOecJ4im8DNt7N1N25vI32LlOxlFkj9269Y+gjMXs30xIS b7Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jD3sg/0vY9wzKGkSyprKBWIHnwfjgL8ksLQ0EZlqtTI=; b=A1O2S4NuEqYDCvMAt5hbWWuK4fhic1rdclwJa92RyJMShAjrDvVRiehi2wnUhnt4GP 5HuQXFZcu5utVE2erQPbB7tInWnA3gjctdSiLu0iUpOEc0UkfQiSc8C9dajYQkJ+Aaa2 eCI5pow8MzbQMvYCjblO0WIf6P26osPVZMWpLFsXwd7zApGIUhURCQzmLNzyXRPpAqJE 1mAd1+UN7sGwZFzfQrbwDCoASz/5HdNoW0j62tZaDhimkdfaeh8mIwCTZU7YHi8Ri+Mh 9fpVOsW9nEVY77Pd9eK+Av1sDG0SyDphoDZmYSe7M7/1cokIWNgf/hQASSxYaG/eHIt2 gIeQ== X-Gm-Message-State: APt69E3Z7uwDEuRzdYF2ayuLmPbCeZPqR9B4logySFVoVRg6mPcHOx0L e2zF1ZTPmbWlwcVSAEUuMT8BDg== X-Google-Smtp-Source: AAOMgpfVztaimYBo5zmJzWPLNZUcQ4d6558PED7M/Ggh90tVnk+xamuIH+yGrwX5w94OBZUqWRpTrQ== X-Received: by 2002:a63:b91c:: with SMTP id z28-v6mr17580932pge.22.1531111924593; Sun, 08 Jul 2018 21:52:04 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id p5-v6sm12292895pfn.57.2018.07.08.21.52.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 21:52:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Neil Jhaveri In-Reply-To: <7809a8a9-d60d-424f-8990-06322ad0cd59@sloti22d1t06> Date: Sun, 8 Jul 2018 21:52:01 -0700 Cc: IETF JMAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <212DBF78-BB4E-4EFB-BEE1-BC13C63F57BA@neiljhaveri.com> References: <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> <7809a8a9-d60d-424f-8990-06322ad0cd59@sloti22d1t06> To: Neil Jenkins X-Mailer: Apple Mail (2.3445.8.2) 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: Mon, 09 Jul 2018 04:52:09 -0000 > On Jul 5, 2018, at 8:09 PM, Neil Jenkins = wrote: >=20 > On Thu, 5 Jul 2018, at 5:05 PM, Neil Jhaveri wrote: >> Would this token then be an argument to PushSubscription/get? >=20 > I've made it just a property on the PushSubscription object. You can = fetch the currently active subscriptions and then filter out those that = don't have the appropriate id. Ok, that seems reasonable to me too. >=20 >> When using an expiring credential, I think it would be good to be = able to extend the lifetime of the push subscription beyond the lifetime = of the credential. Is that allowed by your proposal? >=20 > Yes, this is just a standard "update" to the expires property of the = subscription object. Ok, great. >=20 >> In addition, is there a maximum limit on the expiration time? I could = easily see an iOS developer wanting a week, or even up to 30 days, to = behave better in cases where the user has disabled background app = refresh. >=20 > I've made this entirely server dependent, but said it MUST be at least = 48h and SHOULD be at least 7 days. Great, that seems reasonable to me. 48h is a good lower bound, and I = think it should work fine for most iOS developers (assuming we got to a = point where they could do this without a push proxy server). > Pull request with proposed changes here = , review welcome! In = particular, I've specified there are no state strings (and so no = /changes method) for PushSubscription objects. This feels right to me, = as they are not like standard objects; they may not be in a persistent = store, they're not tied to a specific account, and the client should = only be interested in subscriptions it creates itself. But if people = think otherwise, pipe up! I agree with leaving out /changes. >=20 > Cheers, > Neil. From nobody Sun Jul 8 22:01:08 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 54361130F15 for ; Sun, 8 Jul 2018 22:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydW7KNRXLB4G for ; Sun, 8 Jul 2018 22:01:04 -0700 (PDT) Received: from mail-pl0-x243.google.com (mail-pl0-x243.google.com [IPv6:2607:f8b0:400e:c01::243]) (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 8855A130F14 for ; Sun, 8 Jul 2018 22:01:04 -0700 (PDT) Received: by mail-pl0-x243.google.com with SMTP id c41-v6so5451775plj.10 for ; Sun, 08 Jul 2018 22:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qdqeKWXnX0YrcjUOG9R45ZTW6v5d98KKpo6g9yMItLM=; b=eFCWrzDCR2A7QCgWf9DdbymOq7QQ3/8cCEmRyhdCFh5ACvSWNCVL1dK18D3Kz8iTJv VOodwB5q1FsxdXONcpeFUlcsUlkQQjmw5UHY/Mwk4g7iZqpOKmpa+WAkSn0+t8xAiD3J M8ZGZdaM3fapS9YGh6js5WR28WnFZM+KLDrYuDfE1c5lepdHBp0xZVHD8KzHrQefUxhb AhQ/UabzzKSq2AZNzbEXeqlxN8LGzCO80KbLLRQqa/roLcsEPzNO0lih00F68w4AQby3 bQ2N55TJg5UzJz1OJufqEUKT0pS0IaZNwHRIKCuHMTgRgSyif9xFYUuG7KFr44z8+OGo K2nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qdqeKWXnX0YrcjUOG9R45ZTW6v5d98KKpo6g9yMItLM=; b=hgDrooa2ZxX1En9Ba6akm9rOKYoyE3NyBRQgx0y37sJnX9k1DnizGhZoaYe7+MiYIr 7E2VnKZe5ifjuKaEFeUeICLb3/FIQJInBNMAlLaDWrAv9h/MOLm1QzPX0Op/Ep9wOpbw T8oJzXtVLyE7U+HF2nqTFIKBdnDfj5ewJUoaek+BUzPExMxwrYxO1cOSGE9O2Bcwy1W9 PeOGEEa+yR/eIJs5UuPpQPE0iixUvJWeVeCu9f5I9UTmafrAHwirDWCd6JbvBnFvNODz kPpzGMpFCdpPTofwrcxAdoo2E26Jja7UG42RVYCIf9f9GXxA9ZlUe+oxUQVWfpVTApuh ta5A== X-Gm-Message-State: APt69E1T8+1EKgUSi6W/GhjT5tVQvg/gTCoZkRCqKeRNHf2/Mcr/YA96 8+qPV1HVJYqdYDTJIKeSR0oXoQ== X-Google-Smtp-Source: AAOMgpfSCMwZ1b2p6BUMd8OFVJgLB/f7+9ByNWV4JTAnU7LmeAz2svGNO1grEyWzPi8pks4GWCiDKw== X-Received: by 2002:a17:902:7606:: with SMTP id k6-v6mr1301937pll.56.1531112464008; Sun, 08 Jul 2018 22:01:04 -0700 (PDT) Received: from [192.168.1.14] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id y15-v6sm22309439pfm.136.2018.07.08.22.01.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 22:01:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Neil Jhaveri In-Reply-To: <9d458346-6062-45f5-9b7a-00f1d1c92585@sloti22d1t06> Date: Sun, 8 Jul 2018 22:01:02 -0700 Cc: IETF JMAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D462F98-F0C0-41A3-BD98-563C1B29B249@neiljhaveri.com> <94e59341-9e1e-4327-9509-8ece4ada8b95@sloti22d1t06> <9d458346-6062-45f5-9b7a-00f1d1c92585@sloti22d1t06> To: Neil Jenkins X-Mailer: Apple Mail (2.3445.8.2) 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: Mon, 09 Jul 2018 05:01:06 -0000 > On Jul 5, 2018, at 8:18 PM, Neil Jenkins = wrote: >=20 > On Fri, 6 Jul 2018, at 3:44 AM, Neil Jhaveri wrote: >> Also, with PushSubscriptions, it might be good to think about how = they could be used with FCM and APNS. (Note, I know nothing about FCM = and I have only done light reading about APNS =E2=80=94 never actually = built anything using it.) >=20 > My understanding is that you are going to need a lightweight proxy = server of your own whatever we do, as you need to authenticate the = connection to APNs using a private certificate that should not be shared = (so shouldn't be built into the app). Given this, it can trivially add = the other data/headers while authenticating the request. >=20 > I'm not deeply familiar with APNs (and even less so with FCM), so I = might be wrong about this. >=20 >> Last year, I asked engineers at Apple working on APNS if they thought = they could support RFC 8030 semantics, and they said maybe they could = expose the 8030-style push endpoints (as opposed to = hour-life-token-based auth or certificate-based auth funneling to a = single URI). But, I think even if they did that, there would still = likely be a need for custom payload content = , and = potentially custom headers = on = every push. >=20 > Ah, so they might add something in the future that would avoid the = authentication problem then? If so, it would be nice to be able to get = the JMAP server to push directly without needing a proxy. However, I'm = hesitant to add extra complexity to the spec when we don't actually know = exactly what will be required yet. I think this is probably better left = for a future extension when the requirements are known. Yeah, I think deferring that probably makes the most sense.=20 But I still think a JMAP server being able to push directly to APNS / = FCM without a proxy server, if those push services supported the = relevant portions of RFC 8030, would be really, really nice. > If someone with more experience working with these systems would like = to comment, I'd love to hear it. Let me see if I can get somebody from Apple=E2=80=99s APNS team to reply = to this thread and provide their opinions. Unfortunately, I don=E2=80=99t = know anybody that works on FCM, or has any experience with it. >=20 > Neil. From nobody Sat Jul 14 17:07: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 DABC9130E29 for ; Sat, 14 Jul 2018 17:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=grryyctu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VcviT2CL 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 goEpFIVTt7Bp for ; Sat, 14 Jul 2018 17:07:28 -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 885091277BB for ; Sat, 14 Jul 2018 17:07:28 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B19A3212C8 for ; Sat, 14 Jul 2018 20:07:27 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sat, 14 Jul 2018 20:07:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=DOqHDLENYsczBBQQ/KxoJQGVieibji5fKtoMpFcDI eM=; b=grryyctu/fuA+go0x6SedsqrnxhDP5ymGSxNHfpwm9eelZmYeYtTrdzQl Df9zIOHFfSf1Y630qoKrKmvZ+JUDuVBPEvuAbU8b2eapq7rwRoK28eZgpImPspwR 4MP5gTO/DlZqAq+Gw0mDzn1+a5jY1CKDPmSz0GQFcGuGXxl1wPjIpiQozyMb42G8 EuakHk9UJmG/AXGLHCrq6I7TKAMEXMzv91VSU2rvEXMgdg1LHOkq8PvnFMHK3Fu0 eulkbwXys6cd0LAHuSK/JffAihKAELGzPe9DzV4l1tjzcr3sz4gftmL14k1em6tJ FHSSpg6kvQMEEG9Enyzt025pd2Azg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=DOqHDLENYsczBBQQ/KxoJQGVieibj i5fKtoMpFcDIeM=; b=VcviT2CLSQphwKS8AvduJXZRchtMDtehyS4kzHJbvSbGC wJo3zGwuZIMl9a1r0AZ+70vV8XoKFEEuneDocQiNsRswK5dzSzzMf4lx1tr0zV1Z igsu57kGUdIA1LZGesZqswynwa5O9Ar1HksEE6PALd2W2dF6EYhSB4ZHSajzbeeW hpAM3tQG4qZOLhftfW8lAVH7eP858w+kzZJ8f+PrJ2PQOOCKZUhC2w+3rszqSbA3 4k3/ERhsMMQfDlxzff2MtWKUjYGE0E8isyGCxraJAnGTfpU93DSXJMjB9rSMa2DT 3oX4ZrkIEOaqUD8CJU8EKeChzQ3Yxs7S4cPlJzBaQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D2E739E10C; Sat, 14 Jul 2018 20:07:26 -0400 (EDT) Message-Id: <1531613246.3702698.1440951808.15A2F066@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153161324637026980" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Sun, 15 Jul 2018 10:07:26 +1000 Archived-At: Subject: [Jmap] Making clients explicitly request totals. X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 00:07:32 -0000 This is a multi-part message in MIME format. --_----------=_153161324637026980 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" (individual contributor hat) One of the design properties we discussed right back at the start of the JMAP effort was "don't make the server do any implicit work that the client doesn't need". A place in which we may not be meeting that well is the "total" field in /query and /queryChanges responses. In some cases, the server may have a complete total, but in other cases it might be significant work, particularly if it has to be a 100% accurate total. Likewise getting a perfect sort may sometimes be hard work, particularly if doing a "relevance" sort or similarly fuzzy thing. Or if there's duplicate suppression or thread collapsing happening. So... I'd like to float the idea of having a calculateTotal: true property on /query and /queryChanges, allowing a client to make a request like "give me the first 30 items" without a total, and the server can reply with either canCalculateChanges: false, or with a token that allows it to know which 30 items it previously returned, such that a request for the next page will get the right data. Think of something like Hacker News or Reddit, where you're getting the "first page" of items, and a token that allows you to get a next page later, until that token goes stale a few hours later. An alternative to having the client explicitly request totals is having the client explicitly request a loosening of the requirement - that's a philosophical question. My preferred philosophy is "the client has to ask for any work it wants the server to do", so default to not providing totals - but I'm open to discussion. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153161324637026980 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
(individual contributor hat)

One of the design properties we discussed right back at the start of the JMAP effort was "don't make the server do any implicit work that the client doesn't need". 

A place in which we may not be meeting that well is the "total" field in /query and /queryChanges responses.  In some cases, the server may have a complete total, but in other cases it might be significant work, particularly if it has to be a 100% accurate total.  Likewise getting a perfect sort may sometimes be hard work, particularly if doing a "relevance" sort or similarly fuzzy thing.  Or if there's duplicate suppression or thread collapsing happening.

So... I'd like to float the idea of having a calculateTotal: true property on /query and /queryChanges, allowing a client to make a request like "give me the first 30 items" without a total, and the server can reply with either canCalculateChanges: false, or with a token that allows it to know which 30 items it previously returned, such that a request for the next page will get the right data.

Think of something like Hacker News or Reddit, where you're getting the "first page" of items, and a token that allows you to get a next page later, until that token goes stale a few hours later.

An alternative to having the client explicitly request totals is having the client explicitly request a loosening of the requirement - that's a philosophical question.  My preferred philosophy is "the client has to ask for any work it wants the server to do", so default to not providing totals - but I'm open to discussion.

Bron.


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


--_----------=_153161324637026980-- From nobody Sun Jul 15 11:18:38 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C7612F18C for ; Sun, 15 Jul 2018 11:18:36 -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=xpByoc5i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FNiIyeij 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 cYz--CUajg3A for ; Sun, 15 Jul 2018 11:18:33 -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 ED086128CF3 for ; Sun, 15 Jul 2018 11:18:32 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4BCBE21175 for ; Sun, 15 Jul 2018 14:18:32 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 15 Jul 2018 14:18:32 -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=PgAr4tAhFHlDfHtUL cQ7rpdq6XmXEy4cLkAuf38AsiQ=; b=xpByoc5iX6MB+jWlq/SZIt2nCOso07uXU tibS1J9y8VvzhesZQjVJvMYxXPX1LTkTWtXCGkG17CwzdyHrGWaNk7IxOM9V78BQ wD4VPrW9vfiTCsLf6PRxabn8eXdtQfKwixzoqTwer0/AfblnSL7rQ808Q1Z9T1vm mmZksRLbPsh1A7GYW7Yt5sBAzfkP7e1UfZ0e7bJ35FLTK9d7NL7IoycpCg5vxKqt SsYsbnkiAX04p4Yq4nKrWmvUVZou+YvBvZ5cDiXvxLGM4RGke5FytBYpunBb8aKA s0aDYcO6Cu7VBLZHAcOQzkZYK4odnitRhn0qWnv5g4Q5AA7oXuubQ== 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=PgAr4t AhFHlDfHtULcQ7rpdq6XmXEy4cLkAuf38AsiQ=; b=FNiIyeijdRBL99NZ4zOSN8 wee8cREK2v2qgODyEQ2ZxYpH5UwQAUHSkIlsvmlbcJCT1KxTaMv+b2VmmooA84PN Jv3uc1OmodMAHy4sapW+P2aIMSkcYRmnkFPEw+YUWnQ/fGDvsVz93ZTe3AqiyyLA yoWyuAbpD0L1Sy8yh5vYZByPFVCTX2nWVzjizBl9LPyg5RyGdtLTfTqez6P7X2+i acmnP40iyS0/b2kUeGZQkxVwr5uFoTjelra/Dcz/x4EOobgXDPbTatF/27u3BJMr uAGoyPKvnvCdGx+cKtiOe4072ZZ5GDnaZ7/0CgMozH7Y0CP9bUGChkTnyN98g1Kg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C4A3A9E0F5; Sun, 15 Jul 2018 14:18:31 -0400 (EDT) Message-Id: <1531678711.818045.1441445200.34ADEC07@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15316787118180452" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Mon, 16 Jul 2018 04:18:31 +1000 In-Reply-To: <1531613246.3702698.1440951808.15A2F066@webmail.messagingengine.com> References: <1531613246.3702698.1440951808.15A2F066@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Making clients explicitly request totals. X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 18:18:36 -0000 This is a multi-part message in MIME format. --_----------=_15316787118180452 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" You've got less than a day to reply to this if you aren't going to be at Montreal and you want your comments mentioned during the session :) Cheers, Bron. On Sun, Jul 15, 2018, at 10:07, Bron Gondwana wrote: > (individual contributor hat) > > One of the design properties we discussed right back at the start of > the JMAP effort was "don't make the server do any implicit work that > the client doesn't need".> > A place in which we may not be meeting that well is the "total" field > in /query and /queryChanges responses. In some cases, the server may > have a complete total, but in other cases it might be significant > work, particularly if it has to be a 100% accurate total. Likewise > getting a perfect sort may sometimes be hard work, particularly if > doing a "relevance" sort or similarly fuzzy thing. Or if there's > duplicate suppression or thread collapsing happening.> > So... I'd like to float the idea of having a calculateTotal: true > property on /query and /queryChanges, allowing a client to make a > request like "give me the first 30 items" without a total, and the > server can reply with either canCalculateChanges: false, or with a > token that allows it to know which 30 items it previously returned, > such that a request for the next page will get the right data.> > Think of something like Hacker News or Reddit, where you're getting > the "first page" of items, and a token that allows you to get a next > page later, until that token goes stale a few hours later.> > An alternative to having the client explicitly request totals is > having the client explicitly request a loosening of the requirement - > that's a philosophical question. My preferred philosophy is "the > client has to ask for any work it wants the server to do", so default > to not providing totals - but I'm open to discussion.> > Bron. > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15316787118180452 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
You've got less than a day to reply to this if you aren't going to be at Montreal and you want your comments mentioned during the session :)

Cheers,

Bron.


On Sun, Jul 15, 2018, at 10:07, Bron Gondwana wrote:
(individual contributor hat)

One of the design properties we discussed right back at the start of the JMAP effort was "don't make the server do any implicit work that the client doesn't need". 

A place in which we may not be meeting that well is the "total" field in /query and /queryChanges responses.  In some cases, the server may have a complete total, but in other cases it might be significant work, particularly if it has to be a 100% accurate total.  Likewise getting a perfect sort may sometimes be hard work, particularly if doing a "relevance" sort or similarly fuzzy thing.  Or if there's duplicate suppression or thread collapsing happening.

So... I'd like to float the idea of having a calculateTotal: true property on /query and /queryChanges, allowing a client to make a request like "give me the first 30 items" without a total, and the server can reply with either canCalculateChanges: false, or with a token that allows it to know which 30 items it previously returned, such that a request for the next page will get the right data.

Think of something like Hacker News or Reddit, where you're getting the "first page" of items, and a token that allows you to get a next page later, until that token goes stale a few hours later.

An alternative to having the client explicitly request totals is having the client explicitly request a loosening of the requirement - that's a philosophical question.  My preferred philosophy is "the client has to ask for any work it wants the server to do", so default to not providing totals - but I'm open to discussion.

Bron.


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


_______________________________________________
Jmap mailing list

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


--_----------=_15316787118180452-- From nobody Sun Jul 15 23:47:21 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 B761A12F1AB for ; Sun, 15 Jul 2018 23:47: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=tvZKAggf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XaV2/+dq 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 CKKn7j2X3MFv for ; Sun, 15 Jul 2018 23:47:18 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418C812777C for ; Sun, 15 Jul 2018 23:47:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 05CC21B1 for ; Mon, 16 Jul 2018 02:47:16 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 02:47: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=4aOhDEMWsp4gkCIuCBnXeq1RxJJpxpSf3SMDL8Iqp dc=; b=tvZKAggfzxAZpWqmMOrGuJGGGupZ2KAB4VX6PutxViQpwVT7sLIMEg54W VP0p4F5ZlQuZUqirCXFhhUyur2rzWOrnzoTEwC2jRjk6eFQtsAVGRulMHo5EoiP+ +DBchwuk18YPkKo0/cRpGfutZFEAKPLAd9NM7F376TSgDaLkLv2RHOigJT/+/wM3 RmB3WAG1MNp+vxBmef1i7OumEKaiDNDlxrFiyd4eUtNcrflXSq0VDs8n4zCWC+GS g3RfJR2HHZdCQ+tHupC7SgJPmQ7ghvhMFzo5gzb2mguhxJI77o5GxX0+Ip2S0TZF 1eoSd3S2HeDJkeRgxxwzcFxnrmmJQ== 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=4aOhDEMWsp4gkCIuCBnXeq1RxJJpxpSf3SMDL8Iqp dc=; b=XaV2/+dqxPKXpJ3Kla1yPBPsGUXVcW21f8SPqUPIKRQbBP4VJH5bGlMIL 7h5MERI68KErcf0AR3kd/CROAbuVnfLY9GV1GZnG0YLWXzOyfLAEf89X1f/yx+6y mlGwRt0Z/61uGyzfSID73MyntzdAErQRwPa/RkX6tnsHDUCRx2+8uD+sS6KMFgmg teKqgjqr8xIO0QsxkCaFo18cMAinjIDwVqVa7ty7kdRPqwMo2BJhxHgIZdRN0e41 Ag6dhujH8HbLL/1Lwo95+ofYcMClblsEAvTHw7HNeCvruSHh8tNc+f0nyKGi3Q56 MomQthMmtVR7dnxLstQZS/lizC82A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 42BC5F114; Mon, 16 Jul 2018 02:47:16 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.4-437-gcc1b3ff-fmnext-20180712v2 x-jmap-identity-id: 64588216 In-Reply-To: <1531678711.818045.1441445200.34ADEC07@webmail.messagingengine.com> References: <1531613246.3702698.1440951808.15A2F066@webmail.messagingengine.com> <1531678711.818045.1441445200.34ADEC07@webmail.messagingengine.com> Date: Mon, 16 Jul 2018 02:47:15 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=78af42d4550f40dbafe9e652f6d14540 Archived-At: Subject: Re: [Jmap] Making clients explicitly request totals. X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 06:47:20 -0000 --78af42d4550f40dbafe9e652f6d14540 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I think th= is is reasonable, presuming it can allow significant performance wins wh= en the client doesn't need the total. As long as the client can get the = total when it needs it. I would imagine it would work something like thi= s:
  • If fast to compute (i.e. cached) the server always r= eturns the total in the query or queryChanges response (this avoids the = client making a future request for it when it was super cheap to return = with the initial request anyway).
  • Otherwise, the total is re= turned as `null` unless specifically requested by a calculat= eTotal: true argument to the methods.

Likewise ge= tting a perfect sort may sometimes be hard work, particularly if doing a= "relevance" sort or similarly fuzzy thing.  Or if there's duplicat= e suppression or thread collapsing happening.

I'm unclear exactly what you're referring to here, or ho= w it's relevant to the proposal. Thread collapsing happens after= sorting.  The proposal does allow you to avoid a lot of the wo= rk of collapsing if just requesting the first X results. But it doesn't = let you avoid sorting, as you need this to determine which results are t= he first X.

the server can reply with either canCalculate= Changes: false, or with a token that allows it to know which 30 items it= previously returned, such that a request for the next page will get the= right data.

Think of something like Hacker News or Reddi= t, where you're getting the "first page" of items, and a token that allo= ws you to get a next page later, until that token goes stale a few hours= later.

Are you proposing some= thing different to the existing queryState string and changes mechanism?= If so, what and why? It seems to me this should "just work" without any= changes to the spec (other than requiring explicit opt-in from the clie= nt to force /queryChanges to return the exact total, as with /query)?

Neil.
--78af42d4550f40dbafe9e652f6d14540 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable I think this is reasonable, presuming it can allow significant performan= ce wins when the client doesn't need the total. As long as the client ca= n get the total when it needs it. I would imagine it would work somethin= g like this: * If fast to compute (i.e. cached) the server always returns the total = in the query or queryChanges response (this avoids the client making a f= uture request for it when it was super cheap to return with the initial = request anyway). * Otherwise, the total is returned as `null` unless specifically reques= ted by a calculateTotal: true argument to the methods. > Likewise getting a perfect sort may sometimes be hard work, particular= ly if doing a "relevance" sort or similarly fuzzy thing.=C2=A0 Or if the= re's duplicate suppression or thread collapsing happening. I'm unclear exactly what you're referring to here, or how it's relevant = to the proposal. Thread collapsing happens=C2=A0*after* sorting.=C2=A0 T= he proposal does allow you to avoid a lot of the work of collapsing if j= ust requesting the first X results. But it doesn't let you avoid sorting= , as you need this to determine which results are the *first* X. > the server can reply with either canCalculateChanges: false, or with a= token that allows it to know which 30 items it previously returned, suc= h that a request for the next page will get the right data. >=20 > Think of something like Hacker News or Reddit, where you're getting th= e "first page" of items, and a token that allows you to get a next page = later, until that token goes stale a few hours later. Are you proposing something different to the existing queryState string = and changes mechanism? If so, what and why? It seems to me this should "= just work" without any changes to the spec (other than requiring explici= t opt-in from the client to force /queryChanges to return the exact tota= l, as with /query)? Neil. --78af42d4550f40dbafe9e652f6d14540-- From nobody Mon Jul 16 00:40: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 01330130DD4 for ; Mon, 16 Jul 2018 00:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCx_jRTlXnqQ for ; Mon, 16 Jul 2018 00:39:57 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71301294D7 for ; Mon, 16 Jul 2018 00:39:57 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 39532C0039; Mon, 16 Jul 2018 08:40:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1531726803; bh=XoicIktHxNVqXxsxMyN6V+TfDLGzEcYYTqZH/RESgA8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=e7Pb2v7F3MHHi68Pe97aF96qqOQsYRNu8dfJKc/4SQdUOQoFgXVQafT+dff8wY0d2 tiWQn6Wf0dIi/AdvdRW/nQB3oLUggGSe0mwXT18zSq9ieVYN1Ibg9EsUuK4CM2hvDg NQ016S2Tl7C5EYt8a05FNpsd6U38AsOBeFaasSmI= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1531726802-23986-23983/9/37; Mon, 16 Jul 2018 07:40:02 +0000 From: Arnt Gulbrandsen To: IETF JMAP Mailing List Date: Mon, 16 Jul 2018 09:39:54 +0200 Mime-Version: 1.0 Message-Id: <207a75dd-f6f2-48b0-bc74-fa10898eb70d@gulbrandsen.priv.no> In-Reply-To: References: <1531613246.3702698.1440951808.15A2F066@webmail.messagingengine.com> <1531678711.818045.1441445200.34ADEC07@webmail.messagingengine.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Making clients explicitly request totals. X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 07:40:00 -0000 Please: Fewer cases to test. "Do it if cheap" and such add complexity, and I don't see that justified. IMAP should have taught us all the value of having grokkable server behaviour. Aside from that, I don't see any justification for having total be a special case. Deviating from the protocol's general principles is fine whenever there's a reason to, I don't see a reason to deviate for totals. "It may require few CPU cycles" is an opportunity, not a reason. Arnt From nobody Mon Jul 16 01:37:19 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 2C7AC1294D7 for ; Mon, 16 Jul 2018 01:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O76izbQG-IW3 for ; Mon, 16 Jul 2018 01:37:14 -0700 (PDT) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 525D5130EBC for ; Mon, 16 Jul 2018 01:37:14 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id g2-v6so2389906pgs.6 for ; Mon, 16 Jul 2018 01:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DewMoItBeJ8cLVbya8SkzXXkYVuFHt0XC9bRis6nmVQ=; b=zzKC4ZsDlLK0LeEITcxxNIMdawuGKuPS4VtawpA03ATmi9Acixr63NLSxDwZVaqvKb TtnSohJAFzs07TVjqRJ7xRCyG7BrAgpVTu3L+3Wo4U7ioOC8W+mXIthxRvoQ54KouI5C HKFjPIXjJq8GYVa6cj6nR8hEm+Uf/cyCqcQqlz4yRbO69NBToAnn/ZExdqPPa4iOZMNJ LqOmZlFLw6x/ddWNOInUAKd401fMvmdCqPU24b0cXEXJ3HJRxcmrk5ZLjFn9JkRUW4sz jkExzOavs7SbdLWtwsB66abFZYgR+4Icd4Yfyf5YQNuzQrIAJk3E87fp+OyT50Ztmxu3 lsug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DewMoItBeJ8cLVbya8SkzXXkYVuFHt0XC9bRis6nmVQ=; b=ag64xOz69TbjiSssKxoqoex4lH7x3iZpdTZzqUeUAlwlXxYZX5oHKf0fdEhAoosAXi 9Y5+rQnY857bv7wIf33fA2G70GvIfAj0fjWbeuJyhlf8ZjhCx0p02e+hxoJ9xP8jh0tD hjoHM3WKXSOOzoCZXGXyenzFlrffh9bnCLZnOBFqeGLq4s1yWhUHK2dSFp/qukjA1wPT KlEkssZwpcD5qwd2Js1so+LoiyDvg1NSgFNoMU+y49V/fINsdvPf44b6Ovh/VgFBc5R6 UPmdGzah05RK8q/A+IdEbwx0/9eASwi11gmY3JPsixCSs+pJ8+aHWsovJngPxG+WjPU0 e3Fg== X-Gm-Message-State: AOUpUlEAOUAEa0RTppBhcOYbevjo3cHLMjo+23uAkOcmaM/9Rkwt1KRB havbWPw5co6TM2bWhvs2q6MBHw1H65Y= X-Google-Smtp-Source: AAOMgpfJSmP4x+bgmpHfknJaMu9v7fV6ePtfs3RKwlM8kS3p0UIFJcKY/0I3W04K0CXifshSzhGzuQ== X-Received: by 2002:a65:66d7:: with SMTP id c23-v6mr14805140pgw.427.1531730233675; Mon, 16 Jul 2018 01:37:13 -0700 (PDT) Received: from ?IPv6:2601:646:8800:790:5402:81ec:944a:eac7? ([2601:646:8800:790:5402:81ec:944a:eac7]) by smtp.gmail.com with ESMTPSA id t186-v6sm20281789pgd.77.2018.07.16.01.37.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jul 2018 01:37:12 -0700 (PDT) From: Neil Jhaveri Message-Id: <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CE36F625-38AA-4820-B394-37FBA2AA2517" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 16 Jul 2018 01:37:11 -0700 In-Reply-To: <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 08:37:18 -0000 --Apple-Mail=_CE36F625-38AA-4820-B394-37FBA2AA2517 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for taking the review feedback, and sorry I didn=E2=80=99t get = around to replying to this sooner! > On Jun 8, 2018, at 11:45 PM, Neil Jenkins = wrote: >=20 > 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 = reference it and avoid repeating the same 4 conventions? Something like = "Type signatures are given for all JSON objects in this document. The = conventions follow those in Section 1 of [RFC XXXX]=E2=80=9D. >=20 > Sure, sounds reasonable. I'll do that. >=20 >>> 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 = 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. >=20 > For compatibility with IMAP it needs to be a MUST =E2=80=93 so yes, = I'll change it. >=20 >> The current definition of EmailAddress object doesn=E2=80=99t seem = sufficient to cover an RFC 5322 Group Address? e.g.: >>> To: A Group:Ed Jones ,joe@where.test,John ; >=20 > The current mapping would be: >=20 > [ > { "name": "A Group", email: null }, > { "name": "Ed Jones", email: "c@a.test" }, > { "name": "John", email: "jdoe@one.test" } > ] >=20 > This gives the group name, but doesn't give the position of the end of = the group. I believe the thinking was groups are normally used for the = whole set, so the end wasn't important. However, we could add an end = marker (name=3Dnull and email=3Dnull?) >=20 > I would really prefer this stayed a flat list rather than a = hierarchical structure though (and remember you are not allowed to have = nested groups). >=20 > Thoughts? I agree with trying to preserve a flat last as a good goal. What about an optional property =E2=80=9CgroupName=E2=80=9D? [ {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jhaveri=E2=80=9D, email: = =E2=80=9Cneil@neiljhaveri.com =E2=80=9D, = groupName: =E2=80=9CThe Neils=E2=80=9D}, {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jenkins=E2=80=9D, email: = =E2=80=9Cneilj@fastmailteam.com =E2=80=9D, = groupName: =E2=80=9CThe Neils=E2=80=9D}, {=E2=80=9Cname=E2=80=9D: =E2=80=9CAnother Person=E2=80=9D, email: = =E2=80=9Canother@person.com =E2=80=9D} ] This assumes that you don=E2=80=99t have two sequential but different = groups with the same name, which I think is legal in RFC 5322 syntax. If = that=E2=80=99s important, we could include yet another optional = groupIndex property to cover that case (or, a Group property itself = having name & index(optional) properties). I lean towards adding the = complexity up-front to cover legal syntax. Thoughts? >=20 >>> 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_ = form... >> It looks to me like the indentation 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*. >=20 > Yeh, I got the markdown indentation wrong. Will fix. >=20 >>> 4.1.2. Header fields =20 >>> ... >>> In addition, the client may request/send properties representing = individual header fields of the form: >>>=20 >>> 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.=20 >> I am not really sure what the conventions are... would this be better = expressed with ABNF, or is this textual explanation sufficient? >=20 > 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. >=20 >> When I first read this, I was a little confused by the text = =E2=80=9Cincluding 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 confusing, maybe it could be clarified into something like = this: >>> This is the full MIME structure of the message body, represented as = an 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. >=20 > Sounds good, will do. >=20 >>> o *bodyValues*: "String[*BodyValue*]" (immutable) This is a map = of... >> Should this be EmailBodyValue instead of BodyValue? >=20 > Yes, will fix. >=20 >> 4.1.3. Body parts >>> ... >>> MIME structures are arbitrary nested trees of documents, but the = majority of email clients present 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 confusing to me, = and felt like the properties were being re-defined. I think it might be = worthwhile considering an edit where the high-level explanation 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 that it = reads a bit more linearly and each property definition is a bit more = self-contained. Thoughts? >=20 > Yes, I think it needs to be moved to the very top of the Email = description, providing a non-normative overview of the structure before = the actual specification. I'll do this. >=20 >> 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? >=20 > 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"). >=20 >>> 4.2. Email/get >>> =E2=80=A6 >>> The following properties are expected to be fast to fetch in a = quality implementation: >> Resent-XX are commonly shown by=20 >=20 > =E2=80=A6 by what?! And importantly, are they commonly shown in the = mailbox listing or when you open the message (because the latter will be = fetched with the body so doesn't have to be fast)? Oops, I meant to delete that comment :), hence it being unfinished. I = don=E2=80=99t know of any clients that show it in the message list, its = generally shown along with the message body. >=20 >>> 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 within an account. In this case, it MUST reject attempts to = import an email considered a duplicate with an "alreadyExists" SetError. = =20 >> 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 have seen the global-uniqueness requirement violated by naively = written scripts.=20 >=20 > 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 needs to be compatible as much as possible with existing systems. I see. Yeah, Gmail does require unique Message-IDs =E2=80=94 at least on = append, they are dropped, even if the content is different. This is = fine, then. >=20 >>> 5. Email Submission >>> =E2=80=A6 >>> o *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?=20 >=20 > I think I'll just reorder it so the Identity section comes before = EmailSubmission. That should read better. >=20 >>> 5. Email Submission >>> * *mailFrom*: The email in the _Sender_ header, if present, = otherwise the _From_ header, if present, and no parameters. If multiple = addresses are present in one of these headers, or there is more 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. *If the address 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 = the identity address, I'd prefer returning a "forbiddenFrom=E2=80=9D = error and give the user a chance to correct their mistake. Thoughts? >=20 > This is the RFC5321 SMTP envelope =46rom remember, not the RFC5322 = message From. This passage of spec is also only referring to what to do = when the client doesn't explicitly set an envelope. I think therefore = this passage is OK, but you raise a good point that we probably need a = separate error for a forbidden RFC5321 =46rom in the envelope. I'll add: >=20 > - `forbiddenMailFrom` =E2=80=93 The server does not permit the user to = send an email > with the [@!RFC5321] envelope From. >=20 > which is in addition to: >=20 > - `forbiddenFrom` =E2=80=93 The server does not permit the user to = send an email > with the [@!RFC5322] =46rom header of the email to be sent. Ah, right! Agreed. >=20 >>> 5. Email Submission >>> =E2=80=A6=20 >>> For emails relayed via an alternative to SMTP, the server = MAY >>> generate a synthetic string representing the status = instead. >>> If it does this, the string MUST be of the following form: >>>=20 >>> + A 3-digit SMTP reply code, as defined in [ >>> RFC5321], section >>> + Then an SMTP Enhanced Mail System Status Code as defined = in [RFC3463], with a registry defined in [RFC5248]. >>> + 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? >=20 > Again, happy to take advice from more experienced editors here. >=20 >>> 5.5 EmailSubmission/set >>> Standard _/set_ method, with the following two extra arguments: >>> o *onSuccessUpdateEmail*:... >> I think a lot of clients will want to move the message from Draft to = Sent using this block. It might be worth explicitly calling that out, or = even giving a full example. Thoughts? >=20 > Yes, that's exactly what it's for. I'll add an example. >=20 >>> 7. Search Snippets >>> =E2=80=A6 >>> o *attachments*: "String|null" If text from the filter matches = the text extracted from an attachment, this is the relevant section of = the attachment (converted to plain text), with matching words/phrases = wrapped in "" tags. It MUST NOT be bigger than 255 octets = in size. If it does not match, this is "null". >> 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?=20 >=20 > 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 if the server doesn't know which part had the match? Yeah, I was thinking a map of partId to matching section, too. But if = that mapping is worrisome for a server implementor, perhaps representing = it as an array of Attachment snippet objects, with snippet and partId = properties.=20 But now the more I think about it, rather than making it optional, maybe = this is just over-complicated and the way you had it is best for now. >=20 >>> 8. Vacation Response >>> The *VacationResponse* object represents 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: >> 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 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 information. >> 2. I also think that there may need to be some mention of loop = prevention =E2=80=94 so that two accounts with vacation responses = don=E2=80=99t continuously reply to each other.=20 >=20 > The spec here was not intended to provide a complete consideration of = everything that should be considered when building a vacation response = system (which is already covered in previous RFCs), merely a mechanism = by which it can be configured by the client. The functionality was = chosen as a common subset supported by most major systems, to make = adoption feasible. 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 question is whether being able to configure the = common subset from arbitrary 3rd party clients is useful or not? >=20 >> 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? >=20 > So, I agree the vacation response could be neatly separated into a = separate specification rather than part of the core mail. The main = reason to include it here is to make sure there is concrete extra = functionality that an existing IMAP client implementing JMAP would be = able to provide that it couldn't with just IMAP. This (sadly) can make = it an easier sell to management than just "it will make everything work = faster, more efficiently and more reliably than before". However, I'm = very interested to hear if you don't think this is likely to be so = useful a hook based on your previous employment experience. Neil & I chatted a bit off-list on this. At least in my experience, I = don=E2=80=99t think it will make a material difference in terms of being = able to sell it to management =E2=80=94 performance & responsiveness = tend to be important for mail clients in general, and I certainly spent = a lot of my team=E2=80=99s time at Apple on that. I still lean towards = separating this into an extension so that it can be made a little bit = more sophisticated. >=20 > Neil._______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail=_CE36F625-38AA-4820-B394-37FBA2AA2517 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for taking the review feedback, and sorry I didn=E2=80=99= t get around to replying to this sooner!

On Jun = 8, 2018, at 11:45 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:

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 reference it and avoid = repeating the same 4 conventions?  Something like "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 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 EmailAddress object doesn=E2=80=99t = seem sufficient to cover an RFC 5322 Group Address? e.g.:
To: A Group:Ed Jones = <c@a.test>,joe@where.test,John <jdoe@one.test>;

The current mapping = would be:

[
    = { "name": "A Group", email: null },
    { = "name": "Ed Jones", email: "c@a.test" },
    { "name": = "John", email: "jdoe@one.test" }
]

This gives the group name, but doesn't give the position of = the end of the group. I believe the thinking was groups are normally = used for the whole set, so the end wasn't important. However, we could = add an end marker (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 groups).

Thoughts?

I = agree with trying to preserve a flat last as a good goal.

What about an optional property = =E2=80=9CgroupName=E2=80=9D?

[
  {=E2=80=9Cname=E2=80=9D: = =E2=80=9CNeil Jhaveri=E2=80=9D, email: =E2=80=9Cneil@neiljhaveri.com=E2=80=9D, groupName: =E2=80=9CThe = Neils=E2=80=9D},
  {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil = Jenkins=E2=80=9D, email: =E2=80=9Cneilj@fastmailteam.com=E2=80=9D, groupName: =E2=80=9CThe = Neils=E2=80=9D},
  {=E2=80=9Cname=E2=80=9D: =E2=80=9CAnothe= r Person=E2=80=9D, email: =E2=80=9Canother@person.com=E2=80=9D}
]

This assumes that you don=E2=80=99t have two = sequential but different groups with the same name, which I think is = legal in RFC 5322 syntax. If that=E2=80=99s important, we could include = yet another optional groupIndex property to cover that case (or, a Group = property itself having name & index(optional) properties). I lean = towards adding the complexity up-front to cover legal = syntax.

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_ form...
It looks to me like = the indentation 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:

            =             header:{header-field-name}

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. 
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=9Cincluding = 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 confusing, = maybe it could be clarified into something like this:
This is the full MIME = structure of the message body, represented as an 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?

Yes, = will fix.

4.1.3. Body parts
...
MIME structures are arbitrary nested trees = of documents, but the majority of email clients present 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 confusing to me, and felt like the properties were = being re-defined. I think it might be worthwhile considering an edit = where the high-level explanation 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 that it reads a bit more linearly and each = property definition is a bit more self-contained. Thoughts?

Yes, I think it needs to be moved = to the very top of the Email description, providing a non-normative = overview of the structure before the actual 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 gives you the full ordering. I'll do this (and name the = property just "attachments").

4.2. = Email/get
=E2=80=A6
   The = following properties are expected to be fast to fetch in a quality = implementation:
Resent-XX are commonly shown = by 

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

Oops, I = meant to delete that comment :), hence it being unfinished. I don=E2=80=99= t know of any clients that show it in the message list, its generally = shown along with the message body.


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 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 little bit restrictive to me =E2=80=94 it=E2=80=99= s author-generated, so I have seen the global-uniqueness requirement = violated by naively written scripts. 

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 needs to be compatible as much as possible with = existing systems.

I see. Yeah, Gmail does require unique Message-IDs = =E2=80=94 at least on append, they are dropped, even if the content is = different. This is fine, then.


5. Email Submission
=E2=80=A6
   o  *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? 

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

5. Email Submission
  *  *mailFrom*: = The email in the _Sender_ header, if present, otherwise the _From_ = header, if present, and no parameters.  If multiple addresses are = present in one of these headers, or there is more 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.  *If the address = 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 the 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 =46rom remember, not the = RFC5322 message From. This passage of spec is also only referring to = what to do when the client doesn't explicitly set an envelope. I think = therefore this passage is OK, but you raise a good point that we = probably need a separate error for a forbidden RFC5321 =46rom in the = envelope. I'll add:

- `forbiddenMailFrom` = =E2=80=93 The server does not permit the user to send an email
  with the [@!RFC5321] envelope From.

which is in addition to:

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

Ah, right! Agreed.


5. Email Submission
=E2=80=A6 
         For emails relayed via an = alternative to SMTP, the server MAY
      =    generate a synthetic string representing the status = instead.
         If it does = this, the string MUST be of the following form:

         +  A 3-digit SMTP = reply code, as defined in [
RFC5321], section
         +  Then an SMTP = Enhanced Mail System Status Code as defined in [RFC3463], with a = registry defined in [RFC5248].
        =  +  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 following two extra arguments:
   o =  *onSuccessUpdateEmail*:...
I think a = lot of clients will want to move the message from Draft to Sent using = this block. It might be worth explicitly calling that out, or even = 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 extracted from an attachment, this is = the relevant section of the attachment (converted to plain text), with = matching words/phrases wrapped in "<mark></mark>" tags. =  It MUST NOT be bigger than 255 octets in size.  If it does = not match, this is "null".
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? 

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 if = the server doesn't know which part had the match?

Yeah, = I was thinking a map of partId to matching section, too. But if that = mapping is worrisome for a server implementor, perhaps representing it = as an array of Attachment snippet objects, with snippet and partId = properties. 

But now the more I = think about it, rather than making it optional, maybe this is just = over-complicated and the way you had it is best for now.


8. Vacation Response
The = *VacationResponse* object represents 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:
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 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 information.
2. I also think that there may need to be some mention of = loop prevention =E2=80=94 so that two accounts with vacation responses = don=E2=80=99t continuously reply to each other. 

The spec here was not intended to = provide a complete consideration of everything that should be considered = when building a vacation response system (which is already covered in = previous RFCs), merely a mechanism by which it can be configured by the = client. The functionality was chosen as a common subset supported by = most major systems, to make adoption feasible. 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 question is whether = being able to configure the common subset from arbitrary 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 separate specification rather than part = of the core mail. The main reason to include it here is to make sure = there is concrete extra functionality that an existing IMAP client = implementing JMAP would be able to provide that it couldn't with just = IMAP. This (sadly) can make it an easier sell to management than just = "it will make everything work faster, more efficiently and more reliably = than before". However, I'm very interested to hear if you don't think = this is likely to be so useful a hook based on your previous employment = experience.

Neil & I chatted a bit off-list on this. At least = in my experience, I don=E2=80=99t think it will make a material = difference in terms of being able to sell it to management =E2=80=94 = performance & responsiveness tend to be important for mail clients = in general, and I certainly spent a lot of my team=E2=80=99s time at = Apple on that. I still lean towards separating this into an extension so = that it can be made a little bit more sophisticated.


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

= --Apple-Mail=_CE36F625-38AA-4820-B394-37FBA2AA2517-- From nobody Mon Jul 16 02:56:35 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1EF130FA2 for ; Mon, 16 Jul 2018 02:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 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_OBFUSCATE_05_10=0.26, 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=OP3tIRWl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XCGVuXA9 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 KHstLOFFCwA6 for ; Mon, 16 Jul 2018 02:56:32 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E393130F2C for ; Mon, 16 Jul 2018 02:56:32 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D6424230; Mon, 16 Jul 2018 05:56:30 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 05:56:31 -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=fm3; bh=JKpODuFQBYiOR+S9oIZf4qpzOOh8Yp0fEkvt5qSg9 WU=; b=OP3tIRWlHJ1eDBoPG/GOX6yXpnrM4LzUtIk/juIlMHlC4wVXlZvk3Kn+P Avr8gETCumzIBHLjfCKoqyfUJ2asJ6XMastMTbScK96Y6fCgj/4Mi3r2dQpPq9t4 YIivIM5uInlWxYDgoc8/pau4JIPldfm+SAWanX8K1sNx6uNNG+9pCxqdKrU0oczr WZVjr7HaY5z5xMMG2nH2jR3IT/6y8s5pbWoZwbbHYh40KnqG4bt+Amj1i0KS4CQ9 9Rf07YSWxmgbq6Fk1pEwY6fALQApm6SOc2EaONhaU2Er7DBpi16k802iPCb/0sIY 5jn3K/Dm57tl7alWWYDqBHZ9V9Qfg== 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=JKpODuFQBYiOR+S9oIZf4qpzOOh8Yp0fEkvt5qSg9 WU=; b=XCGVuXA91wOp0vtsNR1Sd60Z4TClJQjZc2Oc7DYVGYvA3IkimM69Spgkx +Vx5/v7HocSeoHlMZqOSqs95pU6/mHB+wn7NQ3N+/Zl10UIMB9iY48Fur6cHo9F0 gd5kWk2eOa+mChF/d6yQIjt19kWkZYmBwVMZHxauwqEcrRC/HLumwRGwMfRvA5hZ z87GpitJ1Pwv7HRE/DnR0ONbTEdLPVkHyGHMYQrFALw4G+/j14gGswRobWJc4wQl /m6MEs9hMIduD6xuxZb40y8oGyQ6UiaTFPxqEaks/uGGXtkNO3ELzuap0Y14d/Rm xASqHohxjHfRhwBPRtEYqDMWzUfSQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CEFAEF114; Mon, 16 Jul 2018 05:56:29 -0400 (EDT) Message-Id: <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.4-437-gcc1b3ff-fmnext-20180712v2 x-jmap-identity-id: 64588216 In-Reply-To: <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> Date: Mon, 16 Jul 2018 05:56:29 -0400 From: Neil Jenkins To: Neil Jhaveri Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=8e65456708aa484089f01d10b528d3fc Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 09:56:33 -0000 --8e65456708aa484089f01d10b528d3fc Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, 16 Jul = 2018, at 6:37 PM, Neil Jhaveri wrote:
What about an optional property =E2=80=9Cgr= oupName=E2=80=9D?

[
&nbs= p; {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jhaveri=E2=80=9D, email: =E2=80= =9Cneil@neiljhaveri.c= om=E2=80=9D, groupName: =E2=80=9CThe Neils=E2=80=9D},
=   {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jenkins=E2=80=9D, email: =E2= =80=9Cneilj@fastmai= lteam.com=E2=80=9D, groupName: =E2=80=9CThe Neils=E2=80=9D},
  {=E2=80=9Cname=E2=80=9D: =E2=80=9CAnother Person=E2=80=9D,= email: =E2=80=9Canothe= r@person.com=E2=80=9D}
]
<= div>
The main trouble with this is that the most common us= e of the group name is for something like this:

=
To: undisclosed-recipients:;

<= /div>
There are no mailboxes here, so there's nothing to add a group= Name property too. I think therefore there have to be start/end group ob= jects.

Neil.
--8e65456708aa484089f01d10b528d3fc Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 16 Jul 2018, at 6:37 PM, Neil Jhaveri wrote: > What about an optional property =E2=80=9CgroupName=E2=80=9D? >=20 > [ > =C2=A0 {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jhaveri=E2=80=9D, email:= =E2=80=9Cneil@neiljhaveri.com=E2=80=9D, groupName: =E2=80=9CThe Neils=E2= =80=9D}, > =C2=A0 {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jenkins=E2=80=9D, email:= =E2=80=9Cneilj@fastmailteam.com=E2=80=9D, groupName: =E2=80=9CThe Neils= =E2=80=9D}, > =C2=A0 {=E2=80=9Cname=E2=80=9D: =E2=80=9CAnother Person=E2=80=9D, emai= l: =E2=80=9Canother@person.com=E2=80=9D} > ] The main trouble with this is that the most common use of the group name= is for something like this: To: undisclosed-recipients:; There are no mailboxes here, so there's nothing to add a groupName prope= rty too. I think therefore there have to be start/end group objects. Neil. --8e65456708aa484089f01d10b528d3fc-- From nobody Mon Jul 16 03:14:54 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 432B7130FA5 for ; Mon, 16 Jul 2018 03:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viltTDdE08Ld for ; Mon, 16 Jul 2018 03:14:50 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BDD126F72 for ; Mon, 16 Jul 2018 03:14:50 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 50227C0030; Mon, 16 Jul 2018 11:14:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1531736096; bh=YIyCTHFllvO+owyIpdM/52uW2kHjzbiebDiUBbWDpSs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SRtTEZ44HmQkolC3IVBZS+QZJW+aryzSd5HO4MnT5HWc0ZhXrkaKJKLEd3ZinrIDN Yvi8GVHa8oKzgJjSuq5K5aJp9msCTdmnEVpZ5jsgqpKiPPkJhreS6mB1l8cXW7d0HG C5rjxvHVIbHuivg5qgzo/G1Ojqjl3evxB5biIFzc= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1531736095-23985-23983/9/23; Mon, 16 Jul 2018 10:14:55 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 16 Jul 2018 12:14:47 +0200 Mime-Version: 1.0 Message-Id: <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> In-Reply-To: <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 10:14:52 -0000 On Monday 16 July 2018 11:56:29 CEST, Neil Jenkins wrote: > There are no mailboxes here, so there's nothing to add a > groupName property too. I think therefore there have to be > start/end group objects. The problem with that is that it matches the RFC but not the modern world. In the modern world, only the example you show is common enough to be seen if you test with, say, 10000 messages random messages from the past years. Syntax that won't be tested is a trouble magnet. Here's a strawman alternative: 1. Empty groups are handled as a special kind of address. JMAP's EmailAddress is extended with an "unreplyable" element, and either "email" or "unreplyable" MUST be present, but never both. The latter is 1*CHAR if set. The server SHOULD specify an address as "email" if it's possible to send to that address, and MUST specify it as "unreplyable" if not. 2. Nonempty groups are handled by adding each address and suppressing the group name. 3. The test suite gets a message for each case. 4. Add "someone shows current use of nonempty groups" as a requirement for revisiting. Arnt From nobody Mon Jul 16 03:19: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 4E9A2130FA5 for ; Mon, 16 Jul 2018 03:19:00 -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=yIAmuTF/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jrT/6lrw 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 5CKXcgg6lJ02 for ; Mon, 16 Jul 2018 03:18:58 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B40130E11 for ; Mon, 16 Jul 2018 03:18:58 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 21FDA245 for ; Mon, 16 Jul 2018 06:18:58 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 06:18: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=wLLMAXp1AUHX8TxApLC/JitXunkp+IaxalGLTFcAY M0=; b=yIAmuTF/+l0/0uoCUeD6jGRWRKS03oJbcsEObWk2ElFRvjEEvJVnlF24T hWu44P4yf2UioyFXeRhK8o8j9Y3tOcTD1ajOevMTmb7kGj+wKrFMusc0spMDuf4Y fbSfriZvKl7T/x7q/cXSj3DnXGvzAL/0JLM16xBRLz2PshSJ9Uqp0Ho6WUQsjggi oVolNMd/CezbEzU7VFBkVUqge2XQ6AqnU1+Ccr2y1HMj/KiQziW97PMuJQruA/dW XUa0GxvUkevAwIXTq0NX1GBcyTisVoF+8eCYG/DOsg4K2rANclwumNViy4LGYm+S NNQVzip0hFqeh6JxXNCONyLAq+icQ== 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=wLLMAXp1AUHX8TxApLC/JitXunkp+IaxalGLTFcAY M0=; b=jrT/6lrwDAr6W5csl0/9PrsDqXbVrYzobv9H8A2crx5+PkvyohSeQh1sW xZj5XB4wA4Zn6KPUdxxvs9J81YSshjoKYDPLD5mSEbnRG2Iw7v8HJS3BDCxJZ4zo rYB30dqRw2Eryc4Tm/Rvv5eS2LhoW4QcqpIHtO6XmHxxWeni9uszkb/l2wF2Qcpg 1mzoxHpgchrSe+oPtMoliIK532mSHqNvnNqMM7E/nOF6YDCNFd7n9r7E3hBtt+DL BVWhld43iCuafF905wCaHqzRFjPVG87QcjeMmJXsOcpTYS89esraeJAZMbroNItA T0iCLROPjnlyV3tPJ7OkiQGQIW46g== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4C42BF114; Mon, 16 Jul 2018 06:18:57 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.4-437-gcc1b3ff-fmnext-20180712v2 x-jmap-identity-id: 64588216 In-Reply-To: <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> Date: Mon, 16 Jul 2018 06:18:56 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=303316197cb0472b94afd623a4842bd3 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 10:19:00 -0000 --303316197cb0472b94afd623a4842bd3 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, 16 Jul = 2018, at 8:14 PM, Arnt Gulbrandsen wrote:
The problem with that is that it matche= s the RFC but not the modern world.
In the modern world, o= nly the example you show is common enough to be seen
if yo= u test with, say, 10000 messages random messages from the past years.

I agree, which is why the origin= al spec had an object for the start of the group (name=3Dgroup name; ema= il=3Dnull), but nothing for the end of the group=E2=80=94because if it's= empty and there are no other addresses (the 99.9% case) it's obvious, a= nd even if there are other addresses, probably you still don't re= ally care where the end of the group is.

I'= d be happy to go back to this if there's general consensus that the end = of the group is not important in the real world.

Neil.
--303316197cb0472b94afd623a4842bd3 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 16 Jul 2018, at 8:14 PM, Arnt Gulbrandsen wrote: > The problem with that is that it matches the RFC but not the modern wo= rld. > In the modern world, only the example you show is common enough to be = seen > if you test with, say, 10000 messages random messages from the past ye= ars. I agree, which is why the original spec had an object for the start of t= he group (name=3Dgroup name; email=3Dnull), but nothing for the end of t= he group=E2=80=94because if it's empty and there are no other addresses = (the 99.9% case) it's obvious, and even if there *are* other addresses, = probably you still don't really care where the end of the group is. I'd be happy to go back to this if there's general consensus that the en= d of the group is not important in the real world. Neil. --303316197cb0472b94afd623a4842bd3-- From nobody Mon Jul 16 03:33:32 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 4D744130FC1 for ; Mon, 16 Jul 2018 03:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLG6xh4FbjX0 for ; Mon, 16 Jul 2018 03:33:28 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6499130DDB for ; Mon, 16 Jul 2018 03:33:28 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 572BAC0030; Mon, 16 Jul 2018 11:33:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1531737214; bh=Y4RUELu4o8khPv+ocCwYfjBWxwFkKPe4dqWE+qU8VBQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pRefA8t/1lXUPkeXn6ggB+X/EbR+1TfV7lNa+VI5M5pgBvyhgADktKgtVR8krdlSM 6DI68lrXPeoLyAVq5FNBVu3kS8YIe0p7Bl7Q/a4t/0VFl3Zveo8gFR7MoMrJVMdVX5 inEDwWyyUfIwmu/FjUo1sEevfzzypMjKNXOPlC88= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1531737213-23985-23983/9/24; Mon, 16 Jul 2018 10:33:33 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 16 Jul 2018 12:33:25 +0200 Mime-Version: 1.0 Message-Id: <8f13de2f-1424-4ca7-9aac-c338f3c6065c@gulbrandsen.priv.no> In-Reply-To: References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 10:33:30 -0000 On Monday 16 July 2018 12:18:56 CEST, Neil Jenkins wrote: > I'd be happy to go back to this if there's general consensus > that the end of the group is not important in the real world. I feel pedantic today. I seem to have grown less pedantic over the years, but this morning I'm young again. The JMAP core RFC ought to either say "JMAP explicitly only targets singlepart messages and MIME messages" and then questions such as about nonempty groups become irrelevant. Or it ought to say that e.g. 20-30 year old archived mail is explicitly in-scope, in which case someone should go and find some old cruft to test, such that it can be specified based on actual testing. Uuencoded attachments, undeclared 8-bit in different charsets (.no used three at the time), nonempty groups, whatever other cruft that was common once and died out 15-20 years ago. Supporting one kind of cruft and not even testing enough to enumerate the other kinds would be doubleplusungood. Arnt From nobody Mon Jul 16 03:56: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 9E493131041 for ; Mon, 16 Jul 2018 03:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FORGED_MUA_EUDORA=0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=rdlab.org 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 TqLr_SEXiW2M for ; Mon, 16 Jul 2018 03:56:30 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (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 51A8313103B for ; Mon, 16 Jul 2018 03:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rdlab.org; s=default; h=Content-Type:Mime-Version:References:In-Reply-To:Subject:From: To:Date:Sender:Reply-To:Message-ID:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=rVlva6mBTFj8hMQ34xJjywA9m857B2P32lxdiaDvbwY=; b=q/TRbHwUGqljYqNbVTFqWvXUVP 2SzqVlSwBjYwewoF6Le0DlSngj8c5u3huwd0LCWQdz84Ildt5B6YBfn9u0/QvTPNJD9v8tFBHYOkP dvirHsOcgkmdtFTPPefUw9p/S4TJEE/ysOtWWzSt5CtbsqO2k/XevMzGeippagPaS+kaOy3n5Pbp0 UgavNl9xo9PF9z9zuB4QuiO3m0UQsPmIccJqxiMEsUwKkFnt8k9KPbbELY5uWrJUYZrugx+fSrOgG dfA5S8m7F0BLTkeaw7Yi1N/FpB1M3Ng6tj3QS++Nfqd3BoINd03pQDiN8rf2oD9HxZQKYAhTgSmwx W76hGAwQ==; Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:21307 helo=Morfin-Morfin.rdlab.org) by host.presenceweb.org with esmtpa (Exim 4.91) (envelope-from ) id 1ff1B5-0004JY-0Y; Mon, 16 Jul 2018 12:56:27 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Jul 2018 12:49:17 +0200 To: Arnt Gulbrandsen ,jmap@ietf.org From: JFCM In-Reply-To: <8f13de2f-1424-4ca7-9aac-c338f3c6065c@gulbrandsen.priv.no> References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> <8f13de2f-1424-4ca7-9aac-c338f3c6065c@gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - rdlab.org X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: info+rdlab.org/only user confirmed/virtual account not confirmed X-Authenticated-Sender: host.presenceweb.org: info@rdlab.org X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20180716105630.51A8313103B@ietfa.amsl.com> Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 10:56:41 -0000 At 12:33 16/07/2018, Arnt Gulbrandsen wrote: >Or it ought to say that e.g. 20-30 year old archived mail is >explicitly in-scope, Amen ++ jefsey > in which case someone should go and find some old cruft to test, > such that it can be specified based on actual testing. Uuencoded > attachments, undeclared 8-bit in different charsets (.no used three > at the time), nonempty groups, whatever other cruft that was common > once and died out 15-20 years ago. Supporting one kind of cruft and > not even testing enough to enumerate the other kinds would be doubleplusungood. > >Arnt > >_______________________________________________ >Jmap mailing list >Jmap@ietf.org >https://www.ietf.org/mailman/listinfo/jmap From nobody Mon Jul 16 04:09: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 E880B130E50 for ; Mon, 16 Jul 2018 04:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=ke+UzB0x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qYAC91Z1 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 pm2tkhDLoVoS for ; Mon, 16 Jul 2018 04:08:59 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764EE130E2D for ; Mon, 16 Jul 2018 04:08:59 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C84181E8 for ; Mon, 16 Jul 2018 07:08:58 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute7.internal (MEProxy); Mon, 16 Jul 2018 07:08:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=NJc6GtG9PGRp7IJYQpclTUb+P59rH uMG6wIBkbhQjek=; b=ke+UzB0xJUofFM1O7WMpBMxtYEHbi0whVDEQcEO1vLyGu KT/CNAUqLA0yaMEzdJGGPuxigI0u96axuIMzAV6iTzHnZNNYeGQovqR5P5SzCtlH tulovblSOF/PrlxD/fj9nriqUF/8yyioi5WfkrwmIBJlhgZg9EdpjYfrOhn5wJ5T lJMqb63iQYunACHOL6naxSz79A43Xw4OoPGxzarFipeCHrdW0TySVzWZN9vbo4zb zuJyZZ7f+7nGIsT+ML1qpwR4dx3NTKYKN+2GV6JaicdCYZDyv8adhR/XqH06ZGMR rhKwiSq6vQpY1KLBe8+CL+sNBw21z6+xgGHS242RA== 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=NJc6Gt G9PGRp7IJYQpclTUb+P59rHuMG6wIBkbhQjek=; b=qYAC91Z1jpm8rs3cpt+fzb nKf7mtcj+rdwjD/JnFvDHv8M4TpecVJXKgSy2ayod6ZYzFN2DeZZofUei9hOxCue K/TGVta97TpQdO+Kcan/qkqqBc5CmLHcijHmYRO+E6WU4fYM0xsmu0ihpyeWxd5l CplDulsJup/V1CGRzhhVk8SMV59lfr0PouBFgVAXQ83hGOp4RpjXhQPa+FODJeVV eNjNkECwTQhX1pk1q1WYwqXUENKuD4zHPWIP6UdN6Reuv6XLi2jv+F7930hSDuAJ JonzjxHeLkFhNKh4Q8zjXK5HYNJF7of7CEx7qM1I7qGlEyQqHNA+/XfH7eHW0Eqg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3D4CF94133; Mon, 16 Jul 2018 07:08:58 -0400 (EDT) Message-Id: <1531739338.3801584.1442104952.05DFC1D5@webmail.messagingengine.com> From: Robert Mueller To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153173933838015840" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> Date: Mon, 16 Jul 2018 21:08:58 +1000 In-Reply-To: Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 11:09:01 -0000 This is a multi-part message in MIME format. --_----------=_153173933838015840 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > I agree, which is why the original spec had an object for the start of > the group (name=3Dgroup name; email=3Dnull), but nothing for the end of > the group=E2=80=94because if it's empty and there are no other addresses = (the > 99.9% case) it's obvious, and even if there *are* other addresses, > probably you still don't really care where the end of the group is.>=20 > I'd be happy to go back to this if there's general consensus that the > end of the group is not important in the real world. I'd prefer not to end up in a case where you can't represent real world data accurately as defined by the latest email RFC spec! I think you should just follow similar to the IMAP RFC. [RFC-2822] group syntax is indicated by a special form of address structure in which the host name field is NIL. If the mailbox name field is also NIL, this is an end of group marker (semi-colon in RFC 822[1] syntax). If the mailbox name field is non-NIL, this is a start of group marker, and the mailbox name field holds the group name phrase. Yeah well, IMAP splits out mailbox name and hostname, so we can't quite use that, but I think having a null email address to mean "start of group" and null email address and null name to mean "end of group" is fairly close to IMAP (so it's historically understandable to email client authors), and also should be reasonably straightforward for email server writers to implement (I believe cyrus does it already, because it only has to slightly tweak the existing IMAP envelope data). Rob Mueller robm@fastmail.fm Links: 1. https://tools.ietf.org/html/rfc822 --_----------=_153173933838015840 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I agree, which is why the original spec had = an object for the start of the group (name=3Dgroup name; email=3Dnull), but= nothing for the end of the group=E2=80=94because if it's empty and there a= re no other addresses (the 99.9% case) it's obvious, and even if there a= re other addresses, probably you still don't really care where the end = of the group is.

I'd be happy to go back to this if there's general consensus that the = end of the group is not important in the real world.

I'd prefer not to end up in a case where = you can't represent real world data accurately as defined by the latest ema= il RFC spec!

I think you should just follow similar to= the IMAP RFC.

         [RFC-2822] g=
roup syntax is indicated by a special form of
         address structure in which the host name field is NIL.  If the
         mailbox name field is also NIL, this is an end of group marker
         (semi-colon in RFC 822 syntax).  If the mailbox name fi=
eld is
         non-NIL, this is a start of group marker, and the mailbox name
         field holds the group name phrase.

Yeah well, IMAP splits out mail=
box name and hostname, so we can't quite use that, but I think having a nul=
l email address to mean "start of group" and null email address and null na=
me to mean "end of group" is fairly close to IMAP (so it's historically und=
erstandable to email client authors), and also should be reasonably straigh=
tforward for email server writers to implement (I believe cyrus does it alr=
eady, because it only has to slightly tweak the existing IMAP envelope data=
).

Rob Mueller
robm@fastmail.= fm

--_----------=_153173933838015840-- From nobody Mon Jul 16 04:59:48 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 CAFA1130E79 for ; Mon, 16 Jul 2018 04:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=tz9t6wWZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Mg30MmBx 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 T0booMuA3uV7 for ; Mon, 16 Jul 2018 04:59:45 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20531130E04 for ; Mon, 16 Jul 2018 04:59:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 87C152B5 for ; Mon, 16 Jul 2018 07:59:44 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 07:59:44 -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=OAyUHTm4hYlXbUYNG UHp2y3bsVVfn78wZA0Cr/GATaE=; b=tz9t6wWZ6hvKYve84bTUlhZPNEa7Z98xk uvOVf0sU7bmdQFoiWQhobnlEu+VIB9A8gqt/hv2MZopRCWrTnfd4V5TlO14O9r9a b4P/rWp8kBWl1grIqDtEO7oixk+8O+9n/LAkcLfRdqDw8PW0CKZJlUfKh+rzmagD ODDBeDgotPlqnGGp3Au05/xhen62UG4vPqkfL6w5P32YaLNk0CIscBlrByR3u3Ba FO9MksI9dQEMupYPt39sDgjir8rPyI6fOjr1sXLT4ZBm0+xsAcd+EVZS5BSXjbfL vvl/7gbMBo0WLv/kPTY5nJN54CO6o0lpzhFXTUDNj9gtTmv8m9LgA== 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=OAyUHT m4hYlXbUYNGUHp2y3bsVVfn78wZA0Cr/GATaE=; b=Mg30MmBxSX2RQubo+phpte 0eZVY+mK+vHM4X88IM4S6I/hizMj8R9077XwTUgRvHJIOYnQUGlm0jiVDv9ZGlVI 6zEJFS03DBWj5ih7NhBasyHjGxGBuukQI8UlJyKMVe/B+TaIDJMc86h1DmCkeOvi zOpN/GGzbqwvfgqHsIb6ChkiHGbNQje/9tNqMa9YCVkCnX+Fnr5UHGyFwZdj38zp eYEuQHH93hJ810nCoVoil/Lp84Lzy1gytup0IF76Qr3/fmTg5Ym/GU0lYic7lvrM R3/0KoGo4EAxVOz3yrebmJNo/uGA2hhuaER/9imqCDj974f9DSmRMMy22sjvvYpA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E512794133; Mon, 16 Jul 2018 07:59:43 -0400 (EDT) Message-Id: <1531742383.3822488.1442148192.2081C0EB@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153174238338224880" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> <1531739338.3801584.1442104952.05DFC1D5@webmail.messagingengine.com> Date: Mon, 16 Jul 2018 21:59:43 +1000 In-Reply-To: <1531739338.3801584.1442104952.05DFC1D5@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 11:59:47 -0000 This is a multi-part message in MIME format. --_----------=_153174238338224880 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, Jul 16, 2018, at 21:08, Robert Mueller wrote: > Yeah well, IMAP splits out mailbox name and hostname, so we can't > quite use that, but I think having a null email address to mean > "start of group" and null email address and null name to mean "end of > group" is fairly close to IMAP (so it's historically understandable > to email client authors), and also should be reasonably > straightforward for email server writers to implement (I believe > cyrus does it already, because it only has to slightly tweak the > existing IMAP envelope data). It was also quite trivial to add to the Perl proxy, which has the native parsed format as a list of structures, each of which contains a group name (may be undefined) and a list of addresses within that group. if (defined $group) { push @res, { name => asText($group), email => undef, }; } foreach my $addr (@$list) { my $name = $addr->phrase(); my $email = $addr->address(); push @res, { name => asText($name), email => $email, }; } if (defined $group) { push @res, { name => undef, email => undef, }; } -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153174238338224880 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, Jul 16, 2018, at 21:08, Robert Mueller wrote:
Yeah well, IMAP splits out mailbox name and hostname, so we can't quite use that, but I think having a null email address to mean "start of group" and null email address and null name to mean "end of group" is fairly close to IMAP (so it's historically understandable to email client authors), and also should be reasonably straightforward for email server writers to implement (I believe cyrus does it already, because it only has to slightly tweak the existing IMAP envelope data).

It was also quite trivial to add to the Perl proxy, which has the native parsed format as a list of structures, each of which contains a group name (may be undefined) and a list of addresses within that group.

    if (defined $group) {
      push @res, {
        name => asText($group),
        email => undef,
      };
    }
    foreach my $addr (@$list) {
      my $name = $addr->phrase();
      my $email = $addr->address();
      push @res, {
        name => asText($name),
        email => $email,
      };
    }
    if (defined $group) {
      push @res, {
        name => undef,
        email => undef,
      };
    }

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


--_----------=_153174238338224880-- From nobody Mon Jul 16 05:08:56 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 CDBBD130DC7 for ; Mon, 16 Jul 2018 05:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2A7l7VVJObR for ; Mon, 16 Jul 2018 05:08:53 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35529130E04 for ; Mon, 16 Jul 2018 05:08:53 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 37D6AC0030; Mon, 16 Jul 2018 13:08:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1531742939; bh=TunRc7oRTfS+CMYWcna1zPLLLe/BbN+YbUIsmgZ7j8M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RtjIHUGA+7iRuMeE3qyPtvn9FyTHPFna5rxMXPfw6duIYx2269YBHKGJ0C/6z+Lfv tc/D1wymF0F4z7ps/uk7Gm0Y6RilWNGFf4I77me5EUL8gTQ1t6QQ5qxBJnMgrF6hQs hXU7X6wE8/bhku1AGJqZx8xRKLyRyQRCqXeT38Yo= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1531742938-23985-23983/9/25; Mon, 16 Jul 2018 12:08:58 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 16 Jul 2018 14:08:50 +0200 Mime-Version: 1.0 Message-Id: In-Reply-To: <1531739338.3801584.1442104952.05DFC1D5@webmail.messagingengine.com> References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> <1531739338.3801584.1442104952.05DFC1D5@webmail.messagingengine.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 12:08:55 -0000 On Monday 16 July 2018 13:08:58 CEST, Robert Mueller wrote: > I'd prefer not to end up in a case where you can't represent > real world data accurately as defined by the latest email RFC > spec! Are there any real world senders that send real world mail to real world recipients and expect nonempty groups to be displayed with correct membership? If yes, then the test suite needs some examples of that. If no, then I suggest that group membership is not required for accurate representation, and ought to be discarded. Storing it on spinning rust is okay, serving that detail via the API puts an unnecessary burden on client developers. JMAP discards many other details, e.g. the server does RFC 2047 decoding and discards the charset defined in the encoded-word. BTW. If someone would like to do half the work, I'd be willing to trawl github until I find ten python/ruby IMAP clients I've never heard of before, so we can assess how buggy or bug-free the support for nonempty groups actually is. (I name those languages because the search should be simple and I can't think of any reason why their support should be better/worse than in other languages.) Arnt From nobody Mon Jul 16 07:44:07 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 91E291310EB for ; Mon, 16 Jul 2018 07:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB8H1IT2sBLO for ; Mon, 16 Jul 2018 07:43:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2660F131078 for ; Mon, 16 Jul 2018 07:43:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUXK6BXZYO004TZZ@mauve.mrochek.com> for jmap@ietf.org; Mon, 16 Jul 2018 07:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1531752022; bh=MeiZUG6pr69jgB7B/NCxG3dqKQfr+ZSD9wJwtxFIORc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=gP5rmxBGVwqOlJFF9kd4s/EGHGPYkoYkqPaievDAjgQMavZ/Extj6xqllDdOI1ZYe L6Gab9gStlmrDKcQlGDMmpA6JRRTK/VsUdPjnxGAZ4yCs7wy3s+vJ2pJPpm1nNTZiw Exa/I4K8BIyhUCMm+khbL+S0sonq5BpHosktAMbw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUCIBNY1B4000051@mauve.mrochek.com>; Mon, 16 Jul 2018 07:40:13 -0700 (PDT) Cc: jmap@ietf.org Message-id: <01QUXK651UCQ000051@mauve.mrochek.com> Date: Mon, 16 Jul 2018 07:10:11 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Jul 2018 14:08:50 +0200" References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> <1531739338.3801584.1442104952.05DFC1D5@webmail.messagingengine.com> To: Arnt Gulbrandsen Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 14:44:06 -0000 > On Monday 16 July 2018 13:08:58 CEST, Robert Mueller wrote: > > I'd prefer not to end up in a case where you can't represent > > real world data accurately as defined by the latest email RFC > > spec! > Are there any real world senders that send real world mail to real world > recipients and expect nonempty groups to be displayed with correct > membership? Given how much siloed usage of email there is in the world, do you think the tiny membership of this group is in a position to make this determination? I don't. I've lost track of how many times I've been surprised by the use cases customers present to our support people. > If yes, then the test suite needs some examples of that. > If no, then I suggest that group membership is not required for accurate > representation, and ought to be discarded. Storing it on spinning rust is > okay, serving that detail via the API puts an unnecessary burden on client > developers. JMAP discards many other details, e.g. the server does RFC 2047 > decoding and discards the charset defined in the encoded-word. > BTW. If someone would like to do half the work, I'd be willing to trawl > github until I find ten python/ruby IMAP clients I've never heard of > before, so we can assess how buggy or bug-free the support for nonempty > groups actually is. (I name those languages because the search should be > simple and I can't think of any reason why their support should be > better/worse than in other languages.) python/ruby are so last year. Why are we worrying about stuff written in those obsolete languages when the world is moving to node.js? (In case it isn't obvious, that was sarcasm.) Anyway, it took me about two minutes to find an node.js email address parser that supports nonempty groups as first class objects: https://github.com/emailjs/emailjs-addressparser The package's unit tests include quite a few group constructs, some of which are actually pretty nasty. (The author has some ideas about how to handle invalid syntax that make me wonder what is generating some of the email address lists this package has to hande, but valid syntax handling appears to me to be correct.) In fact this was the first node.js email address parser I found. It looks like it's used by a fair amount of other node-ware, including the associated IMAP client: https://github.com/emailjs/emailjs-imap-client The IMAP client was last updated five hours ago. The address parser was last updated 3 days ago, and has 9 forks. So it looks like this code is actively used and maintained. I trust I don't need to explain how the node.js ecosystem works and how packages like this are picked up and used. Ned From nobody Mon Jul 16 08:07:28 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 EAD50130E6B for ; Mon, 16 Jul 2018 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=xbVH2a5l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UUJ76iPY 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 PKvlcvVaFUmn for ; Mon, 16 Jul 2018 08:07:23 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903A012426A for ; Mon, 16 Jul 2018 08:07:23 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DAB36272 for ; Mon, 16 Jul 2018 11:07:22 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 11:07:22 -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=d0Ab7tBObggXLFhnH IqSFSE52cKftvaoX+6WOqCcwEw=; b=xbVH2a5l9XXbsTe8KbpUlB7iM2r6kcuys kd/X/VkadqR5XVdmxoHFDFA6rWJkJQU84x5wf9nirH0NX1FK52U22YoXUwverwA3 fWJ82owM1a8gZm6yhBGg6iaHz0TPvXPZBsJdGTHB9ax/3GWIkdSVyR6krZvT1FcL +DyoJdFDOaARIOLuqnWZiSgv3KXAet4ngfAliHYv2gsvkHEq1qDbyEyXz7lwQifX Mmv4mAF10o79r6FqpCPWxGKjSZDowhbgUR1JonH8ocSx/2uTTGbAMxyVLndFl0j9 qDI6MuqZFQjh0eT/lTHiU/m5o2bR8oIaqdPN9BzMjRVIKvAKimS2g== 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=d0Ab7t BObggXLFhnHIqSFSE52cKftvaoX+6WOqCcwEw=; b=UUJ76iPYo/9qUpIjnmitUJ OokUn2vvAaEwQO3aHrU0ktuUOUMEXSOQNUSlA10e2jNhvcYHwMIX6WtSUA7x5QAF hYi0QBkuPDn5mqhUaoOk60TiIc8o9O1GShMWd1SN/pWp7LEbS7yq0lfIUZG9+U7V WUCVu0pYiOZzqXU6MghtVy9nXNVY1R+sHvq4kgEFOXpdnyHchZ2KQz0c6FVNQYqy nJQ7EaScDcI5c0K26qAALVjTTh6yez8Duy4zWjWxWN+pzZLNlymcaHL9oYAEy6J/ bsvvfsEQ8PUfQQ8qexo/Ghg9mONSVtmvw+1cTlHghkmNazuU+9VTladfparRciNA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 01C709E102; Mon, 16 Jul 2018 11:07:21 -0400 (EDT) Message-Id: <1531753641.2111601.1442372528.11764A23@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153175364121116010" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa In-Reply-To: <01QUXK651UCQ000051@mauve.mrochek.com> Date: Tue, 17 Jul 2018 01:07:21 +1000 References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> <1531739338.3801584.1442104952.05DFC1D5@webmail.messagingengine.com> <01QUXK651UCQ000051@mauve.mrochek.com> Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 15:07:26 -0000 This is a multi-part message in MIME format. --_----------=_153175364121116010 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, Jul 17, 2018, at 00:10, Ned Freed wrote: > python/ruby are so last year. Why are we worrying about stuff written > in those> obsolete languages when the world is moving to node.js? The better Perl libraries certainly support it :) For some degree of "better". There's plenty of worser Perl libraries. So if we are supporting Group syntax, are we happy with the presentation: { name: "GroupName", email: null, }, { name: "Member", email: "member@example.com", }, { ... }, { name: null, email: null, } It's certainly easy enough to generate on the server. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153175364121116010 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, Jul 17, 2018, at 00:10, Ned Freed wrote:
python/ruby are so last year. Why are we worrying about stuff written in those
obsolete languages when the world is moving to node.js?

The better Perl libraries certainly support it :)  For some degree of "better".  There's plenty of worser Perl libraries.

So if we are supporting Group syntax, are we happy with the presentation:

{
  name: "GroupName",
  email: null,
},
{
  name: "Member",
  email: "member@example.com",
},
{ ... },
{
  name: null,
  email: null,
}

It's certainly easy enough to generate on the server.

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


--_----------=_153175364121116010-- From nobody Mon Jul 16 08:12:01 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 737EF131116 for ; Mon, 16 Jul 2018 08:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wsEXjLFp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Pw36MzhF 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 vzexxMzZ9yjM for ; Mon, 16 Jul 2018 08:11:49 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B55131119 for ; Mon, 16 Jul 2018 08:11:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B50DC2C1 for ; Mon, 16 Jul 2018 11:11:48 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 11:11:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=nSg9OOulO07oyPAk+ZC+vjTMuyvLcDqSmC+sMmjHU wA=; b=wsEXjLFpZjTW3JmHpiE8WyOukHJhpe3g9WbavCEWyBghkD6tPbM69RrqF s7NLFi05M3II6OSCna0yWOOTj/INpcEWkXFH4qod+w7N4l2koisGYdSQu6kJGhoE hQI9BINNWGOHjcnDk3vZRtdUGJdN4FeytSyXsfzScuSTwhfQvXdwiMFuDvvGY1Qj F3AKIvybjuXPput10wtXMCdPy6+60sYrmAdYdFVIbVe7noVv4cNVtM5TmsiDGZ8Y +JQ7puuUW+63mluNzTMKOqxF9fr1+xSOtujE5nbRHw5QN1bmVp8ll5MGFRAc7Pde D3qHfk8KWtschluz+fBENm9nGHQyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=nSg9OOulO07oyPAk+ZC+vjTMuyvLc DqSmC+sMmjHUwA=; b=Pw36MzhFLp7gFb2yvVoSyT0FnAjdkMTe3ROR1EFQE/oZ0 u21EyA17SMQd+Q4v0s7227X1BelZflp56SmZZVf/ep1syM9aArT987ZFWG8VQ1jz xRkTpzNnPsKUmtTw+z4fxdODMcwgEgphTyC96JzYSx+QeK7uj4vnzoNnv0XxN5vM YaI+rDaYLbO72iIziJ0SKsJcnhbvipiQSqM2PfVcB1ZOB6XUjfQmVunwcvco+tF2 y7JoAzEHx0cwhofZxN72jgXo5dmAGqBIXlYWDxbbBsxWWrmsUWao57fy5KwvL4WT my20nm+84XTG2zDQnPU6VpCM5+r9mdX/1YL9imcdg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 18A5D9E0A2; Mon, 16 Jul 2018 11:11:48 -0400 (EDT) Message-Id: <1531753908.2113076.1442378392.2B13702A@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153175390821130760" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 01:11:48 +1000 Archived-At: Subject: [Jmap] Slides uploaded X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 15:12:00 -0000 This is a multi-part message in MIME format. --_----------=_153175390821130760 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" https://datatracker.ietf.org/doc/slides-102-jmap-ietf102-jmap-slides/ Only new item for the agenda is totals in query responses. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153175390821130760 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

Only new item for the agenda is totals in query responses.

Bron.

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


--_----------=_153175390821130760-- From nobody Mon Jul 16 11: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 0C86C130EA5 for ; Mon, 16 Jul 2018 11:37:58 -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=qdy7K2CE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CSKZt6BC 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 ZnPCMsyx4t6V for ; Mon, 16 Jul 2018 11:37:55 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D5D130E74 for ; Mon, 16 Jul 2018 11:37:55 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 377BC39D for ; Mon, 16 Jul 2018 14:37:55 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 14:37:55 -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=+0nV11UJdjnMb0pinhQLpzSiTZ2knxO/+XtgqaZFV bs=; b=qdy7K2CE75r1bPffOtMvE2fcjYrnIeoqDaGc/Xg1+AlVv8PdRNSXpCX4N tO/N9awg4zwfwRcluObXLKZtMevISDeN++B4Wc3GOKIVzjO10k+c7YB+hI0k++kW 1URXwFK517jllA3lHyDw6GycAGRYndWxiD7+DvLu0TuDaRNk6IjahPndgxvm788S G3qTzn7JEs/CBb8ZXYajYWnSkBZIVKkiHh4/u7nPwRzJD1OOxKC9OWXiw85u9T1s LTQ55p+wTP8MANxIOpdO+Z/ZyHokVsj3aCSr6lfIkstvtSL0FnLnFqgpFry+qAmI NRJCSwPlsuFQKL+DBtzZA1DOO/0UA== 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=+0nV11UJdjnMb0pinhQLpzSiTZ2knxO/+XtgqaZFV bs=; b=CSKZt6BCqbTcwRb8K04eFw4ECcyRvwNI9mGi4GGeQmVIF4OjYyYqllEvg peGmUlwhE67u5GwXPy04z0X0L1KMl/LUUqYHQX/7PY2vtDZvMzKQ6y/Mbd8Mn0Md 9ppTRPHewoKQr68DRgSOXboIAyFcgGS27AkcvRNfhE3b0/XMTz2uj75UuBTJxnEB O6O2MzbvMayhjkINfEGqAKeCA8jkte51sSaLs+JQAw07IamhJsXXo2DbFgHpkeki UMqKWrav6Q2dF+CxmJSN4rxlq7VFj0ujbryHRTAa4SN94p+HWC7PWyPo/ZMj8JC7 CkMC6H0FNNoUijFWGq5daxYw5h7UA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4862DF114; Mon, 16 Jul 2018 14:37:54 -0400 (EDT) Message-Id: <712602b4-b6c3-496b-8ba5-299ddabf0055@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.4-437-gcc1b3ff-fmnext-20180712v2 x-jmap-identity-id: 64588216 In-Reply-To: <1531753641.2111601.1442372528.11764A23@webmail.messagingengine.com> References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> <5da29c15-973f-4ec9-9608-b4059edcac46@gulbrandsen.priv.no> <1531739338.3801584.1442104952.05DFC1D5@webmail.messagingengine.com> <01QUXK651UCQ000051@mauve.mrochek.com> <1531753641.2111601.1442372528.11764A23@webmail.messagingengine.com> Date: Mon, 16 Jul 2018 14:37:53 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=5d2f909a956d43b59f9f881f64299ee5 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:38:00 -0000 --5d2f909a956d43b59f9f881f64299ee5 Content-Type: text/html
I'm happy with the null/null representation, although I agree it's a hack. The main alternative in my mind is something like this:

{
  name: "GroupName",
  group: "start",
},
{
  name: "Member",
  email: "member@example.com",
},
{ ... },
{
  group: "end"
}

This is more explicit. The main disadvantage is that you have an array of objects that are different shapes then, which might be a pain for some statically typed languages to deal with.

Neil.
--5d2f909a956d43b59f9f881f64299ee5 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm happy with the null/null representation, although I agree it's a hac= k. The main alternative in my mind is something like this: { =C2=A0 name: "GroupName", =C2=A0 group: "start", }, { =C2=A0 name: "Member", =C2=A0 email: "member@example.com", }, { ... }, { =C2=A0 group: "end" } This is more explicit. The main disadvantage is that you have an array o= f objects that are different shapes then, which might be a pain for some= statically typed languages to deal with. Neil. --5d2f909a956d43b59f9f881f64299ee5-- From nobody Mon Jul 16 12:03:37 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306CC12F295 for ; Mon, 16 Jul 2018 12:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMs7Svbg4_Fx for ; Mon, 16 Jul 2018 12:03:34 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 745E1130F00 for ; Mon, 16 Jul 2018 12:03:34 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id r1-v6so7871194pgp.11 for ; Mon, 16 Jul 2018 12:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pFC1HCShR2sQP+HrEj1cSxL+5x7jmVHT21H3f5yZFcU=; b=QMrt9P45fzlMneQKAKJtbz1RsNzk+zFKTTKfvu42qQgDBlW+yfon84LQ3fguNZDuwU GPTqlqL4fAxOS865vLO8HsnFXZ6qdbWjR9iE0T8hYmUj/W15l/31ieOkFccSyQ7m1zyG vq+mJ/RGTvYKl7MAbjf0kOpfPqlhp39FFhc74IhvS/krPUnMv5E2c2RQPJKA8qMzVH60 Tc0cgtnMIcqBsTykZ72K4umfVhr9u+fccSiN1DPIExpQUJ+dZiiH3FLyVotmjpEhzLeI 1lw6ir8qf7GVsxuOlNyxiQyFKUHnWovfHGCvdvJJElY7qIk/aIDwGJV2KnXPmsu2NlZn Gt6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pFC1HCShR2sQP+HrEj1cSxL+5x7jmVHT21H3f5yZFcU=; b=s/08dNSvWgS2oNgi6xgWBn2LAFTxx0DDvRYumvO6+b3AT0xjf+Y2SU0mCosiRhA27a esf2Lj88u6U+8cxynEVxtOnChsBkRTjbw3Mj84MIm1b5/hNC0J5O7z8EijrlMaKV3kUe yifLquAdp7Dohu+2fMnhF96itfYbcGha6P9CncZDsmgYWxjBPBBwlX9mEZWXWpX9bNpH jyOqZSXfjn+hfQvinEfTNvkAzf4WsibcRM+x7yZpQxp9XiqdRY3HQwuXo1IQ4rl7n+nY zXcAnPxIncZ1j2o5fwPxY3N91ViheS5RFeI8RTiaWIUn+7d/mTMS5lj3mVFT2zk96iuI TDEw== X-Gm-Message-State: AOUpUlHhq0dcvhjC50YnomqsmyuG2QfkN5xNcwXqro8sIIA5h4J+H5be FeeyBNaV14k3vhsQwqLClHkfsBgRpN8= X-Google-Smtp-Source: AAOMgpfDeLq/+nFewS7ER38urO3JP9m6aqec1X0phde6njzRs5PBm7zhDt9nbNpCaHzSpMWwHFmHfg== X-Received: by 2002:a63:df04:: with SMTP id u4-v6mr16459605pgg.434.1531767813927; Mon, 16 Jul 2018 12:03:33 -0700 (PDT) Received: from ?IPv6:2601:646:8800:790:5402:81ec:944a:eac7? ([2601:646:8800:790:5402:81ec:944a:eac7]) by smtp.gmail.com with ESMTPSA id o72-v6sm67119568pfk.76.2018.07.16.12.03.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jul 2018 12:03:33 -0700 (PDT) From: Neil Jhaveri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BFB6C3E4-5257-4F38-9CC3-1E77C777E588" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 16 Jul 2018 12:03:32 -0700 In-Reply-To: <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:03:36 -0000 --Apple-Mail=_BFB6C3E4-5257-4F38-9CC3-1E77C777E588 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 16, 2018, at 2:56 AM, Neil Jenkins = wrote: >=20 > On Mon, 16 Jul 2018, at 6:37 PM, Neil Jhaveri wrote: >> What about an optional property =E2=80=9CgroupName=E2=80=9D? >>=20 >> [ >> {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jhaveri=E2=80=9D, email: = =E2=80=9Cneil@neiljhaveri.com=E2=80=9D, groupName: =E2=80=9CThe = Neils=E2=80=9D}, >> {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jenkins=E2=80=9D, email: = =E2=80=9Cneilj@fastmailteam.com=E2=80=9D, groupName: =E2=80=9CThe = Neils=E2=80=9D}, >> {=E2=80=9Cname=E2=80=9D: =E2=80=9CAnother Person=E2=80=9D, email: = =E2=80=9Canother@person.com=E2=80=9D} >> ] >=20 > The main trouble with this is that the most common use of the group = name is for something like this: >=20 > To: undisclosed-recipients:; >=20 > There are no mailboxes here, so there's nothing to add a groupName = property too. I think therefore there have to be start/end group = objects. What about {"name": null, "email": null, "groupName": = "undisclosed-recipients" to handle this case?=20 A normal address: {"name": "Neil Jhaveri", email: "neil@neiljhaveri.com = "} An empty group: {"name": null, "email": null, "groupName": "undisclosed-recipients"} A nonempty group: {"name": "Group Member1", email: "member1@group.com = ", "groupName": "Group"}=20 (The only downside I see to this is if there are two sequential groups = with identical names but different membership.) >=20 > Neil. --Apple-Mail=_BFB6C3E4-5257-4F38-9CC3-1E77C777E588 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 16, 2018, at 2:56 AM, Neil Jenkins <neilj@fastmailteam.com> wrote:

On = Mon, 16 Jul 2018, at 6:37 PM, Neil Jhaveri wrote:
What about an optional = property =E2=80=9CgroupName=E2=80=9D?

[
  {=E2=80=9Cname=E2=80=9D: =E2=80=9CNeil Jhaveri=E2=80=9D,= email: =E2=80=9Cneil@neiljhaveri.com=E2=80=9D, groupName: =E2=80=9CThe = Neils=E2=80=9D},
  {=E2=80=9Cname=E2=80=9D: =E2=80=9CNe= il Jenkins=E2=80=9D, email: =E2=80=9Cneilj@fastmailteam.com=E2=80=9D, groupName: =E2=80=9CThe = Neils=E2=80=9D},
  {=E2=80=9Cname=E2=80=9D: = =E2=80=9CAnother Person=E2=80=9D, email: =E2=80=9Canother@person.com=E2=80=9D}
]

The main trouble with this is = that the most common use of the group name is for something like = this:

To: undisclosed-recipients:;

There are no mailboxes here, so there's = nothing to add a groupName property too. I think therefore there have to = be start/end group objects.

What = about  {"name": null, "email": null, "groupName": = "undisclosed-recipients" to handle this case? 

A normal address:
{"name": "Neil = Jhaveri", email: "neil@neiljhaveri.com"}

An empty group:
{"name": null, "email": = null, "groupName": "undisclosed-recipients"}

A nonempty group:
{"name": "Group = Member1", email: "member1@group.com", "groupName": = "Group"} 

(The only downside I = see to this is if there are two sequential groups with identical names = but different membership.)


Neil.

= --Apple-Mail=_BFB6C3E4-5257-4F38-9CC3-1E77C777E588-- From nobody Mon Jul 16 12:05:34 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 B7874131181 for ; Mon, 16 Jul 2018 12:05:31 -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=Wetsv/nv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZQybsHYW 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 n4boowtZfvSt for ; Mon, 16 Jul 2018 12:05:30 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0747712F295 for ; Mon, 16 Jul 2018 12:05:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 88F663E2; Mon, 16 Jul 2018 15:05:29 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 15:05:29 -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=fm3; bh=RMSh/AxvLL7QaWzc2F8b3GuQU/0+AXFqiY5ztOEda fQ=; b=Wetsv/nvPBgRmdTY3WO5aZWhRydo8mScMKHlbSpw82V3JNthwaQaUhYS2 5bnfwakKcBafiFCki0Fym2QnListF9zAQl3u/xiM2lLrGpAwYWdEj6Ajpc/p/+mi bqGWBZpmNjKrbSwgr0WvqxR79Mw6F4F0Ksh0+EczeGZWlkg+JA7Z1ZhEigmQYWxS +TascP/vv3hFtSRQmIltr6OHqlgAmghIo+2kiqQjoCjToWjWLUMsHRynOA9WCKmC 0MOxd6DJdXhp7WCwdUXk0Bx9Rkrtg4KUKQidJm+w0wnrl4C/39pqFWgHYFLcbf3E YoWV2Mo2zasPx5chAFmosu8I0XjnA== 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=RMSh/AxvLL7QaWzc2F8b3GuQU/0+AXFqiY5ztOEda fQ=; b=ZQybsHYW/kyKMPc+b0Q1zpogDS4UK4H1RPeCTTdiLqGmLBcpMWTgjep/d F+BMlXEbhIadhL2vGBm7ytQqG7KplBSbQ2lb9RSzjxLnEYpCepSb+3OsIBoyV+aC oP7IHpZzar3q/x/yDG+Cun4HyWrEDP3gkk1F7IBJpdvKwY6TeQlbqWA42mxu3WI1 NAtBJG39EkwruAKmisWYOIKWGw8k5eeTzupb3r9Fwqi3LSCX+ZHYC3sBdhqdXrk0 2sIXMg4CdpDvc8sIgNSTjg22PSb2G+EbHdASQapXY1ChxamRiQZthdVjb0D8z0Gy wiphzheulPRAShlluhCS1L0ph+DqA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D7696F114; Mon, 16 Jul 2018 15:05:28 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.4-437-gcc1b3ff-fmnext-20180712v2 x-jmap-identity-id: 64588216 In-Reply-To: References: <77C4AF98-B3B6-4C18-AFAE-A63EDAB00DF6@neiljhaveri.com> <64c637e8-cbf8-4158-b3b3-6040252d93b0@sloti35d1t03> <1E7BD237-053D-4C4A-82E5-6B9D04E5A732@neiljhaveri.com> <2a4940f9-7ea4-4e67-b00e-5b5557da8ac9@sloti22d1t06> Date: Mon, 16 Jul 2018 15:05:28 -0400 From: Neil Jenkins To: Neil Jhaveri Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=f103b0c217eb4a44bbf9c61b38f79464 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:05:32 -0000 --f103b0c217eb4a44bbf9c61b38f79464 Content-Type: text/html
On Tue, 17 Jul 2018, at 5:03 AM, Neil Jhaveri wrote:
What about  {"name": null, "email": null, "groupName": "undisclosed-recipients" to handle this case? 

I don't like this, because the non-empty group case is different to the empty group case (which is the only time you would get a null email!). More cases to test, more chance of implementations messing up.

Neil.
--f103b0c217eb4a44bbf9c61b38f79464 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 17 Jul 2018, at 5:03 AM, Neil Jhaveri wrote: > What about =C2=A0{"name": null, "email": null, "groupName": "undisclos= ed-recipients" to handle this case?=C2=A0 I don't like this, because the non-empty group case is different to the = empty group case (which is the only time you would get a null email!). M= ore cases to test, more chance of implementations messing up. Neil. --f103b0c217eb4a44bbf9c61b38f79464-- From nobody Mon Jul 16 12:10:29 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 2018012F295 for ; Mon, 16 Jul 2018 12:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=w30B+zjr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C1za3aF1 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 m4jjs8ceDQOz for ; Mon, 16 Jul 2018 12:10:24 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42DF131180 for ; Mon, 16 Jul 2018 12:10:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 1AAE93D4 for ; Mon, 16 Jul 2018 15:10:24 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 15:10:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=BKuL2E6r59TEnT1+21GuvkmTbnD5AtW6BX0gcBfou vI=; b=w30B+zjrmxIdbvRSNgUKEeRFyZ+zUi6PPhasjxxio1Y80BOcZ4FoIvNjx DmtM+3FLdrB5pSFBl8+/5ajFNgKoQGhY9jhjszBpejJLJTV12zneamXWFDIcfBFp EogbYAGLB76F8EZnu3qNUgWuWtvNrKz0liI8o6o4TM+akZPHzZhWRqga7otb/xW4 lNN1BS7DyNpo6aHOeQAyctOSbrjVga+rmeEWtbLWK9vMSZJOpAh9HZ2GO56oiY0l BhCVl0tKVMjc+1iu/VIj/Q0Wf9CGSQbla0TXMqyXVVxCVAZ1hNVmJ2u8rXq1pyyX xjeFrUcty1GFNmu+YqHMH56fWgGZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=BKuL2E6r59TEnT1+21GuvkmTbnD5A tW6BX0gcBfouvI=; b=C1za3aF1kW/EimBGrKZX2+cenJ4+N5PJr0BvOvi7jJGB8 nhWxg1Et5H4o0tSYJNupQGqz6iCL36F+1P0MRFvp1SGeniYYjBBoG7N1B8y2mCN0 36y2tV2Cjtl5nr2osiu7UmpUE2RoSAHuNve046gMtwueov5uYuXy7one0oK1tXWh LOHapzz4bVoRfjU4TkQCYeNsO/pzv0FW0CXX4Nr9xb+B9p2yoW/XdJFkPm4A4PE0 zZgyll0fdJ5mxbyWeFEZ8fs8+8y+KPMjUTvbYN7pzM5a+d49HN7b6fkYfLS6JGJn zxfPjExb1LcQrH16lMXsz+pOAyCCI8AVEPJQefKEQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 574609E10A; Mon, 16 Jul 2018 15:10:23 -0400 (EDT) Message-Id: <1531768223.2177812.1442668928.2DF5FBDD@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153176822321778122" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 05:10:23 +1000 Archived-At: Subject: [Jmap] Minutes uploaded X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:10:27 -0000 This is a multi-part message in MIME format. --_----------=_153176822321778122 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I've uploaded the minutes to the Datatracker. Text follows: JMAP IETF102 Minutes - Montreal / 16-Jul-2018 13:30-14:30 Core ---- * Error Registry - Registry is infrastructure - better to get it in place up front! - Chris Newman will write text * Push Filtering - Keep default behaviour as "push everything for data type" - Create an extension for "filtered push" as a separate option * Explicit totals - We're going to change to "require client to ask for totals" - If the client doesn't ask, server MUST NOT send totals, because clients often just test against an implementation. * Last Call - no objections in the room to going to last call after applying this current set of changes Mail ---- * Group Names - lots of discussion, will finalise on the list * Splitting out extensions - will keep vacation in the mail spec document * but with a separate capability, so there's an example in the spec of how to do extensions to it. - attachment searching is covered by updated text in the spec * "search in non-text bodyparts" * would be useful to know which MIME bodyparts matched * Last Call - no objections in the room to going to last call after applying this current set of changes Extensions ---------- * Re-charter - more likely to succeed if we have an initial set of extensions that we plan to work on rather than fully open-ended. - will start with what we have now * websockets - FastMail and Isode are interested - Ken to keep working on it - wsUrl to be moved under capabilities because there's already a registry there, so no namespace clash issues * sieve - Definite interest - Very few clients allow full sieve editing, instead having a more simplistic rule builder. - Do we want to offer an intermediate format? (like how JMAP hides the full MIME complexity) - to be discussed on the list * MDN - Definite interest - Will go to the list for an author * single HTML file - No demand for it yet, so shelved - Question: is there a standard "web archive" format yet? Should consider that as a way to bundle images, etc. * search in attachments - see above: non-text body parts - it's impossible to get all possible searchable text to match user expectation (e.g. OCR of text-like images), so it will always depend on what servers can do - put text in the spec detailing the user experience behaviour, but don't constrain server Other Business -------------- Discussion went back to nulls and groups in the asAddresses representation,and nothing was resolved. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153176822321778122 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I've uploaded the minutes to the Datatracker.  Text follows:

JMAP IETF102 Minutes - Montreal / 16-Jul-2018 13:30-14:30

Core
----

* Error Registry
- Registry is infrastructure - better to get it in place up front!
- Chris Newman will write text

* Push Filtering
- Keep default behaviour as "push everything for data type"
- Create an extension for "filtered push" as a separate option

* Explicit totals
- We're going to change to "require client to ask for totals"
- If the client doesn't ask, server MUST NOT send totals, because
   clients often just test against an implementation.

* Last Call
- no objections in the room to going to last call after applying
   this current set of changes

Mail
----

* Group Names
- lots of discussion, will finalise on the list

* Splitting out extensions
- will keep vacation in the mail spec document
   * but with a separate capability, so there's an example
     in the spec of how to do extensions to it.
- attachment searching is covered by updated text in the spec
   * "search in non-text bodyparts"
   * would be useful to know which MIME bodyparts matched

* Last Call
- no objections in the room to going to last call after applying
   this current set of changes

Extensions
----------

* Re-charter
- more likely to succeed if we have an initial set of extensions that
   we plan to work on rather than fully open-ended.
- will start with what we have now

* websockets
- FastMail and Isode are interested
- Ken to keep working on it
- wsUrl to be moved under capabilities because there's already a
   registry there, so no namespace clash issues

* sieve
- Definite interest
- Very few clients allow full sieve editing, instead having a more
   simplistic rule builder.
- Do we want to offer an intermediate format?  (like how JMAP hides
   the full MIME complexity)
- to be discussed on the list

* MDN
- Definite interest
- Will go to the list for an author

* single HTML file
- No demand for it yet, so shelved
- Question: is there a standard "web archive" format yet?  Should consider
   that as a way to bundle images, etc.

* search in attachments
- see above: non-text body parts
- it's impossible to get all possible searchable text to match user
   expectation (e.g. OCR of text-like images), so it will always depend
   on what servers can do
- put text in the spec detailing the user experience behaviour, but don't
   constrain server

Other Business
--------------

Discussion went back to nulls and groups in the asAddresses representation,
and nothing was resolved.


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


--_----------=_153176822321778122-- From nobody Mon Jul 16 12:20:05 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8481311D3 for ; Mon, 16 Jul 2018 12:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wJ4rCttu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oTrxjeop 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 Q9ShyZ5djC91 for ; Mon, 16 Jul 2018 12:19:53 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7A9131181 for ; Mon, 16 Jul 2018 12:19:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3448439B for ; Mon, 16 Jul 2018 15:19:51 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 15:19:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=tiDaY09uo6V4yaY2I73SwtxHXAnFZjA+TU6dqCWR2 LY=; b=wJ4rCttunp9gWkrwgUjm3wUfbbZbfp8kl2Kd2ttxd8BUTSOmP0nqNz1Hx fxEYT2Zq6akOSg4dtTV/5CwbNmrq6/kJAAh2zpSPcQaHvLOI5cZ0OVW6eP0ylv4Y Jgj903tLQZZYNyjGjQlfDzEV4fqAr1RcYw29PSwLWacecfIK7PQece6dLqxYovtf yuAsu+dtClrF3AhoqNmGWoOTwF3u8P4UxBKwFREUrJ7hdt9wL5tDZKkRWOHN43GJ S35jNs0FQnN0aIt1ILv2ftaSNoZ/Vr9kOomOECLFe8vX+1DeOxFWf2UGJtRi0uNT N4WRPZCEndAbO0MgqoBLyhuBXYH3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=tiDaY09uo6V4yaY2I73SwtxHXAnFZ jA+TU6dqCWR2LY=; b=oTrxjeopgSD3MlPomNQq0wj13K6UjN/DVG8p3fazchzFY tVubCKZFeSrq0AGkMNy0OblKt/ItRhqYYjiq4x5EpGRA5pTwVL3YyuMKrdxcbGcS 8llDGiPtCJQm/6BdXHapbaBZn7NbAEXPwukeIDq5VSB1HyDqkcVYjyfnGtcJ6/Lo 43tuiZ9ctgpABwx37S+p/zrrS1fYlKXJ2k1eU3DFEp03xNFMdwDygP0vBWqhI5W0 8HFCpWFZlPVxc91/HQxDrxG4avdk2sqnxHCr3IWcgxF4KH+XkEQmuXvR4D8/Pnzo kpZ1Dhr2dOApZJzY5FR+m3tfFSv5rmZOjAuq9aLvg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 95D4A9E10A; Mon, 16 Jul 2018 15:19:50 -0400 (EDT) Message-Id: <1531768790.2181790.1442669984.0DB3B48E@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153176879021817900" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 05:19:50 +1000 Archived-At: Subject: [Jmap] List of extensions planned X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:20:04 -0000 This is a multi-part message in MIME format. --_----------=_153176879021817900 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Reading through the minutes, these are the extensions that I will be proposing that we add to the charter: * jmap-core-push-filter - A method for filtering push messages from a JMAP server* jmap-core-websockets - A way to transport JMAP over websockets * jmap-mail-sieve - A way to manage sieve (RFC5804 via JMAP) * jmap-mail-mdn - A way to submit message disposition notification (RFC3798 via JMAP)* jmap-calendar - A method to access and manage calendars (RFC4791 via JMAP)* jmap-contacts - A method to access and manage addressbooks (RFC6352 via JMAP) Are there any other extensions that I have missed? I'll be working with Alexey to work out how to write the re-chartering request. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153176879021817900 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Reading through the minutes, these are the extensions that I will be proposing that we add to the charter:

* jmap-core-push-filter - A method for filtering push messages from a JMAP server
* jmap-core-websockets - A way to transport JMAP over websockets
* jmap-mail-sieve - A way to manage sieve (RFC5804 via JMAP)
* jmap-mail-mdn - A way to submit message disposition notification (RFC3798 via JMAP)
* jmap-calendar - A method to access and manage calendars (RFC4791 via JMAP)
* jmap-contacts - A method to access and manage addressbooks (RFC6352 via JMAP)

Are there any other extensions that I have missed?  I'll be working with Alexey to work out how to write the re-chartering request.

Thanks,

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


--_----------=_153176879021817900-- From nobody Mon Jul 16 12:27: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 8BDE41311DF for ; Mon, 16 Jul 2018 12:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=o6BV0J5o; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sjR4q5DW 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 7Mu-KNoCs6Yr for ; Mon, 16 Jul 2018 12:26:49 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF04131181 for ; Mon, 16 Jul 2018 12:26:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E146224D for ; Mon, 16 Jul 2018 15:26:48 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 15:26:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UvSblzCYoyEkMtJBxHM8Qr4fLXo9KoQLP72gAjOE5 ns=; b=o6BV0J5omGHhd7G9UAEVInuGfXns7Ldnw1CRyVZdxbIZVbP8TMPfaeUYa u24ZLEOGd1f6i1ip0BwnYCpi4rbN5yFy3+NLsjzF9iQE9AFtQc3A9O4F/vwCZFCs MqLl/a2bbG8CJuTl4mj82spWekQnwfiNEb1wIp5vfmxK5ESapCBWquh3kkuAAgfr 8ksjqhA7Xz1z1k72kFbbKW/YLAln2SK7x2lr+cfS/ArCpcmvOWbk0SH3XjeV2glK FglgKLpKmiosfaPlJJboVp8dOlBUwVfJDV/wsuLwubgKlQy94Yj4xNIiy2XrrXsc oP1OIxFXhUSKcDHHACa+SqkiGA3iw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=UvSblzCYoyEkMtJBxHM8Qr4fLXo9K oQLP72gAjOE5ns=; b=sjR4q5DWxXHGFTs6H5Qja3thmaruYC9OSXmS8XmPbwQqE hKrL2svCpgw/Auut+QH9pz/zMMTcs/3veJSAac68wy8IAgtyAl8oNrpF1n0EJVtO x3bmdHnjPMFEIEYu2rCA/Ak9JBsDx5/CkYnW303ArgPxF1LB9IyaJyW0co1dzWK4 jQOX2hWgDlIhfKpjQwoU5MlBBdualLD9/4AUuf+nGKx+aIE1z/+8iMi4duJYF8tM L8bNT1VhtIk8EKJLVpOoNLGSg8oAOhGV+xExsVtxj0NvgKoZQG6IpH7rny9drnu/ f4p96MAqaajdhmOAWA9q3OX3Z+QY0+br9VoZ2hgsA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 40F0E9E10A; Mon, 16 Jul 2018 15:26:48 -0400 (EDT) Message-Id: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153176920821847200" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 05:26:48 +1000 Archived-At: Subject: [Jmap] Discussion of "MANAGESIEVE for JMAP" X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:26:55 -0000 This is a multi-part message in MIME format. --_----------=_153176920821847200 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" This was the extension discussion for sieve. The discussion in the room covered: * Full sieve support is common on servers, but rare in clients * Do we want to support all of sieve, or just a subset? (if so, how do we decide what subset? How do we update with future sieve extensions?)* how does this interact with the vacation support in the mail spec? My suggestion is that we start with an extension for full sieve, and maybe propose a way to manage a more limited file as well. The key question here would be whether we transport sieve scripts as a blob of raw text, or whether we define a "sieve as JSON" mapping. Next steps: * What's the scope of what we want to do? (managesieve inside JMAP / sieve as JSON / limited subset)* Who wants to author a spec? Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153176920821847200 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
This was the extension discussion for sieve.  The discussion in the room covered:

* Full sieve support is common on servers, but rare in clients
* Do we want to support all of sieve, or just a subset?  (if so, how do we decide what subset?  How do we update with future sieve extensions?)
* how does this interact with the vacation support in the mail spec?

My suggestion is that we start with an extension for full sieve, and maybe propose a way to manage a more limited file as well.  The key question here would be whether we transport sieve scripts as a blob of raw text, or whether we define a "sieve as JSON" mapping.

Next steps:

* What's the scope of what we want to do?  (managesieve inside JMAP / sieve as JSON / limited subset)
* Who wants to author a spec?

Bron.

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


--_----------=_153176920821847200-- From nobody Mon Jul 16 12:28:52 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D04130DE2 for ; Mon, 16 Jul 2018 12:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=G1EtRkLq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Pgk0G69S 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 okKk9E2tkIZo for ; Mon, 16 Jul 2018 12:28:48 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBF8131186 for ; Mon, 16 Jul 2018 12:28:47 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 0807D35A for ; Mon, 16 Jul 2018 15:28:46 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 15:28:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=t0sDOlzxFuccI5ev1iS4SjBjchh1fERh/mIVyZ4ep Pc=; b=G1EtRkLqvVSKxA/6HsLYmlJf7O9dvPFdCtJIJ0tyRT7DMXs4FDzV1p0Lx Uzpz04CLFgGp0AIpIe35OjVzZIUfPgQyHgvVwA50Hi9exGTrYazrZUShnuMI6mfx iq/qz3ZlvoGalbbE2N22t8J/A+47oD9IANKklLPG4bRGkvAEZQhIJ/Hmycdv3hXS jPz9X1GiFfP8/MfvGpaobCZs9Lvi12yTmWh9JSklalDcgarvO+h8RE1d2ov3jse4 x/1nmPPDfv5qkERpECDPmeftKNR+oxmD/2xUhwjdEn9aRvhehDZi6HiQi3VsHmgV WlHGwM3/we0B518nnLjzHh30FtNCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=t0sDOlzxFuccI5ev1iS4SjBjchh1f ERh/mIVyZ4epPc=; b=Pgk0G69SEZqE/cV6Ilmp9MYHrN6ZM0ncALttVgeExuYjF CKZ5AdpHFrPLmdOc5kUTpSXMVyXFU4JQ4pSMgGEwEH0bS1dK4hYdjz6NIjXzsu54 LloTYvYBMijBblL9KKoddM+gN7Aa4Oew9XAvVZKSwgueSqbmNn2YpFhXyRT6yJCc fwbJSvIjM/YyqgYmGN8LFbfbdSdxtMDfx8J21TAkEm4+ugMwJsCZSUuJh5GDskcA 4i1N05LmhmcVMSpZ8v/Zf/Wr6llD5Sg6UGXPMkHppBXQiFCjcnK0W6xd2WQ+QjK6 fFVoNhBui+mWRPxM+dAXhEe7nf4mkVybQ1UTMYotw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 52FEA9E10A; Mon, 16 Jul 2018 15:28:46 -0400 (EDT) Message-Id: <1531769326.2185479.1442690368.32F5133D@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153176932621854792" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 05:28:46 +1000 Archived-At: Subject: [Jmap] MDN extension - call for author! X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:28:50 -0000 This is a multi-part message in MIME format. --_----------=_153176932621854792 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi all, We agreed in today's meeting that we want to create an extension for creating MDNs via JMAP. We need somebody to champion this and author the extension. Please make an orderly line in the replies. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153176932621854792 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi all,

We agreed in today's meeting that we want to create an extension for creating MDNs via JMAP.  We need somebody to champion this and author the extension.  Please make an orderly line in the replies.

Thanks,

Bron.

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


--_----------=_153176932621854792-- From nobody Mon Jul 16 12:44:39 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA1E130E09 for ; Mon, 16 Jul 2018 12:44:37 -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=qLfpt2SI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=b5c0WQqW 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 6aSvrUQzCY0k for ; Mon, 16 Jul 2018 12:44:35 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B68130E42 for ; Mon, 16 Jul 2018 12:44:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B99B5331 for ; Mon, 16 Jul 2018 15:44:34 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 15:44:34 -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=Rtf44zE+OmR8b6eg/G37nKa6G+xcMgT5dY1Qa5Utz Dg=; b=qLfpt2SIud4mfQppG1d/TqYXQobQhYcF14bYb4n1+CD3jnoLnpbJPvI5V WBiJw9Z79lf1jKvbGcdVLGH2Ih9su7gzr4ECLgSrkB4EMzqanOeve1X4mlsl4Rur 0N3Pk3LdW1z2vu9RLybpMbjj4d2a/iQP8YIG6L2fIOikZjnG4wOqxgEkVdumFJ1g NyLfLW173NQYig0vOfdrXMLZayVt6jGufKcz3xoEI7jsjkRMYuGGEsSyrMRbjy1n aHZVNzDXhXiEcCVoY7Ccprrv7zZgvGR5LKuKzAPJhqg3lTVKD1XvSuvv8Q+ul13n 8ttFIw6oGwqwOZKAgeXBRf59Afq1w== 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=Rtf44zE+OmR8b6eg/G37nKa6G+xcMgT5dY1Qa5Utz Dg=; b=b5c0WQqW6rRFerlippxU9mpL2cMGidfa9mVhIzmdvFmVC75yA0pTXr9g6 VI6TV+0c1p0Vq1NPyXDroUMSX7kpz1X8gPEww6mVXZoxhBaC8wHmRHi5j0dKhqtI 00oLDnJ4Qh+/9OpdmYFVW/ruG+0diHc9wCpMBQ7wdii2SdJHDmraCLUrMvALPtE2 s3vuY51/sA//FgM3wyuH3MBNmZiubID1bv35AsNqR1+8N/ijRYi7kDbREu8lRlxT tT5v0wbHDnS/s92hw/g60jZA2G2LITrwEOD6sBUweRaih0l7R2nVhZI8LIX183tn xuwEP2AL5o/3Q2LFXKWi3YA9KjVJw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ABC48F114; Mon, 16 Jul 2018 15:44:32 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.4-437-gcc1b3ff-fmnext-20180712v2 x-jmap-identity-id: 64588216 In-Reply-To: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> References: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> Date: Mon, 16 Jul 2018 15:44:47 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=ed0942c6f465483b8f82dcc233104700 Archived-At: Subject: Re: [Jmap] Discussion of "MANAGESIEVE for JMAP" X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:44:38 -0000 --ed0942c6f465483b8f82dcc233104700 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
As discuss= ed in the meeting, to a rounding error, no one writes sieve. Instead, cl= ients present a GUI that generates sieve in the background. The trouble = is that different clients will support different features and produce di= fferent sieve, not to mention going from the raw sieve back to the GUI b= uilding blocks is a hard task in itself, so I struggle to see how this e= xtension is going to lead to useful interoperability, unless you presume= users only use one client and anything else is "here be dragons".

A JMAP extension for "rules" would be very usefu= l if it could let multiple clients edit them=E2=80=A6 but whenever I've = looked into trying to define this, the differences in supported features= between servers let alone clients is so huge it's seemed impossible to = come up with anything likely to be both useful and implemented.

Neil.
--ed0942c6f465483b8f82dcc233104700 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable As discussed in the meeting, to a rounding error, no one writes sieve. I= nstead, clients present a GUI that generates sieve in the background. Th= e trouble is that different clients will support different features and = produce different sieve, not to mention going from the raw sieve back to= the GUI building blocks is a hard task in itself, so I struggle to see = how this extension is going to lead to useful interoperability, unless y= ou presume users only use one client and anything else is "here be drago= ns". A JMAP extension for "rules" would be very useful if it could let multip= le clients edit them=E2=80=A6 but whenever I've looked into trying to de= fine this, the differences in supported features between servers let alo= ne clients is so huge it's seemed impossible to come up with anything li= kely to be both useful and implemented. Neil. --ed0942c6f465483b8f82dcc233104700-- From nobody Mon Jul 16 13:12:00 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69055131238 for ; Mon, 16 Jul 2018 13:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=kL8/aBJt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RPXC8yZ/ 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 zCcUrNtIHJKP for ; Mon, 16 Jul 2018 13:11:47 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EFE131214 for ; Mon, 16 Jul 2018 13:11:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4AB302FE for ; Mon, 16 Jul 2018 16:11:30 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 16:11:30 -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=VAd9imm7MAicU5opb FyThbH3ATS848MEHKIXUvaLYEg=; b=kL8/aBJtJ8ZYbNgk5lhvyb+IOhp/SjBlO JyauHgaphzJbPV1nY0eGqqTfyNWfN1PdmMo4gl27U1LFNwZuxU/y/uPDLVuGOMeC P3VgC020K3hIa/RB8EVvOuIp0seXvj7PNXI/ktnV3g0Z1X2tAByF1y7/h/Dad6Fn wdmMcWkZZ/lS0Uli3tsCGZUR95qri27g8o7SfXzDee5YxCI/DqsMiJBh2CJawkFp 4oVCBINXygT+Bac3iXvsS46H0Gga96UNT2RoEz8Qv07oUVdXm4wiButwnnbkcOQ8 AAX4EJ0/BFn6QLTVWZfjmBlsNbukz0/t9cLKB1zvEpKxeBtbSQxSw== 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=VAd9im m7MAicU5opbFyThbH3ATS848MEHKIXUvaLYEg=; b=RPXC8yZ/kq+9VmjjdSgEBx EpR0msqIeOZl7XfQY/+jR9WpVaGJhC8zjHU6zvEYW8lynR2CVIgJp7yRo8fCdWxR iGBSpYFXa1JGkQ8oAbK7W9rLgxZ9h1LaMLTT2AV/E9uEdJj7w8K3em+PjXIRJeJj hVO0YLkC2u6jt+ENFbQMv/y2T8tCqVkLhU3cUvwajGXNJHgntgbfDY9unbd1qjJF b1Md9rHcHV4aVZAE91XyFhvKobQvkKipvYoXOGuuZLoeLpezlNjT/Xpf8xkp82QV 0WrBXhlWZKg8AsnIkC7veqaW8QQfywdDXIQC9B8XV0/NNOEK8PD3v6zfA3tvEoVA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 885CC9E10A; Mon, 16 Jul 2018 16:11:29 -0400 (EDT) Message-Id: <1531771889.2202688.1442738640.35506494@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153177188922026882" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 06:11:29 +1000 In-Reply-To: References: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Discussion of "MANAGESIEVE for JMAP" X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 20:11:59 -0000 This is a multi-part message in MIME format. --_----------=_153177188922026882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Yep, so the question is "how can we add value" over just having people use managesieve... On Tue, Jul 17, 2018, at 05:44, Neil Jenkins wrote: > As discussed in the meeting, to a rounding error, no one writes sieve. > Instead, clients present a GUI that generates sieve in the background. > The trouble is that different clients will support different features > and produce different sieve, not to mention going from the raw sieve > back to the GUI building blocks is a hard task in itself, so I > struggle to see how this extension is going to lead to useful > interoperability, unless you presume users only use one client and > anything else is "here be dragons".>=20 > A JMAP extension for "rules" would be very useful if it could let > multiple clients edit them=E2=80=A6 but whenever I've looked into trying = to > define this, the differences in supported features between servers let > alone clients is so huge it's seemed impossible to come up with > anything likely to be both useful and implemented.>=20 > Neil. > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153177188922026882 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Yep, so the question is "how can we= add value" over just having people use managesieve...


On Tue, Jul 17, 2018, at 05:44, Neil Jenkins wrote:
As discussed in the meeting, to a rounding e= rror, no one writes sieve. Instead, clients present a GUI that generates si= eve in the background. The trouble is that different clients will support d= ifferent features and produce different sieve, not to mention going from th= e raw sieve back to the GUI building blocks is a hard task in itself, so I = struggle to see how this extension is going to lead to useful interoperabil= ity, unless you presume users only use one client and anything else is "her= e be dragons".

A JMAP extension for "rules" would be very useful if it could let mult= iple clients edit them=E2=80=A6 but whenever I've looked into trying to def= ine this, the differences in supported features between servers let alone c= lients is so huge it's seemed impossible to come up with anything likely to= be both useful and implemented.

Neil.
_______________________________________________
Jmap mailing list

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


--_----------=_153177188922026882-- From nobody Mon Jul 16 13:12: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 CD80E130DED for ; Mon, 16 Jul 2018 13:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=FM8KiAQP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VigUKEUQ 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 nOqgExLhse_B for ; Mon, 16 Jul 2018 13:12:50 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD044130DC2 for ; Mon, 16 Jul 2018 13:12:50 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3C5E7354 for ; Mon, 16 Jul 2018 16:12:50 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 16:12:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=rGIayCZqkWH0Xbu8eCMWAbz4tc5p90S0cLFfFO4DC 5c=; b=FM8KiAQPRuk8bLmMZABf3dsyrxBssgbjkmMBqKIxKYSO4tROA2ks158MS wM1uc1YAVsXQn4qyB8dPO5qkUBWCjWjiXISs3bVJCin/ejKDmo/nnSBp0cSnaKkL Iyul21xkMckHUFifPLtWDBrHgNe3GYKHLDrrH65TPCdT3uAzn5KoStXhQAf3/MpQ jUG/3vyOqEEFDYL1nFJFsfazd5lrLOlMXjQDeKfrReq+sfbuFmeuqOSZCj7Zzezz ljMHiUfVw3WS7fXUJ9tVvakt63DHquh2LHpS+BhfJcoHNPsF9XD/soIWBZg3pExv iToIDAgrYXzEpBq66fEihwAir4piQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=rGIayCZqkWH0Xbu8eCMWAbz4tc5p9 0S0cLFfFO4DC5c=; b=VigUKEUQmKmN4Nul2nvHvWqn3JpreNPwXPNXlRGIb/K7P oFK4O5pXmmwlYMQ1BUm5CK2qNkaoF8nPs2G1XRSvsUbvouuPk91dp5WnbImbDAle 0Lmn0plxKmcsh88wQ9pTyRhhOcQmY3K+iAXWyOD25sTyX+G8EEoQHzpazYqu58M3 Xn2vMxRXJq0FgW8eYJkB1fd4LT1As1H3tvR5U+9IMDYIQpvpo08yATgtRhUmr5eM lsVO8HsyATlQaCKRRbHhmxrdArupZe6pwRv8W+oom3zB3kvZJUpXh4BFtWmTtMX1 G/7wSjoKw0hZGCIhKY5hyxzeXim6ot8+OOyQFHBUQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7BD1C9E10A; Mon, 16 Jul 2018 16:12:49 -0400 (EDT) Message-Id: <1531771969.2203316.1442692336.1765438F@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153177196922033160" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 06:12:49 +1000 Archived-At: Subject: [Jmap] Address Groups - proposals X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 20:12:53 -0000 This is a multi-part message in MIME format. --_----------=_153177196922033160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" There's been a bunch of discussion both here, in the meeting today, and on Jabber. I figured I'd give them all catchy names and write up how they'd look for this theoretical header line: To: "First Person" , Friends: "My Friend" , another@example.com; second@example.com, "A Third person" , undisclosed-recipients:; *Flat no groups:* *lossy of group information * [ { name: "First Person", email: "first@example.com" }, { name: "My Friend", email: "friend@example.com" }, { name: null, email: "another@example.com" }, { name: null, email: "second@example.com" }, { name: "A Third person", email: "third@example.com" }, ] *Flat group names:* *lossy of empty groups and adjacent groups of same name * [ { name: "First Person", email: "first@example.com" }, { name: "My Friend", email: "friend@example.com", group: "Friends" }, { name: null, email: "another@example.com", group: "Friends" }, { name: null, email: "second@example.com" }, { name: "A Third person", email: "third@example.com" }, ] *Flat group names null: (like SQL left join) * *lossy of adjacent groups of same name* [ { name: "First Person", email: "first@example.com" }, { name: "My Friend", email: "friend@example.com", group: "Friends" }, { name: null, email: "another@example.com", group: "Friends" }, { name: null, email: "second@example.com" }, { name: "A Third person", email: "third@example.com" }, { name: null, email: null, group: "undisclosed-recipients" }, ] *Flat group names null numbered:* *full fidelity, no data loss. * [ { name: "First Person", email: "first@example.com" index: 0}, { name: "My Friend", email: "friend@example.com", group: "Friends", index: 1 },{ name: null, email: "another@example.com", group: "Friends", index: 1 },{ name: null, email: "second@example.com", index: 2 }, { name: "A Third person", email: "third@example.com", index: 2 }, { name: null, email: null, group: "undisclosed-recipients", index: 3 },] *Flat Implicit Group Markers: (null email for group markers) * *full fidelity, no data loss.* *CURRENT SPEC * [ { name: "First Person", email: "first@example.com" }, { name: "Friends", email: null }, { name: "My Friend", email: "friend@example.com" }, { name: null, email: "another@example.com" }, { name: null, email: null }, { name: null, email: "second@example.com" }, { name: "A Third person", email: "third@example.com" }, { name: "undisclosed-recipients", email: null }, { name: null, email: null }, ] *Flat Explicit Group Markers: (like XML SAX) * *full fidelity, no data loss.* [ { name: "First Person", email: "first@example.com" }, { name: "Friends", group: "start" }, { name: "My Friend", email: "friend@example.com" }, { name: null, email: "another@example.com" }, { name: "Friends", group: "end" }, { name: null, email: "second@example.com" }, { name: "A Third person", email: "third@example.com" }, { name: "undisclosed-recipients", group: "start" }, { name: "undisclosed-recipients", group: "end" }, ] (optional variant: null for name on end markers) *Nested Mixed: * *full fidelity, no data loss.* [ { name: "First Person", email: "first@example.com" }, { group: "Friends", addresses: [ { name: "My Friend", email: "friend@example.com" }, { name: null, email: "another@example.com" }, ] }, { name: null, email: "second@example.com" }, { name: "A Third person", email: "third@example.com" }, { group: "undisclosed-recipients", addresses: [] }, ] *Nested Full: * *full fidelity, no data loss.* { group: null, addresses: [ { name: "First Person", email: "first@example.com" }, ] }, { group: "Friends", addresses: [ { name: "My Friend", email: "friend@example.com" }, { name: null, email: "another@example.com" }, ] }, { group: null, addresses: [ [ { name: null, email: "second@example.com" }], [ { name: "A Third person", email: "third@example.com" }], ] }, { group: "undisclosed-recipients", addresses: [] }, *asGroupAddresses:* Two ways to get data - asAddresses is "Flat no groups", asGroupAddresses is "Nested Full". ============ I think that's every proposal that's out there. There's obviously pros and cons to all of them. We need to pick one. Ok - FIGHT! Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153177196922033160 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
There's been a bunch of discussion both here, in the meeting today, and on Jabber.  I figured I'd give them all catchy names and write up how they'd look for this theoretical header line:

To: "First Person" <first@example.com>, Friends: "My Friend" <friend@example.com>, another@example.com; second@example.com, "A Third person" <third@example.com>, undisclosed-recipients:;

Flat no groups:
lossy of group information

[
{ name: "First Person", email: "first@example.com" },
{ name: "My Friend", email: "friend@example.com" },
{ name: null, email: "another@example.com" },
{ name: null, email: "second@example.com" },
{ name: "A Third person", email: "third@example.com" },
]

Flat group names:
lossy of empty groups and adjacent groups of same name

[
{ name: "First Person", email: "first@example.com" },
{ name: "My Friend", email: "friend@example.com", group: "Friends" },
{ name: null, email: "another@example.com", group: "Friends" },
{ name: null, email: "second@example.com" },
{ name: "A Third person", email: "third@example.com" },
]

Flat group names null: (like SQL left join)
lossy of adjacent groups of same name

[
{ name: "First Person", email: "first@example.com" },
{ name: "My Friend", email: "friend@example.com", group: "Friends" },
{ name: null, email: "another@example.com", group: "Friends" },
{ name: null, email: "second@example.com" },
{ name: "A Third person", email: "third@example.com" },
{ name: null, email: null, group: "undisclosed-recipients" },
]

Flat group names null numbered:
full fidelity, no data loss.

[
{ name: "First Person", email: "first@example.com" index: 0},
{ name: "My Friend", email: "friend@example.com", group: "Friends", index: 1 },
{ name: null, email: "another@example.com", group: "Friends", index: 1 },
{ name: null, email: "second@example.com", index: 2 },
{ name: "A Third person", email: "third@example.com", index: 2 },
{ name: null, email: null, group: "undisclosed-recipients", index: 3 },
]

Flat Implicit Group Markers: (null email for group markers)
full fidelity, no data loss.

CURRENT SPEC

[
{ name: "First Person", email: "first@example.com" },
{ name: "Friends", email: null },
{ name: "My Friend", email: "friend@example.com" },
{ name: null, email: "another@example.com" },
{ name: null, email: null },
{ name: null, email: "second@example.com" },
{ name: "A Third person", email: "third@example.com" },
{ name: "undisclosed-recipients", email: null },
{ name: null, email: null },
]

Flat Explicit Group Markers: (like XML SAX)
full fidelity, no data loss.

[
{ name: "First Person", email: "first@example.com" },
{ name: "Friends", group: "start" },
{ name: "My Friend", email: "friend@example.com" },
{ name: null, email: "another@example.com" },
{ name: "Friends", group: "end" },
{ name: null, email: "second@example.com" },
{ name: "A Third person", email: "third@example.com" },
{ name: "undisclosed-recipients", group: "start" },
{ name: "undisclosed-recipients", group: "end" },
]

(optional variant: null for name on end markers)

Nested Mixed:
full fidelity, no data loss.

[
{ name: "First Person", email: "first@example.com" },
{ group: "Friends", addresses: [
  { name: "My Friend", email: "friend@example.com" },
  { name: null, email: "another@example.com" },
] },
{ name: null, email: "second@example.com" },
{ name: "A Third person", email: "third@example.com" },
{ group: "undisclosed-recipients", addresses: [] },
]

Nested Full:
full fidelity, no data loss.

{ group: null, addresses: [
  { name: "First Person", email: "first@example.com" },
] },
{ group: "Friends", addresses: [
  { name: "My Friend", email: "friend@example.com" },
  { name: null, email: "another@example.com" },
] },
{ group: null, addresses: [
  [ { name: null, email: "second@example.com" }],
  [ { name: "A Third person", email: "third@example.com" }],
] },
{ group: "undisclosed-recipients", addresses: [] },

asGroupAddresses:

Two ways to get data - asAddresses is "Flat no groups", asGroupAddresses is "Nested Full".

============

I think that's every proposal that's out there.  There's obviously pros and cons to all of them.  We need to pick one.

Ok - FIGHT!

Bron.

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


--_----------=_153177196922033160-- From nobody Mon Jul 16 13:39:17 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 C97261312AC for ; Mon, 16 Jul 2018 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=e+IV50Td; dkim=neutral reason="invalid (public key: not available)" header.d=rjbs.manxome.org header.b=Xz9YF1aV 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 mzAyI8FBDKCt for ; Mon, 16 Jul 2018 13:39:04 -0700 (PDT) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DE013128C for ; Mon, 16 Jul 2018 13:37:11 -0700 (PDT) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B783310094A; Mon, 16 Jul 2018 16:37:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :content-transfer-encoding:in-reply-to; s=sasl; bh=oqYOBPpteLlQf MR/LJgm2QHqpl0=; b=e+IV50TdxBdfxPUcb03O3ktbw4FaOMpmMX+5SYZfAJCrF C5g+NeIQPXi0XlVos1YULa7bGqn5vBJU0Pedu7zJ6p3HGvufxwNkTBbiH+2+zmNQ l9Br/kGvXo+c2+P0W4ZcfuhZbtG6bYdBN7aulq30+ZtlDyZD7NHEVGuJSgwyRg= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AE218100949; Mon, 16 Jul 2018 16:37:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=rjbs.manxome.org; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-transfer-encoding:in-reply-to; s=mesmtp; bh=FMN760g/MwwD/0LcBZWVNCo5eHAy4ou23n8yGJGhviU=; b=Xz9YF1aV6MCUuuQ5142cR1LOWT/1TLGjeLRIwaGmmDnrAclQIRlz96+kkhgu2Mrsu34W9BD/UZxPeyEeUfcqFrZlK2NvsY+r4FuPVvlV04KD5yvG0BM767rRvECsj9LYVnli4kqTS+75tgDC3Pe/8yp0btQ9aE/CXTQbyT3CSdE= Received: from carpenter.manxome.org (unknown [45.33.15.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 15642100948; Mon, 16 Jul 2018 16:37:09 -0400 (EDT) Received: by carpenter.manxome.org (Postfix, from userid 1000) id 072097FDEB; Mon, 16 Jul 2018 16:37:08 -0400 (EDT) Date: Mon, 16 Jul 2018 16:37:08 -0400 From: Ricardo Signes To: Bron Gondwana Cc: jmap@ietf.org Message-ID: <20180716203707.GA10650@debian> References: <1531771969.2203316.1442692336.1765438F@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1531771969.2203316.1442692336.1765438F@webmail.messagingengine.com> X-Message-Flag: Warning: Your computer is current broadcasting an IP address. X-Planet: Planet of the Apes User-Agent: Mutt/1.5.23 (2014-03-12) X-Pobox-Relay-ID: 02AECC9A-8938-11E8-9D59-063AD72159A7-07314517!pb-smtp1.pobox.com Archived-At: Subject: Re: [Jmap] Address Groups - proposals X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 20:39:14 -0000 * Bron Gondwana [2018-07-16T16:12:49] > There's been a bunch of discussion both here, in the meeting today, and > on Jabber. I figured I'd give them all catchy names and write up how > they'd look for this theoretical header line: Thanks for this! My thinking here is: 1. I love that JMAP makes working with email so approachable for non-domain experts. It's an easy to understand API, and you can get to work by us= ing it in a beginner's way before progressing, if ever, to more complex mod= es of operation. I want to build on this property of JMAP when possible. 2. I love that even for advanced operation, it is almost never necessary to resort to fetching the message/rfc822 blob. Most data is available in = raw or differently-processed forms. Even experts shouldn't have to resort = to blob processing most of the time. Mailbox groups are worth making available because of reason #2. Experts shouldn't have to get the raw header, encoded-warts and all, and work out t= he header structure. On the other hand, mailbox groups are rarely seen and even more rarely worth noting. The casual user can, I assert, pay them no mind. Groups should not complicate the life of the casual user. Providing a flat list is nice for the casual user, but if the flat list contains weird-o non-address sentinel values, *it's no longer a flat list*. It's a deeper structure that has been serialized into a flat list. I think it's worse for both sets of users: it's an unnatural expression of the structured data that an advanced user might want, and it's an unnatural expression of the simple data that a beginner might want. (I also think that in the simple case, any entry with a null email is not great.) This is why I think we're best off providing two distinct forms: one to provide the simplest form for 99.9% of input and for casual users, and one = with an appropriate data structure for those who care about group structure. I would suggest that :asAddresses does what Bron called "flat no groups", a= nd that :asGroupedAddresses does "nested full". I think that trying to be understandable is a good goal, but using a pre-existing IMAP convention that will be understandable to already-minted experts in IMAP is far less compelling to me than to simply be understandab= le by using a self-explanatory data structure. --=20 rjbs From nobody Mon Jul 16 15:09:56 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 007EC13127F for ; Mon, 16 Jul 2018 15:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUhnkPcXNwCo for ; Mon, 16 Jul 2018 15:09:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43355131265 for ; Mon, 16 Jul 2018 15:09:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUXZO6MN0G005OBH@mauve.mrochek.com> for jmap@ietf.org; Mon, 16 Jul 2018 15:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1531778678; bh=+y4SdBN4f1oULB7l1ASBLBET6Y4S4rB6t8PA0f6xYCg=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=NXliy3MQfZf3qJmo26vvQ1TfIVVBuPsh2jmYeYN1R/6uusO/P2KKujFeNasjsGX2M sYpnN2dzyFCzTT5J78/3xBPsnQh7yO4zcZAo3jOlD7djZkn7KUgnMEZtO8mnJbyk7u pwEeVLtJj6d0nw2PsEKsDzixu2zeeCwiAs+RKwSk= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUCIBNY1B4000051@mauve.mrochek.com>; Mon, 16 Jul 2018 15:04:36 -0700 (PDT) Cc: IETF JMAP Mailing List Message-id: <01QUXZO4QXIU000051@mauve.mrochek.com> Date: Mon, 16 Jul 2018 14:28:36 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Jul 2018 15:44:47 -0400" References: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> To: Neil Jenkins Archived-At: Subject: Re: [Jmap] Discussion of "MANAGESIEVE for JMAP" X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 22:09:53 -0000 > As discussed in the meeting, to a rounding error, no one writes sieve. This seems backwards to me: Lots of clients *write* sieve. (And I'm quite surprised at how well they do it - we rarely encounter syntax problems with generated sieves, and clients are actually pretty good at getting the quoting right in order to avoid injection attacks.) What clients don't do is *read* sieves. I've only found one implementation that did this, and I could never get it to work - although that was entirely a matter of it being browser-based thing that for whatever reason refused to load. What clients read instead is a set of rules, which may or may not be stored as part of the sieve. And there are also implementations that construct sieves as as side effect of a much more general business rules logic scheme. Not to be discounted are clients that let users write their own sieves. You may think this doesn't happen, but you'd be wrong - we have a number of sites that support it, including some very large ones. > Instead, clients present a GUI that generates sieve in the background. The > trouble is that different clients will support different features and produce > different sieve, not to mention going from the raw sieve back to the GUI > building blocks is a hard task in itself, so I struggle to see how this > extension is going to lead to useful interoperability, unless you presume users > only use one client and anything else is "here be dragons". Who says the purpose of the extension is necessarily to provide interoperability? Seems to me the main goal here is to make it possible to write reaosnable mail clients. Given how many clients support setting up and maintaining server-side rules, I don't think a system that fails to allow for this can be seen as anything other than deficient. > A JMAP extension for "rules" would be very useful if it could let multiple > clients edit them… but whenever I've looked into trying to define this, the > differences in supported features between servers let alone clients is so huge > it's seemed impossible to come up with anything likely to be both useful and > implemented. Well, I've heard tell of a mail filtering language, something called sieve, that probably could be prevailed upon to provide a subset of capabilities and associated semantics that would form the basis for a rule language. Or maybe that was just my imagination. Ned From nobody Mon Jul 16 15:24:49 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 D61951310A6 for ; Mon, 16 Jul 2018 15:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=oMYKaQUA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h1csMNJM 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 2IG8aRZaqDaK for ; Mon, 16 Jul 2018 15:24:44 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33CE130F09 for ; Mon, 16 Jul 2018 15:24:43 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 32858431 for ; Mon, 16 Jul 2018 18:24:43 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 18:24:43 -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=pelZHClvKDLt6sUQG xoI3kqsqnkKYPqLs/MDK57guVE=; b=oMYKaQUAYdKmP5ncfRVr/kQeJo5+Dvwl5 nZgTq/9R4/QSnQYc5TaJMwp7gifBEnYoLAYwiZONf/S3aD567o2BentbebE0SOfi /GwW+j8wPf+LZcw7JWiBfurbTo7BoZRMCyOCfp1CoLBlcGiL3A8vN9uWRgNdwuCU 0ndmfFdCCAbtz6KFWVjOCshc/ioeejNhLCYK2pVD3V1dd+vMnfUevWsb3dlT7sVn rkd1ExitGjQu25cBw5PktxfstaIElc8G83VHYjIN7alZjAqNdhszcEx6LaTMW30Q ZVF4lU0O5kOnqXwy6ZGXY0Le16FI7ILGpqoqyT/GxLl34B+pNZWow== 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=pelZHC lvKDLt6sUQGxoI3kqsqnkKYPqLs/MDK57guVE=; b=h1csMNJMiAPOxON1B+SPZZ GftAV9+348Gq0cxdfapMy4ICREptBJWy7hw0s2G9WEkfjSvJjxw7BNAtx+lhwBbV T9WeMUNdw3+Jb3GhL0Ba6+9X4CbjHs193gBae15vSWjTEYKTCTpsXMnIDNTQ+Y1i YGnoyWOjV+MM4apnXz7U46fn+IUaD6FVaDApRvzGFs/MYOsOTKpeD6BggUEB2vKe OzZw4sAzEldsHpUvPjUsWy+n+a4vNXFkRVjWaaI836oOwdGa32KXxxBMysM1/NVk Ngw+47y2Ww3cJhFsL2CMShfwOKHcrb6dtcgI+aeC43laXkEw6kDLLM3PnegiwkUw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 483AF9E10A; Mon, 16 Jul 2018 18:24:42 -0400 (EDT) Message-Id: <1531779882.3050382.1442873000.50CC0811@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153177988230503820" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 08:24:42 +1000 In-Reply-To: <01QUXZO4QXIU000051@mauve.mrochek.com> References: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> <01QUXZO4QXIU000051@mauve.mrochek.com> Archived-At: Subject: Re: [Jmap] Discussion of "MANAGESIEVE for JMAP" X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 22:24:48 -0000 This is a multi-part message in MIME format. --_----------=_153177988230503820 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Am I reading a volunteering to write a Sieve JMAP extension? Bron. On Tue, Jul 17, 2018, at 07:28, Ned Freed wrote: >> As discussed in the meeting, to a rounding error, no one >> writes sieve.>=20 > This seems backwards to me: Lots of clients **write** sieve. (And > I'm quite> surprised at how well they do it - we rarely encounter syntax > problems with> generated sieves, and clients are actually pretty good at = getting > the quoting> right in order to avoid injection attacks.) >=20 > What clients don't do is **read** sieves. I've only found one > implementation that> did this, and I could never get it to work - althoug= h that was > entirely a> matter of it being browser-based thing that for whatever rea= son > refused to> load. >=20 > What clients read instead is a set of rules, which may or may not > be stored> as part of the sieve. And there are also implementations that > construct> sieves as as side effect of a much more general business rules > logic scheme.>=20 > Not to be discounted are clients that let users write their own > sieves. You may> think this doesn't happen, but you'd be wrong - we have = a number of > sites that> support it, including some very large ones. >=20 >> Instead, clients present a GUI that generates sieve in the >> background. The>> trouble is that different clients will support differe= nt features and >> produce>> different sieve, not to mention going from the raw sieve back = to >> the GUI>> building blocks is a hard task in itself, so I struggle to see >> how this>> extension is going to lead to useful interoperability, unless= you >> presume users>> only use one client and anything else is "here be dragon= s". >=20 > Who says the purpose of the extension is necessarily to provide > interoperability? Seems to me the main goal here is to make it > possible to> write reaosnable mail clients. Given how many clients support > setting up> and maintaining server-side rules, I don't think a system tha= t fails > to allow> for this can be seen as anything other than deficient. >=20 >> A JMAP extension for "rules" would be very useful if it could let >> multiple>> clients edit them=E2=80=A6 but whenever I've looked into tryi= ng to define >> this, the>> differences in supported features between servers let alone = clients >> is so huge>> it's seemed impossible to come up with anything likely to b= e both >> useful and>> implemented. >=20 > Well, I've heard tell of a mail filtering language, something > called sieve,> that probably could be prevailed upon to provide a subset = of > capabilities> and associated semantics that would form the basis for a ru= le > language.>=20 > Or maybe that was just my imagination. >=20 > Ned >=20 > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153177988230503820 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Am I reading a volunteering to writ= e a Sieve JMAP extension?

Bron.

On Tue, Jul 17, 2018, at 07:28, Ned Freed wrote:
As discussed in the meeting, to = a rounding error, no one writes sieve.

This seems backwards to me: Lots of clients *write* sieve. (And= I'm quite
surprised at how well they do it - we rarely encounter syntax problems= with
generated sieves, and clients are actually pretty good at getting the = quoting
right in order to avoid injection attacks.)

What clients don't do is *read* sieves. I've only found one imp= lementation that
did this, and I could never get it to work - although that was entirel= y a
matter of it being  browser-based thing that for whatever reason = refused to
load.

What clients read instead is a set of rules, which may or may not be s= tored
as part of the sieve. And there are also implementations that construc= t
sieves as as side effect of a much more general business rules logic s= cheme.

Not to be discounted are clients that let users write their own sieves= . You may
think this doesn't happen, but you'd be wrong - we have a number of si= tes that
support it, including some very large ones.

Instead, clients present a GUI that generates sieve in the= background. The
trouble is that different clients will support different features and = produce
different sieve, not to mention going from the raw sieve back to the G= UI
building blocks is a hard task in itself, so I struggle to see how thi= s
extension is going to lead to useful interoperability, unless you pres= ume users
only use one client and anything else is "here be dragons".

Who says the purpose of the extension is necessarily to provide
interoperability? Seems to me the main goal here is to make it possibl= e to
write reaosnable mail clients. Given how many clients support setting = up
and maintaining server-side rules, I don't think a system that fails t= o allow
for this can be seen as anything other than deficient.

A JMAP extension for "rules" would be very useful if it co= uld let multiple
clients edit them=E2=80=A6 but whenever I've looked into trying to def= ine this, the
differences in supported features between servers let alone clients is= so huge
it's seemed impossible to come up with anything likely to be both usef= ul and
implemented.

Well, I've heard tell of a mail filtering language, something called s= ieve,
that probably could be prevailed upon to provide a subset of capabilit= ies
and associated semantics that would form the basis for a rule language= .

Or maybe that was just my imagination.

Ned

_______________________________________________
Jmap mailing list

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


--_----------=_153177988230503820-- From nobody Mon Jul 16 15:36:15 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 B627A131243 for ; Mon, 16 Jul 2018 15:36:14 -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=DXzWH0se; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MgTN293X 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 GK9KnkP91j6M for ; Mon, 16 Jul 2018 15:36:13 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73A913123F for ; Mon, 16 Jul 2018 15:36:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 046F33B4; Mon, 16 Jul 2018 18:36:12 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 16 Jul 2018 18:36:13 -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=fm3; bh=SxWm3qPZoCGlK5UMZUSOlVNZc7P/cRFHyWdEubRDk Rg=; b=DXzWH0se5s74f9ytzz6uGybKUELIU/ofUGcnNh2GPYV6mzmORDZ/MNNIv eS2hYK6znqd0OOEJ9VTHaivz5BNpRFFHrZfYY8yggnJ0bGOKCjieJccNgdE4VY19 JfhTv4O3TPi3fddVLQl4vh9m0AwF88tewqiHNBC0KWzZ/Wyj3dIvy5sT9bBwNFdq NkP8julG24bHwkesApplX57XmAdd20BKf+QZn7/gFmTSI05qQ7NzutuZFc+kCVTv clwbJJzX2kmLf1PBe2VaNmd6c5PkuuAT3o0AXltXOeC1BGs60oCqPzL8EpR9vN29 5TZIkfWbSFlUG2OB3wxM6NQpDPCOg== 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=SxWm3qPZoCGlK5UMZUSOlVNZc7P/cRFHyWdEubRDk Rg=; b=MgTN293XBF4TcebepCeSTZKuQYmqQ9dVbdGVa/0cOOwlI/owOj04TVe8G QlBsHnq+CDOzpOBQLxVWxy05ZLn7Z6gbSs9xjdrJsrpVSg2GyH1ZL/D9j68h+wV5 x8eEn45PcRldonBTO/MhimgTHYkxnFQCCzrgG1ydEQoIE+oHfnx/RbPK9dkrrYhj oVwuTp4n1KyvkJpIsO3asfGMAmGlDdxb9EMev5EBK4wWeneUSTy/Dswd6GCRH88H hyOIOycjo2qQsG+cTpa+eGVN+N1YVLg2hSkt/4t0ZRUDw5FxlLlDJr+VmBUcX8gn 2DITPyLc6M7Mju6JH9T3QXejLuWpg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2816AF114; Mon, 16 Jul 2018 18:36:12 -0400 (EDT) Message-Id: <0a651f4c-6c12-4305-8cc4-2fcd6a0e4ed8@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.4-437-gcc1b3ff-fmnext-20180712v2 x-jmap-identity-id: 64588216 In-Reply-To: <01QUXZO4QXIU000051@mauve.mrochek.com> References: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> <01QUXZO4QXIU000051@mauve.mrochek.com> Date: Mon, 16 Jul 2018 18:36:11 -0400 From: Neil Jenkins To: Ned Freed Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=f32d39fca21b4319893283a4aab22ce3 Archived-At: Subject: Re: [Jmap] Discussion of "MANAGESIEVE for JMAP" X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 22:36:15 -0000 --f32d39fca21b4319893283a4aab22ce3 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, 17 Jul = 2018, at 8:09 AM, Ned Freed wrote:
This seems backwards to me: Lots of clients *w= rite* sieve.

Yes. Sorry if I w= as not clear: I was saying few people write sieve directly themselves.

=
Not to be discounted are clients that let users write their own si= eves. You may
think this doesn't happen, but you'd be wron= g - we have a number of sites that
support it, including s= ome very large ones.

Oh, I'm a= ware this happens=E2=80=94we support this ourselves at FastMail=E2=80=94= but in terms of being a useful problem to solve, allowing clients to sup= port a GUI for configuring rules on the server is much more useful than = offering a text box for users to type in sieve.

Who says the purpose o= f the extension is necessarily to provide
interoperability= ?

Well, generally interoperabi= lity is one of the reasons we define standards. If a user with multiple = clients (which is pretty common) finds they either show different sets o= f rules, or worse(?), overwrite each other's rules, I suspect they will = find this confusing and consider it broken behaviour. With my service pr= ovider hat on, I do not look forward to dealing with those support ticke= ts.

Neil.
--f32d39fca21b4319893283a4aab22ce3 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 17 Jul 2018, at 8:09 AM, Ned Freed wrote: > This seems backwards to me: Lots of clients *write* sieve. Yes. Sorry if I was not clear: I was saying few people write sieve direc= tly themselves. > Not to be discounted are clients that let users write their own sieve= s. You may > think this doesn't happen, but you'd be wrong - we have a number of si= tes that > support it, including some very large ones. Oh, I'm aware this happens=E2=80=94we support this ourselves at FastMail= =E2=80=94but in terms of being a useful problem to solve, allowing clien= ts to support a GUI for configuring rules on the server is much more use= ful than offering a text box for users to type in sieve. > Who says the purpose of the extension is necessarily to provide > interoperability? Well, generally interoperability is one of the reasons we define standar= ds. If a user with multiple clients (which is pretty common) finds they = either show different sets of rules, or worse(?), overwrite each other's= rules, I suspect they will find this confusing and consider it broken b= ehaviour. With my service provider hat on, I do not look forward to deal= ing with those support tickets. Neil. --f32d39fca21b4319893283a4aab22ce3-- From nobody Mon Jul 16 16:13:35 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7241311FB for ; Mon, 16 Jul 2018 16:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, URIBL_BLOCKED=0.001] 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 Np0DyGZGjC0H for ; Mon, 16 Jul 2018 16:13:31 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 6AB9713114C for ; Mon, 16 Jul 2018 16:13:31 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6GN9COH194710 for ; Mon, 16 Jul 2018 23:13:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : mime-version : content-type; s=corp-2018-07-02; bh=2dAA0vv+kF+RYvUGwsYus0f0Fm81LYh6IkeYnaeNZlo=; b=rVE+b5/xxQipj3TOiJwrZm814+ccBSXA0j0R6sknofl1NjFvJZtftQeqd2yi+m+VQ4C+ T0gU34gDdHILyUXCj/IgJpZ+4VTSF/abGNw2QblewYx6XpNfs6vHI6yX+emxpeE+oZ0A Cg1qme2W9b+uX47WGq2i7vm4U+bpBRTzV8ESbOTEsS1PZrXEpHw4Vi1qvB4xZMLTxrfF ZvGV5nEAXC6OCiJh7XL+O7yo5h6va3SEUvpCiEpzFLgNP21pFqWOA1tDGqACPbeCljVF 70JaxXgYm2r8neW3hwcHsgkb2ACa0IK/+JAHH1PmVlD3htEiVRvxk/Vi5cKiNeUt0+Uo vw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2k7a3jpera-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 16 Jul 2018 23:13:30 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6GNDTiq025820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 16 Jul 2018 23:13:29 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6GNDTCr015852 for ; Mon, 16 Jul 2018 23:13:29 GMT Received: from [31.133.140.238] (/31.133.140.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jul 2018 16:13:29 -0700 From: "Chris Newman" To: "IETF JMAP Mailing List" Date: Mon, 16 Jul 2018 19:13:26 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <10C47D45-8263-4271-AB44-7D24EBAF8417@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8956 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=909 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807160256 Archived-At: Subject: [Jmap] First cut at error codes registry X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 23:13:34 -0000 Here's my initial pull request for an error code registry for JMAP core: https://github.com/jmapio/jmap/pull/246 Issues I encountered: 1. The naming convention for HTTP-level errors (all lower case) and method-level errors (camelCase) is different. It looks weird with a combined registry. I prefer a combined registry to avoid error naming overlap based on scope (and to simplify the text). Should we make the method-level errors camel case, or is the difference deliberate? 2. Each error is used in one or more object types (e.g. JMAP Error object, JMAP SetError object) and may or may not be method-specific. Should I try to add a column to the registry to distinguish where an error is used, or should I keep the registry simpler? If you prefer another column, suggested text would be appreciated. Feel free to comment here or on the PR. Thanks for feedback, - Chris From nobody Mon Jul 16 18:16:34 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 94A69130EBD for ; Mon, 16 Jul 2018 18:16: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, FREEMAIL_FROM=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=fastmail.com header.b=G1ak2Uxy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D7s0unaY 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 UXhwL5rkxyOb for ; Mon, 16 Jul 2018 18:16:28 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF6C130E7B for ; Mon, 16 Jul 2018 18:16:28 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id A6AD5153A for ; Mon, 16 Jul 2018 21:16:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 16 Jul 2018 21:16:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= 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=UPoUHGo53XqjzwQWKWPL9IR3iZZDi7GPWUKj1ixHweU=; b=G1ak2Uxy GpWZBT8wo6Gb9BPf8IAQ32rlR4cugCNSzOMpOOlIhXweyUeMpAM15VmtEFcFAMzw gkMY/HhWdVlIOBexx9MveVqmXwqvZ2CG/uNnud+L7tid/PAwu3PjE5MDGWZTD+6p 4V+eeyz4O+fmpbYcSELOpKvypMlftS0nxfb9ZvCxAjXHUV7r2eh+3rsb4U3nWEWH 9eMXmn8wWgb4S3DwADMZCvhO8XF92LwtinGBqv8PfH4witl7dxf9C4JEUcwX9ln1 bxRxGUUXvFIg/2qLlj4q+OrNGc0t8QM2LljRligYgiJSwXghyluwjMuO5PQm1vJ8 kkSGvhzGliRiig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=UPoUHGo53XqjzwQWKWPL9IR3iZZDi 7GPWUKj1ixHweU=; b=D7s0unaYsuGPtHPPnlAZ7QMXIk66hqcraVqOCb+fCRsse nGzcanxXTKUh+il/C/tcn8dyDKBF3P7BXd8E01sbRGU2HLdwBKqkbE3iASTwMXcA lcCH7rV1sIPh0qb35WfPxFd+V52E8FJVRUOpbkMd4dPPtTjMWkO631GXSmGT8Jxw iiEkkbUZT7hH6Esl3ZFpV/F5VoM1e6TW/id5u/P/cUSia+0n34OQG0trqGFNhQqf 6y/ekBCreBeStSGIXw5z8xlA3fIo0I4y/TUhTBSs7SCfsCS3R0LXjiaqgswNqqcn t3eFUs/TGFQeKfRg01xu8fmIlElq9nB6HD2twaBgA== X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (bas2-montreal42-64-229-100-59.dsl.bell.ca [64.229.100.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 51ACCE4314 for ; Mon, 16 Jul 2018 21:16:27 -0400 (EDT) To: jmap@ietf.org References: <10C47D45-8263-4271-AB44-7D24EBAF8417@oracle.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Mon, 16 Jul 2018 21:16:26 -0400 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: <10C47D45-8263-4271-AB44-7D24EBAF8417@oracle.com> Content-Type: multipart/mixed; boundary="------------65C39D625D40871DB25B5DEC" Content-Language: en-US Archived-At: Subject: Re: [Jmap] First cut at error codes registry X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 01:16:32 -0000 This is a multi-part message in MIME format. --------------65C39D625D40871DB25B5DEC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07/16/2018 07:13 PM, Chris Newman wrote: > Here's my initial pull request for an error code registry for JMAP core: > >  https://github.com/jmapio/jmap/pull/246 > > Issues I encountered: > > 1. The naming convention for HTTP-level errors (all lower case) and > method-level errors (camelCase) is different. It looks weird with a > combined registry. I prefer a combined registry to avoid error naming > overlap based on scope (and to simplify the text). Should we make the > method-level errors camel case, or is the difference deliberate? I vote for making the HTTP-level errors camelCase as well. > 2. Each error is used in one or more object types (e.g. JMAP Error > object, JMAP SetError object) and may or may not be method-specific. > Should I try to add a column to the registry to distinguish where an > error is used, or should I keep the registry simpler? If you prefer > another column, suggested text would be appreciated. I  have no string opinion on this issue. -- Ken Murchison Cyrus Development Team FastMail US LLC --------------65C39D625D40871DB25B5DEC Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------65C39D625D40871DB25B5DEC-- From nobody Mon Jul 16 20:39: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 97F4A130E95 for ; Mon, 16 Jul 2018 20:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 U6O75bQVEGP8 for ; Mon, 16 Jul 2018 20:39:53 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12ED130DEF for ; Mon, 16 Jul 2018 20:39:53 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6H3dPaX172213; Tue, 17 Jul 2018 03:39:47 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; s=corp-2018-07-02; bh=nqdd7P5w3Cp6HPSrsO2y7JzRrIXUzk8aC093DNcDipY=; b=h5GYjPtS4Z5uGSD2wc3JZEuofGAzT2q6rgxFhl3xTM0kgCsZS2z68oWCuQyfweslSw62 Nl0Sfy3m2qyB2KuK7Lmm2OIcH5i/1NY+7/PYwSlb3WpHc5hQLm8ozxV99kX2JSIxK5uD EggpcbVu5UhCJoymtrUsg2Ml7CfKQnUGaBdAjYSHHG6AcLjDeQzTvG4/o8fL9mFAcDr4 Yq1RSqUKB/vfkxlvYIT9YPJ1DLjww00tKFEMPnlc+ovVDmBiLn3cQRNhp35Qn6fBHCAH Xvgo9SXwbbdT5p0gspmyNKzPMW2ux6EX9gk4IV8qcngoZUgm2QNn84d4mjVlfhlNOhMO rQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2k7a3t6wyr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Jul 2018 03:39:47 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6H3dkPQ024516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Jul 2018 03:39:46 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6H3djFX026678; Tue, 17 Jul 2018 03:39:46 GMT Received: from [172.20.10.81] (/66.171.169.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jul 2018 20:39:45 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: jmap@ietf.org Date: Mon, 16 Jul 2018 23:39:42 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> References: <1531769208.2184720.1442678728.4E169FA0@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D1E72259-D777-43E0-A6BD-0E3A6B02E572_=" Embedded-HTML: [{"HTML":[3419, 1792], "plain":[1909, 885], "uuid":"93CD35FE-23F3-4183-99CB-0BE0A6477715"}] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8956 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807170034 Archived-At: Subject: Re: [Jmap] Discussion of "MANAGESIEVE for JMAP" X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 03:39:57 -0000 --=_MailMate_D1E72259-D777-43E0-A6BD-0E3A6B02E572_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable I think there is good reason to believe that Managesieve's semantics for = multiple Sieves will result in usability problems if multiple clients = access Managesieve for the same user. Interesting question: could we = come up with a reasonably simple model that allows clients to: 1. offer = a GUI that generates a Sieve, and 2. be aware of other generated Sieves = in such a way that the least astonishment principle is not violated. Here's a strawman: A client can upload a Sieve script but there is mandatory metadata as = follows: 1. a human description of the client that generated the Sieve that's = useful to provide end-user context. 2. a flag indicating if the client generates "concatenation-friendly" = Sieves (let's not worry the technical details of that yet). 3. a textual description of what the filter does intended to be read by = an end user (likely needs at least line breaks and indenting). (maybe = also a 1-liner or title for the Sieve) 4. enable/disable flag If a concatenation-hostile Sieve is on the server, there's only one = Sieve allowed. If another client wants to set rules it can offer the = user the option to delete the Sieve created by client X that does Y = (since X & Y are mandatory metadata). Multiple Sieves are allowed if they are all concatenation-friendly. When multiple sieves are present, the order the sieves run in is = settable by the client. Disabled Sieves don't run but do participate in = the ordering. So a minimal JMAP-sieve client generates a concatenation hostile Sieve = with mandatory metadata and will offer to delete all server-side Sieves = (with presentation of the metadata) if there are any. A better JMAP-sieve client will generate concatenation-friendly Sieves = and can offer a GUI to reorder and enable/disable the Sieves (including = ones by other clients). Ok, strawmen are meant to be bashed so bash away... - Chris On 16 Jul 2018, at 15:26, Bron Gondwana wrote: > This was the extension discussion for sieve. The discussion in the > room covered: > * Full sieve support is common on servers, but rare in clients > * Do we want to support all of sieve, or just a subset? (if so, how = > do > we decide what subset? How do we update with future sieve > extensions?)* how does this interact with the vacation support in = > the mail spec? > > My suggestion is that we start with an extension for full sieve, and > maybe propose a way to manage a more limited file as well. The key > question here would be whether we transport sieve scripts as a blob of > raw text, or whether we define a "sieve as JSON" mapping. > Next steps: > > * What's the scope of what we want to do? (managesieve inside JMAP / > sieve as JSON / limited subset)* Who wants to author a spec? > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > _______________________________________________ > 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=3D27Vu7AQgrnPiwFD0= 8DlPCM_c_FE68RWdyBCpytmUuxY&s=3DrbZUMaAM-FCuKja2ekQGKYSHjLneRGhJEDkjwC9Sa= -E&e=3D --=_MailMate_D1E72259-D777-43E0-A6BD-0E3A6B02E572_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I think there is good reason to = believe that Managesieve's semantics for multiple Sieves will result = in usability problems if multiple clients access Managesieve for the same= user. Interesting question: could we come up with a reasonably simple mo= del that allows clients to: 1. offer a GUI that generates a Sieve, and 2.= be aware of other generated Sieves in such a way that the least astonish= ment principle is not violated.

Here's a strawman:
A client can upload a Sieve script but there is mandatory metadata as fol= lows:
1. a human description of the client that generated the Sieve that's = useful to provide end-user context.
2. a flag indicating if the client generates "concatenation-friendly= " Sieves (let's not worry the technical details of that yet). 3. a textual description of what the filter does intended to be read by a= n end user (likely needs at least line breaks and indenting). (maybe also= a 1-liner or title for the Sieve)
4. enable/disable flag

If a concatenation-hostile Sieve is on the server, there&= #39;s only one Sieve allowed. If another client wants to set rules it can= offer the user the option to delete the Sieve created by client X that d= oes Y (since X & Y are mandatory metadata).

Multiple Sieves are allowed if they are all concatenation= -friendly.

When multiple sieves are present, the order the sieves ru= n in is settable by the client. Disabled Sieves don't run but do part= icipate in the ordering.

So a minimal JMAP-sieve client generates a concatenation = hostile Sieve with mandatory metadata and will offer to delete all server= -side Sieves (with presentation of the metadata) if there are any.

A better JMAP-sieve client will generate concatenation-fr= iendly Sieves and can offer a GUI to reorder and enable/disable the Sieve= s (including ones by other clients).

Ok, strawmen are meant to be bashed so bash away...

- Chris

On 16 Jul 2018, at 15:26, Bron Gondwana wrote:

This was the extension discussion for s= ieve.  The discussion in the room covered:

* Full sieve support is common on serve= rs, but rare in clients
* Do we want to support all of sieve, o= r just a subset?  (if so, how do we decide what subset?  How do= we update with future sieve extensions?)
* how does this interact with the vacat= ion support in the mail spec?

My suggestion is that we start with an = extension for full sieve, and maybe propose a way to manage a more limite= d file as well.  The key question here would be whether we transport= sieve scripts as a blob of raw text, or whether we define a "sieve as JS= ON" mapping.

Next steps:

* What's the scope of what we want to d= o?  (managesieve inside JMAP / sieve as JSON / limited subset)
* Who wants to author a spec?
=

Bron.

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


________________________________= _______________
Jmap mailing list
Jmap@ietf.org
https://urldefense.proofpoint.c= om/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jmap&d=3DDwICAg= &c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3= rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3D27Vu7AQgrnPiwFD08DlPCM_c_FE68RWdy= BCpytmUuxY&s=3DrbZUMaAM-FCuKja2ekQGKYSHjLneRGhJEDkjwC9Sa-E&e=3D

--=_MailMate_D1E72259-D777-43E0-A6BD-0E3A6B02E572_=-- From nobody Tue Jul 17 06:42:31 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 E698712D7F8 for ; Tue, 17 Jul 2018 06:42:28 -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=V5B9Amv1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ag41booF 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 dke5P_bV49rR for ; Tue, 17 Jul 2018 06:42:27 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3101C130EAC for ; Tue, 17 Jul 2018 06:42:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 635CF2BA; Tue, 17 Jul 2018 09:42:26 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 17 Jul 2018 09:42:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=hQFtvv 28y7qa7T5uVQrqa5q5sJN37jZkB/8o7gddgB0=; b=V5B9Amv1gyaJ7TjQfVrR8k cx0sYqgpyrTmRLAEqLLvHhoga2s+29A34YysZjUv0Qie2yupVRTHBqlZpyTFDSEQ srchvZ8VUJy0OZya9gjrhPKfcf9Osi57ETWXWmN1sCLyVSqqb0sCpkpELT/d/vQ8 66wD8HIK14ltdXyrurVAF0C+7mIBoiMRojk9D2Qm5/MIaylmMWH2rfpMgOYPxJwn 6RKZaK78i9pvD6WzWKnyrjqEiLi+B6xeF92d3ijwq+hWyRLSOYDOfs5gfZZq1MdU NSCo4+6xRvXiU2wUnX8nva35TWNkSbCp/n7quN6Znv0SGM/uYXKa1/p3fqNJ33ug == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=hQFtvv 28y7qa7T5uVQrqa5q5sJN37jZkB/8o7gddgB0=; b=ag41booFGPRAv/OSb+yvMP 32lXDZmzBFmy51eVUvOYE5CyH7/VvsAJyt30FInbJQCHtKbAWMIpvRWJRkotVOTi Z2sd1/irL8ozlaQZp3Vwg92G8Wwa8jVeOLmSEhbKCMuP2a1EzGa/g1Ta1bfY06w2 Chddp0SoXrj10lGHB4MwyjvONUuaqt/XoqggoHZe/JtjjWFdeEIO8jhO7/3bOMZ2 94jLU1l2l/hx9AuEeN5VmYr5vckKpXqZmLZ3bb3XS2n5Bp0xU35NnKnZ7fj7F/+w 9Co1f9xLIovUgFkCmGFgJQMxfA3oZU1jhLL5O5USk8lm9EGWzFC2ruhc+aF64D2g == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A12EA42A9; Tue, 17 Jul 2018 09:42:25 -0400 (EDT) Message-Id: <1531834945.609135.1443581368.51723A74@webmail.messagingengine.com> From: Bron Gondwana To: Raphael OUAZANA Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15318349456091350" X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa Date: Tue, 17 Jul 2018 23:42:25 +1000 References: <1531769326.2185479.1442690368.32F5133D@webmail.messagingengine.com> <44ff046a19ba15a4bbe0f59c472a298f@linagora.com> In-Reply-To: <44ff046a19ba15a4bbe0f59c472a298f@linagora.com> Archived-At: Subject: Re: [Jmap] MDN extension - call for author! X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:42:29 -0000 This is a multi-part message in MIME format. --_----------=_15318349456091350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" That's fantastic. Thank you. Looking forward to it. Please let us know if you need and help getting started. Cheers, Bron On Tue, Jul 17, 2018, at 23:40, Raphael OUAZANA wrote: > Hi, >=20 > Le 2018-07-16 21:28, Bron Gondwana a =C3=A9crit : >> Hi all, >>=20 >> We agreed in today's meeting that we want to create an extension for>> c= reating MDNs via JMAP. We need somebody to champion this and author>> the = extension. Please make an orderly line in the replies. >=20 > I'm volunteer to author it. I think I will need a mentor as > this will be> my first contribution to an IETF process. >=20 > Regards, > Rapha=C3=ABl Ouazana. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15318349456091350 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
That's fantastic. Thank you. Lookin= g forward to it. Please let us know if you need and help getting started.

Cheers,

Bron


On Tue, Jul 17, 2018, at 23:40, Raphael OUAZANA wrote:
Hi,

Le 2018-07-16 21:28, Bron Gondwana a =C3=A9crit :
Hi all,

We agreed in today's meeting that we want to create an extension for
creating MDNs via JMAP.  We need somebody to champion this and au= thor
the extension.  Please make an orderly line in the replies.

I'm volunteer to author it. I think I will need a mentor as this will = be
my first contribution to an IETF process.

Regards,
Rapha=C3=ABl Ouazana.

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

--_----------=_15318349456091350-- From nobody Tue Jul 17 07:00:54 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 BC501130E58 for ; Tue, 17 Jul 2018 06:41:11 -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_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=DzEDCu4V; dkim=pass (2048-bit key) header.d=linagora.com header.b=MwdMk25u 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 XwfQH19aDDjM for ; Tue, 17 Jul 2018 06:41:09 -0700 (PDT) Received: from e1i145.smtp2go.com (e1i145.smtp2go.com [103.36.108.145]) (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 61589130DC7 for ; Tue, 17 Jul 2018 06:41:09 -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:Message-ID:Subject:To: From:Date:Reply-To:Sender:List-Unsubscribe; bh=LsxOwvNSEeaWTEXb7xBNYLRy5NeOUtYD0K65ta4k2RM=; b=DzEDCu4VDbss4826YNW6DpOMQQ DkckMOiHkwmdBEfeuy8mnnvtqLSN8dgy2om3lABrO25B2qLv8KQ9/HnEKeCAQUw5wQ02AG5rK1cbw w9eg/jP/eyquP0gN55GyFl+vHoXgB0DjurV/xTDOkEpxuRTsAkeUKpcYLLtF1TU94nmKTCsPcQnBd xg5Q3pv6di6YiipzQR+2u/5jBRHxUH2W9H9YDRYvqDGmO9XM9xURo+hQcyCJUoGtrVSRZoWjI6b4N QJXunsPKn1J+8/3R2JeR8bNpnFczmgkS7OkPYSaiI+jTkP1uJ7P63hDtqN8+l7Mqf50snYmmrMuJP oFP8x9ug==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linagora.com; i=@linagora.com; q=dns/txt; s=s266739; t=1531834869; h=from : subject : to : message-id : date; bh=LsxOwvNSEeaWTEXb7xBNYLRy5NeOUtYD0K65ta4k2RM=; b=MwdMk25u1JoLgjrA8kHWEGdsecBlBZoJZ0S5aL1NpOUy+sCVCYDLaWyaALnXyBvZPL2nQh Aozmc+NHR73tqYzPtZfJVT5VAK0ePhsIEKCC2dI3X2XNi3FoJKaUOXppuw/FZqXLyMse6i9C pl+3fG2Bg3RPPJa9/nANTcjXm21AEB0pXAq++51RchlMnRm63YooeUxeO6e05sHJ3AqB+7q4 8me7ecnGsYnJAGS1jtwAUWfVDbAYDCetcYxV8D1lQfRiseMBlvs+KWiruka9AyCElJUd4JBx ppPCPBkGvQ55MyI6bw6QXbGtFKMTh6yKNI4dASfY02xBbLB3o9Yfqc4g== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 17 Jul 2018 15:40:58 +0200 From: Raphael OUAZANA To: Bron Gondwana Cc: jmap@ietf.org In-Reply-To: <1531769326.2185479.1442690368.32F5133D@webmail.messagingengine.com> References: <1531769326.2185479.1442690368.32F5133D@webmail.messagingengine.com> Message-ID: <44ff046a19ba15a4bbe0f59c472a298f@linagora.com> X-Sender: raphael.ouazana@linagora.com User-Agent: Roundcube Webmail/1.1.4 X-Smtpcorp-Track: 1ffQDswSET0IDQ.TlHIx23W2 Feedback-ID: 266739m:266739aja3LFS:266739swEPBqJLsX:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to Archived-At: X-Mailman-Approved-At: Tue, 17 Jul 2018 07:00:52 -0700 Subject: Re: [Jmap] MDN extension - call for author! X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:41:12 -0000 Hi, Le 2018-07-16 21:28, Bron Gondwana a écrit : > Hi all, > > We agreed in today's meeting that we want to create an extension for > creating MDNs via JMAP. We need somebody to champion this and author > the extension. Please make an orderly line in the replies. I'm volunteer to author it. I think I will need a mentor as this will be my first contribution to an IETF process. Regards, Raphaël Ouazana. From nobody Mon Jul 23 03:27:28 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 6B96C130E4B for ; Mon, 23 Jul 2018 03:27:27 -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=iqvFnEep; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qJq5r7Js 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 N0bZAKfvi_R6 for ; Mon, 23 Jul 2018 03:27:26 -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 895FA130E52 for ; Mon, 23 Jul 2018 03:27:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F3C2921BD5 for ; Mon, 23 Jul 2018 06:27:24 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 23 Jul 2018 06:27:24 -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=GlgrILmEHq2fu5Pdp28oGq3WwFjsShQo/cHJtauv6 /c=; b=iqvFnEeppaWSxG8vRgk4tQzT2306vo/EmszUlXIFZemC7c0QRndCppSZx 7QKwSPv6iXQXxNYt1PBcTwsJGeA7zjqIpqzjwdCbjmEtqJmCzzIGHBe6khaSRJcE 3wX+DldK92v7uvhIYLBzbXDEliRdc+zZnRn3Foxi8f1QCHNwM5k8xJwQoXHZ28qW VmjzX2/XdjG1sL/65Y50Gk4ncyt0bkjtTbTADY60hWu6XuDEByZH7lSBeVSy7lWJ ajjZQ0Fz94/S1tfOgb6gtlNLvy4Vt0HahHxhobpdvDNnm6eR0om1ihDQThs4hikj 8o2z2hdO5c8D+sMFAxz07U4dvrTDA== 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=GlgrILmEHq2fu5Pdp28oGq3WwFjsShQo/cHJtauv6 /c=; b=qJq5r7JsZNkWZQVkQdgO8DP/IC0+dtmV22nlZl/BAWx4l3iDz/O70aP4f SyRBtOssf8SsSi0nwQDfWTHqe4L+OYKKDhdLxkISczlTXHyNM+Z25/OFEH5gn7QM 8aC0KRsmT2XESzue2TCuV/kDikZzKp4/bYGjdbh6xrtAqE43aSuRq1Sb1Um/DTom 8ExPlgYG6ba8EMEP5MHQQ7oAUzi1BwTD/unCUY05g1nV2sjypZHE9jjr039sI1Xq 5aqvJug0pUqz1UgXjOFy7FrDCe2h9VTpf45tW11Pzc66xau2afbv7j2HqTytn7gD f1zhVl/ayVzowJQW6xEnbibzIWi1g== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 10FF3EB9F; Mon, 23 Jul 2018 06:27:23 -0400 (EDT) Message-Id: <323520f0-41fb-41d9-9929-2b8b6db86c68@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-12-g2496422-fmnext-20180717v1 x-jmap-identity-id: 64588216 In-Reply-To: <10C47D45-8263-4271-AB44-7D24EBAF8417@oracle.com> References: <10C47D45-8263-4271-AB44-7D24EBAF8417@oracle.com> Date: Mon, 23 Jul 2018 06:27:23 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=65000b80c6c64aa6b9c9c30842939573 Archived-At: Subject: Re: [Jmap] First cut at error codes registry X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 10:27:27 -0000 --65000b80c6c64aa6b9c9c30842939573 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Chris. I= 've merged this, although we can still make changes of course.
=

1. = The naming convention for HTTP-level errors (all lower case) and 
method-level errors (camelCase) is different.

I've changed these to be camelCase so every= thing is consistent.

2. Each error is used in one or more object type= s (e.g. JMAP Error 
object, JMAP SetError object) and= may or may not be method-specific. 
Should I try to = add a column to the registry to distinguish where an 
error is used, or should I keep the registry simpler? If you prefer&nbs= p;
another column, suggested text would be appreciated.

I'm not sure about this. If the = purpose is primarily to avoid name collisions between different specs, t= hen there's no need to document this. If you're a client author looking = up all the error codes you might need to handle, you'd still need to rea= d the referenced section of the RFCs to see if it was relevant, but it w= ould let you skip some that definitely didn't apply. So, I don't think i= t's necessary, but it could be mildly useful.

The column would need to be something like "Error context" with value= for each row any combination of "Request, Method, Set" (the three diffe= rent levels that errors are returned at).

--65000b80c6c64aa6b9c9c30842939573 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Chris. I've merged this, although we can still make changes of co= urse. > 1. The naming convention for HTTP-level errors (all lower case) and=C2= =A0 > method-level errors (camelCase) is different. I've changed these to be camelCase so everything is consistent. > 2. Each error is used in one or more object types (e.g. JMAP Error=C2= =A0 > object, JMAP SetError object) and may or may not be method-specific.=C2= =A0 > Should I try to add a column to the registry to distinguish where an=C2= =A0 > error is used, or should I keep the registry simpler? If you prefer=C2= =A0 > another column, suggested text would be appreciated. I'm not sure about this. If the purpose is primarily to avoid name colli= sions between different specs, then there's no need to document this. If= you're a client author looking up all the error codes you might need to= handle, you'd still need to read the referenced section of the RFCs to = see if it was relevant, but it would let you skip some that definitely d= idn't apply. So, I don't think it's necessary, but it could be mildly us= eful. The column would need to be something like "Error context" with value fo= r each row any combination of "Request, Method, Set" (the three differen= t levels that errors are returned at). Neil. --65000b80c6c64aa6b9c9c30842939573-- From nobody Fri Jul 27 08:26:49 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 EA0AE130F75; Fri, 27 Jul 2018 08:26:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <153270520782.32707.4419621555491459322@ietfa.amsl.com> Date: Fri, 27 Jul 2018 08:26:47 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:26:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : Sending an MDN Response with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-00.txt Pages : 5 Date : 2018-07-27 Abstract: This document specifies a data model for handling [RFC8098] MDN messages with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mdn-00 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 30 08:42:18 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 9E187130DD4 for ; Mon, 30 Jul 2018 08:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3-dBv_xAjKo for ; Mon, 30 Jul 2018 08:42:15 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id B96BB130DE0 for ; Mon, 30 Jul 2018 08:42:14 -0700 (PDT) Received: from [10.168.3.2] (unknown [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 6DE642B3CDA for ; Mon, 30 Jul 2018 18:34:37 +0300 (EEST) From: Stephan Bosch To: jmap@ietf.org Message-ID: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> Date: Mon, 30 Jul 2018 17:34:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Jmap] Review of draft-ietf-jmap-core-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 15:42:17 -0000 Hi, Here are some of the comments and suggestions I collected while reading draft-ietf-jmap-core-06. I haven't followed the discussions and developments much lately, so there could be some stuff there (design choices) that is obvious to everyone else, but not to me. Some comments may therefore be redundant. Text from the document itself is pasted here as-is. My comments are prefixed with "-> ". Regards, Stephan. ## Section 1.1: "Foo" - Any name that is not a native JSON type means an object       for which the properties (and their types) are defined elsewhere       within this document. -> What about "Date" and "UTCDate"? These are just strings and not objects. ## Section 1.2: -> Should we define a separate special "Size" Number type for size values? Otherwise, the >= 0 requirement for size values needs to be restated everywhere (which it currently isn't). ## Section 1.7: -> Is HTTPS required for JMAP? According to Section 7.1, yes. So, that should probably be mentioned here as well. ## Section 2: o  *accounts*: "String[Account]" -> Some of this text may fit better in Section 1.5.2. Servers MAY advertise vendor-specific JMAP  extensions. To avoid conflict, the identifiers for these MUST be a URI beginning with a domain owned by the vendor. -> What exactly would this normally look like? A URN? An HTTP URL? Maybe add one in the example for clarity. At reference to Section 3.3 for finding details. (see "Making an API request") -> why not just use a numeric Section reference? o     *downloadUrl*: "String" The URL endpoint to use when downloading       files (see the Download section of this spec), in [RFC6570] URI       Template (level 1) format.  The URL MUST contain variables called       "blobId", MAY contain a variables called "accountId" and SHOULD       contain a variable called "name". -> What do these variables mean? Refer to the relevant section(s). -> How long is a client supposed to cache the session data? What if e.g. the API URLs need to change while clients are active? Should we add a TTL field so that clients will use the new session data, or do we expect them to only reread the session data when errors occur? ## Section 3.2: *createdIds*: "String[String]" (optional) -> Very long description for this field. Maybe create a separate section on how the createdIds feature works in general? Other parts of the specification can point to that section as well. ## Section 3.3: -> Why is this not discussed earlier? I'd expect this in Section 1. ## Section 3.5: -> Some arguments are marked explicitly as "(optional)". What exacly does that mean? Isn't the mere fact that these have a default or "|null" in their specification the same? ## Section 3.6: -> Please clarify the difference between request-level and method-level errors in a short introduction. ## Section 3.6.1:    Every JSON "problem details" object MUST include a "type" member with a URI    either one of the following values, or a value defined in a future RFC, or a    value beginning with a domain owned by the vendor. -> What exactly would this normally look like? A URN? An HTTP URL? Maybe add one in the example for clarity. Refer to Section 3.3 for clarity. ## Section 3.6.2:    Further possible errors for a particular method are specified in the    method descriptions.    Further general errors MAY be defined in future RFCs.  Should a    client receive an error type it does not understand, it MUST treat it    the same as the "serverFail" type. -> Next section actually defines "resultReference", which was not listed here. -> Shouldn't that be called e.g. "invalidResultReference" instead? ## Section 3.7: -> Would it be useful to add the ability for a client to make the server omit (specific) responses for a method? I.e. have certain response data available only for references from other methods but not return it to the client? This could save some effort on sending/parsing data that the client doesn't really need to see. -> Can result references also yield arrays of objects or only arrays of strings (as in the example)? If yes, this could maybe be used to make some really stupid/abusive requests that copy objects between contexts (accounts), without using the proper copy methods. What to do with that? -> Can there be duplicate method responses? I.e., can there be ambiguities in reference resolution? ## Section 4.3:       Any server-set properties MAY be included in the patch if their       value is identical to the current server value (before applying       the patches to the object).  Otherwise, the update MUST be       rejected with an _invalidProperties_ SetError. -> The SetError concept is not yet explained at this point.    The server MAY skip an update (rejecting it with a "willDestroy"    SetError) if that object is destroyed in the same /set request. -> The SetError concept is not yet explained at this point.    The following SetError types are defined and may be returned for set    operations on any record type where appropriate: -> What about a generic temporary failure? "tryLater" ? -> What a bout a "tooBig" error? ## Section 4.4: -> How is/could the complexity of filters limited by the server? What error should be returned if such limit is exceeded? Should the client be able to know the limits from querying some session data? -> How would queryState be implemented; some hash of all results? From nobody Mon Jul 30 08:53:30 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CDC13113C for ; Mon, 30 Jul 2018 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvGx14wy6j_c for ; Mon, 30 Jul 2018 08:53:25 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id A2C6E13115E for ; Mon, 30 Jul 2018 08:53:24 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id E50C62B3CDA for ; Mon, 30 Jul 2018 18:53:23 +0300 (EEST) From: Stephan Bosch To: jmap@ietf.org Message-ID: Date: Mon, 30 Jul 2018 17:53:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Jmap] Review of draft-ietf-jmap-mail-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 15:53:29 -0000 Hi, Here are some of the comments and suggestions I collected while reading draft-ietf-jmap-mail-06. As stated in my previous review, I haven't followed the discussions and developments much lately, so there could be some stuff there (design choices) that is obvious to everyone else, but not to me. Some comments may therefore be redundant. Text from the document itself is pasted here as-is. My comments are prefixed with "-> ". Regards, Stephan. ## Section 1.1: *sever-set*: -> Typo Section 1.2: -> Why not refer to core, where this information is replicated? ## Section 2: This may be any Net-Unicode string ([RFC5198]) of at least 1 character in length and maximum 255 octets in size. -> 255 octets could be very limited for languages involving multi-byte characters. Could this perhaps be a server capability property? Where does this limit come from anyway? IMAP? -> Also, stating the limit in octets rather than UTF-8 characters (or maybe just codepoints) makes this inconsistent between languages (for display). -> Is there a maximum mailbox hierarchy depth? How would the client know about it? What minimum depth must be supported by any server? -> How are IMAP namespaces mapped to JMAP? More specifically: how are personal and shared mailboxes identified in JMAP? ## Section 2.3: -> How to find a mailbox by name without downloading the full list? -> Should wildcard name queries be possible? -> Why only *hasRole* and not allow query for a specific *role* and a value of "*" meaning any? I think this could be particularly useful for backreferences to operate on a specific mailbox by role rather than id or name. -> Comparing to IMAP LIST-EXTENDED: Would filters for *hasChildren* be useful? ## Section 4.1.1: *keywords*: "String[Boolean]" (default: "{}") A set of keywords that apply to the email. The set is represented as an object, with the keys being the _keywords_. The value for each key in the object MUST be "true". -> Why is this an object? o *receivedAt*: "UTCDate" (immutable; default: time of creation on server) The date the email was received by the message store. This is the _internal date_ in IMAP. -> Could we define savedAt already (IMAP SAVEDATE)? ## Section 4.4.2: o *allInThreadHaveKeyword* - This value MUST be considered "true" for the email if *all* of the emails in the same thread (regardless of mailbox) have the keyword given as the _keyword_ property on this _Comparator_ object. -> There is no _keyword_ property in this _Comparator_ object. ## Section 4.4.3: "collapseThreads == true" -> Editorial comment: shouldn't this just be a sentence? This looks weird. ## Section 4.6: -> Should we add a "tooLarge" SetError? (defined for EmailSubmission/set) ## Section 4.7: If the email cannot be imported because it would take the account over quota, the import should be rejected with a "maxQuotaReached" SetError. -> core, Section 4.3 defines "overQuota" ## Section 5.3: o "maxQuotaReached": The user has reached a server-defined limit on the number of identities. -> core, Section 4.3 defines "overQuota" -> Should we add a "tooLarge" SetError? (defined for EmailSubmission/set) ## Section 9.3: -> Please provide an URL reference for SMTP XCLIENT capability, or at least describe it here in more detail. -> Same for "milter protocol"