On Oct 3, 2008, at 12:42 AM, Juha Heinanen wrote:
Dean Willis writes:
It probably is useful, just as having keepalive separate from
outbound
is probably useful. If we were designing outbound from scratch, we'd
probably break those two functions out into separate drafts, and have
outbound use them.
my understanding is that there has never been a previous outbound
related rfc, i.e., we ARE designing outbound from scratch.
Nope. We're designing outbound from where it is -- a document with
years of effort in it, and quite a few implementations.
We always learn things while doing a document. Sometimes those things
make their way into the document sometimes they don't.
My understanding of the WG's consensus position is that, while we
could probably keep making Outbound better forever, the currently
known weaknesses are not enough to force a fundamental redesign at
this point. We're still open to clarifications, and there's always
the possibility that a real show-stopper could exist, but these two
design limitations don't qualify as show-stoppers.
Given that we can, if we find it sufficiently useful, add a generic
connect-reuse modifier apart from outbound, Is it worth derailing
outbound in order to fix it at this stage?
it surely is. real life fact is that many vendors have already
implemented keepalive as a standalone mechanism and (as my presence
example showed) there would be need to have a generic mechanism for
connection reuse too.
We're looking at a standalone keepalive, and Christer has been leading
that work. We've also been stumbling over a connection-reuse mechanism
for years; perhaps you have an insight that could lead that work
towards some sort of meaningful conclusion.
--
Dean
_______________________________________________
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
