Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09)

[John C Klensin <[e-mail]>]

+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
[e-mail] 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