[Standards] Proposed XMPP Extension: Multi-stage IBR

Stephen Paul Weber singpolyma at singpolyma.net
Fri Feb 5 20:07:42 UTC 2016


> Firstly, this is altering a Final XEP via the backdoor, by reusing the  
> same  XML namespace for an altered protocol. This is trivial to fix - just 
> use a different namespace

This is barely an alteration.  In fact, I originally thought this would work 
with XEP-0070 until is seemed no client implemented this.

If we used a different namespace, we'd lose the backwards-compatability, 
which I think would be pretty unfortunate.

> Secondly, I expect there to be resistance to using a hardcoded set of
> elements rather than a form.

There's no intent on my part that this be "rather than a form".  
I explicitly copied the " If the host requires additional information above 
and beyond the data elements specified in the schema, it SHOULD use Data 
Forms as described in the Extensibility section of XEP-0077. " -- 
realistically I expect many implementations to use forms (most that I see 
already do for XEP-0077), but to keep it compatible as an extension of 
XEP-0077 of course one would need to support both.  Since this isn't really 
a protocol-level change, just an interpretation change.

> Thirdly, my gut feeling is that once you swap the hardcoded element set
> with forms, it'll look remarkably like XEP-0050. XEP-0050 works for *most*
> cases where we use the old XEP-0077 protocol - registration for chatrooms
> and gateways

I'm unclear on where XEP-0050 fits in to the picture for structured 
interactions like this.  Registering (either with a server or with 
a gateway) isn't an "adhoc" command, but rather a known command that clients 
want to provide specific UI for (that is, it's not just in a big list of 
"commands the entity supports" as with the normal UI for XEP-0050).  Perhaps 
there could be (or is?) a registry of "well known" ad-hoc commands that 
clients could check for the support of and omit from the normal XEP-0050 UI 
and provide seperate UI for them?  If that makes sense.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160205/33faa400/attachment.sig>


More information about the Standards mailing list