Copyright © 2022 , Society of Motion Picture and Television Engineers . All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.
The Society of Motion Picture and Television Engineers (SMPTE) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual.
For more information, please visit www.smpte.org .
This Standards Administrative Guideline forms an adjunct to the use and interpretation of the SMPTE Standards Operations Manual. In the event of a conflict, the Operations Manual shall prevail.
This Administrative Guideline provides the process of registering a MIME Type that is based on a SMPTE Engineering Document.
The following keywords have a specific meaning in the context of this document:
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
No terms and definitions are listed in this document.
Listed below are the steps to register with IANA a new MIME Type based on a SMPTE Engineering Document using their Standards Tree registration described in IETF RFC 6838 . If a corresponding MIME Type already exists, then there is no need to go through this process.
IANA, in accordance with IETF RFC 6838 , requires the final registration template to be published in an Engineering Document. The template should be published as an Annex of the document that defines the media type (either as part of the original publication, as an amendment, or as a revision). In most cases, the Engineering Document type should be a Standard. An RP may be used if the defining document is an RP. If the registration applies to multiple standards, the registration may be published as an Amendment to any of the referenced Standards or as a separate RP.
An example of the body text for an Amendment that specifies a MIME Type Registration Template is shown in Annex B .
The following steps in this section shall be performed.
The Editor should read the following RFCs (or RFCs that have obsoleted them) before proceeding with an application for a MIME Type. It is important to understand the application process and requirements completely. These documents are the standards for Media Types:
After completing the research and verifying that there is not an existing MIME Type that can be referenced, the Editor should collect the information required in IETF RFC 6838 to register the MIME Type and populating a draft registration template, such as the one in Annex A .
The Engineering Document follows the due process defined in the SMPTE Standards Operations Manual . If desired, the Editor may request that the TC Chair submit a provisional registration request once the project is approved to hold the type name. Once the CD has been finalized, the Editor shall request that the TC Chair submit the draft registration request to IANA.
The
TC
Chair
shall
submit
the
draft
registration
by
filling
out
the
application
(
https://www.iana.org/form/media-types
)
with
the
following
information
from
the
approved
template.
Any
items
that
are
not
applicable
shall
be
filled
out
with
N/A
.
Do
not
use
words
like
“none”
that
might
be
interpreted
incorrectly.
This shall be the name of the TC chair submitting the registration for review.
This
shall
be
the
Teams
email
address
(
@m.smpte.org
)
of
the
TC
Chair
submitting
the
registration
for
review.
What is the media type name? This should be copied from the approved template.
What is the media subtype name? This should be copied from the approved template.
Describe the required parameters. This should be copied from the approved template.
Describe the optional parameters. This should be copied from the approved template.
Select
between;
7-bit
text
,
8-bit
text
,
binary
,
or
framed
.
Provide
additional
notes
if
necessary.
This
should
be
copied
from
the
approved
template.
Provide a discussion of the security considerations. This should be copied from the approved template.
Provide a discussion of the interoperability considerations. This should be copied from the approved template.
If the Standard has already been published (e.g., if the registration is being published as an Amendment), provide references to the published specification. If applicable, this should be copied from the approved template.
Describe applications which use this media type. This should be copied from the approved template.
This should be copied from the approved template.
This should be copied from the approved template.
Check
Yes
.
After
the
document
is
published,
the
Director
of
Standards
will
check
No
when
the
final
registration
is
submitted.
There are subcategories here to be copied from the approved template.
These three categories and detail to be copied from the approved template. Note that at the time this AG is published, there is a free-form text box below the pull-down menu that is required and can simply match the contents of the pulldown if no further text is provided by the Editor.
This shall be filled out with the following text:
IMPORTANT: This is a draft presented as a request for feedback from IANA experts. We respectfully request a provisional registration while the document is in process.
The contact person shall “Director of Standards” and the contact email shall be standards-support@smpte.org .
IANA is generally responsive and will likely send a confirmation that the draft registration has been received and in some cases might request additional information. For instance, if the referenced standard is behind a paywall, the TC chair should be prepared to supply a liaison copy of the referenced standard. The TC Chair should ensure that the IANA representative understands that SMPTE is requesting expert feedback on the submission. The submitting TC chair shall submit any feedback received as one or more comments against the FCD ballot.
The SMPTE Engineering Document development process is then followed. Further changes may be made as a result of document reviews or comment resolution according to the due process defined by the SMPTE Standards Operations Manual .
Once
the
document
has
been
published,
the
Editor
should
notify
the
Director
of
Standards
to
submit
the
final
registration.
The
registration
template
information
should
be
copied
directly
from
the
published
document,
and
the
Provisional
Registrations
field
is
set
to
No
,
as
the
request
represents
the
final
registration,
and
with
the
Other
Information
&
Comments
field
filled
as
follows:
This registration request corresponds to a previously accepted provisional registration request. The related SMPTE document has since been formally published as represented herein. Final publication of this registration is respectfully requested.
The Director of Standards should forward the tracking number back to the Editor for tracking the progress of the request to Acceptance.
The following template may be used to fulfill the requirements of 5.2 . This template is based on the template provided in IETF RFC 6838 and this annex can be updated as necessary as that document is superseded. Further information on each field in the registration template is available in IETF RFC 6838 .
| Author (name and email): | Name and email address of the TC chair corresponding to 5.4.2 and 5.4.3 |
| Type name: | What is the media type name? |
| Subtype name: | What is the media subtype name? |
| Required Parameters: | Describe the required parameters. |
| Optional Parameters: | Describe the optional parameters. |
| Encoding considerations: |
[
7-bit
text,
8-bit
text,
binary,
framed
]
Provide additional notes as necessary. |
| Security considerations: | Provide a discussion of security considerations. |
| Interoperability considerations: | Provide a discussion of the interoperability considerations. |
| Published Specification: |
Provide
references
to
the
published
specification,
if
any.
Otherwise,
N/A
.
|
| Applications that use this media type: | Describe applications which use this media type. |
| Fragment identifier considerations: | See IETF RFC 3986 |
| Restrictions on usage: |
N/A
except
where
intended
usage
is
LIMITED
USE
.
|
| Provisional Registration? |
YES
|
| Additional information: |
Optional
(use
N/A
as
needed
where
these
fields
are
not
supplied)
|
| Deprecated alias names for this type: | |
| Magic number(s): | |
| File extension(s): | |
| Macintosh file type code(s): | |
| Object Identifier(s) or OID(s) | See IETF RFC 1494 |
| Intended usage: |
[
COMMON,
LIMITED
USE,
OBSOLETE
]
|
| Other information & Comments |
IMPORTANT:
This
is
a
draft
presented
as
a
request
for
feedback
from
IANA
experts.
We
respectfully
request
a
provisional
registration
while
the
document
is
in
process.
|
| Contact Person: |
Director
of
Standards,
Society
of
Motion
Picture
and
Television
Engineers
(SMPTE)
standards-support&smpte.org
|
The
following
is
the
body
text
of
an
example
Amendment
(Amd1:2022
to
ST
268-2:2018),
which
specifies
the
registration
template
used
for
the
image/dpx
MIME
type.
1 Scope
This amendment contains the registration template for the image/dpx MIME type.
2 Add New Annex D
The following text is added as Annex D:
Annex D IANA MIME Type Registration Template (informative)
This annex serves to register and document the MIME Type image/dpx, which is associated with files
conforming to SMPTE ST 268-1 or SMPTE ST 268-2. The registration is intended to address the
requirements of IETF RFC 6838.
D.1 Media type name
image
D.2 Media subtype name
dpx
D.3 Required parameters
N/A
D.4 Optional parameters
standard – If specified, the parameter indicates the version of the SMPTE standard with which the
file complies. At the time of IANA registration, the possible values are st268-1 (for SMPTE ST 268-1)
and st268-2 (for SMPTE ST 268-2).
If the standard parameter is absent, the file can comply with any version of the SMPTE standard.
D.5 Encoding considerations
binary
D.6 Security considerations
DPX files only encode images with corresponding metadata and do not employ executable content.
The header defines a "user-defined information" section that can contain arbitrary binary data. As
such, a maliciously coded file could contain a binary blob comprising executable content. Therefore,
the user-defined header must not contain executable content, and implementations that receive,
display, or otherwise process images must preclude the execution of any executable content that
ight be received.
Some files also contain a “standards-based metadata” section that can include arbitrary XML. Such
XML could include potentially harmful or malicious links to other resources. Implementations will
need to ensure that a received file can be handled within the available memory. DPX allows
run-length encoding, so decoders will need suitable bounds checks to ensure that memory locations
outside the allocated decoded image buffer cannot be altered.
DPX files do not have integral encryption or authentication. A 32-bit “encryption key” field is
defined in SMPTE ST 268-1, but the standard does not specify an encryption algorithm; therefore,
utilizing the field for encrypting picture data will generally not be interoperable. Any file
protection, privacy, or integrity requirements must be handled using an external mechanism.
D.7 Interoperability considerations
SMPTE ST 268-1 has been very widely used since it was standardized (initially as SMPTE 268M:1994)
but has experienced some interoperability issues in practice. These issues have occurred primarily
due to conflicting interpretations relating specifically to how the pixel data is ordered, packed,
and padded. SMPTE ST 268-2 has improved interoperability due to the inclusion of metadata that
resolves ambiguities that are present in ST 268-1. However, ST 268-2 is a more recent standard,
whereas ST 268-1 has been widely used for many years prior and is employed in voluminous archives.
Both ST 268-1 and ST 268-2 define core fields and values. Files must include all core fields, and
reader or receiver implementations must interpret all core fields and values.
D.8 Published specification
SMPTE ST 268-1; SMPTE ST 268-2 (which incorporates ST 268-1 by reference)
D.9 Applications which use this media
DPX is derived from Kodak's Cineon format and is used primarily as a file format for digitization
of camera-captured frames and as a digital intermediate file format.
D.10 Fragment identifier considerations
N/A
D.11 Restrictions on usage
N/A
D.12 Additional information
D.12.1 Deprecated alias names for this type
N/A
D.12.2 Magic number(s)
hex 53 44 50 58 (most-significant byte first file) or 58 50 44 53 (least-significant byte first file)
D.12.3 File extension(s)
dpx
D.12.4 Macintosh file type code
N/A
D.12.5 Object Identifiers
N/A
D.13 Person to contact for further information
Name: Director of Standards Development
Email: standards-support&smpte.org
D.14 Intended usage
Common
D.15 Author/Change controller
Society of Motion Picture and Television Engineers ("SMPTE")
3 Add new Bibliography item
The following text is added to the Bibliography:
IETF RFC 6838 – Media Type Specifications and Registration Procedures.