[OpenSIPS-Devel] Adding support for 'dialog-rules'
Iñaki Baz Castillo
ibc at aliax.net
Tue Nov 17 01:56:04 CET 2009
El Lunes, 16 de Noviembre de 2009, Adrian Georgescu escribió:
> One of the IETF goals is to make protocols extensible without having
> to go back to the standards body for adding new stuff. In SIP you can
> an extra header for instance without breaking anything and without
> having to standardize it either.
> This is one example for extending the usage of the standard common-
> policy. It takes 5 lines of code to use it for other useful purposes.
> It means that IETF did something good in the end.
Well, IETF's pres-rules is not something good IMHO as it's a half-done
specification that creates, for sure, interoperability problems. In fact I
would say that IETF pres-rules is a big pain.
The main problem is that the pres-rules XML format is not stricted at all so
client A can generate a correct pres-rules document but client B couldn't read
it as it would generate a pres-rules document with same meaning in a very
I remember that IETF doesn't specify at all the format of pres-rules document.
Some vendors (as Counterpath or you, AG) use two <rules> sections
("pres_whitelist" with action "allow" and "pres_blacklist" with action
"block"). In this way interoperability """works""" when just Counterpath or AG
software is involved. I would like to know what happens if Eyebeam or
SipSimpleClient gets, via XCAP, a pres-rules document with lots of <rule>
sections and <many> (not just <one>) in <condition> sections. Some
<transformation> would be also cool...
For sure they would ignore or would interpret wrongly the meaning of the
document. But the pres-rules document is 100% valid according to the RFC.
So, we have a half-done specification, pres-rules, and now a custom
specification (pres-dialog-rules) based on it, so keeping all the issues I've
explained above. This is the reason why I don't like a lot this new feature.
Iñaki Baz Castillo <ibc at aliax.net>
More information about the Devel