[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [hybi] WS framing alternative



> You are proposing that given a length and a series of bytes encoding
> text
> in a variable-sized encoding (UTF-8), the application return a series
> of
> characters.

Sure.  It's like the old argument over whether C or Pascal strings are better.  It's not really a fun argument.  It was not my intent to argue over the merits of either approach.

The point was to allow for arbitrary binary content as well as UTF-8 text together.  The point was to adopt a framing scheme that would allow for MIME.  If you want to avoid the problem you refer to (which I don't see as being as big as you make it out to be), then that's quite difficult if you want to allow for binary data - hence the two framing schemes in WS.

...
> Regarding the rest of your e-mail, I don't disagree with the facts, but
> I
> disagree with the cost-benefit analyses, with your opinion of what is
> and
> what is not an acceptable risk, and with some of your goals. I don't
> know
> of any objective way to argue those points, and I agree that if you
> start
> with your positions, that you wouldn't develop WebSockets the way it is
> currently specced.
> 
> What is the process for proceeding in the IETF when people have
> fundamentally different and mutually exclusive opinions?

I believe that we use the methods of the Sophists.  We beat each other around the head with rhetoric.  Then we either come to a compromise, someone concedes, or the different parties begin to enjoy the argument too much and we end up with proprietary solutions.

Thankfully, we aren't arguing in a vacuum.  I'm happy to cede to the will of a majority on the issue, just as I hope that you are.  And deployment counts for a lot.  Until I feel that I'm arguing without support, I will continue to argue for a text-based protocol with (marginally) greater provision for extension than currently exists.

--Martin


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.