Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)

[Dave Singer]

>  >
>>  The slides you quote are my interpretation of the traditional rules for
>>  media under the "text" top level type. As you know, there has been some
>>  discussion on relaxing these rules for media types with limited domain
>>  of applicability. The RTP Payload Format for 3GPP timed text might fall
>>  into this new category. Accordingly, we have this MIME review to decide
>>  if the format should be "text" or "video".
>
>Thanks for your answer. So we have that *only* registering for a wider
>domain of applicability would require to follow the *traditional* rules.
>
>Would one criteria for assessing the domain of applicability be to group the
>use cases in those that don't need modifiers and those that do? This is
>intuitive. I.e.:
>
>simple text apps (require no modifiers= no video requirements, thus
>text/3gpp-tt?)
>-----------
>- instant messaging
>- text conversation
>- other..
>
>more complex apps (have video reqs.)
>------------------
>- commercial banners (decorated)
>- news tickers (decorated)
>- karaoke
>- clickable text strings
>- captions (although most captions don't need modifiers, some do e.g.
>scrolling end actors' list)
>
>If this analysis is OK, we could register both and clearly state the
>scenarios in which each of them is used.  This would enable a client that
>just understands UTF8/16 and the payload format to receive the text/3gpp-tt
>w/o implementing the more complex timed text decoder, which may be useful.
>A side effect of using this classification is that the registration *does
>implicitly* follow the traditional rules.
>
>Looking forward to your comments,
>

Since this payload format always has some binary fields, the text 
cannot be correctly extracted without understanding it, whether or 
not modifiers are present.  I therefore feel that it should be either 
(a) only under text/ or (b) only under video/.  I don't see any 
advantage to splitting it like this;  the 3gpp-payload-unaware 
terminal can't make any more sense of a packet without modifiers than 
it can one with them.
-- 
David Singer
Apple Computer/QuickTime