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

Matthew A. Miller linuxwolf at outer-planes.net
Tue May 17 12:37:32 CDT 2005


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".

Thanks for the hard though!

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. I'm not sure why I didn't see 
and say this before.

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)?
- If the offer does not include any understood <method/>s, what should 
the recipient do? Ignore it? Fail the entire connection?[1]
- If the recipient requests a method that does not exist, what then?[2]

>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 (-;

[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/>



More information about the Council mailing list