Subject: Re: [MMUSIC] AD review: draft-ietf-mmusic-image-attributes-06

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 13 Sep 2010 11:17:03 +0200

Hi

FYI. I want this draft to advance.

I will update this draft on the places where I believe it is applicable. Thanks Robert and Tom for the suggestions and nits. 
If you have any answers to my followup questions below (posted already Aug. 30), please let me know.

Regards
Ingemar

> -----Original Message-----
> From: Ingemar Johansson S 
> Sent: den 30 augusti 2010 09:21
> To: Robert Sparks; [email-masked]; 'DRAGE, Keith (Keith)'
> Cc: [email-masked]; 
> Ingemar Johansson S; [email-masked]
> Subject: RE: AD review: draft-ietf-mmusic-image-attributes-06
> 
> Hi
> 
> Thanks for the comments and sorry for the delay. As Kyunghun 
> Jung answered to the first set of questions I will 
> concentrate on the remainder (inline below) Must admit that 
> this MUST, must, SHOULD, should is really complicated. Keith 
> commented on my use of RFC2119 keywords and I though I got 
> things right but aparently there seems to be a few rough 
> edges. (see discussion around section 3.1.1.2 below). 
> Keith: I have marked the applicable parts where I would 
> appreciate your input with [KD].
> 
> Regards
> Ingemar
> 
> > -----Original Message-----
> > From: Robert Sparks [mailto:[email-masked]]
> > Sent: den 19 augusti 2010 20:07
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: AD review: draft-ietf-mmusic-image-attributes-06
> > 
> > (There is a copy of these comments at 
> > http://www.nostrum.com/~rjsparks/mmusic-image-attributes.txt
> > for awhile in case any mail clients re-wrap the lines in a way that 
> > makes this too hard to read).
> > 
> > The document places requirements on "high end" devices without 
> > defining them or characterizing them beyond what you can take away 
> > from the name. Without a more objective definition, these 
> requirements 
> > effectively reduce to "Some implemantation MAY" do these things. If 
> > that's what you mean, please say it that way. If you really 
> are trying 
> > to inflict SHOULDs and MUSTs on something, please reduce 
> the ambiguity 
> > in what they are.
> > 
> > I'm surprised that there hasn't been more discussion around the 
> > message size bloat associated with including an imageattr line with 
> > "send * recv *" in offers where the offerrer isn't planning to use 
> > this document's extension. Have I missed that searching the 
> archives?
> > If so, please provide a pointer. Were other negotiation mechanisms 
> > considered?
> > 
> > The document should better capture the motivation for allowing the 
> > answerer to create attribute value entries that aren't 
> covered by the 
> > offer's proposal. It should better describe _when_ additional 
> > offer/answer exchanges would be induced (informing the operator as 
> > well as the implementor), and show that this can't result in the 
> > infinite ping-pong loop that the general pattern of 
> answering with a 
> > subset of the offer was created to avoid in the first place.
> > 
> > In section 3.1.1, the document should call out where to find the 
> > definition of WSP and DIGIT you are intending to use.
> > The last two lines of comments at the end of key-value's 
> ABNF need to 
> > start with semicolons
> WSP and DIGIT are defined in RFC5234, isn't the reference sufficient ?
> 
> > 
> > 3.1.1.2: second bullet (o), last sub-bullet (*): It's not 
> clear what 
> > "should not on its own include"
> > means. Are you trying to say that if an offer doesn't include an 
> > a=imageattr for a stream, then the offer MUST NOT include one?
> I got the idea from earlier discussions (Keith Drage) [KD] 
> that RFC2119 keywords should not be used here, perhaps I 
> misunderstood.
> 
> > 
> > 3.1.1.2: third bullet (o), first sub-bullet (*): This use 
> of SHOULD is 
> > unclear. When would the offer _not_ resort to other 
> methods? I think 
> > you're trying to say that if the image attribute is not included in 
> > the answer, then the offerer knows the answerer does not 
> support this 
> > mechanism and continues to process the answer as if this 
> mechanism had 
> > not been offered.
> Correct. Perhaps rewrite as "If the image attribute is not 
> included in the SDP answer the offerer SHOULD continue to 
> process the answer as if this mechanism had not been offered" ?
> 
> > 
> > 3.1.1.2: second bullet (o), second sub-bullet (*): This has 
> the same 
> > issue as the first sub-bullet.
> > Assuming I understand the intent, this would be clearer if 
> you wrote 
> > along these lines:
> >   * If the image attribute is included in the SDP answer, 
> but none of 
> > the entries are usable or
> >     acceptable, the offer MUST initiate a new offer/answer exchange 
> > without using the image attribute.
> Sounds reasonable
> 
> > The draft should also indicate what to do with any media 
> packets that 
> > might arrive before that second offer/answer completes.
> OK, my take here is that as the offer/answer completed Ok 
> otherwise, media should be able to flow. Another alternative 
> is to set to port number to zero in the answer, not sure here 
> what is the most correct.
> 
> > 
> > 3.2.1: first paragraph - This MUST NOT belongs in 3.1.1.2, (at the 
> > last sub-bullet of the second bullet if I've understood 
> you), and it 
> > applies to _all_ answers, not just those to initial 
> invites. I suggest 
> > changing this sentence to something along these lines: "When the 
> > initial offer does not contain the 'imageattr' attribute, 
> the rules in 
> > section
> > 3.1.1.2 require the attribute to be absent in the answer."
> OK
> 
> > 
> > 3.2.6 : It's not clear what the purpose of this section is. 
> > If it's only to call out the problem and capture the 
> > discussion of some possible solutions (but not specify a 
> > solution), that should be stated more clearly. Right now, the 
> > text could be read to be recommending the solution in the 3rd 
> > bullet of 3.2.6.4, but it's not well specified. 
> OK. An extra sentence "section 3.2.6.4 outlines a few 
> recommended solutions" to 3.2.6 would do.
> 
> > Either way, 
> > the document should note that using port 0 this way may 
> > defeat the return of any information about image attributes 
> > from the answerer in the first offer/answer round. Per 3264:
> >    A port number of zero in the offer indicates that the
> >    stream is offered but MUST NOT be used.  This has no 
> > useful semantics
> >    in an initial offer, but is allowed for reasons of completeness,
> >    since the answer can contain a zero port indicating a 
> > rejected stream
> >    (Section 6). 
> > In section 6, it notes that media formats for rejected 
> > streams are ignored. Devices wishing to save bandwidth may 
> > surpress any attributes associated with that m-line.  Also, 
> > be very careful with the semantics - when a slot for a 
> > rejected stream is reused, it is adding a new media stream, 
> > not modifying/updating an existing stream.
> OK. This potentially makes port=0 a bit shaky doesn't it?. 
> One can add an extra sentence "Note that according to 
> RFC3264, a port number of zero means that the whole media 
> line is rejected meaning that a new offer for the same port 
> number should be treated as a completely new stream and not 
> as an update.". Is there any other more foolproof way to 
> solve this?, preconditions ?
> 
> > 
> > 4.2.3: The example claims it is presenting a complete SDP 
> > offer - it isn't. It would be more accurate to say "more of 
> > the SDP offer is shown"
> OK
> 
> > 
> > The draft needs to note that the coupling between the 
> > attributes in the offer and answer is associated with the 
> > codec, not the payload type number. It's possible to 
> > negotiate different payload type numbers for the same codec 
> > in the pair of unidirectional streams assocated with an m 
> > line. The offer can indicate a PT number of 101 and the 
> > answer can use PT 102, for example. If that happens, the 
> > offerer will be sending RTP with payload frames labeled 102 
> > and the answerer will be sending frames labeled 101.
> > (But the answerer's SDP would have contained a=imageaddr:102).
> One solution is to specify
> a=imageattr:* ..
> Isn't this sufficient
> 
> > 
> > It would also be good to call out what's allowed with this 
> > parameter when an m-line has more than one payload type 
> > number mapped to the same codec.
> I have not until now seen any bigger issues here. Could you 
> please outline what is missing in this respect in sections 
> 3.1.1 and 3.1.1.1 ?
> 
> > 
> > Nits:
> > 
> > Introduction: last paragraph first sentence : This sentence 
> > doesn't parse for me.
> > Is it trying to say "This document is limited to 
> > point-to-point unicast communication scenarios"?
> Yes. Perhaps a bit complicated way of saying it from my side 
> :-), will change.
> 
> > 
> > 3.1.1.2: first bullet (o), second sub-bullet (*): Should 
> > "recommended" be in upper case?
> If I interpret Keiths [KD] previous comments correctly it should not.
> 
> > 
> > 3.2.9 : first paragraph: The MUST requirement in the 2nd 
> > sentence misrepresents what the answer is.
> > There are no unknown parameters to remove from the answer - 
> > the answer is not a copy of the offer, it is content that the 
> > answerer generates. It would be better to say the answerer 
> > MUST ignore any unknown parameters in the offer and MUST NOT 
> > include them in the answer it generates.
> OK, will fix this
> 
> > 
> > 4.1 : The last part of this example is confusing. Instead of 
> > "If Bob does not support any x and y resolution in any of of 
> > (sic) the X and Y ranges", perhaps you could say "If Bob does 
> > not support any x and y resolution in one of the provided 
> > send or recv ranges". Then instead of starting the next 
> > sentence as "In this case", start it as "For instance, if Bob 
> > doesn't support any of the offered alternatives in the recv 
> > attr-list in the offer", and delete the sentence starting "In 
> > the above example".
> OK, will fix this
> 
> > 
> > 
>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 17 Sep 2010 14:47:54 -0500

Hi Ingemar -

Some comments/questions inline:

Keith - there's two questions for you inline:

On Aug 30, 2010, at 2:21 AM, Ingemar Johansson S wrote:

> Hi
> 
> Thanks for the comments and sorry for the delay. As Kyunghun Jung answered to the first set of questions I will concentrate on the remainder (inline below)
> Must admit that this MUST, must, SHOULD, should is really complicated. Keith commented on my use of RFC2119 keywords and I though I got things right but aparently there seems to be a few rough edges. (see discussion around section 3.1.1.2 below). 
> Keith: I have marked the applicable parts where I would appreciate your input with [KD].
> 
> Regards
> Ingemar
> 
>> for awhile in case any mail clients re-wrap the lines in a 
>> way that makes this too hard to read).
>> 
>> The document places requirements on "high end" devices 
>> without defining them or characterizing them beyond what you 
>> can take away from the name. Without a more objective 
>> definition, these requirements effectively reduce to "Some 
>> implemantation MAY" do these things. If that's what you mean, 
>> please say it that way. If you really are trying to inflict 
>> SHOULDs and MUSTs on something, please reduce the ambiguity 
>> in what they are.
>> 
>> I'm surprised that there hasn't been more discussion around 
>> the message size bloat associated with including an imageattr 
>> line with "send * recv *" in offers where the offerrer isn't 
>> planning to use this document's extension. Have I missed that 
>> searching the archives?
>> If so, please provide a pointer. Were other negotiation 
>> mechanisms considered?
>> 
>> The document should better capture the motivation for 
>> allowing the answerer to create attribute value entries that 
>> aren't covered by the offer's proposal. It should better 
>> describe _when_ additional offer/answer exchanges would be 
>> induced (informing the operator as well as the implementor), 
>> and show that this can't result in the infinite ping-pong 
>> loop that the general pattern of answering with a subset of 
>> the offer was created to avoid in the first place. 
>> 
>> In section 3.1.1, the document should call out where to find 
>> the definition of WSP and DIGIT you are intending to use.  
>> The last two lines of comments at the end of key-value's ABNF 
>> need to start with semicolons
It would improve the document to be explicit. Other documents have added a sentence along the lines of
"WSP and DIGIT are defined in RFC5234". 

>> clear what "should not on its own include"
>> means. Are you trying to say that if an offer doesn't include 
>> an a=imageattr for a stream, then the offer MUST NOT include one?
> I got the idea from earlier discussions (Keith Drage) [KD] that RFC2119 keywords should not be used here, perhaps I misunderstood.

Keith - could you look at this bullet again and help build text that's not misleading?
The phrase "should not include on its own" isn't strong enough.

> 
>> 
>> 3.1.1.2: third bullet (o), first sub-bullet (*): This use of 
>> SHOULD is unclear. When would the offer _not_ resort to other 
>> methods? I think you're trying to say that if the image 
>> attribute is not included in the answer, then the offerer 
>> knows the answerer does not support this mechanism and 
>> continues to process the answer as if this mechanism had not 
>> been offered.
> Correct. Perhaps rewrite as "If the image attribute is not included in the SDP answer the offerer SHOULD continue to process the answer as if this mechanism had not been offered" ?
That would work for me.

>> the same issue as the first sub-bullet.
>> you wrote along these lines:
>>  * If the image attribute is included in the SDP answer, but 
>> none of the entries are usable or
>>    acceptable, the offer MUST initiate a new offer/answer 
>> exchange without using the image attribute.
> Sounds reasonable
> 
>> packets that might arrive before that second offer/answer completes.
> OK, my take here is that as the offer/answer completed Ok otherwise, media should be able to flow. Another alternative is to set to port number to zero in the answer, not sure here what is the most correct.
I'm a little confused by the second part of your response, but rereading the section and my question, I withdraw the point. I can't think now of what else the draft could say.

> 
>> 
>> 3.2.1: first paragraph - This MUST NOT belongs in 3.1.1.2, 
>> (at the last sub-bullet of the second bullet if I've 
>> understood you), and it applies to _all_ answers, not just 
>> those to initial invites. I suggest changing this sentence to 
>> something along these lines: "When the initial offer does not 
>> contain the 'imageattr' attribute, the rules in section 
> OK. An extra sentence "section 3.2.6.4 outlines a few recommended solutions" to 3.2.6 would do.
> 
>> Either way, 
That's the point - it _is_ a shaky way to solve the problem.
> One can add an extra sentence "Note that according to RFC3264, a port number of zero means that the whole media line is rejected meaning that a new offer for the same port number should be treated as a completely new stream and not as an update.". Is there any other more foolproof way to solve this?, preconditions ?
Preconditions would probably work, and would avoid the big concern I have with deviating from the answer-is-a-subset-of-the-offer principle in O/A.
> One solution is to specify

Sorry - I'm not following.
I think it would be sufficient to just call out that the scenario I've detailed
above can happen so that implementers aren't surprised.

> I have not until now seen any bigger issues here. Could you please outline what is missing in this respect in sections 3.1.1 and 3.1.1.1 ?
This is not a big issue, but it is a point to call out to avoid implementer surprise.
It's related to what i have above.

> Yes. Perhaps a bit complicated way of saying it from my side :-), will change.
> 
>> 

Keith - this section is the specification - has Ingemar interpreted your
feedback as you intended? If this isn't where the behavior is being
constrained, where _is_ the normative behavior defined?

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 29 Sep 2010 11:25:07 +0200

Hi

I have uploaded a new version which should adress all the comments and suggestions for improvement except the ones related to RFC2119 keywords. 
The diff is 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-image-attributes-07

The remaining issues are 

==============
> The phrase "should not include on its own" isn't strong enough.
==============
and
==============
> Keith - this section is the specification - has Ingemar 
> interpreted your feedback as you intended? If this isn't 
> where the behavior is being constrained, where _is_ the 
> normative behavior defined?
==============

Regards
Ingemar

> Sent: den 17 september 2010 21:48
> To: Ingemar Johansson S
> Cc: [email-masked]; 'DRAGE, Keith (Keith)'; 
> [email-masked]; 
> [email-masked]
> Subject: Re: AD review: draft-ietf-mmusic-image-attributes-06
> 
> Hi Ingemar -
> 
> > Thanks for the comments and sorry for the delay. As Kyunghun Jung 
> > answered to the first set of questions I will concentrate 
> on the remainder (inline below) Must admit that this MUST, 
> must, SHOULD, should is really complicated. Keith commented 
> on my use of RFC2119 keywords and I though I got things right 
> but aparently there seems to be a few rough edges. (see 
> discussion around section 3.1.1.2 below).
> >> requirements effectively reduce to "Some implemantation 
> MAY" do these 
> >> things. If that's what you mean, please say it that way. If you 
> >> really are trying to inflict SHOULDs and MUSTs on 
> something, please 
> >> reduce the ambiguity in what they are.
> >> 
> >> this document's extension. Have I missed that searching 
> the archives?
> It would improve the document to be explicit. Other documents 
> have added a sentence along the lines of "WSP and DIGIT are 
> defined in RFC5234". 
> 
> > 
> >> 
> of SHOULD 
> >> is unclear. When would the offer _not_ resort to other methods? I 
> >> think you're trying to say that if the image attribute is not 
> >> included in the answer, then the offerer knows the 
> answerer does not 
> >> support this mechanism and continues to process the answer 
> as if this 
> >> mechanism had not been offered.
> >> 3.1.1.2: second bullet (o), second sub-bullet (*): This 
> has the same 
> I'm a little confused by the second part of your response, 
> but rereading the section and my question, I withdraw the 
> point. I can't think now of what else the draft could say.
> 
> > 
> >> 
> >> applies to _all_ answers, not just those to initial invites. I 
> >> suggest changing this sentence to something along these 
> lines: "When 
> >> the initial offer does not contain the 'imageattr' attribute, the 
> >> rules in section
> >> If it's only to call out the problem and capture the discussion of 
> >> some possible solutions (but not specify a solution), that 
> should be 
> >> stated more clearly. Right now, the text could be read to be 
> >> recommending the solution in the 3rd bullet of 3.2.6.4, 
> but it's not 
> >> well specified.
> >> the document should note that using port 0 this way may defeat the 
> >> return of any information about image attributes from the 
> answerer in 
> >> the first offer/answer round. Per 3264:
> >>   stream is offered but MUST NOT be used.  This has no useful 
> >> semantics
> >>   since the answer can contain a zero port indicating a rejected 
> >> stream
> >>   (Section 6). 
> >> In section 6, it notes that media formats for rejected streams are 
> >> ignored. Devices wishing to save bandwidth may surpress any 
> >> attributes associated with that m-line.  Also, be very 
> careful with 
> >> the semantics - when a slot for a rejected stream is reused, it is 
> >> adding a new media stream, not modifying/updating an 
> existing stream.
> Preconditions would probably work, and would avoid the big 
> concern I have with deviating from the 
> answer-is-a-subset-of-the-offer principle in O/A.
> > 
> >> 
> offer - it 
> >> isn't. It would be more accurate to say "more of the SDP offer is 
> >> shown"
> > OK
> > 
> >> 
> attributes in 
> >> the offer and answer is associated with the codec, not the payload 
> >> type number. It's possible to negotiate different payload type 
> >> numbers for the same codec in the pair of unidirectional streams 
> >> assocated with an m line. The offer can indicate a PT 
> number of 101 
> >> and the answer can use PT 102, for example. If that happens, the 
> >> offerer will be sending RTP with payload frames labeled 
> 102 and the 
> >> answerer will be sending frames labeled 101.
> I think it would be sufficient to just call out that the 
> scenario I've detailed above can happen so that implementers 
> aren't surprised.
> 
> > 
> >> 
> parameter 
> >> when an m-line has more than one payload type number mapped to the 
> >> same codec.
> >> Introduction: last paragraph first sentence : This 
> sentence doesn't 
> >> parse for me.
> >> Is it trying to say "This document is limited to point-to-point 
> >> unicast communication scenarios"?
> Keith - this section is the specification - has Ingemar 
> interpreted your feedback as you intended? If this isn't 
> where the behavior is being constrained, where _is_ the 
> normative behavior defined?
> 
> > 
> >> 
> >> 3.2.9 : first paragraph: The MUST requirement in the 2nd sentence 
> >> misrepresents what the answer is.
> >> There are no unknown parameters to remove from the answer - the 
> >> answer is not a copy of the offer, it is content that the answerer 
> >> generates. It would be better to say the answerer MUST ignore any 
> >> unknown parameters in the offer and MUST NOT include them in the 
> >> answer it generates.
> > OK, will fix this
> > 
> >> 
> >> 4.1 : The last part of this example is confusing. Instead 
> of "If Bob 
> >> does not support any x and y resolution in any of of
> >> (sic) the X and Y ranges", perhaps you could say "If Bob does not 
> >> support any x and y resolution in one of the provided send or recv 
> >> ranges". Then instead of starting the next sentence as "In this 
> >> case", start it as "For instance, if Bob doesn't support 
> any of the 
> >> offered alternatives in the recv attr-list in the offer", 
> and delete 
> >> the sentence starting "In the above example".
> > OK, will fix this
> > 
> >> 
> >> 
> 
>