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
