+1 to Ned's explanation. His note crossed mine in the posting
queue and basically address different parts of the issue.
However, one mini-correction that, IMO, just strengthens both of
our points...
--On Thursday, December 18, 2014 07:22 -0800
ned+ietf@xxxxxxxxxxxxxxxxx wrote:
>...
> But instead we ended up with multiple CESs, which were either
> profiled subsets
> of ISO 2022 or schemes where the hi bit was essentially a CCS
> flag. It's much
> more straightforward to handle such things as charsets, so
> that's what we did.
>
> See RFC 2978 for additional details.
>
>> So does RFC 20 define a CES as well?
>
> No. Of course there's an obvious CES to associate with it: The
> mapping of the
> 128 integer values it defines to octets with the same value.
> Do that and you
> essentially have the US-ASCII charset.
Actually, RFC 20 says, in its very first sentence, "...standard
7-bit ASCII embedded in an 8 bit byte whose high order bit is
always 0". Unless I'm missing something, that is a mapping
from a CCS (although ASCII defined those integers in Column/Row
form rather than as single integers) and a CES. So, possibly
modulo references to different versions of ASCII (I don't have
time to check whether the Charset definition for US-ASCII points
to the same version of US-ASCII that RFC 20 does), RFC 20 and
US-ASCII are more than just "essentially" the same".
john