| rfc9751v1.txt | rfc9751.txt | |||
|---|---|---|---|---|
| Internet Engineering Task Force (IETF) M. Westerlund | Internet Engineering Task Force (IETF) M. Westerlund | |||
| Request for Comments: 9751 Ericsson | Request for Comments: 9751 Ericsson | |||
| Updates: 8088 February 2025 | Updates: 8088 March 2025 | |||
| Category: Standards Track | Category: Standards Track | |||
| ISSN: 2070-1721 | ISSN: 2070-1721 | |||
| Closing the RTP Payload Format Media Types Registry | Closing the RTP Payload Format Media Types Registry | |||
| Abstract | Abstract | |||
| A number of authors defining RTP payload formats and the Working | A number of authors defining RTP payload formats and the Working | |||
| Group process have failed to ensure that the media types are | Group process have failed to ensure that the media types are | |||
| registered in the IANA "RTP Payload Format Media Types" registry as | registered in the IANA "RTP Payload Format Media Types" registry as | |||
| skipping to change at line 63 ¶ | skipping to change at line 63 ¶ | |||
| 3. IANA Considerations | 3. IANA Considerations | |||
| 4. Security Considerations | 4. Security Considerations | |||
| 5. References | 5. References | |||
| 5.1. Normative References | 5.1. Normative References | |||
| 5.2. Informative References | 5.2. Informative References | |||
| Acknowledgments | Acknowledgments | |||
| Author's Address | Author's Address | |||
| 1. Introduction | 1. Introduction | |||
| It has been observed that specifications of new Real-time Transport | Some times, authors defining new Real-time Transport Protocol (RTP) | |||
| Protocol (RTP) payload formats often forget to specify registration | payload formats forgot to specify registration of the format's media | |||
| of the format's media type in the IANA registry "RTP Payload Formats | type in the "RTP Payload Format Media Types" registry [RTP-FORMATS] | |||
| Media Types" [RTP-FORMATS] as recommended by [RFC8088]. In practice, | as recommended by [RFC8088]. In practice, this has no real impact. | |||
| this has no real impact. This registry is not used for any purpose | This registry is not used for any purpose other than to track which | |||
| other than to track which media types actually have RTP payload | media types actually have RTP payload formats, which can be done | |||
| formats. That purpose could be addressed through other means. | through other means. | |||
| The "Media Types" registry [MEDIA-TYPES] is the crucial registry to | It is required that media types be registered in the "Media Types" | |||
| register any media type to establish the media type used to identify | registry [MEDIA-TYPES] to identify the format in various signalling | |||
| the format in various signalling usages, to avoid collisions, and to | usages, avoid collisions, and reference the defining specifications. | |||
| reference their specifications. | ||||
| To resolve this situation, this document performs the following | To resolve this situation, this document: | |||
| actions. First, it updates the registry to include known RTP payload | ||||
| formats at the time of writing. Then, it closes the "RTP Payload | * updates the "RTP Payload Format Media Types" registry to include | |||
| Format Media Types" registry to future registrations. Beyond | known RTP payload formats at the time of writing, | |||
| instructing IANA to close this registry, the instructions to authors | ||||
| in [RFC8088] are updated so that registration in the closed registry | * closes the "RTP Payload Format Media Types" registry to future | |||
| is no longer mentioned. | registrations and lists this RFC as a reference, and | |||
| * removes from [RFC8088] the instruction to register RTP payload | ||||
| formats in the "RTP Payload Format Media Types" registry. | ||||
| The origins of the "RTP Payload Format Media Types" registry, as | The origins of the "RTP Payload Format Media Types" registry, as | |||
| referenced in [RTP-FORMATS], are unclear. The registry cites | referenced in [RTP-FORMATS], are unclear. The registry cites | |||
| [RFC4855] as providing the instructions for its maintenance. | [RFC4855] as providing the instructions for its maintenance. | |||
| However, upon reviewing RFC 4855, no text has been found that defines | However, upon reviewing RFC 4855, no text has been found that defines | |||
| the registry's purpose and operational rules. Further attempts to | the registry's purpose and operational rules. Further attempts to | |||
| trace the registry's creation have failed to uncover any references | trace the registry's creation have failed to uncover any references | |||
| to its establishment. It is likely that the registry was created | to its establishment. It is likely that the registry was created | |||
| based on email correspondence or at the request of an Area Director. | based on email correspondence or at the request of an Area Director. | |||
| Consequently, there is no known specification for this registry that | Consequently, there is no known specification for this registry that | |||
| requires updating upon its closure. | requires updating upon its closure. | |||
| 2. Update to How to Write an RTP Payload Format | 2. Update to How to Write an RTP Payload Format | |||
| The IANA Considerations section of "How to write an RTP Payload | The IANA Considerations section of "How to write an RTP Payload | |||
| Format" (Section 7.4 of [RFC8088]) mandates that RTP payload formats | Format" (Section 7.4 of [RFC8088]) mandates that RTP payload formats | |||
| shall be registered in the "RTP Payload Format Media Types" registry. | shall be registered in the "RTP Payload Format Media Types" registry. | |||
| This paragraph is changed without affecting its status as part of an | The following paragraph is updated as shown below, thus removing the | |||
| Informational RFC. Thus removing the need to register in the "RTP | need for media types to be registered in the "RTP Payload Format | |||
| Payload Format media types". | Media Types" registry. Note that this update does not impact the | |||
| rest of RFC 8088's status as an Informational RFC. | ||||
| OLD: | OLD: | |||
| | Since all RTP payload formats contain a media type specification, | | Since all RTP payload formats contain a media type specification, | |||
| | they also need an IANA Considerations section. The media type | | they also need an IANA Considerations section. The media type | |||
| | name must be registered, and this is done by requesting that IANA | | name must be registered, and this is done by requesting that IANA | |||
| | register that media name. When that registration request is | | register that media name. When that registration request is | |||
| | written, it shall also be requested that the media type is | | written, it shall also be requested that the media type is | |||
| | included under the "RTP Payload Format media types" sub-registry | | included under the "RTP Payload Format media types" sub-registry | |||
| | of the RTP registry (http://www.iana.org/assignments/rtp- | | of the RTP registry (http://www.iana.org/assignments/rtp- | |||
| End of changes. 5 change blocks. | ||||
| 22 lines changed or deleted | 25 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||