> 2. Two existing Printer MIB v2 objects, 'prtGeneralPrinterName' and
> 'prtChannelInformation' are INCORRECTLY given a SYNTAX of 'DisplayString'
> which forces NVT ASCII only (code positions 128 to 255 SHALL not be used)
> instead of 'OCTET STRING' which would give the same capabilities for other
> sets with US-ASCII as a subset as in 1 above.
INCORRECTLY my fiduciary. This was extensively discussed in meetings
and on the mailing list. We knew we were forcing NVT ASCII when we
made this decision -- you were there, too. The use of DisplayString was
intended to indicate this choice. Here's an excerpt from one of your
e-mail messages on the subject:
> Date: Tue, 29 Oct 1996 18:25:16 PST
> To: pwg@pwg.org
> From: Tom Hastings <hastings@cp10.es.xerox.com>
...
> 1. Want DisplayString as data type, or at least specify in the DESCRIPTION,
> so that the data must be the restricted form of ASCII (NVT ASCII? was is
> the RFC for it?)
> 3. On page 42, in 'PrtChannelInformationTC', in the 8 July 1997 draft of
> the Printer MIB v2, we find:
>
> -- Keyword: NDSPrinter
> -- Syntax: Text (Unicode)
>
> With a syntax of 'DisplayString' (as currently), this would FORCE the
> use of UTF-7 (defined in RFC 2152) and would PRECLUDE the use of UTF-8
> encoding (defined in ISO 10646 and summarized in RFC 2044), to convey
> this Unicode name. Probably need to change the above from "(Unicode)"
> to "UTF-8" as well.
We need to specify UTF-7 as the recommended encoding for Unicode. (The
prtChannelInformation specification says that different channel types
must specify how data is encoded if it is not naturally NVT ASCII, and,
in its current form, it gives the UTF-8 encoding of Unicode as an
example.)
Here is an excerpt from one of my e-mail messages that relates to this:
> Date: Sat, 02 Nov 1996 16:12:03 PST
> From: David_Kellerman@nls.com
> To: pwg@pwg.org
...
> Question: UTF-8 apparently uses eight-bit codes, which causes problems
> if we're saying data values are coded with only NVT ASCII graphic
> characters (32-126). There's an RFC 1642 that describes UTF-7, a
> seven-bit representation of Unicode, but I have no idea of whether it is
> generally accepted. Suggestions from anyone?
As far as I can tell from the e-mail archives, this question went
unanswered. I ended up leaving a reference to UTF-8 in the
prtChannelInformation description. This looks like it was a mistake.
:: David Kellerman Northlake Software 503-228-3383
:: david_kellerman@nls.com Portland, Oregon fax 503-228-5662