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