Re: Comments on <draft-ietf-acap-mlsf-00.txt>?

From: Randy Presuhn (
Date: Wed Jun 04 1997 - 23:56:58 EDT

Hi -

A couple of observations from a bystander who thought he was asking an
innocent question:

> Message-Id: <>
> To: Multiple Recipients of <>
> Reply-To: Chris Newman <>
> From: "Unicode Discussion" <>
> Date: Wed, 4 Jun 1997 19:31:45 -0700 (PDT)
> Subject: Re: Comments on <draft-ietf-acap-mlsf-00.txt>?
> This needs a solution that is above the character stream level and below
> the application protocol level. Were it encoded into the character
> stream, that would result in quoting problems which would destroy
> server-side searching capabilities. Were it put at the application
> protocol level it would require a datastructure so complicated as to be
> completely impractical and unusable. In addition, putting it at the
> application protocol level means that a different solution for the same
> problem will be necessary in each application protocol.
> There are *a lot* of attribute-value based protocols including SNMP, LDAP,
> DHCP, ACAP, RFC 822/MIME/HTTP, etc. In fact, the attribute-value model is
> a basic tool in protocol design. There's simply no clean way to represent
> language alternatives of multi-valued attributes at the application
> protocol level.
> MLSF can solve the general case problem, with language selection code
> that's just over a page of C, and "ignore" code that's 1/2 a page of C.
> Yes, it is _possible_ to solve this problem at different levels, but
> only with many many times the level of complexity of MLSF, and
> potentially serious performance costs as well. We don't need more ASN.1s,
> X.400s and ISO 2022s in the world. We need a multi-lingual string format
> that's as simple and elegant as UTF-8 is for multi-lingual-character
> strings. The distinction is subtle but important.

1) It sounds like there is violent agreement about the need to use
    a higher-level protocol for language tagging. It seems to me that
    MLSF really is just defining such a higher level protocol, logically
    layered on UTF-8.

2) Not all attribute-based protocols are alike. To do this sort
    of thing with SNMP, two design options would stand out from the
        a) defining a TEXTUAL-CONVENTION specifying the use of
           UTF-8 in conjunction with some higher-level protocol,
           such as MLSF or some kind of rich text.
        b) defining a separate OBJECT-TYPE that gives the language
           information for the related object.
    (Packing multiple values of a list into the value of a single object
    instance would be really tacky MIB design and have serious scalability
    problems; a table is the preferred way of representing list-valued
    things.) Both (a) and (b) are ugly. (b) causes a proliferation
    of instances, (a) would probably be terrible for indexing.

    To do this sort of thing with CMIP, which has the full power of
    ASN.1 at its disposal, likely choices would be:
        a) specifying in the BEHAVIOUR clause of an attribute that
           it used UTF-8 in conjunction with some higher-level
        b) defining a data type with a syntax something like:
           LangString ::= SEQUENCE OF
                          SEQUENCE { langTag OCTET STRING,
                                     utf8stuff OCTET STRING }

    Both of these can be ugly from the perspective of formulating matching
    rules for event forwarding discriminators or filters.

    For both protocols, a key issue is whether the language tagging
    is relevant for attribute value matching. If an operator requests
    "Gift", should matching instances be returned for both English and
    German? Is there a need to be able to request all trouble tickets
    containing Korean user names embdded in Chinese problem descriptions?

    If knowledge of the language tag is required for information
    retrieval, alternative (a) makes more sense for both protocols.
    If it is required that the tagging information should be
    ignored for lookup purposes, alternative (b) is easier to deal with
    for SNMP and CMIP. If there are requirements to do both, well, the
    SNMP and CMIP information models don't offer any assistance.

    Are these things issues for ACAP?

3) In the discussion of DAP PICS a couple of weeks ago, concern over
    X.500 matching rules was the primary motivation for the folks who
    wanted to (severely) constrain the set of code points used.

 Randy Presuhn BMC Software, Inc. (Silicon Valley Division)
 Voice: +1 408 556-0720 (Formerly PEER Networks)
 Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130
 Email: San Jose, California 95129-3433 USA
 In accordance with the BMC Communications Systems Use and Security
 Policy memo dated December 10, 1996, page 2, item (g) (the first of
 two), 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."

This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT