Re: DisplayString in guidelines 4.6.1.4 and Appendix D

["C. M. Heard" <heard@pobox.com>]

On Wed, 12 Feb 2003, Juergen Schoenwaelder wrote:
JS> >>>>> C M Heard writes:
JS> 
JS> :   Note 2.  DisplayString does not support internationalized text.
JS> :            New MIB modules SHOULD use SnmpAdminString instead.
JS> 
JS> I suggest to change that to:
JS> 
JS>    Note 2.  DisplayString does not support internationalized text.
JS>             New MIB modules SHOULD use SnmpAdminString for objects
JS>             that are expected to hold internationalized text.
JS> 
JS> The point here is that in some cases, using DisplayString is actually
JS> not a problem (think for example of an object that models HTTP request
JS> names such as GET, POST and so on). I guess there is also an official
JS> RFC on this issue - but I do not recall the name or number...

This somewhat milder wording in the note suggests that DisplayString is
OK under certain circumstances.  That seems inconsistent with removing
it from the list of TCs (which was another part of the proposal).

On Wed, 12 Feb 2003, Harrington, David wrote:

DBH> SnmpAdminString is [appropriate] for some uses; DisplayString is
DBH> appropriate for some uses. For instance, it was decided that
DBH> sysContact should continue to be given using DisplayString as
DBH> a least-common denominator "standard" for administrator names,
DBH> much as UDP/IPv4 is the least common denominator standard
DBH> transport for SNMP. Just as UDP can be supplemented with TCP or
DBH> other transport can be supplemented by a sysContact-like object
DBH> in SnmpAdminString/UTF8 format.
DBH> 
DBH> DisplayString should not be verboten.

to which Bert Wijnen replied:

BW> > SnmpAdminString is [appropriate] for some uses; DisplayString is
BW> > appropriate for some uses. For instance, it was decided that 
BW> > sysContact should continue to be given using DisplayString as
BW> > a least-common denominator "standard" for administrator names,
BW> 
BW> I doubt that that was the reason. My recollection is that we 
BW> did not want to change it while moving from DS to STD.
BW> I personally thought making the change was OK, but the majority
BW> of the SNMPv3 WG thought not. So we kept it and basically said
BW> we'd have to do a SnmpAdminString based set of objects for
BW> the current DisplayStrings in the system group and then 
BW> deprecate the old objects.

FWIW, my recollection is similar:  we toyed around with changing the
definition of sysContact (and even made several tests to see what
older managers would do) but in the end the WG decided that it would
be an unacceptable change of semantics.

BW> > much as UDP/IPv4 is the least common denominator standard
BW> > transport for SNMP. Just as UDP can be supplemented with TCP or
BW> > other transport can be supplemented by a sysContact-like object
BW> > in SnmpAdminString/UTF8 format.
BW> >
BW> > DisplayString should not be verboten.
BW>
BW> Correct, but it's use will be minimal in new MIB modules I think.

My reading of this discussion is that (so far) there really is not a
consensus for saying that DisplayString is NOT RECOMMENDED, which is
more or less what my proposed changes would do.  There does seem to
be agreement that there should be a note in Appendix D pointing out
that it does not support internationalized text, and I think that it
is quite resonable for that note to make the strong statement that
DisplayString MUST NOT be used for objects that are required to hold
internationalized text.

One point brought up in a related discussion on the mibs list is
that SnmpAdminstring is not the only UTF-8 TC in common use;  one
also finds Utf8String and LongUtf8String, defined in SYSAPPL-MIB
[RFC2287], in quite a few MIB modules.

In light of all this, I would like to suggest the following revised
proposal for addressing this issue:

(a) leave DisplayString in the list of TCs mentioned in 4.6.1.4,
    but add mention of Utf8String and LongUtf8String.
(b) leave DisplayString in the list of "Commonly Used TCs" in Appendix D,
    but add a second note under the list of TCs from SNMPv2-TC:

   Note 1.  InstancePointer is obsolete and MUST NOT be used.
   Note 2.  DisplayString does not support internationalized text.
            It MUST NOT be used for objects that are required to
            hold internationalized text.  Designers SHOULD consider
            using SnmpAdminString, Utf8String, or LongUtf8String for
            such objects.

(c) Add the following to Appendix D, right below SnmpAdminString:

   The following TCs are defined in SYSAPPL-MIB [RFC2287]:

   Utf8String                  OCTET STRING (SIZE (0..255))
   LongUtf8String              OCTET STRING (SIZE (0..1023))

(d) Add the following normative reference:

[RFC2287]   C. Krupczak, C. and J. Saperia, "Definitions of System-Level
            Managed Objects for Applications", RFC 2287, February 1998.


I'm sure that this proposal won't make everyone happy, but I just
don't think that there is consensus for making a blanket statement
that DisplayString is NOT RECOMMENDED, which is what the original
proposal in effect had.  I think that "MUST NOT be used for objects
that are required to hold internationalized text" is correct and
will rule out using it in most places these days.

OK, I've put my nomex suit on, so let the hot rockets fly :)

//cmh