[Standards] NEW: XEP-0390 (Entity Capabilities 2.0)

Emmanuel Gil Peyrot linkmauve at linkmauve.fr
Sat May 27 14:10:51 UTC 2017


On Sat, May 27, 2017 at 11:01:18AM +0200, Jonas Wielicki wrote:
> On Samstag, 27. Mai 2017 10:22:27 CEST Daniel Gultsch wrote:
> > 2017-05-27 6:39 GMT+02:00 Evgeny Khramtsov <xramtsov at gmail.com>:
> > > Fri, 26 May 2017 18:41:17 +0200
> > > 
> > > Daniel Gultsch <daniel at gultsch.de> wrote:
> > >> would sending in presence work?
> > > 
> > > If we choose to use presences, then why even bother with putting caps in
> > > features?
> > 
> > Fair question. Maybe to avoid a race condition where the client
> > queries the disco node before receiving the presence?
> 
> I would like to add that the server sending a presence is only consistent if 
> the client has sent presence. The client might want to know the servers 
> features before that.

Why is there that requirement?  A server knows the session exists, and
can send any stanza of its own to all of the connected resources, I
don’t see why a presence wouldn’t fit there.

> 
> In addition, clients might want to get updates on the servers features even 
> though they themselves never send presence.

This would be handled just fine by having the server send presence
updates to the “invisible” client.

Having it negociated by the client adding a feature to their own
stream:features may be useful, but I can also see the opposite argument
that sending it unconditionally wouldn’t break anything.

Thanks,

-- 
Emmanuel Gil Peyrot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170527/88eddb78/attachment.sig>


More information about the Standards mailing list