Re: comments on draft-ietf-sming-reqs-02.txt: I18n

[rpresuhn-lists@dorothy.bmc.com]

Hi -

> Message-Id: <5.0.2.1.2.20010711122316.03157c70@mail.scruznet.com>
> Date: Wed, 11 Jul 2001 12:59:46 -0700
> To: sming@ops.ietf.org
> From: "David T. Perkins" <dperkins@dsperkins.com>
> Subject: Re: comments on draft-ietf-sming-reqs-02.txt: I18n
> In-Reply-To: <200107111910.MAA26950@dorothy.bmc.com>
..
> Thanks for responding. However, I still have concerns. The hard problems
> seem to have been dismissed without addressing them. For example, 
> binary FTP is not a solution. ^Z is mis-direction.

"ASCII"-mode FTP differs from binary mode (on most platforms)
in the handling of the <CR> <LF> mess.  RFC 959 doesn't
provide any guidance on what to do with bytes with the
high-order bit set.  The implementations I've encountered
pass it through unchanged.  However, in the specific case of
IETF documents, this whole "FTP" argument is a red herring,
since the RFC publication process will generally weed out
anything not in the seven-bit range.

The point regarding "^Z" is that the portability issues for
UTF-8 support in compilers are no worse than portability
issues that already arise with the processing of 7-bit ASCII.

> NOTE: 7-bit displayable ASCII is not the same as 7-bit ASCII.
> NOTE: there are symbols, such as smiley face, that are not
>       other languages with someone might want to put in
>       a standards-track document that contained a module.
>       (There are much better examples of symbols than
>        smiley face, but it seemed appropriate here!)

"Smiley face" is not part of ASCII.  The bit pattern used
by some PCs that results in a smiley on the screen is one
of the non-printing control codes in ASCII.  If you have a
requirement to ship these, then ASCII isn't enough.  I suggest
that UTF-8 is the most reasonable answer to this requirement
which still maintains compatibility with seven-bit ASCII.

> What I've seen that "worked" is to use all 7-bit displayable
> ASCII and use quoting to put in other characters. It's not pretty,
> but it worked.

This amounts to defining yet another character encoding standard.
UTF-8 is widely deployed, widely understood, and simple.  Let's
not introduce unneeded complexity by defining some ad hoc character
encoding when a perfectly adequate one already exists.

> Please provide some real examples of mainstream usage.
..

HTML. XML. SNMPv3. Java. Microsoft Windsow.  Apple's MacOS.
http://www.unicode.org/unicode/onlinedat/products.html
Or are things like Microsoft Word not "mainstream" enough?

Given the IETF policy on character sets in RFC 2277, I would
think that the burden of proof in this discussion should be on
anyone advocating a specification which precludes the use of
most of the world's written languages in things as inoccuous
as comments and descriptions.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------