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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
