[Standards] NEW: XEP-0224 (Attention)

Richard Dobson richard at dobson-i.net
Mon Aug 13 13:44:46 UTC 2007

> I think there might be a point in this. Basicly i expect a caps capable
> client to completely ignore disco (outside of the caps usage) for a contact
> that does caps. So if some feature is not in caps i'd assume the client
> doesn't have that feature, unless a) the xep specifies (explicitly!) that
> caps should not be used or b) implementation experience dictates that it
> has to be ignored for some good reason.
> Caps can't optimize for the case that different users get different
> features (broadcast and constant meanings for the broadcasted data), so we
> should try to make it clear where a client can't use caps and go via disco.
> This would likely be either
>   - explicit statement in all xeps that define a feature that the client
>     shouldn't trust caps (complex to maintain, simple to implement)
>   - an extension to caps to say "maybe supported, query disco to know for
>     sure". (complicates caps, adds complexity, easy to maintain)
> Well or disallowing different protocol features for different contacts.

As requested previously do you have any actual real use cases to need 
different caps for contacts? Since no one came up with any previously 
when I asked I can only assume there arnt any and that this is just 
pointless complexity for an perceived issue that doesnt actually exist, 
lets just get the real use cases out there so we can examine them to see 
if there arnt better ways to do them anyway.


More information about the Standards mailing list