> 1. I assume that there would be no checking of the operator entered
> identification information. That is, the operator/administrator set in
> whatever they want (or can), and get the same data bytes back. They
> are not restricted to the identified character coding set.
Perhaps this is not a big deal for all people, but the idea that an
operator (ie, mgmt app user) is not restricted to the identified charset
seems unreasonable. (I know you're not necessarily advocating this idea.)
Thanks for pointing out this strange situation.
> 2. I assume that the static code set object would be read only. Or do
> you see an instance where someone would be sufficiently masochistic to
> make it read/write?
Not to belabor the issue (I'm just curious), but why would it be so strange
to make this object read/write? I realize that embedded implementations
would have a bit of a hard time (and maybe that's why you call it masochistic),
but it is possible, right? Or am I missing something obvious?
> prtChannelInformation (??? this is a mix of user derived and
> fixed info... I don't think any generalstatement of character set can
> hold. It would seem, for example, that Novell parameters (if 4.0 or
> higher) should be and to eneter them in double byte would be ...bad.
> Perhaps the character set for Channel Information parameters be
> separately specified, per parameter, in the MIB descriptions?)
Yes, prtChannelInformation should be treated as a very special case,
having it's own (fixed) definition for the charset.
> 4. LocalizationLanguage (ISO639) and LocalizationCountry (ISO3166) are
> two character codes (with a size constraint to 2 octets); would these
> be recognizable/enterable in any likely character set to be specified?
Why wouldn't these two objects have a syntax of DisplayString? Aren't
these codes fixed values in ASCII? If so, then they shouldn't be
localized.
...jay