rfc8866v5.txt		rfc8866.txt
	skipping to change at line 118 ¶		skipping to change at line 118 ¶
	6.13. framerate (Frame Rate)		6.13. framerate (Frame Rate)
	6.14. quality		6.14. quality
	6.15. fmtp (Format Parameters)		6.15. fmtp (Format Parameters)
	7. Security Considerations		7. Security Considerations
	8. IANA Considerations		8. IANA Considerations
	8.1. The "application/sdp" Media Type		8.1. The "application/sdp" Media Type
	8.2. Registration of SDP Parameters with IANA		8.2. Registration of SDP Parameters with IANA
	8.2.1. Registration Procedure		8.2.1. Registration Procedure
	8.2.2. Media Types ("media")		8.2.2. Media Types ("media")
	8.2.3. Transport Protocols (<proto>)		8.2.3. Transport Protocols (<proto>)
	8.2.4. Attribute Names ("att-field")		8.2.4. Attribute Names (<attribute-name>)
	8.2.5. Bandwidth Specifiers (<bwtype>)		8.2.5. Bandwidth Specifiers (<bwtype>)
	8.2.6. Network Types (<nettype>)		8.2.6. Network Types (<nettype>)
	8.2.7. Address Types (<addrtype>)		8.2.7. Address Types (<addrtype>)
	8.3. Encryption Key Access Methods (OBSOLETE)		8.3. Encryption Key Access Methods (OBSOLETE)
	9. SDP Grammar		9. SDP Grammar
	10. Summary of Changes from RFC 4566		10. Summary of Changes from RFC 4566
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	11.2. Informative References		11.2. Informative References
	Acknowledgements		Acknowledgements
	skipping to change at line 967 ¶		skipping to change at line 967 ¶
	k=<method>		k=<method>
	k=<method>:<encryption key>		k=<method>:<encryption key>
	The "k=" line (key-field) is obsolete and MUST NOT be used. It is		The "k=" line (key-field) is obsolete and MUST NOT be used. It is
	included in this document for legacy reasons. One MUST NOT include a		included in this document for legacy reasons. One MUST NOT include a
	"k=" line in an SDP, and MUST discard it if it is received in an SDP.		"k=" line in an SDP, and MUST discard it if it is received in an SDP.
	5.13. Attributes ("a=")		5.13. Attributes ("a=")
	a=<attribute>		a=<attribute-name>
	a=<attribute>:<value>		a=<attribute-name>:<attribute-value>
	Attributes are the primary means for extending SDP. Attributes may		Attributes are the primary means for extending SDP. Attributes may
	be defined to be used as session-level attributes, media-level		be defined to be used as session-level attributes, media-level
	attributes, or both. (Attribute scopes in addition to media-level		attributes, or both. (Attribute scopes in addition to media-level
	and session-level scopes may also be defined in extensions to this		and session-level scopes may also be defined in extensions to this
	document, e.g., [RFC5576] and [RFC8864].)		document, e.g., [RFC5576] and [RFC8864].)
	A media description may contain any number of "a=" lines (attribute-		A media description may contain any number of "a=" lines (attribute-
	fields) that are media description specific. These are referred to		fields) that are media description specific. These are referred to
	as media-level attributes and add information about the media		as media-level attributes and add information about the media
	description. Attribute-fields can also be added before the first		description. Attribute-fields can also be added before the first
	media description; these session-level attributes convey additional		media description; these session-level attributes convey additional
	information that applies to the session as a whole rather than to		information that applies to the session as a whole rather than to
	individual media descriptions.		individual media descriptions.
	Attribute-fields may be of two forms:		Attribute-fields may be of two forms:
	* A property attribute is simply of the form "a=<attribute>". These		* A property attribute is simply of the form "a=<attribute-name>".
	are binary attributes, and the presence of the attribute conveys		These are binary attributes, and the presence of the attribute
	that the attribute is a property of the session. An example might		conveys that the attribute is a property of the session. An
	be "a=recvonly".		example might be "a=recvonly".
	* A value attribute is of the form "a=<attribute>:<value>". For		* A value attribute is of the form "a=<attribute-name>:<attribute-
	example, a whiteboard could have the value attribute		value>". For example, a whiteboard could have the value attribute
	"a=orient:landscape".		"a=orient:landscape".
	Attribute interpretation depends on the media tool being invoked.		Attribute interpretation depends on the media tool being invoked.
	Thus receivers of session descriptions should be configurable in		Thus receivers of session descriptions should be configurable in
	their interpretation of session descriptions in general and of		their interpretation of session descriptions in general and of
	attributes in particular.		attributes in particular.
	Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.		Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.
	Attribute values are octet strings, and MAY use any octet value		Attribute values are octet strings, and MAY use any octet value
	skipping to change at line 1930 ¶		skipping to change at line 1930 ¶
	Author/Change controller:		Author/Change controller:
	Authors of RFC 8866		Authors of RFC 8866
	IETF MMUSIC working group delegated from the IESG		IETF MMUSIC working group delegated from the IESG
	8.2. Registration of SDP Parameters with IANA		8.2. Registration of SDP Parameters with IANA
	This document specifies IANA parameter registries for six named SDP		This document specifies IANA parameter registries for six named SDP
	subfields. Using the terminology in the SDP specification Augmented		subfields. Using the terminology in the SDP specification Augmented
	Backus-Naur Form (ABNF), they are "media", <proto>, "att-field",		Backus-Naur Form (ABNF), they are "media", <proto>, <attribute-name>,
	<bwtype>, <nettype>, and <addrtype>.		<bwtype>, <nettype>, and <addrtype>.
	This document also replaces and updates the definitions of all those		This document also replaces and updates the definitions of all those
	parameters previously defined by [RFC4566].		parameters previously defined by [RFC4566].
	IANA: Please change all references to RFC4566 in these registries to		IANA: Please change all references to RFC4566 in these registries to
	instead refer to this document.		instead refer to this document.
	The contact name and email address for all parameters registered in		The contact name and email address for all parameters registered in
	this document is:		this document is:
	skipping to change at line 1956 ¶		skipping to change at line 1956 ¶
	+======+==========+================+===========+		+======+==========+================+===========+
	| Type | SDP Name | [other fields] | Reference |		| Type | SDP Name | [other fields] | Reference |
	+======+==========+================+===========+		+======+==========+================+===========+
	Table 3: Common format for SDP registries		Table 3: Common format for SDP registries
	8.2.1. Registration Procedure		8.2.1. Registration Procedure
	A specification document that defines values for SDP "media",		A specification document that defines values for SDP "media",
	<proto>, "att-field", <bwtype>, <nettype>, and <addrtype> parameters		<proto>, <attribute-name>, <bwtype>, <nettype>, and <addrtype>
	MUST include the following information:		parameters MUST include the following information:
	* Contact name		* Contact name
	* Contact email address		* Contact email address
	* Name being defined (as it will appear in SDP)		* Name being defined (as it will appear in SDP)
	* Type of name ("media", <proto>, <bwtype>, <nettype>, or		* Type of name ("media", <proto>, <bwtype>, <nettype>, or
	<addrtype>)		<addrtype>)
	skipping to change at line 2059 ¶		skipping to change at line 2059 ¶
	that a new one be registered through the IETF process [RFC6838] by		that a new one be registered through the IETF process [RFC6838] by
	production of, or reference to, a Standards Track RFC that defines		production of, or reference to, a Standards Track RFC that defines
	the format.		the format.
	For other protocols, formats MAY be registered according to the rules		For other protocols, formats MAY be registered according to the rules
	of the associated <proto> specification.		of the associated <proto> specification.
	Registrations of new formats MUST specify which transport protocols		Registrations of new formats MUST specify which transport protocols
	they apply to.		they apply to.
	8.2.4. Attribute Names ("att-field")		8.2.4. Attribute Names (<attribute-name>)
	Attribute-field names ("att-field") MUST be registered with IANA and		Attribute-field names (<attribute-name>) MUST be registered with IANA
	documented to avoid any issues due to conflicting attribute		and documented to avoid any issues due to conflicting attribute
	definitions under the same name. (While unknown attributes in SDP		definitions under the same name. (While unknown attributes in SDP
	are simply ignored, conflicting ones that fragment the protocol are a		are simply ignored, conflicting ones that fragment the protocol are a
	serious problem.)		serious problem.)
	The format of the attribute registry is:		The format of the attribute registry is:
	+======+==========+=============+==============+===========+		+======+==========+=============+==============+===========+
	| Type | SDP Name | Usage Level | Mux Category | Reference |		| Type | SDP Name | Usage Level | Mux Category | Reference |
	+======+==========+=============+==============+===========+		+======+==========+=============+==============+===========+
	skipping to change at line 2091 ¶		skipping to change at line 2091 ¶
	+===========+=======+=============+===========+=====================+		+===========+=======+=============+===========+=====================+
	| attribute | setup | session, | TRANSPORT | [RFC4145] [RFC8859] |		| attribute | setup | session, | TRANSPORT | [RFC4145] [RFC8859] |
	| | | media, | | [MSRP-DATACHANNEL] |		| | | media, | | [MSRP-DATACHANNEL] |
	| | | dcsa | | |		| | | dcsa | | |
	| | | (msrp) | | |		| | | (msrp) | | |
	+-----------+-------+-------------+-----------+---------------------+		+-----------+-------+-------------+-----------+---------------------+
	Table 5: Attribute registry example		Table 5: Attribute registry example
	This one registry combines all of the previous usage-level-specific		This one registry combines all of the previous usage-level-specific
	"att-field" registries, including updates made by [RFC8859]. IANA is		<attribute-name> registries, including updates made by [RFC8859].
	requested to do the necessary reformatting.		IANA is requested to do the necessary reformatting.
	Section 6 of this document replaces the initial set of attribute		Section 6 of this document replaces the initial set of attribute
	definitions made by [RFC4566]. IANA is requested to update the		definitions made by [RFC4566]. IANA is requested to update the
	registry accordingly.		registry accordingly.
	Documents can define new attributes and can also extend the		Documents can define new attributes and can also extend the
	definitions of previously defined attributes.		definitions of previously defined attributes.
	8.2.4.1. New Attributes		8.2.4.1. New Attributes
	New attribute registrations are accepted according to the		New attribute registrations are accepted according to the
	"Specification Required" policy of [RFC8126], provided that the		"Specification Required" policy of [RFC8126], provided that the
	specification includes the following information:		specification includes the following information:
	* Contact name		* Contact name
	* Contact email address		* Contact email address
	* Attribute name: the name of the attribute that will appear in SDP.		* Attribute name: the name of the attribute that will appear in SDP.
	This MUST conform to the definition of "att-field".		This MUST conform to the definition of <attribute-name>.
	* Attribute syntax: for a value attribute (see Section 5.13), an		* Attribute syntax: for a value attribute (see Section 5.13), an
	ABNF definition of the attribute value <att-value> syntax (see		ABNF definition of the attribute value <attribute-value> syntax
	Section 9) MUST be provided. The syntax MUST follow the rule form		(see Section 9) MUST be provided. The syntax MUST follow the rule
	per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define the		form per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL
	allowable values that the attribute might take. It MAY also		define the allowable values that the attribute might take. It MAY
	define an extension method for the addition of future values. For		also define an extension method for the addition of future values.
	a property attribute, the ABNF definition is omitted as the		For a property attribute, the ABNF definition is omitted as the
	property attribute takes no values.		property attribute takes no values.
	* Attribute semantics: for a value attribute, a semantic description		* Attribute semantics: for a value attribute, a semantic description
	of the values that the attribute might take MUST be provided. The		of the values that the attribute might take MUST be provided. The
	usage of a property attribute is described under Purpose below.		usage of a property attribute is described under Purpose below.
	* Attribute value: the name of an ABNF syntax rule defining the		* Attribute value: the name of an ABNF syntax rule defining the
	syntax of the value. Absence of a rule name indicates that the		syntax of the value. Absence of a rule name indicates that the
	attribute takes no values. Enclosing the rule name in "[" and "]"		attribute takes no values. Enclosing the rule name in "[" and "]"
	indicates that a value is optional.		indicates that a value is optional.
	skipping to change at line 2173 ¶		skipping to change at line 2173 ¶
	attribute usage level. They should not choose only "session" when		attribute usage level. They should not choose only "session" when
	the attribute can have different values when media is disaggregated,		the attribute can have different values when media is disaggregated,
	i.e., when each "m=" section has its own IP address on a different		i.e., when each "m=" section has its own IP address on a different
	endpoint. In that case, the attribute type chosen should be		endpoint. In that case, the attribute type chosen should be
	"session, media" or "media" (depending on desired semantics). The		"session, media" or "media" (depending on desired semantics). The
	default rule is that for all new SDP attributes that can occur both		default rule is that for all new SDP attributes that can occur both
	in session and media level, the media level overrides the session		in session and media level, the media level overrides the session
	level. When this is not the case for a new SDP attribute, it MUST be		level. When this is not the case for a new SDP attribute, it MUST be
	explicitly stated.		explicitly stated.
	IANA has registered the initial set of attribute names ("att-field"		IANA has registered the initial set of attribute names (<attribute-
	values) with definitions as in Section 6 of this memo (these		name> values) with definitions as in Section 6 of this memo (these
	definitions replace those in [RFC4566]).		definitions replace those in [RFC4566]).
	8.2.4.2. Updates to Existing Attributes		8.2.4.2. Updates to Existing Attributes
	Updated attribute registrations are accepted according to the		Updated attribute registrations are accepted according to the
	"Specification Required" policy of [RFC8126].		"Specification Required" policy of [RFC8126].
	The Designated Expert reviewing the update is requested to evaluate		The Designated Expert reviewing the update is requested to evaluate
	whether the update is compatible with the prior intent and use of the		whether the update is compatible with the prior intent and use of the
	attribute, and whether the new document is of sufficient maturity and		attribute, and whether the new document is of sufficient maturity and
	skipping to change at line 2467 ¶		skipping to change at line 2467 ¶
	%s"base64:" base64 /		%s"base64:" base64 /
	%s"uri:" uri		%s"uri:" uri
	; NOTE: These names are case-sensitive.		; NOTE: These names are case-sensitive.
	base64 = *base64-unit [base64-pad]		base64 = *base64-unit [base64-pad]
	base64-unit = 4base64-char		base64-unit = 4base64-char
	base64-pad = 2base64-char "==" / 3base64-char "="		base64-pad = 2base64-char "==" / 3base64-char "="
	base64-char = ALPHA / DIGIT / "+" / "/"		base64-char = ALPHA / DIGIT / "+" / "/"
	; sub-rules of 'a='		; sub-rules of 'a='
	attribute = (att-field ":" att-value) / att-field		attribute = (attribute-name ":" attribute-value) / attribute-name
	att-field = token		attribute-name = token
	att-value = byte-string		attribute-value = byte-string
	; sub-rules of 'm='		; sub-rules of 'm='
	media = token		media = token
	;typically "audio", "video", "text", "image"		;typically "audio", "video", "text", "image"
	;or "application"		;or "application"
	fmt = token		fmt = token
	;typically an RTP payload type for audio		;typically an RTP payload type for audio
	;and video media		;and video media
	skipping to change at line 2628 ¶		skipping to change at line 2628 ¶
	* Changed the mechanism and documentation required for registering		* Changed the mechanism and documentation required for registering
	new attributes (Section 8.2.4.1).		new attributes (Section 8.2.4.1).
	* Tightened up IANA registration procedures for extensions. Removed		* Tightened up IANA registration procedures for extensions. Removed
	phone number and long-form name (Section 8.2).		phone number and long-form name (Section 8.2).
	* Expanded the IANA <nettype> registry to identify valid <addrtype>		* Expanded the IANA <nettype> registry to identify valid <addrtype>
	subfields (Section 8.2.6).		subfields (Section 8.2.6).
	* Reorganized the several IANA att-field registries into a single		* Reorganized the several IANA <attribute-name> registries into a
	registry (Section 8.2.4).		single registry (Section 8.2.4).
	* Revised ABNF syntax (Section 9) for clarity. Backward		* Revised ABNF syntax (Section 9) for clarity. Backward
	compatibility is maintained with a few exceptions:		compatibility is maintained with a few exceptions:
	- Revised the syntax of time descriptions ("t=", "r=", "z=") to		- Revised the syntax of time descriptions ("t=", "r=", "z=") to
	remove ambiguities. Clarified that "z=" only modifies the		remove ambiguities. Clarified that "z=" only modifies the
	immediately preceding "r=" lines. Made "z=" without a		immediately preceding "r=" lines. Made "z=" without a
	preceding "r=" a syntax error (Section 5.11). (This is		preceding "r=" a syntax error (Section 5.11). (This is
	incompatible with certain aberrant usage.)		incompatible with certain aberrant usage.)
End of changes. 16 change blocks.
	31 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/