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
SMPTE's
Engineering
Documents,
including
Standards,
Recommended
Practices,
and
Engineering
Guidelines,
are
prepared
by
SMPTE’s
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 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.
The following keywords have a specific meaning in the context of 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”
"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
"Director
of
Standards”
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 parametersstandard – If specified, the parameter indicates the version of the SMPTE standard with which thestandard - 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. SuchSome 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 isDPX 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.IETF RFC 6838 - Media Type Specifications and Registration Procedures.