Re: [hybi] deflate-stream and masking

You sound frustrated, Greg.    I understand that.

On the one hand, we could throw our hands up in frustration and either start
over, or fork the existing work.   Either way, the browser vendors would
need to ratify (by implementing) the protocol.

On the other hand, we could push the current design to standardization, so
that the browser vendors can do final implementation and we all can start
using the 20% of it that isn't borked.  Of course, if we remove a feature or
three beforehand, then the browser folks have to do less and can ship
sooner.

Please try to forgive the dreamers who have gilded our kitchen sink.   It is
a thrilling and intoxicating thing to do protocol design - it leads one to
do stuff because you can imagine it, not because it's actually needed.

I'd be happy to help with whichever of the above courses of action that
 gives me a lightweight asynchronous persistant connection between scripts
running in an easily available, off the shelf, bog standard browser client
and whatever server abomination I come up with, as soon as possible.

On Wed, Jul 20, 2011 at 10:29 PM, Greg Wilkins <gregw@intalio.com> wrote:

> On 21 July 2011 05:48, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> > My reading of the discussion is that people don't necessarily want to
> throw
> > out deflate-stream, but they don't think it belongs in the base spec and
> > they would prefer to see it defined in a separate draft, just as you
> propose
> > for deflate-frame.
>
> My reading is that there is a mix of opinions.  Some want it thrown
> out, others want to keep it.
>
> What I want to know is how (yet again) has a feature with such divided
> support made it into the spec.  Why does this WG insist on putting non
> consensus features into the spec and then having the argument to
> remove them or not.   The status quo should not be to have a
> non-consensus feature included.    It should be for the proponents of
> a feature to make their case for inclusion and not for the opponents
> to make the case for exclusion.
>
> While it would be good for the base spec to have both compression and
> an exemplar extension - that is no reason to just accept any old
> extension that is neither good compression nor a good exemplar.
>
> I also understand the argument that deflate-frame should just be
> written up in another draft - by why does that not also apply to
> deflate-stream?
>
> If we are going to have a favoured son, can't we pick the healthy one
> with some good prospects rather than the black sheep that is going to
> end up dead or in jail?
>
> regards
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>