draft-ietf-rtcweb-data-channel-11.txt		draft-ietf-rtcweb-data-channel-12.txt
	Network Working Group R. Jesup		Network Working Group R. Jesup
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track S. Loreto		Intended status: Standards Track S. Loreto
	Expires: January 5, 2015 Ericsson		Expires: April 1, 2015 Ericsson
	M. Tuexen		M. Tuexen
	Muenster Univ. of Appl. Sciences		Muenster Univ. of Appl. Sciences
	July 4, 2014		September 28, 2014
	WebRTC Data Channels		WebRTC Data Channels
	draft-ietf-rtcweb-data-channel-11.txt		draft-ietf-rtcweb-data-channel-12.txt
	Abstract		Abstract
	The WebRTC framework specifies protocol support for direct		The WebRTC framework specifies protocol support for direct
	interactive rich communication using audio, video, and data between		interactive rich communication using audio, video, and data between
	two peers' web-browsers. This document specifies the non-media data		two peers' web-browsers. This document specifies the non-media data
	transport aspects of the WebRTC framework. It provides an		transport aspects of the WebRTC framework. It provides an
	architectural overview of how the Stream Control Transmission		architectural overview of how the Stream Control Transmission
	Protocol (SCTP) is used in the WebRTC context as a generic transport		Protocol (SCTP) is used in the WebRTC context as a generic transport
	service allowing WEB-browsers to exchange generic data from peer to		service allowing WEB-browsers to exchange generic data from peer to
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 5, 2015.		This Internet-Draft will expire on April 1, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 22		skipping to change at page 2, line 22
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Use Cases for Unreliable Data Channels . . . . . . . . . 3		3.1. Use Cases for Unreliable Data Channels . . . . . . . . . 3
	3.2. Use Cases for Reliable Data Channels . . . . . . . . . . 4		3.2. Use Cases for Reliable Data Channels . . . . . . . . . . 4
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 5		5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 5
	6. The Usage of SCTP for Data Channels . . . . . . . . . . . . . 8		6. The Usage of SCTP for Data Channels . . . . . . . . . . . . . 8
	6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8		6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8
	6.2. Association Setup . . . . . . . . . . . . . . . . . . . . 9		6.2. SCTP Association Management . . . . . . . . . . . . . . . 9
	6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9		6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9
	6.4. WebRTC Data Channel Definition . . . . . . . . . . . . . 9		6.4. Data Channel Definition . . . . . . . . . . . . . . . . . 9
	6.5. Opening a Channel . . . . . . . . . . . . . . . . . . . . 10		6.5. Opening a Data Channel . . . . . . . . . . . . . . . . . 10
	6.6. Transferring User Data on a Channel . . . . . . . . . . . 10		6.6. Transferring User Data on a Data Channel . . . . . . . . 11
	6.7. Closing a Channel . . . . . . . . . . . . . . . . . . . . 11		6.7. Closing a Data Channel . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	In the WebRTC framework, communication between the parties consists		In the WebRTC framework, communication between the parties consists
	of media (for example audio and video) and non-media data. Media is		of media (for example audio and video) and non-media data. Media is
	sent using SRTP, and is not specified further here. Non-media data		sent using SRTP, and is not specified further here. Non-media data
	is handled by using SCTP [RFC4960] encapsulated in DTLS [RFC4347].		is handled by using SCTP [RFC4960] encapsulated in DTLS [RFC4347].
	+----------+		+----------+
	| SCTP |		| SCTP |
	skipping to change at page 7, line 13		skipping to change at page 7, line 13
	Figure 2.		Figure 2.
	+------+------+------+		+------+------+------+
	| DCEP | UTF-8|Binary|		| DCEP | UTF-8|Binary|
	| | data | data |		| | data | data |
	+------+------+------+		+------+------+------+
	| SCTP |		| SCTP |
	+----------------------------------+		+----------------------------------+
	| STUN | SRTP | DTLS |		| STUN | SRTP | DTLS |
	+----------------------------------+		+----------------------------------+
	| ICE |		| ICE |
	+----------------------------------+		+----------------------------------+
	| UDP1 | UDP2 | ... |		| UDP1 | UDP2 | UDP3 | ... |
	+----------------------------------+		+----------------------------------+
	Figure 2: WebRTC protocol layers		Figure 2: WebRTC protocol layers
	This stack (especially in contrast to DTLS over SCTP [RFC6083] in		This stack (especially in contrast to DTLS over SCTP [RFC6083] in
	combination with SCTP over UDP [RFC6951]) has been chosen because it		combination with SCTP over UDP [RFC6951]) has been chosen because it
	o supports the transmission of arbitrary large user messages.		o supports the transmission of arbitrary large user messages.
	o shares the DTLS connection with the SRTP media channels of the		o shares the DTLS connection with the SRTP media channels of the
	skipping to change at page 8, line 22		skipping to change at page 8, line 22
	complete SCTP packet, so it provides confidentiality, integrity and		complete SCTP packet, so it provides confidentiality, integrity and
	source authentication of the complete SCTP packet.		source authentication of the complete SCTP packet.
	SCTP provides congestion control on a per-association base. This		SCTP provides congestion control on a per-association base. This
	means that all SCTP streams within a single SCTP association share		means that all SCTP streams within a single SCTP association share
	the same congestion window. Traffic not being sent over SCTP is not		the same congestion window. Traffic not being sent over SCTP is not
	covered by the SCTP congestion control. Using a congestion control		covered by the SCTP congestion control. Using a congestion control
	different from than the standard one might improve the impact on the		different from than the standard one might improve the impact on the
	parallel SRTP media streams.		parallel SRTP media streams.
			SCTP uses the same port number concept as TCP and UDP do. Therefore
			an SCTP association uses two port numbers, one at each SCTP end-
			point.
	6. The Usage of SCTP for Data Channels		6. The Usage of SCTP for Data Channels
	6.1. SCTP Protocol Considerations		6.1. SCTP Protocol Considerations
	The DTLS encapsulation of SCTP packets as described in		The DTLS encapsulation of SCTP packets as described in
	[I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used.		[I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used.
	This SCTP stack and its upper layer MUST support the usage of		This SCTP stack and its upper layer MUST support the usage of
	multiple SCTP streams. A user message can be sent ordered or		multiple SCTP streams. A user message can be sent ordered or
	unordered and with partial or full reliability.		unordered and with partial or full reliability.
	skipping to change at page 9, line 8		skipping to change at page 9, line 10
	supported. In addition to the timed reliability PR-SCTP policy		supported. In addition to the timed reliability PR-SCTP policy
	defined in [RFC3758], the limited retransmission policy defined in		defined in [RFC3758], the limited retransmission policy defined in
	[I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. Limiting the		[I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. Limiting the
	number of retransmissions to zero combined with unordered delivery		number of retransmissions to zero combined with unordered delivery
	provides a UDP-like service where each user message is sent		provides a UDP-like service where each user message is sent
	exactly once and delivered in the order received.		exactly once and delivered in the order received.
	The support for message interleaving as defined in		The support for message interleaving as defined in
	[I-D.ietf-tsvwg-sctp-ndata] SHOULD be used.		[I-D.ietf-tsvwg-sctp-ndata] SHOULD be used.
	6.2. Association Setup		6.2. SCTP Association Management
	In the WebRTC context, the SCTP association will be set up when the		In the WebRTC context, the SCTP association will be set up when the
	two endpoints of the WebRTC PeerConnection agree on opening it, as		two endpoints of the WebRTC PeerConnection agree on opening it, as
	negotiated by JSEP (typically an exchange of SDP)		negotiated by JSEP (typically an exchange of SDP)
	[I-D.ietf-rtcweb-jsep]. It will use the DTLS connection selected via		[I-D.ietf-rtcweb-jsep]. It will use the DTLS connection selected via
	ICE; typically this will be shared via BUNDLE or equivalent with DTLS		ICE; typically this will be shared via BUNDLE or equivalent with DTLS
	connections used to key the SRTP media streams.		connections used to key the SRTP media streams.
	The number of streams negotiated during SCTP association setup SHOULD		The number of streams negotiated during SCTP association setup SHOULD
	be 65535, which is the maximum number of streams that can be		be 65535, which is the maximum number of streams that can be
	negotiated during the association setup.		negotiated during the association setup.
			SCTP supports two ways of terminating an SCTP association. A
			graceful one, using a procedure which ensures that no messages are
			lost during the shutdown of the association. The second method is a
			non-graceful one, where one side can just abort the association.
			Each SCTP end-point supervises continuously the reachability of its
			peer by monitoring the number of retransmissions of user messages and
			test messages. In case of excessive retransmissions, the association
			is terminated in a non-graceful way.
			If an SCTP association is closed in a graceful way, all of its data
			channels are closed. In case of a non-graceful teardown, all data
			channels are also closed, but an error indication SHOULD be provided
			if possible.
	6.3. SCTP Streams		6.3. SCTP Streams
	SCTP defines a stream as a unidirectional logical channel existing		SCTP defines a stream as a unidirectional logical channel existing
	within an SCTP association to another SCTP endpoint. The streams are		within an SCTP association to another SCTP endpoint. The streams are
	used to provide the notion of in-sequence delivery and for		used to provide the notion of in-sequence delivery and for
	multiplexing. Each user message is sent on a particular stream,		multiplexing. Each user message is sent on a particular stream,
	either ordered or unordered. Ordering is preserved only for ordered		either ordered or unordered. Ordering is preserved only for ordered
	messages sent on the same stream.		messages sent on the same stream.
	6.4. WebRTC Data Channel Definition		6.4. Data Channel Definition
	The WebRTC Data Channels are bidirectional. They also consider the		One strong wish is for the application-level API to be close to the
	notions of in-sequence, out-of-sequence, reliable and unreliable as		API for WebSockets, which implies bidirectional streams of data and a
	properties of channels. One strong wish is for the application-level		textual field called 'label' used to identify the meaning of the data
	API to be close to the API for WebSockets, which implies		channel.
	bidirectional streams of data and waiting for onopen to fire before
	sending, a textual label used to identify the meaning of the streams.
	The realization of a bidirectional data channel is a pair of one		The realization of a data channel is a pair of one incoming stream
	incoming stream and one outgoing SCTP stream having the same stream		and one outgoing SCTP stream having the same SCTP stream identifier.
	SCTP identifier.		How these SCTP stream identifiers are selected is protocol and
			implementation dependent. This allows a bidirectional communication.
	How stream values are selected is protocol and implementation		Additionally, each data channel has the following properties in each
	dependent.		direction:
	Each data channel also has a priority, which is an 2 byte unsigned		o reliable or unreliable message transmission. In case of
	integer value. These priorities MUST be interpreted as weighted-		unreliable transmissions, the same level of unreliability is used.
	fair-queuing scheduling priorities per the definition of the		Please note that in SCTP this is a property of an SCTP user
	corresponding stream scheduler supporting interleaving in		message and not of an SCTP stream.
	[I-D.ietf-tsvwg-sctp-ndata]. For use in WebRTC, the values used
	SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high")
	or 1024 ("extra high").
	6.5. Opening a Channel		o in-order or out-of-order message delivery for message sent.
			Please note that in SCTP this is a property of an SCTP user
			message and not of an SCTP stream.
			o A priority, which is a 2 byte unsigned integer. These priorities
			MUST be interpreted as weighted-fair-queuing scheduling priorities
			per the definition of the corresponding stream scheduler
			supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata]. For use
			in WebRTC, the values used SHOULD be one of 128 ("below normal"),
			256 ("normal"), 512 ("high") or 1024 ("extra high").
			o an optional label.
			o an optional protocol.
			Please note that for a data channel being negotiated with the
			protocol specified in [I-D.ietf-rtcweb-data-protocol] all of the
			above properties are the same in both directions.
			6.5. Opening a Data Channel
	Data channels can be opened by using negotiation within the SCTP		Data channels can be opened by using negotiation within the SCTP
	association, called in-band negotiation, or out-of-band negotiation.		association, called in-band negotiation, or out-of-band negotiation.
	Out-of-band negotiation is defined as any method which results in an		Out-of-band negotiation is defined as any method which results in an
	agreement as to the parameters of a channel and the creation thereof.		agreement as to the parameters of a channel and the creation thereof.
	The details are out of scope of this document.		The details are out of scope of this document. Applications using
			data channels need to use the negotiation methods consistently on
			both end-points.
	A simple protocol for in-band negotiation is specified in		A simple protocol for in-band negotiation is specified in
	[I-D.ietf-rtcweb-data-protocol].		[I-D.ietf-rtcweb-data-protocol].
	When one side wants to open a channel using out-of-band negotiation,		When one side wants to open a channel using out-of-band negotiation,
	it picks a stream. Unless otherwise defined or negotiated, the		it picks a stream. Unless otherwise defined or negotiated, the
	streams are picked based on the DTLS role (the client picks even		streams are picked based on the DTLS role (the client picks even
	stream identifiers, the server odd stream identifiers). However, the		stream identifiers, the server odd stream identifiers). However, the
	application is responsible for avoiding collisions with existing		application is responsible for avoiding collisions with existing
	streams. If it attempts to re-use a stream which is part of an		streams. If it attempts to re-use a stream which is part of an
	existing data channel, the addition SHOULD fail. In addition to		existing data channel, the addition SHOULD fail. In addition to
	choosing a stream, the application SHOULD also determine the options		choosing a stream, the application SHOULD also determine the options
	to use for sending messages. The application MUST ensure in an		to use for sending messages. The application MUST ensure in an
	application-specific manner that the application at the peer will		application-specific manner that the application at the peer will
	also know the selected stream to be used, and the options for sending		also know the selected stream to be used, and the options for sending
	data from that side.		data from that side.
	6.6. Transferring User Data on a Channel		6.6. Transferring User Data on a Data Channel
	All data sent on a data channel in both directions MUST be sent over		All data sent on a data channel in both directions MUST be sent over
	the underlying stream using the reliability defined when the data		the underlying stream using the reliability defined when the data
	channel was opened unless the options are changed, or per-message		channel was opened unless the options are changed, or per-message
	options are specified by a higher level.		options are specified by a higher level.
	No more than one message should be put into an SCTP user message.		No more than one message should be put into an SCTP user message.
	The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the		The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the
	interpretation of the "Payload data". For identifying a JavaScript		interpretation of the "Payload data". The following PPIDs MUST be
	string encoded in UTF-8 the PPID "WebRTC String" MUST be used, for		used (see Section 8):
	JavaScript binary data (ArrayBuffer or Blob) the PPID "WebRTC Binary"
	MUST be used (see Section 8).		WebRTC String: to identify a non-empty JavaScript string encoded in
			UTF-8.
			WebRTC String Empty: to identify an empty JavaScript string encoded
			in UTF-8.
			WebRTC Binary: to identify a non-empty JavaScript binary data
			(ArrayBuffer, ArrayBufferView or Blob).
			WebRTC Binary Empty: to identify an empty JavaScript binary data
			(ArrayBuffer, ArrayBufferView or Blob).
			SCTP does not support the sending of empty user messages. Therefore,
			if an empty message has to be sent, the appropriate PPID (WebRTC
			String Empty or WebRTC Binary Empty) is used and the SCTP user
			message of one zero byte is sent. When receiving an SCTP user
			message with one of these PPIDs, the receiver MUST ignore the SCTP
			user message and process it as an empty message.
	The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary		The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary
	Partial" is deprecated. They were used for a PPID-based		Partial" is deprecated. They were used for a PPID-based
	fragmentation and reassembly of user messages belonging to reliable		fragmentation and reassembly of user messages belonging to reliable
	and ordered data channels.		and ordered data channels.
	If a message with an unsupported PPID is received or some error is		If a message with an unsupported PPID is received or some error
	detected by the receiver (for example, illegal ordering), the		condition related to the received message is detected by the receiver
	receiver SHOULD close the corresponding data channel.		(for example, illegal ordering), the receiver SHOULD close the
			corresponding data channel. This implies in particular that
			extensions using additional PPIDs can't be used without prior
			negotiation.
	The SCTP base protocol specified in [RFC4960] does not support the		The SCTP base protocol specified in [RFC4960] does not support the
	interleaving of user messages. Therefore sending a large user		interleaving of user messages. Therefore sending a large user
	message can monopolize the SCTP association. To overcome this		message can monopolize the SCTP association. To overcome this
	limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to		limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to
	support message interleaving, which SHOULD be used. As long as		support message interleaving, which SHOULD be used. As long as
	message interleaving is not supported, the sender SHOULD limit the		message interleaving is not supported, the sender SHOULD limit the
	maximum message size to 16 KB to avoid monopolization.		maximum message size to 16 KB to avoid monopolization.
	It is recommended that the message size be kept within certain size		It is recommended that the message size be kept within certain size
	bounds as applications will not be able to support arbitrarily-large		bounds as applications will not be able to support arbitrarily-large
	single messages. This limit has to be negotiated, for example by		single messages. This limit has to be negotiated, for example by
	using [I-D.ietf-mmusic-sctp-sdp].		using [I-D.ietf-mmusic-sctp-sdp].
	The sender SHOULD disable the Nagle algorithm to minimize the		The sender SHOULD disable the Nagle algorithm (see [RFC1122]) to
	latency.		minimize the latency.
	6.7. Closing a Channel		6.7. Closing a Data Channel
	Closing of a data channel MUST be signaled by resetting the		Closing of a data channel MUST be signaled by resetting the
	corresponding outgoing streams [RFC6525]. This means that if one		corresponding outgoing streams [RFC6525]. This means that if one
	side decides to close the data channel, it resets the corresponding		side decides to close the data channel, it resets the corresponding
	outgoing stream. When the peer sees that an incoming stream was		outgoing stream. When the peer sees that an incoming stream was
	reset, it also resets its corresponding outgoing stream. Once this		reset, it also resets its corresponding outgoing stream. Once this
	is completed, the data channel is closed. Resetting a stream sets		is completed, the data channel is closed. Resetting a stream sets
	the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with		the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with
	a corresponding notification to the application layer that the reset		a corresponding notification to the application layer that the reset
	has been performed. Streams are available for reuse after a reset		has been performed. Streams are available for reuse after a reset
	skipping to change at page 12, line 7		skipping to change at page 13, line 17
	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.
	]		]
	This document uses four already registered SCTP Payload Protocol		This document uses six already registered SCTP Payload Protocol
	Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary		Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary
	Data Last", and "DOMString Partial". [RFC4960] creates the registry		Data Last", "DOMString Partial", "WebRTC String Empty", and "WebRTC
	"SCTP Payload Protocol Identifiers" from which these identifiers were		Binary Empty". [RFC4960] creates the registry "SCTP Payload Protocol
	assigned. IANA is requested to update the reference of these four		Identifiers" from which these identifiers were assigned. IANA is
	assignments to point to this document and change the names of the		requested to update the reference of these six assignments to point
	PPIDs. Therefore these four assignments should be updated to read:		to this document and change the names of the first four PPIDs. The
			corresponding dates should be kept.
	+------------------------------------+-----------+-----------+		Therefore these six assignments should be updated to read:
	| Value | SCTP PPID | Reference |
	+------------------------------------+-----------+-----------+		+-------------------------------+----------+-----------+------------+
	| WebRTC String | 51 | [RFCXXXX] |		| Value | SCTP | Reference | Date |
	| WebRTC Binary Partial (Deprecated) | 52 | [RFCXXXX] |		| | PPID | | |
	| WebRTC Binary | 53 | [RFCXXXX] |		+-------------------------------+----------+-----------+------------+
	| WebRTC String Partial (Deprecated) | 54 | [RFCXXXX] |		| WebRTC String | 51 | [RFCXXXX] | 2013-09-20 |
	+------------------------------------+-----------+-----------+		| WebRTC Binary Partial | 52 | [RFCXXXX] | 2013-09-20 |
			| (Deprecated) | | | |
			| WebRTC Binary | 53 | [RFCXXXX] | 2013-09-20 |
			| WebRTC String Partial | 54 | [RFCXXXX] | 2013-09-20 |
			| (Deprecated) | | | |
			| WebRTC String Empty | 56 | [RFCXXXX] | 2014-08-22 |
			| WebRTC Binary Empty | 57 | [RFCXXXX] | 2014-08-22 |
			+-------------------------------+----------+-----------+------------+
	9. Acknowledgments		9. Acknowledgments
	Many thanks for comments, ideas, and text from Harald Alvestrand,		Many thanks for comments, ideas, and text from Harald Alvestrand,
	Adam Bergkvist, Christer Holmberg, Cullen Jennings, Paul Kyzivat,		Richard Barnes, Adam Bergkvist, Gunnar Hellstrom, Christer Holmberg,
	Eric Rescorla, Irene Ruengeler, Randall Stewart, Justin Uberti, and		Cullen Jennings, Paul Kyzivat, Eric Rescorla, Irene Ruengeler,
	Magnus Westerlund.		Randall Stewart, Justin Uberti, and Magnus Westerlund.
	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.
	[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.		[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
	Conrad, "Stream Control Transmission Protocol (SCTP)		Conrad, "Stream Control Transmission Protocol (SCTP)
	skipping to change at page 13, line 23		skipping to change at page 14, line 44
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245, April		Traversal for Offer/Answer Protocols", RFC 5245, April
	2010.		2010.
	[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-ndata]		[I-D.ietf-tsvwg-sctp-ndata]
	Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A		Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
	New Data Chunk for Stream Control Transmission Protocol",		"Stream Schedulers and a New Data Chunk for the Stream
	draft-ietf-tsvwg-sctp-ndata-00 (work in progress),		Control Transmission Protocol", draft-ietf-tsvwg-sctp-
	February 2014.		ndata-01 (work in progress), July 2014.
	[I-D.ietf-rtcweb-data-protocol]		[I-D.ietf-rtcweb-data-protocol]
	Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel		Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
	Establishment Protocol", draft-ietf-rtcweb-data-		Establishment Protocol", draft-ietf-rtcweb-data-
	protocol-06 (work in progress), June 2014.		protocol-07 (work in progress), July 2014.
	[I-D.ietf-tsvwg-sctp-dtls-encaps]		[I-D.ietf-tsvwg-sctp-dtls-encaps]
	Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS		Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
	Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-		Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
	dtls-encaps-04 (work in progress), May 2014.		dtls-encaps-05 (work in progress), July 2014.
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for WebRTC", draft-		Rescorla, E., "Security Considerations for WebRTC", draft-
	ietf-rtcweb-security-06 (work in progress), January 2014.		ietf-rtcweb-security-07 (work in progress), July 2014.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-09 (work in progress), February 2014.		rtcweb-security-arch-10 (work in progress), July 2014.
	[I-D.ietf-rtcweb-jsep]		[I-D.ietf-rtcweb-jsep]
	Uberti, J. and C. Jennings, "Javascript Session		Uberti, J., Jennings, C., and E. Rescorla, "Javascript
	Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work		Session Establishment Protocol", draft-ietf-rtcweb-jsep-07
	in progress), February 2014.		(work in progress), July 2014.
	[I-D.ietf-tsvwg-sctp-prpolicies]		[I-D.ietf-tsvwg-sctp-prpolicies]
	Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,		Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
	"Additional Policies for the Partial Reliability Extension		"Additional Policies for the Partial Reliability Extension
	of the Stream Control Transmission Protocol", draft-ietf-		of the Stream Control Transmission Protocol", draft-ietf-
	tsvwg-sctp-prpolicies-03 (work in progress), May 2014.		tsvwg-sctp-prpolicies-03 (work in progress), May 2014.
	[I-D.ietf-mmusic-sctp-sdp]		[I-D.ietf-mmusic-sctp-sdp]
	Loreto, S. and G. Camarillo, "Stream Control Transmission		Loreto, S. and G. Camarillo, "Stream Control Transmission
	Protocol (SCTP)-Based Media Transport in the Session		Protocol (SCTP)-Based Media Transport in the Session
	Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-06		Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-07
	(work in progress), February 2014.		(work in progress), July 2014.
	10.2. Informative References		10.2. Informative References
			[RFC1122] Braden, R., "Requirements for Internet Hosts -
			Communication Layers", STD 3, RFC 1122, October 1989.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.		Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
	[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram		[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
	Transport Layer Security (DTLS) for Stream Control		Transport Layer Security (DTLS) for Stream Control
	Transmission Protocol (SCTP)", RFC 6083, January 2011.		Transmission Protocol (SCTP)", RFC 6083, January 2011.
	[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream		[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
	Control Transmission Protocol (SCTP) Packets for End-Host		Control Transmission Protocol (SCTP) Packets for End-Host
End of changes. 35 change blocks.
	81 lines changed or deleted		148 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/