Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)
draft-ietf-mmusic-image-attributes-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2011-03-03
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-03-03
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2011-03-03
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2011-03-02
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-02-24
|
11 | (System) | IANA Action state changed to In Progress |
2011-02-23
|
11 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-02-23
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-02-23
|
11 | Amy Vezza | IESG has approved the document |
2011-02-23
|
11 | Amy Vezza | Closed "Approve" ballot |
2011-02-23
|
11 | Amy Vezza | Approval announcement text regenerated |
2011-02-23
|
11 | Amy Vezza | Ballot writeup text changed |
2011-02-21
|
11 | Robert Sparks | Ballot writeup text changed |
2011-02-21
|
11 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss |
2011-02-18
|
11 | (System) | New version available: draft-ietf-mmusic-image-attributes-11.txt |
2011-01-21
|
11 | (System) | Removed from agenda for telechat - 2011-01-20 |
2011-01-20
|
11 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation. |
2011-01-20
|
11 | Russ Housley | [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. |
2011-01-20
|
11 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-20
|
11 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-20
|
11 | Adrian Farrel | [Ballot comment] I have only partially reviewed this document, but I have no objection to the technical content in this document. I found a lot … [Ballot comment] 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 (http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) 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 transmitted. 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/ ? --- REQ-1 s/wish/wishes/ --- 3.1.1 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 appropriate. I see this saying: The attribute MUST contain at least one of the keywords "send" and "recv". --- 3.1.1 o For sendrecv streams both of the send and recv directions SHOULD BE present in the SDP. s/BE/be/ --- 3.1.1 o For inactive streams it is RECOMMENDED that both of the send and recv directions are present in the SDP. s/SDP/SDP message/ ? --- 3.1.1.1 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. |
2011-01-20
|
11 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
11 | Sean Turner | [Ballot comment] I support Tim's discuss. |
2011-01-19
|
11 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
11 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
11 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-18
|
11 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Stephen Farrell. |
2011-01-18
|
11 | Peter Saint-Andre | [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. |
2011-01-18
|
11 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-18
|
11 | David Harrington | [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? |
2011-01-18
|
11 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-18
|
11 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-17
|
11 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-17
|
11 | Tim Polk | [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.) |
2011-01-17
|
11 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded |
2011-01-17
|
11 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-14
|
11 | Alexey Melnikov | [Ballot comment] I've done a detailed review of the document and overall I think it is fine. Some comments below: Last paragraph of section 3.1.1.1, … [Ballot comment] I've done a detailed review of the document and overall I think it is fine. Some comments below: Last paragraph of section 3.1.1.1, 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. In 3.1.1.2: 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. 3.2.7.4. 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. |
2011-01-14
|
11 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-10
|
11 | Robert Sparks | Ballot writeup text changed |
2011-01-10
|
11 | Robert Sparks | Placed on agenda for telechat - 2011-01-20 |
2011-01-10
|
11 | Robert Sparks | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-01-10
|
11 | Robert Sparks | [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks |
2011-01-10
|
11 | Robert Sparks | Ballot has been issued |
2011-01-10
|
11 | Robert Sparks | Created "Approve" ballot |
2011-01-06
|
11 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-01-05
|
11 | Amanda Baber | 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. |
2011-01-04
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2011-01-04
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2010-12-21
|
11 | Gorry Fairhurst | Assignment of request for Last Call review by TSVDIR to Gorry Fairhurst was rejected |
2010-12-17
|
11 | David Harrington | Request for Last Call review by TSVDIR is assigned to Gorry Fairhurst |
2010-12-17
|
11 | David Harrington | Request for Last Call review by TSVDIR is assigned to Gorry Fairhurst |
2010-12-16
|
11 | Amy Vezza | Last call sent |
2010-12-16
|
11 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Negotiation of Generic Image Attributes in SDP) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Negotiation of Generic Image Attributes in SDP' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-01-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-image-attributes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-image-attributes/ |
2010-12-16
|
11 | Robert Sparks | Last Call was requested |
2010-12-16
|
11 | Robert Sparks | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2010-12-16
|
11 | Robert Sparks | Last Call text changed |
2010-12-16
|
11 | (System) | Ballot writeup text was added |
2010-12-16
|
11 | (System) | Last call text was added |
2010-12-16
|
11 | (System) | Ballot approval text was added |
2010-12-16
|
11 | Robert Sparks | Ballot writeup text changed |
2010-12-15
|
10 | (System) | New version available: draft-ietf-mmusic-image-attributes-10.txt |
2010-11-25
|
09 | (System) | New version available: draft-ietf-mmusic-image-attributes-09.txt |
2010-10-15
|
08 | (System) | New version available: draft-ietf-mmusic-image-attributes-08.txt |
2010-09-29
|
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-09-29
|
07 | (System) | New version available: draft-ietf-mmusic-image-attributes-07.txt |
2010-08-19
|
11 | Robert Sparks | State changed to AD Evaluation::Revised ID Needed from AD Evaluation by Robert Sparks |
2010-08-19
|
11 | Robert Sparks | State changed to AD Evaluation from Publication Requested by Robert Sparks |
2010-08-09
|
11 | Cindy Morgan | [Note]: 'Tom Taylor (tom111.taylor@bell.net) is the Document Shepherd.' added by Cindy Morgan |
2010-08-09
|
11 | Cindy Morgan | (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 … (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. |
2010-08-09
|
11 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-06-14
|
06 | (System) | New version available: draft-ietf-mmusic-image-attributes-06.txt |
2010-06-03
|
05 | (System) | New version available: draft-ietf-mmusic-image-attributes-05.txt |
2010-02-17
|
04 | (System) | New version available: draft-ietf-mmusic-image-attributes-04.txt |
2009-10-18
|
03 | (System) | New version available: draft-ietf-mmusic-image-attributes-03.txt |
2009-10-18
|
11 | (System) | Document has expired |
2009-04-16
|
02 | (System) | New version available: draft-ietf-mmusic-image-attributes-02.txt |
2009-03-06
|
01 | (System) | New version available: draft-ietf-mmusic-image-attributes-01.txt |
2009-02-09
|
00 | (System) | New version available: draft-ietf-mmusic-image-attributes-00.txt |