SDP image media type: IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)
Registering 'image' as a top-level media type for session descriptions.
Salgueiro, G., "IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)", RFC 6466, DOI 10.17487/RFC6466, December 2011, <https://www.rfc-editor.org/info/rfc6466>.
@misc{rfc6466,
series = {Request for Comments},
number = 6466,
howpublished = {RFC 6466},
publisher = {RFC Editor},
doi = {10.17487/RFC6466},
url = {https://www.rfc-editor.org/info/rfc6466},
author = {G. Salgueiro},
title = {{IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)}},
pagetotal = 6,
year = 2011,
month = dec,
} RFC text
Contents
Internet Engineering Task Force (IETF) G. Salgueiro
Request for Comments: 6466 Cisco Systems
Category: Standards Track December 2011
ISSN: 2070-1721
IANA Registration of the 'image' Media Type
for the Session Description Protocol (SDP)
Abstract
This document describes the usage of the 'image' media type and
registers it with IANA as a top-level media type for the Session
Description Protocol (SDP). This media type is primarily used by SDP
to negotiate and establish T.38 media streams.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6466.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Overview
In an earlier version of the SDP specification [RFC2327] of
packetized media types, such as those used with the Real-time
Transport Protocol (RTP) [RFC3550], share the namespace with
Multipurpose Internet Mail Extensions (MIME) media types registry
[RFC4288] [RFC4289] (i.e., "MIME media types"). This is in contrast
to the latest version of the SDP specification [RFC4566], which
requested that an SDP-specific media type registry be created and
maintained by IANA. The top-level SDP media content types registered
by RFC 4566 [RFC4566] are 'audio', 'video', 'text', 'application',
and 'message'. A glaring omission from this list is the 'image'
media type.
The 'image' media type is an existing top-level MIME media type and
is widely used in SDP implementations for setting up T.38 Real-Time
Facsimile [T38] media streams. This media type is extensively
referenced by examples in ITU-T T.38 [T38] and IETF Standards Track
documents like RFC 4145 [RFC4145]. The following example shows the
media description of a T.38 media stream as commonly found in a
Session Initiation Protocol (SIP) [RFC3261] INVITE; it contains an
SDP offer for T.38 over both UDP Transport Layer (UDPTL) and TCP.
For the sake of brevity, only the SDP body of the SIP INVITE request
is displayed in this example.
v=0
o=alice 53655765 2353687637 IN IP4 pc33.example.com
s=SDP image example
c=IN IP4 192.0.2.2
t=0 0
m=image 49170 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:262
a=T38FaxMaxDatagram:90
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv
m=image 49172 tcp t38
a=T38FaxRateManagement:localTCF
The purpose of this document is to register with IANA the 'image'
media type as a top-level SDP media type. This ensures seamless
continuity with documentation that uses the 'image' MIME media type
and the previously registered MIME media sub-types like 'image/t38'
[RFC3362] that are used as SDP media descriptors for T.38 [T38].
This document complies with the request of Section 8.2.1 of RFC 4566
[RFC4566] that indicates:
The same rules should apply for media names as for top-level media
content types, and where possible the same name should be
registered for SDP as for MIME. For media other than existing
top-level media content types, a Standards Track RFC MUST be
produced for a new top-level content type to be registered, and
the registration MUST provide good justification why no existing
media name is appropriate.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. IANA Considerations
IANA has registered an 'image' token in the media sub-registry of the
Session Description Protocols (SDP) Parameters registry. This
registration contains the required information elements outlined in
the SDP registration procedure defined in Section 8.2.8 of RFC 4566
[RFC4566].
(1) Contact Information:
Name: Gonzalo Salgueiro
Email: gsalguei@cisco.com
Telephone Number: (919) 392-3266
(2) Name being registered (as it will appear in SDP): image
(3) Long-form name in English: image
(4) Type of name ('media', 'proto', 'fmt', 'bwtype', 'nettype', or
'addrtype'): media
(5) Purpose of the registered name:
The 'image' media type for the Session Description Protocol
is used to describe a media stream whose content consists of
one or more separate images that require appropriate hardware
to display. The media subtype further describes the specific
format of the image. Currently, the 'image' media type for
SDP is used ubiquitously by the SIP control protocol to
establish T.38 media streams.
(6) Specification for the registered name: RFC 6466
4. Security Considerations
The 'image' media type registered by this document in the SDP
parameters registry maintained by IANA is primarily for use by the
offer/answer model of the Session Description Protocol [RFC3264] for
the negotiation and establishment of T.38 [T38] media streams using
SIP [RFC3261]. This additional SDP media type does not introduce any
security considerations beyond those detailed in Section 7 of RFC
4566 [RFC4566].
The security vulnerabilities in T.38 [T38] and its associated
transport protocols (TCP [RFC0793], UDP [RFC0768], and RTP [RFC3550])
are well documented in each of their respective specifications. The
ability to exchange images other than T.38 can expose the recipient
to potentially malicious executable code.
5. Acknowledgements
Thanks go to the chairs of the IETF Multiparty Multimedia Session
Control (MMUSIC) working group (Miguel A. Garcia and Flemming
Andreasen) for their guidance, encouragement, and the creation of the
media type registry. Special thanks to Miguel A. Garcia for his
thorough and insightful review of the many draft revisions of this
document.
This document has benefited from the discussion and review of the
MMUSIC working group, especially the detailed and thoughtful comments
and corrections of Keith Drage, Yasubumi Chimura, Kevin P. Fleming,
Bert Greevenbosch, and Gonzalo Camarillo.
The author would also like to acknowledge the considerable efforts of
Kevin P. Fleming and the members of the Fax-over-IP (FoIP) TG in the
SIP Forum that contributed to the new revision of the ITU-T T.38
Recommendation that prompted the need to register the 'image' media
type for SDP.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
6.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3362] Parsons, G., "Real-time Facsimile (T.38) - image/t38 MIME
Sub-type Registration", RFC 3362, August 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, December 2005.
[T38] International Telecommunication Union, "Procedures for
real-time Group 3 facsimile communication over IP
Networks", ITU-T Recommendation T.38 (Pre-Published),
September 2010,
<http://www.itu.int/rec/T-REC-T.38-201009-P/en>.
Author's Address
Gonzalo Salgueiro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
EMail: gsalguei@cisco.com
AI ELI5
On this page
§1Why 'image' Matters in SDP
The Session Description Protocol (SDP) is used to describe multimedia sessions, allowing devices to agree on what kinds of data they will exchange. RFC 4566 defined five top-level media types for SDP: 'audio', 'video', 'text', 'application', and 'message'. However, an important media type was missing: 'image'.
The 'image' media type is an established top-level MIME media type, and it was already widely used in real-world SDP implementations for negotiating T.38 fax media streams. ITU-T T.38 is a standard for sending fax documents over IP networks, and implementations commonly used 'image' in SDP descriptions even though the protocol specification did not officially register it.
Imagine a rulebook for describing calls that was missing 'pictures' even though everyone was already sending pictures. This RFC fixes that.
§2The Gap Between Standards and Practice
Before RFC 6466, a discrepancy existed between the SDP specification and real-world deployments. The specification created a registry for SDP-specific media types, separate from MIME types, and RFC 4566 was careful to request that new media types be registered in this registry. However, the 'image' type—which predated this registry decision—was not included in the initial list.
The RFC notes that 'image' had been extensively referenced in ITU-T T.38 examples and in IETF standards like RFC 4145 (TCP-Based Media Transport in SDP). The example in RFC 6466 shows a typical SDP session description for a T.38 fax media stream, with the media line reading m=image 49170 udptl t38. This usage was common, but lacked explicit standardization.
The standard rulebook didn't mention 'pictures', but everyone was using them anyway. This RFC officially adds them to the book.
§3IANA Registration Details
RFC 6466 registers 'image' as a media type in the Session Description Protocols (SDP) Parameters registry. The registration includes: the contact information of the registrant (Gonzalo Salgueiro from Cisco); the name to be registered in SDP as 'image'; the long-form name in English, also 'image'; the type of name as 'media' (not 'proto', 'fmt', or other variants); and the purpose of the registration.
The stated purpose is that the 'image' media type describes a media stream whose content consists of one or more separate images that require appropriate hardware to display. The media subtype (the part after the slash, such as 't38') further specifies the format. The registration notes that 'image' is used ubiquitously with the SIP control protocol to establish T.38 media streams.
The registry now officially says: 'image' is a valid choice for describing media in a session, mainly for fax.
§4Security and Compatibility
RFC 6466 notes that registering 'image' as an SDP media type does not introduce new security considerations beyond those already described in RFC 4566. The security properties of SDP itself—and the Offer/Answer Model that negotiates these media types—remain unchanged.
However, the RFC acknowledges security issues in the technologies that might use this media type. T.38 itself, along with its transport protocols (TCP, UDP, and RTP), have documented security considerations. Additionally, the ability to exchange images other than T.38 could expose recipients to potentially malicious executable code. These risks are pre-existing and not introduced by this registration.
Adding 'image' doesn't make calling less safe. But if someone sends you a bad image file, that's still dangerous. The RFC says so.
§5Why This Matters
This registration serves as formal standards-track justification for a media type that was already in widespread use. By registering 'image', RFC 6466 complies with the request in RFC 4566 Section 8.2.1, which stated that new top-level media types for SDP should be produced as Standards Track RFCs with good justification.
The practical benefit is alignment between the MIME media type namespace and the SDP media type registry. Implementors and specification writers can now point to a formal standards document when using 'image' in SDP. For T.38 fax over IP, this provides clearer guidance in the standards literature.
This gives the rulebook permission to use 'image', which helps engineers know they're doing the right thing.