[Standards] Entity Capabilities Woes

[Rachel Blackman]

> For example if 'xmpp-ftrans' was registred, and one received this:
> <presence>
>    <c xmlns="http://jabber.org/protocol/caps"
>       node="http://psi-im.org/caps"
>       ver="0.11-dev-rev8" ext="xmpp-ftrans"/>
> </presence>
>
> It could correctly assume the result of sending this:
> <query xmlns='http://jabber.org/protocol/disco#info'
>          node='http://exodus.jabberstudio.org/caps#ftrans'/>
>
> would be this:
> <query xmlns='http://jabber.org/protocol/disco#info'
>          node='http://exodus.jabberstudio.org/caps#xmpp-ftrans'>
>     <feature var='http://jabber.org/protocol/bytestreams'/>
>     <feature var='http://jabber.org/protocol/si'/>
>     <feature var='http://jabber.org/protocol/si/profile/file- 
> transfer'/>
>     <feature var='http://jabber.org/protocol/xhtml-im'/>
> </query>

I'm assuming that the #ftrans/#xmpp-ftrans and the psi-im.org/caps  
versus exodus.jabberstudio.org/caps stuff is all just typos, likewise  
the inclusion of xhtml-im in an 'ftrans' bundle.

But this still makes for an example.  What if we do decide down the  
road, that, say, 'xhtml-im' is indeed a subset of ftrans for some  
reason, and so the 'ftrans' bundle is updated to include that  
definition.  Now either you're advertising xhtml-im in two things  
('ftrans' and 'xhtml' for instance) or you have a situation where  
Client A still thinks 'ftrans' only means the bytestreams/si/file- 
transfer features, and so doesn't recognize that Client B speaks  
xhtml-im.

How do you deal with this?  if you add something to a bundle, does it  
need a new shortname?  'ftrans2'?  Then we now have to advertise  
'ftrans ftrans2' so that clients which only know about 'ftrans' know  
I support file transfer, while newer clients that know about  
'ftrans2' know that I support file-transfer and the xhtml extensions  
to it, or whatever.

It puts a burden on client authors to keep a static table of  
shortname-to-featureset mappings around.  It's not difficult  
codewise, but it creates a huge hassle, and will still bloat the ext  
tables.

Honestly, if people really, really feel strongly about the need to  
have a fully-push caps thing, why not add a 'rext' tag to a caps  
element?  Registered extensions.  Put, say, 'xhtml-im' in there, and  
tada, anything that knows Registered Extensions knows that, yay, you  
support xhtml-im because that is a registered extension that maps to  
http://jabber.org/protocol/xhtml-im.  Just support the other stuff as  
well as the Registered Extensions, too.  Then if rext proves popular  
enough, hey, you've already reduced the amount of bandwidth going  
across.  And if not, it doesn't break backwards compatibility.

But throwing out caps and starting over seems like a waste.  It's  
here, it works fine, it's nicely extensible, and I really think  
there's other things we could spend our time and energy sorting out  
that are more crucial to the success of Jabber/XMPP/XIM/ 
InsertIMNameHere.  Getting PEP actually implemented in servers,  
sorting out the conflicting file transfer specifications, things like  
that. ;)

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/