[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Sip 199-02: minors from Robert (was RE: WGLC fordraft-ietf-sip-199-02)
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip