Re: FYI... Binary Optimized Header Encoding for SPDY

Aha. I had a discussion that reminded me of one of the reasons to dislike
utf-8

If we use ascii, we KNOW we can drop the first bit, which means we get a
possible 12.5% compression trivially.
I'd rather have the complexity in encoding and reduce complexity on
compression. Of course, if we're willing to all implement huffman coding,
this isn't a problem, but that is substantially more complexity than
dropping a bit off every character.

Are we willing to implement huffman coding? It'd certainly make me happy.

-=R

On Tue, Aug 7, 2012 at 5:06 PM, Roberto Peon <grmocg@gmail.com> wrote:

>
>
>>>> It doesn't buy the protocol itself much. But it buys the users of the
>>>>
>>> protocol a lot.
>>>
>>> Which users? I'm having a hard time imagining why metadata has to be
>>> utf-8.
>>>
>>>
>> names: File names, user names, country names, domain names, protocol
>> names, User-Agent: names, Server: names, Accept-* names, type names ...
>> metadata is chock full of names when you start looking at it closely. And
>> "for some strange reason" people around the world insist on being able to
>> send/receive them in different languages and non-American spellings nowdays.
>
>
> I think that allowing something used for names where the character set was
> not constrained and whose visual representation is not always defined and
> often ambiguous for names where being able to tell uniqueness is an
> important security property was a royally stupid decision. Frankly, I could
> care less if names were represented in chinese characters, egyption
> pictographs, or what have you so long as they're unambiguous.
>
> In any case, that ship has sailed.
> I think you have a convincing argument... it still "smells" wrong to me,
> and I'll attempt to ponder why. If I don't come up with anything, I won't
> argue against it :)
>
> -=R
>
>