[standards-jig] JEP-0025

Peter Saint-Andre stpeter at jabber.org
Tue Feb 24 21:44:00 UTC 2004

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.


More information about the Standards mailing list