> When we reviewed these suggestions and advice against the
> original localization proposal (late June), there did not seem
> to be any way to make it all work. Now it seems possible that
> Tom Hastings' latest proposal would be a satisfactory compromise
> that incorporates this advice and has minimal impact to the MIB.
Alright, now I'm really confused! I had just cast a "Yes" vote
to Tom Hastings' proposal...but now I find I must retract my vote
due to the latest advice from our local experts.
The reason I voted "Yes" was that I thought Tom was proposing that
all non-localized strings currently constrained to be ASCII should
be changed to OCTET STRING, where the content of such strings is
represented by UTF-8.
Now I have been told that Tom's proposal says that such OCTET STRING
MIB objects can contain data from *any* character set, and not be
constrained to UTF-8.
In the message from Harald A. that Chris forwarded, he states:
> Today: Strings are US-ASCII only, mostly English.
> More desirable: Strings are UTF-8, mostly readable locally.
> Most desirable: Strings are UTF-8, inquirer can choose which
> language he prefers, and be given a reasonable answer.
>
> (If you revise the MIB in such a way as to allow any character
> set without defining how to find out which, you lose - DON'T)
>
> MLSF or something like it is necessary if you want to avoid
> rabid revisions of SNMP like carrying language preferences
> in the community string; I'm sure there are SNMPv3 people
> willing to draw a knife on you if you suggest that :-)
>
> Upshot: I think you can do OK with the middle road this round,
> but probably nothing more. But DO define the charset!
So, unless Tom's proposal explicitly defines (ie, constrains) the
character set, I don't see how this proposal will work. In fact,
how can we achieve any reasonable degree of interoperability without
the charset defined?
I've also been convinced that the charset of choice (based on IETF
trends) is UTF-8, so hopefully we'll go that route.
...jay