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