[Kamailio-Users] SIMPLE vs XMPP: The Resolution

[Iñaki Baz Castillo]

2009/10/7 Juha Heinanen <jh at tutpro.com>:
> why OMA?  it is part of closed mobile operator walled garden that we
> should have nothing to do with.

Yes, that's a good vision. The problem here is that IETF *didn't*
finish its work for SIMPLE and XCAP. Instead, IETF has published
half-done specifications.

I paste a mail I sent to IETF SIMPLE maillist:

  http://www.ietf.org/mail-archive/web/simple/current/msg08512.html

--------------------------------
After studying all the SIMPLE and XCAP stuff (and
implement part of it), I get a simple conclusion: XCAP and SIMPLE
specifications *don't* exist.

With it I mean that SIMPLE and XCAP (as specified by IETF) don't
provide a fixed and strict set of rules and specifications and it's
*impossible* to get interoperability. Some examples:

- RFC 5025 (pres rules) doesn't specify which is the default action to
perform is a watcher URI is not listed in the document.

- RFC 5025 doesn't clarify which should be the presence server
behavior if the same watcher URI appears in a rule with "allow" action
and also in a rule with "blocked" action. Which one has preference?
the first one? the second one?

- Again with RFC 5025: The pres-rules format is *really* wide and
ambiguous. There are 10000 ways to create a pres-rules document with
same meaning. It's *impossible* that two implementations could share
the same document. This is: vendor A softphone generates a valid
pres-rules document and uploads to the XCAP server. Vendor B softphone
(same SIP account) gets that document and, of course, it doesn't
understand it since it would use a completely different pres-rules
document format to get the same meaning.
I've realized that AG-Projects software implementing XCAP uses a
***custom*** pres-rules format based on 3 rules with id
"pres_whitelist" (action "allow"), "pres_blacklist" (action "block")
and "pres_politeblocked" (action "politeblock"). Can I ask *why*? just
because CounterPath softphones use a similar pres-rules format? This
is just a vendor specific format, no more. IETF doesn't specify it at
all so interoperability is not possible.

- In a presentity there can be a "note" element in various places:
  - Inside the "tuple" section.
  - Inside the "person" section.
  - As a main element in the "presentity" element.
This is annoying and I've seen some implementations setting *all*
these "notes" with same text. But the fact is that nobody can know
which element will other implementation choose to show to the user.

- Resource list stuff: If a user adds a resource list in a pres-rules
rule the the presence server inspecting the pres-rules should also
read the resource-list. What about if the user modifies the
resource-list via XCAP? Then the XCAP server should notify a change to
the presence server in order it to inspect again the pres-rules. Does
IETF RFC's specify it? not at all.


So, what we have? nothing. We have a hyper-complex and ambiguous set
of specifications which don't provide interoperability at all. When I
read "this softphones implements XCAP" I understand "this softphone
implements XCAP so it works ONLY with same vendor's softphones, XCAP
server and presence server". Is this what we want?

OMA's XDM specification is a specification layer on top of XCAP/SIMPLE
documents which tries to create a fixed and strict subset of IETF
specifications in order to make it feasible for clients adoption. For
example it defines a very strict format for the pres-rules document.
It also defines the XCAP server behavior (XDMS server).

I really think that this should be a task of IETF rather than OMA. I
cannot understand why IETF has published such useless and half-done
documents, can I ask *why*?? sharing a simple budy list or privacy
rules is IMPOSSIBLE with IETF's specifications!!!. Anyhow this is what
we have.

Which should be the way to go? perhaps implement OMA's XDM specs?
(I've read XDM documents and they are designed to be SIP core agnostic
(valid for IMS or any kind of SIP core).
--------------------------------


If it's not clear in the quoted text, I also say that Kamailio
presence_xml module (that which reads the presrules document to
allow/disallow a subscription) doesn't follow the standard (since
there is no standard). Instead it follows its own rules (and these
rules could be different than a XCAP client expect, even if both
interpretations are valid according to XCAP RFC's).


Nowadays I'm reading OMA specifications. The *really* propose a good
and strict SIMPLE and XCAP (called XMD) specification. And this
specification is not just for IMS or mobile terminals, not at all,
it's SIP CORE agnostic, it's a set of specifications that can run in
*any* SIP environment.

Yes, I would prefer that IETF does its job and provides an usable,
feasible, strict and *interoperable* specifications, so common tasks
as sharing a buddy list or setting presence privacy rules could be
implemented by reading IETF documents. However it doesn't exist at all
in IETF world.


I paste a text appearing in OMA-RD-Presence_SIMPLE-V1_1-20080627-A.pdf:

---------------------------------------------------------------
4.1         OMA Presence Mandate

SIP/SIMPLE by IETF is accompanied with a set of Internet Drafts and
RFCs (such as RPID, Rich Presence Information Data
Format; CIPID, Contact Information in Presence Information Data
Format; and XCAP, XML Configuration Access
Protocol). 3GPP and 3GPP2 specify the practical implementations of
IETF specifications in IMS (IP Multimedia Subsystem)
and MMD (MultiMedia Domain) respectively. Both transport IP traffic
and use SIP as signalling protocol, and are commonly
known as SIP/IP Core. On top of all this, OMA SIMPLE presence service
specifications, developed in REQ and PAG WGs,
define a SIP/SIMPLE-based Presence Service.

The specifications mentioned above leave a number of degrees of
freedom open; for example, the tuples as defined by IETF
can be used any which way to convey Presence Information. Not even the
Presence Information content is specified. The
situation is akin to having a functioning phone line but no common
language between the conversing parties. This makes it
difficult to achieve interoperability between different vendor’s products.

OMA’s role is to create application level specifications for Presence
Service. This includes presence information semantics
and guidelines for presence applications, please see Figure 1. These
specifications shall be agnostic to the underlying network
technology, be it specified by 3GPP, 3GPP2, or by somebody else.
-----------------------------------------------------------------


So this is what we have. Nobody cares about SIP SIMPLE/XCAP and IETF's
specifications are not finished at all. So:

- We can create our own interpretation of IETF's documents (as
Kamailio's presence_xml module and OpenXCAP do) and create a
*propietary* implementation on top of half-done standards (even if
it's GPL software). And we end with our own rich presence capable
softphone, which only works with our own presence server and XCAP
server.

- Or we can follow a set of specifications on top of IETF RFC's made
by OMA, the only organization around the world which seems really
interested in SIP presence adoption.


Juha, I though as you but after trying to implement XCAP/SIMPLE
specifications I understood that it's *not* possible just with IETF's
docs. OMA specifications is the only good approach for the moment
(IMHO).


Regards.



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