+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(_at_)mauve(_dot_)mrochek(_dot_)com 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