[Standards] Entity Capabilities Woes

Daniel Henninger jadestorm at nc.rr.com
Thu Mar 15 03:33:33 UTC 2007

Maybe I'm just not "getting it" but when I looked over entity  
capabilities for PyAIMt and PyICQt, I was trying to pick a good way  
to determine if the client supported XHTML or not before bothering  
them with it.  What I found was something that didn't seem to have  
any rules.. just just because something said xhtml didn't mean that  
it was the xhtml support I was expecting.  Could have meant anything.

Looking over some of the examples and such and discussion going on  
here, I'm starting to wonder if I simply don't understand the point.   
I notice that like Psi specifies psi-im.org/caps or something like  
that.  Am I to understand that capabilities mean nothing across  
applications?  Seeing psi-im.org/caps seems to imply that it's only  
capabilities as psi has decided to define.  What good is that to a  
transport or another client?

Of course, at the moment I can't even see the extensions page to read  
over the XEP again.  Some sort of database error.  I also don't know  
if things have changed since the last time I looked.  But on a base  
level, if someone offers up the capability ...  xhtml.  How am I to  
know that that really means xhtml?  What about if they decide to use  
xht as the short version of the capability instead of xhtml because  
they don't like over 3 character caps?  Are there rules in place that  
I'm not aware of?

Generally I love the "protocol" aspect of it, but it's the actual  
content that makes little sense to me.  So I don't really like or  
dislike it.  From my perspective it was just a pointless XEP and I  
moved on.  (at least for my purposes)

I'm hoping to be corrected here.  ;D  Just so you all know...  I  
imagine I'm just missing some key concept of it.


On Mar 14, 2007, at 7:38 PM, Ian Paterson wrote:

> Rachel Blackman wrote:
>> In the end, caps is one of our protocols that is actually both a)  
>> sufficient for the task, and b) reasonably well-adopted.  Given  
>> that, I think time and effort is better spent on other things  
>> rather than taking a wheel which works and spending that time  
>> reinventing it just because you don't like the tread pattern. :)
> +1
> The existing tread pattern is arguably better too.
> - Ian

More information about the Standards mailing list