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

Jonas Wielicki 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?

For sure.

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


kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170527/d79d0d28/attachment.sig>

More information about the Standards mailing list