[Standards-JIG] XMPP bandwidth compression

Bob Wyman bob at wyman.us
Wed Jul 7 22:21:38 UTC 2004

Stephen Pendleton wrote:
>It seems to me that for the feature negotiation JEP-0020 is useful:
	I think this would not be ideal. The problem is that to use JEP-0020
you must have already opened up an XML Jabber stream and then you have to
suffer the overhead of the JEP-0020 roundtrips to negotiate with the server
to get a new non-XML stream. Even if the roundtrip costs are ignored, you
are still faced with the problem that upon completing the JEP-0020
negotiation you will have an open XML stream which must be closed and
reopened before you can push non-XML data over the link.
	Personally, I think that if non-XML streams are supported as
alternatives, then the request for such a stream should be part of the
stream initiation. The server would then respond either with an XML stream
(the default and the fallback), which all clients should be required to
understand, or stream using the requested alternative encoding (something
like Fast Infoset). This avoids the negotiation roundtrips as well as the
problem of closing the XML stream and opening a new alternative format
	Note: For this to work properly and to ensure that interop is not
compromised, it is important to insist that "Jabber/XMPP compliant" systems
must always be capable of supporting the XML format. (Clients that were so
constrained that they simply can't support XML should at least be required
to recognize that their request for an alternative stream format was
rejected and be capable of closing the stream, using normal text-based
Jabber XML, once they discover the rejection.
	Given that the method I outline above impacts stream initiation, I
think it would be necessary to do this as an extension to XMPP rather than
as JEP although a JEP might be used for experimental purposes until the
entire process was understood, debugged, etc. and an RFC could be put
through the system.

		bob wyman

More information about the Standards mailing list