I don't think that sentence restricts them at all -- it is only
referring to when a document is limited to the US-ASCII encoding.
>>...
>>Therefore, user agents may use the charset parameter to select a
>>different declaration, even though the mechanism...
>
> [nit] I would add:
>
> The intent, however, is that such a declaration be as identical as
> possible to that of section 12.3, the only differences being those
> required to support the announced charset.
That's good.
>>6.3.2 Character octet reference
>
> It doesn't make much sense to say "#233" to mean "e-acute" in a
> document if codepoint 233 in that document's encoding means something
> else than "e-acute". I would either restrict the use of those
> entities to documents encoded in Latin-1, or specify that they mean
> "the character whose codepoint is given by the number, in the encoding
> specified by the charset parameter (ISO-8859-1 by default)".
I believe the WG decided on the interpretation:
The character octet references are not dependent on the character
set encoding of the document. For example, "×" always represents
the ISO-8859-1 multiply sign, even when the document's declared
character set is other than ISO-8859-1.
so I have added that to the spec.
> BTW, the table in section 13.3 has errors: grave-accented letters
> always come before acute-accented ones in Latin-1, contrary to what
> the table says. I haven't had time to check the rest, sorry.
Yep, I tested it and found 24 bad entries. Thanks for pointing that out.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>