[Standards] Entity Capabilities Woes

Peter Saint-Andre stpeter at jabber.org
Sat Mar 17 03:10:44 UTC 2007

Daniel Noll wrote:
> On Saturday 17 March 2007 03:57, Rachel Blackman wrote:
>> Saying that because both are file transfer protocols they are the
>> same feature is like saying that because AIM and XMPP are both
>> messaging protocols, I can advertise them as one messaging network.
>> Maybe from an end-user standpoint they look similar, but under the
>> hood they are vastly different.
> Wrong analogy.
> The correct analogy for your example is that both implement the same feature 
> called "ability to chat to people."
>> If, of course, I see some other client:
>> node='http://sample.org/xmpp/caps' ver='2.1' ext='a'
>> ...then I need to now query and cache http://sample.org/xmpp/caps#2.1
>> and http://sample.org/xmpp/caps#a because 'a' here does not in any
>> way, shape or form necessarily map to the 'a' above.
> True enough.
> So I suppose the workaround is to change the node each time that the meaning 
> of the exts change, since even if it's the same "client" as far as the user 
> can tell, it doesn't necessarily have to mean the client author won't change 
> the caps node URI.

Why??? Just make each ext mean the same thing and change the ext string 
if the feature changes. Better to change the ext string than the node 

> One other thing I wonder about caps...
> Suppose I make a bot which logs on today, pretending to be Psi 0.11 and 
> reporting no disco#features.  What happens when users cache that? :-)

Yes there are poisoning attacks. Those need to be addressed more 
forcefully (see other thread).


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070316/e4ff2404/attachment.bin>

More information about the Standards mailing list