IoT SIG - 2023-12-16


  1. debacle

    Hey "@all" (fortunately, XMPP has no "mention-all"!): What do think about a XEP "ProtoBuf Containers". Just like "XEP-0335: JSON Containers" by MattJ, but for ProtoBuf. How would we encode it? Just hex? Base64?

  2. flow

    well base64 > hex

  3. flow

    I guess at one point we may want to mime things up

  4. flow

    BaseXML would be even better than base64, but compatiblity

  5. flow

    to summarize: a mime(-like) container format which has base64 as mandatory to timplement but other encodings like BaseXML can be signalled, therefore negoiated and used

  6. debacle

    flow I need to check what BaseXML actually is ;-) I guess something like base64 with larger alphabet and without '<' and '&'?

  7. debacle

    flow Found https://github.com/kriswebdev/BaseXML

  8. debacle

    flow IMHO, the efficiency gain of `BaseXML` compared to base64 is too small to justify its use. `base64` is supported by most environments already, hopefully implemented in an efficient way. I can imagine, that if stream compression is applied, it works better on base64 than on BaseXML, leading to similar results. Tests are left as an exercise to the reader, but I assume similar results as for `base122`: http://blog.kevinalbs.com/base122

  9. flow

    debacle, the point I tried to express is that while base64 should be mandatory to implement, it is trival to design a specification in such a way that it also allows other encodings like BaseXML if all involved parties want to use that

  10. debacle

    flow Yes, I understand the beauty of a flexible design. But I'm not sure, if it is worth the trouble for a (assumed by me) small user base for such a feature (= ProtoBuf over XMPP). I hope for a super-minimalistic XEP just like 0335 :-) ATM, it is not urgent for me anyway, because we (= my employer) just use JSON and will add stream compression soon. PB is a vague idea for the future. Or we look at EXI, again.

  11. flow

    debacle, absolutely understandable. I just have my "what I believe would be best for the XMPP ecosystem" goggles on

  12. flow

    and note that compared to xep335 a protobuf xep requires binary encoding

  13. debacle

    flow Sure, in the JSON container format there was no open question, while for PB there is.

  14. flow

    and at that point, we may as well define a generic xep that specifies the binary content (hence my comparision with mime) and the used encoding

  15. debacle imagines taking a year off to write a MIME XEP ;-)

  16. debacle

    I wonder, if there is precedence for using `base64` or other techniques in any XEP?

  17. debacle

    I wonder, if there is precedence for using `base64` or similar techniques in any XEP?

  18. flow

    Base64 is widely used in XMPP, a prime example is SASL

  19. flow

    and btw, writing a mime xep is probably a matter of hours (and I wouldn't be surprised if we hadn't one already)

  20. flow

    the main problem is that there seems to be no protobuf entry in the mime registry