Subject: [Jmap] Fwd: New Version Notification for draft-murchison-jmap-websocket-00.txt

From: Ken Murchison <[email-masked]>
Date: Tue, 29 May 2018 16:07:08 -0400

Having implemented JMAP over WebSocket in the Cyrus IMAP server, I 
figured that I would go ahead and start documenting it.

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-murchison-jmap-websocket-00.txt
Date: 	Tue, 29 May 2018 13:05:41 -0700
From: 	[email-masked]
To: 	Ken Murchison <[email-masked]>, Kenneth Murchison 
<[email-masked]>

A new version of I-D, draft-murchison-jmap-websocket-00.txt
has been successfully submitted by Kenneth Murchison and posted to the
IETF repository.

Name:		draft-murchison-jmap-websocket
Revision:	00
Title:		A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket
Document date:	2018-05-29
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-murchison-jmap-websocket-00.txt
Status:         https://datatracker.ietf.org/doc/draft-murchison-jmap-websocket/
Htmlized:       https://tools.ietf.org/html/draft-murchison-jmap-websocket-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-murchison-jmap-websocket

Abstract:
    This document defines a binding for the JSON Meta Application
    Protocol (JMAP) over a WebSocket transport layer.  A WebSocket
    binding for JMAP provides higher performance than the current HTTP
    binding for JMAP.

Open Issues

    o  Discovering support for JMAP over WebSocket.

    o  Should we allow push notifications over the WS connection?

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 29 May 2018 22:53:09 -0400

Looks good. A few thoughts:
 * This should definitely be advertised in the capabilities object, as per any JMAP extensions.
 * Should the server be allowed to advertise a different URL for a websockets API connection as opposed to an HTTP one?
 * Are responses guaranteed to be in the same order as requests? (Probably not; if you want methods to execute sequentially you should bundle them in a single request object, but then how do you correlate the response objects to the request objects? Probably need to add an id property to the request/response object.)
 * I think being able to receive push events over the single websocket connection makes sense, but that means you'd have to be able to distinguish the different message types you might receive (API response or push).
 * What changes are required to rate limiting options for the server? These probably need to be advertised in the capabilities object for this extension.

Neil.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 30 May 2018 09:31:10 -0400

On 05/29/2018 10:53 PM, Neil Jenkins wrote:
> Looks good.. A few thoughts:
>

OK.  For now, I'll put the extension in the cyrusimap.org namespace.

>   * Should the server be allowed to advertise a different URL for a
>     websockets API connection as opposed to an HTTP one?
>

Sure.  I'll add a 'wsUrl' String to the capabilities.

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

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

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

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

>   * What changes are required to rate limiting options for the server?
>     These probably need to be advertised in the capabilities object
>     for this extension.
>

Are you thinking that we need separate maxSizeRequest, 
maxConcurrentRequests, maxCallsInRequest, maxObjectsInGet, and 
maxObjectsInSet for the WebSocket connection?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC