The IESG has received a request from an individual submitter to consider the following document:
- 'Media Type Specifications and Registration Procedures ' <draft-freed-media-type-reg-02.txt> as a BCP
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2005-04-12.
I have reviewed draft-freed-media-type-reg-03.txt, and have a number of
comments intended to align the registration procedures with the current
practice defined RFC 3555. These primarily arise due to the widespread use
of media subtype names to identify formats that can be conveyed within RTP.
The rules for display of text media types assume that such types are, to
some extent, readable without special purpose viewing software. This is
certainly true for most types, but some existing types have restrictions
on their use which are incompatible with this rule (e.g. the "text/t140"
type specified in RFC 2793 is a framed encoding defined only for transfer
via RTP and cannot be directly displayed). The following edit to Section
4.2.1 ("Text Media Types"), third paragraph, is one way to resolve this
inconsistency, by noting that subtypes which are defined with restricted
usage cannot necessarily be directly displayed:
OLD:
Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of "text".
NEW:
Beyond plain text, there are many formats for representing what might
be known as "rich text". An interesting characteristic of many such
representations is that they are to some extent readable even without
the software that interprets them. It is useful, then, to
distinguish them, at the highest level, from such unreadable data as
images, audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, and provided the subtype
^^^^^^^^^^^^^^^^^^^^^^^^
is not defined for restricted usage, it is reasonable to show subtypes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
of "text" to the user, while it is not reasonable to do so with most non
textual data. Such formatted textual data should be represented using
subtypes of "text".
The addition of the "framed" encoding defined in section 4.8 is valuable
now that media types are being widely used outside the traditional email
environment. Since there are many media types defined to use RTP framing,
and since RFC 3555 imposes additional registration requirements on these
formats, it would be useful to reference it from within this draft. The
following change to section 4.8 is one possible such edit:
OLD:
framed The content consists of a series of frames or packets without
internal framing or alignment indicators. Additional out of band
information is needed to interpret the data properly, including
but not necessarily limited to knowledge of the boundaries between
successive frames. Note that media types of this sort cannot
simply be stored in a file or transported as a simple stream of
octets, and therefore such media types are unsuitable for use in
many traditional protocols.Additional restrictions on 7bit and 8bit are given in [RFC2046].
NEW:
framed The content consists of a series of frames or packets without
internal framing or alignment indicators. Additional out of band
information is needed to interpret the data properly, including
but not necessarily limited to knowledge of the boundaries between
successive frames and knowledge of the transport mechanism. Note
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that media types of this sort cannot simply be stored in a file or
transported as a simple stream of octets, and therefore such media
types are unsuitable for use in many traditional protocols.Additional restrictions on 7bit and 8bit are given in [RFC2046]. A commonly used transport with framed encoding is the Real-time ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Transport Protocol, RTP. Additional rules for framed encodings ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ defined for transport using RTP are given in [RFC3555]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This change also adds wording to indicate that knowledge of the transport
mechanism is required to understand a framed format, since each transport
may convey frames in a different way, and will hence require different out
of band information to interpret the data (e.g. RFC 3952 defines a subtype
"audio/iLBC" comprising a sequence of iLBC audio frames, along with out of
band information necessary to interpret those frames when conveyed in both
file- and RTP-based transport).
As a consequence of the above changes, a normative reference to RFC 3555 is introduced. This will require the addition of:
[RFC3555] Casner, S., and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.in section 14.1.
One might expect many framed encodings to be defined for restricted use only, or to require parameters which are specific to the combination of transport and media type. It might be worthwhile adding text to clarify that this is expected, although it's not clear to me what would be the best place to add it.
Colin
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf