26 feb 2009 kl. 15.20 skrev Iñaki Baz Castillo:
2009/2/26 Johansson Olle E oej@edvina.net:
" This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP." "1. Introduction The meaning and usage of the SIPS URI scheme and of TLS [RFC5246] is underspecified in SIP [RFC3261] and has been a source of confusion for implementers. This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP (including both [RFC3261] and [RFC3608]."
This is very common in lots of RFC's: It seems that a draft must contain some stuff about "security" and "privacy" in order to be accepted as a new RFC.
For example, each new RFC has a vague section mentioning S/MIME:
"In order to provide security the UA could use S/MIME"
Of course, S/MIME is not implemented *AT ALL*, but that seems not to be important, the target is publishing a new RFC so S/MIME, SIPS, IPSEC and TLS stuff is required to appear "somewhere" in the draft.
IETF guys should visit our planet someday.
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.
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? - Would it be possible to get more implementation guidelines published?
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
Will these changes be implemented at all? When?
I think people will use "rfc2833" over insecure RTP for a very long time, regardless that it's now not allowed.
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.
If the standardization is too far away from current implementations, we have a fork. That's not good for anyone. /O