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.
Richard
