draft-ietf-rtcweb-data-protocol-01.txt   draft-ietf-rtcweb-data-protocol-02.txt 
RTCWeb 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: April 24, 2014 Ericsson Expires: August 13, 2014 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
October 21, 2013 February 9, 2014
RTCWeb Data Channel Protocol WebRTC Data Channel Protocol
draft-ietf-rtcweb-data-protocol-01.txt draft-ietf-rtcweb-data-protocol-02.txt
Abstract Abstract
The Web Real-Time Communication (WebRTC) working group is charged to The Web Real-Time Communication (WebRTC) working group is charged to
provide protocols to support for direct interactive rich provide protocols to support for direct interactive rich
communication using audio, video, and data between two peers' web- communication using audio, video, and data between two peers' web-
browsers. This document specifies a simple protocol for establishing browsers. This document specifies a simple protocol for establishing
symmetric data channels between the peers. It uses a two way symmetric data channels between the peers. It uses a two way
handshake and allows sending of user data without waiting for the handshake and allows sending of user data without waiting for the
handshake to complete. handshake to complete.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 April 24, 2014. This Internet-Draft will expire on August 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . 6 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 6
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 7 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 8
8.2. New Message Type Registry . . . . . . . . . . . . . . . . 8 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 8
8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 8 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 9
8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 9 8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informational References . . . . . . . . . . . . . . . . 10 10.2. Informational References . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The data channel protocol is designed to provide, in the WebRTC data The data channel protocol is designed to provide, in the WebRTC data
channel context [I-D.ietf-rtcweb-data-channel], a simple in-band channel context [I-D.ietf-rtcweb-data-channel], a simple in-band
method to open symmetric data channels. As discussed in method to open symmetric data channels. As discussed in
[I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control
Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram
Transport Layer Security (DTLS) [RFC6347] as described in Transport Layer Security (DTLS) [RFC6347] as described in
[I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already
skipping to change at page 3, line 8 skipping to change at page 3, line 12
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document uses the following terms: This document uses the following terms:
Association: An SCTP association. Association: An SCTP association.
Stream: A unidirectional stream of an SCTP association. It is Stream: A unidirectional stream of an SCTP association. It is
uniquely identified by a stream identifier (0-65534). Note: uniquely identified by an SCTP stream identifier (0-65534). Note:
stream identifier 65535 is reserved due to SCTP Init messages the SCTP stream identifier 65535 is reserved due to SCTP INIT and
allowing a maximum of 65535 streams to be negotiated (0-65534). INIT-ACK chunks only allowing a maximum of 65535 streams to be
negotiated (0-65534).
Channel: Two Streams with the same identifier, one in each Channel: Two Streams with the same SCTP stream identifier, one in
direction, which are managed together. each direction, which are managed together.
4. Protocol Overview 4. Protocol Overview
This protocol is a simple, low-overhead way to establish This protocol is a simple, low-overhead way to establish
bidirectional Channels over an SCTP association with a consistent set bidirectional Channels over an SCTP association with a consistent set
of properties. of properties.
The set of consistent properties includes The set of consistent properties includes
o whether the messages are transmitted reliable or unreliable. In o whether the messages are transmitted reliable or unreliable. In
case of unreliable transmissions, the same level of unreliability case of unreliable transmissions, the same level of unreliability
is used. is used.
o whether the messages are delivered in-order or out-of order. o whether the messages are delivered in-order or out-of order.
o an optional label for the Channel. o an optional label for the Channel.
o an optional protocol for the Channel. o an optional protocol for the Channel.
o the outgoing SCTP stream. o the SCTP streams.
The data channel protocol uses a two way handshake to open a data The data channel protocol uses a two way handshake to open a data
channel. The side wanting to open a data channel selects an unused channel by combining two SCTP streams, one in each direction, with
Stream and sends a DATA_CHANNEL_OPEN message. The peer responds with the same SCTP stream identifier. The side wanting to open a data
a DATA_CHANNEL_ACK message. Then the data channel is open. Please channel selects an SCTP stream identifier for which the corresponding
note that the opening side can send user messages before the incoming and outgoing SCTP stream is unused and sends a
DATA_CHANNEL_ACK is received. These data channel messages are sent DATA_CHANNEL_OPEN message on this outgoing SCTP stream. The peer
on the same Stream as the user messages belonging to the data responds with a DATA_CHANNEL_ACK message on its corresponding
channel. The demultiplexing is based on the SCTP payload protocol outgoing SCTP stream. Then the data channel is open. Please note
identifier. that the opening side can send user messages before the
DATA_CHANNEL_ACK is received. Data channel messages are sent on the
same Stream as the user messages belonging to the data channel. The
demultiplexing is based on the SCTP payload protocol identifier
(PPID), since the data channel protocol uses a specific PPID.
To avoid glare in opening Channels, each side MUST use either even or To avoid glare in opening Channels, each side MUST use either even or
odd Streams when sending a DATA_CHANNEL_OPEN message. The method odd Streams when sending a DATA_CHANNEL_OPEN message. The method
used to determine which side uses odd or even is based on the used to determine which side uses odd or even is based on the
underlying DTLS connection role when used in RTCWeb, with the side underlying DTLS connection role when used in WebRTC, with the side
acting as the DTLS client using even stream identifiers. acting as the DTLS client using even stream identifiers.
Note: There is no attempt to resolve label glare; if both sides open Note: There is no attempt to resolve label glare; if both sides open
a Channel labeled "x" at the same time, there will be two Channels a Channel labeled "x" at the same time, there will be two Channels
labeled "x" - one on an even Stream pair, one on an odd pair. labeled "x" - one on an even Stream pair, one on an odd pair.
The protocol field is to ease cross-application interoperation The protocol field is to ease cross-application interoperation
("federation") by identifying the data being passed with an IANA- ("federation") by identifying the user data being passed with an
registered string, and may be useful for homogenous applications IANA-registered string (see Section 8.4), and may be useful for
which may create more than one type of Channel. homogenous applications which may create more than one type of
Channel.
5. Message Formats 5. Message Formats
Every data channel protocol message starts with a one byte field Every data channel protocol message starts with a one byte field
called "Message Type" which indicates the type of the message. The called "Message Type" which indicates the type of the message. The
corresponding values are managed by IANA (see Section 8.2). corresponding values are managed by IANA (see Section 8.2).
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 channel. using the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability Parameter | | Reliability Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Length | Protocol Length | | Label Length | Protocol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / \ /
| 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 the This field holds the IANA defined message type for the the
DATA_CHANNEL_OPEN message. The suggested value of this field for DATA_CHANNEL_OPEN message. The suggested value of this field for
IANA is 0x03. IANA is 0x03.
Channel Type: 1 byte (unsigned integer) Channel Type: 1 byte (unsigned integer)
This field specifies the type of the channel to be opened and the This field specifies the type of the channel to be opened and the
values are managed by IANA (see Section 8.3): values are managed by IANA (see Section 8.3):
DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable in- DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable in-
order bi-directional communication channel. order bi-directional communication channel.
DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The channel provides a DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The channel provides a
reliable unordered bi-directional communication channel. reliable unordered bi-directional communication channel.
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The channel provides DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The channel provides
a partially-reliable in-order bi-directional Communication a partially-reliable in-order bi-directional Communication
channel. User messages will not be retransmitted more times channel. User messages will not be retransmitted more times
than specified in the Reliability Parameter. than specified in the Reliability Parameter.
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The
channel provides a partial reliable unordered bi-directional channel provides a partial reliable unordered bi-directional
Communication channel. User messages will not be Communication channel. User messages will not be retransmitted
retransmitted more times than specified in the Reliability more times than specified in the Reliability Parameter.
Parameter.
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides
a partial reliable in-order bi-directional Communication a partial reliable in-order bi-directional Communication
channel. User messages might not be transmitted or channel. User messages might not be transmitted or
retransmitted after a specified life-time given in milli- retransmitted after a specified life-time given in milli-
seconds in the Reliability Parameter. This life-time starts seconds in the Reliability Parameter. This life-time starts
when providing the user message to the Javascript engine. when providing the user message to the Javascript engine.
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel
provides a partial reliable unordered bi-directional provides a partial reliable unordered bi-directional
Communication channel. User messages might not be Communication channel. User messages might not be transmitted
transmitted or retransmitted after a specified life-time or retransmitted after a specified life-time given in milli-
given in milli-seconds in the Reliability Parameter. This seconds in the Reliability Parameter. This life-time starts
life-time starts when providing the user message to the when providing the user message to the Javascript engine.
Javascript engine.
Priority: 2 bytes (integer) Priority: 2 bytes (integer)
The priority of the channel. The priority of the channel as described in
[I-D.ietf-rtcweb-data-channel]. The higher the number, the lower
the priority.
Reliability Parameter: 4 bytes (unsigned integer) Reliability Parameter: 4 bytes (unsigned integer)
This field is ignored if a reliable channel is used. This field is ignored if a reliable channel is used.
If a partial reliable channel with limited number of If a partial reliable channel with limited number of
retransmissions is used, this field specifies the number of retransmissions is used, this field specifies the number of
retransmissions. If a partial reliable channel with limited retransmissions. If a partial reliable channel with limited
lifetime is used, this field specifies the maximum lifetime in lifetime is used, this field specifies the maximum lifetime in
milliseconds. milliseconds. The following table summarizes this:
+------------------------------------------------+------------------+
| Channel Type | Reliability |
| | Parameter |
+------------------------------------------------+------------------+
| DATA_CHANNEL_RELIABLE | Ignored |
| DATA_CHANNEL_RELIABLE_UNORDERED | Ignored |
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX |
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX |
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms |
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms |
+------------------------------------------------+------------------+
Label Length: 2 bytes (unsigned integer) Label Length: 2 bytes (unsigned integer)
The length of the label field in bytes. The length of the label field in bytes.
Protocol Length: 2 bytes (unsigned integer) Protocol Length: 2 bytes (unsigned integer)
The length of the protocol field in bytes. The length of the protocol field in bytes.
Label: Variable Length (sequence of characters) Label: Variable Length (sequence of characters)
The name of the channel. This may be an empty string. The name of the channel. This may be an empty string.
Protocol: Variable Length (sequence of characters) Protocol: Variable Length (sequence of characters)
The protocol for the channel. This may be an empty string. If The protocol for the channel. If this is an empty string the
used, it is an IANA-registered protocol (see Section 8.4). protocol us unspecified. If it is an non-empty string, it
specifies an IANA-registered protocol (see Section 8.4).
5.2. DATA_CHANNEL_ACK Message 5.2. DATA_CHANNEL_ACK Message
This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE
message on the stream used for user messages using the channel. message on the stream used for user messages using the channel.
Reception of this message tells the opener that the channel setup Reception of this message tells the opener that the channel setup
handshake is complete. 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 the This field holds the IANA defined message type for the the
DATA_CHANNEL_ACK message. The suggested value of this field for DATA_CHANNEL_ACK message. The suggested value of this field for
IANA is 0x02. IANA is 0x02.
6. Procedures 6. Procedures
All data channel protocol messages MUST be sent requesting ordered All data channel protocol messages MUST be sent requesting ordered
delivery and using reliable transmission. They MUST be sent on the delivery and using reliable transmission. They MUST be sent on the
skipping to change at page 7, line 29 skipping to change at page 7, line 52
If a DATA_CHANNEL_OPEN message is received on an already used SCTP If a DATA_CHANNEL_OPEN message is received on an already used SCTP
stream or there are any problems with parameters within the stream or there are any problems with parameters within the
DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is
not well-formed, the receiver MUST reset the corresponding outgoing not well-formed, the receiver MUST reset the corresponding outgoing
SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK
message in response to the received message. Therefore, receiving an message in response to the received message. Therefore, receiving an
SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK
message has been received indicates to the sender of the message has been received indicates to the sender of the
corresponding DATA_CHANNEL_OPEN message the failure of the data corresponding DATA_CHANNEL_OPEN message the failure of the data
channel setup procedure. channel setup procedure. After also successfully resetting the
corresponding outgoing SCTP stream, a new DATA_CHANNEL_OPEN message
can be sent on the stream.
7. Security Considerations 7. Security Considerations
This document does not add any additional considerations to the ones This document does not add any additional considerations to the ones
given in [I-D.ietf-rtcweb-security] and given in [I-D.ietf-rtcweb-security] and
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
8. IANA Considerations 8. IANA Considerations
[NOTE to RFC-Editor: [NOTE to RFC-Editor:
skipping to change at page 8, line 44 skipping to change at page 9, line 20
| Name | Type | Reference | | Name | Type | Reference |
+-------------------+-----------+-----------+ +-------------------+-----------+-----------+
| Reserved | 0x00 | [RFCXXXX] | | Reserved | 0x00 | [RFCXXXX] |
| 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
interoperability problems, since they have been used in earlier
versions of the document.
8.3. New Channel Type Registry 8.3. 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 protocol to manage the one byte Registry" for the data channel protocol to manage the one byte
"Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1).
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:
skipping to change at page 10, line 33 skipping to change at page 11, line 19
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
Transmission Protocol (SCTP) Stream Reconfiguration", RFC Transmission Protocol (SCTP) Stream Reconfiguration", RFC
6525, February 2012. 6525, February 2012.
[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-02 (work in progress), October 2013. dtls-encaps-03 (work in progress), February 2014.
10.2. Informational References 10.2. Informational References
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data
Channels", draft-ietf-rtcweb-data-channel-05 (work in Channels", draft-ietf-rtcweb-data-channel-06 (work in
progress), July 2013. progress), October 2013.
[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-05 (work in progress), July 2013. ietf-rtcweb-security-06 (work in progress), January 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-07 (work in progress), July 2013. rtcweb-security-arch-08 (work in progress), January 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
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
 End of changes. 34 change blocks. 
87 lines changed or deleted 113 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/