< draft-ietf-alto-incr-update-sse-17.txt   draft-ietf-alto-incr-update-sse-18.txt >
ALTO WG W. Roome ALTO WG W. Roome
Internet-Draft Nokia Bell Labs Internet-Draft Nokia Bell Labs
Intended status: Standards Track Y. Yang Intended status: Standards Track Y. Yang
Expires: January 23, 2020 Yale University Expires: July 26, 2020 Yale University
July 22, 2019 January 23, 2020
ALTO Incremental Updates Using Server-Sent Events (SSE) ALTO Incremental Updates Using Server-Sent Events (SSE)
draft-ietf-alto-incr-update-sse-17 draft-ietf-alto-incr-update-sse-18
Abstract Abstract
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol
provides network related information, called network information provides network related information, called network information
resources, to client applications so that clients can make informed resources, to client applications so that clients can make informed
decisions in utilizing network resources. For example, an ALTO decisions in utilizing network resources. For example, an ALTO
server can provide network and cost maps so that an ALTO client can server can provide network and cost maps so that an ALTO client can
use the maps to determine the costs between network endpoints when use the maps to determine the costs between network endpoints when
choosing communicating endpoints. choosing communicating endpoints.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 23, 2020. This Internet-Draft will expire on July 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Major Changes Since Version -01 . . . . . . . . . . . . . . . 4 2. Major Changes Since Version -01 . . . . . . . . . . . . . . . 5
3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Server-Sent Events (SSEs) . . . . . . . . . . . . . . . . 6 4.1. Server-Sent Events (SSEs) . . . . . . . . . . . . . . . . 7
4.2. JSON Merge Patch . . . . . . . . . . . . . . . . . . . . 8 4.2. JSON Merge Patch . . . . . . . . . . . . . . . . . . . . 8
4.2.1. JSON Merge Patch Encoding . . . . . . . . . . . . . . 8 4.2.1. JSON Merge Patch Encoding . . . . . . . . . . . . . . 8
4.2.2. JSON Merge Patch ALTO Messages . . . . . . . . . . . 9 4.2.2. JSON Merge Patch ALTO Messages . . . . . . . . . . . 9
4.3. JSON Patch . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. JSON Patch . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.1. JSON Patch Encoding . . . . . . . . . . . . . . . . . 13 4.3.1. JSON Patch Encoding . . . . . . . . . . . . . . . . . 13
4.3.2. JSON Patch ALTO Messages . . . . . . . . . . . . . . 13 4.3.2. JSON Patch ALTO Messages . . . . . . . . . . . . . . 13
5. Overview of Approach . . . . . . . . . . . . . . . . . . . . 15 5. Overview of Approach . . . . . . . . . . . . . . . . . . . . 15
6. Update Messages: Data Update and Control Update Messages . . 17 6. Update Messages: Data Update and Control Update Messages . . 17
6.1. ALTO Update Message Format . . . . . . . . . . . . . . . 17 6.1. ALTO Update Message Format . . . . . . . . . . . . . . . 17
6.2. ALTO Data Update Message . . . . . . . . . . . . . . . . 18 6.2. ALTO Data Update Message . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 20 skipping to change at page 3, line 20
7.8. Keep-Alive Messages . . . . . . . . . . . . . . . . . . . 26 7.8. Keep-Alive Messages . . . . . . . . . . . . . . . . . . . 26
8. Stream Control Service . . . . . . . . . . . . . . . . . . . 26 8. Stream Control Service . . . . . . . . . . . . . . . . . . . 26
8.1. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 27
8.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 27 8.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 27
8.4. Accept Input Parameters . . . . . . . . . . . . . . . . . 28 8.4. Accept Input Parameters . . . . . . . . . . . . . . . . . 28
8.5. Capabilities & Uses . . . . . . . . . . . . . . . . . . . 28 8.5. Capabilities & Uses . . . . . . . . . . . . . . . . . . . 28
8.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 28 8.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Example: IRD Announcing Update Stream Services . . . . . 29 9.1. Example: IRD Announcing Update Stream Services . . . . . 29
9.2. Example: Simple Network and Cost Map Updates . . . . . . 31 9.2. Example: Simple Network and Cost Map Updates . . . . . . 32
9.3. Example: Advanced Network and Cost Map Updates . . . . . 34 9.3. Example: Advanced Network and Cost Map Updates . . . . . 35
9.4. Example: Endpoint Property Updates . . . . . . . . . . . 38 9.4. Example: Endpoint Property Updates . . . . . . . . . . . 39
10. Operation and Processing Considerations . . . . . . . . . . . 41 9.5. Example: Multipart Message Updates . . . . . . . . . . . 42
10.1. Considerations for Choosing SSE Line Lengths . . . . . . 41 10. Operation and Processing Considerations . . . . . . . . . . . 44
10.2. Considerations for Choosing Data Update Messages . . . . 42 10.1. Considerations for Choosing Data Update Messages . . . . 44
10.3. Considerations for Client Processing Data Update 10.2. Considerations for Client Processing Data Update
Messages . . . . . . . . . . . . . . . . . . . . . . . . 43 Messages . . . . . . . . . . . . . . . . . . . . . . . . 45
10.4. Considerations for Updates to Filtered Cost Maps . . . . 44 10.3. Considerations for Updates to Filtered Cost Maps . . . . 46
10.5. Considerations for Updates to Ordinal Mode Costs . . . . 44 10.4. Considerations for Updates to Ordinal Mode Costs . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 10.5. Considerations for SSE Text Formatting and Processing . 46
11.1. Update Stream Server: Denial-of-Service Attacks . . . . 45 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47
11.2. ALTO Client: Update Overloading or Instability . . . . . 45 11.1. Update Stream Server: Denial-of-Service Attacks . . . . 47
11.3. Stream Control: Spoofed Control Requests . . . . . . . . 45 11.2. ALTO Client: Update Overloading or Instability . . . . . 48
12. Requirements on Future ALTO Services to Use this Design . . . 46 11.3. Stream Control: Spoofed Control Requests . . . . . . . . 48
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 12. Requirements on Future ALTO Services to Use this Design . . . 48
14. Alternative Designs Not Supported . . . . . . . . . . . . . . 48 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
14.1. Why Not HTTP/2 Server-Push . . . . . . . . . . . . . . . 48 14. Alternative Designs Not Supported . . . . . . . . . . . . . . 51
14.2. Why Not Allowing Stream Restart . . . . . . . . . . . . 49 14.1. Why Not HTTP/2 Server-Push . . . . . . . . . . . . . . . 51
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 14.2. Why Not Allowing Stream Restart . . . . . . . . . . . . 52
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol
provides network related information called network information provides network related information called network information
resources to client applications so that clients may make informed resources to client applications so that clients may make informed
decisions in utilizing network resources. For example, an ALTO decisions in utilizing network resources. For example, an ALTO
server provides network and cost maps, where a network map partitions server provides network and cost maps, where a network map partitions
the set of endpoints into a manageable number of sets each defined by the set of endpoints into a manageable number of sets each defined by
a Provider-Defined Identifier (PID), and a cost map provides directed a Provider-Defined Identifier (PID), and a cost map provides directed
skipping to change at page 5, line 34 skipping to change at page 5, line 39
(Section 8) to allow a client to add or remove resources from a (Section 8) to allow a client to add or remove resources from a
previously created update stream. The ALTO server creates a new previously created update stream. The ALTO server creates a new
stream control resource for each update stream instance, assigns a stream control resource for each update stream instance, assigns a
unique URI to it, and sends the URI to the client as the first unique URI to it, and sends the URI to the client as the first
event in the stream. event in the stream.
3. Terms 3. Terms
This document uses the following terms: Update Stream, Update Stream This document uses the following terms: Update Stream, Update Stream
Server, Update Message, Data Update Message, Full Replacement, Server, Update Message, Data Update Message, Full Replacement,
Incremental Change, Control Update Message, Stream Control Service, Incremental Change, Stream Control Service, Stream Control, Stream
Stream Control. Control Server, Substream-ID, Data-ID, Control Update Message.
Update Stream: An update stream is an HTTP connection between an ALTO Update Stream: An update stream is an HTTP connection between an ALTO
client and an ALTO server so that the server can push a sequence of client and an ALTO server so that the server can push a sequence of
update messages using SSE to the client. update messages using SSE to the client.
Update Stream Server: We refer to an ALTO server providing an update Update Stream Server: We refer to an ALTO server providing an update
stream as an ALTO update stream server, or update stream server for stream as an ALTO update stream server, or update stream server for
short. Note that the ALTO server mentioned in this document refers short. Note that the ALTO server mentioned in this document refers
to a general server that provides various kinds of services; it can to a general server that provides various kinds of services; it can
be an update stream server or stream control server (see below); it be an update stream server or stream control server (see below); it
skipping to change at page 6, line 19 skipping to change at page 6, line 25
Full Replacement: A full replacement for a resource encodes the Full Replacement: A full replacement for a resource encodes the
content of the resource in its original ALTO encoding. content of the resource in its original ALTO encoding.
Incremental Change: An incremental change specifies only the Incremental Change: An incremental change specifies only the
difference between the new content and the previous version. An difference between the new content and the previous version. An
incremental change can be encoded using either JSON merge patch or incremental change can be encoded using either JSON merge patch or
JSON patch in this document. JSON patch in this document.
Stream Control Service: An stream control service provides an HTTP Stream Control Service: An stream control service provides an HTTP
URI so that the ALTO client of an update stream can use it to send URI so that the ALTO client of an update stream can use it to send
stream control requests on the addition or removal of resources stream control requests to the ALTO server on the addition or removal
receiving update messages from the update stream. of resources receiving update messages from the update stream. The
ALTO server creates a new stream control resource for each update
stream instance, assigns a unique URI to it, and sends the URI to the
client as the first event in the stream. (Note that the Stream
Control Service in ALTO has no association with the similarly named
Stream Control Transmission Protocol [RFC4960].)
Stream Control: A shorthand for stream control service. Stream Control: A shorthand for stream control service.
Stream Control Server: An stream control server providing the stream Stream Control Server: An stream control server providing the stream
control service. control service.
Substream-ID: An ALTO client can assign a unique substream-id when
requesting the addition of a resource receiving update messages from
an update stream. The server puts the substream-id in each update
event for that resource. Substream-id allows a client to use one
update stream to receive updates to multiple requests for the same
resource (i.e., with the same resource-id in an ALTO IRD), for
example, for a POST-mode resource with different input parameters.
Data-ID: It is a subfield of the `event` field of SSE to identify the
ALTO data (object) to be updated. For an ALTO resource returning a
multipart response, the data-id to identify the data (object) is the
substream-id, in addition to the content-id of the object in the
multipart response. The data-id of a single part response is just
the substream-id.
Control Update Message: A control update message is a message in an Control Update Message: A control update message is a message in an
update stream for the update stream server to notify the ALTO client update stream for the update stream server to notify the ALTO client
of related control information of the update stream. The first of related control information of the update stream. The first
message of an update stream is a control update message and provides message of an update stream is a control update message and provides
the URI using which the ALTO client can send stream control requests the URI using which the ALTO client can send stream control requests
to the stream control server. Additional control update messages in to the stream control server. Additional control update messages in
an update stream allow the update stream server to notify the ALTO an update stream allow the update stream server to notify the ALTO
client of status changes (e.g., the server will no longer send client of status changes (e.g., the server will no longer send
updates for an information resource). updates for an information resource).
4. Background 4. Background
The design requires two basic techniques: server push and encoding of The design requires two basic techniques: server push and encoding of
incremental changes. Using existing techniques whenever possible, incremental changes. Using existing techniques whenever possible
this design uses Server-Sent Events (SSEs) for server push; JSON (e.g., WebSocket, HTTP/2), this design uses Server-Sent Events (SSEs)
merge patch and JSON patch to encode incremental changes. Below we for server push; JSON merge patch and JSON patch to encode
give a non-normative summary of these two techniques. incremental changes. Below we give a non-normative summary of these
two techniques.
4.1. Server-Sent Events (SSEs) 4.1. Server-Sent Events (SSEs)
The following is a non-normative summary of SSE; see [SSE] for its The following is a non-normative summary of SSE; see [SSE] for its
normative definition. normative definition.
Server-Sent Events enable a server to send new data to a client by Server-Sent Events enable a server to send new data to a client by
"server-push". The client establishes an HTTP ([RFC7230], [RFC7231]) "server-push". The client establishes an HTTP ([RFC7230], [RFC7231])
connection to the server and keeps the connection open. The server connection to the server and keeps the connection open. The server
continually sends messages. Each message has one or more lines, continually sends messages. Each message has one or more lines,
skipping to change at page 8, line 17 skipping to change at page 8, line 42
4.2.1. JSON Merge Patch Encoding 4.2.1. JSON Merge Patch Encoding
To avoid always sending complete data, a server needs mechanisms to To avoid always sending complete data, a server needs mechanisms to
encode incremental changes. This design uses JSON merge patch as one encode incremental changes. This design uses JSON merge patch as one
mechanism. Below is a non-normative summary of JSON merge patch; see mechanism. Below is a non-normative summary of JSON merge patch; see
[RFC7396] for the normative definition. [RFC7396] for the normative definition.
JSON merge patch is intended to allow applications to update server JSON merge patch is intended to allow applications to update server
resources via the HTTP patch method [RFC5789]. This document adopts resources via the HTTP patch method [RFC5789]. This document adopts
the JSON merge patch message format to encode incremental changes, the JSON merge patch message format to encode incremental changes,
but uses a different transport mechanism. but uses a different HTTP method, i.e., it uses POST instead of
PATCH.
Informally, a JSON merge patch object is a JSON data structure that Informally, a JSON merge patch object is a JSON data structure that
defines how to transform one JSON value into another. Specifically, defines how to transform one JSON value into another. Specifically,
JSON merge patch treats the two JSON values as trees of nested JSON JSON merge patch treats the two JSON values as trees of nested JSON
objects (dictionaries of name-value pairs), where the leaves are objects (dictionaries of name-value pairs), where the leaves are
values (e.g., JSON arrays, strings, numbers) other than JSON objects values (e.g., JSON arrays, strings, numbers) other than JSON objects
and the path for each leaf is the sequence of keys leading to that and the path for each leaf is the sequence of keys leading to that
leaf. When the second tree has a different value for a leaf at a leaf. When the second tree has a different value for a leaf at a
path, or adds a new leaf, the JSON merge patch tree has a leaf, at path, or adds a new leaf, the JSON merge patch tree has a leaf, at
that path, with the new value. When a leaf in the first tree does that path, with the new value. When a leaf in the first tree does
skipping to change at page 16, line 47 skipping to change at page 16, line 47
of the resource. Future documents may define additional mechanisms of the resource. Future documents may define additional mechanisms
for incremental changes. The update stream server decides when to for incremental changes. The update stream server decides when to
send data update messages, and whether to send full replacements or send data update messages, and whether to send full replacements or
incremental changes. These decisions can vary from resource to incremental changes. These decisions can vary from resource to
resource and from update to update. resource and from update to update.
An update stream can run for a long time, and hence there can be An update stream can run for a long time, and hence there can be
status changes at the update stream server side during the lifetime status changes at the update stream server side during the lifetime
of an update stream; for example, the update stream server may of an update stream; for example, the update stream server may
encounter an error or need to shut down for maintenance. To support encounter an error or need to shut down for maintenance. To support
robust, flexible protocol design, this design allows the update robust, flexible protocol design, this document allows the update
stream server to send server control updates (vs data updates) to the stream server to send server control updates (vs data updates) to the
ALTO client as well, showing as control update messages from the ALTO client as well, showing as control update messages from the
update stream server to the ALTO client. update stream server to the ALTO client.
------------------------------------------------------------------ ------------------------------------------------------------------
| | | |
| +-------+ +-------+ init request +-------+ | | +-------+ +-------+ init request +-------+ |
| | | | | <---------- | | | | | | | | <---------- | | |
| add/remove | | | | | | | | add/remove | | | | | | |
| resource |Stream | |Update | data update | | | | resource |Stream | |Update | data update | | |
skipping to change at page 18, line 6 skipping to change at page 18, line 6
6.1. ALTO Update Message Format 6.1. ALTO Update Message Format
Data update and control update messages have the same basic Data update and control update messages have the same basic
structure: each message includes a data field to provide data structure: each message includes a data field to provide data
information, which is typically a JSON object; and an event field information, which is typically a JSON object; and an event field
preceding the data field, to specify the media type indicating the preceding the data field, to specify the media type indicating the
encoding of the data field. encoding of the data field.
A data update message needs additional information to identify the A data update message needs additional information to identify the
ALTO data to which the update message applies. For example, an ALTO ALTO data (object) to which the update message applies. For example,
client can request updates for both a cost map and its dependent an ALTO client can request updates for both a cost map and its
network map in the same update stream. The ALTO client assigns dependent network map in the same update stream. The ALTO client
substream-id "1" in its request to receive updates to the network assigns substream-id "1" in its request to receive updates to the
map; and substream-id "2" to the cost map. For this example, the network map; and substream-id "2" to the cost map. For this example,
substream-id defines the data to be updated and need to be indicated the substream-id defines the data to be updated and need to be
in a data update message. indicated in a data update message. As another example, an ALTO
client can request updates for an ALTO resource returning a multipart
response. Each part of this multipart response is an HTTP message
including a Content-ID header and a JSON object body. The ALTO
client assigns substream-id "mp" in its request to recieve updates to
each part of the multipart response. For this example, the
combination of the substream-id and the Content-ID defines the data
to be updated and need to be indicated in a data update message. To
be generic, this document use a data-id to identify the ALTO data
(object) to be updated.
Hence, the event field of ALTO update message can include two sub- Hence, the event field of ALTO update message can include two sub-
fields (media-type and data-id), where the two sub-fields are fields (media-type and data-id), where the two sub-fields are
separated by a comma: separated by a comma (',', U+002C):
media-type [ ',' data-id ] media-type [ ',' data-id ]
To allow non-ambiguous decoding of the two sub-fields, the media-type According to Section 4.2 of [RFC6838], the comma character is not
name used by ALTO SSE MUST NOT contain a comma (character code 0x2c), allowed in a media-type name. So there is no ambiguous decoding of
and the string before the comma is the media-type name. [To RFC the two sub-fields.
editor: please check this conforms to Section 4.2 of [RFC6838] and
confirms to IANA.]
Note that an update message does not use the SSE "id" field. Note that an update message does not use the SSE "id" field.
6.2. ALTO Data Update Message 6.2. ALTO Data Update Message
A data update message is sent when a monitored resource changes. In A data update message is sent when a monitored resource changes. In
[RFC7285], each resource is encoded as a single JSON object. In the [RFC7285], each resource is encoded as a single JSON object. In the
general case, a resource may include multiple JSON objects. This general case, a resource may include multiple JSON objects. This
document considers the case that a resource may contain multiple document considers the case that a resource may contain multiple
components (parts) and they are encoded using multipart/related components (parts) and they are encoded using multipart/related
[RFC2387]. Each component requiring the service of this document [RFC2387]. Each component requiring the service of this document
MUST be identified by a unique Content-ID to be defined in its MUST be identified by a unique Content-ID to be defined in its
defining document. defining document.
The `data-id` sub-field identifies the ALTO data to which a data The `data-id` sub-field identifies the ALTO data to which a data
update message applies. For a resource containing only a single JSON update message applies. For a resource containing only a single JSON
object, the substream-id assigned by the client when requesting the object, the substream-id assigned by the client when requesting the
SSE service is enough to identify the data. In this document, SSE service is enough to identify the data. Substream-ids MUST be
substream-ids MUST follow the rules for ALTO ResourceIds unique within an update stream, but need not be globally unique. For
(Section 10.2 of [RFC7285]). Substream-ids MUST be unique within an a resource using multipart/related, the `data-id` sub-field MUST be
update stream, but need not be globally unique. For a resource using the concatenation of the substream-id, the '.' separator (U+002E) and
multipart/related, the `data-id` sub-field must include the the unique Content-ID in order.
substream-id, `.` and the unique Content-ID.
A substream-id is encoded as a JSON string with the same format as
that of the type ResourceID (Section 10.2 of [RFC7285]). The type
SubstreamID is used in this document to indicate a string of this
format.
A data update is either a complete specification of the identified A data update is either a complete specification of the identified
data, or else an incremental patch (e.g., a JSON merge patch or JSON data, or else an incremental patch (e.g., a JSON merge patch or JSON
patch), if possible, describing the changes from the last version of patch), if possible, describing the changes from the last version of
the data. This document refers to these as full replacement and the data. This document refers to these as full replacement and
incremental change, respectively. The encoding of a full replacement incremental change, respectively. The encoding of a full replacement
is defined its defining document (e.g., network and cost map messages is defined its defining document (e.g., network and cost map messages
by [RFC7285], and uses media type defined in that document. The by [RFC7285], and uses media type defined in that document. The
encoding of JSON merge patch is defined by [RFC7396], with media type encoding of JSON merge patch is defined by [RFC7396], with media type
"application/merge-patch+json"; the encoding of JSON patch is defined "application/merge-patch+json"; the encoding of JSON patch is defined
skipping to change at page 19, line 32 skipping to change at page 19, line 44
Figure 3: Examples of ALTO data update messages. Figure 3: Examples of ALTO data update messages.
6.3. ALTO Control Update Message 6.3. ALTO Control Update Message
Control update messages have the media type "application/alto- Control update messages have the media type "application/alto-
updatestreamcontrol+json", and the data is of type updatestreamcontrol+json", and the data is of type
UpdateStreamControlEvent: UpdateStreamControlEvent:
object { object {
[String control-uri;] [String control-uri;]
[SubstreamId started<1..*>;] [SubstreamID started<1..*>;]
[SubstreamId stopped<1..*>;] [SubstreamID stopped<1..*>;]
[String description;] [String description;]
} UpdateStreamControlEvent; } UpdateStreamControlEvent;
control-uri: the URI providing stream control for this update stream control-uri: the URI providing stream control for this update stream
(see Section 8). The server MUST send a control update message (see Section 8). The server MUST send a control update message
with an URI as the first event in an update stream. If the URI with an URI as the first event in an update stream. If the URI
is NULL, the update stream server does not support stream is NULL, the update stream server does not support stream
control for this update stream; otherwise, the update stream control for this update stream; otherwise, the update stream
server provides stream control through the given URI. server provides stream control through the given URI.
skipping to change at page 21, line 7 skipping to change at page 21, line 7
7.3. Accept Input Parameters 7.3. Accept Input Parameters
An ALTO client specifies the parameters for the new update stream by An ALTO client specifies the parameters for the new update stream by
sending an HTTP POST body with the media type "application/alto- sending an HTTP POST body with the media type "application/alto-
updatestreamparams+json". That body contains a JSON Object of type updatestreamparams+json". That body contains a JSON Object of type
UpdateStreamReq, where: UpdateStreamReq, where:
object { object {
[AddUpdatesReq add;] [AddUpdatesReq add;]
[SubstreamId remove<0..*>;] [SubstreamID remove<0..*>;]
} UpdateStreamReq; } UpdateStreamReq;
object-map { object-map {
SubstreamId -> AddUpdateReq; SubstreamID -> AddUpdateReq;
} AddUpdatesReq; } AddUpdatesReq;
object { object {
String resource-id; String resource-id;
[String tag;] [String tag;]
[Boolean incremental-changes;] [Boolean incremental-changes;]
[Object input;] [Object input;]
} AddUpdateReq; } AddUpdateReq;
add: specifies the resources (and the parameters for the resources) add: specifies the resources (and the parameters for the resources)
for which the ALTO client wants updates. We say that the add- for which the ALTO client wants updates. We say that the add-
request creates a substream. The ALTO client MUST assign a request creates a substream. The ALTO client MUST assign a
unique substream-id (Section 6.1) for each entry, and uses those unique substream-id (Section 6.2) for each entry, and uses those
substream-ids as the keys in the "add" field. substream-ids as the keys in the "add" field.
resource-id: the resource-id of an ALTO resource, and MUST be in the resource-id: the resource-id of an ALTO resource, and MUST be in the
update stream's "uses" list (Section 8.5.2 of Section 7.5). If update stream's "uses" list (Section 8.5.2 of Section 7.5). If
the resource-id is a GET-mode resource with a version tag (or the resource-id is a GET-mode resource with a version tag (or
"vtag"), as defined in Section 6.3 and Section 10.3 of "vtag"), as defined in Section 6.3 and Section 10.3 of
[RFC7285], and the ALTO client has previously retrieved a [RFC7285], and the ALTO client has previously retrieved a
version of that resource from the update stream server, the ALTO version of that resource from the update stream server, the ALTO
client MAY set the "tag" field to the tag part of the client's client MAY set the "tag" field to the tag part of the client's
version of that resource. If that version is not current, the version of that resource. If that version is not current, the
skipping to change at page 29, line 40 skipping to change at page 29, line 40
stream control server is sure that the update stream server has also stream control server is sure that the update stream server has also
processed the request. Regardless of 202 or 204 HTTP response, the processed the request. Regardless of 202 or 204 HTTP response, the
final updates of related resources will be notified by the update final updates of related resources will be notified by the update
stream server using its control update message(s), due to our modular stream server using its control update message(s), due to our modular
design. design.
9. Examples 9. Examples
9.1. Example: IRD Announcing Update Stream Services 9.1. Example: IRD Announcing Update Stream Services
Below is an example IRD announcing two update stream services. The Below is an example IRD announcing three update stream services. The
first, which is named "update-my-costs", provides updates for the first, which is named "update-my-costs", provides updates for the
network map, the "routingcost" and "hopcount" cost maps, and a network map, the "routingcost" and "hopcount" cost maps, and a
filtered cost map resource. The second, which is named "update-my- filtered cost map resource. The second, which is named "update-my-
prop", provides updates to the endpoint properties service. prop", provides updates to the endpoint properties service. The
third, which is named "update-my-pv", provides updates to a non-
standard ALTO service returning a multipart response.
Note that in the "update-my-costs" update stream shown in the example Note that in the "update-my-costs" update stream shown in the example
IRD, the update stream server uses JSON patch for network map, and it IRD, the update stream server uses JSON patch for network map, and it
uses JSON merge patch to update the other resources. Also, the uses JSON merge patch to update the other resources. Also, the
update stream will only provide full replacements for "my-simple- update stream will only provide full replacements for "my-simple-
filtered-cost-map". filtered-cost-map".
Also, note that this IRD defines two filtered cost map resources. Also, note that this IRD defines two filtered cost map resources.
They use the same cost types, but "my-filtered-cost-map" accepts cost They use the same cost types, but "my-filtered-cost-map" accepts cost
constraint tests, while "my-simple-filtered-cost-map" does not. To constraint tests, while "my-simple-filtered-cost-map" does not. To
avoid the issues discussed in Section 10.4, the update stream avoid the issues discussed in Section 10.3, the update stream
provides updates for the second, but not the first. provides updates for the second, but not the first.
This IRD also announces a non-standard ALTO service, which is named
"my-pv". This service accepts an extended endpoint cost request as
an input and returns a multipart response including an endpoint cost
resource and a property map resource. This document does not rely on
any other design details of this new service. In this document, the
"my-pv" service is only used to illustrate how the update stream
service provides updates to an ALTO resource returning a multipart
response.
"my-network-map": { "my-network-map": {
"uri": "http://alto.example.com/networkmap", "uri": "http://alto.example.com/networkmap",
"media-type": "application/alto-networkmap+json", "media-type": "application/alto-networkmap+json",
}, },
"my-routingcost-map": { "my-routingcost-map": {
"uri": "http://alto.example.com/costmap/routingcost", "uri": "http://alto.example.com/costmap/routingcost",
"media-type": "application/alto-costmap+json", "media-type": "application/alto-costmap+json",
"uses": ["my-networkmap"], "uses": ["my-networkmap"],
"capabilities": { "capabilities": {
"cost-type-names": ["num-routingcost"] "cost-type-names": ["num-routingcost"]
skipping to change at page 31, line 10 skipping to change at page 31, line 22
} }
}, },
"my-props": { "my-props": {
"uri": "http://alto.example.com/properties", "uri": "http://alto.example.com/properties",
"media-type": "application/alto-endpointprops+json", "media-type": "application/alto-endpointprops+json",
"accepts": "application/alto-endpointpropparams+json", "accepts": "application/alto-endpointpropparams+json",
"capabilities": { "capabilities": {
"prop-types": ["priv:ietf-bandwidth"] "prop-types": ["priv:ietf-bandwidth"]
} }
}, },
"my-pv": {
"uri": "http://alto.example.com/endpointcost/pv",
"media-type": "multipart/related;
type=application/alto-endpointcost+json",
"accepts": "application/alto-endpointcostparams+json",
"capabilities": {
"cost-type-names": [ "path-vector" ],
"ane-properties": [ "maxresbw", "persistent-entities" ]
}
},
"update-my-costs": { "update-my-costs": {
"uri": "http://alto.example.com/updates/costs", "uri": "http://alto.example.com/updates/costs",
"media-type": "text/event-stream", "media-type": "text/event-stream",
"accepts": "application/alto-updatestreamparams+json", "accepts": "application/alto-updatestreamparams+json",
"uses": [ "uses": [
"my-network-map", "my-network-map",
"my-routingcost-map", "my-routingcost-map",
"my-hopcount-map", "my-hopcount-map",
"my-simple-filtered-cost-map" "my-simple-filtered-cost-map"
], ],
skipping to change at page 31, line 40 skipping to change at page 32, line 14
"uri": "http://alto.example.com/updates/properties", "uri": "http://alto.example.com/updates/properties",
"media-type": "text/event-stream", "media-type": "text/event-stream",
"uses": [ "my-props" ], "uses": [ "my-props" ],
"accepts": "application/alto-updatestreamparams+json", "accepts": "application/alto-updatestreamparams+json",
"capabilities": { "capabilities": {
"incremental-change-media-types": { "incremental-change-media-types": {
"my-props": "application/merge-patch+json" "my-props": "application/merge-patch+json"
}, },
"support-stream-control": true "support-stream-control": true
} }
},
"update-my-pv": {
"uri": "http://alto.example.com/updates/pv",
"media-type": "text/event-stream",
"uses": [ "my-pv" ],
"accepts": "application/alto-updatestreamparams+json",
"capabilities": {
"incremental-change-media-types": {
"my-pv": "application/merge-patch+json"
},
"support-stream-control": true
}
} }
9.2. Example: Simple Network and Cost Map Updates 9.2. Example: Simple Network and Cost Map Updates
Given the update streams announced in the preceding example IRD, Given the update streams announced in the preceding example IRD,
below we show an example of an ALTO client's request and the update below we show an example of an ALTO client's request and the update
stream server's immediate response, using the update stream resource stream server's immediate response, using the update stream resource
"update-my-costs". In the example, the ALTO client requests updates "update-my-costs". In the example, the ALTO client requests updates
for the network map and "routingcost" cost map, but not for the for the network map and "routingcost" cost map, but not for the
"hopcount" cost map. The ALTO client uses the ALTO server's "hopcount" cost map. The ALTO client uses the ALTO server's
skipping to change at page 41, line 38 skipping to change at page 42, line 38
data: {"ipv6:2001:db8:100::2" : {"priv:ietf-load": "9"}} data: {"ipv6:2001:db8:100::2" : {"priv:ietf-load": "9"}}
data: } data: }
(pause) (pause)
event: application/merge-patch+json,props-4 event: application/merge-patch+json,props-4
data: { "endpoint-properties": data: { "endpoint-properties":
data: {"ipv6:2001:db8:100::4" : {"priv:ietf-load": "3"}} data: {"ipv6:2001:db8:100::4" : {"priv:ietf-load": "3"}}
data: } data: }
10. Operation and Processing Considerations 9.5. Example: Multipart Message Updates
10.1. Considerations for Choosing SSE Line Lengths This example shows how an ALTO client can request a non-standard ALTO
service returning a multipart response. The update stream server
immediately sends full replacements of the multipart response. After
that, the update stream server sends data update messages for the
individual parts of the response as the ALTO data (object) in each
part changes.
SSE was designed for events that consist of relatively small amounts POST /updates/pv HTTP/1.1
of line-oriented text data, and SSE clients frequently read input one Host: alto.example.com
line-at-a-time. However, an update stream sends full cost maps as Accept: text/event-stream
single events, and a cost map may involve megabytes, if not tens of Content-Type: application/alto-updatestreamparams+json
megabytes, of text. This has implications for both the update stream Content-Length: ###
server and the ALTO Client.
First, SSE clients might not be able to handle a multi-megabyte data {
"line". Hence it is RECOMMENDED that an update stream server limit "add": {
data lines to at most 2,000 characters. "ecspvsub1": {
"resource-id": "endpoint-cost-pv",
"input": { ... input of an endpoit cost ... }
}
}
}
Second, some SSE client packages read all the data for an event into HTTP/1.1 200 OK
memory, and then present it to the client as a single character Connection: keep-alive
array. However, a client computer may not have enough memory to hold Content-Type: text/event-stream
the entire JSON text for a large cost map. Hence an ALTO client
SHOULD consider using an SSE library which presents the event data in
manageable chunks, so the ALTO client can parse the cost map
incrementally and store the underlying data in a more compact format.
10.2. Considerations for Choosing Data Update Messages event: application/alto-updatestreamcontrol+json
data: {"control-uri": "http://alto.example.com/updates/streams/1414"}
event: multipart/related;boundary=example-pv;
type=application/alto-endpointcost+json,ecspvsub1
data: --example-pv
data: Content-ID: ecsmap
data: Content-Type: application/alto-endpointcost+json
data:
data: { ... data (object) of an endpoint cost map ... }
data: --example-pv
data: Content-ID: propmap
data: Content-Type: application/alto-propmap+json
data:
data: { ... data (object) of a property map ... }
data: --example-pv--
(pause)
event: application/merge-patch+json,ecspvsub1.ecsmap
data: { ... merge patch for updates of ecspvsub1.ecsmap ... }
event: application/merge-patch+json,ecspvsub1.propmap
data: { ... merge patch for updates of ecspvsub1.propmap ... }
10. Operation and Processing Considerations
10.1. Considerations for Choosing Data Update Messages
The choice on data update messages depends on both how frequently the The choice on data update messages depends on both how frequently the
resources will change, and how extensive those changes will be. For resources will change, and how extensive those changes will be. For
stable resources with minor changes, the update stream server may stable resources with minor changes, the update stream server may
choose to send incremental changes; for resources that frequently choose to send incremental changes; for resources that frequently
change, the update stream server may choose to send a full change, the update stream server may choose to send a full
replacement after a while. Whether to send full replacement or replacement after a while. Whether to send full replacement or
incremental change depends on the update stream server. incremental change depends on the update stream server.
For incremental updates, this design allows both JSON patch and JSON For incremental updates, this design allows both JSON patch and JSON
skipping to change at page 43, line 8 skipping to change at page 45, line 5
that PID, while JSON patch would have to send a list of remove that PID, while JSON patch would have to send a list of remove
operations and delete the prefix one by one. operations and delete the prefix one by one.
Therefore, each update stream server may decide on its own whether to Therefore, each update stream server may decide on its own whether to
use JSON merge patch or JSON patch according to the changes in use JSON merge patch or JSON patch according to the changes in
network maps. network maps.
Other JSON-based incremental change formats may be introduced in the Other JSON-based incremental change formats may be introduced in the
future. future.
10.3. Considerations for Client Processing Data Update Messages 10.2. Considerations for Client Processing Data Update Messages
In general, when an ALTO client receives a full replacement for a In general, when an ALTO client receives a full replacement for a
resource, the ALTO client should replace the current version with the resource, the ALTO client should replace the current version with the
new version. When an ALTO client receives an incremental change for new version. When an ALTO client receives an incremental change for
a resource, the ALTO client should apply those patches to the current a resource, the ALTO client should apply those patches to the current
version of the resource. version of the resource.
However, because resources can depend on other resources (e.g., cost However, because resources can depend on other resources (e.g., cost
maps depend on network maps), an ALTO client MUST NOT use a dependent maps depend on network maps), an ALTO client MUST NOT use a dependent
resource if the resource on which it depends has changed. There are resource if the resource on which it depends has changed. There are
skipping to change at page 44, line 5 skipping to change at page 46, line 5
connection, discard the dependent resources, and reestablish the connection, discard the dependent resources, and reestablish the
update stream. The ALTO client MAY retain the version tag of the update stream. The ALTO client MAY retain the version tag of the
last version of any tagged resources and give those version tags when last version of any tagged resources and give those version tags when
requesting the new update stream. In this case, if a version is requesting the new update stream. In this case, if a version is
still current, the update stream server will not re-send that still current, the update stream server will not re-send that
resource. resource.
Although not as efficient as possible, this recovery method is simple Although not as efficient as possible, this recovery method is simple
and reliable. and reliable.
10.4. Considerations for Updates to Filtered Cost Maps 10.3. Considerations for Updates to Filtered Cost Maps
If an update stream provides updates to a Filtered cost map which If an update stream provides updates to a Filtered cost map which
allows constraint tests, then an ALTO client MAY request updates to a allows constraint tests, then an ALTO client MAY request updates to a
Filtered cost map request with a constraint test. In this case, when Filtered cost map request with a constraint test. In this case, when
a cost changes, the update stream server MUST send an update if the a cost changes, the update stream server MUST send an update if the
new value satisfies the test. If the new value does not, whether the new value satisfies the test. If the new value does not, whether the
update stream server sends an update depends on whether the previous update stream server sends an update depends on whether the previous
value satisfied the test. If it did not, the update stream server value satisfied the test. If it did not, the update stream server
SHOULD NOT send an update to the ALTO client. But if the previous SHOULD NOT send an update to the ALTO client. But if the previous
value did, then the update stream server MUST send an update with a value did, then the update stream server MUST send an update with a
"null" value, to inform the ALTO client that this cost no longer "null" value, to inform the ALTO client that this cost no longer
satisfies the criteria. satisfies the criteria.
An update stream server can avoid such issues by offering update An update stream server can avoid such issues by offering update
streams only for filtered cost maps which do not allow constraint streams only for filtered cost maps which do not allow constraint
tests. tests.
10.5. Considerations for Updates to Ordinal Mode Costs 10.4. Considerations for Updates to Ordinal Mode Costs
For an ordinal mode cost map, a change to a single cost point may For an ordinal mode cost map, a change to a single cost point may
require updating many other costs. As an extreme example, suppose require updating many other costs. As an extreme example, suppose
the lowest cost changes to the highest cost. For a numerical mode the lowest cost changes to the highest cost. For a numerical mode
cost map, only that one cost changes. But for an ordinal mode cost cost map, only that one cost changes. But for an ordinal mode cost
map, every cost might change. While this document allows an update map, every cost might change. While this document allows an update
stream server to offer incremental updates for ordinal mode cost stream server to offer incremental updates for ordinal mode cost
maps, update stream server implementors should be aware that maps, update stream server implementors should be aware that
incremental updates for ordinal costs are more complicated than for incremental updates for ordinal costs are more complicated than for
numerical costs, and ALTO clients should be aware that small changes numerical costs, and ALTO clients should be aware that small changes
may result in large updates. may result in large updates.
An update stream server can avoid this complication by only offering An update stream server can avoid this complication by only offering
full replacements for ordinal cost maps. full replacements for ordinal cost maps.
10.5. Considerations for SSE Text Formatting and Processing
SSE was designed for events that consist of relatively small amounts
of line-oriented text data, and SSE clients frequently read input one
line-at-a-time. However, an update stream sends a full cost map as a
single events, and a cost map may involve megabytes, if not tens of
megabytes, of text. This has implications that the ALTO client and
the update stream server may consider.
First, some SSE client libraries read all data for an event into
memory, and then present it to the client as a character array.
However, a client may not have enough memory to hold the entire JSON
text for a large cost map. Hence an ALTO client SHOULD consider
using an SSE library which presents the event data in manageable
chunks, so the ALTO client can parse the cost map incrementally and
store the underlying data in a more compact format.
Second, an SSE client library may use a low level, generic socket
read library that stores each line of an event data, just in case the
higher level parser may need the line delimiters as part of the
protocol formatting. A server sending a complete cost map as a
single line may then generate a multi-megabyte data "line", and such
a long line may then require complex memory management at the client.
It is RECOMMENDED that an update stream server limit the lengths of
data lines.
11. Security Considerations 11. Security Considerations
As an extension of the base ALTO protocol [RFC7285], this document As an extension of the base ALTO protocol [RFC7285], this document
fits into the architecture of the base protocol, and hence the fits into the architecture of the base protocol, and hence the
Security Considerations (Section 15) of the base protocol fully apply Security Considerations (Section 15) of the base protocol fully apply
when this extension is provided by an ALTO server. For example, the when this extension is provided by an ALTO server. For example, the
same authenticity and integrity considerations (Section 15.1 of same authenticity and integrity considerations (Section 15.1 of
[RFC7285]) still fully apply; the same considerations for the privacy [RFC7285]) still fully apply; the same considerations for the privacy
of ALTO users (Section 15.4 of [RFC7285]) also still fully apply. of ALTO users (Section 15.4 of [RFC7285]) also still fully apply.
skipping to change at page 46, line 31 skipping to change at page 49, line 9
design is made. design is made.
At the low level encoding level, new line in SSE has its own At the low level encoding level, new line in SSE has its own
semantics. Hence, this design requires that resource encoding does semantics. Hence, this design requires that resource encoding does
not include new lines that can confuse with SSE encoding. In not include new lines that can confuse with SSE encoding. In
particular, the data update message MUST NOT include "event: " or particular, the data update message MUST NOT include "event: " or
"data: " at a new line as part of data message. "data: " at a new line as part of data message.
If an update stream provides updates to a filtered cost map that If an update stream provides updates to a filtered cost map that
allows constraint tests, the requirements for such services are allows constraint tests, the requirements for such services are
stated in Section 10.4. stated in Section 10.3.
13. IANA Considerations 13. IANA Considerations
This document defines two new media-types, "application/alto- This document defines two new media-types, "application/alto-
updatestreamparams+json", as described in Section 7.3, and updatestreamparams+json", as described in Section 7.3, and
"application/alto-updatestreamcontrol+json", as described in "application/alto-updatestreamcontrol+json", as described in
Section 6.3. All other media-types used in this document have Section 6.3. All other media-types used in this document have
already been registered, either for ALTO, JSON merge patch, or JSON already been registered, either for ALTO, JSON merge patch, or JSON
patch. patch.
skipping to change at page 50, line 41 skipping to change at page 53, line 17
extended by adding version tags to cost maps, which would solve the extended by adding version tags to cost maps, which would solve the
retransmission-on-reconnect problem. However, adding tags to cost retransmission-on-reconnect problem. However, adding tags to cost
maps might add a new set of complications. maps might add a new set of complications.
15. Acknowledgments 15. Acknowledgments
Thank you to Dawn Chen (Tongji University), Shawn Lin (Tongji Thank you to Dawn Chen (Tongji University), Shawn Lin (Tongji
University) and Xiao Shi (Yale University) for their contributions to University) and Xiao Shi (Yale University) for their contributions to
an earlier version of this document. an earlier version of this document.
16. References 16. Contributors
Section 3, Section 6 and Section 9 of this document are based on
contributions from Jingxuan Jensen Zhang.
17. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, BCP 14, August 1998. RFC 2387, BCP 14, August 1998.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
5789, March 2010. RFC 4960, September 2007.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, March 2010.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", RFC 6838, Specifications and Registration Procedures", RFC 6838,
January 2013. January 2013.
[RFC6902] Bryan, P. and M. Nottingham, "JavaScript Object Notation [RFC6902] Bryan, P. and M. Nottingham, "JavaScript Object Notation
(JSON) Patch", RFC 6902, April 2013. (JSON) Patch", RFC 6902, April 2013.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285, September
2014.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014. 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285, September
2014.
[RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396,
October 2014. October 2014.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. Protocol Version 2 (HTTP/2)", RFC 7540, May 2015.
[SSE] Hickson, I., "Server-Sent Events (W3C)", W3C [SSE] Hickson, I., "Server-Sent Events (W3C)", W3C
Recommendation 03 February 2015, February 2015. Recommendation 03 February 2015, February 2015.
Authors' Addresses Authors' Addresses
 End of changes. 44 change blocks. 
100 lines changed or deleted 234 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/