inline >-----Original Message----- >From: Christer Holmberg [mailto:[email protected]] >Sent: Thursday, March 05, 2009 4:11 AM >To: Bob Penfield >Cc: [email protected] >Subject: RE: [Sip] I-D Action:draft-ietf-sip-199-06.txt > > >Hi Bob, > >>I have few comments on draft-ietf-sip-199-06.txt. I apologize >>if any of these are duplicates. >> >>Section 6. The statement requiring the proxy to keep track of >>early dialogs: >> >> A proxy which supports generating of 199 response codes MUST keep >> track of early dialogs, in order to determine whether to generate a >> 199 response when the proxy receives a non-2xx final response. In >> addition, the proxy MUST keep track on which early dialogs it has >> received and forwarded 199 responses, in order to not generate >> additional 199 responses for those early dialogs. >> >>Should precede the statement: >> >> If the forking proxy generates a 199 response, and if the >> forking proxy is able to identify additional early dialogs >> which are terminated by the same non-2xx final response, it MUST >> also generate and send a 199 response upstream for each of those >> early dialogs, >> >>In fact, if the proxy is keeping track of early dialogs, >>under what circumstances would it not be "able to identify >>additional early dialogs which are terminated by the same >>non-2xx final response"? > >Just because the proxy keeps track of early dialogs, it doesn't >necessarily know that an error response on early dialog X also >terminates early dialog Y. In order to know that, the forking proxy >needs to know that early dialogs X and Y come from the same forking >proxy further down the path. >
Of course it can. If the proxy forwarded the request to Z, and Z forked to X and Y, the provisional responses from X and Y that created the early dialogs would have the same branch-id. The error response from Z would have that same branch-id. The proxy would know that all early dialogs created by a 1xx with that branch-id would have terminated (i.e. both X and Y). > >>Section 8 (199 Early Dialog Terminated) seems out of place. >>Shouldn't this be in the introduction? or in an "Overview Of >>Operation" between sections 3 and 4? > >I have tried to use other similar drafts as "template". > > >>The text in Section 9 (Usage with SDP offer/answer) should be >>in section 5 (User Agent Server behavior). > >I think it is good to have a separate chapter. Of course, I could refer >to chapter 9 from chapter 5. My point is that all too often behavior requirements (MUST, SHOULD, MAY, etc.) get buried is separate sections and folks can miss them. If all the requirements are in the applicable "behavior" section, they are easy to find and developers are less likely to miss them. If you want it to be a separate section, make it 5.1. All UAS requirements should be in section 5 or a subsection thereof. > >>The statement in section 10 recommending that the UAS send >>199 unreliably should be in section 5. >> >>The statement in section 10 forbidding proxies from sending >>199 reliably should be in section 6 (Proxy behavior). > >Same as for offer/answer. > >Since the 199 procedures related to offer/answer and reliable responses >are special, I think it is good to have specific chapters for it. > The requirements/restrictions for reliable provisional responses are very important. They could easily be missed by having them in a separate chapter in the back of the document. Again, all UAS behavior requirements should be in section 5 (or sub-section) and all proxy behavior requirements should be in chapter 6 (or sub-section). >Regards, > >Christer > cheers, (-:bob _______________________________________________ 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
