ietf
[Top] [All Lists]

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

2014-12-18 10:18:30
+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

<Prev in Thread] Current Thread [Next in Thread>