On Oct 3, 2008, at 12:42 AM, Juha Heinanen wrote:
Dean Willis writes:It probably is useful, just as having keepalive separate from outboundis 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 sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip