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