snip...
>> 3. Ira suggested that the syntax of the objects:
>>
>> finSupplyMediaInputName
>> finSupplyMediaInputDescription
>> finSupplyMediaInputMediaType
>>
>> be change from "DisplayString" to "OCTET STRING" to be consistent
>> with the Printer MIB. Since it was previously discussed and
agreed
>> that these objects should be "DisplayString", I did not change.
>
>I forget the discussion about keeping it as DisplayString. The
problem
>with DisplayString, is that it MUST be US-ASCII. With OCTET STRING,
>it could be some other character set (and language). See the
suggested
>clarifications that Ira and I proposed to reflect current
implementations.
>
>By keeping it as DisplayString, then if we ever did agree to allowing
other
>charsets for the Printer MIB, we couldn't for the Finisher MIB.
Further arguments for changing these three back to OCTET STRING to
agree with the Printer MIB:
We must change at least finSupplyMediaInputDescription back to
OCTET STRING in order to agree with the semantics that we have written
which require the data to be whatever the current localizaion is:
The finSupplyMediaInputDescription is intended to be localized
(as in the Printer MIB):
finSupplyMediaInputDescription OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A free form text description of this input subunit in the
localization specified by prtGeneralCurrentLocalization."
::= { finSupplyMediaInputEntry 11 }
RFC 1902 says:
11.1.1. Mapping to the SYNTAX clause
When mapping to the SYNTAX clause of the OBJECT-TYPE macro:
snip...
(6) An object with a character string syntax becomes either an OCTET
STRING, or a DisplayString [3], depending on the repertoire of the
character string.
[3] is RFC 1903. Therefore, it cannot be DisplayString, which RFC 1903
restricts to US-ASCII:
<bigger>DisplayString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Represents textual information taken from the NVT ASCII
character set, as defined in pages 4, 10-11 of RFC 854.
To summarize RFC 854, the NVT ASCII repertoire specifies:
- the use of character codes 0-127 (decimal)
- the graphics characters (32-126) are interpreted as
US ASCII
- NUL, LF, CR, BEL, BS, HT, VT and FF have the special
meanings specified in RFC 854
- the other 25 codes have no standard interpretation
- the sequence 'CR LF' means newline
- the sequence 'CR NUL' means carriage-return
- an 'LF' not preceded by a 'CR' means moving to the
same column on the next line.
- the sequence 'CR x' for any x other than LF or NUL is
illegal. (Note that this also means that a string may
end with either 'CR LF' or 'CR NUL', but not with CR.)
Any object defined using this syntax may not exceed 255
characters in length."
SYNTAX OCTET STRING (SIZE (0..255))
</bigger>
I claim that we should change all three back to OCTET STRING
to be consistent with the Printer MIB and to allow implementations to
use other charsets for these three objects. We should only use
DisplayString when the data is restricted to US-ASCII for some reason,
such as the data is really keywords for programs, not arbitrary text for
humans.
Tom
>
>>
>>Unless we can resolve the above three issues via email, I would like
to
>>place these issues for discussion on the agenda for next week.
>>
>>
>> Ron Bergman
>> Dataproducts Corp.
>>
>>
>>
>>
>
>