rfc8864v11.txt		rfc8864.txt
	skipping to change at line 299 ¶		skipping to change at line 299 ¶
	a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"		a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
	a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128		a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128
	a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000		a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000
	| Note: The last example (a=dcmap:4) shows a 'label' parameter		| Note: The last example (a=dcmap:4) shows a 'label' parameter
	| value that contains one nonprintable 'escaped-char' character		| value that contains one nonprintable 'escaped-char' character
	| (the tabulator character).		| (the tabulator character).
	Within an "a=dcmap:" attribute line's 'dcmap-opt' value, only one		Within an "a=dcmap:" attribute line's 'dcmap-opt' value, only one
	'maxretr-opt' parameter or one 'maxtime-opt' parameter may be		'maxretr-opt' parameter or one 'maxtime-opt' parameter may be
	present. Both MUST NOT be present.		present. Both parameters MUST NOT be present.
	5.1.2. 'dcmap-stream-id' Parameter		5.1.2. 'dcmap-stream-id' Parameter
	The 'dcmap-stream-id' parameter indicates the SCTP stream identifier		The 'dcmap-stream-id' parameter indicates the SCTP stream identifier
	within the SCTP association used to form the data channel.		within the SCTP association used to form the data channel.
	5.1.3. 'label' Parameter		5.1.3. 'label' Parameter
	The 'label' parameter indicates the name of the channel. It		The 'label' parameter indicates the name of the channel. It
	represents a label that can be used to distinguish, in the context of		represents a label that can be used to distinguish, in the context of
	skipping to change at line 328 ¶		skipping to change at line 328 ¶
	* Serialize the WebRTC label as a UTF-8 string [RFC3629].		* Serialize the WebRTC label as a UTF-8 string [RFC3629].
	* Treat the UTF-8 serialization as a series of bytes.		* Treat the UTF-8 serialization as a series of bytes.
	* For each byte in the serialization,		* For each byte in the serialization,
	- If the byte can be expressed as a 'quoted-char', do so.		- If the byte can be expressed as a 'quoted-char', do so.
	- Otherwise, express the byte as an 'escaped-char'.		- Otherwise, express the byte as an 'escaped-char'.
	| Note: The empty string MAY also be explicitly used as a 'label'		| Note: The empty string can also be explicitly used as a 'label'
	| value, such that 'label=""' is equivalent to the 'label'		| value, such that 'label=""' is equivalent to the 'label'
	| parameter not being present at all. [RFC8832] allows the		| parameter not being present at all. [RFC8832] allows the
	| DATA_CHANNEL_OPEN message's 'Label' value to be an empty		| DATA_CHANNEL_OPEN message's 'Label' value to be an empty
	| string.		| string.
	5.1.4. 'subprotocol' Parameter		5.1.4. 'subprotocol' Parameter
	The 'subprotocol' parameter indicates which protocol the client		The 'subprotocol' parameter indicates which protocol the client
	expects to exchange via the channel. This parameter maps to the		expects to exchange via the channel. This parameter maps to the
	'Protocol' parameter defined in [RFC8832]. Section 9.1 specifies how		'Protocol' parameter defined in [RFC8832]. Section 9.1 specifies how
	values for new subprotocol parameters are registered. 'subprotocol'		values for new subprotocol parameters are registered. 'subprotocol'
	is an optional parameter. If the 'subprotocol' parameter is not		is an optional parameter. If the 'subprotocol' parameter is not
	present, then its value defaults to an empty string.		present, then its value defaults to an empty string.
	| Note: The empty string MAY also be explicitly used as a		| Note: The empty string can also be explicitly used as a
	| 'subprotocol' value, such that 'subprotocol=""' is equivalent		| 'subprotocol' value, such that 'subprotocol=""' is equivalent
	| to the 'subprotocol' parameter not being present at all.		| to the 'subprotocol' parameter not being present at all.
	| [RFC8832] allows the DATA_CHANNEL_OPEN message's 'Protocol'		| [RFC8832] allows the DATA_CHANNEL_OPEN message's 'Protocol'
	| value to be an empty string.		| value to be an empty string.
	5.1.5. 'max-retr' Parameter		5.1.5. 'max-retr' Parameter
	This parameter indicates that the data channel is partially reliable.		This parameter indicates that the data channel is partially reliable.
	The 'max-retr' parameter indicates the maximal number of times a user		The 'max-retr' parameter indicates the maximal number of times a user
	message will be retransmitted. The 'max-retr' parameter is optional.		message will be retransmitted. The 'max-retr' parameter is optional.
	skipping to change at line 477 ¶		skipping to change at line 477 ¶
	dcsa-value = stream-id SP attribute		dcsa-value = stream-id SP attribute
	stream-id = 1*5DIGIT		stream-id = 1*5DIGIT
	attribute = <from RFC 8866>		attribute = <from RFC 8866>
	Example:		Example:
	a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"		a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
	a=dcsa:2 accept-types:text/plain		a=dcsa:2 accept-types:text/plain
	Note that the reference to [RFC8866] defines where the attribute		The reference to [RFC8866] defines where the attribute definition can
	definition can be found; it does not provide any limitations on		be found; it does not provide any limitations on support of
	support of attributes defined in other documents in accordance with		attributes defined in other documents in accordance with this
	this attribute definition. Note, however, that not all SDP		attribute definition. However, not all SDP attributes are suitable
	attributes are suitable as an "a=dcsa:" parameter. The registry of		as an "a=dcsa:" parameter. The registry of IANA SDP parameters
	IANA SDP parameters contains the lists of IANA-registered session-		contains the lists of IANA-registered session-level and media-level
	level and media-level or media-level-only SDP attributes.		or media-level-only SDP attributes.
	Thus, in the example above, the original attribute line		Thus, in the example above, the original attribute line
	"a=accept-types:text/plain" is represented by the attribute line		"a=accept-types:text/plain" is represented by the attribute line
	"a=dcsa:2 accept-types:text/plain", which specifies that this		"a=dcsa:2 accept-types:text/plain", which specifies that this
	instance of the MSRP subprotocol being transported on the SCTP		instance of the MSRP subprotocol being transported on the SCTP
	association using the data channel with stream id 2 accepts plaintext		association using the data channel with stream id 2 accepts plaintext
	files.		files.
	As opposed to the data channel "a=dcmap:" attribute parameters, these		As opposed to the data channel "a=dcmap:" attribute parameters, these
	parameters are subject to offer/answer negotiation, following the		parameters are subject to offer/answer negotiation, following the
	skipping to change at line 813 ¶		skipping to change at line 813 ¶
	This document specifies new SDP attributes used in the negotiation of		This document specifies new SDP attributes used in the negotiation of
	data channel parameters.		data channel parameters.
	These parameters are negotiated as part of opening an SCTP channel		These parameters are negotiated as part of opening an SCTP channel
	over DTLS as specified in [RFC8841]. Each subprotocol may come with		over DTLS as specified in [RFC8841]. Each subprotocol may come with
	its own security considerations that need to be documented as part of		its own security considerations that need to be documented as part of
	the subprotocol definition. Otherwise, this document does not add		the subprotocol definition. Otherwise, this document does not add
	any security considerations to those specified in [RFC8841].		any security considerations to those specified in [RFC8841].
	Such error cases as the use of unknown parameter values or violations		Error cases such as the use of unknown parameter values or violations
	of the odd/even rule (Section 6.1) MUST be handled by closing the		of the odd/even rule (Section 6.1) MUST be handled by closing the
	corresponding data channel.		corresponding data channel.
	9. IANA Considerations		9. IANA Considerations
	9.1. Subprotocol Identifiers		9.1. Subprotocol Identifiers
	Registration of new subprotocol identifiers is performed using the		Registration of new subprotocol identifiers is performed using the
	existing IANA "WebSocket Subprotocol Name Registry" table.		existing IANA "WebSocket Subprotocol Name Registry" table.
	skipping to change at line 1026 ¶		skipping to change at line 1026 ¶
	DOI 10.17487/RFC8873, January 2021,		DOI 10.17487/RFC8873, January 2021,
	<https://www.rfc-editor.org/info/rfc8873>.		<https://www.rfc-editor.org/info/rfc8873>.
	[T38] International Telecommunication Union, "Procedures for		[T38] International Telecommunication Union, "Procedures for
	real-time Group 3 facsimile communication over IP		real-time Group 3 facsimile communication over IP
	networks", ITU-T Recommendation T.38, November 2015,		networks", ITU-T Recommendation T.38, November 2015,
	<https://www.itu.int/rec/T-REC-T.38-201511-I/en>.		<https://www.itu.int/rec/T-REC-T.38-201511-I/en>.
	[WebRtcAPI]		[WebRtcAPI]
	Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:		Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
	Real-time Communication Between Browsers", W3C Candidate		Real-time Communication Between Browsers", W3C Proposed
	Recommendation, <https://www.w3.org/TR/webrtc/>.		Recommendation, <https://www.w3.org/TR/webrtc/>.
	Appendix A. Generic Data Channel Negotiation Aspects when Not Using		Appendix A. Generic Data Channel Negotiation Aspects when Not Using
	DCEP		DCEP
	This appendix summarizes how data channels work in general and		This appendix summarizes how data channels work in general and
	discusses some key aspects that should be considered for the out-of-		discusses some key aspects that should be considered for the out-of-
	band negotiation of data channels if DCEP is not used.		band negotiation of data channels if DCEP is not used.
	A WebRTC application creates a data channel by providing a number of		A WebRTC application creates a data channel by providing a number of
End of changes. 6 change blocks.
	12 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/