draft-ietf-jmap-websocket-02.txt   draft-ietf-jmap-websocket-03.txt 
JMAP K. Murchison JMAP K. Murchison
Internet-Draft Fastmail Internet-Draft Fastmail
Intended status: Standards Track July 5, 2019 Intended status: Standards Track July 22, 2019
Expires: January 6, 2020 Expires: January 23, 2020
A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket
draft-ietf-jmap-websocket-02 draft-ietf-jmap-websocket-03
Abstract Abstract
This document defines a binding for the JSON Meta Application This document defines a binding for the JSON Meta Application
Protocol (JMAP) over a WebSocket transport layer. The WebSocket Protocol (JMAP) over a WebSocket transport layer. The WebSocket
binding for JMAP provides higher performance than the current HTTP binding for JMAP provides higher performance than the current HTTP
binding for JMAP. binding for JMAP.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2020. This Internet-Draft will expire on January 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Discovering Support for JMAP over WebSocket . . . . . . . . . 3 3. Discovering Support for JMAP over WebSocket . . . . . . . . . 3
4. JMAP Subprotocol . . . . . . . . . . . . . . . . . . . . . . 3 4. JMAP Subprotocol . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. WebSocket Messages . . . . . . . . . . . . . . . . . . . 4 4.2. WebSocket Messages . . . . . . . . . . . . . . . . . . . 4
4.2.1. JMAP Requests . . . . . . . . . . . . . . . . . . . . 4 4.2.1. JMAP Requests . . . . . . . . . . . . . . . . . . . . 4
4.2.2. JMAP Responses . . . . . . . . . . . . . . . . . . . 5 4.2.2. JMAP Responses . . . . . . . . . . . . . . . . . . . 5
4.2.3. JMAP Request-level Errors . . . . . . . . . . . . . . 5 4.2.3. JMAP Request-level Errors . . . . . . . . . . . . . . 5
4.2.4. JMAP Push Notifications . . . . . . . . . . . . . . . 5 4.2.4. JMAP Push Notifications . . . . . . . . . . . . . . . 5
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registration of the WebSocket JMAP Subprotocol . . . . . 10 6.1. Registration of the WebSocket JMAP Subprotocol . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 11 publication) . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
JMAP [I-D.ietf-jmap-core] over HTTP [RFC7235] requires that every JMAP [RFC8620] over HTTP [RFC7235] requires that every JMAP API
JMAP API request be authenticated. Depending on the type of request be authenticated. Depending on the type of authentication
authentication used by the JMAP client and the configuration of the used by the JMAP client and the configuration of the JMAP server,
JMAP server, authentication could be an expensive operation both in authentication could be an expensive operation both in time and
time and resources. In such circumstances, authenticating every JMAP resources. In such circumstances, authenticating every JMAP API
API request may harm performance. request may harm performance.
The WebSocket binding for JMAP eliminates this performance hit by The WebSocket [RFC6455] binding for JMAP eliminates this performance
authenticating just the WebSocket handshake request and having those hit by authenticating just the WebSocket handshake request and having
credentials remain in effect for the duration of the WebSocket those credentials remain in effect for the duration of the WebSocket
connection. This binding supports JMAP API requests and responses, connection. This binding supports JMAP API requests and responses,
with optional support for push notifications. with optional support for push notifications.
Furthermore, the WebSocket binding for JMAP can optionally compress Furthermore, the WebSocket binding for JMAP can optionally compress
[RFC7692] both JMAP API requests and responses. Although compression [RFC7692] both JMAP API requests and responses. Although compression
of HTTP responses is ubiquitous, compression of HTTP requests has of HTTP responses is ubiquitous, compression of HTTP requests has
very low, if any deployment, and therefore isn't a viable option for very low, if any deployment, and therefore isn't a viable option for
JMAP API requests over HTTP. JMAP API requests over HTTP.
2. Conventions Used in This Document 2. Conventions Used in This Document
skipping to change at page 3, line 19 skipping to change at page 3, line 19
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [1] [RFC2119] [RFC8174] when, and only when, they appear in all 14 [1] [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The same terminology is used in this document as in the core JMAP The same terminology is used in this document as in the core JMAP
specification. specification.
3. Discovering Support for JMAP over WebSocket 3. Discovering Support for JMAP over WebSocket
The JMAP capabilities object is returned as part of the standard JMAP The JMAP capabilities object is returned as part of the standard JMAP
Session object (see Section 2 of [I-D.ietf-jmap-core]). Servers Session object (see Section 2 of [RFC8620]). Servers supporting this
supporting this specification MUST add a property named specification MUST add a property named
"urn:ietf:params:jmap:websocket" to the capabilities object. The "urn:ietf:params:jmap:websocket" to the capabilities object. The
value of this property is an object which MUST contain the following value of this property is an object which MUST contain the following
information on server capabilities: information on server capabilities:
webSocketUrl: "String" The URL to use for initiating a JMAP over o webSocketUrl: "String"
WebSocket handshake.
supportsWebSocketPush: "Boolean" This is "true" if the server The URL to use for initiating a JMAP over WebSocket handshake.
supports push notifications over the WebSocket, as described in
Section 4.2.4. o supportsWebSocketPush: "Boolean"
This is true if the server supports push notifications over the
WebSocket, as described in Section 4.2.4.
Example: Example:
"urn:ietf:params:jmap:websocket": { "urn:ietf:params:jmap:websocket": {
"webSocketUrl": "/jmap/ws/", "webSocketUrl": "https://server.example.com/jmap/ws/",
"supportsWebSocketPush": true "supportsWebSocketPush": true
} }
4. JMAP Subprotocol 4. JMAP Subprotocol
The term WebSocket subprotocol refers to an application-level The term WebSocket subprotocol refers to an application-level
protocol layered on top of a WebSocket connection. This document protocol layered on top of a WebSocket connection. This document
specifies the WebSocket JMAP subprotocol for carrying JMAP API specifies the WebSocket JMAP subprotocol for carrying JMAP API
requests, responses, and optional push notifications through a requests, responses, and optional push notifications through a
WebSocket connection. Binary data MUST NOT be uploaded or downloaded WebSocket connection. Binary data MUST NOT be uploaded or downloaded
through a WebSocket JMAP connection. Binary data is handled per through a WebSocket JMAP connection. Binary data is handled per
Section 6 of [I-D.ietf-jmap-core]) via a separate HTTP connection or Section 6 of [RFC8620] via a separate HTTP connection or stream.
stream.
4.1. Handshake 4.1. Handshake
The JMAP WebSocket client and JMAP WebSocket server negotiate the use The JMAP WebSocket client and JMAP WebSocket server negotiate the use
of the WebSocket JMAP subprotocol during the WebSocket handshake, of the WebSocket JMAP subprotocol during the WebSocket handshake,
either via a HTTP/1.1 Upgrade request (see Section 1.3 of [RFC6455]) either via a HTTP/1.1 Upgrade request (see Section 1.3 of [RFC6455])
or a HTTP/2 Extended CONNECT request (see Section 5 of [RFC8441]). or a HTTP/2 Extended CONNECT request (see Section 5 of [RFC8441]).
Regardless of the method used for the WebSocket handshake, the client Regardless of the method used for the WebSocket handshake, the client
MUST make an authenticated [RFC7235] HTTP request on the JMAP MUST make an authenticated [RFC7235] HTTP request on the JMAP
"webSocketUrl" (Section 3), and the client MUST include the value "webSocketUrl" (Section 3), and the client MUST include the value
'jmap' in the list of protocols for the 'Sec-WebSocket-Protocol' "jmap" in the list of protocols for the "Sec-WebSocket-Protocol"
header field. The reply from the server MUST also contain 'jmap' in header field. The reply from the server MUST also contain "jmap" in
its corresponding 'Sec-WebSocket-Protocol' header field in order for its corresponding "Sec-WebSocket-Protocol" header field in order for
a JMAP subprotocol connection to be established. a JMAP subprotocol connection to be established.
If a client receives a handshake response that does not include If a client receives a handshake response that does not include
'jmap' in the 'Sec-WebSocket-Protocol' header, then a JMAP "jmap" in the "Sec-WebSocket-Protocol" header, then a JMAP
subprotocol WebSocket connection was not established and the client subprotocol WebSocket connection was not established and the client
MUST close the WebSocket connection. MUST close the WebSocket connection.
Once the handshake has successfully completed, the WebSocket Once the handshake has successfully completed, the WebSocket
connection is established and can be used for JMAP API requests, connection is established and can be used for JMAP API requests,
responses, and optional push notifications. Other message types MUST responses, and optional push notifications. Other message types MUST
NOT be transmitted over this connection. NOT be transmitted over this connection.
The credentials used for authenticating the HTTP request to initiate The credentials used for authenticating the HTTP request to initiate
the handshake remain in effect for the duration of the WebSocket the handshake remain in effect for the duration of the WebSocket
connection. connection.
4.2. WebSocket Messages 4.2. WebSocket Messages
Data frame messages in the JMAP subprotocol MUST be of the text type Data frame messages in the JMAP subprotocol MUST be of the text type
and contain UTF-8 encoded data. The messages MUST be in the form of and contain UTF-8 encoded data. The messages MUST be in the form of
a single JMAP Request object (see Section 3.2 of a single JMAP Request object (see Section 3.2 of [RFC8620]), JMAP
[I-D.ietf-jmap-core]) or JMAP WebSocketPushEnable object (see WebSocketPushEnable object (see Section 4.2.4.2), or JMAP
Section 4.2.4) when sent from the client to the server, and in the WebSocketPushDisable object (see Section 4.2.4.3) when sent from the
form of a single JMAP Response object, JSON Problem Details object, client to the server, and in the form of a single JMAP Response
or JMAP StateChange object (see Sections 3.3, 3.5.1, and 7.1 object, JSON Problem Details object, or JMAP StateChange object (see
respectively of [I-D.ietf-jmap-core]) when sent from the server to Sections 3.3, 3.5.1, and 7.1 respectively of [RFC8620]) when sent
the client. from the server to the client.
4.2.1. JMAP Requests 4.2.1. JMAP Requests
This specification adds two extra arguments to the Request object: This specification adds two extra arguments to the Request object:
@type: "String" This MUST be the string "Request". o @type: "String"
id: "String" (default: ) A client-specified identifier for the This MUST be the string "Request".
request.
o id: "String" (optional)
A client-specified identifier for the request.
JMAP over WebSocket allows the server to process requests out of JMAP over WebSocket allows the server to process requests out of
order. The client-specified identifier is used as a mechanism for order. The client-specified identifier is used as a mechanism for
the client to correlate requests and responses. the client to correlate requests and responses.
Additionally, the "maxConcurrentRequests" field in the "capabilities" Additionally, the "maxConcurrentRequests" field in the "capabilities"
object (see Section 2 of [I-D.ietf-jmap-core]) limits the number of object (see Section 2 of [RFC8620]) limits the number of inflight
inflight requests over the WebSocket. requests over the WebSocket.
4.2.2. JMAP Responses 4.2.2. JMAP Responses
This specification adds two extra arguments to the Response object: This specification adds two extra arguments to the Response object:
@type: "String" This MUST be the string "Response". o @type: "String"
requestId: "String|null" The client-specified identifier in the This MUST be the string "Response".
corresponding request. If "null", no identifier was provided in
the request. o requestId: "String" (optional; only returned if given in the
request)
The client-specified identifier in the corresponding request.
4.2.3. JMAP Request-level Errors 4.2.3. JMAP Request-level Errors
This specification adds two extra arguments to the Problem Details This specification adds two extra arguments to the Problem Details
object: object:
@type: "String" This MUST be the string "RequestError". o @type: "String"
requestId: "String|null" The client-specified identifier in the This MUST be the string "RequestError".
corresponding request. If "null", no identifier was provided in
the request. o requestId: "String" (optional; only returned if given in the
request)
The client-specified identifier in the corresponding request.
4.2.4. JMAP Push Notifications 4.2.4. JMAP Push Notifications
JMAP over WebSocket servers that support push notifications on the JMAP over WebSocket servers that support push notifications on the
WebSocket will advertise a "supportsWebSocketPush" property with a WebSocket will advertise a "supportsWebSocketPush" property with a
value of "true" in the server capabilities object. value of true in the server capabilities object.
4.2.4.1. Notification Format
All push notifications take the form of a standard StateChange object
(see Section 7.1 of [RFC8620]).
This specification adds one extra argument to the StateChange object:
o pushState: "String" (optional)
A (preferably short) string representing the state on the server
for ALL of the data types in the account (not just the objects
returned in this call).
4.2.4.2. Enabling Notifications
A client enables push notifications from the server by sending a A client enables push notifications from the server by sending a
WebSocketPushEnable object to the server. A WebSocketPushEnable WebSocketPushEnable object to the server. A WebSocketPushEnable
object has the following properties: object has the following properties:
@type: "String" This MUST be the string "WebSocketPushEnable". o @type: "String" This MUST be the string "WebSocketPushEnable".
dataTypes: "String[]|null" A list of data type names (e.g. o dataTypes: "String[]|null"
"Mailbox", "Email") that the client is interested in. A
StateChange notification will only be sent if the data for one of
these types changes. Other types are omitted from the TypeState
object. If "null", changes will be pushed for all supported data
types.
pushState: "String" Optional. The last "pushState" token that the A list of data type names (e.g. "Mailbox", "Email") that the
client received from the server. Upon receipt of a "pushState" client is interested in. A StateChange notification will only be
token, the server SHOULD immediately send all changes since that sent if the data for one of these types changes. Other types are
state token. omitted from the TypeState object. If null, changes will be
pushed for all supported data types.
All push notifications take the form of a standard StateChange object o pushState: "String" (optional)
(see Section 7.1 of [I-D.ietf-jmap-core]).
This specification adds one extra argument to the StateChange object: The last "pushState" token that the client received from the
server. Upon receipt of a "pushState" token, the server SHOULD
immediately send all changes since that state token.
pushState: "String" Optional. A (preferably short) string 4.2.4.3. Disabling Notifications
representing the state on the server for ALL of the data types in
the account (not just the objects returned in this call). A client disables push notifications from the server by sending a
WebSocketPushDisable object to the server. A WebSocketPushDisable
object has the following property:
o @type: "String"
This MUST be the string "WebSocketPushDisable".
4.3. Examples 4.3. Examples
The following examples show WebSocket JMAP opening handshakes, a JMAP The following examples show WebSocket JMAP opening handshakes, a JMAP
Core/echo request and response, and a subsequent closing handshake. Core/echo request and response, and a subsequent closing handshake.
The examples assume that the JMAP "webSocketUrl" has been advertised The examples assume that the JMAP "webSocketUrl" has been advertised
in the JMAP Session object as "/jmap/ws/". Note that folding of in the JMAP Session object as "/jmap/ws/". Note that folding of
header fields is for editorial purposes only. header fields is for editorial purposes only.
WebSocket JMAP connection via HTTP/1.1 with push notifications WebSocket JMAP connection via HTTP/1.1 with push notifications for
enabled: mail [I-D.ietf-jmap-mail] enabled:
[[ From Client ]] [[ From Server ]] [[ From Client ]] [[ From Server ]]
GET /jmap/ws/ HTTP/1.1 GET /jmap/ws/ HTTP/1.1
Host: server.example.com Host: server.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Authorization: Basic Zm9vOmJhcg== Authorization: Basic Zm9vOmJhcg==
Sec-WebSocket-Key: Sec-WebSocket-Key:
dGhlIHNhbXBsZSBub25jZQ== dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Protocol: jmap Sec-WebSocket-Protocol: jmap
Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 13
Origin: http://www.example.com Origin: http://www.example.com
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: Sec-WebSocket-Accept:
s3pPLMBiTxaQ9kYGzzhZRbK+xOo= s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: jmap Sec-WebSocket-Protocol: jmap
[WebSocket connection established] [WebSocket connection established]
WS_DATA WS_DATA
{ {
"@type": "WebSocketPushEnable", "@type": "WebSocketPushEnable",
"dataTypes": [ "Mailbox", "Email" ], "dataTypes": [ "Mailbox", "Email" ],
"pushState": "aaa" "pushState": "aaa"
} }
WS_DATA WS_DATA
{ {
"@type": "StateChange", "@type": "StateChange",
"changed": { "changed": {
"a456": { "a456": {
"Email": "d35ecb040aab" "Email": "d35ecb040aab"
} }
}, },
"pushState": "bbb" "pushState": "bbb"
} }
WS_DATA WS_DATA
{ {
"@type": "Request", "@type": "Request",
"id": "R1", "id": "R1",
"using": [ "urn:ietf:params:jmap:core" ], "using": [ "urn:ietf:params:jmap:core" ],
"methodCalls": [ "methodCalls": [
[ [
"Core/echo", { "Core/echo", {
"hello": true, "hello": true,
"high": 5 "high": 5
}, },
"b3ff" "b3ff"
] ]
] ]
} }
WS_DATA WS_DATA
{ {
"@type": "Response", "@type": "Response",
"requestId": "R1", "requestId": "R1",
"methodResponses": [ "methodResponses": [
[ [
"Core/echo", { "Core/echo", {
"hello": true, "hello": true,
"high": 5 "high": 5
}, },
"b3ff" "b3ff"
]
] ]
} ]
}
WS_DATA WS_DATA
The quick brown fox jumps The quick brown fox jumps
over the lazy dog. over the lazy dog.
WS_DATA WS_DATA
{ {
"@type": "RequestError", "@type": "RequestError",
"requestId": "null", "requestId": null,
"type": "type":
"urn:ietf:params:jmap:error:notJSON", "urn:ietf:params:jmap:error:notJSON",
"status": 400, "status": 400,
"detail": "detail":
"The request did not parse as I-JSON." "The request did not parse as I-JSON."
} }
WS_DATA
WS_DATA {
{ "@type": "StateChange",
"@type": "StateChange", "changed": {
"changed": { "a123": {
"a123": { "Mailbox": "0af7a512ce70"
"Mailbox": "0af7a512ce70"
}
} }
"pushState": "ccc"
} }
"pushState": "ccc"
}
WS_CLOSE WS_CLOSE
WS_CLOSE WS_CLOSE
[WebSocket connection closed] [WebSocket connection closed]
WebSocket JMAP connection on a HTTP/2 stream which also negotiates WebSocket JMAP connection on a HTTP/2 stream which also negotiates
compression [RFC7692]: compression [RFC7692]:
[[ From Client ]] [[ From Server ]] [[ From Client ]] [[ From Server ]]
SETTINGS SETTINGS
SETTINGS_ENABLE_CONNECT_PROTOCOL = 1 SETTINGS_ENABLE_CONNECT_PROTOCOL = 1
HEADERS + END_HEADERS HEADERS + END_HEADERS
:method = CONNECT :method = CONNECT
:protocol = websocket :protocol = websocket
:scheme = https :scheme = https
:path = /jmap/ws/ :path = /jmap/ws/
:authority = server.example.com :authority = server.example.com
authorization = Basic Zm9vOmJhcg== authorization = Basic Zm9vOmJhcg==
sec-websocket-protocol = jmap sec-websocket-protocol = jmap
sec-websocket-version = 13 sec-websocket-version = 13
sec-websocket-extensions = sec-websocket-extensions =
permessage-deflate permessage-deflate
origin = http://www.example.com origin = http://www.example.com
HEADERS + END_HEADERS HEADERS + END_HEADERS
:status = 200 :status = 200
sec-websocket-protocol = jmap sec-websocket-protocol = jmap
sec-websocket-extensions = sec-websocket-extensions =
permessage-deflate permessage-deflate
[WebSocket connection established] [WebSocket connection established]
DATA DATA
WS_DATA WS_DATA
[compressed text] [compressed text]
DATA DATA
WS_DATA WS_DATA
[compressed text] [compressed text]
... ...
DATA + END_STREAM DATA + END_STREAM
WS_CLOSE WS_CLOSE
DATA + END_STREAM DATA + END_STREAM
WS_CLOSE WS_CLOSE
[WebSocket connection closed] [WebSocket connection closed]
[HTTP/2 stream closed] [HTTP/2 stream closed]
5. Security Considerations 5. Security Considerations
The security considerations for both WebSocket (see Section 10 of The security considerations for both WebSocket (see Section 10 of
[RFC6455]) and JMAP (see Section 8 of [I-D.ietf-jmap-core]) apply to [RFC6455]) and JMAP (see Section 8 of [RFC8620]) apply to the
the WebSocket JMAP subprotocol. WebSocket JMAP subprotocol.
6. IANA Considerations 6. IANA Considerations
6.1. Registration of the WebSocket JMAP Subprotocol 6.1. Registration of the WebSocket JMAP Subprotocol
This specification requests IANA to register the WebSocket JMAP This specification requests IANA to register the WebSocket JMAP
subprotocol under the "WebSocket Subprotocol Name" Registry with the subprotocol under the "WebSocket Subprotocol Name" Registry with the
following data: following data:
Subprotocol Identifier: JMAP Subprotocol Identifier: jmap
Subprotocol Common Name: WebSocket Transport for JMAP (JSON Meta Subprotocol Common Name: WebSocket Transport for JMAP (JSON Meta
Application Protocol) Application Protocol)
Subprotocol Definition: RFCXXXX (this document) Subprotocol Definition: RFCXXXX (this document)
7. Acknowledgments 7. Acknowledgments
The author would like to thank the following individuals for The author would like to thank the following individuals for
contributing their ideas and support for writing this specification: contributing their ideas and support for writing this specification:
Neil Jenkins, Robert Mueller, and Chris Newman. Neil Jenkins, Robert Mueller, and Chris Newman.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-jmap-core]
Jenkins, N. and C. Newman, "JSON Meta Application
Protocol", draft-ietf-jmap-core-17 (work in progress),
March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>. <https://www.rfc-editor.org/info/rfc6455>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
skipping to change at page 11, line 18 skipping to change at page 12, line 9
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, September 2018, RFC 8441, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/info/rfc8441>. <https://www.rfc-editor.org/info/rfc8441>.
[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
2019, <https://www.rfc-editor.org/info/rfc8620>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-jmap-mail] [I-D.ietf-jmap-mail]
Jenkins, N. and C. Newman, "JMAP (JSON Meta Application Jenkins, N. and C. Newman, "JMAP (JSON Meta Application
Protocol) for Mail", draft-ietf-jmap-mail-16 (work in Protocol) for Mail", draft-ietf-jmap-mail-16 (work in
progress), March 2019. progress), March 2019.
[RFC7692] Yoshino, T., "Compression Extensions for WebSocket", [RFC7692] Yoshino, T., "Compression Extensions for WebSocket",
RFC 7692, DOI 10.17487/RFC7692, December 2015, RFC 7692, DOI 10.17487/RFC7692, December 2015,
<https://www.rfc-editor.org/info/rfc7692>. <https://www.rfc-editor.org/info/rfc7692>.
8.3. URIs 8.3. URIs
[1] https://tools.ietf.org/html/bcp14 [1] https://tools.ietf.org/html/bcp14
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) publication)
Changes since ietf-02:
o Updated JMAP Core reference to RFC 8620.
o Added 'WebSocketPushDisable' object.
o Editorial and formatting changes.
Changes since ietf-01: Changes since ietf-01:
o Changed 'wsURL' to 'webSocketUrl' and removed push query option. o Changed 'wsURL' to 'webSocketUrl' and removed push query option.
o Added 'supportsWebSocketPush' capability. o Added 'supportsWebSocketPush' capability.
o Added '@type' argument to Request object. o Added '@type' argument to Request object.
o Added 'WebSocketPushEnable' object. o Added 'WebSocketPushEnable' object.
 End of changes. 53 change blocks. 
157 lines changed or deleted 190 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/