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

[Peter Saint-Andre]

On Tue, May 17, 2005 at 11:37:32AM -0600, Matthew A. Miller wrote:
> My responses are inline, but there is one more nit (that won't hold this 
> JEP back from DRAFT):
> 
> The language should match RFC-3920 better. Specifically, using 
> "receiving entity" instead of "server", and "initiating entity" instead 
> of "client".

Good idea.

> Joe Hildebrand wrote:
> 
> >All I said on the list was "show me a *single* compression scheme that
> >has something to negotiate first".  Or something to that effect.  I'm
> >asserting that there are no compression schemes that require option
> >negotiation, and as such, adding it to the protocol makes it
> >unnecessarily complex.
> > 
> >
> My apologies, I somehow lost track of that last response. I'll retract 
> my first statement, but say that there needs to be actual discussion 
> aorund the steps, not just the examples. 

You're right. The JEP Editor should have caught that.

> A couple of things that spring to mind are:
> - In the offer (step 1), should/must there be at least one <method/> 
> (schema implies there can be 'one' to 'unbounded', if I'm remembering my 
> xsd correctly)?

There MUST be at least one <method/> child.

> - If the offer does not include any understood <method/>s, what should 
> the recipient do? Ignore it? Fail the entire connection?[1]

Compression is OPTIONAL so I would say the initiating entity SHOULD
ignore it.

> - If the recipient requests a method that does not exist, what then?[2]

I sense the need for some error elements qualified by the compression
namespace:

  -  <unsupported-method/> 
  -  <compression-failed/> (a catch-all condition)
  -  others?

> >I'm ok with making zlib mandatory to implement, if there's consensus for
> >that.  I've started to think that mandatory to implement isn't terribly
> >useful, since there's no way to enforce it meaningfully.  Even if it is
> >mandatory to implement, though, implementations still have to be ready
> >for it to not be turned on, and to react accordingly.
> >
> I assumed the whole point behind having <method/> was to specify what's 
> supported/deployed, and that a client that doesn't understand any of the 
> specified methods "does the right thing" (as with SASL).
> 
> Having a "mandatory to implement" gives disparate teams a baseline to 
> work from. They can have a reasonable assumption that at least this 
> method is likely. If the team(s) collaborate on their own requirements, 
> that's their discretion.
> 
> In other words, your argument doesn't convince me otherwise (-;

Making zlib mandatory to implement seems like a good idea to me.

> [1]  My personal feeling is the recipient should ignore such a request,
> but some implementations may consider this some sort of electronic
> albatros.
> 
> [2] This may seem pendantic, but we have other JEPs that go into this level 
> of coverage.
> 
> -- 
> -  LW
> 
> GOT JABBER?? <http://www.jabber.org/>

Got pedantry?? ;-)

/psa