[Council] VOTE: JEP-0138 (Stream Compression)
stpeter at jabber.org
Tue May 17 17:42:24 CDT 2005
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".
> 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?
Compression is OPTIONAL so I would say the initiating entity SHOULD
> - If the recipient requests a method that does not exist, what then?
I sense the need for some error elements qualified by the compression
- <compression-failed/> (a catch-all condition)
> >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.
>  My personal feeling is the recipient should ignore such a request,
> but some implementations may consider this some sort of electronic
>  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?? ;-)
More information about the Council