2009/2/26 Olle E. Johansson oej@edvina.net:
This is a problem I realize at every SIPit. The implementations are far away from the IETF world. And the gap doesn't seem to close.
Basic stuff like DNS is not understood or used by many SIPit attendees so even trying to mention NAPTR is too complex, and it's necessary for many security scenarious.
RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really complex, and it's not needed in 99% of current SIP deployments, so vendors don't implement it. If a SIP provider whises to use NAPTR records then all its clients should implement it in their SIP phones (obviously this is unfeasible for now). Solution? don't use NAPTR at all.
The big question is how to close this gap. I have no clue.
- Can we stop the IETF SIP development during a year and work on
implementations, testing and reality checks?
AFAIK no one draft or RFC comes with a real implementation. Sincerelly I don't feel to much interest in real implementations aroud IETF. They can join a long maillist thread about exotic SIP issues that will never happen because nobody will implement the required especifications. When I read IETF-SIP maillist and compare their threads with today's SIP implementations, they seems two different worlds.
- Would it be possible to get more implementation guidelines published?
Does one of these already exist? where?
We have at least two cases now where an update to the RFC added important MUSTs:
- Tel uri - phone-context is now required, which affects all SIP devices
using SIP uri with user=phone regardless if they use a Tel: URI.
- RFC2833 DTMF is updated and secure RTP is now required
I would add all those especifications including new "Require" values, and also those requiring multipart (widely NOT implemented).
The Jabber world annualöy publish a document where they specify "base level standard compliance" for a client and a server. Maybe the SIP world should copy this and use it as a way to push changes to the market.
There is somewhere an RFC pointing a list of "recommended" RFC's. When I read it long time ago there were a *lot* of specifications there.
If the standardization is too far away from current implementations, we have a fork. That's not good for anyone.
Sure, but who care? This should care to both implementators and designers, but...