This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The draft currently says: "An ASCII-compatible character encoding is one that is a superset of US-ASCII (specifically, ANSI_X3.4-1968) for bytes in the set 0x09, 0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A, and 0x61 - 0x7A." What exactly is meant? Is Shift_JIS Ascii-compatible (it encodes the US-ASCII characters at the same bytes as US-ASCII, but also uses these bytes as the second bytes in a multibyte character encoding). http://www.w3.org/TR/html5/forms.html#application-x-www-form-urlencoded-encoding-algorithm refers to ASCII-compatible, and in that context, I would want to have Shift_JIS be ASCII-compatible, but from the above definition, I'd lean to the conclusion that Shift_JIS may not be ASCII-compatible. Please clarify whether ASCII-compatible means that the above bytes are only used for US-ASCII character, or whether it means that for US-ASCII characters, only the above bytes are used. If you use ASCII-compatible in several places in your spec, you might have to check and maybe split the definition into two, to take into account different circumstances.
I've tried to fix this; please let me know if the new text is ok.
http://www.w3.org/TR/html5/infrastructure.html#ascii-compatible-character-encoding doesn't seem to be updated. I'm assuming you are working on an editing copy, if you tell me where it is, I'll gladly have a look at it.
Oh, yeah, you don't want to use the TR version, that's out of date even before it gets published. Use the WHATWG version, it's the most up to date: http://www.whatwg.org/specs/web-apps/current-work/ ...or alternatively the version on dev.w3.org, which is only slightly behind: http://dev.w3.org/html5/spec/Overview.html
Looking at http://dev.w3.org/html5/spec/Overview.html#ascii-compatible-character-encoding: This solves the problem, but is needlessly complex. Instead of An ASCII-compatible character encoding is a single-byte or variable-length encoding in which the bytes 0x09, 0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A, and 0x61 - 0x7A, ignoring bytes that are the second and later bytes of multibyte sequences, all correspond to single-byte sequences that map to the same Unicode characters as those bytes in ANSI_X3.4-1968 (US-ASCII). the following would say the same but would be simpler: An ASCII-compatible character encoding is a character encoding in which the Unicode characters that have bytes values 0x09, 0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27, 0x2C - 0x3F, 0x41 - 0x5A, and 0x61 - 0x7A in ANSI_X3.4-1968 (US-ASCII, [RFC1345]) are represented by exactly and only the same byte values. The note after that is also a good start, but also needs some more work. Shift_JIS is used on every Japanese PC and Mac, so I wouldn't call this an exotic encoding. On the other hand, I didn't find a *submitted* draft for UTF-8+names, so whathever you think about it, it's clearly a dead end at this point of time. So I would reword: Note: This includes such exotic encodings as Shift_JIS and variants of ISO-2022, even though it is possible for bytes like 0x70 to be part of longer sequences that are unrelated to their interpretation as ASCII. It excludes such encodings as UTF-7, UTF-8+names, UTF-16, HZ-GB-2312, GSM03.38, and EBCDIC variants. to something like: Note: This includes encodings such as Shift_JIS and variants of ISO-2022, where it is possible for bytes like 0x70 to appear as part of multibyte sequences that are unrelated to their interpretation as ASCII. It excludes encodings such as UTF-7, UTF-16, HZ-GB-2312, GSM03.38, and EBCDIC variants.
Your rephrasing of the first paragraph doesn't work because it is ambiguous about whether multibyte sequences that contain ASCII-like bytes are included or not. Also, it excludes other representations of those same characters, which as far as I can tell isn't necessary. I'll fix the second paragraph.
Multibyte sequences that contain ASCII-like bytes are included by the fact that they are not excluded. Other representations of the same characters are excluded, because I thought that that's what you want. If the only thing that you need for an ASCII-compatible encoding is that characters such as !, ", &, ',... can, *among else*, be encoded by the relevant ASCII bytes, then indeed that has to be worded differently. But before we lock down one wording, it might be good to understand why we hase the ASCII-compatible encoding restriction in the first place.
The ASCII-compatible encoding concept exists for two reasons; first, to prevent authors from trying to declare the encoding using the <meta charset> feature in the cases where the encoding detection algorithm wouldn't ever find the charset (e.g. using <meta charset> alone in a UTF-16 file, with no BOM and no external charset declaration), and second, to restrict the character encodings that can be used in form submission to those that aren't incompatible with opaquely treating a URL as ASCII with some unknown bytes.
Fixed the wording of the second paragraph. Please feel free to reopen this bug if you think that other aspects should still change; I merely change the resolutions as a way to manage which bugs are on my "TODO" list, it is not an attempt to prevent further discussion.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.