Re: Sip 199-02: minors from Robert (was RE: WGLC fordraft-ietf-sip-199-02)

And they have caused significant implementer confusion.

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