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

[Colin Perkins <csp at csperkins.org>]

José,

On 25 Oct 2004, at 09:32, Rey Jose wrote:
> 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 <ietf-types at iana.org> mailing list on September  
> 13th).
>
> So I'd like to ask for  WGLC.

This draft is clearly not ready for working group last call. There are  
some significant editorial and document quality issues that obviously  
need to be addressed, along with a number of technical problems.

The editorial issues relate primarily to document structuring and  
clarity of explanation. The draft is difficult to follow, confusing  
introductory material with the payload format specification, and badly  
structured. You should start with an introduction, then move onto  
background, requirements and design rationale, then terminology, then  
the payload format and rules for packetization, fragmentation, etc.

You need to write a simple introduction that briefly describes the  
purpose of the document, introduces the 3GPP timed text format, and  
outlines how the remainder of the document is structured. This could  
comprise the first two paragraphs of the current section 2 and much of  
section 2.1, followed by an outline of the remainder of the document.  
This will be section 1 of the revised draft.

Create a new background, design rationale and requirements section.  
This will probably have much of the text from the current section 2.1  
and 2.2, and should form section 2 of the revised draft.

Review section 2.3 of the current draft, splitting it into text which  
is background and design rationale, and that which specifies behaviour.  
The text specifying behaviour should go into the payload format  
specification section (much of the current section 2.3.3 to 2.3.6 is  
specification, not background, since it places normative requirements  
on implementations). Moving this text into the payload format  
specification may require you to restructure that section, either  
splitting it or adding new subsections.

Move the terminology section later in the document, to form section 3  
of the revised draft.

Make sure all figures are numbered and have appropriate captions, and  
are cross-referenced by figure number. Ensure that figures are not  
split across page boundaries.

I believe these are the minimum set of changes needed to bring the  
document structure into line, and to make it understandable to readers.

Moving onto the technical issues, I recommend you add two new sections  
to explain how this draft relates to RFC 2793 and to RFC 3640.

In section 2.2, requirement 1 is to keep the 3GP text sample structure.  
This is justified by stating that a receiver SHALL be able to rebuild  
the text samples from the received RTP packets. I agree that rebuilding  
the text samples is an appropriate goal, but don't see why this  
requires the payload format to keep the 3GP text sample structure? We  
have other payload formats that modify the data format to optimise  
media transport, but allow reconstruction of the original data.

In section 2.2, requirement 3 states that it may be more appropriate to  
send large sample descriptions in-band. What is the justification for  
this? In-band transmission would seem inappropriate for large  
descriptions, since they're more likely to be affected by packet loss  
than smaller descriptions that fit into a single packet.

Section 2.3.3 (second bullet point on page 9) ends with "explained  
further in this document", but doesn't say where. In this, and all  
other similar cases, please give explicit cross-references to section  
or figure numbers.

Section 2.3.3 (last bullet point on page 9) mentions that "it does not  
seem reasonable to include such additional headers". What headers are  
these? The text preceding talks about intelligent fragmentation, but  
it's not clear that this needs extra headers.

Section 2.3.4 specifies how packets are formed from samples and  
modifiers. The rules listed in the numbered list at the start of the  
sections allow empty packets, but the preceding text specifies that at  
least one unit of data must be included. Which is correct?

The first observation in section 2.3.4 (near the end of page 10) states  
that type 5 units may be placed anywhere in the aggregate, and SHALL  
NOT be regarded for calculating the timestamp (indeed, they MUST be  
ignored when calculating the timestamp). The numbered rules for  
aggregate payload earlier in the section allow a packet that comprises  
only a type 5 unit. What is the RTP timestamp for such a packet, given  
that type 5 units MUST be ignored when calculating timestamps?

Figure 1 is unclear, please add a key explaining what is being shown,  
and explaining the labels. What are these particular examples chosen?

An unnumbered figure is split across the end of page 11 and the start  
of page 12. It's not clear if this relates to the text immediately  
before it ("For illustrative purposes, three different...") or that  
following. Please label the figure, and clarify from where it's  
referenced.

Section 2.3.5 talks about the TOTAL and THIS fields, which have not  
been defined. This discussion needs to be moved to after the  
specification of TYPE 2, 3 and 4 headers, where these fields are  
defined.

Section 3 starts with an unnumbered figure, which needs a figure number  
and caption. This shows an RTP packet without payload header which is  
confusing  since Figure 2 (in section 3.1) shows the presence of the  
payload header. I suggest moving Figure 2 to the start of section 3,  
rather than having near duplicates of the packet diagram.

Section 3 again notes that TYPE 5 units do not make use of the  
timestamp. All RTP packets need a valid timestamp; if only TYPE 5 units  
are included, what value does it take?

Section 3 notes that the RTP timestamp rate is the value of the  
"timescale" parameter in the Media Header Box. Because the timestamp  
rate affects the synchronisation accuracy and RTCP statistics, I think  
this draft needs to give guidance on how that parameter is chosen when  
the file is constructed.

Section 3 notes that "Other timestamp clockrates MAY be used" but  
doesn't give guidance on what are appropriate other rates. Suggest  
adding some text to explain that the typical use is to match the 3GPP  
timed text clock rate to that used by an associated audio or video  
stream, not to use some arbitrary value.

Section 3 (last paragraph on page 15) states that "no default sample  
size of sampling rate is defined for timed text". Four paragraphs  
earlier the draft states "A default value of 1000 Hz is RECOMMENDED"  
for the timestamp. Which is correct?

Section 3.1 repeats the payload header format in Figures 2, 3 and 5,  
with minor differences. A single copy is sufficient.

Section 3.1 talks about improving interoperability with RFC 3640, but  
doesn't explain how or why this is desirable. Suggest moving this to  
the new section on the "Relation to RFC 3640".

In Section 3.1.1, note that the 16 bit LEN field is in network byte  
order.

Section 3.1.2 (first bullet point) says "U, R and TYPE as defined  
above", but doesn't say where above. It also doesn't mention LEN.

Section 3.1.2, second bullet, third paragraph mentions that transport  
of sample descriptions out of band is "MANDATORY". This is not the  
right place to specify that - it confuses signalling with the details  
of the packet format. The capitalised term "MANDATORY" is not defined  
anywhere.

Section 3.1.2 (first paragraph on page 21) states that a maximum of 64  
dynamic SIDX are allowed at any moment, but allows a range of 0-127.  
Suggest either allowing 127 active values, or reducing the allowable  
range, or adding an explanatory note to clarify.

In Section 3.1.2, SDUR has 3 bytes, since two bytes gives limited  
maximum duration. This will be true no matter what: is it appropriate  
to place a fixed maximum? Or to define a way in which event duration  
can be extended by a following packet to allow unlimited duration  
events?

Section 3.1.2 has an "example that illustrates how units of unknown  
duration MUST be presented". If there's a rule, it need to be defined  
explicitly, not by a single example.

Section 3.1.2 (top of page 22) says that "sample of unknown duration  
SHALL NOT use features, such as scrolling or karaoke, which  
require...". This is not sufficient: need a complete list of  
exclusions, otherwise there's the potential for confusion.

Section 3.1.2 (top of page 22) says that only TYPE 5 units can follow  
units of unknown duration otherwise it's not possible to calculate the  
timestamp. Which timestamp does that refer to? The RTP timestamp of the  
packet or that (implied) for the following unit? Please clarify.

Section 3.1.2 (last two bullets) explains that the TLEN is needed by  
the decoder to know where the modifiers in the payload start. It's not  
clear what this means: does the text string include modifier boxes? I  
thought TYPE 1 units transported text samples only, and that any  
modifiers would be part of a TYPE 5 unit later?

Similar comment for section 3.1.3, where SLEN indicates the size of the  
text string plus any modifier boxes. From the description earlier, it  
can be read that there are no modifiers and only text here?

These lead to a bigger question: lease clarify the contents of the  
payload. Is it a single logical block, with the headers giving pointers  
to sub-parts of the block? Or is it multiple logical blocks (some text,  
some modifiers) stacked after the headers in order?

Section 3.1.3 states that LEN MUST be greater than 9. What is the  
response to a packet where LEN <= 9? (similar comments apply for  
section 3.1.4, 3.1.5 and 3.1.6)

Section 3.1.3 what should a receiver do if it receives fragments with  
differing SLEN values?

Sections 3.1.3, 3.1.4 and 3.1.5, what should a receiver do if it  
receives units where THIS > TOTAL? Or if TOTAL = 0?

Please add some examples of complete RTP packets and their contents,  
for several combinations of unit types, including all the headers and  
data.

Section 6.1 (end of page 26) expand and reference "O/A exchange".

Section 7.1 states that a receiver MUST ignore any "unspecified"  
parameter. Can you clarify what this means? Did you intend to write  
"unrecognised"?

Section 7.1: the definition of the "rate" parameter duplicates that  
from section 3. Suggest referencing that definition, rather than trying  
to summarise it.

Section 7.1 defines a number of parameters as "16 bit integers" or as  
"16 bit unsigned integers". Does this mean that the parameters are in  
binary format? Or do you intend (as in the examples in section 8) that  
the decimal representation is used?

Section 8.1, last bullet point says that unknown parameters SHALL be  
ignored. Does this mean that they're not copied into the SDP (i.e.  
ignored by the device generating the SDP)? Or are they copied, but  
ignored by the device that later uses the SDP? Please clarify.

--
Colin Perkins
http://csperkins.org/


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt