- From: Janusz Majnert <j.majnert@samsung.com>
- Date: Mon, 27 May 2013 08:32:31 +0200
- To: whatwg@lists.whatwg.org
On 2013-05-23 07:11, Anne van Kesteren wrote: > On Wed, May 22, 2013 at 12:20 PM, Janusz Majnert <j.majnert@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
Received on Monday, 27 May 2013 06:33:16 UTC