[Standards-JIG] Re: JEP-0124: comments on proposed version 1.5
vinod.p at gmail.com
Fri Apr 28 05:46:15 UTC 2006
On 4/28/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Ian Paterson and I discussed these items off-list. I modify my questions
> and comments as follows...
> Peter Saint-Andre wrote:
> > In today's Jabber Council meeting , we discussed the proposed
> > revisions to JEP-0124.   I promised to provide some comments. Here
> > they are. :-)
> *Some runtime environments constrain the number of simultaneous HTTP
> requests a client may make to each connection manager; if such clients
> need to connect using more than one account at the same time, then
> support for multi-stream sessions is essential.
> * While XMPP does not allow two sessions with the same full JID to
> be open at the same time, it does use one stream in each direction for
> client-to-server connections; support for multiple streams enables
> clients that connect via the HTTP Binding to emulate that behavior and
> thereby reduce network traffic.
Shouldn't multi-stream support go into a separate JEP? This could be
used on both ends of a JEP-0124 implementation. Eg. an HTTP client
using multiple streams to a JEP-0124 server, and the JEP-0124 server
using a single tcp connection with multiple streams to an xmpp server.
> While it is currently envisioned that implementations of the protocol
> specified herein will mostly be used as connection managers for XMPP
> servers, management of connections to non-XMPP implementations is also
> possible. Furthermore, a connection manager that implements the HTTP
> Binding will simply act as a pass-through mechanism for XML (not
> necessarily XML that conforms to the schemas for the 'jabber:client' and
> 'jabber:server' namespaces as specified in RFC 3920 and RFC 3921).
> Therefore, the XML schemas defined herein are explicitly not limited to
> XMPP. Any error handling for non-XMPP elements and attributes is the
> responsibility of the application using such a connection manager, not
> the connection manager itself.
Great! This widens the scope for JEP-0124 implementations.
More information about the Standards