> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Christer Holmberg > Sent: 22 March 2009 16:50 > To: Adam Roach; SIP WG > Subject: Re: [Sip] draft-ietf-sip-199-06 > > > Hi, > > >Between Minneapolis and now, this document has become a lot more > confusing, which I think > >bodes pretty ill for its hopes of being deployed. > > I can tell you it will be deployed, but let's focus on your > comments :) > > >For example, in section 5: > > > > If the received initial request contains an 199 option > tag, the UAS > > SHOULD NOT send a 199 response for a dialog on which it intends to > > send a final response... > > > >This reads as if sending a 199 response somehow absolves a UAS of > sending a final response. > >Certainly this is not the intention of the draft (at least, not > according to the text in > >section 7). Section 5 needs to be re-phrased to indicate what is > actually intended here. > > I undrstand what you mean. The text can be read in a way that > a UA could > use 199 instead of the final response. That is certainly not the > intention. The idea was to cover B2BUAs, which similar to forking > proxies may not send final response for all dialogs. > > >In fact, on that topic, it's radically unclear to me how > UASes fit into > the entire scheme at > >all -- my understanding is that the 199 response is only sent by > forking proxies. > > No, a UAS (both a UA and B2BUA) can also send it. This was discussed > before, and there were no objections to allowing the UAS to send it. > > I do agree that end terminals normally may not send it, but > you may have > network entities (applicatoin servers, B2BUAs generating multiple > dialogs etc) which will. [JRE] The reason we need to cover B2BAUs is that a B2BUA may behave like a proxy and withhold the sending of a final response until it receives responses from other branches it has created. So can we not have the same rule for any server (proxy or UAS), telling it what to do when a final response is withheld? This might make it simpler. There would not then be any need for a normal UAS to send 199.
> > >In section 6: > > > > When a forking proxy receives a non-2xx final response that it > > recognizes as terminating one or more early dialogs, if the proxy > > does not intend to forward the final response immediately (in > > accordance with rules for a forking proxy) and the UAC > has indicated > > support for the 199 response code, the proxy SHOULD generate and > send > > a 199 response upstream for each early dialog terminated on the > > downstream side by the non-2xx final response, except for > any early > > dialog for which the proxy has previously received and forwarded a > > 199 response. > > > >What? On my best run at reading that, I made it to about the > 81st word > before the first > >predicate clause fell out of my head. If it's really as > complicated as > the structure of this > >sentence makes it seem, we need a flowchart or some other simplifying > mechanism. > > I don't understand what is unclear, eventhough the wording > and style may > have some 3GPP influences :) Sure, there may be 81 words, but > I think it > describes what the proxy does in a rather straight forward way. > > I also don't see how a flowchart would make this text more clear, > because the actions depends on what has/has not happened > before. But, if > you have a proposal on how to make the text more simple I am happy to > incorporate that. [JRE] I agree with Adam that it is unclear. When trying to write down a normative requirement that is dependent on multiple conditions, it often helps to list the conditions in a bulleted list, e.g.: If - foo1 - and foo2 - and not foo3 then do bar. John > > Regards, > > Christer > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [email protected] for questions on current sip > Use [email protected] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
