> > Spark uses a special variant of XEP-96 that apparently breaks > > compatibility with every other client, most likely due to x:data > > ambiguity. I'd suggest the Spark guys make an extension that is less > > prone to misinterpretation. > > I don't know what the best solution is in this situation. We want Spark to > be compatible as can be in this case but if we were to move to strictly > interpret the XEP this would cause a degradation in the file transfer > experience in Spark, as you can see it was a lose, lost situation.
As I wrote, maybe it is possible to make an extension that won't be misinterpretted. Rather than fiddling with the x:data form, how about going the traditional route and adding some new namespaced elements/attributes? We can take a time machine back to 2003: http://mail.jabber.org/pipermail/members/2003-August/002570.html -Justin
