[Standards-JIG] Stream compression (JEP-138) and notification of failure or success (repost from JSF Members)

Sebastiaan Deckers cbas at pandion.be
Wed Jan 11 16:48:49 UTC 2006

I agree with Gato.

One suggestion: change <compressed/> to <proceed/> so that developers 
understand this behaviour is like with TLS negotiation.
Clarifying the wording of the JEP would help too.


Gaston Dombiak wrote:

> Hey guys,
> When implementing JEP-138: Stream compression my initially understanding
> was that <compressed> was being sent by the server once he was able to
> switch to compression mode and all validations have passed (e.g.
> compression is available, compression is not already in use, etc.).
> However, when testing against Pandion I found that Pandion was waiting
> for the <compressed> notification to be sent before compression is
> active.
> The reason for that is that the client was expecting a confirmation from
> the server saying that there was no <failure> and that compression can
> be established. And if a <failure> stanza was sent to the client then
> the client will still be able to parse it since compression is still not
> active. In other words, <compressed> is being used just like <proceed>
> in TLS.
> After chatting with Sebastiaan Deckers (author of Pandion) I decided to
> change Wildfire implementation and follow the way Pandion was using it
> since the explanation seemed logical to me. Moreover, Soapbox is also
> following this idea. I wanted to test wildfire with Exodus in order to
> confirm that exodus is also following this approach but until now I was
> not able to obtain a binary version of Exodus that supports stream
> compression.
> Since we now have 2 servers and 1 confirmed client that are using
> <compressed> as <proceed> in TLS, I was thinking that we might need to
> make a few small changes to the JEP. We would need to change
> <compressed> to <compress> and also make it more clear that <compress>
> should be sent before compression is active and after all validations
> have passed (i.e. no <failure>)
> What do you think?
> Regards,
>  -- Gato

More information about the Standards mailing list