Add support for XEP-115 rev 1.5

[GoogleCodeExporter]

Miranda Version                  : 0.9 
Unicode Build                    : Yes
Test Build # (if applicable)     : #12014
Plugin Version # (if applicable) : #12014

What steps will reproduce the problem?
1. Open XML Console and login to a Jabber server.

What is the expected result?
Miranda should send somethink like this:

<presence from='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     hash='sha-1'
     node='http://code.google.com/p/exodus'
     ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence>

where 'ver' attribute is a specially-constructed string (called a "verification 
string") that represents the entity's service discovery identity. 

What happens instead?

Miranda sends somethink like this

<presence>
   <priority>50</priority>
   <c xmlns="http://jabber.org/protocol/caps" node="http://miranda-im.org/caps" ver="0.9.0.10" ext="cmds mood tune activity mir_notes" />
   <x xmlns="vcard-temp:x:update">
      <photo />
   </x>
   <status>Some status msg</status>
</presence>

Ok so where is the problem?
ver attribute is not a veryfication string, and ext attribute was deprecated.

Original issue reported on code.google.com by andrzej....@gmail.com on 18 Jun 2010 at 4:26

[GoogleCodeExporter]

http://xmpp.org/extensions/attic/xep-0115-1.3.html

Miranda uses XEP-0115 v1.3

Original comment by maxim.mluhov on 18 Jun 2010 at 4:40

• Changed state: Invalid

[GoogleCodeExporter]

>Miranda uses XEP-0115 v1.3

The 1.3 version is old. A latest version of this protocol is 1.5..
Miranda should use newest version of this XEP.

Original comment by andrzej....@gmail.com on 18 Jun 2010 at 4:47

[GoogleCodeExporter]

Are you having problems with a particular serve? Describing the actual problem 
always helps!

Original comment by borkra on 18 Jun 2010 at 5:52

[GoogleCodeExporter]

Invalid? There is no namespace versioning for xep 0115, so v1.3 is deprecated 
and not recommended for implementation. The only currently valid version of 
this xep is 1.5 and it should be implemented. Cuz using 1.3 version perfectly 
disables "caps/disco#info cache" in clients and servers equipped in v1.5.

Original comment by sar...@gmail.com on 18 Jun 2010 at 6:01

[GoogleCodeExporter]

So are you having problems communicating with servers? If yes, which ones (all, 
not good enough please provide the examples)? Which issue this cause?

Always describe the problem not the solution.

Original comment by borkra on 18 Jun 2010 at 6:40

[GoogleCodeExporter]

Eh. Just read v1.5 and you'll understand. 
1) There is no strict "communication problem";
2) Version 1.3 is obsolete;
3) 1.5 is backward compatible with 1.3, so everything works EXCEPT for caps 
cache;
4) Clients (yes, also clients) and servers equipped with 1.5 cannot cache 
"disco#info" result until they verify "version string" hash;

5) Every time when miranda logs on to a 1.5 compliant server it has to ask 
client for it's caps, EVERY TIME. Cuz before server adds "disco" response to 
cache it has to verify hash (mir does not present valid hash);

6) Bottom line is: server could ask only one client, one time about its caps 
and save bandwidth by doing it only once. It CANNOT, because miranda 
implementation of xep 0115 is damn old.
7) Besides, some new clients (as you can see in attachment) recognizes mir as 
"buggy", cuz the cannot identify version of this xep used, they (correctly) 
assume that the only valid version is 1.5;

Original comment by sar...@gmail.com on 18 Jun 2010 at 6:59

Attachments:

• mir.png

[GoogleCodeExporter]

Servers _MAY_ cache v1.3 replies, as described in XEP-0115, so it is not 
Miranda problem, if your favorite server does not cache results properly

Original comment by maxim.mluhov on 18 Jun 2010 at 7:11

[GoogleCodeExporter]

For a session, not across sessions. And only if it supports legacy format. 
Unverified disco#info cannot be trusted, so it can be used only for one 
session. Oh Christ, 1.3 is old an it has been replaced by new version, so why 
do you stick to it so badly?

Besides: "a caps-processing application does not support the legacy format, 
[...]  SHOULD NOT cache it, since the application cannot validate the identity 
and features by checking the hash."

Sooo, if client/server does not support 1.3 it cannot cache results.

Original comment by sar...@gmail.com on 18 Jun 2010 at 7:41

[GoogleCodeExporter]

So the problem is that the server does not support 1.3?

Original comment by maxim.mluhov on 18 Jun 2010 at 8:39

[GoogleCodeExporter]

The whole thing will become much easier if you stop arguing about close of 
standards and start talking about the issue as dumb user. If servers with high 
user base involved, fixing will become an absolute requirement.

As you already noticed arguments about version numbers got you nowhere.

Original comment by borkra on 18 Jun 2010 at 8:40

[GoogleCodeExporter]

@maxim.mluhov: No, problem is that miranda is outdated and not standards-track 
compliant. 

"For historical purposes, Version 1.3 of this specification is archived at 
<http://www.xmpp.org/extensions/attic/xep-0115-1.3.html>." - note: keyword 
"historical".

As borkra partially pointed out: if server implements standard-track xep, it 
could use less bandwidth if clients also support current version protocol.

Miranda is outdated here, that's all.

Original comment by sar...@gmail.com on 18 Jun 2010 at 8:48

[GoogleCodeExporter]

This way, it's a desired enhancement not a bug. Opened back up as a low 
priority enhancement, as no real issues are caused.

Original comment by borkra on 18 Jun 2010 at 8:54

• Changed title: Add support for XEP-115 rev 1.5
• Changed state: Assigned
• Added labels: Component-Protocol-Jabber, Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Bug

[GoogleCodeExporter]

I stumpled today on this issue and meanwhile even more Clients and Server 
sofware does use Rev/version 1.5 of XEP-0115 ;)
Maybe someone got get into it and implemnt it for Miranda? :) Last Updated of 
the XEP was on 2008-02-26 (4 years ago!)

Original comment by hosteddinner on 18 Mar 2012 at 12:48