rfc8866v12.txt   rfc8866.txt 
skipping to change at line 899 skipping to change at line 899
+---+------------------------------------+ +---+------------------------------------+
| d | days (86400 seconds) | | d | days (86400 seconds) |
+---+------------------------------------+ +---+------------------------------------+
| h | hours (3600 seconds) | | h | hours (3600 seconds) |
+---+------------------------------------+ +---+------------------------------------+
| m | minutes (60 seconds) | | m | minutes (60 seconds) |
+---+------------------------------------+ +---+------------------------------------+
| s | seconds (allowed for completeness) | | s | seconds (allowed for completeness) |
+---+------------------------------------+ +---+------------------------------------+
Table 1: Time unit specification Table 1: Time Unit Specification
characters Characters
Thus, the above repeat-field could also have been written: Thus, the above repeat-field could also have been written:
r=7d 1h 0 25h r=7d 1h 0 25h
Monthly and yearly repeats cannot be directly specified with a single Monthly and yearly repeats cannot be directly specified with a single
SDP repeat time; instead, separate time-descriptions should be used SDP repeat time; instead, separate time-descriptions should be used
to explicitly list the session times. to explicitly list the session times.
5.11. Time Zone Adjustment ("z=") 5.11. Time Zone Adjustment ("z=")
skipping to change at line 1127 skipping to change at line 1127
* RTP/SAVP: denotes the Secure Real-time Transport Protocol * RTP/SAVP: denotes the Secure Real-time Transport Protocol
[RFC3711] running over UDP. [RFC3711] running over UDP.
* RTP/SAVPF: denotes SRTP with the Extended SRTP Profile for * RTP/SAVPF: denotes SRTP with the Extended SRTP Profile for
RTCP-Based Feedback [RFC5124] running over UDP. RTCP-Based Feedback [RFC5124] running over UDP.
The main reason to specify the transport protocol in addition to The main reason to specify the transport protocol in addition to
the media format is that the same standard media formats may be the media format is that the same standard media formats may be
carried over different transport protocols even when the network carried over different transport protocols even when the network
protocol is the same -- a historical example is VAT (MBone's protocol is the same -- a historical example is vat (MBone's
popular multimedia audio tool) Pulse Code Modulation (PCM) audio popular multimedia audio tool) Pulse Code Modulation (PCM) audio
and RTP PCM audio; another might be TCP/RTP PCM audio. In and RTP PCM audio; another might be TCP/RTP PCM audio. In
addition, relays and monitoring tools that are transport-protocol- addition, relays and monitoring tools that are transport-protocol-
specific but format-independent are possible. specific but format-independent are possible.
<fmt> is a media format description. The fourth and any subsequent <fmt> is a media format description. The fourth and any subsequent
subfields describe the format of the media. The interpretation of subfields describe the format of the media. The interpretation of
the media format depends on the value of the <proto> subfield. the media format depends on the value of the <proto> subfield.
If the <proto> subfield is "RTP/AVP" or "RTP/SAVP", the <fmt> If the <proto> subfield is "RTP/AVP" or "RTP/SAVP", the <fmt>
skipping to change at line 1273 skipping to change at line 1273
ptime-value = non-zero-int-or-real ptime-value = non-zero-int-or-real
Example: Example:
a=ptime:20 a=ptime:20
This gives the length of time in milliseconds represented by the This gives the length of time in milliseconds represented by the
media in a packet. This is probably only meaningful for audio data, media in a packet. This is probably only meaningful for audio data,
but may be used with other media types if it makes sense. It should but may be used with other media types if it makes sense. It should
not be necessary to know "a=ptime:" to decode RTP or VAT audio, and not be necessary to know "a=ptime:" to decode RTP or vat audio, and
it is intended as a recommendation for the encoding/packetization of it is intended as a recommendation for the encoding/packetization of
audio. audio.
6.5. maxptime (Maximum Packet Time) 6.5. maxptime (Maximum Packet Time)
Name: maxptime Name: maxptime
Value: maxptime-value Value: maxptime-value
Usage Level: media Usage Level: media
skipping to change at line 1762 skipping to change at line 1762
| 10 | the best still-image quality the | | 10 | the best still-image quality the |
| | compression scheme can give. | | | compression scheme can give. |
+----+----------------------------------------+ +----+----------------------------------------+
| 5 | the default behavior given no quality | | 5 | the default behavior given no quality |
| | suggestion. | | | suggestion. |
+----+----------------------------------------+ +----+----------------------------------------+
| 0 | the worst still-image quality the | | 0 | the worst still-image quality the |
| | codec designer thinks is still usable. | | | codec designer thinks is still usable. |
+----+----------------------------------------+ +----+----------------------------------------+
Table 2: Encoding quality values Table 2: Encoding Quality Values
6.15. fmtp (Format Parameters) 6.15. fmtp (Format Parameters)
Name: fmtp Name: fmtp
Value: fmtp-value Value: fmtp-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
skipping to change at line 1954 skipping to change at line 1954
The IETF MMUSIC working group <mmusic@ietf.org> or its successor The IETF MMUSIC working group <mmusic@ietf.org> or its successor
as designated by the IESG. as designated by the IESG.
All of these registries have a common format: All of these registries have a common format:
+======+==========+================+===========+ +======+==========+================+===========+
| 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>, <attribute-name>, <bwtype>, <nettype>, and <addrtype> <proto>, <attribute-name>, <bwtype>, <nettype>, and <addrtype>
parameters MUST include the following information: parameters MUST include the following information:
* Contact name * Contact name
* Contact email address * Contact email address
skipping to change at line 2070 skipping to change at line 2070
they apply to. they apply to.
8.2.4. Attribute Names (<attribute-name>) 8.2.4. Attribute Names (<attribute-name>)
Attribute-field names (<attribute-name>) MUST be registered with IANA Attribute-field names (<attribute-name>) MUST be registered with IANA
and 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-name> registry is:
+======+==========+=============+==============+===========+ +======+==========+=============+==============+===========+
| Type | SDP Name | Usage Level | Mux Category | Reference | | Type | SDP Name | Usage Level | Mux Category | Reference |
+======+==========+=============+==============+===========+ +======+==========+=============+==============+===========+
Table 4: Format of the attribute registry Table 4: Format of the <attribute-name> Registry
For example, the attribute "setup", which is defined for both session For example, the attribute "lang", which is defined for both session
and media level, will be listed in the new registry as follows: and media level, will be listed in the new registry as follows:
+===========+======+==========+===========+========================+ +===========+======+==========+===========+========================+
| Type | SDP | Usage | Mux | Reference | | Type | SDP | Usage | Mux | Reference |
| | Name | Level | Category | | | | Name | Level | Category | |
+===========+======+==========+===========+========================+ +===========+======+==========+===========+========================+
| attribute | lang | session, | TRANSPORT | [RFC8866] [RFC8859] | | attribute | lang | session, | TRANSPORT | [RFC8866] [RFC8859] |
| | | media | | | | | | media | | |
+-----------+------+----------+-----------+------------------------+ +-----------+------+----------+-----------+------------------------+
Table 5: Attribute registry example Table 5: <attribute-name> Registry Example
This one registry combines all of the previous usage-level-specific This one <attribute-name> registry combines all of the previous
<attribute-name> registries, including updates made by [RFC8859]. usage-level-specific "att-field" registries, including updates made
IANA is requested to do the necessary reformatting. by [RFC8859]. 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
skipping to change at line 2249 skipping to change at line 2249
The RFC MUST specify the Mux Category for this value as defined by The RFC MUST specify the Mux Category for this value as defined by
[RFC8859]. [RFC8859].
The format of the <bwtype> registry is: The format of the <bwtype> registry is:
+======+==========+==============+===========+ +======+==========+==============+===========+
| Type | SDP Name | Mux Category | Reference | | Type | SDP Name | Mux Category | Reference |
+======+==========+==============+===========+ +======+==========+==============+===========+
Table 6: Format of the <bwtype> registry Table 6: Format of the <bwtype> Registry
IANA is requested to update the <bwtype> registry entries for the IANA is requested to update the <bwtype> registry entries for the
bandwidth specifiers "CT" and "AS" with the definitions in bandwidth specifiers "CT" and "AS" with the definitions in
Section 5.8 of this memo (these definitions replace those in Section 5.8 of this memo (these definitions replace those in
[RFC4566]). [RFC4566]).
8.2.6. Network Types (<nettype>) 8.2.6. Network Types (<nettype>)
Network type "IN", representing the Internet, is defined in Network type "IN", representing the Internet, is defined in
Section 5.2 and Section 5.7 of this memo (this definition replaces Section 5.2 and Section 5.7 of this memo (this definition replaces
skipping to change at line 2280 skipping to change at line 2280
should be small and should be rarely extended. A new network type should be small and should be rarely extended. A new network type
registration MUST reference an RFC that gives details of the network registration MUST reference an RFC that gives details of the network
type and the address type(s) that may be used with it. type and the address type(s) that may be used with it.
The format of the <nettype> registry is: The format of the <nettype> registry is:
+======+==========+========================+===========+ +======+==========+========================+===========+
| Type | SDP Name | Usable addrtype Values | Reference | | Type | SDP Name | Usable addrtype Values | Reference |
+======+==========+========================+===========+ +======+==========+========================+===========+
Table 7: Format of the <nettype> registry Table 7: Format of the <nettype> Registry
IANA is requested to update the <nettype> registry to this new IANA is requested to update the <nettype> registry to this new
format. The following is the updated content of the registry: format. The following is the updated content of the registry:
+=========+==========+========================+===========+ +=========+==========+========================+===========+
| Type | SDP Name | Usable addrtype Values | Reference | | Type | SDP Name | Usable addrtype Values | Reference |
+=========+==========+========================+===========+ +=========+==========+========================+===========+
| nettype | IN | IP4, IP6 | [RFC8866] | | nettype | IN | IP4, IP6 | [RFC8866] |
+---------+----------+------------------------+-----------+ +---------+----------+------------------------+-----------+
| nettype | TN | RFC2543 | [RFC2848] | | nettype | TN | RFC2543 | [RFC2848] |
skipping to change at line 2596 skipping to change at line 2596
CRLF = <CRLF definition from RFC 5234> CRLF = <CRLF definition from RFC 5234>
HEXDIG = <HEXDIG definition from RFC 5234> HEXDIG = <HEXDIG definition from RFC 5234>
SP = <SP definition from RFC 5234> SP = <SP definition from RFC 5234>
VCHAR = <VCHAR definition from RFC 5234> VCHAR = <VCHAR definition from RFC 5234>
URI-reference = <URI-reference definition from RFC 3986> URI-reference = <URI-reference definition from RFC 3986>
addr-spec = <addr-spec definition from RFC 5322> addr-spec = <addr-spec definition from RFC 5322>
10. Summary of Changes from RFC 4566 10. Summary of Changes from RFC 4566
* Generally clarified and refined terminology. Aligned terms used * Generally clarified and refined terminology. Aligned terms used
in text with the ABNF. The term "att-field" is now <attribute- in text with the ABNF. The terms <attribute>, <att-field>, and
name>. The term "media" is now <media>. "att-field" are now <attribute-name>. The terms <value> and <att-
value> are now <attribute-value>. The term "media" is now
<media>.
* Identified now-obsolete items: "a=cat:" (Section 6.1), "a=keywds:" * Identified now-obsolete items: "a=cat:" (Section 6.1), "a=keywds:"
(Section 6.2), and "k=" (Section 5.12). (Section 6.2), and "k=" (Section 5.12).
* Updated normative and informative references, and added references * Updated normative and informative references, and added references
to additional relevant related RFCs. to additional relevant related RFCs.
* Reformatted the SDP Attributes section (Section 6) for * Reformatted the SDP Attributes section (Section 6) for
readability. The syntax of attribute values is now given in ABNF. readability. The syntax of attribute values is now given in ABNF.
skipping to change at line 2635 skipping to change at line 2637
* 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 <attribute-name> registries into a * Reorganized the several IANA "att-field" registries into a single
single registry (Section 8.2.4). <attribute-name> registry (Section 8.2.4).
* Revised ABNF syntax (Section 9) for clarity and for alignment with * Revised ABNF syntax (Section 9) for clarity and for alignment with
text. Backward compatibility is maintained with a few exceptions. text. Backward compatibility is maintained with a few exceptions.
Of particular note: Of particular note:
- 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.)
skipping to change at line 2660 skipping to change at line 2662
[RFC3261] by [RFC5954]. Removed rules that were unused as a [RFC3261] by [RFC5954]. Removed rules that were unused as a
result of this change. result of this change.
- The "att-field" rule has been renamed "attribute-name" because - The "att-field" rule has been renamed "attribute-name" because
elsewhere "*-field" always refers to a complete line. However, elsewhere "*-field" always refers to a complete line. However,
the rulename "att-field" remains defined as a synonym for the rulename "att-field" remains defined as a synonym for
backward compatibility with references from other RFCs. backward compatibility with references from other RFCs.
- The "att-value" rule has been renamed "attribute-value". - The "att-value" rule has been renamed "attribute-value".
* Revised some use of terminology in the text for clarity and
alignment with the ABNF. <attribute>, <att-field>, and "att-field"
are now <attribute-name>. <value> and <att-value> are now
<attribute-value>.
* Revised normative statements that were redundant with ABNF syntax, * Revised normative statements that were redundant with ABNF syntax,
making the text non-normative. making the text non-normative.
* Revised IPv4 unicast and multicast addresses in the example SDP * Revised IPv4 unicast and multicast addresses in the example SDP
descriptions per [RFC5735] and [RFC5771]. descriptions per [RFC5735] and [RFC5771].
* Changed some examples to use IPv6 addresses, and added additional * Changed some examples to use IPv6 addresses, and added additional
examples using IPv6. examples using IPv6.
* Incorporated case-insensitivity rules from [RFC4855]. * Incorporated case-insensitivity rules from [RFC4855].
 End of changes. 15 change blocks. 
24 lines changed or deleted 21 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/