[Standards] Service discovery for clients

[Peter Saint-Andre]

JabberForum wrote:
> Maciek Niedzielski;1340 Wrote: 
>> If I remember well, pubsub (xep60 pubsub, not pep) delivers events as 
>> messages sent to _bare_ jid just after event occurs. So pubsub 
>> server/service cannot check client features because it doesn't know 
>> where the message will be routed. It may even end up in offline
>> storage.
>>
>> And it's hard to improve this situation because pubsub service doesn't
>> know your presence, so it doesn't know where to ask about supported 
>> features.

The pubsub service *might* know your presence, but it might not. Perhaps 
in deployment, smart pubsub services will decide that they really need 
presence (from which they'll get caps/disco) and the problem will be solved.

> Of course. That's why I am not speaking about the pubsub service, but
> about your server which routes your messages. The best way is to route
> the right message to the right client. Or else the only future for
> multi-feature XMPP is either to have as many JID as you use different
> feature or to have a single client which can do absolutely everything.
> 
> But the fact is that many people prefer to have different clients for
> different feature. Or sometimes you can only use some basic client (as a
> limited web client while at work when the network ports are restricted
> but still want to get all your unsupported messages the evening when
> arriving home with your full-featured client). Etc.

Resource Application Priority (XEP-0168) was intended to solve something 
like this problem, but perhaps it needs to be updated or reworked -- I 
have not looked at it in a while.

/psa