Subject: [MMUSIC] Further comments on draft-ietf-mmusic-image-attributes-04

From: Tom Taylor <[email-masked]>
Date: Mon, 10 May 2010 21:55:21 -0400

I am sending a list of nits directly to the author. These comments go beyond 
nits, I think.

1) I don't think you specify the units of the X and Y parameters. I assume they 
are pixel counts, but you should say so.

Section 3.2.1.1, current text is

"Payload type number:  The image attribute is bound to a specific
       media by means of the payload type number."

s/media/codec/. The binding to a specific medium occurs simply by the fact that 
the attribute is in a specific media-level description.

-----

Also in Section 3.2.1.1, you specify that par is in the form of a range:

"par=[ratio_min-ratio_max]"

This is more restricted than the production 'range' in the ABNF. I'm wondering 
if we should rewrite the ABNF to show that explicitly. Anyone else want to comment?

-----

Section 3.3.1: I think the points you want to make are in the wrong order. The 
title of this subsection is "No imageattr in first offer". It seems logical that 
you should first say what the answerer should do (should not do, in this case). 
Actually, you already talked about wild card insertion in section 3.2.1.2, so 
you don't really have to say much here.

I suggest you drop the first sentence and the last paragraph, since they are 
talking about offerer behaviour. You may want to start out the new first 
sentence with:
"When the initial offer does not contain the imageattr attribute, the answerer ..."

If you want, you can refer to high-end behaviour in the first bullet as follows:

   "o  The offerer of the initial SDP is not likely to understand
       the image attribute if it did not include it in the offer,
       bearing in mind that Section 3.2.1.1 recommends that the offerer
       provide the attribute with wildcarded parameters if it has no
       preference."

----

References:

Normative references should precede informative references.

A normative reference is one that has to be understood to implement this 
specification correctly. By that criterion, you need SDP (RFC 4566) and ABNF 
(RFC 5234) to start with. The offer/answer discussion requires RFC 3264 and you 
should probably have SIP (RFC 3261) in there as well. Section 3.3.8 calls for 
[GROUPING] and [RFC5583].