Subject: [AVT] Comments on draft-ietf-avt-rtp-3gpp-timed-text-08.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 13 Jan 2005 15:23:38 +0100

Hi Jose,

I have now reviewed the draft and it really looks great. I have a few 
minor issues that I would hope you resolve before we do a WG last call.

1) section 2.4, bullet 4:
"if the size cannot be expressed as an (unsigned) 16-bit integer SHALL 
NOT be conveyed."

This sentence seems to be missing a word. May I suggest that you change 
this sentence to:

"if the size cannot be expressed as an (unsigned) 16-bit integer, the 
sample description SHALL NOT be conveyed."

2) Section 3: Text sample definition, second paragraph: The last three 
words in the paragraph does appear to be garbage.

3) Section 4.1.1: Type field:
"The receiver SHALL ignore packets with unrecognized TYPE value."

I think the word "packet" shall be replaced with "unit". If we ignore 
the unit, the rest of the packet can be used. Thus allowing extensions 
like the one the MPEG people asked for. However it might be necessary to 
add something in the processing of TS about ignoring these.

4) Section 4.1.2, page 16, third paragraph:
"A maximum of 64 dynamic active SIDX values is allowed at any moment."

I think one should add the word "simultaneously" into the sentence:

"A maximum of 64 dynamic simultaneously active SIDX values is allowed at 
any moment."

5) Section 4.1.3, Please use the same text for defining U, R; TYPE and 
SIDX and SDUR as in the other. This formulation is not clear.

Proposal:
"  o U, R and TYPE as defined in Section 4.1.1.

    o SIDX and SDUR as defined in Section 4.1.2.
"

6) Section 4.1.3, LEN definition:
"Hence, as a minimum, a text fragment MUST contain one
      character in either UTF-8 or UTF-16."

I think the construction with the minimum is not 100% clear. I think 
this can be improved by adding a "at least" into the sentence:

Hence, as a minimum, a text fragment MUST contain at least one
      character in either UTF-8 or UTF-16."

7) Section 4.1.3, Page 19, the example:
"Several constraints may come in this scenario into place, for example:"

Something is wrong in this sentence.

8) Section 4.1.6.1, the algorithm on page 24:

I think this algorithm is wrong, because you can move the active box 
backwards by sending a pattern like: 1, 2, 4, 3 which would inactive 4 
after 3 has been received. I think the algorithm should be redefined so 
that it first check if any received SIDX is within the active range, 
independently if it has been received before or is new and becomes active.

9) Section 4.1.6.1, page 24, Example: This example contains an normative 
definition. Please move that normative definition, for example into the 
algorithm.

10) Section 4.2, the section title. Can remove "Extension mechanisms"?

11) Section 4.2, The SIDX algorithm. I can't understand how it would be 
required to use the algorithm you suggest. As long as a sender ensures 
that the receiver will have all sample descriptions when he has them, 
there is no need for a normative algorithm that I am not convinced will 
work. If you have a usage of sample descriptions that goes back and 
forth in the value field. Lets for example say that you have series that 
according to your algorithm contains the following usage of SIDXs: 4, 
97, 4, 98, 97, 4, 97. To avoid emptying and needing to retransmit the 
sample descriptions you could instead do intelligent renumbering.

12) Section 4.5, page 31, second bullet:
"    Note that, in this special case,
      no timestamp calculation is needed.  I.e., the RTP timestamp of
      both units represents the display time."

It seems that this sentence is not clear, as it not correctly explain 
how you can arrive at the timestamp without calculations. Proposal for 
rewording:

"Note that, in this special case, no timestamp calculation is needed. 
I.e., the RTP timestamp of both units is equal to the timestamp in the 
packet's RTP header."

13) Section 4.5: I am missing a note that explain how to achieve a 
aggregated type 1 packet that contains samples that are not consecutive, 
i.e. TS1+SDUR1 < TS2. Although it is quite simple to include an extra 
Type 1 unit with no sample, but a SDUR2 field that are equal to 
TS2-(TS1+SDUR1).

14) Section 5: Last sentence in section:

I don't think that you should recommend usage of both repetition and all 
the other methods. I suggest to change the SHOULD to a MAY or could.

15) Section 6. Sentence 2 and 3 are in error. The current profiles are 
not mandating congestion control due to it considered to be used also on 
tightly managed networks where congestion is addressed in other ways 
then monitoring. Also it do not define a method that is deemed TCP 
friendly by the larger IETF community. I would avoid this type of 
statement and instead discuss how one can regulate the bandwidth when 
using the payload format. The important factors should be the 
improvement possible with aggregation and the dangers with the resilient 
mechanism, especially repetition that increases bandwidth and thus need 
to be included in any bit-rate budget to not cause congestion.

16) Section 8.1, tx3g:
The definition of the data field does not sufficiently define in what 
format the SIDX field that are concatenated is to be in. Proposal:
"Each entry is the result of running base64 encoding over the 
concatenation of the (static) SIDX value as 8-bit unsigned integer and 
the (static) sample description for that SIDX, in this order."

17. Section 8.1: Additional information:
I think one can clarify also in the registration that the 3GPP timed 
text format is stored in 3GPP files. Thus I would suggest to add "and 
its storage" into the first sentence like this:

"The 3GPP Timed Text media format and it storage is specified in 3GPP TS 
26.245 "Transparent end-to-end packet switched streaming service (PSS); 
         Timed Text Format (Release 6)".

18) Section 8.1, Change Controller:
Please change it to:
"IETF Audio/Video Transport Working Group delegated from the IESG."

19) Section 9.3, first example text:
"Note also that the answerer's text
    box dimensions fit within the within the maximum values signaled in
    the offer."

As you can see there is two "within the" in this sentence. Please address.

20) Section 12, ref 16: Version 6.2 is available.

So I hope for a quick addressing of these issues so that we can proceed 
to a WG last call.

Cheers

Magnus

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