Re: [Simple] Soon you can Blink!

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

2009/9/28 Adrian Georgescu <ag at ag-projects.com>:
> http://wiki.icanblink.com/
>
> Blink implements RTP audio sessions (VoIP), session based Instant Messaging
> (IM), File Transfer and multi-party chat sessions using MSRP protocol and
> its relay extension, desktop sharing using VNC protocol, publication and
> subscription for rich presence information such as availability, moods,
> activities and geo-location, management for the presence rules, resource
> lists, RLS services documents using XCAP protocol.
>
> You can receive a notification when the software become available or
> participate to our early adopter program by registering on the mailing list:
>
> http://lists.ag-projects.com/mailman/listinfo/blink
>
> The software implements most of the SIP SIMPLE working group items and will
> have an open source license.


Let me a question. 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).


Sorry for this mail, but this subject is really depressing for me.

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