[standards-jig] JEP-0025

Barry Latimer 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 ??


-----Original Message-----
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
more fully.

> 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 mailing list