On 2013-05-23 07:11, Anne van Kesteren wrote:
On Wed, May 22, 2013 at 12:20 PM, Janusz Majnert <j.majn...@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

Reply via email to