[Standards] NEW: XEP-0390 (Entity Capabilities 2.0)
jonas at wielicki.name
Sat May 27 09:01:18 UTC 2017
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.
In addition, clients might want to get updates on the servers features even
though they themselves never send presence.
> > If we choose to use stream elements, we can send <caps/> nonza. I think
> > there should be some consistency.
> This will require some signaling from the client that it is able to
> parse those nonzas. Otherwise some clients might break if they
> suddenly receive unknown stanzas?
> But this signaling could be done with a caps feature? (The server does
> have the clients feature list anyway, right?)
That would work.
Any other ideas?
I remember that Dave suggested to have a caps stream feature which can be
negotiated, which would also allow the server to know the features of the
client before the client has sent presence; that can be relevant e.g. for MIX
where crucial server behaviour (e.g. roster contents!) depends on client
That way, when the client negotiates the to-be-defined caps feature, the
server could know the client supports it and understands <caps/> nonzas (or IQ
updates or whatever mechanism is used to inform the client about changed caps
for the server).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards