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.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to