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), 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-unsubscr...@xmpp.org _______________________________________________
