[xiph-rtp] [csp@csperkins.org: Re: [AVT] rtp-vorbis and rtp-theora available]

[Ralph Giles]

Forwarding Colin's remarks on the draft spec from the avt list for 
reference. Original is:

  http://www1.ietf.org/mail-archive/web/avt/current/msg07306.html


----- Forwarded message from Colin Perkins <csp at csperkins.org> -----

From: Colin Perkins <csp at csperkins.org>
Subject: Re: [AVT] rtp-vorbis and rtp-theora available

Luca,

[Apologies for the extremely slow response]

On 2 Mar 2006, at 17:50, Luca Barbato wrote:
>The new drafts are available in the ftp
>
>http://www.ietf.org/internet-drafts/draft-barbato-avt-rtp- 
>theora-00.txt
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-00.txt
>
>I tried to address most of the issue risen in the last meeting and
>overall clean up wording and format.
>
>Please review and comment on this new revision

I think these drafts are on the right lines, and I would encourage  
the Vorbis and Theora communities to work to complete them. I believe  
both drafts could be ready for RFC publication with only relatively  
minor revisions.

Regarding the Vorbis draft, since that seems to be the most advanced,  
I think the basic technical approach is solid. I have a number of  
detailed comments on a mix of technical and editorial issues:

- Abstract: it is preferable to avoid the term MIME, since the media  
type registry is not used exclusively for email. I suggest rewording  
the second paragraph: "Also included within this memo are media type  
registrations, and the details necessary for the use of Vorbis with  
the Session Description Protocol (SDP)."

- Section 2.2: an explicit statement that each RTP packet can only  
contain a single type of Vorbis payload would be useful for clarity.

- Section 2.3: clarify that the "length" field is in network byte  
order, and is in units of bytes. Similarly, clarify the byte order  
for the "Ident" field.

- Section 3.1.1 states that "A Vorbis Packed Configuration is  
indicated with the payload type field set to 1". Should it be the  
"Vorbis Data Type" that is set to 1? The current text could be  
confused with the RTP payload type.

- Section 3.2.1.1: the media type registration should be moved to  
section 6 with the other IANA considerations, otherwise it might be  
missed. Also, please update the registration template following RFC  
4288 section 10.

- Section 3.3: I'm unclear what is meant by the last paragraph of  
this section. Is the intent that an RTCP packet is sent early, rather  
than following the usual RTCP timing rules? If so, a reference to RFC  
4585 must be made and the RTP/AVPF profile negotiated during session  
setup. If the intent is that the standard RTCP rules are followed,  
then I recommend removing the text about RTCP here, since it confuses.

- Section 4: should this be "Vorbis Data Type" rather than "payload  
type"? [same issue as section 3.1.1]

- Section 5.2: I have similar concerns about RTCP use as with section  
3.3 of the draft. In particular, if normal RTCP rules are followed,  
implosion will be avoided, so the need to explicitly warn against  
this leads to concern that the RTCP packets are sent early, ignoring  
the RTCP timing rules in RFC 3550 and/or RFC 4585.

- Section 6: the clock rate ("rate") must be listed as a required  
parameter. You might also list "channels" as an optional parameter.

- Sections 6.1 and 6.2 should be moved out of IANA considerations,  
and into a separate section. The IANA has started to complain if this  
section contains things other than parameter registrations.

- Section 6.1.1: there is a typo at the end of the first paragraph.

- Section 6.1.1: clarify that the a=fmtp: line has been folded to fit  
the memo, but would be a single long line in the SDP message.

- References: is reference 16 used?

Regards,
Colin



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

----- End forwarded message -----