[Council] VOTE: JEP-0138 (Stream Compression)

[Peter Saint-Andre]

FYI, I've updated the interim version to address these considerations:

http://www.saint-andre.com/jabber/jeps/jep-0138-0.5.html

Matt, does this meet with your approval? If so, I will publish a new
version of the JEP that we can vote on.

Peter

On Tue, May 17, 2005 at 09:01:25PM -0500, Peter Saint-Andre wrote:
> On Tue, May 17, 2005 at 05:40:59PM -0600, Joe Hildebrand wrote:
> > 
> > > Since stream compression MUST be negotiated in both 
> > > directions, we probably need to describe how to handle a 
> > > failure in one direction (e.g., do you drop the connection in 
> > > the other direction)?
> > 
> > Yes.  ANY failure causes stream to be dropped.
> 
> Could such failures include error conditions that arise after the streams
> are already negotiated? If so, it seems appropriate to use some existing
> stream error condition rather than a compression-specific condition,
> perhaps like so:
> 
> <stream:error>
>   <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
>   <failure xmlns='http://jabber.org/protocol/compress'/>
>     <processing-failed/>
>   </failure>
> </stream:error>
> </stream:stream>
> 
> We might want two different conditions, one for setup failure and
> another for processing failure (rather than one <compression-failed/> 
> condition).
> 
> > > Also, presumably an implementation or deployment could 
> > > require that the same compression method be used in both 
> > > directions, but it could enforce that by advertising only the 
> > > method already in use for the other direction so I don't 
> > > think we need any business rule about that in the JEP.
> > 
> > Nod.  Plus, if you wanted asymetric compression, you could define another
> > method name.
> 
> Sure. But we've got the registry, so folks can register those if
> desired.
> 
> /psa
>