Subject: Re: [MMUSIC] Moving draft-ietf-mmusic-image-attributes

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 17 Jul 2009 10:54:41 +0200

Hi
 
The message below was posted already on may 26
http://www.ietf.org/mail-archive/web/mmusic/current/msg07623.html
 
Please let me know what is needed to make this draft advance to WGLC
 
/Ingemar
============================
In 
http://www.ietf.org/mail-archive/web/mmusic/current/msg07613.html
Kyunghun Jung gave a response regarding 3GPP SA4s view on the draft.
In 
http://www.ietf.org/mail-archive/web/mmusic/current/msg07614.html
I beleieve I have clarified the issues that was raised during the AVT
session and the discussion with Roni Even and Jonathan Lennox
afterwards.
With this in mind I would like to know what is missing in order to make
this draft advance to WGLC.
Regards
Ingemar 
===============================

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 20 Jul 2009 09:46:38 -0600

Ingemar,

   You have requested that 
draft-ietf-mmusic-image-attributes-02 goes through WGLC.

   After my review of the draft, I believe it needs some
more editing before we can proceed for a final wg review.  The note
below provides some editorial and technical comments.

Thanks,
Jean-Francois.
MMUSIC co-chair

--- Notes
This is a brief review of draft-ietf-mmusic-image-attributes-02, dated
April 16, 2009.

1) ID nits
See
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mmu
sic-image-attributes-02.txt 
Please fix the ID nits.

2) Editorial comments

The draft needs some rewrite in various sections to present the
requirements and motivations more clearly to the reader.

2.1)
In some instances, it is a case of just cleaning up some English
syntax:
	- spell out e.g. into 'example' in sentence like:
  | "A possible use case is to make it possible for a e.g a low-end
  |  hand-held terminal to display video without"

same for
  | As most codecs specifies some kind of indication of e.g. the
  | image size already 

  | This may not work well e.g in the presence of bad channel
  | conditions esp. in 

or even for:
 | " Optimal aspect ratio: If rescaling of the image is possible on the
 |    receiver side one can imagine that the offer contains three
 |    resolutions 100x200, 200x100 and 100x100 with sar=1.0 (1:1).
 -> here state the benefit clearly, then follow with an example.
    Consider something like this:
    Optimal aspect ratio: the indication of the supported image sizes
and aspect ratio allows the receiver to select the most appropriate
combination based on its rescaling capabilities and the desired
rendering. For example,  if a sender proposes three resolutions in its
SDP Offer, 100x200, 200x100 and 100x100 with sar=1.0 (1:1), etc.

2.2)
In other cases, it is a matter of rewriting the text as it would read
in the RFC.  Forget the debates in the WG that led to inserting some
text here and there to justify requirements or choices, just present
the story with the consensus for a new reader.

Example p3:
"  The cautious reader may however object that the rescaling issue has
   been moved to the sender and also that codecs such as H.264 are not
   mandated to support the rescaling of the video image size.  This
   potentially reduces the number of valid arguments to only 1 (optimal
   use of bandwidth)."
  -> rather than objecting, when this document is an RFC, the
     implementer will simply disregard this or will not consider it
     valuable enough for implementation.
  Consider replacing the text above with something like this
   " In cases where rescaling is not implemented (for example,
   rescaling is not mandatory to implement in H.264), the indication
   of the image attributes may still provide an optimal use of bandwidth
   because ...."
           ^^^^ explain 

Another example is the list that follows (end of page 3, start of page
4):
  | However, what must then be considered is that:
  |
  |   o  Rescaling on the sender/encoder side is likely to be easier to
do
  |      as the camera related software/hardware already contains the
  |      necessary functionality for
zooming/cropping/trimming/sharpening
  |      the video signal.  Moreover, rescaling is generally done in RGB
or
  |      YUV domain and should not depend on the codecs used.
  ... and the 2 bullets that follow

  This seems again a leftover of an argument that rescaling is better
  done on the sender side.  At this point, I would recommend you
  capture this more clearly:
     For implementers that are considering rescaling issues, note that
     there are several benefits to doing it on the sender side.

2.3)
   Other nits:
   	p4: s/more specific peer to peer situations/more specifically,
	point-to-point communications

	p4: do a spell check, see the heading of section 3
	s/Defintion/Definition

	p4++: from section 3 onward, the text would gain in clarity if
	you remove the already mentioned examples and use a
	specification style.
	Example, proposed new text for the introduction of section 3:
   This section defines the SDP image attribute "imageattr" that can
   be used in an SDP Offer/Answer exchange to indicate various image
   attribute parameters.
   In this document, we define the following image attribute
   parameters: image resolution, sample aspect ratio (sar), allowed
   range in picture aspect ratio and the preference of a given
   parameter set over another.  The attribute is
   however extensible and guidelines for defining extensions are
   provided in <>.
   -> no need to call out some of the benefits again here
   
   Remove "new" in places like "new image attribute" or "new
   attribute" (by the time this is an RFC, it is not new anymore).

2.4)
   Might help to have a separate section covering some of the 
objectives you state in the intro and the requirements of section
3.1 (i.e., put all of that in a section outside the introduction
where you consolidate the motivations, benefits and requirements. 
Not a must though, just a suggestion.

3) Technical comments

 - terminology:
   you use "sender" and "receiver" for the endpoints that send or
   receive the media.  You use "offerer" and "answerer" to designate
   the roles of the endpoint in the O/A model.
   Sometimes, you mix and match those, please review all those 4 terms
   and make sure they are used with their meaning.
   May be you could reuse what is in
   http://tools.ietf.org/html/rfc5547 (where file sender/receiver are
   close to what you call sender/receiver of media).

   Example: p4, section 3:
  | The new SDP attribute contains a set of image attribute options
  | that the offerer can provide.  The receiver can then select the
 
    I think you mean the answerer here.
    The offerer is sometimes the sender, sometimes the receiver, let's
    not mix the roles.

 - normative reference:
   In section 3, you define the attribute by essentially requiring the
   SDP Offer/Answer mechanism to be used.
   => I believe RFC 4566 and 3264 must be normative 

 - reference to 3GPP discussion paper:
  p4 has a pointer to [S4-080144].  I read this document and it do not
  find it useful to leave in the RFC-to-be.  Either some of the
  motivations have already been laid out in the draft, or else they
  should be.
  The issue I have with leaving this pointer is that it concludes with
  a recommendation to extending "a=framesize" while this whole draft
  is about providing a different solution.
  For what you think is still important in that 3GPP document, put it
  in plain English in the document and get rid of the pointer.
  Is there a 3GPP document that makes use of this attribute? If so, can
you provide a pointer to the list?

 - section 3.1 and use of RFC 2119 verbs:
   I would say that based on the document, you want to 
   replace this:
   "The new image attribute should meet the following requirements:"
   with:
   "The image attribute MUST meet the following requirements:"
   	<list REQ-1 through REQ-4>
	BTW please check, you have 2 requirements numbered REQ-3
   and then if you think OPT-1 is optional, make this a MAY or a
   SHOULD.

  - section 3.1 and requirements:
  Here are some comments on the current requirements:
  | The new image attribute should meet the following requirements:
        ^^^                 ^^^^^
	remove		    MUST
  |
  | REQ-1:  Support the offer of a specific image size on the receiver
  |   display or in other words, reduce or avoid the need for rescaling
  |   images in the receiver to fit a given portion of the screen.
I would change this REQ-1 into:

            Support the indication of one or more set(s) of image
	    attributes that the SDP endpoint wish to receive or send.
	    An image attribute set MUST include a specific image size.

(I would cut the rest "reduce or avoid... as this is best in the
motivation section and, the avoidance of rescaling is separate from
this requirement.)

  |
  |REQ-2:  Support asymmetric setups i.e the very likely scenario where
  |   Alice prefers an image size of 320x240 for her display while Bob
  |   prefers an image size of 176x144.

       s/setup/negotiation of image attributes, meaning that each side
       in the Offer/Answer SHOULD be able to negotiate the image
       attributes if prefers to send and receive.
  |
  |REQ-3:  Interoperate with codec specific parameters such as sprop-
  |   parameter-sets in H.264 or config in MPEG4.
       this needs to be developed and more specific. Expand and
       provide examples or justifications here as well.

  |
  |REQ-3:  Make the attribute generic with as little codec specific
  |   details/tricks as possible.  Ideally the attribute should not care
  |   about the codec specific features.
      replace with
      	s/Make the attribute generic with as little codec specific
       details/tricks as possible/be codec agnostic

  |
  |OPT-1:  Make it possible to use attribute for other purposes than
  |   video.  One possible use case may be distributed white-board
  |   presentations which are based on transmission of compressed bitmap
  |   images where rescaling often produce very poor results.
      replace with
       As written, I'm not sure if this is a requirement.
       May be you mean:
       	the image attribute SHOULD support the description of
	image-related attributes for various types of media, including
	video, pictures, images, etc.

  - page 5: your aBNF is not valid.  
	      a) A rulename cannot have underscores, please update.
	      b) for comments use ';' followed by the comment
	      c) check it http://tools.ietf.org/tools/bap/abnf.cgi
	  this probably works:
image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" ) 1*WSP
attr-list )
PT = 1*DIGIT / "*"
attr-list = ( set *(1*WSP set) ) / "*"
            d) define the whole aBNF in one place:
	       include the set rulename with everything else, define
	       range in aBNF
	    e) any extension token for the attribute set?
	    f) put a reference for aBNF

  - aBNF, payload type and requirement to support images:

  p6 says:
  |o  PT is the payload type number, it can be set to * to indicate that
  |   the attribute applies to all payload types in the media
  |   description.

  do all media have a payload type?  what do you do for things
  that have MIME type image/jpeg? just put *?
  what if I want to use this attribute with RFC 5547?

   -  section 3.2.1 and image attribute per payload type or for all:
   could there be use cases where you would want to specify an image
   attribute per group of media?  for example, an offer contains a
   bunch of video codecs, two audio codecs and the offerer would like
   to indicate an image attribute preference for all video codecs.
   This is the case of an endpoint that says: no matter what PT you
   choose to send, I'd like to receive it with this set of image
   attributes.
   Putting * does not work because of the audio.
   Is there a case where media line grouping could work and the
   semantic of the PT can be a payload type, a group of media lines?
PT = 1*DIGIT / "*" / "mid:" 1*DIGIT
   see RFC3388bis and mid

  - section 3.2.1
    The section below is critical for the O/A negotiation and it is
    not clear in the current draft.

  | o  The answerer MAY choose to keep imageattr but is not required to
  |    do so.  If the attribute is kept in the SDP answer:
It seems to me that SDP implementations that support this RFC-to-be
MUST include the imageattr in the response if it is included in the
Offer.  In other words, the whole purpose of this attribute is to
negotiate and if one side expresses a preference, the other one must
respond with something, no?

  |   *  The answerer MUST for its receive direction only include one or
  |      more valid entries taken from the offer.  In other words, the
  |      answerer MUST for its receive direction only pick one or more
  |      valid entries from the multidimensional solution space spanned
  |      by the offer.

s/from the offer/from the Offer's send direction.
s/valid entries/entries it can support 
(or you should define clearly what a valid entry is, it means a set of
image attributes it can support)

s/ multidimensional solution space spanned by the offer/ sub-set of
entries proposed by in the Offer in the Offerer's send direction.

==> what happens if the answerer cannot support any of the offered
image values?
   you seem to allow Bob to respond to Alice with what he can support
   in section 3.2.2. page 9, something that would contradict the MUST
   above.  
   See "If Bob does not support any x and y resolution in the given x
and y
   range in attr_list or a * was given for the recv direction then he
   MUST either:
   o  Provide with another list of options (attr_list).  The answer from
      Bob may then look like:"

  |   *  The answerer MAY for its send direction modify the attribute in
  |      the sense that new entries other than those presented in the
  |      offer are added.  It must however be noted that this may lead
  |      to an extra offer/answer exchange of the added parameters are
  |      not supported by the offerer.
  
  "added"?  that means the answerer cannot remove things from the
  offerered list?  this is confusing, especially given that in the
  Offer, what the offerer puts in its rec parameter list is only a
  preference.

 - section 3.2.2
   Some of the semantic defined in 3.2.2. MUST have associated
   requirements in section 3.1.1., given the way you've chosen to
   split those up.  

  - IANA section
    fill in the contact details again
    add the long form name of the attribute
    add appropriate values with a pointer to section 3.1
    (see draft-ietf-mmusic-sdp-capability-negotiation-10 for an
    example)

// stopped my review here given the time allocated to this ID.

> -----Original Message-----
> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: Friday, July 17, 2009 2:55 AM
> To: Jean-Francois Mule; [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] Moving draft-ietf-mmusic-image-attributes
> 
> Hi
>