Hi, If we can't even use the words defined, and used, in 3261 (and probably in other specs) something is really wrong, and to start using different wordings in different documents isn't going to make things more clear in my opinion...
However, I have no problem to copy/paste the definition text from 3261 into the 199-draft, if that helps. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2008 5:40 PM To: Robert Sparks Cc: Christer Holmberg; SIP IETF Subject: Re: [Sip] Sip 199-02: minors from Robert (was RE: WGLC fordraft-ietf-sip-199-02) Robert Sparks wrote: > And they have caused significant implementer confusion. What would be better? Phrases like "toward the UAC" amd "toward the UAS" would *work* but are cumbersome. Would it help to define upstream and downstream in the document? Paul > RjS > > On Nov 24, 2008, at 8:31 AM, Christer Holmberg wrote: > >> >> 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 > _______________________________________________ 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
