Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-03.txt

From: [email-masked]
Date: Wed, 18 Apr 2007 18:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for Vorbis Encoded Audio
	Author(s)	: L. Barbato
	Filename	: draft-ietf-avt-rtp-vorbis-03.txt
	Pages		: 25
	Date		: 2007-4-18
	
This document describes an RTP payload format for transporting Vorbis
   encoded audio.  It details the RTP encapsulation mechanism for raw
   Vorbis data and details the delivery mechanisms for the decoder
   probability model, referred to as a codebook and other setup
   information.

   Also included within this memo are media type registrations, and the
   details necessary for the use of Vorbis with the Session Description
   Protocol (SDP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-rtp-vorbis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-vorbis-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Mon, 30 Apr 2007 23:38:00 +0100

Hi Luca,

> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-03.txt

I just reviewed this draft in detail, with the aim of getting it  
ready for publication, and found a some more issues:

Section 2.1 (timestamp): "...conveyed out-of-band as a SDP  
parameter." -> "...conveyed out-of-band (e.g. as an SDP parameter)."

Section 2.2 (last paragraph): I suggest clarifying that "The payload  
MUST be either a single fragment of a Vorbis packet, or one or more  
complete Vorbis packets". This is described in section 5, but it  
doesn't hurt to be explicit here.

Section 2.3 (2nd paragraph): I assume Vorbis decoders will parse the  
bit stream  to determine if padding has been added, so there's no  
need to explicitly signal how much padding is present? Also, does the  
value of the padding bits matter? A few words of clarification would  
be useful.

Section 2.4: I think it would be clearer if figures 4 and 5 were  
combined into a single figure, as done for the later examples. Also,  
the figure makes it look like the complete packet is 32 bit aligned:  
to avoid confusion, including the length of the vorbis data packets,  
and showing that the resulting RTP packet is not a multiple of 32  
bits would be good.

Section 3 (1st paragraph): expand the acronym "VQ" on first use.

Section 3 (3rd paragraph): "SDP delivery is used" -> "SDP delivery is  
typically used" since other options are possible.

Section 3 (4th paragraph): "The delivery vectors in use are specified  
by..." -> "...can be specified by..." since, again, something other  
than SDP might be used to configure this in future.

Section 3 (4th paragraph): Delete the last word in the paragraph  
("section"), it's redundant.

Section 3.1.1 (1st paragraph): Do the identification and setup  
headers end on byte boundaries, or is there a need to include  
padding? If padding is needed, is it added between the two headers,  
or after both? (i.e. does the setup header always start on a byte  
boundary?)

Section 3.1.1 (1st paragraph): might be clearer if normative language  
is used: "The packet configuration packet MUST include the  
identification header, followed by the setup header. It MUST NOT  
include the comment header." or similar?

Section 3.2.1: clarify that the initial 32 bit count field is in  
network byte order. Also, would it be useful for debugging and  
validity checks for the format to start with a magic number?

Section 5.1: rather than using "xxxxx" for the timestamp, suggest  
picking a hex value as an example.

Section 6: clarify that the delivery-method and configuration  
parameters may be included multiple times; and that configuration  
parameters follow the associated delivery-method parameter.

Section 7: "MIME" -> "Media Type" throughout, since this isn't email.

Section 7: "a=fmpt" -> "a=fmtp" (typo, occurs twice)

Section 7 (last paragraph): "in the c attribute" -> "in the c=  
line" (it isn't an attribute in SDP).

Section 7.1.1: typo "lenght"

Section 10: are there any security considerations due to the need to  
fetch code books? At the least, it should mention that codebooks are  
(potentially) fetched from Internet sites, which can leak information  
on when a certain stream is played, and so is a potential privacy  
risk. Not sure if there's anything else to mention?

With these changes, I think the draft will be in a suitable shape for  
publication. If you have nothing more to do to the draft, we can  
consider starting the media type review and working group last call,  
once a revision to address these comments is available.

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