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

Peter Saint-Andre stpeter at jabber.org
Tue May 17 21:01:25 CDT 2005


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




More information about the Council mailing list