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

[Ingemar Johansson S <[e-mail]>]

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 

==============
> >> 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.
> 
> 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.
==============
and
==============
> >> 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.
> 
> 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




> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]] 
> Sent: den 17 september 2010 21:48
> To: Ingemar Johansson S
> Cc: [e-mail]; 'DRAGE, Keith (Keith)'; 
> [e-mail]; 
> [e-mail]
> Subject: Re: AD review: draft-ietf-mmusic-image-attributes-06
> 
> 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
> > 
> >> -----Original Message-----
> >> From: Robert Sparks [mailto:[e-mail]]
> >> Sent: den 19 augusti 2010 20:07
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> 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 ?
> 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". 
> 
> > 
> >> 
> >> 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.
> 
> 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.
> 
> > 
> >> 
> >> 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.
> 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
> >> 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?.
> 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.
> > 
> >> 
> >> 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
> 
> 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.
> 
> > 
> >> 
> >> 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 ?
> 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.
> 
> > 
> >> 
> >> 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.
> 
> 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
> > 
> >> 
> >> 
> 
>