[Standards] Proposed XMPP Extension: Bind 2.0
flo at geekplace.eu
Tue Jan 17 22:09:52 UTC 2017
On 17.01.2017 16:23, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Bind 2.0
> Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup.
> URL: http://xmpp.org/extensions/inbox/bind2.0.html
How do clients know which version of carbons got enabled?
I could live with Bind2 being hardcoded to MAM and Carbons. But is there
any particular reason why the <bind/> step should not be a flexible
atomic mechanism for resource binding and performing arbitrary actions?
and <bound/> returns the result of the action(s) (if any). Or an
meaningful error is returned, if one or more actions could not be
performed. That would also ensure that the versions requested by the
client got enabled.
+1 for removing client suggested resource parts.
Nit: Example 3 contains a comma
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards