[Standards] [Operators] Future of XMPP Re: The Google issue

Alexander Holler holler at ahsoftware.de
Thu Dec 5 01:46:50 UTC 2013


Am 04.12.2013 23:48, schrieb Peter Waher:

> One option, though, is EXI, which "knows" - with some encouragement - to ship values as binary even though in traditional XML serialization, they'd be base64 encoded. My only worry is that the level of benefit that this gives is rapidly eroded by how good XML parsers have got, especially when you consider the overhead that known-schema causes to the complexity of the protocol.

Hmm, I think the question is wrong. It shouldn't be "what are benefits
when using a binary represention which doesn't need a XML-parser", it
should be "why use a XML-parser at all"?

XML might be fine for the message content itself, e.g. if someone likes
stuff like HTML-messages, but I don't see why one should take the
overhead (regardless how small or large that is) of using XML for the
metadatas and other communication related stuff which is only handled
internally by software. Why would I want to use e.g. a string instead of
a (bingary) number to specify an attribe if no human will see the string
(or number) at all? That is, in my humble opinion, just totally
unnecessary overhead. Nobody does type stanzas by hand, humans only
enter and see the content (excpet for debugging purposes, but for those
the SW can represent the binary stuff in any form, even translated to
XML). And in times of encryption the stuff on the wire already isn't
readable anymore.

But thanks a lot for the pointer to EXI, I'm not up-to-date with all the
new existing protocols (and will have a look at EXI) and just started
that discussion in response to using XMPP for M2M. It wasn't my
intention to change XMPP or speak about XMPP 2.0, I just wanted to
mention that I would not like to use XMPP in the existing form for M2M.
Unfortunately that ended up in a discussion about XML-parsers and why
change XMPP. ;)


Alexander Holler

More information about the Standards mailing list