Hi -
A couple of observations from a bystander who thought he was asking an
innocent question:
> Message-Id: <9706050236.AA18388@unicode.org>
> To: Multiple Recipients of <unicode@unicode.org>
> Reply-To: Chris Newman <Chris.Newman@innosoft.com>
> From: "Unicode Discussion" <unicode@unicode.org>
> 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
rest:
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
protocol
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) http://www.bmc.com
Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130
Email: rpresuhn@bmc.com 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