Previously the SASL2 XEP used a base64 encoded challenge-response flow for it's tasks. That allows challenges and responses to be of arbitrary payload, but makes it difficult to encode information when defining SASL2 tasks for XMPP in future XEPs. One example we came across ourselves are the SCRAM upgrade tasks. For these upgrades the server needs to send the client the used salt as well as the iteration count to use. Encoding this into a base64 string would involve to either develop some arbitrary text-encoding (like "s=xxx,i=4096") or base64-encode XML. Both is not perfect and could be even more problematic for other SASL2 tasks.
We therefore decided to use XML for SASL2 tasks. To make the protocol flow easier, I've pushed an update to the PR adding a wrapper-element to the SASL2 protocol flow for tasks: https://github.com/xsf/ xeps/pull/1214/commits/251800fabb9ac4fd095f9b04a04f062022c94dbe This <task-data/> element can contain any element defined in a future specification of the task in question. For SCRAM upgrades, the task is defined in this split-out ProtoXEP over here: https://github.com/tmolitor-stud-tu/xeps/commits/scram-upgrades (rendered version: https://dyn.eightysoft.de/final/xep-scram-upgrade.html ) For other tasks the SASL2 gives a fictional example using base64, too: https:// dyn.eightysoft.de/final/xep-0388.html#example-14 SASL2 tasks originally defined for another protocol (say SMTP) could now still use base64 while other tasks only defined for XMPP could use the richer and more readable XML variant. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
