Subject: [AVT] Comments on draft-ietf-avt-rtp-vc1-01

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Nov 2005 15:53:54 +0100

Hi Anders,

I have some comments on the VC1 payload format.

Technical

T1. Section 3.4, Figure 1: Could you please expand the list of frames so 
that P5 is included also in the capture order. Because I suspect that P5 
is not at all P5 but rather should be called P7 or so.

T2. Section 4.3: The concept of decode time is not well explained. 
Please elaborate on this.

T3. The MIME parameters "level", "width", "height" and "framerate.

I think these parameters need to be split into two different parameters. 
One set that defines receiver capabilities that allows the receiver to 
indicate in an offer/answer exchange the capabilities that is not 
possible to exceed by this receiver. Then there should be another set of 
parameters for actual out-of-band configuration. That set could be 
replaced to any value within the capabilities of the receiver.

T4. Section 5.1: This section seems to be missing the definition on how 
the sequence number is used. To my understanding this is used to recover 
coded order it decoding timestamps are not used. Secondly it is also 
used by the fragmentation mechanism to determine the order of fragments 
and to ensure that no fragment is missing.

T5. Section 6.1, Config parameter. Why isn't base64 used instead of 
base16 as it will encode 2 bits more per character.

T6. I am missing an offer/answer section.

Editorial

E1. I can't say that it wrong, only unusual to divide the front page 
into IPR Notice and Status of this memo. Usually the IPR Notice is part 
of the Status of this memo section.'

E2. In the status of this memo section there is the following sentence:
"Distribution of this document is unlimited."

This is not commonly done as the copyright boiler plate is intended to 
give IETF all the rights it need, while you as an author maintain the 
rest of the rights. But if you are willing to make further statements 
you are free to do them.

E3. All your heading numbering has become strange, the number and the 
actual heading ends up on different lines. Please try to address these 
issues for better readability. It also seem to effect the page lengths.

E4. I spotted some places where it says "a RTP" where we usually say "an 
RTP"

E5. Section 5.2, first paragraph: Figure 4 reference has been moved an 
extra line.

E6. Section 6.1, Please add an reference to 
draft-freed-media-type-reg-05 and RFC 3555 for the rules this 
registration is done under.

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]

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

---

From: Dave Singer <[email-masked]>
Date: Mon, 7 Nov 2005 10:32:00 -0800

I have not updated these for this meeting nor asked for agenda time. 
I thank Colin for his feedback, which was mostly questions of detail, 
boilerplate, and so on.  Before I go on to deal with these I wanted 
to check whether people weren't commenting because

it isn't relevant to you so you haven't read them
it seems fine
you haven't got to it yet
some other reason

if you were expecting to read them and/or comment but have not yet, 
can you let me know?  Otherwise I will do the updates based on the 
presumption that, for those who care/know, they seem mostly fine.

Thanks, have a great meeting
-- 
David Singer
Apple Computer/QuickTime

---

From: Colin Perkins <[email-masked]>
Date: Fri, 11 Nov 2005 08:13:30 -0800

On 7 Nov 2005, at 06:53, Magnus Westerlund wrote:
> T1. Section 3.4, Figure 1: Could you please expand the list of  
> frames so that P5 is included also in the capture order. Because I  
> suspect that P5 is not at all P5 but rather should be called P7 or so.
>
> I think these parameters need to be split into two different  
> parameters. One set that defines receiver capabilities that allows  
> the receiver to indicate in an offer/answer exchange the  
> capabilities that is not possible to exceed by this receiver. Then  
> there should be another set of parameters for actual out-of-band  
> configuration. That set could be replaced to any value within the  
> capabilities of the receiver.

It would be good to be consistent with RFC 4175 here.

Colin