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

[Ballot comment] 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 ...

[Ballot comment]
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.

[Ballot comment] The technical content of this document appears to be acceptable. The document is difficult to read in numerous places because of run-on sentences ...

[Ballot comment]
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
        size.

[Ballot comment] This document is well-written. These comments require no action by the authors, but if these fixes were applied, it might make for a ...

[Ballot comment]
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 3.1.1.1, 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?

[Ballot discuss] This is mostly a discuss-discuss, but also is a reminder that the authors have agreed to add security considerations about DoS attacks after ...

[Ballot discuss]
This is mostly a discuss-discuss, but also is a reminder that the authors have agreed to add security considerations
about DoS attacks after a discussion with the security directorate reviewer (Stephen Farrell).  Since no text has been proposed as yet, and I agree with his premise, I will hold the discuss as a placeholder even after the discussion
takes place...

Actionable part:
When an offeror "sees no reason to use the image attribute", section 3.2.1 recommends including the attribute with
the wildcard.  The security directorate review notes that an answerer could select attributes that would demand
significant resources, resulting in a DOS attack.  To resolve this, I believe some text needs to be added noting
that memory and other resource considerations need to be considered before accepting the response, even if the
specified attributes can be supported/accepted.

Here's the discuss-discuss part: the ABNF permits the attribute list to be a wild card for both send and recv.  Is there
any good reason for the offeror to specify the wildcard (as opposed to an explicit list) for the send attribute list?  Are
there really any systems that would not restrict the formats it was willing to send to a list?  Offering to send media
without restricting the format seems to invite the kind of DoS attack that Stephen was thinking about.  (Flexibility
regarding reception of media seems more logical to me, although there is still a clear attack vector.)

IANA understands that, upon approval of this document, there is a single IANA Action that needs to be completed. In the att-field (media level only ...

IANA understands that, upon approval of this document, there is a single
IANA Action that needs to be completed.

In the att-field (media level only) subregistry of the Session
Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters

a single, new entry will be added as follows:

SDP name: imageattr
Reference: [RFC-to-be]

IANA understands that this is the only action required upon approval of
this document.

(1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does ...

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Tom Taylor is the Document Shepherd. I have read the document and
believe it is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

No concerns. Video and AVT experts have commented on it.
Document history:
- liaison received from 3GPP asking if MMUSIC is interested in work
in this area, April, 2008
- draft-johansson-mmusic-image-attributes-00.txt introduced to the
list in May, 2008
- comments by Roni Even, response by Johansson, resulting
in -01 update, June 2008
- comments by Colin Perkins, discussion between Kyunghun Jung,
Randell Jesup, and Ingemar Johansson, plus discussion at
Dublin meeting, July 2008
- -02 version submitted, September 2008. Kyunghun Jung, one of the
signatories of the 3GPP liaison statement, added as co-author.
- 3GPP progress noted by Ingemar Johansson, October 2008
- IETF 73 meeting discussion repeated to the list, November, 2008
- initial submission as Mdraft-ietf-mmusic-image-attributes,
February 2009
- -01 version submitted, March 2009
- discussion at IETF 74, March 2009
- -02 version submitted, April 2009
- confirmed that the draft meets 3GPP's needs, May 2009
- extensive editorial review by J-F Mule, July 2009
- layered coding issue reported to list by author, October, 2009
- -03 version submitted with further work to be done, October, 2009
- -04 version subitted, February 2010
- errors noted by Dan Wing, April, 2010
- formal WGLC announced, 26/04/2010
- last call comments from Keith Drage, Cullen Jennings, Dan Wing,
Charles Eckel, Tom Taylor
- -05 version submitted, June 2010
- ABNF error noted, -06 version submitted, June 2010

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns. No IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Solid consensus. More people than usual made WGLC comments.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The -06 version has some second-order idnits problems that the authors
have promised to fix. There is also an example in section 4.2.4 that
is inconsistent with the ABNF. This request for publication is being
submitted to move things along in the understanding that the process
allows for the necessary update at an appropriate stage.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References OK. (Idnits complaints noted above.)

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

IANA section OK. One media-level SDP attribute defined.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

ABNF verified by BAP and inspection. SDP verified by inspection.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document proposes a new generic session set up attribute to make
it possible to negotiate different image attributes such as image
size. A possible use case is to make it possible for a low-end hand-
held terminal to display video without the need to rescale the image,
something that may consume large amounts of memory and processing
power. The draft also helps to maintain an optimal bitrate for video
as only the image size that is desired by the receiver is
transmitted.

Working Group Summary

Work on this document was initiated to satisfy 3GPP requirements.
It benefited from comments on and off the list before going to WGLC,
and attracted a number of comments during WGLC.

Document Quality

3GPP confirmed that the emerging document met their requirements,
and its content has been taken up into their specifications.