[Standards] Proposed XMPP Extension: User-defined Data Transfer

Jonas Schäfer jonas at wielicki.name
Tue Dec 31 11:12:46 UTC 2019

31 Dec 2019 12:00:36 pm Marvin W :

> On 12/31/19 8:01 AM, Jonas Schäfer wrote:
> > I do not see anything wrong per se with XEPs built for a very specific API. We have that already with the XML-RPC embedding (which went somewhat out of fashion).
> >
> I don't think this comparison makes a lot of sense.
> Assuming you refer to XEP-0009, this describes a way how to use an
> existing, well-known protocol inside XMPP. However, neither XEP-0009 nor
> XML-RPC spec define, how this transport protocol should be exposed in
> the API of client libraries - and as far as I know, there is also no
> such common API for XML-RPC libraries.
> If this was about using JSON instead of XML for RPC calls, it should
> just rely on the JSON-RPC protocol.


> > Maybe it would also be worth to move the API description into its own Informational XEP (like we did for XEP-0300) or an XSF external document. This would also allow to evolve the API independently of the wire protocol.
> >
> I'd be happy with splitting into two XEPs: one Standards track for the
> wire protocol and one Informational XEP "Best practices for library
> implementations of User-defined Data Transfer" (or sth alike). I'd still
> question the usefulness of the wire protocol (compared to specifying in
> that Informational XEP a library API that doesn't require a new wire
> protocol but provides the same features with probably even a lower
> overhead),

I'm not sure how this can work without extra wire protocol if the stated goal is to transport a blob of JSON alongside a string which identifies its type. The goal comes, as Dave noted in his email, from in-the-wild use of XMPP. And even I cannot argue the benefit of that (and I certainly don't like JSON).

Nevertheless, if that's all more reason to split API and wire format. If you have a suggestion on how to solve this without new wire format, that could be written down in the API XEP and the proposed format could be deprecated.

> but that shouldn't keep either of the two from becoming
> Experimental (remembering that Experimental means that it should not be
> part of released software).
> The current proposal IMO stretches the definition of a Standards Track
> XEP too much to be accepted on that track.
> Marvin
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

Jonas Schäfer
This was sent from mobile, and I'm not good with those. Sorry for brevity and such.

More information about the Standards mailing list