[Standards] Proposed XMPP Extension: Bind 2.0

Florian Schmaus 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?

Something like

<bind xmlns='urn:xmpp:bind2:0'>
  <action type="urn:xmpp:mam:1"/>
  <action type="urn:xmpp:carbons:2/>
  <action type="foo:bar"/>
  …
</bind>

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

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170117/f299df28/attachment.sig>


More information about the Standards mailing list