draft-ietf-rtcweb-data-protocol-03.txt   draft-ietf-rtcweb-data-protocol-04.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: August 15, 2014 Ericsson Expires: October 11, 2014 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
February 11, 2014 April 9, 2014
WebRTC Data Channel Establishment Protocol WebRTC Data Channel Establishment Protocol
draft-ietf-rtcweb-data-protocol-03.txt draft-ietf-rtcweb-data-protocol-04.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 August 15, 2014. This Internet-Draft will expire on October 11, 2014.
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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 6 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 8 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9
8.2. New Message Type Registry . . . . . . . . . . . . . . . . 8 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9
8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 9 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10
8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informational References . . . . . . . . . . . . . . . . 11 10.2. Informational References . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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
[I-D.ietf-rtcweb-data-channel], a simple in-band method to open [I-D.ietf-rtcweb-data-channel], a simple in-band method to open
symmetric data channels. As discussed in 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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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 the priority of the Channel.
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 SCTP streams. o the SCTP streams.
The Data Channel Establishment Protocol uses a two way handshake to The Data Channel Establishment Protocol uses a two way handshake to
open a data channel by combining two SCTP streams, one in each open a data channel by combining two SCTP streams, one in each
direction, with the same SCTP stream identifier. The side wanting to direction, with the same SCTP stream identifier. The side wanting to
open a data channel selects an SCTP stream identifier for which the open a data channel selects an SCTP stream identifier for which the
skipping to change at page 4, line 19 skipping to change at page 4, line 20
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 WebRTC, 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 user data being passed with an ("federation") by identifying the user data being passed with an
IANA-registered string (see Section 8.4), and may be useful for IANA-registered string ('WebSocket Subprotocol Name Registry' defined
homogenous applications which may create more than one type of in [RFC6455]), and may be useful for homogeneous applications which
Channel. may create more than one type of Channel. Please note that there is
also no attempt to resolve protocol glare.
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).
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
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 retransmitted communication channel. User messages will not be retransmitted
more times than specified in the Reliability Parameter. more times than specified in the Reliability 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 protocol stack.
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 transmitted communication channel. User messages might not be transmitted
or retransmitted after a specified life-time given in milli- or 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 protocol stack.
Priority: 2 bytes (integer) Priority: 2 bytes (integer)
The priority of the channel as described in The priority of the channel as described in
[I-D.ietf-rtcweb-data-channel]. The higher the number, the lower [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower
the priority. the priority.
Reliability Parameter: 4 bytes (unsigned integer) Reliability Parameter: 4 bytes (unsigned integer)
This field is ignored if a reliable channel is used. For reliable channels this field MUST be set to 0 on the sending
If a partial reliable channel with limited number of side and MUST be ignored on the receiving side. If a partial
retransmissions is used, this field specifies the number of reliable channel with limited number of retransmissions is used,
retransmissions. If a partial reliable channel with limited this field specifies the number of retransmissions. If a partial
lifetime is used, this field specifies the maximum lifetime in reliable channel with limited lifetime is used, this field
milliseconds. The following table summarizes this: specifies the maximum lifetime in milliseconds. The following
table summarizes this:
+------------------------------------------------+------------------+ +------------------------------------------------+------------------+
| Channel Type | Reliability | | Channel Type | Reliability |
| | Parameter | | | Parameter |
+------------------------------------------------+------------------+ +------------------------------------------------+------------------+
| DATA_CHANNEL_RELIABLE | Ignored | | DATA_CHANNEL_RELIABLE | Ignored |
| DATA_CHANNEL_RELIABLE_UNORDERED | Ignored | | DATA_CHANNEL_RELIABLE_UNORDERED | Ignored |
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX |
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 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 | Lifetime in ms |
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 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 as a UTF-8 encoded string. This may be an
empty string.
Protocol: Variable Length (sequence of characters) Protocol: Variable Length (sequence of characters)
The protocol for the channel. If this is an empty string the The sub-protocol for the channel as a UTF-8 encoded string. If
protocol us unspecified. If it is an non-empty string, it this is an empty string the protocol is unspecified. If it is a
specifies an IANA-registered protocol (see Section 8.4). non-empty string, it specifies an protocol registered in the
'WebSocket Subprotocol Name Registry' created in [RFC6455].
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 a 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
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 Establishment Protocol messages MUST be sent All Data Channel Establishment Protocol messages MUST be sent using
requesting ordered delivery and using reliable transmission. They ordered delivery and reliable transmission. They MUST be sent on the
MUST be sent on the same outgoing SCTP stream as the user messages same outgoing SCTP stream as the user messages belonging to the
belonging to the corresponding data channel. Multiplexing and corresponding data channel. Multiplexing and demultiplexing is done
demultiplexing is done by using the SCTP payload protocol identifier by using the SCTP payload protocol identifier (PPID). Therefore Data
(PPID). Therefore Data Channel Establishment Protocol message MUST Channel Establishment Protocol message MUST be sent with the assigned
be sent with the assigned PPID for the Data Channel Establishment PPID for the Data Channel Establishment Protocol (see Section 8.1).
Protocol (see Section 8.1). Other message MUST NOT be sent using Other messages MUST NOT be sent using this PPID.
this PPID.
If one sides wants to open a data channel, it chooses an SCTP stream If one side wants to open a data channel, it chooses an SCTP stream
identifier for which the corresponding incoming and outgoing SCTP identifier for which the corresponding incoming and outgoing SCTP
streams are free. If the side is the DTLS client, it MUST choose an streams 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 even stream identifier, if the side is the DTLS server, it MUST
choose an odd one. It fills in the parameters of the choose an odd one. It fills in the parameters of the
DATA_CHANNEL_OPEN message and sends it on the chosen SCTP stream. DATA_CHANNEL_OPEN message and sends it on the chosen SCTP stream.
After the DATA_CHANNEL_OPEN message has been sent, the sender of it After the DATA_CHANNEL_OPEN message has been sent, the sender of it
can start sending messages containing user data without waiting for can start sending messages containing user data without waiting for
the reception of the corresponding DATA_CHANNEL_ACK message. the reception of the corresponding DATA_CHANNEL_ACK message.
However, before the DATA_CHANNEL_ACK message or any other message has However, before the DATA_CHANNEL_ACK message or any other message has
been received on the data channel, all other messages containing user been received on a data channel, all other messages containing user
data and belonging to the data channel MUST be sent ordered, not data and belonging to this data channel MUST be sent ordered, no
matter whether the data channel is ordered or not. After the matter whether the data channel is ordered or not. After the
DATA_CHANNEL_ACK or any other message has been received on the data DATA_CHANNEL_ACK or any other message has been received on the data
channel, messages containing user data MUST be send ordered on channel, messages containing user data MUST be send ordered on
ordered data channels and MUST be sent unordered on unordered data ordered data channels and MUST be sent unordered on unordered data
channels. Therefore receiving a message containing user data on an channels. Therefore receiving a message containing user data on an
unused SCTP stream indicates an error. The corresponding outgoing unused SCTP stream indicates an error. The corresponding channel
SCTP stream MUST be reset using [RFC6525]. MUST be closed as described in [I-D.ietf-rtcweb-data-channel].
If a DATA_CHANNEL_OPEN message is received on an unused stream, the If a DATA_CHANNEL_OPEN message is received on an unused stream, the
stream identifier corresponds to the role of the peer and all stream identifier corresponds to the role of the peer and all
parameters in the DATA_CHANNEL_OPEN message are valid, then a parameters in the DATA_CHANNEL_OPEN message are valid, then a
corresponding DATA_CHANNEL_ACK message is sent on the stream with the corresponding DATA_CHANNEL_ACK message is sent on the stream with the
same stream identifier as the one the DATA_CHANNEL_OPEN message was same stream identifier as the one the DATA_CHANNEL_OPEN message was
received on. received on.
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 close the corresponding channel
SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK using the procedure described in [I-D.ietf-rtcweb-data-channel] and
message in response to the received message. Therefore, receiving an MUST NOT send a DATA_CHANNEL_ACK message in response to the received
SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK message. Therefore, receiving an SCTP stream reset request for a
message has been received indicates to the sender of the stream on which no DATA_CHANNEL_ACK message has been received
corresponding DATA_CHANNEL_OPEN message the failure of the data indicates to the sender of the corresponding DATA_CHANNEL_OPEN
channel setup procedure. After also successfully resetting the message the failure of the data channel setup procedure. After also
corresponding outgoing SCTP stream, a new DATA_CHANNEL_OPEN message successfully resetting the corresponding outgoing SCTP stream, which
can be sent on the stream. concludes the channel closing initiated by the peer, 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:
"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 three new registries for the Data PPID assignment and to create two new registries for the Data Channel
Channel Establishment Protocol. Establishment Protocol.
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.
Therefore this assignment should be updated to read: Therefore this assignment should be updated to read:
skipping to change at page 9, line 30 skipping to change at page 10, line 4
| 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 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. versions of the document. The value 0xff has been reserved for
future extensibility.
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 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).
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.
Please note that if new channel types support ordered and unordered Please note that if new channel types support ordered and unordered
message delivery, the high order bit SHOULD be used to indicated message delivery, the high order bit SHOULD be used to indicate
whether the message delivery is unordered or not. whether the message delivery is unordered or not.
Initially the following values need to be registered: Initially the following values need to be registered:
+------------------------------------------------+------+-----------+ +------------------------------------------------+------+-----------+
| Name | Type | Reference | | Name | Type | Reference |
+------------------------------------------------+------+-----------+ +------------------------------------------------+------+-----------+
| DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] |
| 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 | |
+------------------------------------------------+------+-----------+ +------------------------------------------------+------+-----------+
8.4. New Protocol Registry
IANA is requested to create a new registration table "Protocol
Registry" for the Data Channel Establishment Protocol to manage the
"Protocol" field of type string in DATA_CHANNEL_OPEN messages (see
Section 5.1).
The assignment of new message types is done through an First Come
First Served action, as defined in [RFC5226]. Documentation of the
new protocol MUST contain the following information:
1. A name for the protocol;
2. A reference for the protocol indicated by the registered string.
Initially this registry is empty.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry
Dingle, Stefan Haekansson, Cullen Jennings, Randall Stewart, Peter Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Irene
Thatcher, Martin Thompson, Justin Uberti, and many others for their Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson, Justin
invaluable comments. Uberti, and many others for their 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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
skipping to change at page 11, line 23 skipping to change at page 11, line 33
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-03 (work in progress), February 2014. dtls-encaps-03 (work in progress), February 2014.
10.2. Informational References 10.2. Informational References
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
6455, December 2011.
[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, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-06 (work in Channels", draft-ietf-rtcweb-data-channel-07 (work in
progress), October 2013. progress), February 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-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-08 (work in progress), January 2014. rtcweb-security-arch-09 (work in progress), February 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. 37 change blocks. 
107 lines changed or deleted 100 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/