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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]