Subject: UTF8 DisplayString

From: Bob Stewart <[email-masked]>
Date: Thu, 12 Nov 1998 15:29:10 -0500

Please excuse the cross post.  I know there are a lot of duplicates, but
this is relates to official business of both working groups.

Juergen and I have a disagreement about using SnmpAdminString where I'm
presently using DisplayString for non-index objects.  He wants
international alphabets and I'm sympathetic but believe we're pushing
beyond the purpose of the textual convention.

While we were working on SnmpAdminString I remember suggesting we should
use it for all DisplayString-like applications and being told it wasn't
quite suitable.  I suggested we needed a textual convention that was
suitable and the SNMPv3 working group decided not to do that.

On that basis I don't believe it meets original intent of the
SnmpAdminString textual convention to use it as a general replacement for
DisplayString.  The description doesn't limit it to index objects, but is
biased in that direction (discouraging carriage control and leading or
trailing blanks).  The name especially implies that it isn't for general
purpose use.

Juergen and I are likely to remain adamantly on opposite sides of this
without an overriding convention at least from the DisMan working group and
preferably from the SNMPv3 working group.

So what's official SNMP standard policy on this one?

	Bob

---

From: Ed Reeder <[email-masked]>
Date: Thu, 12 Nov 1998 13:42:19 -0800

Bob,
Here's what the Host MIB (RFC1514) did to address a similar problem.

InternationalDisplayString ::= OCTET STRING
   --  This data type is used to model textual information in some
   --  character set.  A network management station should use a local
   --  algorithm to determine which character set is in use and how it
   --  should be displayed.  Note that this character set may be
encoded
   --  with more than one octet per symbol, but will most often be NVT

We ran up against the case where entities, like file system names,
needed to be represented in the MIB and it was possible, and
even likely, that they would be named in the user's national language.

At the time, 1992-1993, we thought that a "better" solution was
needed, but that we weren't going to address it in our mib.

/Ed Reeder

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 12 Nov 1998 18:10:23 -0800 (PST)

> quite suitable.

This was because SnmpAdminString's definition says: "The use of leading
or trailing white space should be avoided", right ?

> I suggested we needed a textual convention that was

I thought the WG decided a) not to change SnmpAdminString, and b) not
to define a UTF8-version of DisplayString at that time.  These are
different from c) deciding a UTF8-version of DisplayString is not needed.

Keith.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 12 Nov 1998 18:22:59 -0800

Hi -

(writing as a technical contributor, not disman chair)

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, 12 November, 1998 12:29
> To: [email-masked]
> Cc: [email-masked]
> Subject: UTF8 DisplayString
...
> beyond the purpose of the textual convention.

SnmpAdminString should work nicely.

> suitable and the SNMPv3 working group decided not to do that.

SnmpAdminString is pretty close for most cases.  Its proscription
of control codes and leading/trailing white space, as well as
its length constraint, may make it unsuitable for some specialized
applications, but not this one, as far as I can tell.

> trailing blanks).  The name especially implies that it isn't

The choice really boils down to one of using the TC or creating
your own TC that looks suspciously like the one in RFC 2271.
Support for the specific semantics of SnmpAdminString are
probably a bit more likely to be built into compilers than
ad hoc TCs with similar intent.

> preferably from the SNMPv3 working group.

In the applmib work, we've been using SnmpAdminString because
it was close enough, even for the non-index cases.

> So what's official SNMP standard policy on this one?
...

We'll have to make something up, I guess.  :-)

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked] http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

---

From: Bob Stewart <[email-masked]>
Date: Fri, 13 Nov 1998 10:23:31 -0500

>different from c) deciding a UTF8-version of DisplayString is not needed.

We remember it the same.

What I'm trying to avoid is using SnmpAdminString in a way that explicitly
was not intended.  If the SNMP community agrees that we need a UTF8 version
of DisplayString, then we should create one and it should become the
replacement for DisplayString in all new standard MIBs.

I'm not saying we don't need it.  I'm saying SnmpAdminString isn't it.

	Bob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 14 Nov 1998 11:15:33 +0100

>>>>> Bob Stewart writes:

Bob> What I'm trying to avoid is using SnmpAdminString in a way that
Bob> explicitly was not intended.  If the SNMP community agrees that
Bob> we need a UTF8 version of DisplayString, then we should create
Bob> one and it should become the replacement for DisplayString in all
Bob> new standard MIBs.

Bob> I'm not saying we don't need it.  I'm saying SnmpAdminString
Bob> isn't it.

We discussed the need for several commonly used new TCs in Los Angeles
and I think there was agreement to put together such an addendum.  The
SNMPv3 chair did not get someone to work on this. Therefore, you have
3 options:

a) Do something to get work on the addendum started, wait until its
   done, continue your MIB.
b) Use SnmpAdminString because it is pretty close to what you want
   and it is available now and has a chance of wide spread support.
c) Define you own TC like in RFC 2287 or (shudder) import it from
   RFC 2287. 

Given the constraints we are working in, I would say b) is a
reasonable option. (Sure, this solution is not really satisfying, 
but what can we little document editors do? Even writing concrete
proposals (draft-daniele-iana-addr-mib-00.txt.gz) does not seem to 
make things moving faster.)
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Bob Stewart <[email-masked]>
Date: Wed, 18 Nov 1998 11:56:48 -0500

>SNMPv3 chair did not get someone to work on this. Therefore, you have

That implies to me that the working group doesn't believe the problem is
worth solving now.

 ...
>make things moving faster.)

The working group explicitly decided that SnmpAdminString was not
appropriate for general use and explicitly decided not to work on such a
textual convention at that time.  I thought we should but was consensused
down.  I'm not willing to subvert that as I don't know enough about the
problems to know why we didn't just do it then.

If we need a commmon, international DisplayString, it should be a product
of the SNMPv3 working group.  It's up to the interested parties,
international members and our international Area Directors to whip the
working group into shape and I'm already interested in more than I can handle.

	Bob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Nov 1998 12:03:37 +0100

>>>>> Bob Stewart writes:

Bob> It's up to the interested parties, international members and our
Bob> international Area Directors to whip the working group into shape
Bob> and I'm already interested in more than I can handle.

I find this statement a bit polemic. "International members" invest
quite some time to write emails and documents in foreign languages and
I think it is unfair to push responsibility for internationalization
to them just because they were born in non-english speaking countries.

Anyway, below is an Internet-Draft (which is probably too late to make
it into the ID repository) which defines some new TCs.  It includes a
stripped down version of SnmpAdminString.
							Juergen

                                                   Juergen Schoenwaelder
Internet-Draft                                           TU Braunschweig
Expires May 1999                                        18 November 1998

                    Textual Conventions Extension 1

                   <draft-schoenw-snmp-tc-ext-00.txt>

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited. Please send comments to
   the SNMP Version 3 Working Group, <[email-masked]>.

Abstract

   This memo defines new textual conventions that are considered to be
   generally useful. This memo extends the set of textual conventions
   defined in RFC 1903, which also defines the language used to define
   textual conventions.

J. Schoenwaelder                                                [Page 1]

Internet-Draft           System MIB Extensions             November 1998

   Table of Contents

   1 Introduction .................................................    2
   2 Definitions ..................................................    2
   3 Acknowledgments ..............................................    5
   4 Authors' Address .............................................    5

1.  Introduction

   This memo defines new textual conventions that are considered to be
   generally useful. It extends the set of textual conventions defined
   in RFC 1903. For more information about textual conventions, please
   consult RFC 1903.

2.  Definitions

   SNMPv2-TC-EXT-01 DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY
           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION
           FROM SNMPv2-TC;

   -- This module is not valid SMIv2. The author left out all the
   -- administrative stuff in order to keep it small.

   InternationalString ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "255t"
       STATUS       current
       DESCRIPTION
           "An octet string containing human-readable information.

            To facilitate internationalization, this information is
            represented using the ISO/IEC IS 10646-1 character set,
            encoded as an octet string using the UTF-8 transformation
            format described in [RFC2279].

            Since additional code points are added by amendments to the
            10646 standard from time to time, implementations must be
            prepared to encounter any code point from 0x00000000 to
            0x7fffffff.  Byte sequences that do not correspond to the
            valid UTF-8 encoding of a code point or are outside this
            range are prohibited.

J. Schoenwaelder                                                [Page 2]

Internet-Draft           System MIB Extensions             November 1998

            The use of control codes should be avoided. When it is
            necessary to represent a newline, the control code sequence
            CR LF should be used.

            For code points not directly supported by user interface
            hardware or software, an alternative means of entry and
            display, such as hexadecimal, may be provided.

            For information encoded in 7-bit US-ASCII, the UTF-8 encoding
            is identical to the US-ASCII encoding.

            UTF-8 may require multiple bytes to represent a single
            character / code point; thus the length of this object in
            octets may be different from the number of characters
            encoded.  Similarly, size constraints refer to the number of
            encoded octets, not the number of characters represented by
            an encoding.

            Note that when this TC is used for an object that is used or
            envisioned to be used as an index, then a SIZE restriction
            MUST be specified so that the number of sub-identifiers for
            any object instance does not exceed the limit of 128, as
            defined by [RFC1905].

            Note that the size of an InternationalString object is
            measured in octets, not characters."
       SYNTAX      OCTET STRING (SIZE (0..255))

   TAddressOrZero ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
           "Denotes a transport service address. A zero-length octet
            string indicates that no transport address is known.

            A TAddress value is always interpreted within the context of
            a TDomain value.  Thus, each definition of a TDomain value
            must be accompanied by a definition of a textual convention
            for use with that TDomain.  Some possible textual conventions,
            such as SnmpUDPAddress for snmpUDPDomain, are defined in the
            SNMPv2-TM MIB module.  Other possible textual conventions are
            defined in other MIB modules.

            Note, the definition of this textual convention is identical
            to the TAddress definition in the SNMPv2-TM MIB module with
            the only difference that this textual convention allows a
            zero-length TAddress value."
       SYNTAX      OCTET STRING (SIZE (0..255))

J. Schoenwaelder                                                [Page 3]

Internet-Draft           System MIB Extensions             November 1998

   TAddressMask ::=
       STATUS      current
       DESCRIPTION
           "Denotes a transport service address mask.

            A mask value is used to select which bits of a transport
            address must match bits of the corresponding instance of
            a TAddress object. The value of an instance of this textual
            convention must always be an OCTET STRING whose length is
            either zero or the same as that of the corresponding instance
            of a TAddress object.

            The matching algorithm is as follows:

            Each bit of each octet in the TAddressMask value corresponds
            to the same bit of the same octet in the TAddress value. For
            bits that are set in the TAddressMask value (i.e. bits equal
            to 1), the corresponding bits in the TAddress value must
            match the bits in a given transport address. If all such bits
            match, the transport address is matched. Otherwise, the match
            fails."
       SYNTAX      OCTET STRING (SIZE (1..255))

   TAddressMaskOrZero ::=
       STATUS
       DESCRIPTION
           "Denotes a transport service address mask. A zero-length octet
            string indicates that the match always succeeds.

            A mask value is used to select which bits of a transport
            address must match bits of the corresponding instance of
            a TAddress object. The value of an instance of this textual
            convention must always be an OCTET STRING whose length is
            either zero or the same as that of the corresponding instance
            of a TAddress object.

            The matching algorithm is as follows:

            If the value of the TAddressMask is a zero-length OCTET
            STRING, the mask value is ignored and the match succeeds.

            Otherwise, each bit of each octet in the TAddressMask value
            corresponds to the same bit of the same octet in the
            TAddress value. For bits that are set in the TAddressMask
            value (i.e. bits equal to 1), the corresponding bits in the
            TAddress value must match the bits in a given transport
            address. If all such bits match, the transport address is

J. Schoenwaelder                                                [Page 4]

Internet-Draft           System MIB Extensions             November 1998

            matched. Otherwise, the match fails."
       SYNTAX      OCTET STRING (SIZE (0..255))
   END

3.  Acknowledgments

   The definitions in this memo are inspired by definitions found in
   other RFCs and Internet-Drafts. Most of the text in the descriptions
   is therefore copied from other sources. Special thanks go to David
   Levi, Randy Presuhn and Keith McCloghrie for writing the original
   descriptions.

4.  Authors' Address

     Juergen Schoenwaelder             Email: [email-masked]
     TU Braunschweig                     Tel: +49 531 391-3283
     Bueltenweg 74/75
     38106 Braunschweig
     Germany

J. Schoenwaelder                                                [Page 5]