Subject: [AVT] Request for WG Last-Call for draft-ietf-avt-rtp-3gpp-timed-text-07.txt

From: "Rey Jose" <[email-masked]>
Date: Mon, 25 Oct 2004 10:32:10 +0200

Hi all,

The last update of this draft was published by the ID manager on October 8th:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-07.txt

Comments during and after the IETF have been incorporated into -06 (in -07 only editorial nits were corrected using the webtool) and sent to the list on September 10th.  No comments have followed. 

Additionally, the draft has already passed the 2-week review period by IETF-types (sent to <[email-masked]> mailing list on September 13th). 

So I'd like to ask for  WGLC.

Thanks,

José

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Oct 2004 18:03:02 +0200

Hi Jose,

I have reviewed the draft, and found some things that needs to be 
correct. However I think it is getting close.

1. Section 2.3.4: bullet 3:
"
           3. for PAYLOAD 3:

                         ts(#6)= ts(#7)= rtpsts2= rtpts3

           In this case rtpts3 must be equal to rtpts2 in order to be
           able to assign this fragment to the correct sample (TS4).
           Additionally, note that units 6 and 7 have the same timestamp
           since they belong to the same text sample (also TS4)."

I think this paragraph is hard to understand, and maybe even misleading. 
ts(#6) is equal to ts(#7) due to the rule that if type 2 and 3 are 
present in the same payload they must all have the same timestamp. The 
current second sentence gives the impression that due to that the TS are 
the same, they belong to the same sample, while the reason is the rule. 
I also think one should clarify that the values of SDUR are ignored in 
this case. I would recommend that the comment is totally rewritten.

2. Section 3:
"  Note that TYPE 5 units do not make use of the timestamp and therefore
    the above does not apply for this particular case."

I have two comments around this. First, there should be a clarification 
on how to set the RTP timestamp if one makes packets with only Type 5 
packets. I would recommend to set it according to the current TS value.

Secondly, I think some clarification on when Type 5 packets shall be 
assumed to become active. From the point they are received, when they 
are unpacked, i.e. order in the RTP packet may have some meaning, or 
when other packets type the type 5 was attached to is utilized. I think 
this has some impact, although the guard band for dynamic types normally 
would prevent it.

3. Section 3.1.1: Bullet about LEN:
    o Finally, the LEN (16 bits) "Length Field": indicates the size (in
      bytes) of this header field and all the fields following, i.e. the
      LEN field followed by the unit payload (text strings and
      modifiers, if any).

It might be beneficial to be clear to add a comment, that the only thing 
excluded from the LEN field is the U|R|Type byte first in the payload 
header.

4. Section 3.1.6:
"  The SIDX value is in the (inclusive) interval [0,127], as this unit
    contains a dynamic sample description."

It is not written explicitly that the SIDX value in a TYPE 5 payload is 
the SIDX value for that content. I would propose something like this:

"The SIDX value that is assigned to the sample description carried as 
sample content of this unit. As any sample description carried is a 
dynamic one, the possible SIDX values are in the (inclusive) 
interval[0,127]."

5. Section 12.1, I think should be moved into 3.1.6 as it contains 
normative language about the handling of dynamic sample descriptions.

6. Section 6.1, last paragraph: I think the SHALL is very unnecessary, I 
think a informative sentence is sufficient. What interoperability effect 
would occur, and what does help with the definition that appropriate 
values needs to be used.

7. Section 7.1: I think that a number of parameters are misclassified. 
Any parameter that do not need to be included in all messages belongs 
under Optional parameters. I think that include: max-w, max-h, width, 
and height. This also has effect in 8.1.

8. Section 7.1: I think there should be an appropriate reference to 
figure 5.1 in [1] for how the tx, ty, width, height parameters work.

9. Section 7.1: Author/Change controller section in the template. As the 
mime type belongs to IETF, the following split between author and change 
controller is appropriate:
"
Author:
	Jose Rey
	Yoshinori Matsui

Change Controller:
	IETF Audio/Video Transport working group delegated from the
         IESG.
"
The Change controller section is provided by Allison and originates from 
one of the APPS ADs.

10. Section 8.2, third paragraph:
   "As stated in the O/A model, some "fmtp" (payload-format-specific)
    parameters have a clear meaning and shall be included in the answer
    as present in the offer.  Other parameters may need to be set among
    parties, because it is not clear that offerer and answerer shall use
    the same values.  A third type of parameters may take different
    values for offerers and answerers."

This paragraph has several sentences of unclear wording:
First sentence, was is meant with "clear meaning". I think we usually 
call them symmetric, and that is due to that both end-point needs to use 
the same value for some reason.

Second sentence, what is meant with "set among parties"? It doesn't seem 
to be declarative (which is the third alternative), so what is special 
with these and what is the difference in relation to symmetric and 
declarative parameters?

11. Section 8.2.1, bullet 1, a, i: Should it also be added, that unless 
special preference exist the offered value should be used?

12. Section 8.2.1, bullet 2:
"2. Parameters describing the display capabilities, ..."
Which parameters are included in this category? Please be explicit about 
this.

13. Section 8.2.1, bullet 3, b: Please clarify that the tx3g applies in 
the offerers or answerers transmission direction.

14. Section 8.2.2: Last bullet: The usage of "sver" in multicast? Is it 
really possible to offer more than one version that all uses? Especially 
if the version result in that different parsing of the samples must be 
used, then one can really only offer one. Otherwise one needs to agree 
on the version used.

15. Section 8.3:
"In this case the answerer's "max-h" and
    "max-w" are compatible with the offerer's "height" and "width".
    Otherwise, the answerer would have to remove this stream and the
    answerer issue a new offer taking the answerer's capabilities into
    account."

I would like to make you aware that the offerer will not receive a 
payload type at all if the answerer has to refuse the stream due to that 
height and width are larger then the supported max-w and max-h. The only 
way to ensure that this would happened would be do define multiple 
payload types, with at least one that is guaranteed to be acceptable, 
thus allowing the answerer to give his max-w and max-h parameters. Then 
the offerer can re-issue the offerer with the knowledge about the 
answerers capability.

16. Section 8.4, second paragraph:
   "In this case, the receiver of a session description MUST support the
    parameters and given values for the streams or else it MUST reject
    the session."

I think one can without changing the sentence meaning replace the first 
MUST with "requires to"

17. Another "sver" related question, which i thought of in relation to 
the example of a Sendonly offer: What happens if the sample description 
format is version dependent? In that case you can't include the tx3g 
parameter until you have agreed on the version you are going to use. The 
resolution would to offer different versions using different payload types.

18. Section 12.1: The algorithm description. I have some problem with 
the current description. Bullet 3, has an IF without an clear argument. 
Also I think it fails to properly describe if the new X must be the next 
value or values above the current active set. Or if one is allowed to 
send an X=127 in a session that had the inactive set to be [64..127]?
Thus resulting in that the currently active set is completely inactivated.

19. Section 12.3:

         o the Decoding Time to Sample Box (stts): the 24 least
           significant bits of the "sample_delta" are mapped to the
           field SDUR (Text Sample Duration),

I think this is incorrectly stated, I think one should use as many bits 
as existing in the mapping to the SDUR value. Please consider that if 
one strictly takes the lower 24, values one can't scale in the mapping, 
or do ceiling value with the bits one have. Lets assume that one can 
only represent number with 3 digits, and SDUR would be 1023, then one 
could send this sample as one with SDUR=999 and another with 
TS=TS_org+999 and SDUR=24.

Editorial comments

E1. Where has all the page break markers gone?

E2. Section 2.3.4, Bullet 1, the note:
           "Note that no sdur value is assigned to TYPE 5
            units, and they are taken into account in the timestamp
            calculation."

Is there a missing "not"  ".. and they are taken into .."?

E3. Section 6.1, second paragraph: "O/A" do not abbreviate here.

E4. Section 7.1, tx3g: Please include a reference after the first 
reference to BASE64 encoding.

E5. Section 7.1, Additional information: The first sentence has lower 
case "the" in the first sentence.

E6. Section 8.2, third paragraph:
"<directionality> may take the values sendrecv, sendonly andrecvonly." 
missing space between "and" and "recvonly".

E7. Section 8.2.1, bullet 1, second sentence: Unclear what "they" refer 
to, please write out "The offerer or answerer".

E8. Section 8.3: "Note also that the answerer's text box dimensions fit 
.." Shouldn't text box be text track in this sentence?

E9. Section 11: Ref [1] exist in 6.0.0 version. Also [16] is available 
in rel 6 if that is desired to be used as ref instead of the REL5 version.

If there is any unclarities about my comments, simply ask about it.

Cheers

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]