Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)
RFC 6236

Note: This ballot was opened for revision 11 and is now closed.

(Robert Sparks) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2011-01-20 for -)
No email
send info
I have only partially reviewed this document, but I have no objection to
the technical content in this document. I found a lot of the text 
somewhat ambiguous or hard to parse, and the number of such issues was 
(IMHO) close to making the document quality suspect and warranting a 
Discuss. Although the RFC Editor will work on these issues, it is my 
opinion that such a level of changes will result in a proportion of
cases will result in:
- bad fixes made by the RFC Editor
- issues being missed.

I urge the authors to at least make fixes to the issues I have
identified, and preferably find a technology-aware native speaker to
review and update the text.


The Abstract really needs to mention SDP

I would prefer if the Introduction was also clearer sooner that this 
document applies to SDP


SDP is not a well-known acronym according to the RFC Editor
so should be expanded:
- in the title
- in the Abstract when you add it
- on first use in the main text


You should expunge all references to "draft" and replace with "document"
(when published as an RFC, this will not be a draft!)                    


In the Abstract...

   The draft also helps to maintain an optimal bitrate for video
   as only the image size that is desired by the receiver is

A nice trick if you can do it, but actually, I think that someone needs
to implement something! How about...

   The mechanisms defined in this document can also be used to help
   maintain an optimal bitrate for video, as only the image size that is
   desired by the receiver is transmitted.


Section 1

   This document proposes a new attribute to make it possible to
   negotiate different image attributes such as image size.  The term
   image size is defined here as it may differ from the physical screen
   size of for instance a hand-held terminal.

I do not find the term "image size" defined.
You may want s/defined/used/ or you may want to add the definition.


Section 1

   There are a number of benefits with a possibility to negotiate the
   image size:

/with a/to the/


Section 1

   o  Optimal quality for the given bitrate: The sender does not need to
      encode an entire CIF (352x288) image if only an image size of
      288x256 is displayed on the receiver screen.  This alternatively
      gives a saving in bitrate.

s/alternatively/alternative/  ?





   o  The attribute typically contains a "send" and a "recv" keyword.
      These specify the preferences for the media once the session is
      set up, in the send and receive direction respectively from the
      point of view of the sender of the session description.  One of
      the keywords ("send" or "recv") MAY be omitted, see Section 3.2.4
      and Section 3.2.2 for a description of cases when this may be

I see this saying:
   The attribute MUST contain at least one of the keywords "send" and



   o  For sendrecv streams both of the send and recv directions SHOULD
      BE present in the SDP.




   o  For inactive streams it is RECOMMENDED that both of the send and
      recv directions are present in the SDP.

s/SDP/SDP message/ ?


   Payload type number (PT):  The image attribute is bound to a specific
      codec by means of the payload type number.

It may be obvious, but there is no statement of where the possible 
values of PT can be found. I think you should add this.

(David Harrington) No Objection

Comment (2011-01-18 for -)
No email
send info
This document is well-written. These comments require no action by the authors, but if these fixes were applied, it might make for a cleaner document.

1) in the first sentence of the introduction, s/attribute/SDP attribute/
2) in the introduction, sar used without definitinon or reference
3) in 3.1.1, for sendrecv streams you use SHOULD BE - BE is not an RFC2119 keyword. The next bullet uses RECOMMENDED. RECOMMENDED and SHOULD mean the same things in RFC2119. It woul dbe nice to be consistent so people ar enot in any way confused by the different language.
4) in, the sentence starting "several image attributes can be defined" is a bit convoluted, and it makes it difficult to parse. "conditioned that" is an unusual wording that makes it harder to parse. It is unclear whether the "conditioned that" is part of the "for instance", or part of the "can be defined".
5) payload type - what s the range? are these types defined in a registry someplace?
6) preference - what is the range of q? is this 0.0-1.0, or are 100.0 and -65537.7 valid values? 
7) sar - what is the range of values?
7) sar - I am confused by the "(range)" in this sentence - do you mean it defines a specific range of sample aspect ratios associated to a given x and y image size?
8) "The response MUST NOT include a sar parameter if there is no acceptable value given." - what does acceptable mean here?  
9) how does one express a sar range? is it "0.1-0.7" or "0.1...0.7" or dx/dy "0.1/0.7" or 0.142857143?
10) "The offerer must be able to support ... The exception is" Isn't MUST with an exception a SHOULD?
11) Can we capitalize the RFC2119 keywords?
12) "to reduce this risk", why isn't this a MUST?
13) in 3.2.2 s/answer/answerer/
14) in 3.2.2, if the third approach solves the problem and has no drawbacks, why not make that one a MUST, and make the other two options MUST NOT?

(Russ Housley) No Objection

Comment (2011-01-20 for -)
No email
send info
  As noted in the Gen-ART Review by Avshalom Houri on 19-Jan-2011, the
  following lines in Section 4.2.4 need to be reworded:
  > Neither part is required to rescale like this (sar may be ignored),
  > the consequence will of course be a distorted image.

  Also, please consider the editorial changes proposed in the Gen-ART
  Review by Avshalom Houri.

(Alexey Melnikov) No Objection

Comment (2011-01-14 for -)
No email
send info
I've done a detailed review of the document and overall I think it is fine. Some comments below:

Last paragraph of section, last sentence:

      Where ratio_min and ratio_max are the min and max allowed picture
      aspect ratios.
      If sar and the sample aspect ratio that the receiver actually uses
      in the display are the same (or close), the relation between the x
      and y pixel resolution and the physical size of the image is
      straightforward.  If however sar differs from the sample aspect
      ratio of the receiver display this must be taken into
      consideration when the x and y pixel resolution alternatives are
      sorted out.

This doesn't say how to achieve that.


  o  Answerer receiving the offer and sending the answer:

      *  The answerer should not include an image attribute in the
         answer if it was not present in the offer.

s/should not/SHOULD NOT ?

Also check if "may"s in this section should be MAYs.  Possible solutions

   o  2nd session-wide offer/answer round: In the 2nd offer/answer the
      codec payload format specific parameters are defined based on the
      outcome of the 'imageattr' negotiation.  The drawback with this is
      that set up of the entire session (including audio) may be delayed
      considerably, especially as the 'imageattr' negotiation can
      already itself cost up to two offer/answer rounds.  Also the
      conflict between the 'imageattr' negotiation and the payload
      format specific parameters is still present after the first offer/
      anser round and a fuzzy/buggy implementation may start media

typo: answer

      before the second offer/answer is completed with unwanted results.

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-01-18 for -)
No email
send info
The technical content of this document appears to be acceptable.

The document is difficult to read in numerous places because of run-on sentences and non-standard English.

I suggest that the authors review the conformance terms in accordance with RFC 2119, because sometimes lowercase keywords (lacking any conformance meaning) are used when uppercase keywords seem more appropriate. For example, in the following sentence "MUST" seems better than "must":

      *  The offerer must be able to support the image attributes that
         it offers.

There are also several instances of uppercase keywords when no conformance meaning is in force. For example, in the following sentence "needs to" seems better than "MUST":

      *  If the image attribute is included in the SDP answer but none
         of the entries are usable or acceptable, the offerer MUST
         resort to other methods to determine the appropriate image

(Sean Turner) No Objection

Comment (2011-01-19 for -)
No email
send info
I support Tim's discuss.