[Standards-JIG] SASL and JEP-0124

Ian Paterson ian.paterson at clientside.co.uk
Mon Apr 12 19:05:34 UTC 2004

I expect we will post a new version of JEP-0124 with many changes next week.
It will address issues like ensuring 'simultaneous' requests are processed
in order, and coping with broken HTTP connections.

Matthias wrote:
> - Is a body element with type='transmit' required to have children? What
>   is the difference in handling type='transmit' and type='poll'?

Yes, type='transmit' is required to have children, type='poll' may not have

When sending to the server, the only type that is technically necessary to
differentiate requests is 'terminate'. The other three values ('transmit',
'poll' and 'initialize') could have been defined with the same type
('initialize' requests have no sid). JEP-0124 only specifies different types
to help developers read the protocol.

Peter wrote:
> I wonder if the distinction is all that valuable. A transmit
> with no child would then really be the same as poll, no?

Yes. If people think that it makes implementaion easier, then in the new
version of JEP-0124 the types 'transmit' and 'poll' could be merged into one
optional type 'normal'?

> - When enforcing the maximum polling frequency, should only be the
>   type='poll' requests counted or should I account the type='transmit'
>   requests as well?

Only poll requests. I'll try and make that more clear.

> - If the connection manager keeps a connection open because no stanza
>   from the server has yet arrived and the client wants to send the next
>   message ... must the client wait for the first connection to
>   finish or does it start the next connection and the connection
>   manager is suposed to close the preceding one?

Normally, the client MAY open a second HTTP request (with HTTP 1.1 the
connection may already be open). If it does then the connection manager MUST
reply immediately to the first one.

The new version of the JEP-0124 will be much clearer about non-polling
behaviour. It will also allow a server to limit the number of simultaneous
connections a client is allowed to make, by including a new 'requests'
attribute in its response to each 'initialize' request. I expect 'requests'
will normally be set to '2'. However servers that only support polling
behaviour may prevent simultaneous connections by setting 'requests' to '1'.

More information about the Standards mailing list