On 15 Mar 2005, at 21:25, The IESG wrote:
> 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.
Thanks for taking the time to review it.
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".
I'm quite sympathetc to the underlying problem, but IMO this change is
unacceptable, in that in order to make it work the fact that a given subtype is
intended for restricted usage would have to be known to the display agent. The
whole idea of having top-level types is predicated on not needing this sort of
exception information.
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].
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Very good stuff. Added.
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.
Added as well.
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.
Yeah, I don't see a good place for it either, so I'm not going to put it in.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf