[whatwg] Fetch: please review!

[Janusz Majnert]

On 2013-05-23 07:11, Anne van Kesteren wrote:
> On Wed, May 22, 2013 at 12:20 PM, Janusz Majnert <j.majnert at samsung.com> wrote:
>> I have a few notes to make on the use of "byte string" notion.
>> First of all, let's look at the definition of "byte string":
>> "A byte string is a byte sequence written down as a string."
>> Where "byte" and "string" are:
>> "A byte is a sequence of eight bits, represented as a double-digit
>> hexadecimal number in the range 0x00 to 0xFF."
>> "A string is a sequence of code points." and later "A code point is a
>> Unicode code point and is represented as a four-to-six digit hexadecimal
>> number, typically prefixed with "U+"."
>>
>> So, just by looking at the definition, I would expect a byte string to be a
>> sequence of hex numbers. That is of course not what is put in the examples
>> and not what this definition aimed for.
>
> If you have a better way to do this, please do suggest. This problem
> has been introduced by HTTP and I think it's important to make sure we
> carefully distinguish between what are actually bytes and what are
> strings, while still maintaining the readability of Content-Type over
> expressing that as a sequence of hex numbers.
Why not use just "ASCII encoded string"? If I'm not mistaken, whenever a 
"byte string" is used in this spec, it is meant to indicate that the 
value should be compared byte-by-byte with a respective constant given 
in the text of the spec. Each of these constants has just one 
unambiguous representation in ASCII. Comparing two ASCII encoded strings 
is also unambiguous.

>
>> The second note is more of a question: why is the "byte string" even used?
>> Why not use just string? The document contains just one occurrence of plain
>> "string" and could very well be replaced with a byte string.
>
> Well, e.g. XMLHttpRequest has both and code points are quite distinct
> from bytes so it seemed useful to have them as distinct concepts.
I would refrain from introducing additional definitions just because 
they are also used in some other specs, even if they are related.



Best regards,
Janusz Majnert
Samsung R&D Institute Poland
Samsung Electronics