draft-ietf-rtcweb-data-protocol-00.txt		draft-ietf-rtcweb-data-protocol-01.txt
	RTCWeb Working Group R. Jesup		RTCWeb Working Group R. Jesup
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track S. Loreto		Intended status: Standards Track S. Loreto
	Expires: January 16, 2014 Ericsson		Expires: April 24, 2014 Ericsson
	M. Tuexen		M. Tuexen
	Muenster Univ. of Appl. Sciences		Muenster Univ. of Appl. Sciences
	July 15, 2013		October 21, 2013
	WebRTC Data Channel Protocol		RTCWeb Data Channel Protocol
	draft-ietf-rtcweb-data-protocol-00.txt		draft-ietf-rtcweb-data-protocol-01.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 an actual (minor) protocol for how		browsers. This document specifies a simple protocol for establishing
	the JS-layer DataChannel objects provide the data channels between		symmetric data channels between the peers. It uses a two way
	the peers.		handshake and allows sending of user data without waiting for the
			handshake to complete.
	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 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 16, 2014.		This Internet-Draft will expire on April 24, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 15		skipping to change at page 2, line 16
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
	5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 4		5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4
	6. Control Messages . . . . . . . . . . . . . . . . . . . . . . 4		5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4
	6.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4		5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 6
	7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Adding a Channel (in-band open) . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7.2. Adding a Channel (external negotiation) . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7.3. Closing a Channel . . . . . . . . . . . . . . . . . . . . 7		8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 7
	7.4. Sending and Receiving Data . . . . . . . . . . . . . . . 8		8.2. New Message Type Registry . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 8
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 9
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	11.2. Informational References . . . . . . . . . . . . . . . . 10		10.2. Informational References . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The DataChannel Protocol is designed to provide, in the WebRTC		The data channel protocol is designed to provide, in the WebRTC data
	context [I-D.ietf-rtcweb-overview], a generic transport service		channel context [I-D.ietf-rtcweb-data-channel], a simple in-band
	allowing a Web Browser to exchange generic data in a bidirectional		method to open symmetric data channels. As discussed in
	peer to peer fashion. As discussed in [I-D.ietf-rtcweb-data-channel]		[I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control
	the protocol uses Stream Control Transmission Protocol (SCTP)		Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram
	[RFC4960] encapsulated on Datagram Transport Layer Security (DTLS)		Transport Layer Security (DTLS) [RFC6347] as described in
	[RFC6347] as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] to		[I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already
	benefit from their already standardized transport and security		standardized transport and security features.
	features.
	2. Conventions		2. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"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-65535).		uniquely identified by a stream identifier (0-65534). Note:
			stream identifier 65535 is reserved due to SCTP Init messages
			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 identifier, one in each
	direction, that are managed together.		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.
	Channels are created by sending an optional DATA_CHANNEL_OPEN message		The set of consistent properties includes
	on an unused Stream. There is no handshake, and the channel is
	available to send on as soon as the DATA_CHANNEL_OPEN has been sent.
	Alternatively, both sides make externally agree to a set of
	parameters for a Channel, in which case no DATA_CHANNEL_OPEN message
	is required.
	To avoid glare in opening Channels, each side must use either even or		o whether the messages are transmitted reliable or unreliable. In
			case of unreliable transmissions, the same level of unreliability
			is used.
			o whether the messages are delivered in-order or out-of order.
			o an optional label for the Channel.
			o an optional protocol for the Channel.
			o the outgoing SCTP stream.
			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
			Stream and sends a DATA_CHANNEL_OPEN message. The peer responds with
			a DATA_CHANNEL_ACK message. Then the data channel is open. Please
			note that the opening side can send user messages before the
			DATA_CHANNEL_ACK is received. These 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.
			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 RTCWeb, 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 labelled "x" at the same time, there will be two Channels		a Channel labeled "x" at the same time, there will be two Channels
	labelled "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 data being passed with an IANA-
	registered string, and may also be useful for homogenous applications		registered string, and may be useful for homogenous applications
	which may create more than one type of Channel.		which may create more than one type of Channel.
	Data that arrives which on an unused Stream MUST be held for a period		5. Message Formats
	TBD until a DATA_CHANNEL_OPEN arrived for that Channel, or until the
	protocol stack has been told to expect data on that Stream (via
	external negotiation), or until [TBD - report error]. This allows
	for external negotiation of streams (or assumption of negotiation by
	cooperating applications). If a later DATA_CHANNEL_OPEN arrives that
	conflicts with the pre-set properties of the Channel, an error should
	be signaled to higher levels.
	Channels are closed by an SCTP reset of the Stream.
	5. Opening Handshake
	The opening handshake is based on the multimedia session description
	exchange that happens between the browsers, typically through a Web
	Server acting as the signaling service.
	[I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier, 'DTLS/
	SCTP', and defines how to establish an SCTP association over DTLS
	using the Session Description Protocol (SDP).
	The SCTP association is created with the number of streams specified
	by the application, and if not specified, then it SHOULD default to
	16 streams.
	It is recommended that additional streams be available dynamically
	based on [RFC6525].
	6. Control Messages
	Control Messages are sent to manage opening bidirectional channels.
	A DATA_CHANNEL_OPEN message is sent on the Stream that is intended to		Every data channel protocol message starts with a one byte field
	be used for a new Channel, and this creates a bidirectional Channel		called "Message Type" which indicates the type of the message. The
	that may be used by both sides to send data.		corresponding values are managed by IANA (see Section 8.2).
	6.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. All DATA_CHANNEL_OPEN messages MUST be sent using		using the channel.
	SCTP options for reliable in-order delivery.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 26		skipping to change at page 4, line 46
	/ \		/ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ /		\ /
	| 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. NOTE: values 0x00-0x02 were used in an older draft		IANA is 0x03.
	with incompatible structures. Any future incompatible message
	changes should define new message types.
	Channel Type: 1 byte (unsigned integer)		Channel Type: 1 byte (unsigned integer)
	This field specifies the type of the channel to be opened:		This field specifies the type of the channel to be opened and the
			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
	skipping to change at page 6, line 39		skipping to change at page 6, line 10
	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. This may be an empty string. If
	used, it SHOULD be an IANA-registered protocol.		used, it is an IANA-registered protocol (see Section 8.4).
	7. Procedures		5.2. DATA_CHANNEL_ACK Message
	7.1. Adding a Channel (in-band open)		This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE
	When one side wants to add a channel using in-band declaration, it		message on the stream used for user messages using the channel.
	picks an unused outgoing Stream (even stream identifier for DTLS		Reception of this message tells the opener that the channel setup
	clients, or odd for DTLS servers); if no unused streams are available		handshake is complete.
	a negotiation to increase the number is done via [RFC6525], or
	failure is returned. It should also check that the other side has
	the same channel available, and if not then initiate an increase in
	the number of streams. It then sends a DATA_CHANNEL_OPEN control
	message on the outgoing stream.
	When an DATA_CHANNEL_OPEN is received on an incoming Stream, the		0 1 2 3
	Stream is associated with a newly-created Channel (unless the Stream		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
	was already part of an externally-negotiated Channel). If any data		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	had arrived on the Stream before the Open arrives and had been		| Message Type |
	buffered, it is now delivered on the new Channel.		+-+-+-+-+-+-+-+-+
	The channel_type and reliability_parameters fields of the		Message Type: 1 byte (unsigned integer)
	DATA_CHANNEL_OPEN message MUST be used to set up the reverse side of		This field holds the IANA defined message type for the the
	the Channel so that both directions use the same options by default.		DATA_CHANNEL_ACK message. The suggested value of this field for
			IANA is 0x02.
	7.2. Adding a Channel (external negotiation)		6. Procedures
	When one side wants to add a channel using external negotiation, it		All data channel protocol messages MUST be sent requesting ordered
	picks a Stream. This can be done by asking the protocol to select an		delivery and using reliable transmission. They MUST be sent on the
	unused Stream (of the approriate even or odd type), or by simply		same outgoing SCTP stream as the user messages belonging to the
	telling the protocol what Stream to use. In the latter case, the		corresponding data channel. Multiplexing and demultiplexing is done
	application is responsible for avoiding collisions with existing		by using the SCTP payload protocol identifier (PPID). Therefore data
	Streams. If it attempts to re-use a Stream which is part of an		channel protocol message MUST be sent with the assigned PPID for the
	existing Channel, the addition should fail.		data channel protocol (see Section 8.1). Other message MUST NOT be
			sent using this PPID.
	In addition to choosing a Stream, the application should also inform		If one sides wants to open a data channel, it chooses a free outgoing
	the protocol of the options to use for sending messages. Note that		SCTP stream. If the side is the DTLS client, it MUST choose an even
	there is no requirement for both sides to have the same options for		stream identifier, if the side is the DTLS server, it MUST choose an
	an externally-negotiated stream, though typically this will be the		odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message
	case.		and sends it on the chosen SCTP stream.
	The application must now ensure in an application-specific manner		After the DATA_CHANNEL_OPEN message has been sent, the sender of it
	that the other side will also inform the protocol that the selected		can start sending messages containing user data without waiting for
	Stream is to be used, and the parameters for sending data from that		the reception of the corresponding DATA_CHANNEL_ACK message.
	side.		However, before the DATA_CHANNEL_ACK message or any other message has
			been received on the data channel, all other messages containing user
			data and belonging to the data channel MUST be sent ordered, not
			matter whether the data channel is ordered or not. After the
			DATA_CHANNEL_ACK or any other message has been received on the data
			channel, messages containing user data MUST be send ordered on
			ordered data channels and MUST be sent unordered on unordered data
			channels. Therefore receiving a message containing user data on an
			unused SCTP stream indicates an error. The corresponding outgoing
			SCTP stream MUST be reset using [RFC6525].
	7.3. Closing a Channel		If a DATA_CHANNEL_OPEN message is received on an unused stream, the
			stream identifier corresponds to the role of the peer and all
			parameters in the DATA_CHANNEL_OPEN message are valid, then a
			corresponding DATA_CHANNEL_ACK message is sent on the stream with the
			same stream identifier as the one the DATA_CHANNEL_OPEN message was
			received on.
	Channels MUST be closed by and SCTP reset of the outgoing Stream. If		If a DATA_CHANNEL_OPEN message is received on an already used SCTP
	an incoming Stream is reset by the peer, an corresponding outgoing		stream or there are any problems with parameters within the
	stream reset SHOULD be issued. If the streams in both directions of		DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is
	a Channel are reset, the Channel is considered fully closed and the		not well-formed, the receiver MUST reset the corresponding outgoing
	Streams are available for reuse for new channel opens.		SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK
			message in response to the received message. Therefore, receiving an
			SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK
			message has been received indicates to the sender of the
			corresponding DATA_CHANNEL_OPEN message the failure of the data
			channel setup procedure.
	7.4. Sending and Receiving Data		7. Security Considerations
	Data shall be sent using PPID's other than the Data Channel Control		This document does not add any additional considerations to the ones
	PPID. These PPID's should be registered with IANA via (TBD). The		given in [I-D.ietf-rtcweb-security] and
	meaning of these data PPIDs and the format of the data shall be		[I-D.ietf-rtcweb-security-arch].
	specific to the usage of this protocol, and typically shall be
	provided to the higher layers to allow proper decoding of the data.
	It is RECOMMENDED that higher layers wishing to transfer large		8. IANA Considerations
	messages fragment them using PPIDs or other mechanisms to avoid
	monopolization of the SCTP association by the transfer of a single
	large message, unless a future SCTP draft relaxes this concern. If
	fragmented solely with PPID values, then transmission MUST occur on a
	reliable in-order channel. If in-band application framing is used,
	then other options may be possible.
	For WebRTC, data PPID's for DOMStrings and binary data (and		[NOTE to RFC-Editor:
	fragmentation thereof) shall be created.
	All data sent on a Channel in both directions MUST be sent over the		"RFCXXXX" is to be replaced by the RFC number you assign this
	underlying Stream using the reliability defined when the Channel was		document.
	opened unless the options are changed, or per-message options are
	specified by a higher level.
	Data may be sent immediately after sending or receiving a		]
	DATA_CHANNEL_OPEN message, or after creating an externally-negotiated
	Channel.
	It is recommended that message size be kept within certain size		IANA is asked to update the reference of an already existing SCTP
	bounds (TBD) as applications will not be able to support arbitrarily-		PPID assignment and to create three new registries for the data
	large single messages.		channel protocol.
	8. Security Considerations		8.1. SCTP Payload Protocol Identifier
			This document uses one already registered SCTP Payload Protocol
			Identifier (PPID). [RFC4960] creates the registry "SCTP Payload
			Protocol Identifiers" from which this identifier was assigned. IANA
			is requested to update the reference of this assignment to point to
			this document. Therefore this assignment should be updated to read:
	To be done.		+----------------+-----------+-----------+
			| Value | SCTP PPID | Reference |
			+----------------+-----------+-----------+
			| WebRTC Control | 50 | [RFCXXXX] |
			+----------------+-----------+-----------+
	9. IANA Considerations		8.2. New Message Type Registry
	[NOTE to RFC-Editor:		IANA is requested to create a new registration table "Message Type
			Registry" for the data channel protocol to manage the one byte
			"Message Type" field in data channel messages (see Section 5).
	"RFCXXXX" is to be replaced by the RFC number you assign this		The assignment of new message types is done through an RFC required
	document.		action, as defined in [RFC5226]. Documentation of the new message
			type MUST contain the following information:
	]		1. A name for the new message type;
	[NOTE to RFC-Editor:		2. A detailed procedural description of the use of messages with the
			new type within the operation of the data channel protocol.
	The suggested values for the Payload Protocol Identifiers are		Initially the following values need to be registered:
	tentative and to be confirmed by IANA.
	]		+-------------------+-----------+-----------+
			| Name | Type | Reference |
			+-------------------+-----------+-----------+
			| Reserved | 0x00 | [RFCXXXX] |
			| Reserved | 0x01 | [RFCXXXX] |
			| DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] |
			| DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] |
			| Unassigned | 0x04-0xfe | |
			| Reserved | 0xff | [RFCXXXX] |
			+-------------------+-----------+-----------+
	This document defines five new SCTP Payload Protocol Identifiers		8.3. New Channel Type Registry
	(PPIDs). [RFC4960] creates the registry "SCTP Payload Protocol
	Identifiers" from which these identifiers need to be assigned. The
	following values are suggested:
	+---------------------+-----------+-----------+		IANA is requested to create a new registration table "Channel Type
	| Value | SCTP PPID | Reference |		Registry" for the data channel protocol to manage the one byte
	+---------------------+-----------+-----------+		"Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1).
	| WebRTC Control | 50 | [RFCXXXX] |
	| DOMString Last | 51 | [RFCXXXX] |
	| Binary Data Partial | 52 | [RFCXXXX] |
	| Binary Data Last | 53 | [RFCXXXX] |
	| DOMString Partial | 54 | [RFCXXXX] |
	+---------------------+-----------+-----------+
	10. Acknowledgments		The assignment of new message types is done through an RFC required
			action, as defined in [RFC5226]. Documentation of the new channel
			type MUST contain the following information:
			1. A name for the new channel type;
			2. A detailed procedural description of the user message handling
			for data channels using this new channel type.
			Please note that if new channel types support ordered and unordered
			message delivery, the high order bit SHOULD be used to indicated
			whether the message delivery is unordered or not.
			Initially the following values need to be registered:
			+------------------------------------------------+------+-----------+
			| Name | Type | Reference |
			+------------------------------------------------+------+-----------+
			| DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] |
			| DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] |
			| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] |
			| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] |
			| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] |
			| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] |
			| Reserved | 0x7f | [RFCXXXX] |
			| Reserved | 0xff | [RFCXXXX] |
			| Unassigned | rest | |
			+------------------------------------------------+------+-----------+
			8.4. New Protocol Registry
			IANA is requested to create a new registration table "Protocol
			Registry" for the data channel 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
	The authors wish to thank Martin Thompson, Cullen Jennings, Harald		The authors wish to thank Martin Thompson, Cullen Jennings, Harald
	Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall		Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall
	Stewart, Stefan Haekansson and many others for their invaluable		Stewart, Stefan Haekansson and many others for their invaluable
	comments.		comments.
	11. References		10. References
	11.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.
	[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
	Conrad, "Stream Control Transmission Protocol (SCTP)
	Partial Reliability Extension", RFC 3758, May 2004.
	[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
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	[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-mmusic-sctp-sdp]
	Loreto, S. and G. Camarillo, "Stream Control Transmission
	Protocol (SCTP)-Based Media Transport in the Session
	Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04
	(work in progress), June 2013.
	[I-D.ietf-tsvwg-sctp-dtls-encaps]		[I-D.ietf-tsvwg-sctp-dtls-encaps]
	Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS		Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
	Encapsulation of SCTP Packets for RTCWEB", draft-ietf-		Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
	tsvwg-sctp-dtls-encaps-00 (work in progress), February		dtls-encaps-02 (work in progress), October 2013.
	2013.
	11.2. Informational References
	[I-D.ietf-rtcweb-overview]		10.2. Informational References
	Alvestrand, H., "Overview: Real Time Protocols for Brower-
	based Applications", draft-ietf-rtcweb-overview-06 (work
	in progress), February 2013.
	[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-04 (work in		Channels", draft-ietf-rtcweb-data-channel-05 (work in
	progress), February 2013.		progress), July 2013.
	Authors' Addresses		[I-D.ietf-rtcweb-security]
			Rescorla, E., "Security Considerations for WebRTC", draft-
			ietf-rtcweb-security-05 (work in progress), July 2013.
			[I-D.ietf-rtcweb-security-arch]
			Rescorla, E., "WebRTC Security Architecture", draft-ietf-
			rtcweb-security-arch-07 (work in progress), July 2013.
			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. 61 change blocks.
	202 lines changed or deleted		243 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/