LatimerB at startcorp.com
Tue Feb 24 22:22:13 UTC 2004
After looking at both JEP-25 and JEP-124, I personally think that JEP-124 is more complete and the authors have spent more time trying to fit XMPP in with request-response methods of HTTP, whereas JEP-25 tends to try and create a HTTP tunnel between an XMPP server and XMPP client, but does not follow the all parts of the HTTP standard.
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? Otherwise I think that JEP-124 modifications to XMPP-Core are correct as HTTP is slightly different than a TCP channel.
Some problems with JEP-25
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.
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 ??
From: Peter Saint-Andre [mailto:stpeter at jabber.org]
Sent: Wednesday, 25 February 2004 8:44 AM
To: standards-jig at jabber.org
Subject: Re: [standards-jig] JEP-0025
On Mon, Jan 19, 2004 at 06:37:18PM -0800, Justin Karneges wrote:
> On Monday 19 January 2004 12:22 pm, Peter Saint-Andre wrote:
> > So it seems that we need to clearly define:
> > 1. The target audiences
> It seems that we have two target audiences here.
> 1) Those that are working with XML-streams, and want to leverage them in an
> HTTP Polling scenario.
> 2) Those that are working with HTTP & XML, and wish to utilize non-persistant
> > 2. The needs of each
> Each audience wants essentially the same thing, and that's XMPP over HTTP.
> The only real difference in functionality desired between the two groups is
> the way security is conducted. The first group would naturally prefer to use
> existing xmpp-core security. The second group would be content with HTTPS.
Well, a simple change to the schema defined in JEP-0124 would allow you
to do TLS over the connection, but it seems to me that the HTTP layer is
the right place for TLS in an HTTP binding.
> I think that if JEP-25 is going to be replaced, we need to establish why it
> should be replaced. Judging by the discussion so far, it seems that the
> rationale for JEP-124 is to provide an easier way for the second group to
> implement XMPP over HTTP, not that there is any particular deficiency in
> JEP-25. This is not a good enough reason to replace the JEP, in my opinion,
> especially if all it would do is reverse the situation (second group happy,
> first group not happy).
JEP-0025 has known deficiencies in the kinds of clients it can support.
Plus that weirdness with the HTTP body has always bothered me. But I was
mostly the scribe on JEP-0124, so others can probably explain things
> As an aside, it is interesting to note that JEP-25 is useful for applications
> beyond XMPP, as it simply provides a generic bytestream over HTTP.
> Considering this kind of technology is already pursued outside of the JSF
> (just google for 'http tunnel' to see other products), perhaps the JSF is not
> the appropriate place to maintain such a spec.
> > But JEP-0025 does require someone to write a server-side piece, no? No
> > mere Jabber/XMPP server accepts client HTTP connections out of the box.
> Right, JEP-25 code has to be written, but it can simply act as a proxy to the
> Jabber server. I believe this is how most available JEP-25 server stuff
> works. jabberd is never modified. The proxy doesn't even have to run on the
> same host, which is nice if you want JEP-25 access to a server that is not
> providing it.
Sure, same thing with JEP-0124 -- it'll be implemented (most likely) as
a connection manager.
Standards-JIG mailing list
Standards-JIG at jabber.org
More information about the Standards