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

[rpresuhn-lists@dorothy.bmc.com]

Hi -

> Message-Id: <5.0.2.1.2.20010711110340.03161560@mail.scruznet.com>
> Date: Wed, 11 Jul 2001 11:16:34 -0700
> To: Frank Strauss <strauss@ibr.cs.tu-bs.de>
> From: "David T. Perkins" <dperkins@dsperkins.com>
> Subject: Re: comments on draft-ietf-sming-reqs-02.txt: I18n
> Cc: SMIng WG <sming@ops.ietf.org>
> In-Reply-To: <ypw7kxfag46.fsf@hansa.ibr.cs.tu-bs.de>
> References: <5.0.2.1.2.20010710130658.0331c670@mail.scruznet.com>
>  <3B4B2F8F.FCFC5FB3@enterasys.com>
>  <10C8636AE359D4119118009027AE99870DA5D953@FMSMSX34>
>  <3B4B2F8F.FCFC5FB3@enterasys.com>
>  <5.0.2.1.2.20010710130658.0331c670@mail.scruznet.com>
...
> 1) first, you have to decide what character set to use and define it
>    well or point to a defining document that has a cost on the order
>    of US$20 or less. (And is easy to get.)

UTF-8, as defined in RFC 2279.  Simple enough?

> 2) you have to consider how you want MIB modules using the character
>    set to be encoded in 7-bit displayable ASCII when they are in
>    RFCs.

UTF-8 covers this trivially.  A byte string consisting solely
of code points corresponding to 7-bit ASCII is identical in
both encodings.

> 3) When modules are sent via email, posted on a WEB site, or retrieved
>    via FTP (ascii mode), will they be not mangled in the transfer,

UTF-8 survives this as well as ASCII does.

>    and displayable with the glyphs that the author intended?

This is not even true for seven-bit ASCII.  (Remember the C++
trigraphs?   They're there for a reason.)

> 4) when a compiler is ported from one environment to another, will
>    the compiler and libraries produce the same results?

This isn't even guaranteed with 7-bit ASCII.  Consider the
differences in handling files containing ^Z by various
platforms if the file isn't opened in "binary" mode.

> 5) will I be able to use existing tools to author and process the modules?
>    (tools such as sed, awk, emacs, etc)

UTF-8 can be handled by at least some versions of these tools.

> 6) will the output from the tools (and compilers) show the "right"
>    text strings?

It's hard to get this wrong, unless people try to transform
the contents of comment / description strings, which in
general is not a smart thing to do.

> I ask these questions because I see these problems with other
> documents. I'm not saying there are no benefits. It just looks
> to me that the costs have not been fully disclosed. But maybe
> others have already solved this problem, and can point me to
> some example solutions.
..

I think that limiting DESCRIPTIONs and comments in SMIv2 to
seven-bit ASCII was a mistake, and we should not perpetuate
this error in SMIng.

I'd like to see the requirement changed from a "nice to
have" to a "must have", in keeping with the BCP RFC 2277.

 ------------------------------------------------------
 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.
 ------------------------------------------------------