On Sunday 08 June 2008 4:23 am, JabberForum wrote:
> > The basic idea behind XTLS is that two XMPP entities negotiate
> > an encrypted "tunnel" between themselves over XMPP. The tunnel
> > is negotiated using standard TLS handshake data, encapsulated
> > in In-Band Bytestreams. The entities can then exchange
> > TLS-encrypted XMPP stanzas over that tunnel.
>
> What about wrapping all stanzas into a single top-level XML element,
> so
> implementors won't have to start a new XML parser for each stanza?
Yes, I agree. As documented, the stream goes something like this:
[ immediate TLS handshake ]
<message/>
<message/>
<message/>
Parsing each message does require a new XML parser instance, or at least some
parser juggling, since the entire stream is not an XML document (in the sense
that we're all used to with XMPP-Core). If, after the TLS handshake
completes, the stream is parsed with an XML parser, you'll get one message
out of it, and then an error as soon as the '<' is encountered of the next
message (document not well formed error?).
I think the original intent with XTLS was to use a new parser instance for the
content of each TLS packet, but this violates the TLS abstraction. Treated
as a stream, we cannot enforce that a particular TLS packet contains an
entire XML document. A single TLS packet might contain many messages, and
one message might be split across many TLS packets.
Better that we change the stream to work like this:
[ immediate TLS handshake ]
<some_root_element>
<message/>
<message/>
<message/>
</some_root_element>
Now a single XML parsing instance can be used for the entire stream, and
message boundaries are determined by the XML parser, not by the IBB/TLS
packetization.
-Justin
