Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-06.txt

From: [email-masked]
Date: Mon, 05 Jun 2006 15:50:01 -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 ATRAC Family
	Author(s)	: M. Romaine, J. Matsumoto
	Filename	: draft-ietf-avt-rtp-atrac-family-06.txt
	Pages		: 27
	Date		: 2006-6-5
	
This document describes an RTP payload format for efficient and
   flexible transporting of audio data encoded with the Adaptive
   TRansform Audio Codec (ATRAC) family of codecs.  Recent enhancements
   to the ATRAC family of codecs support high quality audio coding with
   multiple channels.  The RTP payload format as presented in this
   document also includes support for data fragmentation, elementary
   redundancy measures, and a variation on scalable streaming.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-06.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-atrac-family-06.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-atrac-family-06.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: Mitsuyuki Hatanaka <[email-masked]>
Date: Tue, 06 Jun 2006 16:37:28 +0900

Dear AVT colleagues,

I have submitted draft -06 of our ATRAC family payload.

The main changes are:
- change the MIME type description to Media Type
- change the terminology "sampleRate" to "rate" at the chapter 7.2 and 7.3
- remove and change the author's information

Best regards,
Mitsuyuki Hatanaka

---

From: Colin Perkins <[email-masked]>
Date: Fri, 16 Jun 2006 17:06:57 +0100

Hatanaka-san,

I've reviewed this draft, and have a number of comments. I think the  
payload format specified is appropriate technically, but the draft  
needs significant editorial work to clarify the explanations before  
it can be published. In particular:

   - Please expand the acronym "ATRAC" in the title, to match the RFC  
Editor
     guidelines.
   - Section 1: seems excessively detailed for an introduction. I would
     suggest consolidating the introduction to the codec into section 3,
     and write a more general introduction for section 1. Note that RFC
     2119 language should be restricted to the normative sections of the
     document, and not used in the introduction and background sections.
   - Section 4: would be better written as a design rationale,  
leaving the
     details of the payload format to section 5. The current split, with
     some details in section 4 and some (partially duplicated) in  
section
     5 is confusing.  In particular, I suggest moving the current  
section
     4.5 to the beginning of section 5 (between the section 5 heading  
and
     the section 5.1 heading), and reworking the remainder of the  
text in
     section 4 to focus on the rationale.
   - Section 5.1: need to add some explanatory text, reference figure  
4 from
     the text, and explain how the other RTP header fields are used.
   - Section 5.2: need to reference section 5 from the text
   - Section 5.2.2: doesn't explain that the redundant frames must be
     preceeded by the header from figure 7.
   - Section 5.2.2: the reference to figure 1 appears incorrect. This  
should
     be to figure 6?
   - Section 5.2.3.1 suggests ignoring a "Frame Offset" field. This  
field is
     not mentioned elsewhere.
   - Section 7 makes numerous mentions to RFC 2327. Please update  
these to
     refer to sdp-new (shortly to appear at RFC 4566)
   - Sections 7.1, 7.2 and 7.3 state that "any unspecified parameter  
MUST be
     ignored". For clarity, please change to "any unknown parameter..."
   - Sections 7.1, 7.2 and 7.2 use a "baseLayer" parameter which  
gives the
     encoded bit-rate, but don't specify the units of that bit-rate.  
Is it
     in bits per second?
   - Sections 7.1, 7.2 and 7.3: for maxptime, please refer to sdp-new
   - Sections 7.2 and 7.3 refer to a table in section 5.3 for  
channelID, yet
     there is no section 5.3. I assume this should be a reference to  
section
     7.4?
   - Section 8: there are three new media subtypes, not two.

Could you please submit an updated draft to address these issues?

Regards,
Colin