[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ó:
> Inaki,
> 
> 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 
different way.

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.

Regards.



-- 
Iñaki Baz Castillo <ibc at aliax.net>



More information about the Devel mailing list