[standards-jig] Thoughts on JEP-0025

Matthias Wimmer m at tthias.net
Fri Jun 7 20:57:07 UTC 2002

Hi M.!

M.Kiesel schrieb:

>[Feature negotiation]
>Any example for such an XML document?- I would recommend not to complicate
>it too much.
I don't think it's to complicate to use XML for that. On the server side 
this document can just be a static thing - on the client side we already 
have XML parsers.

An example how this could look like:

<?xml version="1.0"?>
<jabberpolling xmlns="http://jabber.org/jabberpolling">
    <!-- show that we support the old JEP-0025 protocol -->

    <!-- show that we support the new extendable polling protocol -->
    <extendable-polling version="1.0">
        <!-- we support SHA magics to protect the pollings -->
        <!-- we support destination addressing -->
            <!-- the destionations we offer -->
            <jabberc2s host="jabber.org"/>
            <jabberc2s-ssl host="jabber.org"/>

    <!-- maybe other polling protocols we support -->

The polling request format can be based on what you already suggested, 
but some things I'd like to change:

- I don't think we have to end the list of tokens with a # token. We 
just can use an empty one.
- It should be possible for the server to detect if the client decided 
to use traditional JEP-0025 or the extendable polling protocol.
  Therefore is propose to start the token list with a comma for the 
extendable protocol, that is a char that is never the first char in a 
JEP-0025 request.
- To be able to have more then 26 (A-Z) tokens I propose the separate 
"token name" and "token content" (maybe I should call it header type and 
header content) with a space char.

A sample request could look like this (I don't show HTTP headers because 
we don't have IDs in it anymore):

initial request:
,EXT 1.0,C 0,N ae01d95cd6f28b1c9873708892714696810d866d,,<?xml 
version="1.0"?><stream:stream to="jabber.org" xmlns=".....

initial reply:
,C 7776:2054,,<?xml version="1.0"?><stream:stream ....

next request:
,C 7776:2054,H 767425dde2d5512172662986b34d3ef9d3e911d0,,<some other 
jabber stream data/>


request with a new hash:
,C 7776:2054,H 70c87a5da2f863a8a91940d812d48137ee055163,N 
374b865bb4e96c0033706d29134eade5279f1908,,<some other jabber stream data/>

if the server detects an error, I would propose not to indicate this 
with a new session ID but in a way like this:
,C 7776:2054,ERR -1:0,,<content of this reply could be a textual error 

>I would however not suggest to use any session IDs if not necessary (for
>example with the hash thing I proposed) for they would waste bandwidth
>then. Keep in mind that here with polling every some seconds every
>additional byte in the request/answer packets will cause a lot traffic
>summed up.
I think compared to what we already transmit (headers of IP, TCP and 
HTTP) a session ID is not much traffic. And I don't think it's a waste 
of bandwidth: With session IDs the polling server can easily access the 
context of a session with a fixed key in a hashed data structure. When 
we use the hash as session ID it changes from request to request. We 
either have to search a list of all open connections with each request 
then or we have to update the key in the hash every time (that means we 
have to copy the context with each request).

>I'd say every 5 seconds if busy, every 40 seconds if idle. But after all
>it's a client thing. Whatever you say I would bet client developers will
>use fixed polling intervals ;-).
Peter already wrote that he had implemented this in Exodus and I have 
implemented this in the JabberApplet extension too.

>BTW did anyone take a look at for example GNU httptunnel?- Maybe it would
>be a good idea to use some existing mechanism for http tunnelling. Maybe
>not. I'm not sure.
Where can I find information on this project?

Tot kijk
Fon: +49-700 77007770		http://matthias-wimmer.de/
Fax: +49-89 312 88654		jabber://mawis@charente.de

More information about the Standards mailing list