Hi Thanks for the answer.
-----Original Message----- From: Martin Duerst [mailto:duerst@w3.org] Sent: Friday, October 08, 2004 7:05 AM To: Rey Jose; IETF-Types Cc: Colin Perkins Subject: RE: Registration of media type text/3gpp-tt
Quickly looking at this, I see that it deals with text, but there is no mention about how this text is encoded.
Text is encoded using UTF-8 or UTF-16. But there is not only text in the payload; there is also modifiers, which are binary. Modifiers are information pieces that allow, e.g., to make karaoke. As I understand from draft-freed-media-type-reg-01 the "Encoding Considerations"section only takes a value. In this case I think "binary" is appropriate since both UTF-8/-16s strings and the binary modifiers are mixed in the payload. I don't think it is needed to explain this again in the registration since a client accepting this media type already knows this. Looking forward to your comments, Jose
This is usually (but not always!) a sign that something may have been overlooked.
Regards, Martin.
At 10:27 04/10/07 +0200, Rey Jose wrote:
Hello,
It is more than 2 weeks since I sent this in for
consideration. Could
you please inform me about the status? I would like to proceed ASAP with WGLC in AVT but cannot without passing this review.
Thanks,
Jos・
-----Original Message----- From: Jose Rey [mailto:rey@panasonic.de] Sent: Monday, September 13, 2004 10:30 AM To: IETF-Types Cc: Yoshinori Matsui; Dave Singer; Jan van der Meer; Colin Perkins; Magnus Westerlund (KI/EAB) Subject: Registration of media type text/3gpp-tt
Hello,
please consider the following media type text/3gpp-tt for registration under the IETF tree. This section is copied from the draft http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-ti med-text-06.txt.
MIME type: text
MIME subtype: 3gpp-tt
Required parameters
rate: the RTP timestamp clockrate is equal to the clockrate of the media. If RTP packets are generated out of a 3GP file, the clockrate of the text media MUST be copied from the 3GP file, i.e. the clockrate is the value of "timescale" parameter in the Media Header Box describing that text track. Other tracks (audio/video/text) in the 3GP file may have their own clockrates as indicated in their corresponding Media Header Box. For live encoding, a clockrate of 1000 Hz is RECOMMENDED but other values MAY be used. If a different timestamp rate value is used, this MUST be chosen carefully as per Section 3 in RFCXXXX.
sver: The parameter "sver" contains a list of supported backwards-compatible versions of the timed text format specification (3GPP TS 26.245) that the sender accepts to receive (and which are the same that it would be willing to send). The first value is the value preferred to be received ( or preferred to send). The first value MAY be followed by a comma-separated list of versions that SHOULD be used as alternatives. The order is meaningful, being first the most preferred and last the least preferred. Each entry has the format Zi(xi*256+yi), where "Zi" is the number of the Release, "xi" and "yi" are taken from the 3GPP specification version, i.e. vZi.xi.yi. For example, for 3GPP TS 26.245 v6.0.0, Zi(xi*256+yi)=6(0), the version value is "60". (Note that "60" is the concatenation of the values Zi=6 and (xi*256+yi)=0 and not its product.)
width: This parameter indicates the width in pixels of the text track or area of the text being sent. This is a 16 bit integer.
height: This parameter indicates the height in pixels of the text track being sent. This is a 16 bit integer.
max-w: This parameter indicates display capabilities. This is the maximum "width" value that the sender of this parameter supports. This is a 16 bit unsigned integer.
max-h: This parameter indicates display capabilities. This is the maximum "height" value that the sender of this parameter supports. This is a 16 bit unsigned integer.
tx: This parameter indicates the horizontal translation offset in pixels of the text track with respect to the origin of the video track. This is a 16 bit integer.
ty: This parameter indicates the vertical translation offset in pixels of the text track with respect to the origin of the video track. This is a 16 bit integer.
layer: This parameter indicates the proximity of the text track to the viewer. More negative values mean closer to the viewer. This parameter has no units. This is a 16 bit integer.
Optional parameters:
tx3g: This parameter MUST be used for conveying sample descriptions out-of-band. It contains a comma-separated list of base64-encoded entries. The entries of this list that MAY follow any particular order and the list MAY be empty. The absence of this parameter is equivalent to an empty list of sample descriptions. Each entry is the result of running base64 encoding over the concatenation of the SIDX and the sample description for that SIDX, in this order. The format of a sample description entry can be found in 3GPP TS 26.245 Release 6 and later releases. All servers and clients MUST understand this parameter and MUST be capable of using the sample description(s) contained in it. Please refer to RFC 3548 [6] for details on the base64 encoding.
Encoding considerations:
RTP payloads complying with this payload format contain binary data.
Note that this type is incompatible with the use of text media types in other protocols, e.g. text/html. This is because in order to extract and decode any of the timed text media it is necessary understand the (binary) payload headers defined in RFCXXXX.
Restrictions on usage:
This type is only defined for transfer via RTP.
Security considerations:
Please refer to Section 10 of RFCXXXX.
Interoperability considerations:
The 3GPP Timed Text media format for which this payload format is defined is specified in Release 6 of 3GPP TS 26.245 "Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6)". The 3GPP file format (3GP) and the SMIL language profile used can be found in Release 5 of 3GPP TS 26.234 and in the corresponding specifications for later Releases. Note also that 3GPP may in future Releases specify extensions or updates to the media format in a backwards- compatible way, e.g. new modifier boxes or extensions to the sample descriptions. The payload format defined in RFCXXXX
Rey & Matsui [Page 29]
Internet Draft Payload Format for 3GPP Timed Text September 10, 2004
allows for such extensions. For future 3GPP Releases of the Timed Text Format, the parameter "sver" is used to identify the exact specification used.
Published specification: RFC XXXX
Applications which use this media type:
Multimedia streaming applications.
Additional information:
the 3GPP Timed Text media format is specified in 3GPP TS 26.245 "Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6)". This document and future extensions to the 3GPP Timed Text format are publicly available at http://www.3gpp.org.
Magic number(s): None.
File extension(s): None.
Macintosh File Type Code(s): None.
Person & email address to contact for further information:
Jose Rey, rey@panasonic.de Yoshinori Matsui, matsui.yoshinori@jp.panasonic.com Audio/Video Transport Working Group.
Intended usage: COMMON
Author/Change controller:
Jose Rey Yoshinori Matsui IETF AVT WG
Thank,
--------------------------------- Jose Rey Mobile Multimedia Team Panasonic R&D Center Germany GmbH D-63225 Langen, Germany Tel.:+49-6103-766-134 Fax :+49-6103-766-166 Email: rey@panasonic.de Web: www.prdcg.panasonic.de ---------------------------------