[Standards] Proposed XMPP Extension: Bind 2.0

Florian Schmaus flo at geekplace.eu
Wed Jan 18 13:16:52 UTC 2017


On 18.01.2017 14:05, Kevin Smith wrote:
>> On 17 Jan 2017, at 22:09, Florian Schmaus <flo at 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
>>
>> 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.

I feel like it is so trivial to change bind2 towards a flexible approach
that it's worth having that specified right from the beginning. I could
imagine use cases where I want MAM but not Carbons. Or MAM, Carbons and
SM, Or just MAM and Carbons.

And I'm curious what Dave further desires. @Dave: Care to drop a few
lines to elaborate?

- Florian

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


More information about the Standards mailing list