[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: DisplayString in guidelines 4.6.1.4 and Appendix D



Hi Mike,

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

DisplayString should not be verboten.

dbh

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com] 
> Sent: Tuesday, February 11, 2003 8:55 PM
> To: Mreview (E-mail)
> Subject: Re: DisplayString in guidelines 4.6.1.4 and Appendix D
> 
> 
> [ in reply to comments/review 
> <draft-ietf-ops-mib-review-guidelines-00.txt> ]
> 
> On Fri, 7 Feb 2003, Wijnen, Bert (Bert) wrote:
> > - sect 4.6.1.4, end of page 14
> >   Mmm... the DisplayString is still current, although we
> >   rarely want to allow people to use it anymore. We prefer
> >   UTF-8 based TCs like SnmpAdminString.
> >   Do we want to make a note of that? I think it would be
> >   good. It is a thing that I see still far too often.
> 
> This escaped my radar because I tend not to be as tuned-in to i18n
> issues as I ought to be.  I propose the following remedy:
> 
> (a) remove DisplayString from the list of TCs mentioned in 4.6.1.4;
> (b) remove DisplayString from the list of "Commonly Used TCs" in
>     Appendix D, and 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.
>             New MIB modules SHOULD use SnmpAdminString instead.
> 
> Changes along these lines were what I suggested in my
> reply to Harrie Hazewinkel's comments that appeared on
> the mibs@ops.ietf.org list.
> 
> Do these changes adequately address the concerns?
> 
> Mike
> 
> 
>