[Standards-JIG] Re: [Members] Stream compression (JEP-138) and notification of failure or success

Peter Saint-Andre stpeter at jabber.org
Wed Jan 11 17:08:28 UTC 2006

I chatted with someone (I think Jakob Schroeter of the Gloox project) 
about this over IM recently and I agree that we need to make the flow 
more explicit in the JEP.

The intent was that once the server sends <compressed/>, both client and 
server MUST send any future traffic in compressed mode (beginning with 
the new stream).

So I suggested to Jakob the following changes:

In the paragraph that reads "If no error occurs, the receiving entity 
MUST inform the initiating entity that compression has been 
established", the text should say "negotiated" rather than 
"established". Then in the next paragraph we need to say that 
compression begins with the new stream.

I don't see a need to change <compressed/> to <compress/> in order to 
clarify this point.


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060111/9ca8cada/attachment.bin>

More information about the Standards mailing list