Jiri, I think we are in 100% agreement then.
For UDP... I was certainly not a proponent of the STUN idea. But after 6 months of arguing on the list and about 6000 postings, the group decided to use STUN. I don't think we want to re-open that can of worms. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jiri Kuthan > Sent: Thursday, May 08, 2008 00:15 > To: Audet, Francois (SC100:3055) > Cc: [email protected]; Christer Holmberg > Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt > > Francois Audet wrote: > > > >> Then we may very well consider making "respond to CRLF > with CRLF" a > >> proposed standardized way too. > >> I mean it is simple and works. Which I prefer over negotiation > >> protocols. > > > > So, basically, you are proposing that for connection-oriented > > transport, we use "respond to double-CRLF with single-CRLF" > instead of Christer's draft. > > > > I assume that would mean that for UDP transport, we'd still > be using > > Christer's draft. > > > > Is this your proposal? > > Hi Francois > > quite so, even I'm still a bit uncertain about what the least evil is > :-) I think it is suboptimal to negotiate transport > characterictics using application-specific protocol. CRLF^2 > seems almost the right thing for TCP. TCP/keepalive seems > even better to me -- I mean we can use it for every single > app without reinventing the wheel. However I'm afraid that > even if "cleaner", it would not work quite so well. > > The trouble with TCP/keepalive is twofold. One is, as Hadriel > mentions, there are OSs that can't deal with it. The question > is how serious shall be in protocol design about OSs whose > TCP stack is not yet state-of-the-art. I'm inclined to be > easy about it, this can be fixed. > The other problem is very similar: there are NATs that ignore > TCP keep-alives to extend bindings. The question is again how > serious shall be in protocol design about software that could > have been better. I'm actually worried more about the latter > under the assumption that network is "imperfect" and > end-devices better compensate for it. Thus I think > CRLF^2 is the most preferable way for its robustness. > > Regarding UDP -- is there anything speaking against CRLF^2 > too? I mean keeping things simple and non-special-cased is a > good thing and I don't realized why this should not work. > > -jiri > > > > _______________________________________________ > 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 > _______________________________________________ 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
