Subject: [AVT] Comments on draft-rey-avt-3gpp-timed-text-02.txtU

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Feb 2004 18:30:43 +0100

Hi Jose,

Here is a number of comments on your draft. I like this much more than 
the previous proposal.

1. In the next update don't forget to update all the boilerplate for IPR 
and copyright according to RFC 3667 and 3668.

2. Abstract: "3GPP timed
    text is time-lined decorated text media format whose defined storage
    format is the ISO (International Standardisation Organisation) Base
    Media File Format."

This is not correct. the 3GPP Timed text is stored in the 3GP file 
format, which is based on the ISO Base Media File Format.

3. section 2, second paragraph: "3GPP timed text is a 3GP file format 
for time-lined decorated text specified in [1]." I would say that "3GPP 
Timed Text is a media format for time-lined decorated text, with a 
defined storage in the 3GP file format."

4. Section 2.1, bullet 3: "This is especially useful for live streaming 
(where the contents are not known a priori) or to protect this 
information through other mechanisms like FEC [4] or retransmission 
[13]." The second part of the sentence is not correct. The possibility 
to protect the important sample descriptions are not a reason for having 
in-band sample descriptions. So please split it out, as FEC and 
retransmission is means to make it work.

5. Section 3, first bullet. "A text sample contains a text length 
indication, a text string, and zero or several modifier boxes (the 
decoration of the text)." Is not "zero or more" a better term, or is it 
impossible to have only one modifier box?

6. Section 3, bullet list. Please adjust the formatting, having the 
lines after the first be adjusted further in so the "-" mark i alone at 
the left makes it more clear that it is a bullet list.

7. Section 3, second bullet: "A fragment may either text strings and 
modifiers or just one of these." This sentence is very strange.

8. Section 4, Marker bit: The current definition is unclear if one only 
has a single complete text sample, should one have the marker bit set or 
not.

9. Section 4, Timestamp: By putting the word "earliest" in the first 
sentence of the timestamp paragraph, you will not have to redefine the 
initial meaning a few lines down and it fits both single and multi 
sample cases. I would also think about using normative SHALL or MUST in 
the definition to make readers aware of that this is something important 
to follow.

10. Section 4, Timestamp: "The value timestamp clockrate is copied 
directly from the 3GP file: the value of "timescale" in the Media Header 
Box is to be used." Is this a SHALL or SHOULD? With the RTP payload it 
will be possible to create 3GPP Timed text without ever storing it 
first. Therefore I think that some general guidance on timestamp rates 
should be written. Also, is the clock rate in the 3GP file fixed or can 
it be different between different files.

11. Section 4.1: "It appears more appropriate to encode text samples 
without taking the path MTU into account." I think that it most 
applications is will be rather easy to ensure that created samples are 
not to big.

12. section 4.1, Third bullet: "- it is RECOMMENDED to include as fewer 
text sample fragments as possible in an RTP packet." First the language 
is wrong "few" instead of "fewer". Secondly, should one really include 
multiple fragments in a RTP packet. Isn't it much better to ensure that 
one does not fragment.

13. Section 4.2: It is not clear if the payload are formed: header 
header data data, or header data header data. could you please clarify.

14. Section 4.2, the payload header? Is there a reason why the reserved 
bits are left most in the first byte? Otherwise I would recommend them 
to be placed between UL and TYPE. That way the bits could in the future 
either be used to extend the TYPE field or for more indication bits.

15. Section 4.2, L definition. "By default this flag is reset." I guess 
that reset is having the bit take the value of 0. Please define reset if 
you are going to use it.

16. Section 4.2, The L bit. Is is really worth having the length field 
as a variable field. It will be needed in all cases except when only a 
single data unit is in a packet. Thus I don't think the overhead from 
these two bytes are in anyway excessive. The number of RTP packets from 
timed text are rather few. In a subtitling usage, their is only a single 
new sample every few seconds. I think simplicity is an advantage here.

17. Section 4.2, SIDX: "To allow SIDX wrap-up, clients SHALL keep as 
valid only those values of SIDX outside of the interval (X+128) modulo 
255, where X is the last SIDX value received." I think you need to 
specify it as an interval not a single value which (X+128) modulo 255 
are. I think you should define this as a client shall only use the 
sample entries that are (X-127)..(X) modulo 255.

18. Section 4.2, SDUR: "However, samples of unknown duration MAY precede 
sample descriptions, as they have no duration." I think duration is the 
wrong word here. Sample descriptions is lacking timing information. They 
are simply sent out and exist.

19. Section 4.2: I think that making each type format its own 
sub-chapter and giving the name would increase the readability.

20. section 4.2: Type=2: If you make the Len field permanent I think the 
SDUR field should be shifted left one byte, the SLEN moved to the end 
and the TOTAL|This byte precede the SDUR field, that way one allows for 
easier processing of the fields on a 32 bit machine.

21. Section 4. type 2, TOTAL and THIS. I think the rules for how one can 
send fragments in relation to other packets needs to be clarified. In 
general I think the fragmentation concept could be explained on a more 
general level. The concept of having different types for splitting text 
and modifiers and that different rules apply could be explained prior to 
defining the boxes.

22. section 8. Please add an statement that unknown parameters SHALL be 
ignored. That way there is some chance of extending the format in a 
predictable way in the future.

23. Section 8. The reference to the timed text specification. Are you 
referring to the release 5 or release 6. As the release 6 is not yet 
frozen, how is the intended timing between the payload format and the 
timed text specification for release 6?

24. Section 9. You have two definitions of how the parameters intended 
for the "a=fmtp" line shall be mapped. Ether you keep the two line 
stating "the REQUIRED .." and "The OPTIONAL", or you use only the 
following line.

25. Section 9.1, the mapping of the clockrate is unclear. It does not 
state exactly to what the 3GP file formats "timescale" value shall be 
copied to. Also must this really be done, one could translate all times 
if desired.

26. Section 9. Missing Offer Answer section.

27. Section 11. Please write the IANA section as a statement what IANA 
must do. In this case it seems appropriate to write. "IANA is request to 
register one MIME type (3GPP-tt) as defined by section 8."

28. Section 12. Are there any data in the 3GPP timed text media format 
that can be introduced that would result in significant higher 
processing requirements for a receiver, thus enabling DOS attacks?

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt