Here are a set of comments to start/continue some discussions on the
199 draft around.
Many of them are nits. Some of them are fairly big.
The draft has quite a bit of cooking to go through yet, but its mostly
of a nature that can be
cooked through fairly quickly I think. I plan to spend time in the
hall with Christer to address
what we haven't killed off on list this week.
----
1) The header says intended status is Informational? You mean PS, right?
2) The draft is still unclear about proxy interaction with the 199
idea, particularly
when it comes to sending them reliably. We need to spend more
time making
the text clear, being particularly careful when there are
multiple proxies in the
path of a response. I bring this up here as a general comment
because I don't
think just fixing individual sections is going to be good enough
- I think its going
to take a holistic editing pass to address.
3) In section 6 you talk of a non-2xx final response terminating one
or more early
dialogs. Can you give me an example scenario where "more" comes
into play?
(preferably add one to the text)? I'm having a hard time seeing
how this ever more
than one.
4) Section 6 says the proxy MUST send a 199 when it receives on of
these non-2xx
final responses. Why is this MUST and not MAY?
There's no Require header here. We can have motivational text
saying why
proxies might really want to, but saying MUST or even SHOULD
seems wrong
from a protocol requirement point of view.
5) With respect to that same requirement - it looks right now like
you're requiring
the proxy to 199 this to-tag even if the UAS that generated it
already did and the
proxy already forwarded that 199 even.
6) Section 6 paragraph one's "MAY release resources" might be
misconstrued to
imply releasing the transaction state, which is NOT what you
mean. I'll propose
text to help try to avoid that later.
7) Section 7: "A UAC that receives a 199 response for an early dialog
MUST NOT
send any further requests on that dialog...". Can you point to any
list discussion
around this requirement? I think there's some danger to consider
there. At the
very least we need to make this statement multiple-usage safe.
8) The last paragraph of section 7 uses MUST NOT and MUST where it
really
should be using does not and is. This paragraph describes things
that are
rather than mandate behavior.
9) Section 8 second open issue: We agreed that we were not addressing
HERFP
with this draft. If we are going to open this mechanism up to
something that
even _partially_ starts to address HERFP (by, as proposed,
including the
non-2xx response that caused the 199), then we need to stop work
on this
draft and go work on HERFP. In other words, my vode for the
answer to this
open issue is "NO".
10) Section 8 first open issue: This looks, at best, to be an
optimization of an
optimization. Considered in the light of having multiple
proxies on the
response path that would have to do extra parsing work because
of this
optimization, I don't think we should consider it further.
11) I can't follow the second paragraph of section 9 at all. Can you
rephrase it?
Once I know what its trying to say, I'll propose alternate text.
12) The open issue in section 10 (can we get a proxy involved in
sending its own
199 reliably) is a big part of the confusion I pointed to at
the beginning of
these comments. This is the part of the draft that I expected
needing face time
in Dublin, but maybe we can make enough progress on it in the
hallway.
I don't think there's any way to allow it, and what we'll need
instead is text
more strongly recommending the endpoints do this themselves
and restrict
any proxy genesis of 199s to the unreliable case (and explain
more that this
is just a transitionary optimization - we _really_ want the
endpoints doing this
work if anything's going to be doing it at all.
13) The security considerations section is TBD.
There's a lot to talk through here. For instance, I can spoof
199s to affect how a call
is ultimately answered in ways that are different (from the
endpoints visibility into
what happened point-of-view) from cancels/byes or even other
response manipulation.
_______________________________________________
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
