[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...
Size: 819 bytes
Desc: Digital signature
More information about the Standards