Subject: [MMUSIC] Working Group Last Call for draft-ietf-mmusic-image-attributes-04

From: Tom Taylor <[email-masked]>
Date: Mon, 26 Apr 2010 11:26:07 -0400

By popular demand, this is to announce Working Group Last Call for 
draft-ietf-mmusic-image-attributes-04.txt. Last Call will close Sunday, May 9th.

Tom Taylor
MMUSIC Co-Chair

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 26 Apr 2010 17:48:32 +0200

A few comments from a quick skim.

1)	The text:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

appears twice in the document. 

2)	In section 3.1, it is impossible for implementations to conform with the RFC 2119 "MUST". These are requirements on the remainder of the document, and it is the remainder of the document that has to conform. This needs to be made clear and the RFC 2119 language probably removed.

3)	Section 3.2.1.2: states "The following rules apply for the offer/answer exchange." This can be interpreted two ways, one that it updates the RFc 3264 requirements, and the other that it entirely replaces them. The relationship with RFC 3264 needs to be made clear.

4)	Section 3.2.1.2: For the text:

      *  The offerer MUST be able to support the image attributes that
         it offers.  The exception is if the offerer has expressed a
         wild card (*) in the attribute list.

How is this different from the general required in SDP offer/answer that if you make an offer, you have to be able to receive what you offer.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Taylor
> Sent: Monday, April 26, 2010 4:26 PM
> To: mmusic
> Cc: Ingemar Johansson S; Jean-Francois Mule
> Subject: [MMUSIC] Working Group Last Call for 
> draft-ietf-mmusic-image-attributes-04
> 
> By popular demand, this is to announce Working Group Last 
> Call for draft-ietf-mmusic-image-attributes-04.txt. Last Call 
> will close Sunday, May 9th.
> 
> Tom Taylor
> MMUSIC Co-Chair
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 28 Apr 2010 18:40:21 -0700

The draft looks good. I have some minor comments.

Section 3.2.1

   o  For sendonly or recvonly streams one of the directions MAY be
      omitted.  See Section 3.3.3, moreover the order of the send and
      recv directions is not important. 

Isn't this true regardless of direction, meaning you are not required to
include both "send" and "recv" attr-lists even if direction is sendrecv
or inactive. If there is a requirement for this, I do not see it stated
clearly anywhere. I am ok with it either way, so long as it is
clarified.

Section 3.2.1.2

      *  The answerer MAY also, for its receive and send direction,
         replace the entries with a complete new set of entries
         different from the original proposed by the offerer.

This seems contrary to the rule in section 3.2.1.1 for sar, namely, "The
response MUST NOT include the sar parameter if there is no acceptable
value given."

Section 3.3.2

   As an example H.264 with profile level 1.2 does not support higher
   resolution than 352x288 (CIF).  The offer/answer rules essentially
   gives that the same profile level must be used in both directions.
   This means that in an asymmetric scenario where Alice wants an image
   size of 580x360 and Bob wants 150x120, profile level 2.2 is needed in
   both directions even though profile level 1 would have been
   sufficient in one direction.

Such restrictions have been removed by rfc3984-bis via the addition of
the level-asymmetry-allowed parameter.

Section 3.3.3

   If the directional attributes a=sendonly or a=recvonly are given for
   a media, there is of course no need to specify the image attribute
   for both directions.  Therefore one of the directions in the
   attribute MAY be omitted.  However it may be good to do the image
   attribute negotiation in both directions in case the session is
   updated for media in both directions at a later stage.

Here as well it would be best to clarify whether or not one is REQUIRED
to include both send and recv attr-list sets if the direction is not
sendonly or recvonly. My assumption is that this is never required,
regardless of direction, but is always recommended. Is that the
intention?

Section 4.2.1

   Alice can then select a valid image size which is closest to the one
   that was originally desired (336x256) and performs a second offer/
   answer
       ----
       a=imageattr:97 send [x=800,y=640,sar=1.1] \
                      recv [x=336,y=256]
       ----
   Bob replies with (actually not necessary)

But it is necessary, otherwise it means Bob no longer supports it.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Taylor
> Sent: Monday, April 26, 2010 11:26 AM
> To: mmusic
> Subject: [MMUSIC] Working Group Last Call
fordraft-ietf-mmusic-image-attributes-04

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 29 Apr 2010 10:23:01 +0200

Hi

Thanks for reading, comments and followup questions inline below

/Ingemar

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: den 26 april 2010 17:49
> To: Tom Taylor; mmusic
> Subject: RE: [MMUSIC] Working Group Last Call for 
Ok, compared with other RFCs, If I get things right it is the first occurence that should be removed.

> 
> 2)	In section 3.1, it is impossible for implementations to 
> conform with the RFC 2119 "MUST". These are requirements on 
> the remainder of the document, and it is the remainder of the 
> document that has to conform. This needs to be made clear and 
> the RFC 2119 language probably removed.
I am not sure I follow. I guess that section 3.1 is not really needed anymore. But you say that "MUST" should not be used in this section. Like I said I believe I misunderstand...

> 
> 3)	Section 3.2.1.2: states "The following rules apply for 
> the offer/answer exchange." This can be interpreted two ways, 
> one that it updates the RFc 3264 requirements, and the other 
> that it entirely replaces them. The relationship with RFC 
> 3264 needs to be made clear.
The intention is not to update RFC3264. I interpreted an earler review by Jean-Francois as a request to specify this in detail. Now I realize that some of the text may be interpreted as an update to RFC3264, question is then how to formulate celarly that this is not the intention. I see however reason to specify the rules around the image attribute clearly.

> How is this different from the general required in SDP 
> offer/answer that if you make an offer, you have to be able 
> to receive what you offer.
Actually I would say that there is no difference at all, even the second sentence is inline with RFC3264. This also relates to comment #3 above. What is the proper level of documentation here?. I guess I can write something like "The offerer MUST be able to support the image attributes that it offers, this is not different from the requirements set in [RFC3264]." 

/Ingemar

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Apr 2010 12:50:32 +0200

> > conform with the RFC 2119 "MUST". These are requirements on the 
> > remainder of the document, and it is the remainder of the document 
> > that has to conform. This needs to be made clear and the RFC 2119 
> > language probably removed.
> I am not sure I follow. I guess that section 3.1 is not 
> really needed anymore. But you say that "MUST" should not be 
> used in this section. Like I said I believe I misunderstand...
> 

Implementations cannot conform to the RFC 2119 language in this section. These type have things have been discussed in the past in similar SIP documents, but we have not really come to a common proposal on the best way to handle them. In the early days they were put in a separate informational RFC. In other cases we have put the language in lower case, or moved it to an appendix. In both these cases you need some introductory text indicating that the text of the section formed the basis from which the protocol was developed, and is included only for informational purposes only. 

> > the offer/answer exchange." This can be interpreted two 
> ways, one that 
> > it updates the RFc 3264 requirements, and the other that it 
> entirely 
> > replaces them. The relationship with RFC
> The intention is not to update RFC3264. I interpreted an 
> earler review by Jean-Francois as a request to specify this 
> in detail. Now I realize that some of the text may be 
> interpreted as an update to RFC3264, question is then how to 
> formulate celarly that this is not the intention. I see 
> however reason to specify the rules around the image 
> attribute clearly.
> 

If the rules of RFC 3264 are not updated, write an informational sentence that says:

"In accordance with RFC 3264, offer answer exchange of these parameter is as follows..."

If they are updated, then you will need to write:

"In addition to the requirements of RFC 3264, offer answer exchange has the following additional requirements:"

followed by sentences that do use RFC 2119 language.

Note that the above are only example formulations and they could be expressed numerous different ways, but the key different is in use of RFC 2119 language or not.

> Actually I would say that there is no difference at all, even 
> the second sentence is inline with RFC3264. This also relates 
> to comment #3 above. What is the proper level of 
> documentation here?. I guess I can write something like "The 
> offerer MUST be able to support the image attributes that it 
> offers, this is not different from the requirements set in 
> [RFC3264]." 

See my response on 3) above. If it is not different, you only need new informational explanation, rather than RFC 2119 text.

regards

Keith

> From: Ingemar Johansson S [mailto:[email-masked]] 
> Sent: Thursday, April 29, 2010 9:23 AM
> To: DRAGE, Keith (Keith); Tom Taylor; mmusic
> Cc: Jean-Francois Mule
> > conform with the RFC 2119 "MUST". These are requirements on the 
> > remainder of the document, and it is the remainder of the document 
> > that has to conform. This needs to be made clear and the RFC 2119 
> > language probably removed.
> I am not sure I follow. I guess that section 3.1 is not 
> really needed anymore. But you say that "MUST" should not be 
> used in this section. Like I said I believe I misunderstand...
> 
> > 
> > the offer/answer exchange." This can be interpreted two 
> ways, one that 
> > it updates the RFc 3264 requirements, and the other that it 
> entirely 
> > replaces them. The relationship with RFC
> The intention is not to update RFC3264. I interpreted an 
> earler review by Jean-Francois as a request to specify this 
> in detail. Now I realize that some of the text may be 
> interpreted as an update to RFC3264, question is then how to 
> formulate celarly that this is not the intention. I see 
> however reason to specify the rules around the image 
> attribute clearly.
> 
> > 
> Actually I would say that there is no difference at all, even 
> the second sentence is inline with RFC3264. This also relates 
> to comment #3 above. What is the proper level of 
> documentation here?. I guess I can write something like "The 
> offerer MUST be able to support the image attributes that it 
> offers, this is not different from the requirements set in 
> [RFC3264]." 
> 
> /Ingemar
> 
> 
> > 
> > regards
> > 
> > Keith
> > 
> Call for

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 30 Apr 2010 14:04:55 +0200

Hi

And thanks for the comments, my answers inline 

/Ingemar

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: den 29 april 2010 03:40
> To: Tom Taylor; mmusic
> Subject: RE: [MMUSIC] Working Group Last Call 
> Isn't this true regardless of direction, meaning you are not 
> required to include both "send" and "recv" attr-lists even if 
> direction is sendrecv or inactive. If there is a requirement 
> for this, I do not see it stated clearly anywhere. I am ok 
> with it either way, so long as it is clarified.
My take is that for sendrecv streams both send and recv SHOULD be present while for inactive streams it is RECOMMENDED that both send and revc are present.

> This seems contrary to the rule in section 3.2.1.1 for sar, 
> namely, "The response MUST NOT include the sar parameter if 
> there is no acceptable value given."
Yes, this is a bit contradictory, the sar parameter is tricky. The intention with this rule is that the answerer should not accept a sar value that it cannot handle and this may lead to distorted pictures. Perhaps I should rewrite the statement in 3.2.1.1 like "The response MUST NOT include the sar parameter if there is no acceptable value given, the reason to this is that if the response includes a sar parameter it is interpreted as accepted". 

> Such restrictions have been removed by rfc3984-bis via the 
> addition of the level-asymmetry-allowed parameter.
Correct, also mentioned in the subsequent paragraph. 

> Here as well it would be best to clarify whether or not one 
> is REQUIRED to include both send and recv attr-list sets if 
> the direction is not sendonly or recvonly. My assumption is 
> that this is never required, regardless of direction, but is 
> always recommended. Is that the intention?
OK, see above, 

> But it is necessary, otherwise it means Bob no longer supports it.
OK, you are right, brain fart...

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 30 Apr 2010 14:57:49 -0700

Hi Ingemar,

Please see additional comment inline.

> Sent: Friday, April 30, 2010 5:05 AM
> To: Charles Eckel (eckelcu); Tom Taylor; mmusic
> Cc: Jean-Francois Mule; Ingemar Johansson S
> My take is that for sendrecv streams both send and recv SHOULD be
present while for inactive streams
> it is RECOMMENDED that both send and revc are present.

Sounds good. I suggest adding that test to the draft.

> Yes, this is a bit contradictory, the sar parameter is tricky. The
intention with this rule is that
> the answerer should not accept a sar value that it cannot handle and
this may lead to distorted
> pictures. Perhaps I should rewrite the statement in 3.2.1.1 like "The
response MUST NOT include the
> sar parameter if there is no acceptable value given, the reason to
this is that if the response
> includes a sar parameter it is interpreted as accepted".

This helps; however, I suggest the following minor change:
"MUST NOT include the sar parameter" to "MUST NOT include a sar
parameter"

Cheers,
Charles