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

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Apr 2005 16:58:52 +0100

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
> [email-masked] or [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Tue, 12 Apr 2005 09:57:12 -0700 (PDT)

> of media subtype names to identify formats that can be conveyed within

Thanks for taking the time to review it.

                                                    

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.

>     A commonly used transport with framed encoding is the Real-time

Very good stuff. Added.

> in section 14.1.

Added as well.

> that this is expected, although it's not clear to me what would be the

Yeah, I don't see a good place for it either, so I'm not going to put it in.

				Ned

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 12 Apr 2005 13:26:26 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, April 12, 2005 12:57 PM
> To: Colin Perkins
> Cc: [email-masked]; [email-masked]
> Subject: Re: Last Call: 'Media Type Specifications and 
> Registration Procedures' to BCP

[snip]

> whole idea of having top-level types is predicated on not 

Ned, how would you reconcile the current text in your document with the
practice specified in RFC 3555?  It's been alleged that the documents are
not in alignment.

-Scott-

---

From: [email-masked]
Date: Tue, 12 Apr 2005 10:30:53 -0700 (PDT)

> practice specified in RFC 3555?  It's been alleged that the documents are

Assuming they really are out of alignment, I'd reconcile them by making
whatever changes are appropriate in a revision to RFC 3555. Changing
fundamental aspects of how media types are supposed to work and which vast
tracts of code depend on is just not an option.

				Ned

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Apr 2005 18:54:28 +0100

> tracts of code depend on is just not an option.

The other changes I suggested were to align the draft with RFC 3555. 
This is a related change, primarily introduced because of the 
"text/t140 type" which is clearly textual data, but requires software 
to decode (and was registered under the RFC 3555 rules). Apologies if 
that wasn't clear.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Apr 2005 19:03:03 +0100

On 12 Apr 2005, at 17:57, [email-masked] wrote:
...
>> usage cannot necessarily be directly displayed:
...
> 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.

Sure, but if the display agent is unaware of the restrictions, it won't 
ever be able to receive the media data. The example I have in mind in 
"text/t140" which is UTF-8 text framed within RTP packets [RFC 2793]. 
The media type is defined only for use with RTP, and an agent that 
doesn't know how to decode RTP framing (i.e. a sequence of UDP packets 
with explicit time and ordering data) will never see the data.

Colin

---

From: Robert Elz <[email-masked]>
Date: Wed, 13 Apr 2005 02:51:34 +0700

Date:        Tue, 12 Apr 2005 19:03:03 +0100
    From:        Colin Perkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | Sure, but if the display agent is unaware of the restrictions, it won't 
  | ever be able to receive the media data. The example I have in mind in 
  | "text/t140" which is UTF-8 text framed within RTP packets [RFC 2793]. 
  | The media type is defined only for use with RTP,

I'm not sure I believe that works.   What prevents this message from
containing an alternative to the text/plain that is (currently) its
only body type, with a Content-Type: text/t140 field (and correctly
formatted for that, as much as it can be in a e-mailbody)  ?

Or what prevents a HTTP response with Content-Type: text/t140?

Sure, the rules for use of that content-type may have been violated,
but what is your MUA (or browser) supposed to do when it receives the message?
All it is likely to know is that it has received yet another odd text/unknown
content type.   And if it is to be displayed, treating it just like all
other text/weird types as the fallback (better than nothing) option ?

I think Ned's point (though he can certainly speak for himself) is that
if rfc3555 is allowing registrations like that, then rfc3555 needs to
be fixed, and any bogus registrations that have been made, need to be
corrected.

kre

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Apr 2005 21:20:28 +0100

> be fixed, and any bogus registrations that have been made, need to be

RFC 3555 allows media types to be defined for transport only via RTP. 
The majority of these registrations are under the audio and video 
top-level types, with a small number being under text. Is your 
objection to any media type being defined only for transport via RTP, 
or to text media types being defined only for transport via RTP?

Colin

---

From: Robert Elz <[email-masked]>
Date: Wed, 13 Apr 2005 05:04:29 +0700

Date:        Tue, 12 Apr 2005 21:20:28 +0100
    From:        Colin Perkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | RFC 3555 allows media types to be defined for transport only via RTP. 
  | The majority of these registrations are under the audio and video 
  | top-level types, with a small number being under text. Is your 
  | objection to any media type being defined only for transport via RTP, 
  | or to text media types being defined only for transport via RTP?

Not to either of those being attempted, but to the expectation that the
"only via RTP" will, or can, ever be enforced.

That is, to your earlier statement ...

	Sure, but if the display agent is unaware of the restrictions, it won't 
	ever be able to receive the media data.

You'd need to be able to show me how that can possibly be true, when I
can trivially easily send e-mail with text/t140 in the Content-Type header.

kre

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Apr 2005 23:50:57 +0100

> can trivially easily send e-mail with text/t140 in the Content-Type 

You can put anything you like in a Content-Type header, but that 
doesn't make the data meaningful without a specification for the 
content.

The restriction for "only via RTP" is made by only specifying the 
framing rules for RTP transport; the necessary information to convey 
the type via non-RTP transports is simply not specified. There are many 
(more than 50) such media types registered, and they are widely 
implemented without the problems at which you are hinting.

Colin

---

From: Stephen Casner <[email-masked]>
Date: Tue, 12 Apr 2005 16:33:21 -0700 (PDT)

> "only via RTP" will, or can, ever be enforced.

What that means is that the specifications only supply instructions
about how to format and transmit the data via RTP, not any other
method.  Therefore...

> can trivially easily send e-mail with text/t140 in the Content-Type header.

When you set out to do that, how are you going to figure out what some
text/t140 content should be?  Are you saying that you would use that
Content-Type but just put US-ASCII into the body?  You could also use
Content-Type=audio/basic and put US-ASCII into the body, but it would
probably not be very useful.

                                                        -- Steve

---

From: [email-masked]
Date: Tue, 12 Apr 2005 15:48:45 -0700 (PDT)

> "only via RTP" will, or can, ever be enforced.

Exactly so. This is why I've been pushing back on this. Stuff slops from one
application/transport to another all the time.

> can trivially easily send e-mail with text/t140 in the Content-Type header.

Two points:

(1) IMO text/t140 content actually conforms pretty well to the restrictions on
    the text top-level type. In particular, text/t140 material basically
    consists of unadorned UTF-8 text. There are a couple of control characters
    used for special purposes, but we're not talking about HTML here or
    anything similar.

(2) The place where text/t140 parts ways with other media type usage is in
    how it is encoded. text/t140 cannot be encoded as a simple series
    of octets. Rather, it depends critically on RTP packet framing both
    to tie the content to other media and to eliminate duplicate material.
    We added the "framed" encoding type to the media type registration
    to take care of this and similar cases. A media type that uses
    the "framed" encoding really is confined to a particular transport
    realm.

So, in the case of text/t140, I reallly don't see any conflict we need to
resolve. But this doesn't mean there aren't potential conflicts - media types
have been defined that work in both the packet and stream worlds. And such
types could very easily leak - in fact I'd be surprised if they didn't.

				Ned