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

Matthew Wild mwild1 at gmail.com
Wed Dec 4 23:30:53 UTC 2013


On 4 December 2013 23:13, Alexander Holler <holler at ahsoftware.de> wrote:
> Am 04.12.2013 23:22, schrieb Matthew Wild:
>
>> On 4 December 2013 22:09, Alexander Holler <holler at ahsoftware.de> wrote:
>>>
>>> But the first hurdle everyone who wants to receive (and understand) XMPP
>>> messages is to get some XMPP-parser on the start and modify it such, that
>>> it
>>> can handle XMPP-streams. And that already does cost a lot of time. And I
>>> think most people don't have much interest in writing their own
>>> XML-parser,
>>> if all they want to do is to send and receive some messages.
>>
>>
>> It is a myth that XMPP requires custom parsers. Prosody uses a
>> completely unmodified Expat - any SAX parser should work just fine for
>> XMPP, and most languages and environments have one available.
>
>
> Who said that custom parsers are necessary? Maybe modify was the wrong term,
> but e.g. you might have same problems when you feed them with the initial
> <stream:stream>, because doing so, you almost never would get a some
> wellformed XML. ;)

Hmm, no, streaming parsers don't care about receiving data in
arbitrary pieces. That's why they're called "streaming" :)

> And just using totally unmodified parsers might be risk, at least if you
> don't use additional steps to prevent unwanted things like stanzas in sizes
> which would eat your available memory, or that problem many expat using
> XMPP-servers have had (can't remember if it was CVE-2009-3560 or something
> else).

Yes, you bring up a good point here - without any explicit framing in
XMPP it's quite tricky to determine stanza size before parsing (also
stanzas can span multiple TCP packets). It is certainly still possible
to still implement stanza size restrictions, it's just a bit more
fiddly. You can count how many bytes you feed into the parser between
events, and abort processing if you go over various limits.

This is something we can perhaps revisit now we're seeing XMPP over
various framed transport protocols such as websockets. And when the
internet switches to message-oriented SCTP we can drop TCP and
streaming parsers completely :)

Regards,
Matthew



More information about the Standards mailing list