Hi, Comments on the minor feedback from Robert. -----
>Minor: >min-1) (I waffled on putting this into major): This entire >mechanism is an optimization, but the word optimization is >never used. This is (as discussed so far) ONLY an >optimization and should be explicitly described as such >(including documenting the limitations of the optimization). I am not sure I disagree with you, but I am trying to figure out what optimization really means in this context. As far as the limitation is concerned, I guess that is because of the fact that it is an optional feature, and that it cannot be assumed that 199 responses will be received for all terminated dialogs. ----- >min-2) The document uses "upstream" and "downstream" >throughout its text. We can probably find a way to replace >those terms with something less likely to induce confusion >especially when translating to other languages. I think that wording has been used elsewhere, but I can use something else. ----- >min-3) The abstract shows the architectural confusion I call >out in maj-2. Its not clear what elements use the 199 in this >description. >The most likely interpretation of the given text is just the UAC. Now, assuming that both forking proxies and UASs can send 199, how about the following: "This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC." ----- >min-4) The last sentence of the 5th paragraph of the >Introduction (which starts "When SIP entities upstream >receive") says SIP entities but talk about things that only >UACs can do, specifically terminating the session startup. When SIP entities upstream receive the non-2xx final response they will automatically terminate the session setup and all associated early dialogs. I could replace the text with the following: "When SIP entities upstream receive the non-2xx final response they will release resources associated with the session, and the UAC will terminte the session setup." ----- >min-5) Paragraph 1 of section 4 (Client Behavior) can be read >to say a UAC MUST always insert a Supported:199. It should >start with a conditional clause such as "If the client wants >to receive 199 responses, then". Correct. I'll fix that. ----- >min-6) Item 5 in section 4.1 talks about dialogs being "inactive" >which doesn't have meaning - I think it meant to say "the >sessions associated with some early dialogs may be set to inactive". I could replace the text with the following: "5. Limited access resources - in case of forking and multiple stream it may not be possible to allow early media on all dialogs, so media sessions associated with some dialogs may e.g. be set to "inactive". When a dialog is terminated, media sessions associated with other dialogs can be allowed." ----- >min-7) Section 5 should be titled "User-Agent Server" >behavior to avoid confusion with Proxies. Ok. ----- >min-8) (This will be major later in the review process if >it's still there when we get there). Section 6 uses 2119 >capitalized words to restate requirements from other, already >published and referenced, documents. This is a practice we >should work hard to avoid. I suggest replacing the first two >sentences with "A proxy will forward a received 199 response >as it is required to forward all other non-100 provisional >responses by RFC 3261." Similarly, the last paragraph of >section 7 should not use 2119 capitalized words. Ok. ----- >min-9) The part of section 6 that talks about the proxy >generating 199s on its own would be clearer if it were >structured around the generation of multiple 199s for a given >3-6xx with the case of only one 199 being generated falling >out as a special case. (currently it documents the 1 final >response makes 1 provisional response and calls out the >multiple-199 case as an exception/extension later in the section). How about replacing: "When a forking proxy receives a non-2xx final response which terminates an early dialog and the proxy does not intend to forward the final response immediately (due to the rules for a forking proxy), and the UAC has indicated support of the 199 response code, the proxy MUST generate and send a 199 provisional response upstream for that early dialog, unless the proxy prior has received and forwarded a 199 response for that early dialog. The 199 provisional response MUST contain a To header tag parameter, which identifies the early dialog that has been terminated." ...with: "When a forking proxy receives a non-2xx final response which terminates one or more (if forking has occured early dialogs, and the proxy does not intend to forward the final response immedialetly (due to the rules for a forking proxy), and the UAC has indicated support of the 199 response code, the proxy must generate and send a 199 provisional response upstream for the early dialog on which the non-2xx final response was received. If the forking proxy is able to identify additional early dialogs which are terminated by the same non-2xx final response, the proxy must also generate and send a 199 provional response upstream for each of those early dialogs." ...and by removing the NOTE. I think that would make the text more clear. ----- 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
