Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
On 12 Aug 2004, at 17:30, Jose Rey wrote:
Dave, Magnus
--cut--
As I said in my previous email, registering under 'text' top level type would mean that the modifiers cannot be used.
why is that true? does text/* only admit of plain text? so, for example, text/html would not be permitted either??
This is what I understand from the slides from Colin presented during the meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip, "09-RTP-Media-Types.pdf"). Specially slide three where it says:
". In particular, it is expected that text media types are "to some extent readable even without the software that interprets them" - RFC 2046 - This rule is derived from email client behaviour; want to pass the message to a dumb pager if there's no better display option"
Colin or Magnus may please correct me if I got it wrong...
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". -- Colin Perkins http://csperkins.org/
-----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Friday, August 13, 2004 12:22 PM To: Jose Rey Cc: Magnus Westerlund; Dave Singer; IETF AVT WG; ietf-types@iana.org Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
On 12 Aug 2004, at 17:30, Jose Rey wrote:
Dave, Magnus
--cut--
As I said in my previous email, registering under 'text' top level type would mean that the modifiers cannot be used.
why is that true? does text/* only admit of plain text? so, for example, text/html would not be permitted either??
This is what I understand from the slides from Colin presented during the meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip, "09-RTP-Media-Types.pdf"). Specially slide three where it says:
". In particular, it is expected that text media types are "to some extent readable even without the software that interprets them" - RFC 2046 - This rule is derived from email client behaviour; want to pass the message to a dumb pager if there's no better display option"
Colin or Magnus may please correct me if I got it wrong...
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, Thanks, Jose
-- Colin Perkins http://csperkins.org/
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
participants (3)
-
Colin Perkins -
Dave Singer -
Jose Rey