26 Feb
2009
26 Feb
'09
5:57 p.m.
26 feb 2009 kl. 15.20 skrev Iñaki Baz Castillo:
2009/2/26 Johansson Olle E <oej(a)edvina.net>et>:
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
" 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.