> On 17 Jan 2017, at 22:09, Florian Schmaus <f...@geekplace.eu> wrote: > > 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?
A fair question. I think for now simply encoding the versions in the bind spec would make sense (for reasons in next paragraph). > 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> Dave has similar desires (going further than this, I think), and I don’t think they’re a bad idea. I just wrote what I thought was the minimal complexity to solve the issue. I noted in the body of the XEP that I anticipate aspects of the protocol changing over time - but I feel that one could implement what’s currently in the document (not saying which carbons version notwithstanding) and be done with most of the work such that a protocol change later would be close to trivial. So we could start getting simple test (or even deployment) solving these problems soon, while we work out the very best way to do it - I think some details of the perfect approach may end up ratholing, and I’m keen that we have a baseline we can work towards while we deal with those issues. > 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 Thanks. I’ll try to add hard-coded Carbons versions, and fix the comma this afternoon if I get some cycles. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
