On 8/15/2014 10:10 PM, Jeffrey Walton wrote:
On Sat, Aug 16, 2014 at 12:08 AM,<shath...@e-z.net> wrote:
...
Even today with Unicode character set families, the ability to provide
a global case-independent mapping becomes a massive problem. There are
a variety of latin-like alphabets and greek alphabets, and even
IBM EBCDIC encodings that are much unlike the US-ASCII character set.
Even more problematic are the cyrillic, hebrew, aramaic, asian, and
african alphabets. Do we need to accept transliteration to these
various alphabetic schems?
Traditionally, case-independence has been the conversion of US-ASCII
and IBM EBCDIC encodings for named strings. In documentation languages,
the use of various Unicode tablular character sets are used.
How much of this above work needs to be accomplished so that
name case-independent and character code table independence needs
to be accomplished. Or should we just define a character encoding
standard for the naming conventions and stick to the definitions?
I believe they are discussing strings like used in cipher suites (for
example, "RC4-MD5"). They are 8-bit clean.
For the upcoming hostname matching gear, IDNs must be A-label form
from RFC 6125, section 6.4.2.
Jeff
______________________________________________________________________
OpenSSL Projecthttp://www.openssl.org
User Support Mailing listopenssl-us...@openssl.org
Automated List managermajord...@openssl.org
The general practice is to use 7-bit US_ASCII encoding or a transcoding
into one of
the transparent EBCDIC encoding for some mainframes based on IBM technology.
Case independence is easy if you restrict yourself to the above code tables.
Once you move to UTF-8 which may require an "8-bit clean" transmission,
the multi-byte content maps to a set of unicode characters in the range of
0x0001 - 0x10FFFF. There are a wide number of
The older SIXBIT character system may still be in use on some systems,
but is
mostly obsolete.
Steven J. Hathaway
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
