ietf
[Top] [All Lists]

Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap)

2017-02-06 15:02:16
On Mon, Feb 6, 2017 at 3:04 PM, Adrien de Croy <adrien(_at_)qbik(_dot_)com> 
wrote:




Adding to this:

   HTTP/HTTPS are not stateless, since they are connection-based.

A lot of the people on the HTTP WG would have an issue with this
statement.

In fact there has been a lot of discussion about the evils of
connection-oriented anything in regard to HTTP, especially around
authentication (e.g. NTLM).

There are proxies that reuse upstream connections between different
clients, the protocol (1.1 at least) is designed to be stateless in terms
of each message being independent of others, whether on the same connection
or not.

So I wouldn't start a new protocol based on the presumption that
HTTP/HTTPS is connection-oriented and not stateless.


​+1

I was hoping we could go a different route here:

1) Write the QUIC protocol. Gives us a multiplexed TCP capability
2) Write a thin shim on QUIC for Web services to replace HTTP presentation
3) Use the result and JSON encoding as the presentation layer for AppsNG​

​Doing JMAP on QUIC right now is error 32: Research on Research. But doing
JMAP on HTTP means inventing a second MUX layer. Also bad.​

​There is clearly potential ​to improve on IMAP user experience. GMAIL
isn't very much different but it is a lot more responsive because the
protocol does things like return the overviews for the 20 latest headers
that the app is trying to present to the user rather than the client going
into hyperspace as it downloads 15 years of messages.

Yes, I know it is possible to do some of the same stuff if the
application's IMAP foo is really good. But being able to optimize the round
trips because you control both ends of the protocol is very powerful.

HTTP has a lot of cruft in it to support browsers running on the 1990s
Internet when the whole continent of Australia was connected by a 56Kb
dialup and T1 was considered lightning fast. And one of the problems with
that sort of cruft is that no matter how rubbish it is or how many problems
it creates, there will always be people who squeak if you try to take it
out.

I am profoundly unimpressed by arguments about using HTTP features like
caching in Web services. If HTTP caching works for your Web Service it is
probably because what you are doing is re-implementing HTTP in HTTP badly.