On Fri, 2008-08-22 at 10:12 +0200, Iñaki Baz Castillo wrote: > El Friday 22 August 2008 07:23:28 Paul Kyzivat escribió: > > Clearly there was a decision to model it after email.
Actually, it was copied from HTTP... in the very early days it was hoped that SIP could slip unnoticed through HTTP proxies - hopeless, as it turned out, but that was the motivation. > I understand it, of course, but some times when complaining about SIP BNF > I've > received replies arguing that it's not a problem of SIP, but a problem of > SMTP or HTTP in which SIP is based. > > This argue is not valid for me, since SIP designers could the oportunity of > basing SIP in other protocols (or making it from scratch). > > Anyway, even if SIP is based in email, it could be done more conservative. > For > example headers like "From" are a pain since basically *all* is valid: > > From: DisplayName <sip:[EMAIL PROTECTED];uri_param=qq>;hdr_param=kk > From: "DisplayName" <sip:[EMAIL PROTECTED];uri_param=qq>;hdr_param=kk > From: <sip:[EMAIL PROTECTED];uri_param=qq>;hdr_param=kk > From: sip:[EMAIL PROTECTED];hdr_param=kk <-- URI param not allowed here > > And also the header field name: > > From > FROM > from > f > F > frOM > > > Instead of allowing all these stuff, allow just: > > From: "DisplayName" <sip:[EMAIL PROTECTED];uri_param=qq>;hdr_param=kk > From: <sip:[EMAIL PROTECTED];uri_param=qq>;hdr_param=kk > > From > f > > > People would be happier and the protocol would also be based in STMP and > HTTP. :) All of what you say (in this and your many similar complaints) is true. But it doesn't matter - the protocol is what it is and complaining about it won't change it. It also will not be changed by any future revision to remove any of these inconvenient features because to do so would cause far far too many problems with deploying the new protocol. Backward compatibility for (millions or billions of) users quite correctly trumps convenience for (tens or hundreds of) software developers. Think of it as job security if you like, but move on and quit complaining about things that cannot be changed. By all means - next time you are defining an entirely new protocol for the Internet that has no backward compatibility issues, be sure you remember these lessons. -- Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ http://www.pingtel.com/ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
