PMP Mail Archive: Re[2]: PMP> Revised proposal on definition of OCTET STRING t

Re[2]: PMP> Revised proposal on definition of OCTET STRING t

Bill Wagner (bwagner@digprod.com)
Tue, 22 Jul 1997 18:51:54 -0400

Jay's observation, as well as Harald's dire warning (and David's
ominous message) appears to reflect a valid concern form the viewpoint
of a non-product specific Printer-MIB reader.

I understand that Tom's proposal was to reflect what has been done,
which may not be optimal. Would it break what has been done to
restrict the character set to UTF8? I believe it would not affect
originally compliant items which were limited to USASCII.


The problem, I think, is in restricting the character set of user
entered identification data that is not used by the printer. This is
'stuff' that the user enters and he expects to get back what he
enters. Here, I would include:

prtGeneralCurrentOperator OCTET STRING,
prtGeneralServicePerson OCTET STRING,
prtInputMediaName OCTET STRING,
prtInputMediaType OCTET STRING,
prtInputMediaColor OCTET STRING,
prtOutputName OCTET STRING,
prtGeneralPrinterName OCTET STRING

In a similar situation, DPI has been asked to 'fix' our MIB II
sysName, sysContact and sysLocation, which are all DisplayString
types, so that we do not restrict what is entered (or returned).
Practically, this does not seem unreasonable although it is deviant
with regard to the RFC.

In a similar approach, we can 'assume' that this user-entered
information is in UTF8, whether it is or not. Perhaps that will allow
the assignment of UTF8 as the character set for all unlocalized
stings.

Bill Wagner Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: Re: PMP> Revised proposal on definition of OCTET STRING to a
Author: JK Martin <jkm@underscore.com> at Internet
Date: 7/22/97 5:36 PM

...

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