Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP

[Colin Perkins]

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@ietf.org or ietf@ietf.org 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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf