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

[Jose Rey]

Hi Colin, all,

Dave and I have been discussing this offline and come to the following
conclusions:

1.- it is not envisioned that the 3GPP Timed Text payload format will be
used for applications such as instant messaging or text conversation, which
do not precise of text decoration for working properly, since there are
other more appropriate media types covering these usages, like text/t140.
Hence,  video/ is enough.

2.- we are not clear on what exactly means to "relax rules for media
registration under text/".  I.e. is text/t140 an example of these "relaxed"
rules or does it comply with the traditional rules as per rfc 2046?  Does
the relaxed rules just mean that besides text also payload headers of that
media type are udnerstood?

We would appreciate your feedback,

Jose



> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]On Behalf Of
> Jose Rey
> Sent: Monday, August 16, 2004 5:39 PM
> To: Dave Singer; Colin Perkins
> Cc: Magnus Westerlund; IETF AVT WG
> Subject: RE: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMediaTypes)
>
>
>
> Dave, Colin,
>
> --cut--
> > >
> > >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.
>
> As Colin said, for limited domains of applicability you can also register
> under text/, without complying with the traditional rules:
>
> "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"."
>
>
> >  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.
>
> Therefore I don't think this is the criteria to judge text/ it appropriate
> or not, but rather whether there are differentiated domains of
> applicability
> for which the timed text format can be used. In my previous email
> I tried to
> classify intuitively in those that need just text and the ones that need
> text AND video.
>
> The answer to this different question might as well be no ;), but
> I had the
> feeling we talked past each other.
>
> Cheers,
>
> Jose
>
> PS: Colin, would RTP payload headers be part of the "software that
> understands it"?)
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>