[Standards] NEW: XEP-0224 (Attention)

textshell-E19442 at neutronstar.dyndns.org textshell-E19442 at neutronstar.dyndns.org
Mon Aug 13 12:38:13 UTC 2007


On Fri, Aug 10, 2007 at 11:41:43AM -0600, Peter Saint-Andre wrote:
> Tomasz Sterna wrote:
> > Dnia 10-08-2007, pi?? o godzinie 16:11 +0100, Richard Dobson napisa??(a):
> >> In that case you would just ignore the attempted shake for people who 
> >> you dont want to be able to do it (and probably return an error of
> >> some sort), but you can still publish that you allow it in your caps
> >> if you allow it for some people in your roster,
> > 
> > Maybe we should think of extending Caps to allow publishing different
> > capabilities to different contacts.
> 
> Over complicated. We made some tradeoffs with caps (and indeed with
> presence itself) by using a broadcast model. If you don't want to
> advertise a feature to everyone in your roster, don't include it in the
> hash.

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.

 - Martin H.



More information about the Standards mailing list