[standards-jig] JEP-0025

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Tue Feb 24 23:05:08 UTC 2004

On Tuesday 24 February 2004 2:22 pm, Barry Latimer wrote:
> If all that is required is a HTTP tunnel that allows XMPP to be sent over
> HTTP then couldn't a more generic tunnelling protocol be looked at?

JEP-25 is the first I've ever seen of such a spec actually documented, and I'm 
not aware of any others.

One of the first hits on google for http tunnelling is 'GNU Http Tunnel', 
though I have no idea what protocol it uses.

> 1) JEP-25 examples are incorrect (minor problem) as they say all request's
> from the client should be sent using the Content Type of
> "application/x-www-form-urlencoded" then the examples are not encoded (from
> previous experience this tends to means that you will get implementations
> that do not URL encode the data before sending it).
> 2) JEP-25 incorrectly uses a content type of "text/xml" for the server's
> response when the response sent back to the client is not a valid XML
> document fragment, in fact it is a "text/plain" document that the client
> needs to parse before it can use the xml fragment contained within.

Well, the content type is pretty much ignored.  Consider the text in Section 
3, third paragraph: "Both the request and response bodies are UTF-8 encoded 
text, even if an HTTP header to the contrary exists."

Of course, this sounds quite silly, and it might be worth updating the 
document, though I'd vote for application/octet-stream instead of text/plain.

> 3) JEP-25 forces both the server and client to use UTF-8 encoding
> regardless of what the HTTP headers specify. Which means that a developer
> is can be unable to use HTTP libraries that will automatically
> encode/decode the HTTP data. Also what happens when the data is sent
> through a transparent proxy that decides to use a different form of
> encoding ??

I think the rationale for this is that XMPP itself is in UTF-8 format.  
However, both the HTTP and XMPP layers cannot be UTF-8, otherwise you'd end 
up doubly encoding, which does not happen in existing implementations.  I've 
always interpretted this bit about UTF-8 in JEP-25 as a 'hint'.  But really, 
what you end up doing is considering the HTTP exchange as raw binary data, 
and then the UTF-8 format is processed in your XMPP engine.


More information about the Standards mailing list