Subject: [Simple] XCAP is not developer-friendly as it doesn't allow using a standard XML/Xpath1.0 library

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Feb 2010 19:17:19 +0100

Hi, I've already complained against the design of XCAP protocol and got good
responses and explanations from this maillist. I appreciate them, however I
would like to complain again:

XCAP reuses Xpath 1.0 by including some restrictions (for example a Xpath
result cannot be multiple nodes, but just one). Ok, no problem, by adding some
extra-logic I can implement such restrictions in my XCAP server (which reuses
an existing XML library supporting Xpath 1.0).

The problem is that XCAP also adds some "features" to the original Xpath 1.0
making it incompatible with existing Xpath libraries. I mean the "default
document namespace" feature.

Let's suppose a resource-list document as follows:

---------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">

  <list name="oma_buddylist">
    <external anchor="http://xcap.example.org/resource-lists/users/sip:[email-masked]/index/~~/resource-lists/list%5B@name=%22list-a%22%5D"/>
  </list>

  <list name="list-a">
    <display-name>My Golf Team</display-name>
    <entry uri="sip:[email-masked]" />
    <entry uri="sip:[email-masked]" />
  </list>

</resource-lists>
---------------------------------------------------

So the client inspects the list "oma_buddylist" and gets
"http://xcap.example.org/resource-lists/users/sip:[email-masked]/index/~~/resource-lists/list%5B@name=%22list-a%22%5D"
which points to another list "list-a" within the same document.

Then the client extracts the Xpath expression:

  "/resource-lists/list%5B@name=%22list-a%22%5D"

And now the client must use Xpath to get such list. Unfortunatelly the existing Xpath
expression is not a valid "Xpath 1.0 expression": there are no node prefixes
and the document includes a default namespace "urn:ietf:params:xml:ns:resource-lists"
for all the nodes.

So the client must do a dirty hack and transform the Xpath expression to something
like this:

  "/ns:resource-lists/ns:list%5B@name=%22list-a%22%5D"

Then the client can use its favourite XML/Xpath1.0 library:

  list_a = xpath(
    document,
    '/ns:resource-lists/ns:list[@name="list-a"]',
    {"ns" => "urn:ietf:params:xml:ns:resource-lists"}
  )

This is a really dirty hack as the client must parse and transform the existing Xpath
expression by itself before using it within its XML/Xpath library.
The same occurs in server side.

So, what's the benefit of the XCAP added feature "default document namespace"?
Just "saving bandwith". Ok, let's check it:

a) Using pure Xpath 1.0 specifications:

  GET /resource-lists/users/sip:[email-masked]/index/~~/ns:resource-lists/ns:list%5B@name=%22list-a%22%5D?xmlns(ns="urn:ietf:params:xml:ns:resource-lists)" HTTP/1.1

b) Using the XCAP "cool" feature (default document namespace):

  GET /resource-lists/users/sip:[email-masked]/index/~~/resource-lists/list%5B@name=%22list-a%22%5D HTTP/1.1

So using case b) we have saved 56 bytes, is it really a so nice benefit?
And the only price we've payed for such increible benefit is the fact that we
*cannot* use any *existing* XML/Xpath1.0 library. Instead we must code our own
pseudo-Xpath library implementing the XCAP "additions", so cool...

I don't know if IETF (and more specifically the SIMPLE group) asks itself why
nobody wants to implement SIP rich presence and XCAP. There you have a good
example. It seems that all these specifications are intented for vendors/operators,
companies which can pay developers to code a XCAP aware Xpath library (not compatible
with Xpath 1.0 specification).

I've talked about this issue with a member of the W3C XML Core Working Group, also
a developer of a very famous XML library. Here his responses when I explained him
the XCAP vs Xpath1.0 issue:

> Sorry, that's not XPath behaviour, and not possible with XXXXXXX which
> implements XPath. I'm very surprized that such a deviation from a W3C
> standard was allowed in an IETF specification, there used to be liaison
> between W3C and IETF to avoid this kind of problems.

Then I told him about the "benefit" of XCAP ("saving bandwidth"). His response:

> Very misplaced attempt at optimizing. Note that HTTP is itself
> extremely verbose compared to a binary protocol, but hint hint it's
> the protocol which prevailed ! The XCAP authors didn't even managed to
> learn the lesson from the very protocol they are using.

So we end with XCAP, a specification which forces us to code a pseudo-XML/Xpath
parser from scrath as the specification is not compatible with those
published by the W3C organization.
It seems that Xpath2.0 allows the concept of "application default namespace"
(as XCAP), but I consider unappropriate to require a Xpath2.0 library just to
save 56 bytes (most of the available XML libraries implement Xpath 1.0 rather
than 2.0).

Best regards.

-- 
Iñaki Baz Castillo <[email-masked]>

---

From: Eduardo Martins <[email-masked]>
Date: Mon, 8 Feb 2010 18:39:59 +0000

What code language you are using?

-- Eduardo

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
http://emmartins.blogspot.com
http://www.redhat.com/solutions/telco

On Mon, Feb 8, 2010 at 6:17 PM, Iñaki Baz Castillo <[email-masked]> wrote:
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Feb 2010 19:46:17 +0100

> What code language you are using?

Does it matter? Well, I'm using Ruby with a XMl library (Nokogiri [*]) which 
is a LibXML2 wrapper.

[*] http://nokogiri.org/

---

From: Eduardo Martins <[email-masked]>
Date: Mon, 8 Feb 2010 19:24:42 +0000

It doesn't matter, but could make your life easier by proposing API x
or y, but no luck regarding Ruby.

-- Eduardo

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Feb 2010 20:55:11 +0100

> or y, but no luck regarding Ruby.

Thanks. I suspect you could point to some Java XML library implementing Xpath 
2.0, something perhaps implemented in Movicents.

However I don't want to use Movicents because it violates the GPL license: it 
claims to be GPL but doesn't let to use commercial usage of it (for that 
paying for other kind of license is required, something which violates the GPL 
terms).

Regards.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Feb 2010 20:55:11 +0100

Regards.

---

From: Eduardo Martins <[email-masked]>
Date: Tue, 9 Feb 2010 00:28:46 +0000

Actually the whole Mobicents Platform nowadays uses LGPL, you can do
whatever you want with it. Red Hat or JBoss business never was selling
software.

As for the API used by the XDM Server on this matter, it is nothing
more then the javax.xml.xpath standard one in Java SE 5.0 or later,
but it involves a couple tricks:

1) Add a special NamespaceContext where the empty element prefix
points to the default document namespace
2) Prefix all elements in the path without prefix with empty prefix.

-- Eduardo

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 9 Feb 2010 01:39:31 +0100

> whatever you want with it. Red Hat or JBoss business never was selling

Has this changed recently? Some months ago (~6) I got a reply from a Red Hat 
person involved in Mobicents telling me that the Mobicents license 
(theorically GPL) doesn't allow me to use to provide commercial sevice.

> 2) Prefix all elements in the path without prefix with empty prefix.

I do a similar hack in my XCAP server. I parse the Xpath and add "dfns:" in 
all the non  prefixed nodes, and later I use "dfns"=>AUID_DEFAULT_NAMESPACE 
before invoking the Xpath parser.

The problem is that clients need to implement the same "trick" in order to 
parse <external> entries in the documents :(

Thanks a lot for your comments.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 9 Feb 2010 02:00:07 +0100

El Martes, 9 de Febrero de 2010, Iñaki Baz Castillo escribió:
> Has this changed recently? Some months ago (~6) I got a reply from a Red
>  Hat  person involved in Mobicents telling me that the Mobicents license

Extracted from  
http://www.mobicents.org/faq.html#What_license_is_Mobicents_distri

-----------------------
Mobicents is distributed under a flexible dual license policy. The default 
distribution license is GNU General Public License (GPL), the most popular 
Free Open Source Software (FOSS) license in the world. Users would consider 
purchasing a commercial license if they intend to redistribute Mobicents along 
with proprietary code or offer a commercial onlince service based on 
Mobicents. Other popular Open Source Products with similar licensing policy 
include MySQL, Asterisk, and Java ME.
-----------------------

This is a violation of the GPL license as it says "Users would consider 
purchasing a commercial license if they intend to redistribute Mobicents along 
with proprietary code or ***offer a commercial onlince service based on 
Mobicents***".

Also the examples of "similar licensing policy" mentioning MySQL, Asterisk, 
and Java ME are wrong. I can take a GPL version of MySQL or Asterisk and offer 
a commercial online service.

So Mobicents license is not GPL as GPL does allow me to take the software, 
build an online service and charge my clients for such service.

I also asked about it to FSF which allows with me after reading the software 
license and terms.

Please, if you are involved in the project take this into consideration. I 
already told about this with other member of the project and got these 
responses:

"Mobicents is distributed under the GPL umbrella license.
I am not a lawyer and cannot address the questions you raise regarding  
the interpretation of the GPL license terms."

"You can use Mobicents to develop the service, but unless you open  
source your code, you should deploy on a licensed JBCP instance."

This last response is a violation of the GPL license.

Thanks a lot.

---

From: Eduardo Martins <[email-masked]>
Date: Tue, 9 Feb 2010 01:20:11 +0000

That faq entry is out of date and is misleading, thanks for the alert,
will be fixed. Anyway, as I said, currently all is LGPL.

-- Eduardo

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 9 Feb 2010 02:26:54 +0100

> will be fixed. Anyway, as I said, currently all is LGPL.

Nice to know. Thanks a lot.