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

["Ayers, Mike" <Mike_Ayers@bmc.com>]

> From: David T. Perkins [mailto:dperkins@dsperkins.com] 

> Costs/interoperability -
> 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.)

	Use Unicode UTF-8.  The spec for UTF-8 is RFC2279.  The complete
code charts for Unicode are available at http://www.unicode.org/charts/.
Total cost: $0.00.  The full Unicode spec is slightly more expensive, but
darn few people will need that.

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

	No.  I have heard no suggestion that international characters be
permitted in IETF works.  This is intended for private use.  7-bit
cleanliness requirements outside of SMIng will be binding whether or not
SMIng supports 8-bit/multibyte.

> 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,
>    and displayable with the glyphs that the author intended?

	Sending UTF-8 by email works fine - just look at my headers.  It is
also fully supported on the web.  For ftp, binary mode must be used, and all
will be well; this applies to rcp, too.

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

	For Unicode it should.  That's the point of it.  Note that
permitting UTF-8 in data fields should be a moot point in that regard, since
data fields should only be passed around by compilers and tools, not
modified.

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

	Sure.  Anything 8-bit clean will work.  Also, see #6.

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

	There are some details required (fonts, locale, etc.) in order to
see international characters.  More and more, OS's are shipping with these
details already covered.  It will be a few years before we see full out of
the box internationalization, but it is coming.

> 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 believe that I am showing that the costs are much lower than
feared.  Please let us know if you have any more concerns.


/|/|ike