[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DisplayString in guidelines 4.6.1.4 and Appendix D
I can live with your new text.
I have only one more remark. That is that we also have
(I believe it is RFC2277) a rule that says that strings
that are intended for use by humans MUST be internationalized.
So someone cannot just claim that "oh this will only be used for
US ASCII characters).
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: woensdag 12 februari 2003 20:28
> To: mreview@ops.ietf.org
> Subject: Re: DisplayString in guidelines 4.6.1.4 and Appendix D
>
>
> 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
>
>