[Standards-JIG] Re: JEP-0124: comments on proposed version 1.5

Ian Paterson ian.paterson at clientside.co.uk
Mon May 8 19:59:14 UTC 2006

Hi Bernhard,

The JEP was designed to bind as closely as possible to HTTP (including
using different HTTP codes), while enabling Web clients that run in
restricted environments (those clients are unable to differentiate
between the different HTTP error codes).

> HTTP Error Codes:
> 400, 403, 404 Error Codes makes problems for error handling. 
> PHP for example reports an error if a 404 is in the http header.

I'm not sure if you are saying that the PHP method you are using will
not allow you to send an HTTP error back to the client?

Alternatively, perhaps you mean you are writing a client in PHP (I'm not
sure why)? If so, if it receives an HTTP error code, then shouldn't it
report an error? After all, it doesn't even really need to know which
error was reported - the client should know anyway since it was probably
not conforming to the protocol.

> If for example the sid, rid is not valid this is not a http 
> error. It is 
> a http-binding error and should be
> reported with 200 OK and an error message like in example 38.
> Here an example (http-bind proxy written in PHP): 

Your example appears to enable a client to connect to a PHP proxy which
in turn connects to a JEP-0124 proxy which in turn connects to an XMPP

The JEP is not designed for that. But if you really want to do it, then
IMHO, if there is a problem it is with PHP (is there really no solution
within PHP?).

Wouldn't it be more efficient to install a standard JEP-0124 connection
manager in proxy mode? Or write your own in PHP? Is the problem that you
don't have sufficient control over any of the three servers involved? Is
that a typical enough reason to justify rewriting the protocol at this

- Ian

More information about the Standards mailing list