Re: 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