draft-ietf-rtcweb-data-protocol-07.txt   draft-ietf-rtcweb-data-protocol-08.txt 
Network Working Group R. Jesup Network Working Group R. Jesup
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Loreto Intended status: Standards Track S. Loreto
Expires: January 5, 2015 Ericsson Expires: April 1, 2015 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
July 4, 2014 September 28, 2014
WebRTC Data Channel Establishment Protocol WebRTC Data Channel Establishment Protocol
draft-ietf-rtcweb-data-protocol-07.txt draft-ietf-rtcweb-data-protocol-08.txt
Abstract Abstract
The WebRTC framework specifies protocol support for direct The WebRTC framework specifies protocol support for direct
interactive rich communication using audio, video, and data between interactive rich communication using audio, video, and data between
two peers' web-browsers. This document specifies a simple protocol two peers' web-browsers. This document specifies a simple protocol
for establishing symmetric Data Channels between the peers. It uses for establishing symmetric Data Channels between the peers. It uses
a two way handshake and allows sending of user data without waiting a two way handshake and allows sending of user data without waiting
for the handshake to complete. for the handshake to complete.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 http://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 5, 2015. This Internet-Draft will expire on April 1, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 (http://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 22 skipping to change at page 2, line 22
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4
5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9
8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9 8.2. New Standalone Registry for the DCEP . . . . . . . . . . 9
8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10 8.2.1. New Message Type Registry . . . . . . . . . . . . . . 9
8.2.2. New Channel Type Registry . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informational References . . . . . . . . . . . . . . . . 12 10.2. Informational References . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Data Channel Establishment Protocol (DCEP) is designed to The Data Channel Establishment Protocol (DCEP) is designed to
provide, in the WebRTC Data Channel context provide, in the WebRTC Data Channel context
skipping to change at page 3, line 47 skipping to change at page 3, line 47
o an optional label for the Data Channel. o an optional label for the Data Channel.
o an optional protocol for the Data Channel. o an optional protocol for the Data Channel.
o the Streams. o the Streams.
This protocol uses a two way handshake to open a Data Channel. The This protocol uses a two way handshake to open a Data Channel. The
handshake pairs one incoming and one outgoing Stream, both having the handshake pairs one incoming and one outgoing Stream, both having the
same Stream Identifier, into a single bidirectional Data Channel. same Stream Identifier, into a single bidirectional Data Channel.
The side wanting to open a Data Channel selects an Stream Identifier The side wanting to open a Data Channel selects a Stream Identifier
for which the corresponding incoming and outgoing Streams are unused for which the corresponding incoming and outgoing Streams are unused
and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. The and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. The
peer responds with a DATA_CHANNEL_ACK message on its corresponding peer responds with a DATA_CHANNEL_ACK message on its corresponding
outgoing Stream. Then the Data Channel is open. Data Channel outgoing Stream. Then the Data Channel is open. Data Channel
Establishment Protocol messages are sent on the same Stream as the Establishment Protocol messages are sent on the same Stream as the
user messages belonging to the Data Channel. The demultiplexing is user messages belonging to the Data Channel. The demultiplexing is
based on the SCTP payload protocol identifier (PPID), since the Data based on the SCTP payload protocol identifier (PPID), since the Data
Channel Establishment Protocol uses a specific PPID. Channel Establishment Protocol uses a specific PPID.
Note: The opening side can send user messages before the Note: The opening side can send user messages before the
DATA_CHANNEL_ACK is received. DATA_CHANNEL_ACK is received.
To avoid glare in opening Data Channels, each side MUST use Streams To avoid collisions where both sides try to open a Data Channel with
with either even or odd Stream Identifiers when sending a the same Stream Identifiers, each side MUST use Streams with either
DATA_CHANNEL_OPEN message. When using SCTP over DTLS even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN
message. When using SCTP over DTLS
[I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which
side uses odd or even is based on the underlying DTLS connection side uses odd or even is based on the underlying DTLS connection
role: the side acting as the DTLS client MUST use Streams with even role: the side acting as the DTLS client MUST use Streams with even
Stream Identifiers, the side acting as the DTLS server MUST use Stream Identifiers, the side acting as the DTLS server MUST use
Streams with odd Stream Identifiers. Streams with odd Stream Identifiers.
Note: There is no attempt to resolve label glare; if both sides open Note: There is no attempt to ensure uniqueness for the label; if both
a Data Channel labeled "x" at the same time, there will be two Data sides open a Data Channel labeled "x" at the same time, there will be
Channels labeled "x" - one on an even Stream pair, one on an odd two Data Channels labeled "x" - one on an even Stream pair, one on an
pair. odd pair.
The protocol field is to ease cross-application interoperation The protocol field is to ease cross-application interoperation
("federation") by identifying the user data being passed with an ("federation") by identifying the user data being passed with an
IANA-registered string ('WebSocket Subprotocol Name Registry' defined IANA-registered string ('WebSocket Subprotocol Name Registry' defined
in [RFC6455]), and may be useful for homogeneous applications which in [RFC6455]), and may be useful for homogeneous applications which
may create more than one type of Data Channel. Please note that may create more than one type of Data Channel. Please note that
there is also no attempt to resolve protocol glare. there is also no attempt to ensure uniqueness for the protocol field.
5. Message Formats 5. Message Formats
Every Data Channel Establishment Protocol message starts with a one Every Data Channel Establishment Protocol message starts with a one
byte field called "Message Type" which indicates the type of the byte field called "Message Type" which indicates the type of the
message. The corresponding values are managed by IANA (see message. The corresponding values are managed by IANA (see
Section 8.2). Section 8.2.1).
5.1. DATA_CHANNEL_OPEN Message 5.1. DATA_CHANNEL_OPEN Message
This message is sent initially on the Stream used for user messages This message is sent initially on the Stream used for user messages
using the Data Channel. using the Data Channel.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Channel Type | Priority | | Message Type | Channel Type | Priority |
skipping to change at page 5, line 25 skipping to change at page 5, line 25
| Label | | Label |
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / \ /
| Protocol | | Protocol |
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Type: 1 byte (unsigned integer) Message Type: 1 byte (unsigned integer)
This field holds the IANA defined message type for the This field holds the IANA defined message type for the
DATA_CHANNEL_OPEN message. The suggested value of this field for DATA_CHANNEL_OPEN message. The value of this field is 0x03 as
IANA is 0x03. specified in Section 8.2.1.
Channel Type: 1 byte (unsigned integer) Channel Type: 1 byte (unsigned integer)
This field specifies the type of the Data Channel to be opened and This field specifies the type of the Data Channel to be opened and
the values are managed by IANA (see Section 8.3): the values are managed by IANA (see Section 8.2.2):
DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a
reliable in-order bi-directional communication. reliable in-order bi-directional communication.
DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides
a reliable unordered bi-directional communication. a reliable unordered bi-directional communication.
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel
provides a partially-reliable in-order bi-directional provides a partially-reliable in-order bi-directional
communication. User messages will not be retransmitted more communication. User messages will not be retransmitted more
skipping to change at page 7, line 22 skipping to change at page 7, line 22
setup handshake is complete. setup handshake is complete.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | | Message Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Message Type: 1 byte (unsigned integer) Message Type: 1 byte (unsigned integer)
This field holds the IANA defined message type for the This field holds the IANA defined message type for the
DATA_CHANNEL_ACK message. The suggested value of this field for DATA_CHANNEL_ACK message. The value of this field is 0x02 as
IANA is 0x02. specified in Section 8.2.1.
6. Procedures 6. Procedures
All Data Channel Establishment Protocol messages MUST be sent using All Data Channel Establishment Protocol messages MUST be sent using
ordered delivery and reliable transmission. They MUST be sent on the ordered delivery and reliable transmission. They MUST be sent on the
same outgoing Stream as the user messages belonging to the same outgoing Stream as the user messages belonging to the
corresponding Data Channel. Multiplexing and demultiplexing is done corresponding Data Channel. Multiplexing and demultiplexing is done
by using the SCTP payload protocol identifier (PPID). Therefore Data by using the SCTP payload protocol identifier (PPID). Therefore Data
Channel Establishment Protocol message MUST be sent with the assigned Channel Establishment Protocol message MUST be sent with the assigned
PPID for the Data Channel Establishment Protocol (see Section 8.1). PPID for the Data Channel Establishment Protocol (see Section 8.1).
Other messages MUST NOT be sent using this PPID. Other messages MUST NOT be sent using this PPID.
If one side wants to open a Data Channel, it chooses an Stream If one side wants to open a Data Channel, it chooses a Stream
identifier for which the corresponding incoming and outgoing Streams Identifier for which the corresponding incoming and outgoing Streams
are free. If the side is the DTLS client, it MUST choose an even are free. If the side is the DTLS client, it MUST choose an even
Stream Identifier, if the side is the DTLS server, it MUST choose an Stream Identifier, if the side is the DTLS server, it MUST choose an
odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message
and sends it on the chosen Stream. and sends it on the chosen Stream.
After the DATA_CHANNEL_OPEN message has been sent, the sender of the After the DATA_CHANNEL_OPEN message has been sent, the sender of the
DATA_CHANNEL_OPEN can start sending messages containing user data DATA_CHANNEL_OPEN can start sending messages containing user data
without waiting for the reception of the corresponding without waiting for the reception of the corresponding
DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK
message or any other message has been received on a Data Channel, all message or any other message has been received on a Data Channel, all
skipping to change at page 9, line 15 skipping to change at page 9, line 15
8. IANA Considerations 8. IANA Considerations
[NOTE to RFC-Editor: [NOTE to RFC-Editor:
"RFCXXXX" is to be replaced by the RFC number you assign this "RFCXXXX" is to be replaced by the RFC number you assign this
document. document.
] ]
IANA is asked to update the reference of an already existing SCTP IANA is asked to update the reference of an already existing SCTP
PPID assignment and to create two new registries for the Data Channel PPID assignment (Section 8.1) and to create a new standalone registry
Establishment Protocol. with its own URL for the DCEP (Section 8.2) containing two new
registration tables (Section 8.2.1 and Section 8.2.2).
8.1. SCTP Payload Protocol Identifier 8.1. SCTP Payload Protocol Identifier
This document uses one already registered SCTP Payload Protocol This document uses one already registered SCTP Payload Protocol
Identifier (PPID) named "WebRTC Control". [RFC4960] creates the Identifier (PPID) named "WebRTC Control". [RFC4960] creates the
registry "SCTP Payload Protocol Identifiers" from which this registry "SCTP Payload Protocol Identifiers" from which this
identifier was assigned. IANA is requested to update the reference identifier was assigned. IANA is requested to update the reference
of this assignment to point to this document and to update the name. of this assignment to point to this document and to update the name.
The corresponding date should be kept.
Therefore this assignment should be updated to read: Therefore this assignment should be updated to read:
+-------------+-----------+-----------+ +-------------+-----------+-----------+------------+
| Value | SCTP PPID | Reference | | Value | SCTP PPID | Reference | Date |
+-------------+-----------+-----------+ +-------------+-----------+-----------+------------+
| WebRTC DCEP | 50 | [RFCXXXX] | | WebRTC DCEP | 50 | [RFCXXXX] | 2013-09-20 |
+-------------+-----------+-----------+ +-------------+-----------+-----------+------------+
8.2. New Message Type Registry 8.2. New Standalone Registry for the DCEP
IANA is requested to create a new standalone registry (aka a webpage)
with its own URL for the Data Channel Establishment Protocol (DCEP).
The title should be "Data Channel Establishment Protocol (DCEP)
Parameters". It will contain the two tables as described in
Section 8.2.1 and Section 8.2.2.
8.2.1. New Message Type Registry
IANA is requested to create a new registration table "Message Type IANA is requested to create a new registration table "Message Type
Registry" for the Data Channel Establishment Protocol (DCEP) to Registry" for the Data Channel Establishment Protocol (DCEP) to
manage the one byte "Message Type" field in DCEP messages (see manage the one byte "Message Type" field in DCEP messages (see
Section 5). Section 5). This registration table should be part of the registry
described in Section 8.2.
The assignment of new message types is done through an RFC required The assignment of new message types is done through an RFC required
action, as defined in [RFC5226]. Documentation of the new message action, as defined in [RFC5226]. Documentation of the new message
type MUST contain the following information: type MUST contain the following information:
1. A name for the new message type; 1. A name for the new message type;
2. A detailed procedural description of the use of messages with the 2. A detailed procedural description of the use of messages with the
new type within the operation of the Data Channel Establishment new type within the operation of the Data Channel Establishment
Protocol. Protocol.
skipping to change at page 10, line 19 skipping to change at page 10, line 31
| Reserved | 0x01 | [RFCXXXX] | | Reserved | 0x01 | [RFCXXXX] |
| DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] |
| DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] |
| Unassigned | 0x04-0xfe | | | Unassigned | 0x04-0xfe | |
| Reserved | 0xff | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] |
+-------------------+-----------+-----------+ +-------------------+-----------+-----------+
Please note that the values 0x00 and 0x01 are reserved to avoid Please note that the values 0x00 and 0x01 are reserved to avoid
interoperability problems, since they have been used in earlier interoperability problems, since they have been used in earlier
versions of the document. The value 0xff has been reserved for versions of the document. The value 0xff has been reserved for
future extensibility. future extensibility. The range of possible values is from 0x00 to
0xff.
8.3. New Channel Type Registry 8.2.2. New Channel Type Registry
IANA is requested to create a new registration table "Channel Type IANA is requested to create a new registration table "Channel Type
Registry" for the Data Channel Establishment Protocol to manage the Registry" for the Data Channel Establishment Protocol to manage the
one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see
Section 5.1). Section 5.1). This registration table should be part of the registry
described in Section 8.2.
The assignment of new message types is done through an RFC required The assignment of new message types is done through an RFC required
action, as defined in [RFC5226]. Documentation of the new Channel action, as defined in [RFC5226]. Documentation of the new Channel
Type MUST contain the following information: Type MUST contain the following information:
1. A name for the new Channel Type; 1. A name for the new Channel Type;
2. A detailed procedural description of the user message handling 2. A detailed procedural description of the user message handling
for Data Channels using this new Channel Type. for Data Channels using this new Channel Type.
skipping to change at page 11, line 19 skipping to change at page 11, line 25
| DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] |
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] |
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] |
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] |
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] |
| Reserved | 0x7f | [RFCXXXX] | | Reserved | 0x7f | [RFCXXXX] |
| Reserved | 0xff | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] |
| Unassigned | rest | | | Unassigned | rest | |
+------------------------------------------------+------+-----------+ +------------------------------------------------+------+-----------+
Please note that the values 0x7f and 0xff have been reserved for
future extensibility. The range of possible values is from 0x00 to
0xff.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry The authors wish to thank Harald Alvestrand, Richard Barnes, Adam
Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Doug Bergkvist, Barry Dingle, Stefan Haekansson, Cullen Jennings, Paul
Leonard, Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin Kyzivat, Doug Leonard, Irene Ruengeler, Randall Stewart, Peter
Thompson, Justin Uberti, and many others for their invaluable Thatcher, Martin Thompson, Justin Uberti, and many others for their
comments. invaluable comments.
10. References 10. References
10.1. Normative References 10.1. Normative 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", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
skipping to change at page 11, line 47 skipping to change at page 12, line 8
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-04 (work in progress), May 2014. dtls-encaps-05 (work in progress), July 2014.
[I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-11 (work in
progress), July 2014.
10.2. Informational References 10.2. Informational References
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
6455, December 2011. 6455, December 2011.
[I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-10 (work in
progress), June 2014.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-06 (work in progress), January 2014. ietf-rtcweb-security-07 (work in progress), July 2014.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-09 (work in progress), February 2014. rtcweb-security-arch-10 (work in progress), July 2014.
Authors' Addresses Authors' Addresses
Randell Jesup Randell Jesup
Mozilla Mozilla
US US
Email: randell-ietf@jesup.org Email: randell-ietf@jesup.org
Salvatore Loreto Salvatore Loreto
 End of changes. 28 change blocks. 
48 lines changed or deleted 68 lines changed or added

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