[SIP Beyond VoIP] missing uri scheme in blink generated resource-lists xcap doc

[Dan Pascu]

On 1 Jul 2015, at 11:03, Juha Heinanen wrote:

> as i have mentioned earlier, uri scheme is missing from sip uris in
> resource-lists xcap documents generated by blink, e.g.
> 
> <?xml version='1.0' encoding='UTF-8'?>
> <rl:resource-lists xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns:addressbook="urn:ag-projects:xml:ns:addressbook" xmlns:blink="urn:ag-projects:blink:xml:ns:addressbook"><rl:list name="oma_buddylist"/><rl:list name="oma_grantedcontacts"><rl:entry uri="test%40test.tutpro.com"/>...
> 
> this breaks compatibility with standards complaint presence servers.

This is not breaking the standard. According to the standard, the uri field is an xs:AnyURI element, which according to the specification is an absolute or relative URI of any kind. In the sipsimple generated documents, the scheme is missing making it a relative uri (the scheme can be deduced from the context, i.e. if it is missing since this is a presence document in the SIP realm it implies the relative URI belongs to the sip scheme).

In addition to this, because SIP has both sip: and sips: schemes, this creates a resolution conflict when identifying the entity that needs to be processed. If I subscribe to you from a sip:user at domain uri and you allow it, but then later I use another device to subscribe to you and it uses a sips:user at domain to subscribe, you will get a new watcher info request as if a new person tries to see your presence and you will have to authorize me twice.

Right now all the code in sipsimple and opensips normalizes the uris by removing the sip: prefix if present in order to correctly identify and match the presentity. Putting the the scheme in there so that every component in the path will take it out when processing makes little sense.

IMO a client/server that wants to be standard compliant must be able to deal with both absolute and relative URIs and if it gets a URI without a scheme it should extrapolate the scheme from the context as sip:

> 
> if it is not possible for some reason to fix this bug,

Besides the aforementioned things and the fact that I do not consider it to be a bug, making this change would break at least the presence server we use. Initially opensips didn't work at all if the uri in the documents contained a scheme. Today it works only if the scheme is sip: but fails for sips: and other schemes.
A lot of other unforeseen things could also break as I do not remember all the details why this was chosen back in the day.

> could you give me
> a hint where in the source code i can try to fix this?

You can take a look in sipsimple in payloads/resourcelists.py and account/xcap/__init__.py
Look where Entry instances are added to the list.

>  now when sources
> are in git, i could clone source for those who need standards compliant
> implementation.

--
Dan