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

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

David Harrington writes:

DH> Hi Frank,

DH> 4.3.18 says nothing about restricting this to enterprise mib
DH> definitions.

We are discussing SMIng language requirements, not module requirements.
However, I propose to clearify the description as follows:

   Description: Informational text (description clauses, reference
      clauses) should allow i18nized encoding (UTF8? others?) so that
      closed/non-standard MIBs can be written in arbitrary human
      languages.

Furthermore, me and Juergen think that a SMIng module guidelines
document would be worthwhile, once the SMIng specifications are
converging. That document should probably state clearly, that every
standard module *must* and every other module that is distributed
otherwise *should* be written in english.

DH> My company purchases some product from OEMs, who develop their own
DH> proprietary mibs to expose the management information related to
DH> their product. If we allow i18n in enterprise mibs, then we begin
DH> to run into problems such as

DH> 1) which languages must our mib tools understand to compile the
DH> mibs for our products? I don't want to have to fight with our OEM
DH> supplies about which language to use.

The language in description texts is irrelevant for the tools. They
are just strings. We should just allow UTF-8 instead of plain old
7-bit ASCII. 

DH> 2) which languages must our customers' mib tools support to be
DH> able to compile the mibs that define the management information
DH> for our products? I'm sure our customers don't want to fight with
DH> our support staff over what languages must be able to be imported
DH> into somebody else's tools.

Again irrelevant for the tools. Strings are just strings, not matter
which language.

Note that even SMIv1/v2 does not enforce people to write MIBs with
english description texts. People, who write MIBs for their own
private purpose, are free to do this in their own language and they
actually do it for a number of languages, even if they have to use
some dirty workaround for some non-ascii characters. Companies who
want to sell products internationally are writing their MIBs in
english, if they are not stupid.

DH> By having one languagge defined as the standard for writing the
DH> information in mibs, we avoid those kinds of problems, just as we
DH> avoid problems by having one langauge defined for writing mibs
DH> (the SMI), rather than making the choice of langauge optional
DH> (e.g. by allowing "mibs" to be written in SMI, SPPI, GDMO, MOF,
DH> etc.)

This comparison is not accurate. SMIng, SMI, SPPI, GDMO are computer
languages. Sure, we need a very well defined non-human-language-adapted
language, here. And all computer languages are defined this way. Only
Microsoft has been stupid enough in the past to define something like
a german VA-BASIC. :-)

To give a comparison that is more appripriate in my view, let's look
at modern programming languages like Java: Java is well defined and
all language keywords are derived from english. But Java would
definetely be regarded as useless in many contries of the world, if
you could not put non-english contents into strings in your Java code.
Companies that hack Java code that is to be used in many contries will
use english (if they don't support multiple languages).

DH> If the engineer you mention doesn't speak English and wants to
DH> write mibs in French, and it will never been seen outside his
DH> company, I say more power to him.  Let him write it however he
DH> wants; but it is still non-standard, and compilers that are
DH> written to be compliant to the standard need not understand
DH> French. 

David, please differentiate the SMIng computer-parsable language and
the contents of arbitrary strings!!! It is definitely right to allow
those Frenchmen to use a standard computer language and existing tools
for that language and it would be arrogant to refuse to support that.

DH> If we make i18n part of the SMI, then compilers written to
DH> be compliant either must understand any language anybody wants to
DH> use, or must be explicitly allowed to ignore the information
DH> contained in a mib module.

The second part if this sentence is not true. This first part is
very easy to achieve: Just allow arbitrary UTF-8 strings.

DH> In the second scenario, we have mibs written that cannot be
DH> compiled using the commonly available tools, and cannot be
DH> understood by most network operators in the world. I don't see
DH> that such a situation helps promote standardization of products
DH> across vendors and across national boundaries. 

Those MIBs will continue to be written in english.

DH> By establishing one language as the standard for writing text in
DH> mibs, we limit the range of languages an operator must learn to
DH> work with mibs (ASN.1, SMI, and English).

In first place, this way, we would be limiting the number of SMIng
users or we are at least reducing productivity, since people would
have to use a foreign language, that the product would never see.

DH> I realize this is does not make things easy for those who don't
DH> speak English, but mibs are also not easy for those who don't
DH> speak ASN.1 or SMI. I think it would be a bad mistake to allow
DH> people to start developing mibs in GDMO and MOF and other
DH> languages because they don't know the langauge that has been
DH> established as the standard language for defining mibs.

I agree.

 -frank