Hi, One thing on min-2:
"Upstream" and "Downstream" are actually defined terms in RFC3261, and also used in the text. Regards, Christer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Christer Holmberg > Sent: 24. marraskuuta 2008 13:26 > To: Robert Sparks; SIP IETF > Subject: [Sip] Sip 199-02: minors from Robert (was RE: WGLC > fordraft-ietf-sip-199-02) > > > 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 > _______________________________________________ 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
