From nobody Tue Nov 15 17:14:14 2016 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 51DFB129479 for ; Tue, 15 Nov 2016 17:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.497, 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 JJStj1NeDc-x for ; Tue, 15 Nov 2016 17:14:10 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B0411129532 for ; Tue, 15 Nov 2016 17:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479258846; d=isode.com; s=june2016; i=@isode.com; bh=XiZ4pMcpfwpVuUGMCOOURDGA3xYO3Q1Ua43z+pelMgM=; 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=hJpbsesF0V6uGiTZrqqMYYgmMZ8Vg481/8tN+L72tNtuunCvWxGh8+sqLJb+PVei8lBEQH 3KXwzI5tGLZ1/QggrtsOmlHmXzDCChbfZZ1c8N86jcPCq6YUa+cKRg276rCQC/tu5y1Cg5 EJuSElhl3SWIhwaSJ5knk0VvW8hggV4=; Received: from [31.133.133.241] (dhcp-85f1.meeting.ietf.org [31.133.133.241]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 16 Nov 2016 01:14:04 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov Date: Wed, 16 Nov 2016 10:29:14 +0900 Message-Id: References: <1478836665.322873.784300457.3FB705B7@webmail.messagingengine.com> To: jmap@ietf.org X-Mailer: iPad Mail (14A456) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-2BA588BC-7F1C-44F1-A494-3E907A80A760 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Jmap] Fwd: Request to form a new WG: JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:14:13 -0000 --Apple-Mail-2BA588BC-7F1C-44F1-A494-3E907A80A760 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Begin forwarded message: > From: Neil Jenkins > Date: 11 November 2016 at 12:57:45 GMT+9 > To: imapext@ietf.org > Subject: Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP >=20 > Hi all, >=20 > Rather than reply to individual emails, I'm going to try to put across > answers to the queries and concerns related so far in this thread. I'm > the author of the draft specification we're putting forward with this > charter; happy to answer any further questions. >=20 > # What is JMAP replacing? >=20 > JMAP is intended to be a new standard for email clients to connect to > mail stores. It therefore replaces IMAP + SMTP submission. It is also > designed to be more generic such that it can be extended with contacts, > calendars in the future (replacing CardDAV/CalDAV). It does not replace > MTA-to-MTA SMTP transmission. >=20 > # Why is this needed? >=20 > It's too hard to write a good MUA with current standards, which has led > to a stagnation in good email clients and a proliferation of proprietary > protocols. >=20 > In addition, IMAP is really not suited to a constrained network > environment, as often found on mobile networks even in developed > countries. The chatty nature of the IMAP protocol is ill-suited to high > latency connections. Things like a folder rename on the server can mean > that all the downloaded and cached email for that folder is invalidated > (because you can't tell for sure over the protocol that they're the > exact same messages), wasting huge amounts of bandwidth. Stateful > connections make it harder to deal with intermittent network outages. >=20 > We're attempting to standardise a new protocol because lots of people > are writing proprietary alternatives to deal with the same deficiencies > with the current standards. Some of these deficiencies could be fixed by > adding things to IMAP (for example persistent IDs on folders and > messages for better caching when another client copies, moves or > renames), but others are structural like the need to calculate a MSGNO > <=3D> UID mapping even if the client doesn't want it, or the need to find > endpoints and authenticate separately to multiple different protocols to > do related tasks. >=20 > Because it's so hard to write a good email client that works with any > IMAP provider, these days many new clients are just for Gmail (with > possibly support for a few other big mailbox providers). It's easy to > see why: IMAP is either the woefully inadequate original RFC3501, or > it's a messy set of incomplete implementations of some of the > extensions. Even CONDSTORE (without QRESYNC) is pushing it; you can't > rely on it to be there in most cases. >=20 > As a result of this, proprietary protocols have been popping up as > alternatives to IMAP. Here are a few examples, the latter two being from > whole companies that formed just to try to help people not have to deal > with IMAP: >=20 > Gmail: https://developers.google.com/gmail/api/v1/reference/ > Outlook: > https://msdn.microsoft.com/office/office365/APi/mail-rest-operations > Nylas: https://nylas.com/cloud/docs > Context.io: https://context.io/docs/lite >=20 > In addition, we're seeing most new mobile email clients proxy everything > via their own server rather than talking directly to the user's mail > store, for much the same reasons. Examples include Mailbox (now > defunct), Alto, Outlook and Newton. This is bad for security and > privacy, and also bad for the client authors as they have to run server > infrastructure in addition to just building their clients. >=20 > Despite not only being proprietary but patented (and expensive!), > ActiveSync has seen a big increase in adoption, and not just with > Microsoft servers, due to its better support for mobile environments and > ease of setup (one login for mail receive/send, contacts and calendars). >=20 > # Why is JMAP better than IMAP? >=20 > JMAP not a conversion of IMAP to JSON; it is a new protocol. It was > designed to be make much more efficient use of network resources, be > easier for developers to work with and hopefully make the best > protocol for email an open standard once more. It's based on years of > experience and real-world experimentation at FastMail, and talking to > other major MUA/MTA developers to make sure we understand the common > needs of the industry. >=20 > Some important attributes that help achieve these goals: >=20 > * The protocol is stateless. It doesn't need a persistent connection, > which is better for mobile use which may have intermittent network > access and wants to conserve battery life by turning the radio off > whenever possible. >=20 > * Ids are immutable and not intended to be user visible. So folder > naming becomes less messy - more like NFS or filesystems with inodes > rather than a name-based hierarchy, and renaming is easy to detect and > cheap to sync. >=20 > * It has a flexible set of commands, which can be batched in arbitrary > ways. You can batch or pipeline single JMAP operations over a stream > protocol easily enough if you wanted to, but we're mostly envisaging > it being used for stateless batch operations to make disconnection > less painful. >=20 > With IMAP you can set two messages to both have the same flag (. STORE > 1,2 +FLAGS (aflag)) but you can't store two different flags to two > different messages in the same action. JMAP allows multiple create, > update and destroy actions on different messages in a single setMessages > command. Pipelining also has the problem that if the connection drops at > just the wrong moment you can wind up applying the first change but not > the second. >=20 > You can use backreferences to other objects created in the same batch - > allowing you to, for example, create a folder tree by referencing > previous parents created in the same request. >=20 > * Clients can efficiently fetch updates from their current state a-la > QRESYNC. This can be implemented effectively using the MODSEQ data > already in modern IMAP servers, or by using a transaction log data > structure. The server can always indicate to the client if it > cannot calculate updates from a particular client state (e.g. > because it is too old). >=20 > * Flood control. The client can always restrict how much data the server > should send. For example, a command might return a "tooManyUpdates" > error if it exceeds the client's limit, rather than returning a > million "* 1 EXPUNGED" lines as can happen in IMAP. Sometimes it's > just more efficient to throw away cached data and refetch, especially > if you're a mobile/webmail interface with only a partial cache of the > server's data. >=20 > * It doesn't require a custom parser. I've got a longer explanation to > the HTTPS/JSON question lower down, but having an encoding format that > is well understood and has widespread support among all programming > languages makes it far easier for developers to get started, > especially if they don't want to build a whole MUA but just integrate > something with email. >=20 > * The data model is backwards compatible with both IMAP folders and > gmail- > style labels. Servers that implement JMAP are likely to want to > support IMAP as well for the foreseeable future, so it's important to > be able to have data structures that support both. Messages are > similarly immutable other than flags/mailboxes. >=20 > * Email can be sent using the same protocol, reducing confusing failure > modes for users (again I talk more about this below). We also have > pretty- > much complete specs for calendaring and contacts via JMAP, but we're > not pushing for them to be standard yet because the object format is > still undergoing a lot of work in the CalConnect group. We think a > single consistent protocol for all of these has a lot of advantages > though, and we hope to get there in the future. >=20 > # Why use HTTPS/JSON? >=20 > The short answer is it's good enough, widely understood and it's by far > the easiest thing for developers to adopt. There's support in basically > all OSes and programming languages. It's easy to read and debug. >=20 > HTTP doesn't tend to run into firewall issues, and is so commonly used > it has integrations which can help with optimisation (for example, iOS > has built-in support for optimising radio usage by batching HTTP calls > from different apps where possible, which their mail team have told us > they would like to be able to use). This isn't an innate advantage of > HTTP, but rather an advantage of its ubiquity. >=20 > With GZIP, JSON data is reasonably compact and fast enough to > serialise/parse. However, the encoding/transport part of JMAP is not > core to its operation, so future specifications could easily add > alternatives (e.g. WebSocket (https://tools.ietf.org/html/rfc6455) > instead of HTTPS, CBOR (http://tools.ietf.org/html/rfc7049) instead of > JSON). For the initial version though, HTTPS+JSON makes the most sense. >=20 > # Binary data >=20 > Binary data is not transported in the JSON (and indeed, as has been > pointed out, can't be without base64 encoding or similar, which is > inefficient). Instead, attachments are referenced by a blobId, and > uploaded/downloaded separately via HTTPS. Clients can reference the > blobId elsewhere to, for example, attach the same file to a new message > without having to download and reupload it again, a big win on slower > internet connections. >=20 > This also means that regularly saving drafts (a common client behaviour) > does not mean sending the same full multi-megabyte attachments over the > network every 60s or so. >=20 > As it's out-of-band with the API calls, uploading/downloading files can > easily be parallelised and doesn't block other API operations. >=20 > # Representation of email >=20 > JMAP defines a JSON structure that represents in a consistent and > structured way all the information that the vast majority of > clients need from an RFC5322 message. The server deals with the > complexities of MIME, encoding issues, parsing headers etc. The > intention is that the server will still operate with RFC5322 > messages for storage and certainly transmission; the JSON > representation is not intended to replace RFC5322, just relieve > client authors from having to deal with it. >=20 > Clients that want to or need to (for example those doing PGP in the > client) can still fetch the RFC5322 if needed. The message is > represented by a blobId, and the raw bytes can be fetched using the same > binary download mechanism as mentioned above. >=20 > # Message submission >=20 > Message submission is via means of an "outbox" folder. Messages are > moved there to send. This was chosen over a separate "send" command for > a few reasons. Firstly it's most consist with the rest of the API, > making it easier for clients to implement offline support > (synchronisation is the same as other changes you might make to > messages). Secondly, clients/servers can support delayed send > (particularly useful for "undo send"), by simply setting the date on the > message in the future and only sending from the outbox when this date is > reached. Until then the message is just sitting in the outbox like any > other mailbox, allowing client to list and revoke without needing custom > API commands. >=20 > Error handling is flexible enough to return a full range of errors when > you try to move a message to this folder, just as you would to a > separate "send" method. >=20 > Clients can use the same JSON structure for sending messages as they get > from the server for received messages, allowing the server to deal with > MIME encoding. This allows clients to be much simpler and easier to > write. (They can also upload a raw RFC5322 message if they want instead > of course.) >=20 > Having the same protocol for message sync and submission is a huge win > for usability; we see a lot of support tickets where users can receive > but not send, or vice versa, because one of these is misconfigured. This > is always very confusing for regular users. >=20 > # Push mechanism >=20 > Immediate updates is an important feature to many users. IMAP IDLE has > two big problems: firstly it only notifies of changes in one folder, so > doesn't inform you of all changes unless you open a connection for every > folder, and secondly it requires a persistent network connection which > is bad for mobile (and not even allowed on iOS). >=20 > JMAP defines two push mechanisms to support the two common use cases. In > both cases the data transferred is simply an edge trigger: a new state > string letting the client know something has changed within a particular > datatype. The client then fetches the new data using the standard > synchronisation methods. >=20 > For desktop clients and webmail, there's an event source interface > (https://html.spec.whatwg.org/multipage/comms.html#the-eventsource-interfa= ce) > . This requires a persistent HTTP connection. >=20 > For mobile, and web integrations, you can set a callback handler. This > makes the mail store server do a callback to a server defined by the > client when something changes; the client's server can then send out-of- > band push events using the native push mechanism of the mobile client. > JMAP itself doesn't require any particular mobile push technology. >=20 > # End-to-end encryption >=20 > A lot of the optimisations for efficient client-server sync require the > server to be able to read the message. If everything were encrypted, the > server would basically be a dumb blob store, unless you have some clever > partial metadata search capability. This is particularly bad for mobile, > where you only want to sync partial information. Users expect to be able > to search their whole archive, so either you need all the data in the > client, or the server needs to have access to the data. >=20 > JMAP is therefore not making any new measures to address end-to-end > encryption. The best advice is probably to run your own "JMAP SERVER" on > trusted hardware; otherwise you need to sync the entire multi-gigabyte > mail spool to all your devices. JMAP is also simple enough that you > could run the server on multiple machines with an underlying replication > protocol over encrypted links and have that do your smarts. >=20 > # Draft proposals and implementations >=20 > As Arnt pointed out, "rough consensus and running code" are key here, > and the current draft of the JMAP spec is being implemented in Cyrus > IMAPd and Dovecot (the two largest open-source IMAP servers), as well as > other open source projects like Apache James and Linagora. Roundcube > have stated they plan to build their next-generation client on JMAP. >=20 > On the proprietary side, Atmail have a JMAP proxy and webmail client > they are releasing to production very soon, and we at FastMail have a > version of our client that talks JMAP too. >=20 > There is interest among other large mailbox providers/mail client > authors, but they don't tend to be early adopters as much. >=20 > The current specification drafts can be found at: >=20 > https://datatracker.ietf.org/doc/draft-jenkins-jmap/ (The generic JMAP > protocol) > https://datatracker.ietf.org/doc/draft-jenkins-jmapmail/ (Mail over > JMAP) >=20 > We have also developed an open-source JMAP proxy, which you can connect > to an IMAP server to try out the protocol and see what happens over the > wire. There's a hosted version at http://proxy.jmap.io/, or you can grab > the code from https://github.com/jmapio/jmap-perl >=20 > Cheers, >=20 > Neil. >=20 --Apple-Mail-2BA588BC-7F1C-44F1-A494-3E907A80A760 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Begin forwarded message:
From: Neil Jenkins <neilj@fastmail.com>
Date: 11 No= vember 2016 at 12:57:45 GMT+9
To: imapext@ietf.org
Subject: Re: [imapext] [ietf-smtp] Fwd= : Request to form a new WG: JMAP

Hi all,

Rather than= reply to individual emails, I'm going to try to put across
= answers to the queries and concerns related so far in this thread. I'm
the author of the draft specification we're putting forward with t= his
charter; happy to answer any further questions.
# What is JMAP replacing?
JMAP is intended to be a new standard for email clients to connect t= o
mail stores. It therefore replaces IMAP + SMTP submission.= It is also
designed to be more generic such that it can be e= xtended with contacts,
calendars in the future (replacing Ca= rdDAV/CalDAV). It does not replace
MTA-to-MTA SMTP transmiss= ion.

# Why is this needed?
=
It's too hard to write a good MUA with current standards, w= hich has led
to a stagnation in good email clients and a pro= liferation of proprietary
protocols.
=
In addition, IMAP is really not suited to a constrained network
environment, as often found on mobile networks even in develop= ed
countries. The chatty nature of the IMAP protocol is ill-= suited to high
latency connections. Things like a folder ren= ame on the server can mean
that all the downloaded and cache= d email for that folder is invalidated
(because you can't te= ll for sure over the protocol that they're the
exact same me= ssages), wasting huge amounts of bandwidth. Stateful
connect= ions make it harder to deal with intermittent network outages.

We're attempting to standardise a new protocol because l= ots of people
are writing proprietary alternatives to deal w= ith the same deficiencies
with the current standards. Some o= f these deficiencies could be fixed by
adding things to IMAP= (for example persistent IDs on folders and
messages for bet= ter caching when another client copies, moves or
renames), b= ut others are structural like the need to calculate a MSGNO
= <=3D> UID mapping even if the client doesn't want it, or the need to f= ind
endpoints and authenticate separately to multiple differ= ent protocols to
do related tasks.
Because it's so hard to write a good email client that works with an= y
IMAP provider, these days many new clients are just for Gm= ail (with
possibly support for a few other big mailbox provi= ders). It's easy to
see why: IMAP is either the woefully ina= dequate original RFC3501, or
it's a messy set of incomplete i= mplementations of some of the
extensions. Even CONDSTORE (wi= thout QRESYNC) is pushing it; you can't
rely on it to be the= re in most cases.

As a result of this, prop= rietary protocols have been popping up as
alternatives to IM= AP. Here are a few examples, the latter two being from
whole= companies that formed just to try to help people not have to dealwith IMAP:

Gmail: https://developers.google.co= m/gmail/api/v1/reference/
Outlook:
= https://msdn.microsoft.com/office/office365/APi/mail-rest-operations
Nylas: https://nylas.c= om/cloud/docs
Context.io: https://context.io/docs/lite

In addition, we're seeing most new mobile= email clients proxy everything
via their own server rather t= han talking directly to the user's mail
store, for much the s= ame reasons. Examples include Mailbox (now
defunct), Alto, O= utlook and Newton. This is bad for security and
privacy, and= also bad for the client authors as they have to run server
= infrastructure in addition to just building their clients.
<= /span>
Despite not only being proprietary but patented (and expensi= ve!),
ActiveSync has seen a big increase in adoption, and no= t just with
Microsoft servers, due to its better support for= mobile environments and
ease of setup (one login for mail r= eceive/send, contacts and calendars).

# Why= is JMAP better than IMAP?

JMAP not a conve= rsion of IMAP to JSON; it is a new protocol. It was
designed= to be make much more efficient use of network resources, be
easier for developers to work with and hopefully make the best
protocol for email an open standard once more. It's based on years of
experience and real-world experimentation at FastMail, and tal= king to
other major MUA/MTA developers to make sure we under= stand the common
needs of the industry.

Some important attributes that help achieve these goals:=

* The protocol is stateless. It doesn't need a pe= rsistent connection,
 which is better for mobile use w= hich may have intermittent network
 access and wants t= o conserve battery life by turning the radio off
 when= ever possible.

* Ids are immutable and not i= ntended to be user visible. So folder
 naming becomes l= ess messy - more like NFS or filesystems with inodes
 = rather than a name-based hierarchy, and renaming is easy to detect and
 cheap to sync.

* It has a= flexible set of commands, which can be batched in arbitrary
 ways.  You can batch or pipeline single JMAP operations over a s= tream
 protocol easily enough if you wanted to, but we= 're mostly envisaging
 it being used for stateless bat= ch operations to make disconnection
 less painful.

With IMAP you can set two messages to both hav= e the same flag (. STORE
1,2 +FLAGS (aflag)) but you can't s= tore two different flags to two
different messages in the sa= me action. JMAP allows multiple create,
update and destroy a= ctions on different messages in a single setMessages
command= . Pipelining also has the problem that if the connection drops at
= just the wrong moment you can wind up applying the first change but no= t
the second.

You can use b= ackreferences to other objects created in the same batch -
a= llowing you to, for example, create a folder tree by referencing
<= span>previous parents created in the same request.
* Clients can efficiently fetch updates from their current state a-l= a
 QRESYNC. This can be implemented effectively using t= he MODSEQ data
 already in modern IMAP servers, or by u= sing a transaction log data
 structure. The server can= always indicate to the client if it
 cannot calculate= updates from a particular client state (e.g.
 because= it is too old).

* Flood control. The clien= t can always restrict how much data the server
 should= send. For example, a command might return a "tooManyUpdates"
 error if it exceeds the client's limit, rather than returning a
 million "* 1 EXPUNGED" lines as can happen in IMAP. Some= times it's
 just more efficient to throw away cached d= ata and refetch, especially
 if you're a mobile/webmai= l interface with only a partial cache of the
 server's= data.

* It doesn't require a custom parser= . I've got a longer explanation to
 the HTTPS/JSON que= stion lower down, but having an encoding format that
 = is well understood and has widespread support among all programming  languages makes it far easier for developers to get started,<= /span>
 especially if they don't want to build a whole MUA bu= t just integrate
 something with email.

* The data model is backwards compatible with both IMAP f= olders and
gmail-
 style labels. Serve= rs that implement JMAP are likely to want to
 support I= MAP as well for the foreseeable future, so it's important to
 be able to have data structures that support both. Messages are
 similarly immutable other than flags/mailboxes.
* Email can be sent using the same protocol, reducin= g confusing failure
 modes for users (again I talk mor= e about this below). We also have
 pretty-
<= span>  much complete specs for calendaring and contacts via JMAP, but w= e're
 not pushing for them to be standard yet because t= he object format is
 still undergoing a lot of work in= the CalConnect group. We think a
 single consistent p= rotocol for all of these has a lot of advantages
 thou= gh, and we hope to get there in the future.

# Why use HTTPS/JSON?

The short answer is i= t's good enough, widely understood and it's by far
the easie= st thing for developers to adopt. There's support in basically
all OSes and programming languages. It's easy to read and debug.
HTTP doesn't tend to run into firewall issues, and i= s so commonly used
it has integrations which can help with o= ptimisation (for example, iOS
has built-in support for optim= ising radio usage by batching HTTP calls
from different apps= where possible, which their mail team have told us
they wou= ld like to be able to use). This isn't an innate advantage of
HTTP, but rather an advantage of its ubiquity.

= With GZIP, JSON data is reasonably compact and fast enough toserialise/parse. However, the encoding/transport part of JMAP is not=
core to its operation, so future specifications could easil= y add
alternatives (e.g. WebSocket (https://tools.ietf.org/html/rfc6455)
<= span>instead of HTTPS, CBOR (= http://tools.ietf.org/html/rfc7049) instead of
JSON). Fo= r the initial version though, HTTPS+JSON makes the most sense.

# Binary data

Binary da= ta is not transported in the JSON (and indeed, as has been
p= ointed out, can't be without base64 encoding or similar, which is
= inefficient). Instead, attachments are referenced by a blobId, and
uploaded/downloaded separately via HTTPS. Clients can reference= the
blobId elsewhere to, for example, attach the same file t= o a new message
without having to download and reupload it a= gain, a big win on slower
internet connections.

This also means that regularly saving drafts (a common c= lient behaviour)
does not mean sending the same full multi-m= egabyte attachments over the
network every 60s or so.=

As it's out-of-band with the API calls, uploading= /downloading files can
easily be parallelised and doesn't bl= ock other API operations.

# Representation o= f email

JMAP defines a JSON structure that r= epresents in a consistent and
structured way all the informa= tion that the vast majority of
clients need from an RFC5322 m= essage. The server deals with the
complexities of MIME, enco= ding issues, parsing headers etc. The
intention is that the s= erver will still operate with RFC5322
messages for storage a= nd certainly transmission; the JSON
representation is not in= tended to replace RFC5322, just relieve
client authors from h= aving to deal with it.

Clients that want to= or need to (for example those doing PGP in the
client) can s= till fetch the RFC5322 if needed. The message is
represented= by a blobId, and the raw bytes can be fetched using the same
binary download mechanism as mentioned above.

<= span># Message submission

Message submissio= n is via means of an "outbox" folder. Messages are
moved the= re to send. This was chosen over a separate "send" command for
a few reasons. Firstly it's most consist with the rest of the API,=
making it easier for clients to implement offline support(synchronisation is the same as other changes you might make to
messages). Secondly, clients/servers can support delayed send
(particularly useful for "undo send"), by simply setting the d= ate on the
message in the future and only sending from the o= utbox when this date is
reached. Until then the message is j= ust sitting in the outbox like any
other mailbox, allowing c= lient to list and revoke without needing custom
API commands= .

Error handling is flexible enough to retu= rn a full range of errors when
you try to move a message to t= his folder, just as you would to a
separate "send" method.

Clients can use the same JSON structure for s= ending messages as they get
from the server for received mes= sages, allowing the server to deal with
MIME encoding. This a= llows clients to be much simpler and easier to
write. (They c= an also upload a raw RFC5322 message if they want instead
of= course.)

Having the same protocol for mess= age sync and submission is a huge win
for usability; we see a= lot of support tickets where users can receive
but not send= , or vice versa, because one of these is misconfigured. This
is always very confusing for regular users.

# Push mechanism

Immediate updates is an i= mportant feature to many users. IMAP IDLE has
two big proble= ms: firstly it only notifies of changes in one folder, so
do= esn't inform you of all changes unless you open a connection for every
folder, and secondly it requires a persistent network connection w= hich
is bad for mobile (and not even allowed on iOS).=

JMAP defines two push mechanisms to support the t= wo common use cases. In
both cases the data transferred is s= imply an edge trigger: a new state
string letting the client= know something has changed within a particular
datatype. Th= e client then fetches the new data using the standard
synchr= onisation methods.

For desktop clients and w= ebmail, there's an event source interface
(https= ://html.spec.whatwg.org/multipage/comms.html#the-eventsource-interface)<= /span>
. This requires a persistent HTTP connection.

For mobile, and web integrations, you can set a callback h= andler. This
makes the mail store server do a callback to a s= erver defined by the
client when something changes; the clie= nt's server can then send out-of-
band push events using the= native push mechanism of the mobile client.
JMAP itself doe= sn't require any particular mobile push technology.
<= br># End-to-end encryption

A lot of t= he optimisations for efficient client-server sync require the
server to be able to read the message. If everything were encrypted, the
server would basically be a dumb blob store, unless you have s= ome clever
partial metadata search capability. This is parti= cularly bad for mobile,
where you only want to sync partial i= nformation. Users expect to be able
to search their whole ar= chive, so either you need all the data in the
client, or the= server needs to have access to the data.

J= MAP is therefore not making any new measures to address end-to-endencryption. The best advice is probably to run your own "JMAP SERVER"= on
trusted hardware; otherwise you need to sync the entire m= ulti-gigabyte
mail spool to all your devices. JMAP is also s= imple enough that you
could run the server on multiple machi= nes with an underlying replication
protocol over encrypted l= inks and have that do your smarts.

# Draft p= roposals and implementations

As Arnt pointe= d out, "rough consensus and running code" are key here,
and t= he current draft of the JMAP spec is being implemented in Cyrus
IMAPd and Dovecot (the two largest open-source IMAP servers), as well as=
other open source projects like Apache James and Linagora. R= oundcube
have stated they plan to build their next-generatio= n client on JMAP.

On the proprietary side, A= tmail have a JMAP proxy and webmail client
they are releasin= g to production very soon, and we at FastMail have a
version= of our client that talks JMAP too.

There i= s interest among other large mailbox providers/mail client
a= uthors, but they don't tend to be early adopters as much.

The current specification drafts can be found at:
<= span>
https://datatracker.ietf.org/doc/draft-jenkins-jmap/ (The gen= eric JMAP
protocol)
https://datatracker.ietf.org/do= c/draft-jenkins-jmapmail/ (Mail over
JMAP)

We have also developed an open-source JMAP proxy, which y= ou can connect
to an IMAP server to try out the protocol and= see what happens over the
wire. There's a hosted version at= http://proxy.jmap.io/, or you can gra= b
the code from https://github.com/jmapio/jmap-perl

Cheers,

Neil.

= --Apple-Mail-2BA588BC-7F1C-44F1-A494-3E907A80A760-- From nobody Tue Nov 15 20:12:53 2016 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 24A4A129420 for ; Tue, 15 Nov 2016 20:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=gmail.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 0HmJt6hvGZLV for ; Tue, 15 Nov 2016 20:12:50 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F7412948C for ; Tue, 15 Nov 2016 20:12:50 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id z62so48524662oiz.1 for ; Tue, 15 Nov 2016 20:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=KyLQ0MgVj7g3SoqPtjBTjqHIRcjXMjNDD014OeYPByU=; b=aM9k4/K0Xn9gehZCdD2iQli8TAGLn+ACX7NmOBXJL4d7/j7K8vX4uk5xJB+O3MMHnp wbZLegxCXQMYzYId0UHuscNMX0+4YhghMuKg3P6xMpzmbkFDDcalDrs4/FAfS7jBs+79 gbtlTuUc4DUR7k5n8kNe8n6bsFLK5qzKhf76LNrQPUTT6DyR+w1PwfB4OMwzWEO7+9M6 x0golnqbUMCBlSnQzhaw+f+HMXXb5zLqfGj8H1IC+1sXBuDHleN5QaBSKyzvpkMNLbd8 baMKQxawKhewMVMHXUS+25INyq7Nr+LyQ+CmC1NSCPmUHG3hFaq3WRyOMSOgH5BWmYpU jcIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=KyLQ0MgVj7g3SoqPtjBTjqHIRcjXMjNDD014OeYPByU=; b=C9z8gDwfbewWTQiWk51VmMHUN0mhaE2O+IiTg5wtzXADjh9iIVNq6JGA7jfA1G2C9Y 0faQBYyYaPeeM9SjBTtlgClvt+MfS5eIumP1NSI5bbzbASu3WM7WYsueKsHzwYODHjSf pw6jzJsFVpa5khD2tw9ckq7wOIWBq09ditukvyfC4Il4ZCM+iUl0CqWnpIj1SvZk90sT 00a2MK18ZX1oZcFTCCvphkkWCenwDTGZSBwLrR3Pk1ocmhNOCTqlss+4pcR0zASfnx7t xgT43MSqdmYwG2Y2KFNRsL/twm6UFCIv60wgtn2CBee3AOlybe8llBqs27fuJWEwgWgZ JVoA== X-Gm-Message-State: ABUngvefsGvQerY5k1zxnG8SefqjgiIPNlr+tyjK/Y6Q5awtCRUvF+g6FGZsoBHlLPvR2A== X-Received: by 10.202.96.197 with SMTP id u188mr850073oib.30.1479269569264; Tue, 15 Nov 2016 20:12:49 -0800 (PST) Received: from [192.168.1.4] (184-99-116-79.boid.qwest.net. [184.99.116.79]) by smtp.googlemail.com with ESMTPSA id p47sm9937785otp.25.2016.11.15.20.12.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 20:12:48 -0800 (PST) To: jmap@ietf.org References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <582BDCBF.70606@gmail.com> Date: Tue, 15 Nov 2016 21:12:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090503000803060606010006" Archived-At: Subject: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 04:12:52 -0000 This is a cryptographically signed message in MIME format. --------------ms090503000803060606010006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/15/2016 02:51 PM, Ted Lemon wrote: > If both end maintain a versioned catalog, updating the catalog becomes = a > process of agreeing on a most recent common version, exchanging diffs > from that, then fetching new messages or message metadata. > > This is a lot less chatty than IMAP. The authoritative key is the message headers, not how the client or=20 server remember the messages. When a mailbox is opened, fetch the headers. The headers are not=20 editable and do not change once received in the mailbox, compare them. If there are some new messages, fetch what ever part of those new=20 messages you want offline. If there are missing ones, an authority already said "make this message=20 go away". So delete it from the client. Some MUAs tweak the message headers to indicate the message is read.=20 Stop that and use some other handshake or other flag. That's not a=20 offline issue, its a I read that message problem. The old Netscape communicator tweaked the received time. If the unit=20 digits of the time was even, it was an unread message. An odd number,=20 the message had been read. Header comparison on a shared 1MB (speed) computer was not an efficient=20 method on shared 56K Internets in the early 80's. Message 'numbers' are=20 an artifact of '/bin/mail[x]', the c-client derivatives, pine, ... Its a client presentation issue in those old clients. IMAP/POP clients=20 used them to number messages because a human had to type get me message=20 XX by hand. IMAP and POP protocols were an extension (almost a=20 shorthand) of what the user typed on the keyboard of those shared slow=20 computers from a DUMB terminal. Old school and unnecessary. If a client wants to display message by number, that's fine. However it=20 really has nothing to do with the 'key' (the headers) to the message. If some server tweaks the headers, then how will any program ever know=20 that its tweaked? It can't. It will look like the old one is deleted,=20 and the new one arrived. Delete it, fetch the newly tweaked message. Messages should not be edited or tweaked in the store. There is much text in IMAP protocols that describe fetching some, or a=20 select set of headers. Not needed any more. Get them all. its fast and a = much better key and sync solution. ---Mobile--- I have a separate email account for my mobile device, because I do not=20 want it downloading the tens of thousands of messages I have collected=20 over the decades. I have never met anyone that wanted to sync tens of thousands of emails=20 to their mobile device. However they can. The sync could be per server. Or could be per folder. Ether way, the=20 message headers are the key and its a client issue. -- Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms090503000803060606010006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CuwwggUCMIID6qADAgECAhAdBOVkkNcrCTidq3YMdkiJMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwNDA3MTQyMjU5WhcNMTcwNDA3MTQyMjU5WjBIMR8wHQYDVQQDDBZkb3Vn bGFzcm95ZXJAZ21haWwuY29tMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwpXz2U03EAEwBMtWerSb3KUI IfTw2/55rms1TwBY+p4Jj7x4DWTlBF6Ur5rdFF70bydWtDGILvSI3BNY2eXjZzbSXl5HCmvZ gUNnYFw6SJkb4S7edV5VdXVdOAVh24y0OBWqedbbuT8eVDZfPTy1mOuUbZo0I0tCoa1Hky14 UDb2qtPKw2Wfn9o2ksubBvn2b0UZlPahGFAcC/qc8M9h0O1G1hsn0BIowvVdr73/Q17Znr9u J/CBaCkNCM2tzH5j1qov7hRRZmeb7mVHrf/Dina9JjBAKsz52KZczLqPz1mSycKiEKc/k0ag FNtl0l6tCpUcoHwzBQ6dlbNOQEtE2QIDAQABo4IBuTCCAbUwDgYDVR0PAQH/BAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQkN0Oa JE+zG3ATs7D0DgRxVGx0fzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggr BgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5Bggr BgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQx LmNybDAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJAZ21haWwuY29tMCMGA1UdEgQcMBqGGGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIFMCwwKgYI KwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsF AAOCAQEAhAL0TajC+aJEbVC9q1elm0H0qgeCyW7EpLcfg8Lxwz/B9r6LvgoDzyS2afLecviF dy37I6jKVIAQH4RmAzVRwkSr1BHAl9TjSIQvlSbanoRnkLxJSWOr5fBiqbwrogv7K10tRGwN +86UIBvfear2f9epnMcI9d/hs4y6t41/uHlU76X5NdHIladYznv2YbZ9RJHUgaQvVYPkMzhA 8AqIVw/2r+RCJLA65Nf1prGxgQhTeA/JjTLVgjaO3AMtj9OQ/xm8NNVXhvLhRzhTXrXbux2q xWjYrPcMTiTrtsQyAZ9kbTaf5S2BErTA6EK5RQfZWFZCIlgI5XhVoHhOAMAchjCCBeIwggPK oAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d5 2DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8 wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDt VB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwv IjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1 ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtG K8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0 BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTAN BgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdOruKb rWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM 3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/ b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uV rZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDT agXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SW JQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0f QoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8 wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S 4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIB ATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBAhAdBOVkkNcrCTidq3YMdkiJMA0GCWCGSAFlAwQCAQUAoIICEzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMTYwNDEyNDda MC8GCSqGSIb3DQEJBDEiBCC5odTpn3LkRKP0GNOoOg3hBpMhNEW0MDzURofSbODQjDBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGa BgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQD ExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTCBnAYLKoZI hvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpT dGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTANBgkqhkiG9w0B AQEFAASCAQCMVa5cjSUgUlUZ6Uiv6xjba5pU0w16LTg0pmxbi82ryKF/ZXNL6kydq268uplz Vo03xAN7BVWeb1Chl9M6Mh3f+6eUkCQQFt4edbadmRwZN8mnGFciiSrKU8Kr9EA4wbTzTqXA z2oEAacxDwcaAwl3zc92yQh7ln8tQw+gS+D3m3Zxo0oHnO277GSS04hh8NXWc/2NfkmySac/ N9n5fzkrpo6LT+/bzY7yOaHGwb3xVRfvF+RGJmB3vXBhUiKBtAE50KbBq6cg1ie5+/Qvxs2H LV30jmP/w7RqPkpjb5L26FXDPR0Kg+4zFb0NrzHVZ2AbRE8a9BTMgxILFeIsP/B1AAAAAAAA --------------ms090503000803060606010006-- From nobody Tue Nov 15 20:31:36 2016 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 177731294F7 for ; Tue, 15 Nov 2016 20:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdokJ9cb-Jr6 for ; Tue, 15 Nov 2016 20:31:33 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 7D366129641 for ; Tue, 15 Nov 2016 20:31:33 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id g23so212578122wme.1 for ; Tue, 15 Nov 2016 20:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l5dduX44PjEvgrFocz69QjVBknJVEhHipRccCWZAd5U=; b=a9H98hvEcF5qRPGwkPjTceYmjRxS78oyjz22UpgXgwxaoy9goJUZG+DHXSR4B14BPq Ly2A7n+j0QaCm2lbiKNpojLA/QVILwMEpu1JYCHZqj7v8ef8ExNPCnZyv7jSWr1iIzlI 9j+PTsl/EbcBnz+ul2Thgs+aXKBQkp6xrMGXe/+y4wANWexCkpgNoZKOaQ5PvEzGQQgR CnG8zaz0qB/vNGI8+ShmhJyUkkej31P/OhszWh6PIQAvvmPoVdYB06hhC5InZRPJAm0W VRu0cZwtMw9cKGX9nYTymqcZMzq79xQr78TxEFrOTPGAl6XcoW5g+aj5Bef/fwJlewv2 qyXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l5dduX44PjEvgrFocz69QjVBknJVEhHipRccCWZAd5U=; b=QWkr52qbYiG385yoPotLE025O71hxXxUjnHmvWjK8CQnsZkpzxAKsaZqjqku82n3hC UZmdK/mux7vAZ6NM050TnSV6+mJifEtHnCQzmynay7yXEokzILnKyAgmzG1dPnZv0CiM rCYO7ncL/4A26W0N4ty5x9JRnX1ives2Eg4wdKepYr0ZGfEErErxghscsW78O0suweXL iKLufBipsPLgIdmquTqS98dq+DQrZxjLfUxQ1Kj7NnKlt3VmBVxRUDJTYa87mo9yDhPf LeybBU/K9pE/E3EVdczXn7kMFqgoskcq8UxYWXFMbz+Om2vJFHByBfqeXuliUMfSqTx6 gKNA== X-Gm-Message-State: ABUngvc6T8IreTgrV83TS6CFwn9hntiHZDBxOMiyumWNcJsxGbaZxCX5YKzp2++/MmQ970qFdGtR8xkkzfpFTA== X-Received: by 10.25.190.79 with SMTP id o76mr327502lff.56.1479270691989; Tue, 15 Nov 2016 20:31:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.24.209 with HTTP; Tue, 15 Nov 2016 20:30:51 -0800 (PST) In-Reply-To: <582BDCBF.70606@gmail.com> References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> From: Ted Lemon Date: Wed, 16 Nov 2016 13:30:51 +0900 Message-ID: To: Doug Royer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 04:31:35 -0000 Doug, the fact that you have a separate email account for your mobile device is _because_ IMAP requires you download all the headers. IMAP is perfectly capable of keeping a subset of all message bodies. But it's this precise issue that I'm talking about when I say that the way IMAP solves this problem isn't good for constrained devices and links. Even my laptop can burn through an amazing amount of bandwidth syncing when there are only two new email messages. On Wed, Nov 16, 2016 at 1:12 PM, Doug Royer wrote: > On 11/15/2016 02:51 PM, Ted Lemon wrote: >> >> If both end maintain a versioned catalog, updating the catalog becomes a >> process of agreeing on a most recent common version, exchanging diffs >> from that, then fetching new messages or message metadata. >> >> This is a lot less chatty than IMAP. > > > The authoritative key is the message headers, not how the client or server > remember the messages. > > When a mailbox is opened, fetch the headers. The headers are not editable > and do not change once received in the mailbox, compare them. > > If there are some new messages, fetch what ever part of those new messages > you want offline. > > If there are missing ones, an authority already said "make this message go > away". So delete it from the client. > > Some MUAs tweak the message headers to indicate the message is read. Stop > that and use some other handshake or other flag. That's not a offline issue, > its a I read that message problem. > > The old Netscape communicator tweaked the received time. If the unit digits > of the time was even, it was an unread message. An odd number, the message > had been read. > > Header comparison on a shared 1MB (speed) computer was not an efficient > method on shared 56K Internets in the early 80's. Message 'numbers' are an > artifact of '/bin/mail[x]', the c-client derivatives, pine, ... > > Its a client presentation issue in those old clients. IMAP/POP clients used > them to number messages because a human had to type get me message XX by > hand. IMAP and POP protocols were an extension (almost a shorthand) of what > the user typed on the keyboard of those shared slow computers from a DUMB > terminal. Old school and unnecessary. > > If a client wants to display message by number, that's fine. However it > really has nothing to do with the 'key' (the headers) to the message. > > If some server tweaks the headers, then how will any program ever know that > its tweaked? It can't. It will look like the old one is deleted, and the new > one arrived. Delete it, fetch the newly tweaked message. > > Messages should not be edited or tweaked in the store. > > There is much text in IMAP protocols that describe fetching some, or a > select set of headers. Not needed any more. Get them all. its fast and a > much better key and sync solution. > > ---Mobile--- > > I have a separate email account for my mobile device, because I do not want > it downloading the tens of thousands of messages I have collected over the > decades. > > I have never met anyone that wanted to sync tens of thousands of emails to > their mobile device. However they can. > > The sync could be per server. Or could be per folder. Ether way, the message > headers are the key and its a client issue. > > -- > > Doug Royer - (http://DougRoyer.US) > DouglasRoyer@gmail.com > 714-989-6135 > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > From nobody Wed Nov 16 11:03:27 2016 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 29382129561 for ; Wed, 16 Nov 2016 11:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=gmail.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 0Le-uZTPeYm6 for ; Wed, 16 Nov 2016 11:03:23 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515BE128874 for ; Wed, 16 Nov 2016 11:03:23 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id t125so133512046ywc.1 for ; Wed, 16 Nov 2016 11:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=02LOttXhH7oaBi63EM7kyhIehPNd+a/TJHcmiCFNr8M=; b=NkV02p9iDyiiTOZETLjc6El6z2ZDH9YGPBl3H+S0HuktMg7LYe16yLZDGZ+go3Y8ni PhxoFjZPsR6vXKS5FOSxrPb0LvrW7eEnW5t03oOwM9v4WB/DYG+o48Rfaeh0iayLayLm 4anm4Zqvhwr+xXkR8UkLw4lJXN7h8NUtqcpnsp/hq9hvOFlTbyUSQPgDY2wbDAVrjmU/ JqIPWDQLxWMAqjDxKY6s7IyI7piotczJs1n14xoqwAiR37ZeSGCpOXBDjh6n03cU7u3K Uz9XyzwhLh9FVuomh+0aMOi9Cxzjm8y3fm2v8W2vUKcHsR93wtWMtCc4mAA2b+lQZkic DA8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=02LOttXhH7oaBi63EM7kyhIehPNd+a/TJHcmiCFNr8M=; b=GBCM6GNpXNciaQv9I2Jz9i0KlF3D1ttSgRkrIbXoGnPowVi6R6LQ/jkYEB9Ff6+0XX ajY2RxFDcFsZlf/txVQZO+7p/UisjfAUZCZHrEcLylopn3rUl6UbowbQt9VNzrt91RLX GMv8UFUdpRcAlP5XygskiI+M0y5mFs9bMnO3o7Bky0JtNFY1m72ksUp3UedJSNC4Je54 DSgIhyULdH6nK3zfm7qNTCAnFRiNPf3JfvJiz7/KlagxRSILqUnLwyM0DggRzZk4pxWJ 7g9aHFJizZ57pOm0b2SRIEmzMHwg1SlIJsc54frmooVgCbDrOyd3kSs9WwT2wbjIk/im Nr5w== X-Gm-Message-State: ABUngvf7SpixXPCJBJ2PgPSwsofX8YkYQi6/Zy96k58KlFSgavbUo71mhEzl9K482V6T2w== X-Received: by 10.157.46.135 with SMTP id w7mr3139850ota.64.1479323002085; Wed, 16 Nov 2016 11:03:22 -0800 (PST) Received: from [192.168.1.4] ([168.103.130.82]) by smtp.googlemail.com with ESMTPSA id o28sm10787214otb.22.2016.11.16.11.03.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 11:03:21 -0800 (PST) To: jmap@ietf.org References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <582CAD78.90608@gmail.com> Date: Wed, 16 Nov 2016 12:03:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020508080708070400020001" Archived-At: Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 19:03:25 -0000 This is a cryptographically signed message in MIME format. --------------ms020508080708070400020001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/15/2016 09:30 PM, Ted Lemon wrote: > Doug, the fact that you have a separate email account for your mobile > device is _because_ IMAP requires you download all the headers. Maybe I am confused with some if the terms. So for this email: Offline - The MUA wants the entire MIME message at the MUA end. Sync - I am not doing offline storage, so a protocol is needed to update = each end with asynchronous changes at the other end. I have a separate phone email because I don't want GIGs of email on my=20 phone. The Android phone apps offline the entire account, not just named = folders, it gets the headers and all of the messages. A flaw in the MUA=20 in my opinion. If you do not want offline storage then its a how do I get only the new=20 display information debate, or selective messages - Update headers sync, = and download. Sync. If your talking about accessing an IMAP account from a laptop while your = phone is also connected to the same IMAP account, and have the active=20 one update the data in the passive one, then that is an update debate -=20 Sync. Offline is simple. Its a copy what ever is new. If they have the same=20 file format an MUA could use rsync and not IMAP. A tweaked rsync=20 protocol for offline email may be a better solution. Maybe we could=20 define a virtual folder format so rsync could be used for offline. If you going to have messages for offline usage, your going to get all=20 of the headers and content anyway. When doing offline, the server should just say. Here is a new message,=20 its ZZ octets in length, and here it is, in raw over the wire MIME=20 format. (perhaps compressed over the wire). Because if the folder is=20 being stored offline, then the MUA has already said it wants all of the=20 headers and content. So no chatter needed. > IMAP is perfectly capable of keeping a subset of all message bodies. = But > it's this precise issue that I'm talking about when I say that the way > IMAP solves this problem isn't good for constrained devices and links. > Even my laptop can burn through an amazing amount of bandwidth > syncing when there are only two new email messages. IMAP - yes. And if the messages are large, not just because of the=20 headers. A few times I have tried to debug an IMAP session and it was=20 amazing how much back and forth was sent, most of which seemed=20 unnecessary. Mostly I suspected a badly written implementation. And yes, non-offline sync is more complex. --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms020508080708070400020001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CuwwggUCMIID6qADAgECAhAdBOVkkNcrCTidq3YMdkiJMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwNDA3MTQyMjU5WhcNMTcwNDA3MTQyMjU5WjBIMR8wHQYDVQQDDBZkb3Vn bGFzcm95ZXJAZ21haWwuY29tMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwpXz2U03EAEwBMtWerSb3KUI IfTw2/55rms1TwBY+p4Jj7x4DWTlBF6Ur5rdFF70bydWtDGILvSI3BNY2eXjZzbSXl5HCmvZ gUNnYFw6SJkb4S7edV5VdXVdOAVh24y0OBWqedbbuT8eVDZfPTy1mOuUbZo0I0tCoa1Hky14 UDb2qtPKw2Wfn9o2ksubBvn2b0UZlPahGFAcC/qc8M9h0O1G1hsn0BIowvVdr73/Q17Znr9u J/CBaCkNCM2tzH5j1qov7hRRZmeb7mVHrf/Dina9JjBAKsz52KZczLqPz1mSycKiEKc/k0ag FNtl0l6tCpUcoHwzBQ6dlbNOQEtE2QIDAQABo4IBuTCCAbUwDgYDVR0PAQH/BAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQkN0Oa JE+zG3ATs7D0DgRxVGx0fzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggr BgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5Bggr BgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQx LmNybDAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJAZ21haWwuY29tMCMGA1UdEgQcMBqGGGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIFMCwwKgYI KwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsF AAOCAQEAhAL0TajC+aJEbVC9q1elm0H0qgeCyW7EpLcfg8Lxwz/B9r6LvgoDzyS2afLecviF dy37I6jKVIAQH4RmAzVRwkSr1BHAl9TjSIQvlSbanoRnkLxJSWOr5fBiqbwrogv7K10tRGwN +86UIBvfear2f9epnMcI9d/hs4y6t41/uHlU76X5NdHIladYznv2YbZ9RJHUgaQvVYPkMzhA 8AqIVw/2r+RCJLA65Nf1prGxgQhTeA/JjTLVgjaO3AMtj9OQ/xm8NNVXhvLhRzhTXrXbux2q xWjYrPcMTiTrtsQyAZ9kbTaf5S2BErTA6EK5RQfZWFZCIlgI5XhVoHhOAMAchjCCBeIwggPK oAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d5 2DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8 wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDt VB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwv IjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1 ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtG K8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0 BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTAN BgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdOruKb rWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM 3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/ b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uV rZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDT agXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SW JQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0f QoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8 wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S 4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIB ATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBAhAdBOVkkNcrCTidq3YMdkiJMA0GCWCGSAFlAwQCAQUAoIICEzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMTYxOTAzMjBa MC8GCSqGSIb3DQEJBDEiBCCQ+HDupB/H+IljBWzsO/me4JlQxsIRWtzsfZsvf/oDqzBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGa BgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQD ExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTCBnAYLKoZI hvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpT dGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTANBgkqhkiG9w0B AQEFAASCAQA+tj1qftCPdrjmLvEaPmw4oHcPp+ULseJ+9aQBdmp0k+YNjKf4JKVMf4o5uWgo HxEdEhOUOIpBLURcPtXixr3GSKkIng0lPFBWJgvswKjTScJBV8W4jwIErFScmOoqAp/Xcq+h D6gOUqqJ9ZscaUDihIW0mzkmICp8e0AW+D0qZw5l2G3KPBULs9pQdLHfpXc9NxclbkFE4Tyn izQHxbLx6/uaozX0jXFGUnzIz2FzUWRdYblALLF79A5xMtoXz9ad37nXwrZSdP14Gbqvx5oH 6ZXNXKjtagJnzVbDQtRSDZVK21txVZlj9fTSUnpBbvUiwEdN3mJV74FsspPiT9TYAAAAAAAA --------------ms020508080708070400020001-- From nobody Wed Nov 16 12:44:04 2016 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 02B0D1294C9 for ; Wed, 16 Nov 2016 12:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbeVRtrqspjr for ; Wed, 16 Nov 2016 12:44:01 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992F9129491 for ; Wed, 16 Nov 2016 12:44:01 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id g23so265777612wme.1 for ; Wed, 16 Nov 2016 12:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vn9abVGv9fozok/uZXxDmROsqsXIGFL3U7GI2aE4k2k=; b=qfSAd7Ij7Uaz8YWEnSqpvjhiGnLph1skefg8zh3EKC4umcXRl740SBnM2Qx44SrsUV JY6ow5bN5Bxx/DE6de4OMGmP28hrMvpU6NZhYRiMnvo9kQ3nn4vwVLKH1ZUcqwoo7XUl z8ZOqb9YfW/aED3cRWoMipb/AFxGUyPmhr0NjYle+F6dGYW7P/+K1k0KUkYFEeXXeM93 Wybj7gXRBiXhSONYqDzYOXrztVNAOuAh63XHp0EmSU7SZIECO247Q+jpunqBfZaJpS1z BskQomtNjuiyDjK+KZo73TnAh58wVFPTdqdWjh8ZOT3OZBd8BwTzrhuNBPXeZIp9PhvQ Rb7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vn9abVGv9fozok/uZXxDmROsqsXIGFL3U7GI2aE4k2k=; b=JqIEqFrvkHk3qvKa4q2APvVxdujPWWG+bxY3OPvg5k4+VsCKz7/+ZEzV+elYeLvB6v tsJCoAG31JNz+FtDwBJBTMLpGsb/tHZG64yN5vYdFVk4AJGSNA4EC8n2jKT0XpYBWmX7 4qsqccwU2B9BU5VXtjQ44Lp2FX872d+X8OKpfmCKXE8v5qrT3diRtV5XFKVbIM3uz/gI Nk3BiKb8mTMbXIs3pqEhUeL+MXhL+P+bm7+mOOu4/XTk8dSRwVGBep9df885MK/1rHBs eFsbqpNmxA2iJRxj1eqEMOa6PgozRaK/iYxTPaOebDH740fFAkYrBM6RB34H0kgKHYSI wsnA== X-Gm-Message-State: ABUngvf9ItR9JSv0W22p98XcOMpguUxrSWZdh3sxdng3hsx/fT00fczmWyeLBRkKMcXtYDuBZlNQyDGpHKavVA== X-Received: by 10.25.215.208 with SMTP id q77mr1645305lfi.126.1479329039865; Wed, 16 Nov 2016 12:43:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.43.210 with HTTP; Wed, 16 Nov 2016 12:43:19 -0800 (PST) In-Reply-To: <582CAD78.90608@gmail.com> References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> <582CAD78.90608@gmail.com> From: Ted Lemon Date: Thu, 17 Nov 2016 05:43:19 +0900 Message-ID: To: Doug Royer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 20:44:04 -0000 Doug, I don't know if I'm being redundant here or if clarification is needed, so I'll do my best to clarify, but if this still doesn't make sense to you, we should probably drop it rather than iterating again. First, it is a _bug_ that the MUA will only download the complete set of messages. It's also not true on my android phone--I have an imap setup, and the phone doesn't download gigabytes of messages. That said, the amount of metadata that needs to be synced to be sure that you have a correct set of metadata is gigantic, and there is no mechanism for eliminating redundant re-downloading of metadata. Doing that is not hard--it just requires that the dataset be versioned. When you download the dataset the first time, the server tells you what version you have. When you connect later after having been offline, you tell the server what version you have, and it sends you the changes, not the whole dataset. If you have made changes, you send your changes. If there are conflicts, there's a conflict resolution process. As a consequence, if 100 messages have arrived since you were last connected, the maximum amount of metadata the server should ever send you is the metadata for 100 messages, even if you have 100k messages in your mail store. Right now, my IMAP client on my Mac routinely downloads the entire 100k messages worth of metadata just to make sure that it has a correct picture of what's in the mail store, because (as far as I know, not an IMAP expert) there is no versioning process like I've described. So that's what I'm arguing about. I don't know if it makes sense to you, or if it's an operational issue that anybody here considers worth talking about. It's definitely derailing a bit; I only mentioned it because the topic came up in the chartering discussion. On Thu, Nov 17, 2016 at 4:03 AM, Doug Royer wrote: > On 11/15/2016 09:30 PM, Ted Lemon wrote: >> >> Doug, the fact that you have a separate email account for your mobile >> device is _because_ IMAP requires you download all the headers. > > > Maybe I am confused with some if the terms. So for this email: > > Offline - The MUA wants the entire MIME message at the MUA end. > > Sync - I am not doing offline storage, so a protocol is needed to update > each end with asynchronous changes at the other end. > > I have a separate phone email because I don't want GIGs of email on my > phone. The Android phone apps offline the entire account, not just named > folders, it gets the headers and all of the messages. A flaw in the MUA in > my opinion. > > If you do not want offline storage then its a how do I get only the new > display information debate, or selective messages - Update headers sync, and > download. Sync. > > If your talking about accessing an IMAP account from a laptop while your > phone is also connected to the same IMAP account, and have the active one > update the data in the passive one, then that is an update debate - Sync. > > Offline is simple. Its a copy what ever is new. If they have the same file > format an MUA could use rsync and not IMAP. A tweaked rsync protocol for > offline email may be a better solution. Maybe we could define a virtual > folder format so rsync could be used for offline. > > If you going to have messages for offline usage, your going to get all of > the headers and content anyway. > > When doing offline, the server should just say. Here is a new message, its > ZZ octets in length, and here it is, in raw over the wire MIME format. > (perhaps compressed over the wire). Because if the folder is being stored > offline, then the MUA has already said it wants all of the headers and > content. So no chatter needed. > >> IMAP is perfectly capable of keeping a subset of all message bodies. But >> it's this precise issue that I'm talking about when I say that the way >> IMAP solves this problem isn't good for constrained devices and links. >> Even my laptop can burn through an amazing amount of bandwidth >> syncing when there are only two new email messages. > > > IMAP - yes. And if the messages are large, not just because of the headers. > A few times I have tried to debug an IMAP session and it was amazing how > much back and forth was sent, most of which seemed unnecessary. Mostly I > suspected a badly written implementation. > > And yes, non-offline sync is more complex. > > > -- > > Doug Royer - (http://DougRoyer.US) > DouglasRoyer@gmail.com > 714-989-6135 > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > From nobody Wed Nov 16 14:47:51 2016 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 0E1E31294AA for ; Wed, 16 Nov 2016 14:47:50 -0800 (PST) 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 (2048-bit key) header.d=teamaol.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 fMvuUG67Lkt7 for ; Wed, 16 Nov 2016 14:47:48 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3113129432 for ; Wed, 16 Nov 2016 14:47:47 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id p66so83800647pga.2 for ; Wed, 16 Nov 2016 14:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol.com; s=google; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9q8gO9l0xT0amDRylvUrYSVi+gj62dkv3m3zBdSbqN4=; b=RhnfR1mnSn5e2AU+oN6b8j1qqyAGu5fb0Ght7YnBYJzK4482hGmXsqjn4ggocf1WMb SfPqfJ2+SChpY9lSu6WVlP3A0LhlbVasq+30fw8xkKznkCD6PLC162ZigtOqP+Gmu/cD QGIuGW9oxhIx+gy171VOymOB1JgyebxGEq3sGp7yLmn8aYCrKj6ZWTKae59yrBbKIhSX PQx3bYrR6tZA89dg76D5xzW/WMv/QGW5eLlUrkqPG0E7ceKg/QTqBwUiaQxXHDNPL9H9 /uzvcOxqgtgy0cx3zcrQLuSp374O8V+WHMiknHARylRSga7BoGK0RZgTSPgfOHwyxQ13 Qdow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9q8gO9l0xT0amDRylvUrYSVi+gj62dkv3m3zBdSbqN4=; b=IXH4G2kva2cfTfHiTxCTQtzjyUinxbPFLwhXw1DYgaYj5AG3iRnX4Q3tZ9I8LT/pqR CkoVDJuzdxbqjZ472kFavaZnDcRb9N6UqPg0dcJKHcM1IcdJqELPwtoWkBKG/2SWCB79 pEiu8DmVHC0tS/lWvoXvXnWDLKMtcWCvIjsxdzvhzGY3ZCzGjlwOIQTWXQoA3jmM98zA dqTzM+UUhysikEW3oFclHaoDY+LYz+fw3bdRFZD/FpOoVgVQ6Egbm3u5lMQdP58p2KBP IUQU8Mu+618h4JVMqoOWH00QOUWnVgKbuBfjDqKGf3oe+U3BT3SQi0NvbS0i4mbNanW5 WX/A== X-Gm-Message-State: ABUngvfqKzMwOqEdz2tV8uPiQ8GfGEqf06I6Q32i/admQ2fSkHD+LkNx9ZUvNnqk5OWC+lJv X-Received: by 10.99.208.21 with SMTP id z21mr13486096pgf.79.1479336467199; Wed, 16 Nov 2016 14:47:47 -0800 (PST) Received: from [10.172.167.74] ([64.236.138.3]) by smtp.gmail.com with ESMTPSA id a22sm76681pfg.7.2016.11.16.14.47.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 14:47:46 -0800 (PST) To: jmap@ietf.org References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> <582CAD78.90608@gmail.com> From: Stu Brandt Message-ID: <3af8ee06-26d4-d8fb-8696-fba8cd4ff116@teamaol.com> Date: Wed, 16 Nov 2016 17:47:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ted Lemon Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 22:47:50 -0000 Does rfc7162 cover your point? I believe JMAP attempts to cover this concept via the sinceState argument. Cheers - Stuart On 11/16/16 3:43 PM, Ted Lemon wrote: > Doug, I don't know if I'm being redundant here or if clarification is > needed, so I'll do my best to clarify, but if this still doesn't make > sense to you, we should probably drop it rather than iterating again. > > First, it is a _bug_ that the MUA will only download the complete set > of messages. It's also not true on my android phone--I have an imap > setup, and the phone doesn't download gigabytes of messages. > > That said, the amount of metadata that needs to be synced to be sure > that you have a correct set of metadata is gigantic, and there is no > mechanism for eliminating redundant re-downloading of metadata. > Doing that is not hard--it just requires that the dataset be > versioned. When you download the dataset the first time, the server > tells you what version you have. When you connect later after having > been offline, you tell the server what version you have, and it sends > you the changes, not the whole dataset. If you have made changes, you > send your changes. If there are conflicts, there's a conflict > resolution process. > > As a consequence, if 100 messages have arrived since you were last > connected, the maximum amount of metadata the server should ever send > you is the metadata for 100 messages, even if you have 100k messages > in your mail store. > > Right now, my IMAP client on my Mac routinely downloads the entire > 100k messages worth of metadata just to make sure that it has a > correct picture of what's in the mail store, because (as far as I > know, not an IMAP expert) there is no versioning process like I've > described. > > So that's what I'm arguing about. I don't know if it makes sense to > you, or if it's an operational issue that anybody here considers worth > talking about. It's definitely derailing a bit; I only mentioned it > because the topic came up in the chartering discussion. > > On Thu, Nov 17, 2016 at 4:03 AM, Doug Royer wrote: >> On 11/15/2016 09:30 PM, Ted Lemon wrote: >>> Doug, the fact that you have a separate email account for your mobile >>> device is _because_ IMAP requires you download all the headers. >> >> Maybe I am confused with some if the terms. So for this email: >> >> Offline - The MUA wants the entire MIME message at the MUA end. >> >> Sync - I am not doing offline storage, so a protocol is needed to update >> each end with asynchronous changes at the other end. >> >> I have a separate phone email because I don't want GIGs of email on my >> phone. The Android phone apps offline the entire account, not just named >> folders, it gets the headers and all of the messages. A flaw in the MUA in >> my opinion. >> >> If you do not want offline storage then its a how do I get only the new >> display information debate, or selective messages - Update headers sync, and >> download. Sync. >> >> If your talking about accessing an IMAP account from a laptop while your >> phone is also connected to the same IMAP account, and have the active one >> update the data in the passive one, then that is an update debate - Sync. >> >> Offline is simple. Its a copy what ever is new. If they have the same file >> format an MUA could use rsync and not IMAP. A tweaked rsync protocol for >> offline email may be a better solution. Maybe we could define a virtual >> folder format so rsync could be used for offline. >> >> If you going to have messages for offline usage, your going to get all of >> the headers and content anyway. >> >> When doing offline, the server should just say. Here is a new message, its >> ZZ octets in length, and here it is, in raw over the wire MIME format. >> (perhaps compressed over the wire). Because if the folder is being stored >> offline, then the MUA has already said it wants all of the headers and >> content. So no chatter needed. >> >>> IMAP is perfectly capable of keeping a subset of all message bodies. But >>> it's this precise issue that I'm talking about when I say that the way >>> IMAP solves this problem isn't good for constrained devices and links. >>> Even my laptop can burn through an amazing amount of bandwidth >>> syncing when there are only two new email messages. >> >> IMAP - yes. And if the messages are large, not just because of the headers. >> A few times I have tried to debug an IMAP session and it was amazing how >> much back and forth was sent, most of which seemed unnecessary. Mostly I >> suspected a badly written implementation. >> >> And yes, non-offline sync is more complex. >> >> >> -- >> >> Doug Royer - (http://DougRoyer.US) >> DouglasRoyer@gmail.com >> 714-989-6135 >> >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap >> > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Wed Nov 16 14:52:28 2016 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 402FF129432 for ; Wed, 16 Nov 2016 14:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2HfsHvK6PoW for ; Wed, 16 Nov 2016 14:52:25 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 157BB129570 for ; Wed, 16 Nov 2016 14:52:25 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id g23so272758654wme.1 for ; Wed, 16 Nov 2016 14:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QBreWcJ/nTjYD8ApPrw6px0OrR2oiQTzl99JFjoSZ64=; b=IkhesdsFIpymfZzECYCgKzmm1FlGCUalXqJ8DIBI55jb+ufoeFSAAVnizB3s0bO5CW sOVogqdHZJSXPFdDBsWb9dBXsP5lBzdglpJhVH0bQyfBHdLj1UF1UT+LAGliF3iPj9AH oy6dL6UAfPozstQXxUxF77NDW06ifDs62zXC8hmNgzkV6B8vrFnvrpXhJpOZ3xMuVRlU eQZMNcFDXcUyW+9THfGenrm6FNazk/Uipe0ADiA8bp9MLm1JZQR2i6ZguumpTyRG7I5v k9UkTo+iXyuW1AgedOe90mqR1TgrPs/chxUUHtJbLSou0djwZFeXz4CxWKNAUHuPEjUY BnHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QBreWcJ/nTjYD8ApPrw6px0OrR2oiQTzl99JFjoSZ64=; b=CEwfnD0tHoE5BO7WxVCloFr+BLSrTjqMYWgYUNh4N9VLD8WbSbO1tdc6s8C+HfdCqR OBBASGWOf+70IzQ/PraEbFgSWRWSrpbFc1uAUD0izjo2qB0avEPRO5SG3OqRqwFTXVpe Vg5TP/Q4ML5UXB66WYWXih6Nki9+aJmd0IMq9pBHidHU6f8Pkr4tc+9/9fTvQvpSEP/S OXXxtH4skaXrI/oc1Z6apG8mgCZcb6/F1YpUT21j4a+Eu8ycAuluXfmC7V49oVSURaaj 4KodwfG74CkvrgECCyEvX+izNgM1XicCrMycJ/dbR32eiA2taGhz9Mi6dJi2pj6zbgNG 574g== X-Gm-Message-State: ABUngvfBvIyUw54nEF8BvJAWnzNZt2CSCEfME/dXnVHASvVwhHOwRXXXpQTMujKXungTpCPGOyviNNN7FOWhpw== X-Received: by 10.25.215.208 with SMTP id q77mr153lfi.126.1479336743490; Wed, 16 Nov 2016 14:52:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.43.210 with HTTP; Wed, 16 Nov 2016 14:51:42 -0800 (PST) In-Reply-To: <3af8ee06-26d4-d8fb-8696-fba8cd4ff116@teamaol.com> References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> <582CAD78.90608@gmail.com> <3af8ee06-26d4-d8fb-8696-fba8cd4ff116@teamaol.com> From: Ted Lemon Date: Thu, 17 Nov 2016 07:51:42 +0900 Message-ID: To: Stu Brandt Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 22:52:27 -0000 I don't think it's using the right data model. The failure mode for not completing the transfer of a changeset should be that the partial changeset is discarded. Otherwise I can't see how you can be sure that the client has an accurate version of the mailbox state. Of course, I also think that mailboxes should be a separate object from the mail store, but that's a complete departure from the IMAP model. On Thu, Nov 17, 2016 at 7:47 AM, Stu Brandt wrote: > Does rfc7162 cover your point? I believe JMAP attempts to cover this > concept via the sinceState argument. > > Cheers > - Stuart > > > On 11/16/16 3:43 PM, Ted Lemon wrote: >> >> Doug, I don't know if I'm being redundant here or if clarification is >> needed, so I'll do my best to clarify, but if this still doesn't make >> sense to you, we should probably drop it rather than iterating again. >> >> First, it is a _bug_ that the MUA will only download the complete set >> of messages. It's also not true on my android phone--I have an imap >> setup, and the phone doesn't download gigabytes of messages. >> >> That said, the amount of metadata that needs to be synced to be sure >> that you have a correct set of metadata is gigantic, and there is no >> mechanism for eliminating redundant re-downloading of metadata. >> Doing that is not hard--it just requires that the dataset be >> versioned. When you download the dataset the first time, the server >> tells you what version you have. When you connect later after having >> been offline, you tell the server what version you have, and it sends >> you the changes, not the whole dataset. If you have made changes, you >> send your changes. If there are conflicts, there's a conflict >> resolution process. >> >> As a consequence, if 100 messages have arrived since you were last >> connected, the maximum amount of metadata the server should ever send >> you is the metadata for 100 messages, even if you have 100k messages >> in your mail store. >> >> Right now, my IMAP client on my Mac routinely downloads the entire >> 100k messages worth of metadata just to make sure that it has a >> correct picture of what's in the mail store, because (as far as I >> know, not an IMAP expert) there is no versioning process like I've >> described. >> >> So that's what I'm arguing about. I don't know if it makes sense to >> you, or if it's an operational issue that anybody here considers worth >> talking about. It's definitely derailing a bit; I only mentioned it >> because the topic came up in the chartering discussion. >> >> On Thu, Nov 17, 2016 at 4:03 AM, Doug Royer >> wrote: >>> >>> On 11/15/2016 09:30 PM, Ted Lemon wrote: >>>> >>>> Doug, the fact that you have a separate email account for your mobile >>>> device is _because_ IMAP requires you download all the headers. >>> >>> >>> Maybe I am confused with some if the terms. So for this email: >>> >>> Offline - The MUA wants the entire MIME message at the MUA end. >>> >>> Sync - I am not doing offline storage, so a protocol is needed to update >>> each end with asynchronous changes at the other end. >>> >>> I have a separate phone email because I don't want GIGs of email on my >>> phone. The Android phone apps offline the entire account, not just named >>> folders, it gets the headers and all of the messages. A flaw in the MUA >>> in >>> my opinion. >>> >>> If you do not want offline storage then its a how do I get only the new >>> display information debate, or selective messages - Update headers sync, >>> and >>> download. Sync. >>> >>> If your talking about accessing an IMAP account from a laptop while your >>> phone is also connected to the same IMAP account, and have the active one >>> update the data in the passive one, then that is an update debate - Sync. >>> >>> Offline is simple. Its a copy what ever is new. If they have the same >>> file >>> format an MUA could use rsync and not IMAP. A tweaked rsync protocol for >>> offline email may be a better solution. Maybe we could define a virtual >>> folder format so rsync could be used for offline. >>> >>> If you going to have messages for offline usage, your going to get all of >>> the headers and content anyway. >>> >>> When doing offline, the server should just say. Here is a new message, >>> its >>> ZZ octets in length, and here it is, in raw over the wire MIME format. >>> (perhaps compressed over the wire). Because if the folder is being stored >>> offline, then the MUA has already said it wants all of the headers and >>> content. So no chatter needed. >>> >>>> IMAP is perfectly capable of keeping a subset of all message bodies. >>>> But >>>> it's this precise issue that I'm talking about when I say that the way >>>> IMAP solves this problem isn't good for constrained devices and links. >>>> Even my laptop can burn through an amazing amount of bandwidth >>>> syncing when there are only two new email messages. >>> >>> >>> IMAP - yes. And if the messages are large, not just because of the >>> headers. >>> A few times I have tried to debug an IMAP session and it was amazing how >>> much back and forth was sent, most of which seemed unnecessary. Mostly I >>> suspected a badly written implementation. >>> >>> And yes, non-offline sync is more complex. >>> >>> >>> -- >>> >>> Doug Royer - (http://DougRoyer.US) >>> DouglasRoyer@gmail.com >>> 714-989-6135 >>> >>> >>> _______________________________________________ >>> Jmap mailing list >>> Jmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/jmap >>> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > > > From nobody Wed Nov 16 16:03:53 2016 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 2A4C9127A91 for ; Wed, 16 Nov 2016 16:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.com header.b=NhuXkm+6; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Gy9g2IbQ 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 24uO_hzuo8Rr for ; Wed, 16 Nov 2016 16:03:50 -0800 (PST) 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 AF942129400 for ; Wed, 16 Nov 2016 16:03:50 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2BB6B206C7 for ; Wed, 16 Nov 2016 19:03:50 -0500 (EST) Received: from betaweb1 ([10.202.2.10]) by compute1.internal (MEProxy); Wed, 16 Nov 2016 19:03:50 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=Y1B1G+s4suxGUXds9YtKC1CrpE A=; b=NhuXkm+6AmomEWGXe+A0iqvUAxQY9ZXFHSp4Wb+cdRM3kwEY6gRwRWYue/ /g8rSFnx66Ult0pOrSDJcLOraVGOoIFCp8r8Iol3apgY2KmwlFfNSqKORY4rUUTA 0Wcf94YlSYpY211j5YnGkrakJe4pgP2V+fOjTOMTjiC1+1P2s= DKIM-Signature: v=1; a=rsa-sha1; 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=smtpout; bh=Y1 B1G+s4suxGUXds9YtKC1CrpEA=; b=Gy9g2IbQRewNo9hhwkAGTCLSZ2Auy3YLCc WbFVQfAYXI5NLQcH2YjDTLAbOT7qC/I29D+dcMes1mNGmRRhAFKktFDbpL5TjfOf mMpZnCNGnnIsd8Sumx2y7WiDm0Z0RvEOvPqFtQ80BLJhLj9xWimS8ed5gR+vMX39 q4OH1/LQU= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DE939E244D; Wed, 16 Nov 2016 19:03:49 -0500 (EST) Message-Id: <1479341029.2748784.790282529.2A410D98@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ac2e1273 Date: Thu, 17 Nov 2016 11:03:49 +1100 References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> In-Reply-To: Archived-At: Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:03:52 -0000 On Wed, 16 Nov 2016, at 03:30 PM, Ted Lemon wrote: > Doug, the fact that you have a separate email account for your mobile > device is __because__ IMAP requires you download all the headers. Right! JMAP is explicitly designed to fix this problem. JMAP was designed with the idea that you would have a canonical data store on the server, and all clients would want to stay in sync with this (as opposed to POP, where different clients may fetch from the server but are entirely independent other than this). This is how all modern email clients work and what most people now expect. However, it also recognises that the data set may be huge, and you may not want or be able to download it all locally. There are a number of levels of caching/offline support a client may use, and JMAP has facilities to work efficiently with all of them. (Note, I'm using the term "message list" below to describe a sorted, filtered list of message ids, e.g. the ordered list of messages in your inbox.) 1. Empty cache JMAP provides methods and data structures to go from nothing to full display of your inbox list (most email clients default view) within two round trips and with minimal data transfer. This is great both for webmail and first setup of any MUA, as you can start using your email with a new client much more quickly than with IMAP. The data structures are also such that you can present the same view *as if you had the entire (possibly 100+ GB) dataset loaded locally*: you know the counts in the folders, how long your message list is (the server does sorting, thread collapsing for you), and the thread information for messages in view. You can jump to any part of the message list and load in just that section, allowing the client to provide full access to your mail without having to download it all, providing it has connectivity. 2. Disconnected partial sync This is most common for mobile apps, but could be any app: you want to make some of the data available offline, but not download the entire (possibly huge) archive. With JMAP, you can easily download just a subsection (say, first 100 ids) of the message lists for the mailboxes you want to make available offline, and then download the message contents themselves. I would expect most clients to get the easier and more compact parsed representation of the message, but they could fetch the raw RFC5322 if they prefer. JMAP uses state strings for each data type and has commands to make it possible to resync efficiently with the server when you come back online. The server can tell the client exactly which messages are new/changed or have been deleted since the last sync. Additionally, you can sync changes to the message lists efficiently too: the server can tell you want to insert and what to remove, without having to redownload the full list of ids. 3. Disconnected full sync This is really an easier case than (2) since you could just do (2) but not limit which mailboxes and how many messages you cached. Once you have your initial sync of everything on the server, you can just use getMessageUpdates to very efficiently get the changes since last time. --------- Despite living in an ever more connected world, offline support is still very important, and while I've just given a brief overview rather than technical deep dive, I hope this conveys that we've really thought about the different scenarios in which this will be used, and tried to make it as efficient as possible in each of them; certainly a significant leap forward from IMAP. Neil. From nobody Wed Nov 16 17:42:29 2016 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 7D0E11293FD for ; Wed, 16 Nov 2016 17:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=gmail.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 d6QY18C5Bk5t for ; Wed, 16 Nov 2016 17:42:21 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 BE472129627 for ; Wed, 16 Nov 2016 17:42:20 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id l8so105052174iti.1 for ; Wed, 16 Nov 2016 17:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to; bh=PH11V9HkAznLLf5u73IzuKGETPXeNLGOpjowbEAVtl0=; b=LrWGioo+TDAy2mm4Qx+9/3hcIqkrZCQ/tMghT9jA/xK2MhTlfGAigI0GNjQ2qcu7t0 5ghbnUfH61hcXq7/57HNWOUycZmTdRIrzza/ynWy/XtNN8CoQYXgRcWD929XKTyDkmfk lsn8uJEo7IRaio00Ky8ATL+gBZ6zvRAw82dDCqr+s2nfBL12M8DLZeVldOYR0BDC0wXJ +pSgtsnqDMsu7KL3Mf0rQJ2Ffv3z4G9epEahJtkXOHMvaTUutBcfRlwySQNq2KE/KwbV jbA7nRYt/vhnkN/mpGgeFkNtdUKdkCmhBwVqmeR3VVwD7D+CIUqXIiwKET0LPbAB45wd CmlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=PH11V9HkAznLLf5u73IzuKGETPXeNLGOpjowbEAVtl0=; b=i8F+8vAUFR896kPw1I1YjILh31v1OXrNW+hjgfrmYd96aSx4ie88R8Mei6g8134W7B GO0Yzvz7eUmopAMnr9a08tMTZ9zOmdvn1Mgd0tEkwP/1JBMXHH+zDol37xK26Xyd/yWr Z56zb7ki50XD9obae/PBhQYeAgPnV7+z94iw0XqD+CdvHOPMpPfLlzbz0NPRI2XtjNC8 /IWVS14dUXBSwiv0R+qPclkzEEbNUb40l3KOQ7F3ce6AzXRnOKbT/D5X+R1aAp2T6OMI JAoq4ActSilE8cAuV+u+kEill1ZcKzgusPMOGFjxtQ24UD+ELHHzcusMUXQbDdS47lPG Jg6A== X-Gm-Message-State: ABUngveYbPYk2scT2vfY6aaMMptp0/iTUoT9kuvM6ZLasdhLDoE0mv3fHgGGH7i8r1/Stg== X-Received: by 10.157.59.180 with SMTP id k49mr223368otc.255.1479346940035; Wed, 16 Nov 2016 17:42:20 -0800 (PST) Received: from [192.168.1.4] ([168.103.130.82]) by smtp.googlemail.com with ESMTPSA id 61sm237017otb.8.2016.11.16.17.42.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 17:42:19 -0800 (PST) To: Ted Lemon References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> <582CAD78.90608@gmail.com> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <582D0AFA.9000505@gmail.com> Date: Wed, 16 Nov 2016 18:42:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070802000903050509080700" Archived-At: Cc: jmap@ietf.org Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:42:22 -0000 This is a cryptographically signed message in MIME format. --------------ms070802000903050509080700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/16/2016 01:43 PM, Ted Lemon wrote: > Doug, I don't know if I'm being redundant here or if clarification is > needed, so I'll do my best to clarify, but if this still doesn't make > sense to you, we should probably drop it rather than iterating again. > > First, it is a _bug_ that the MUA will only download the complete set > of messages. It's also not true on my android phone--I have an imap > setup, and the phone doesn't download gigabytes of messages. I am not trying to debate, I am guessing we are not talking the same jarg= on. When I set my original email account on my android phone to store-for=20 OFFLINE reading mode (checked SYNC GMAIL in the gmail application), it=20 filled up my android, then crashed. I had to factory reset my phone. Then I created a 2nd gmail account to use as the phone primary email=20 address. I then added my original gmail account to my phone, and did NOT select=20 store for OFFLINE (unchecked SYNC GMAIL in the gmail application), and I = can read my original gmail account, and it does not copy the mailbox to=20 the phone. And does not have those messages available for offline reading= =2E My new email is in offline for reading mode (gmail app calls it 'sync=20 gmail'). My old email is in online only reading mode. The 'official gmail' app: I have no idea if it uses IMAP, POP, or=20 something they created. I do know if you set it for offline reading, it=20 copied my entire (GIGs) account (all folders, all mailboxes for that=20 account). With Seamonkey (Spin of Thunderbird). I have "Keep messages for this=20 account in this computer" checked (offline reading mode). It downloaded=20 all messages with I first initialized it. It took more than a day. And=20 the messages are stored in my home Linux box, AND on the gmail server. Looking at the amount of traffic when I start seamonkey, it does not=20 seem to download all headers for my gmail IMAP account. So, I am=20 guessing the apple app your talking about is a inefficient implementation= =2E --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms070802000903050509080700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CuwwggUCMIID6qADAgECAhAdBOVkkNcrCTidq3YMdkiJMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwNDA3MTQyMjU5WhcNMTcwNDA3MTQyMjU5WjBIMR8wHQYDVQQDDBZkb3Vn bGFzcm95ZXJAZ21haWwuY29tMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwpXz2U03EAEwBMtWerSb3KUI IfTw2/55rms1TwBY+p4Jj7x4DWTlBF6Ur5rdFF70bydWtDGILvSI3BNY2eXjZzbSXl5HCmvZ gUNnYFw6SJkb4S7edV5VdXVdOAVh24y0OBWqedbbuT8eVDZfPTy1mOuUbZo0I0tCoa1Hky14 UDb2qtPKw2Wfn9o2ksubBvn2b0UZlPahGFAcC/qc8M9h0O1G1hsn0BIowvVdr73/Q17Znr9u J/CBaCkNCM2tzH5j1qov7hRRZmeb7mVHrf/Dina9JjBAKsz52KZczLqPz1mSycKiEKc/k0ag FNtl0l6tCpUcoHwzBQ6dlbNOQEtE2QIDAQABo4IBuTCCAbUwDgYDVR0PAQH/BAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQkN0Oa JE+zG3ATs7D0DgRxVGx0fzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggr BgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5Bggr BgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQx LmNybDAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJAZ21haWwuY29tMCMGA1UdEgQcMBqGGGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIFMCwwKgYI KwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsF AAOCAQEAhAL0TajC+aJEbVC9q1elm0H0qgeCyW7EpLcfg8Lxwz/B9r6LvgoDzyS2afLecviF dy37I6jKVIAQH4RmAzVRwkSr1BHAl9TjSIQvlSbanoRnkLxJSWOr5fBiqbwrogv7K10tRGwN +86UIBvfear2f9epnMcI9d/hs4y6t41/uHlU76X5NdHIladYznv2YbZ9RJHUgaQvVYPkMzhA 8AqIVw/2r+RCJLA65Nf1prGxgQhTeA/JjTLVgjaO3AMtj9OQ/xm8NNVXhvLhRzhTXrXbux2q xWjYrPcMTiTrtsQyAZ9kbTaf5S2BErTA6EK5RQfZWFZCIlgI5XhVoHhOAMAchjCCBeIwggPK oAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d5 2DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8 wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDt VB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwv IjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1 ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtG K8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0 BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTAN BgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdOruKb rWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM 3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/ b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uV rZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDT agXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SW JQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0f QoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8 wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S 4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIB ATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBAhAdBOVkkNcrCTidq3YMdkiJMA0GCWCGSAFlAwQCAQUAoIICEzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMTcwMTQyMTha MC8GCSqGSIb3DQEJBDEiBCCrTxQWpimcmGAHiDfpNph7jBK0P+rvT9SPIwAQmBniATBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGa BgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQD ExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTCBnAYLKoZI hvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpT dGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTANBgkqhkiG9w0B AQEFAASCAQBJ6qk5y9fhsVfcfMmRAlvVPu0kI1Ob/fkA7a7SX1lSOqB4fXgLucbNmBhsXc+g MPnLxr4Nd9Ihh9IK8wd20K7RvD17OYmekZ2oRvF/oLTJrCUZsLlMK+ZnO9bbMbIXaJeW7Zq4 /j3niFNVC1hnl4AqZ9RVq+3e1wSszzyivSS2f/aXZhq71D1/5oE6zyFPWEg58ocYBz30WKy0 tUxDKnWqiTpDrjoAMMnMmKnRDzsyeSTkkfneyplhTzVikK1x94ph16J7w5Ok3mlEk6coW+3z EtyRBbJdtzEptZ01wGQZicZux5UUlUdlRpG94lj+i1Kz52cgiVOJM3LHG5MQSM/bAAAAAAAA --------------ms070802000903050509080700-- From nobody Thu Nov 17 14:00:01 2016 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 71F7D1294B3 for ; Thu, 17 Nov 2016 14:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, 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 KKsUrLLfNq6J for ; Thu, 17 Nov 2016 13:59:59 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 337D212947E for ; Thu, 17 Nov 2016 13:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479419998; d=isode.com; s=june2016; i=@isode.com; bh=zQmMS0zmsdOXxdihvTV7+eCW1+2+4rIf3CU1K5AgOvQ=; 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=ijqzBg2+XSdIdnPJnbx/Geve2lWzXTIzG5WYBG0XWRyUqW+Js8m/GlYD4MIFvnJWUouVMK 4fU7NesmZHkSc3ZI/Po2Qb/w1NqoAe6Ucp1E6tVfCNAIrO1TV5/nueKCKthcr+atzVkf/e 7Kob7JV/yn8hGpG4Ka8Ya8Ds6Le7q/c=; Received: from [192.168.219.191] ((unknown) [106.255.97.69]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 17 Nov 2016 21:59:58 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: Date: Fri, 18 Nov 2016 07:15:10 +0900 Message-Id: References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> <582CAD78.90608@gmail.com> To: Ted Lemon MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: jmap@ietf.org, Doug Royer Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:00:00 -0000 Ted, > On 17 Nov 2016, at 05:43, Ted Lemon wrote: >=20 > That said, the amount of metadata that needs to be synced to be sure > that you have a correct set of metadata is gigantic, and there is no > mechanism for eliminating redundant re-downloading of metadata. > Doing that is not hard--it just requires that the dataset be > versioned. When you download the dataset the first time, the server > tells you what version you have. When you connect later after having > been offline, you tell the server what version you have, and it sends > you the changes, not the whole dataset. If you have made changes, you > send your changes. If there are conflicts, there's a conflict > resolution process. >=20 > As a consequence, if 100 messages have arrived since you were last > connected, the maximum amount of metadata the server should ever send > you is the metadata for 100 messages, even if you have 100k messages > in your mail store. >=20 > Right now, my IMAP client on my Mac routinely downloads the entire > 100k messages worth of metadata just to make sure that it has a > correct picture of what's in the mail store, because (as far as I > know, not an IMAP expert) there is no versioning process like I've > described. This is covered by IMAP CONDSTORE and QRESYNC extensions. So either your ser= ver and client don't support these, or the client is badly written. Best Regards, Alexey From nobody Thu Nov 17 14:03:28 2016 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 E025712947E for ; Thu, 17 Nov 2016 14:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdhRX2Svu0Rt for ; Thu, 17 Nov 2016 14:03:26 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 C62E1129479 for ; Thu, 17 Nov 2016 14:03:25 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id a197so102823wmd.0 for ; Thu, 17 Nov 2016 14:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j1+iDxfpIG5FTbTapJwufQzYoV3cGNtXN6F8spWVdZE=; b=u7nSXMMlAa3KWRI83gEvVVEIoNFUNviNUHySeTaVwk6cORFDl2lJATZzTw2hj4Zd+Q bzhQI9AoRA8U58cXMctSYPwOHyaQFQLqR7iec9AcjwfZ5vm5zf/n4CJwrR+KwevnVKtV kSSsbCmrJrNtstTKJoieK8Wjqsp10BmXh7IpeJStP5M4/OHmJ+dewIkYlCqXeDse4B2G 4D04WgcI5Xad1cnXQ4PqlL6cN++gsUDAG+Ur5J8Jsq5iBxbLey7VRhPRTYSde3z8eZDr h+ol2pJmJudiQVQyrZQapiX2FQNt9rZarF84Mys725UJE1/f5BD23lpxS1yF62zId0lB XIhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j1+iDxfpIG5FTbTapJwufQzYoV3cGNtXN6F8spWVdZE=; b=DtIiDR9AQ8RS8TBMA2IakyPH3XCDYwP2W8nLa82TjvAid/ZaH7StpeSUDZ3XuSll8N Ra06jVBL4HeLYWM1hCfTDv819E15zJUCK7nRH2ipkrjw4fItYff9dF2p9UHOKW5bVfBr 6OnzqiwZ+dIRWaMYYLgN0lgEOViRhrjm/vC2hXfp6wV7frufoz3ystzkt8G02yzFxA6p 9hGLW9Q9CFMGF+d+T3lGnlIqvFrGdiz/ofVX5flA0ImD3sea1nsFSaRax5lmnFpnEC9M pXP2q3r3TnZs71hH86gGaAJr0klTyined1a3fhoPwrBQOhLu8tJbE2vGGpBzBHVsjoJX 8fRg== X-Gm-Message-State: ABUngve9/PtVdatsyXQ4IB5ZOcFHWXC+CpTDCQLY3zH7cQ79mDRF4DP+q22Ii3CfNkhxxM5YAQH3nYdTa17nkA== X-Received: by 10.25.23.25 with SMTP id n25mr1031741lfi.152.1479420204205; Thu, 17 Nov 2016 14:03:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.43.210 with HTTP; Thu, 17 Nov 2016 14:02:43 -0800 (PST) In-Reply-To: References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> <582CAD78.90608@gmail.com> From: Ted Lemon Date: Fri, 18 Nov 2016 07:02:43 +0900 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jmap@ietf.org, Doug Royer Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:03:28 -0000 Alexiy, I think the problem with CONDSTORE and QRESYNC is that the data model isn't good, and so you can't really feel secure that you actually have a correct picture of the whole mail store. So every so often you do a massive resync. It doesn't happen every time you check for mail, but with a better data model, it would only happen if there were no revisions of the metadata database in common between the two ends. On Fri, Nov 18, 2016 at 7:15 AM, Alexey Melnikov wrote: > Ted, > >> On 17 Nov 2016, at 05:43, Ted Lemon wrote: >> >> That said, the amount of metadata that needs to be synced to be sure >> that you have a correct set of metadata is gigantic, and there is no >> mechanism for eliminating redundant re-downloading of metadata. >> Doing that is not hard--it just requires that the dataset be >> versioned. When you download the dataset the first time, the server >> tells you what version you have. When you connect later after having >> been offline, you tell the server what version you have, and it sends >> you the changes, not the whole dataset. If you have made changes, you >> send your changes. If there are conflicts, there's a conflict >> resolution process. >> >> As a consequence, if 100 messages have arrived since you were last >> connected, the maximum amount of metadata the server should ever send >> you is the metadata for 100 messages, even if you have 100k messages >> in your mail store. >> >> Right now, my IMAP client on my Mac routinely downloads the entire >> 100k messages worth of metadata just to make sure that it has a >> correct picture of what's in the mail store, because (as far as I >> know, not an IMAP expert) there is no versioning process like I've >> described. > > This is covered by IMAP CONDSTORE and QRESYNC extensions. So either your server and client don't support these, or the client is badly written. > > Best Regards, > Alexey > From nobody Thu Nov 17 14:51:30 2016 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 476D7129474 for ; Thu, 17 Nov 2016 14:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 JYlj6-y8Bf3G for ; Thu, 17 Nov 2016 14:51:26 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 2CD2E1294C3 for ; Thu, 17 Nov 2016 14:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1479423085; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NUC0MUF70AaEcBwIUHPQFm9XcFUuliKo5m8sevMIz8g=; b=wFHngf2ztPsNFwgqbmx7Fm6WijJNGw2K/diJoUZAQIAfbiA+/acqwcxMK6cEcjng KRqf08CV5MWfEdVPULzGf3XXFqvYCQXDp87FqmHgpxyQcXFYY7H6p8ycf/kD3tF0 vIcHAlvtIWcUrll0mW+imXJIgA9gopPYn2vUMBlubu3or+pmm7JVy1cN+FZfISSk lvHeli6SW6Pr2xR+9Qa3/+FlhlKUnNRF/z746KduXwhZoRKlINB8cEsXmRT7eZH1 y9lABrIKBkdmyYKvUuc6gchidMaUu412pxOa0wyCV56uWbtb2ia4oHwgCXkJnXC3 wt+B4GKW86u5rJe16ZbzgA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id DD.59.09085.D643E285; Thu, 17 Nov 2016 14:51:25 -0800 (PST) X-AuditID: 11973e11-b4dfb7000000237d-e1-582e346de43a Received: from mailex13.apple.com (nwk-mbx16p-w02.pex.exch.apple.com [17.146.17.21]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id BD.A0.29380.D643E285; Thu, 17 Nov 2016 14:51:25 -0800 (PST) Received: from nwk-mbx16p-w01.pex.exch.apple.com (17.146.17.20) by nwk-mbx16p-w02.pex.exch.apple.com (17.146.17.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Thu, 17 Nov 2016 14:51:24 -0800 Received: from nwk-mbx16p-w01.pex.exch.apple.com ([17.146.17.20]) by nwk-mbx16p-w01.pex.exch.apple.com ([17.146.17.20]) with mapi id 15.01.0544.027; Thu, 17 Nov 2016 14:51:23 -0800 From: Neil Jhaveri To: Ted Lemon Thread-Topic: [Jmap] Offline / sync Thread-Index: AQHSQR3zFlf2xcnTRk2/A//YLb21+qDeQISAgAANmYA= Date: Thu, 17 Nov 2016 22:51:23 +0000 Message-ID: <3ACA7E47-FC61-4927-B38E-43FB2E2B6CB7@apple.com> References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> <582CAD78.90608@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [17.114.218.161] Content-Type: text/plain; charset="us-ascii" Content-ID: <39582E69DB1A8B49ABB2BD03748B56A1@pex.exch.apple.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUi2FCYpptrohdh0PbTwGLG6iKLyxN+sVn0 3p/BZvFmzREmBxaPpgvL2D12zrrL7rFkyU8mj1PNhgEsUVw2Kak5mWWpRfp2CVwZG6fvZy24 KFZxt38VcwPjdKEuRk4OCQETiXVTHzJ3MXJxCAnsY5TYPH0NM0zi67Fr7CC2kMAiJomXq80g ijqYJGZ1/GODcHYwSvRtfgbUwcHBJqAusflcGkiDiICCxNwza5hAbGaBcokzzecYQWxhASWJ 1Us2MEPUKEu8P7CVBaRVRMBKYtcPMZAwi4CqROfetWAlvAI2Env/N7FDrJrELjH/+l6wmZwC gRI7epvBZjIKiEl8PwWzS1zi1pP5TBAPCEgs2XMe6hlRiZeP/7FC2DoSZ68/YYSwlSQONm5k hujVkViw+xMbhO0osW7HbaiZ2hLLFr6GOkhQ4uTMJywgB0kIbGKXmLdoGeMERulZSHbPQjJr FpJZs5DMmoVk1gJG1lWMQrmJmTm6mXlGeokFBTmpesn5uZsYQRE/3U5wB+PxVVaHGAU4GJV4 eBed0o0QYk0sK67MPcQozcGiJM47iwMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgfFt+aFj j8tfd9ufT+jcyzpxcV0Je3Utf8PKt33LspklQ7kyX4WufMPlrq/ltGLice5Kp30GfZy93tOb tiYtSOW5sfl8Q5xa+BTLL1EfNpzieXZl/ZKf5++7fs+damw/y+BMmknAuVnKM/qX219P/bXu 7YI3VgXXdWe9PBEWdJ+lLTdbLerN441KLMUZiYZazEXFiQCznUHS2QIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRnCQoqptrohdh8HqGvMWM1UUWlyf8YrPo vT+DzeLNmiNMDiweTReWsXvsnHWX3WPJkp9MHqeaDQNYorhsUlJzMstSi/TtErgyNk7fz1pw Uazibv8q5gbG6UJdjJwcEgImEl+PXWOHsMUkLtxbzwZiCwksYpJ4udqsi5ELyO5gkpjV8Y8N wtnBKNG3+RlzFyMHB5uAusTmc2kgDSICChJzz6xhArGZBcolzjSfYwSxhQWUJFYv2cAMUaMs 8f7AVhaQVhEBK4ldP8RAwiwCqhKde9eClfAK2Ejs/d/EDrFqErvE/Ot7wWZyCgRK7OhtBpvJ CHTo91Mwu8Qlbj2ZzwTxgIDEkj3nmSFsUYmXj/+xQtg6EmevP2GEsJUkDjZuZIbo1ZFYsPsT G4TtKLFux22omdoSyxa+hjpIUOLkzCcsExglZyFZNwtJ+ywk7bOQtM9C0r6AkXUVo0BRak5i pYVeYkFBTqpecn7uJkZQ5DYUpu1gbFpudYhRgINRiYd3wSndCCHWxLLiytxDjBIczEoivBP0 9SKEeFMSK6tSi/Lji0pzUosPMSYDQ24is5Rocj4wqeSVxBuamBiYGBubGRubm5iTJqwkziv3 SSdCSCA9sSQ1OzW1ILUIZgsTB6dUA+MZNuYdM3c5aN2LCcw69r3HbsqhyKfpfzM+8C9fznHT ma0hf0rRuhznv+dDFhvaqq1tUNGak8rAzaD1Y3X/TcF0ceflb9ZbpDIUrH5UfK2JeQ7ProSz B8q8VTY/FXGNzXvmViN2Nb+Sa83erycMH23ry/nCIFvuIJTC7c2pzKo4cd+xY9uu2SmxFGck GmoxFxUnAgBziIHYIAMAAA== Archived-At: Cc: Alexey Melnikov , Doug Royer , "jmap@ietf.org" Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:51:28 -0000 > On Nov 17, 2016, at 2:02 PM, Ted Lemon wrote: >=20 > Alexiy, I think the problem with CONDSTORE and QRESYNC is that the > data model isn't good, and so you can't really feel secure that you > actually have a correct picture of the whole mail store. So every so > often you do a massive resync. It doesn't happen every time you > check for mail, but with a better data model, it would only happen if > there were no revisions of the metadata database in common between the > two ends. Out of curiosity, could you elaborate on some of these issues? Apple Mail supports both CONDSTORE and QRESYNC and, in our experience, they= have worked well and been implemented well enough by servers. We admittedl= y do have some fallback paths to resynchronize all UIDs and flags in specif= ic cases (e.g. syncing without CONDSTORE/QRESYNC), as we have seen some bug= s where we believed the servers had not computed history exactly correctly.= But we believed these to just be implementation bugs, and have encountered= similar problems with Exchange Web Services, too. Best, - Neil >=20 > On Fri, Nov 18, 2016 at 7:15 AM, Alexey Melnikov > wrote: >> Ted, >>=20 >>> On 17 Nov 2016, at 05:43, Ted Lemon wrote: >>>=20 >>> That said, the amount of metadata that needs to be synced to be sure >>> that you have a correct set of metadata is gigantic, and there is no >>> mechanism for eliminating redundant re-downloading of metadata. >>> Doing that is not hard--it just requires that the dataset be >>> versioned. When you download the dataset the first time, the server >>> tells you what version you have. When you connect later after having >>> been offline, you tell the server what version you have, and it sends >>> you the changes, not the whole dataset. If you have made changes, you >>> send your changes. If there are conflicts, there's a conflict >>> resolution process. >>>=20 >>> As a consequence, if 100 messages have arrived since you were last >>> connected, the maximum amount of metadata the server should ever send >>> you is the metadata for 100 messages, even if you have 100k messages >>> in your mail store. >>>=20 >>> Right now, my IMAP client on my Mac routinely downloads the entire >>> 100k messages worth of metadata just to make sure that it has a >>> correct picture of what's in the mail store, because (as far as I >>> know, not an IMAP expert) there is no versioning process like I've >>> described. >>=20 >> This is covered by IMAP CONDSTORE and QRESYNC extensions. So either your= server and client don't support these, or the client is badly written. >>=20 >> Best Regards, >> Alexey >>=20 >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Thu Nov 17 16:02:35 2016 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 4359B129587 for ; Thu, 17 Nov 2016 16:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw-U7UcuK-RV for ; Thu, 17 Nov 2016 16:02:32 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F62129581 for ; Thu, 17 Nov 2016 16:02:31 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id g23so4759406wme.1 for ; Thu, 17 Nov 2016 16:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZO6Gjh/nQWuwf5kyRB9I0M30Hpp2IyO+syhxsAT9BoQ=; b=HX8JvFoHOfIP1hl4aIMRWioq7jkSWWvvn+r6r56ScasDS6ph6PSsSgV6iDI9qqJ4L/ lna+yle0bSQU9uGz6tDlrrRv8byq4QQLVTI9YxPwajta+QIg6nrNyymKteRv0GrwFeLv GvNqhYp8SQvei4qbKGv6bVofe++ReBOjcy3LxFh3YB9mYCU34Tqpk+AcFswinz1J5Tdm DOYlU/fg2qR3cDWLRw9KmbKm5H7RkE0f/3xj4kXYJ+uznwIGrCIcZZwrwEtWc0wfc6Uj ws68JgbsBviDoeYXmSPn4kpyMAHhmAahpL2So31L1O1ctgNUE1hCjnGEfgCOawbW+wVi 4tIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZO6Gjh/nQWuwf5kyRB9I0M30Hpp2IyO+syhxsAT9BoQ=; b=CTBlt6lq+A4xuanp9J25Lszxaep17zxB9++DRHcIkdqxwBcmULRBJenny7LPRIofWV 0t/ahfcwXg8plmYgu890lKRYwwjjrNRVET2kVvMV8cS60Tt1N1vZwJke9fV+T1ZCellh uSUG1Civ0ACr9EERF9CLzWnfRYcj33nCel8y+YmxD7h0wE4mfDl/D39A+5lGxaIASfdV 2O0RHCWQ/ySZPvEmDI/Le3fQBgCsotGwJtpQV8QgBvMeM3zPAk91XIzYrR/5Yuz800ni lYecpc2a3hvHhqSrNIKFWOIJ7xqkhm7p/tKUeSsrQ+0qd1jOC83A64AO4wdCJVtiTe+K mbDA== X-Gm-Message-State: ABUngveI346EeOjOg2+sQxmz6oq/2k4FEwPAzvmep7P/CKJoQFiawIkjKeFZvXe82G2OafqdiNbIxD7ztaJoAw== X-Received: by 10.25.215.208 with SMTP id q77mr1094381lfi.126.1479427350136; Thu, 17 Nov 2016 16:02:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.43.210 with HTTP; Thu, 17 Nov 2016 16:01:49 -0800 (PST) In-Reply-To: <3ACA7E47-FC61-4927-B38E-43FB2E2B6CB7@apple.com> References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <582B67A2.4010804@gmail.com> <582BDCBF.70606@gmail.com> <582CAD78.90608@gmail.com> <3ACA7E47-FC61-4927-B38E-43FB2E2B6CB7@apple.com> From: Ted Lemon Date: Fri, 18 Nov 2016 09:01:49 +0900 Message-ID: To: Neil Jhaveri Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexey Melnikov , Doug Royer , "jmap@ietf.org" Subject: Re: [Jmap] Offline / sync X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 00:02:34 -0000 Hm, okay, that's useful information. My main complaint about the apple client is that if it detects a blank mail store on the server, it will erase five gigabytes of mail on the client. But aside from that I think I am seeing the behavior you are describing--it uses CONDSTORE/QRESYNC most of the time, but every so often there's a massive resync, which, if it happens over my cell phone connection, will kill the battery. And also if I am syncing over a lossy link, the chattiness of the protocol means that it takes a terribly long time to sync up even when using CONDSTORE/QRESYNC. On Fri, Nov 18, 2016 at 7:51 AM, Neil Jhaveri wrote: > >> On Nov 17, 2016, at 2:02 PM, Ted Lemon wrote: >> >> Alexiy, I think the problem with CONDSTORE and QRESYNC is that the >> data model isn't good, and so you can't really feel secure that you >> actually have a correct picture of the whole mail store. So every so >> often you do a massive resync. It doesn't happen every time you >> check for mail, but with a better data model, it would only happen if >> there were no revisions of the metadata database in common between the >> two ends. > > Out of curiosity, could you elaborate on some of these issues? > > Apple Mail supports both CONDSTORE and QRESYNC and, in our experience, th= ey have worked well and been implemented well enough by servers. We admitte= dly do have some fallback paths to resynchronize all UIDs and flags in spec= ific cases (e.g. syncing without CONDSTORE/QRESYNC), as we have seen some b= ugs where we believed the servers had not computed history exactly correctl= y. But we believed these to just be implementation bugs, and have encounter= ed similar problems with Exchange Web Services, too. > > Best, > - Neil > >> >> On Fri, Nov 18, 2016 at 7:15 AM, Alexey Melnikov >> wrote: >>> Ted, >>> >>>> On 17 Nov 2016, at 05:43, Ted Lemon wrote: >>>> >>>> That said, the amount of metadata that needs to be synced to be sure >>>> that you have a correct set of metadata is gigantic, and there is no >>>> mechanism for eliminating redundant re-downloading of metadata. >>>> Doing that is not hard--it just requires that the dataset be >>>> versioned. When you download the dataset the first time, the server >>>> tells you what version you have. When you connect later after having >>>> been offline, you tell the server what version you have, and it sends >>>> you the changes, not the whole dataset. If you have made changes, you >>>> send your changes. If there are conflicts, there's a conflict >>>> resolution process. >>>> >>>> As a consequence, if 100 messages have arrived since you were last >>>> connected, the maximum amount of metadata the server should ever send >>>> you is the metadata for 100 messages, even if you have 100k messages >>>> in your mail store. >>>> >>>> Right now, my IMAP client on my Mac routinely downloads the entire >>>> 100k messages worth of metadata just to make sure that it has a >>>> correct picture of what's in the mail store, because (as far as I >>>> know, not an IMAP expert) there is no versioning process like I've >>>> described. >>> >>> This is covered by IMAP CONDSTORE and QRESYNC extensions. So either you= r server and client don't support these, or the client is badly written. >>> >>> Best Regards, >>> Alexey >>> >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > From nobody Tue Nov 22 11:49:08 2016 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 41D931296EC for ; Tue, 22 Nov 2016 11:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=gmail.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 KaFK67u6n7c8 for ; Tue, 22 Nov 2016 11:49:04 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 CE130129430 for ; Tue, 22 Nov 2016 11:49:04 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id b126so29884577oia.2 for ; Tue, 22 Nov 2016 11:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to; bh=CxOdhETYPNHnOIygEJrnza+Q/RtE+gTenHeGX7Z75go=; b=npMEUVD91kNDnVFG3VtiS718yOVR+hZpVGdnYmcph1mMJDvvBSXEsoLMtXYtTJrCFe Ta9zcRgF4botW3FIrUoSnIwmkNHfl4stsy9lYs1maNHgqci0fiVkqPIFnOiUotJkT3RG 0wKnhXxBdg2S54TtK2EwRnsL+wPJPl6vbkgeC2cEkO2nGaqzRDvIsaIfSE8gIIpaGZXv eKy0vTPhZLLZj3u1SJw5t8CIibNvcH9D7wbxSlZJwYNQ0ndVJaTbhy9NyGKzjCb7qGo7 U7t5XDnfs7crhqT0vg+eIlioWA2O3z2J6q4d/TKykXYj/i3nedFD+7tidP25pqLyTbDq cAHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=CxOdhETYPNHnOIygEJrnza+Q/RtE+gTenHeGX7Z75go=; b=Bmmdlvfyf+flkijoZXypNK2N22LAqorfhXF1ayYKkY05MwEu0a42Ypmj5LnVm+eTpN lPDZGu7B4Fpsq/KIG8LdVIwd1wPr1nclypG86nseunrhmA/ZT/81O/x8GSnb2ZiVbe7Q /pF1ZnBLiB/JfKo2V/C8AOjKdg3feRPLd8ydW98AKjsq2FAxZjzijNJ/QUVp2YRTKfSq etZIJPCqoiTPchV1NDtWkei8yh6onT6ULN7LtVr77CsCcWKg8qx5K85TTsTs/SyuFeRb 1B0rcpaPXj+ssrSFuJI/KtyYjmuy5az3vxD49ckoyPOSNwRMVusTHDtP63lDMF4bqEH2 KB5g== X-Gm-Message-State: AKaTC03PuM+RSDImqRi89iQZiyEYcRZ4aY1hxeCa0+V/BjOjxmg36A19GM3vbpZU++juKA== X-Received: by 10.157.6.227 with SMTP id 90mr14570521otx.73.1479844144163; Tue, 22 Nov 2016 11:49:04 -0800 (PST) Received: from [192.168.1.4] ([97.121.16.239]) by smtp.googlemail.com with ESMTPSA id y201sm9232169oie.28.2016.11.22.11.49.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 11:49:03 -0800 (PST) To: jmap@ietf.org References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <5834A12E.3060807@gmail.com> Date: Tue, 22 Nov 2016 12:49:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070505060908020305040702" Archived-At: Cc: blong@google.com Subject: [Jmap] Mirror or not to mirror. X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 19:49:06 -0000 This is a cryptographically signed message in MIME format. --------------ms070505060908020305040702 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/21/2016 10:38 PM, Brandon Long wrote (on ietf-smtp, imapext): > I've said this to some client developers directly, but it's good to > share the concept more widely: > > There should be no "full mirror" clients, only disconnected state > clients which make different choices of window size. There are Gmail > accounts today which would exceed the ssd in many laptops, or the > monthly bandwidth allotment of some broadband customers. A full sync i= s > useful for backups, but a regular client would be wise to make full syn= c > a special case of "reasonable cache space on this device/connection > happens to be larger than the user's account". If your saying it should not be a requirement to mirror you account - I=20 agree. If that is not what you are saying: The decision to mirror (offline) or not mirror your email, is a user=20 need, not a protocol design issue. A protocol exists to make what is=20 needed a standard. A protocol does not design user needs. I need it, others over the years have said they need it. And FYI, I offline my main mega-sized GMAIL account now by telling my=20 MUA to keep email for offline usage. Gmail already supports it. --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms070505060908020305040702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CuwwggUCMIID6qADAgECAhAdBOVkkNcrCTidq3YMdkiJMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwNDA3MTQyMjU5WhcNMTcwNDA3MTQyMjU5WjBIMR8wHQYDVQQDDBZkb3Vn bGFzcm95ZXJAZ21haWwuY29tMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwpXz2U03EAEwBMtWerSb3KUI IfTw2/55rms1TwBY+p4Jj7x4DWTlBF6Ur5rdFF70bydWtDGILvSI3BNY2eXjZzbSXl5HCmvZ gUNnYFw6SJkb4S7edV5VdXVdOAVh24y0OBWqedbbuT8eVDZfPTy1mOuUbZo0I0tCoa1Hky14 UDb2qtPKw2Wfn9o2ksubBvn2b0UZlPahGFAcC/qc8M9h0O1G1hsn0BIowvVdr73/Q17Znr9u J/CBaCkNCM2tzH5j1qov7hRRZmeb7mVHrf/Dina9JjBAKsz52KZczLqPz1mSycKiEKc/k0ag FNtl0l6tCpUcoHwzBQ6dlbNOQEtE2QIDAQABo4IBuTCCAbUwDgYDVR0PAQH/BAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQkN0Oa JE+zG3ATs7D0DgRxVGx0fzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggr BgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5Bggr BgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQx LmNybDAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJAZ21haWwuY29tMCMGA1UdEgQcMBqGGGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIFMCwwKgYI KwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsF AAOCAQEAhAL0TajC+aJEbVC9q1elm0H0qgeCyW7EpLcfg8Lxwz/B9r6LvgoDzyS2afLecviF dy37I6jKVIAQH4RmAzVRwkSr1BHAl9TjSIQvlSbanoRnkLxJSWOr5fBiqbwrogv7K10tRGwN +86UIBvfear2f9epnMcI9d/hs4y6t41/uHlU76X5NdHIladYznv2YbZ9RJHUgaQvVYPkMzhA 8AqIVw/2r+RCJLA65Nf1prGxgQhTeA/JjTLVgjaO3AMtj9OQ/xm8NNVXhvLhRzhTXrXbux2q xWjYrPcMTiTrtsQyAZ9kbTaf5S2BErTA6EK5RQfZWFZCIlgI5XhVoHhOAMAchjCCBeIwggPK oAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d5 2DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8 wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDt VB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwv IjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1 ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtG K8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0 BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTAN BgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdOruKb rWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM 3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/ b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uV rZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDT agXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SW JQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0f QoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8 wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S 4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIB ATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBAhAdBOVkkNcrCTidq3YMdkiJMA0GCWCGSAFlAwQCAQUAoIICEzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMjIxOTQ5MDJa MC8GCSqGSIb3DQEJBDEiBCCT4R0oKnCu7TCMqlk2WYyL4DHHdlcTm57xlikqUOQ9GjBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGa BgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQD ExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTCBnAYLKoZI hvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpT dGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTANBgkqhkiG9w0B AQEFAASCAQBYtU2Jq99LtIvL4RAOs7usdNwgQIZgvwhPe//w5L97AuDWIYxvmTRqVR1Eafuy BiMsizoxkQVWltAGP0uMUQwgbC0krJkBMu8C+9S+Bvqjlj/d70JTchK7HNUsUrwZbWdoTFu9 oHdwjJdonxVRMoC4BrjvBb1vzDKUXmR2YUpqYTRD6XEW77k+GMu5kJ+4rOlR8KCONqSdheVy 8M/3e27OF7l57qSypPdq4I+n8NG+gxrRFbyrorLLmxav2UPRZTZfE+37wacM2kTrpslurRt+ eTnSUHBse/WRma9QfKUoDvMWydb0PpvKxZmT2PPmNH1xBrO5XeRPngjYEsrt8MtTAAAAAAAA --------------ms070505060908020305040702-- From nobody Tue Nov 22 11:56:03 2016 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 C2CBE12951A for ; Tue, 22 Nov 2016 11:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=gmail.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 MhonV6hKmoG2 for ; Tue, 22 Nov 2016 11:56:00 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3E3129665 for ; Tue, 22 Nov 2016 11:56:00 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id v84so29938498oie.3 for ; Tue, 22 Nov 2016 11:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to; bh=2WjQ6jx0xdgeSNmnC6uiH/fR6ogRWYp96qsJs7cUw+g=; b=Y4rIKYdM1PwGpyRbvaFvkE3icLkXgUqCj2gyBCYli45Hau1KZP71i9bc8dH3qv/Cjh +prdllFsow3eN3b3JtaqpKxzAXdlLh68EWbmqoqQz4scXiLoJ1MD+k8FK58n2MHkgbtM 8FBnYutztUQHb5MGZLRWfz6SM/PUTdnl6zSOobHwZXG+DwSg3fxGesJasMVeiaeTTIq0 RHrDQlJ7CrBi7iPUDvwhXDPTkK78oRHvzfKhN++2mDPGpB29GSGkofwe73Qm58maFuXv BG2mCKqMeRRD5npTRPNxyTLa7OQvdtn7yozSW+N+hCTQOKpsWPIyEfbxtBmqpbjXjRyU 5dYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=2WjQ6jx0xdgeSNmnC6uiH/fR6ogRWYp96qsJs7cUw+g=; b=D85byFUzniZoy9DVeoghd4vcZ2ldbciSotRQPNf3nEIHrsu9Gmv+7dVHD/n3/+J2W5 MR7YslgSPQk+0s3Hns/FDeZbDptyjeZHIwAohIFsqYg5YHaCtDBh4Jy7M+aTW4pTg6dQ cOwwQTBLUrFRCFUTYjuhktbt9SUUKVw8ejt6cLLJzJmGIIwXE6T4oDBCw+eeriQ6CV7+ MExxv/37zyJComqBTqgkVEJXIERWEaeitiHxied9Yl2Moo9tMI4UbgzGUGjq7FdixeC8 4Xdk4d0voZ9m/ZN0z8nCDvsMXxjBZP6t6QSHS/4DKKv82IkLHDpFeClQyVnAKGaLZbPw emlw== X-Gm-Message-State: AKaTC03evH2hcKiwJOTKBCo1zbbLj4Ger/WVvodGEFdrIFJVDlrtykn2p/6+y6fpK8J5mg== X-Received: by 10.202.76.196 with SMTP id z187mr13105293oia.202.1479844559657; Tue, 22 Nov 2016 11:55:59 -0800 (PST) Received: from [192.168.1.4] ([97.121.16.239]) by smtp.googlemail.com with ESMTPSA id t184sm9171091oie.21.2016.11.22.11.55.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 11:55:59 -0800 (PST) To: jmap@ietf.org References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <5834A2CE.8050502@gmail.com> Date: Tue, 22 Nov 2016 12:55:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030908080501080500030803" Archived-At: Cc: Tony Finch Subject: Re: [Jmap] [imapext] offline mode, was Re: [ietf-smtp] Fwd: Request to form a new WG: JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 19:56:02 -0000 This is a cryptographically signed message in MIME format. --------------ms030908080501080500030803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/15/2016 05:10 AM, Tony Finch wrote (on imapext and ietf-smtp): > Is everyone here using the term "offline mode" to mean the same thing? No they are not. > ... > How much do the necessary protocol features differ between a full-fat > disconnected mode client (a mirror on the client of the entire > account on the server) vs a poorly-connected mobile client which needs = to > sync a smaller window on the account? Concurrent access to multiple > mailboxes? what else? For those that need a full copy (mirror), it could be a MUCH simpler=20 protocol. Like I said earlier, you could almost use rsync. For those that just want a fast cache of emails, that is not a mirror=20 and is a much more difficult protocol. Some POP accounts still mandate (policy) the copying of the email. Once=20 you pop it, its deleted, or will be soon. If you need to keep it, you=20 have to copy it. Not all email accounts are ISP's. Not all email=20 providers want to be your store for your email. --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms030908080501080500030803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CuwwggUCMIID6qADAgECAhAdBOVkkNcrCTidq3YMdkiJMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwNDA3MTQyMjU5WhcNMTcwNDA3MTQyMjU5WjBIMR8wHQYDVQQDDBZkb3Vn bGFzcm95ZXJAZ21haWwuY29tMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwpXz2U03EAEwBMtWerSb3KUI IfTw2/55rms1TwBY+p4Jj7x4DWTlBF6Ur5rdFF70bydWtDGILvSI3BNY2eXjZzbSXl5HCmvZ gUNnYFw6SJkb4S7edV5VdXVdOAVh24y0OBWqedbbuT8eVDZfPTy1mOuUbZo0I0tCoa1Hky14 UDb2qtPKw2Wfn9o2ksubBvn2b0UZlPahGFAcC/qc8M9h0O1G1hsn0BIowvVdr73/Q17Znr9u J/CBaCkNCM2tzH5j1qov7hRRZmeb7mVHrf/Dina9JjBAKsz52KZczLqPz1mSycKiEKc/k0ag FNtl0l6tCpUcoHwzBQ6dlbNOQEtE2QIDAQABo4IBuTCCAbUwDgYDVR0PAQH/BAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQkN0Oa JE+zG3ATs7D0DgRxVGx0fzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggr BgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5Bggr BgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQx LmNybDAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJAZ21haWwuY29tMCMGA1UdEgQcMBqGGGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIFMCwwKgYI KwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsF AAOCAQEAhAL0TajC+aJEbVC9q1elm0H0qgeCyW7EpLcfg8Lxwz/B9r6LvgoDzyS2afLecviF dy37I6jKVIAQH4RmAzVRwkSr1BHAl9TjSIQvlSbanoRnkLxJSWOr5fBiqbwrogv7K10tRGwN +86UIBvfear2f9epnMcI9d/hs4y6t41/uHlU76X5NdHIladYznv2YbZ9RJHUgaQvVYPkMzhA 8AqIVw/2r+RCJLA65Nf1prGxgQhTeA/JjTLVgjaO3AMtj9OQ/xm8NNVXhvLhRzhTXrXbux2q xWjYrPcMTiTrtsQyAZ9kbTaf5S2BErTA6EK5RQfZWFZCIlgI5XhVoHhOAMAchjCCBeIwggPK oAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d5 2DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8 wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDt VB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwv IjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1 ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtG K8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0 BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTAN BgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdOruKb rWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM 3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/ b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uV rZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDT agXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SW JQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0f QoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8 wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S 4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIB ATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBAhAdBOVkkNcrCTidq3YMdkiJMA0GCWCGSAFlAwQCAQUAoIICEzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMjIxOTU1NTha MC8GCSqGSIb3DQEJBDEiBCDL3bUsZFKwRG9PZyjyjOsVNDIqwouJ7xwMCsLvpZMAMDBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGa BgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQD ExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTCBnAYLKoZI hvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpT dGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTANBgkqhkiG9w0B AQEFAASCAQAoJ/KN+Hijf1XTsbz244Iqn0qvFeg9Y4GrAAtshW22vfnRYgDVZ8y0wIR57vlX eaeqjTrVuINpdSIDrbb8p08/FmnPVKjrhvfJUjnFvVrewL6qdR+yU+N9648WeWEcJMcMkRx7 2t71r609iQxP9Tk4uDZE5VIY7WmkwWy8kMJg9alGfgDJIHUKqDLmNIBrsMN2E1+7SC8LXtMI X0rk31gPdenZx7deojVVRBG7wgnidfDr3YHobYsEVwFmEiWrYczXBMhRkSTdIWOY+Q8Vbtq9 5G35COsB42kWuQEHMjy0YOUTNQqbtX66MAnomd9bKuwQdHVpse71uWCm06MFM4YzAAAAAAAA --------------ms030908080501080500030803-- From nobody Tue Nov 22 18:31:58 2016 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 DE5221293E3 for ; Tue, 22 Nov 2016 18:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.com header.b=ZN7/T1VO; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=gTFe3WIO 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 AdJpA7-VZLrn for ; Tue, 22 Nov 2016 18:31:56 -0800 (PST) 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 832821294C9 for ; Tue, 22 Nov 2016 18:31:56 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 00933205F8; Tue, 22 Nov 2016 21:31:55 -0500 (EST) Received: from betaweb1 ([10.202.2.10]) by compute1.internal (MEProxy); Tue, 22 Nov 2016 21:31:54 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=7SpM/eHcfno1zbWHxRggnvJGlv s=; b=ZN7/T1VOtrGslHWV03ehtmmHos1hQa4sjkq64X4N7ghBwPDvrO4sUiyFat wgd/WoPe0atlhsxGEv/5+HwAG3NXeBu/u0GbzJi8ijxl/Ju6TXlTd183FkGo6MqW MyU+jmk/cC0CmnjEYUaFavUTnpl5bImDL2apmfbJwTWOFunWU= DKIM-Signature: v=1; a=rsa-sha1; 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=smtpout; bh=7S pM/eHcfno1zbWHxRggnvJGlvs=; b=gTFe3WIOFxuKD7wY0IvhRdPD5aaMG72KKP qEgJAw43sSIE+5oA/Y2TFC5SXhBKo6chVRyJaP2LuFq7nX8IyQ2HnvXRSxqTayj/ 7M0sgp76fxDn9hLlFz7tn0ODs36b0wUA/475kuDNO/P0Nr4uf7sulCVdq4S9b/FF MhbS8u/r0= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A8DD4E24C9; Tue, 22 Nov 2016 21:31:54 -0500 (EST) Message-Id: <1479868314.3825024.796533673.45DF1986@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_147986831438250240" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75d05893 In-Reply-To: <5834A12E.3060807@gmail.com> Date: Wed, 23 Nov 2016 13:31:54 +1100 References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <58220833.4000806@gmail.com> <01Q73SYPHLDI011H9Q@mauve.mrochek.com> <5F4EE3F805C40EF25D1E0E57@JcK-HP8200> <01Q7B16YQ1IO011H9Q@mauve.mrochek.com> <582A5594.5080008@gmail.com> <5834A12E.3060807@gmail.com> Archived-At: Cc: Brandon Long Subject: Re: [Jmap] Mirror or not to mirror. X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 02:31:58 -0000 This is a multi-part message in MIME format. --_----------=_147986831438250240 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On 11/21/2016 10:38 PM, Brandon Long wrote (on ietf-smtp, imapext): > There should be no "full mirror" clients, only disconnected state > clients which make different choices of window size. I completely agree. And this is the case JMAP is most optimised for. Depending on the device, the size of the user's account, and the user's preference, the client may choose a cache size such that the whole account is mirrored. But this is just a special case of the broader partial cache case. Even in the full sync case, depending on bandwidth limitations it can take a while to get to that point when adding a new account, and in the meantime you want the user to be able to fully access their mail as *though* it were all local, providing they are currently online. This is again the partial cache situation that JMAP works really well for. Neil. --_----------=_147986831438250240 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On 11/21/2016 10:38 PM, Brandon Long wrote (on ietf-smtp, imapext):
There should be no "full mirror" clients, only disconnected state clients which make different choices of window size.

I completely agree. And this is the case JMAP is most optimised for. Depending on the device, the size of the user's account, and the user's preference, the client may choose a cache size such that the whole account is mirrored. But this is just a special case of the broader partial cache case.

Even in the full sync case, depending on bandwidth limitations it can take a while to get to that point when adding a new account, and in the meantime you want the user to be able to fully access their mail as *though* it were all local, providing they are currently online. This is again the partial cache situation that JMAP works really well for.

Neil.
--_----------=_147986831438250240--