draft-ietf-rtcweb-data-channel-03.txt		draft-ietf-rtcweb-data-channel-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 28, 2013 Ericsson		Expires: August 29, 2013 Ericsson
	M. Tuexen		M. Tuexen
	Muenster Univ. of Appl. Sciences		Muenster Univ. of Appl. Sciences
	February 24, 2013		February 25, 2013
	RTCWeb Data Channels		RTCWeb Data Channels
	draft-ietf-rtcweb-data-channel-03.txt		draft-ietf-rtcweb-data-channel-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 protocol support for direct interactive rich communication		provide protocol support for direct interactive rich communication
	using audio, video, and data between two peers' web-browsers. This		using audio, video, and data between two peers' web-browsers. This
	document specifies the non-media data transport aspects of the WebRTC		document specifies the non-media data transport aspects of the WebRTC
	framework. It provides an architectural overview of how the Stream		framework. It provides an architectural overview of how the Stream
	Control Transmission Protocol (SCTP) is used in the WebRTC context as		Control Transmission Protocol (SCTP) is used in the WebRTC context as
	a generic transport service allowing Web Browser to exchange generic		a generic transport service allowing Web Browser to exchange generic
	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 August 28, 2013.		This Internet-Draft will expire on August 29, 2013.
	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 5, line 29		skipping to change at page 5, line 29
	with the congestion control algorithms.		with the congestion control algorithms.
	Req. 5 Data channels MUST be secured; allowing for confidentiality,		Req. 5 Data channels MUST be secured; allowing for confidentiality,
	integrity and source authentication. See		integrity and source authentication. See
	[I-D.ietf-rtcweb-security] and		[I-D.ietf-rtcweb-security] and
	[I-D.ietf-rtcweb-security-arch] for detailed info.		[I-D.ietf-rtcweb-security-arch] for detailed info.
	Req. 6 Data channels MUST provide message fragmentation support		Req. 6 Data channels MUST provide message fragmentation support
	such that IP-layer fragmentation can be avoided no matter		such that IP-layer fragmentation can be avoided no matter
	how large a message the Javascript application passes to be		how large a message the Javascript application passes to be
	sent.		sent. It also MUST ensure that large data channel transfers
			don't unduely delay traffic on other data channels.
	Req. 7 The data channel transport protocol MUST NOT encode local IP		Req. 7 The data channel transport protocol MUST NOT encode local IP
	addresses inside its protocol fields; doing so reveals		addresses inside its protocol fields; doing so reveals
	potentially private information, and leads to failure if the		potentially private information, and leads to failure if the
	address is depended upon.		address is depended upon.
	Req. 8 The data channel transport protocol SHOULD support		Req. 8 The data channel transport protocol SHOULD support
	unbounded-length "messages" (i.e., a virtual socket stream)		unbounded-length "messages" (i.e., a virtual socket stream)
	at the application layer, for such things as image-file-		at the application layer, for such things as image-file-
	transfer; Implementations might enforce a reasonable message		transfer; Implementations might enforce a reasonable message
	size limit.		size limit.
	Req. 9 The data channel packet format/encoding MUST be such that it		Req. 9 The data channel transport protocol SHOULD avoid IP
	is impossible for a malicious Javascript to generate an
	application message crafted such that it could be
	interpreted as a native protocol over UDP - such as UPnP,
	RTP, SNMP, STUN, etc.
	Req. 10 The data channel transport protocol SHOULD avoid IP
	fragmentation. It MUST support PMTU discovery and MUST NOT		fragmentation. It MUST support PMTU discovery and MUST NOT
	rely on ICMP or ICMPv6 being generated or being passed back,		rely on ICMP or ICMPv6 being generated or being passed back,
	especially for PMTU discovery.		especially for PMTU discovery.
	Req. 11 It MUST be possible to implement the protocol stack in the		Req. 10 It MUST be possible to implement the protocol stack in the
	user application space.		user application space.
	5. SCTP over DTLS over UDP Considerations		5. SCTP over DTLS over UDP Considerations
	The important features of SCTP in the RTCWeb context are:		The important features of SCTP in the RTCWeb context are:
	o TCP-friendly congestion control.		o TCP-friendly congestion control.
	o The congestion control is modifiable for integration with media		o The congestion control is modifiable for integration with media
	stream congestion control.		stream congestion control.
	skipping to change at page 9, line 16		skipping to change at page 9, line 14
	6. The Usage of SCTP in the RTCWeb Context		6. The Usage of SCTP in the RTCWeb Context
	6.1. Association Setup		6.1. Association Setup
	The SCTP association will be set up when the two endpoints of the		The SCTP association will be set up when the two endpoints of the
	WebRTC PeerConnection agree on opening it, as negotiated by JSEP		WebRTC PeerConnection agree on opening it, as negotiated by JSEP
	(typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally,		(typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally,
	the negotiation SHOULD include some type of congestion control		the negotiation SHOULD include some type of congestion control
	selection. It will use the DTLS connection selected via SDP;		selection. It will use the DTLS connection selected via SDP;
	typically this will be shared via BUNDLE with DTLS connections used		typically this will be shared via BUNDLE or equivalent with DTLS
	to key the DTLS-SRTP media streams.		connections used to key the DTLS-SRTP media streams.
	The application SHOULD indicate the initial number of streams		The application SHOULD indicate the initial number of streams
	required when opening the association, and if no value is supplied,		required when opening the association, and if no value is supplied,
	the implementation SHOULD provide an appropriate default. If more		the implementation SHOULD provide an appropriate default. If more
	simultaneous streams are needed, [RFC6525] allows adding additional		simultaneous streams are needed, [RFC6525] allows adding additional
	(but not removing) streams to an existing association. Note there		(but not removing) streams to an existing association. Note there
	can be up to 65536 SCTP streams per SCTP association in each		can be up to 65536 SCTP streams per SCTP association in each
	direction.		direction.
	6.2. SCTP Streams		6.2. SCTP Streams
	SCTP defines a stream as an unidirectional logical channel existing		SCTP defines a stream as an unidirectional logical channel existing
	within an SCTP association one to another SCTP endpoint. The streams		within an SCTP association one to another SCTP endpoint. The streams
	are used to provide the notion of in-sequence delivery and for		are 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 order or unordered. Ordering is preserved only for all		either order or unordered. Ordering is preserved only for ordered
	ordered messages sent on the same stream.		messages sent on the same stream.
	6.3. Channel Definition		6.3. Channel Definition
	The W3C has consensus on defining the application API for WebRTC		The W3C has consensus on defining the application API for WebRTC
	dataChannels to be bidirectional. They also consider the notions of		dataChannels to be bidirectional. They also consider the notions of
	in-sequence, out-of-sequence, reliable and un-reliable as properties		in-sequence, out-of-sequence, reliable and un-reliable as properties
	of Channels. One strong wish is for the application-level API to be		of Channels. One strong wish is for the application-level API to be
	close to the API for WebSockets, which implies bidirectional streams		close to the API for WebSockets, which implies bidirectional streams
	of data and waiting for onopen to fire before sending, a textual		of data and waiting for onopen to fire before sending, a textual
	label used to identify the meaning of the stream, among other things.		label used to identify the meaning of the stream, among other things.
	skipping to change at page 10, line 24		skipping to change at page 10, line 20
	been performed.		been performed.
	[RFC6525] also guarantees that all the messages are delivered (or		[RFC6525] also guarantees that all the messages are delivered (or
	expired) before resetting the stream.		expired) before resetting the stream.
	6.4. Usage of Payload Protocol Identifier		6.4. Usage of Payload Protocol Identifier
	The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal		The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal
	the interpretation of the "Payload data", like the protocol specified		the interpretation of the "Payload data", like the protocol specified
	in [I-D.jesup-rtcweb-data-protocol] uses them to identify a		in [I-D.jesup-rtcweb-data-protocol] uses them to identify a
	Javascript string, a Javascript array or a Javascript blob.		Javascript string, a Javascript binary data (ArrayBuffer or Blob) and
			to provide fragmentation support for large messages that may cause
			the message to monopolize the SCTP association.
	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
	This document does not require any actions by the IANA.		This document does not require any actions by the IANA.
End of changes. 10 change blocks.
	18 lines changed or deleted		15 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/