[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                          C. Newman
Internet Draft: Multi-Lingual String Format                     Innosoft
Document: draft-ietf-acap-mlsf-01.txt                          June 1997
                                                   Expires in six months


                   Multi-Lingual String Format (MLSF)


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.  Internet Drafts may be updated, replaced, or obsoleted by
     other documents at any time.  It is not appropriate to use Internet
     Drafts as reference material or to cite them other than as a
     "working draft" or "work in progress".

     To learn the current status of any Internet-Draft, please check the
     1id-abstracts.txt listing contained in the Internet-Drafts Shadow
     Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
     munnari.oz.au.

     A revised version of this draft document will be submitted to the
     RFC editor as a Proposed Standard for the Internet Community.
     Discussion and suggestions for improvement are requested.  This
     document will expire six months after publication.  Distribution of
     this draft is unlimited.


Abstract

     The IAB charset workshop [IAB-CHARSET] concluded that for human
     readable text there should always be a way to specify the natural
     language.  Many protocols are designed with an attribute-value
     model (including RFC 822, HTTP, LDAP, SNMP, DHCP, and ACAP) which
     stores many small human readable text strings.  The primary
     function of an attribute-value model is to simplify both
     extensibility and searchability.  A solution is needed to provide
     language tags in these small human readable text strings, which
     does not interfere with these primary functions.

     This specification defines MLSF (Multi-Lingual String Format) which
     applies another layer of encoding on top of UTF-8 [UTF-8] to permit



Newman                                                          [Page 1]


Internet Draft        Multi-Lingual String Format              June 1997


     the addition of language tags anywhere within a text string.  In
     addition, it defines an alternate form which can be used to include
     alternative representations of the same text in different character
     sets.  MLSF has the property that UTF-8 is a proper subset of MLSF.
     This preserves the searchability requirement of the attribute-value
     model.

     Appendix F of this document includes a brief discussion of the
     background behind MLSF and why some other potential solutions were
     rejected for this purpose.


1. Conventions used in this document

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as defined in "Key words for
     use in RFCs to Indicate Requirement Levels" [KEYWORDS].


2. MLSF simple form

     MLSF uses "Tags for the Identification of Languages" [LANG-TAGS] as
     the basis for language identification.

     Language tags are encoded by mapping them to upper-case, then
     adding hexadecimal A0 to each octet.  The result is broken up into
     groups of five octets followed by a final group of five or fewer
     octets.  Each group is prefixed by a UTF-8-style length count with
     the low bits set to 0.  See Appendix D for sample source code to
     perform this conversion.

     MLSF simple form is defined by the MLSF-SIMPLE rule in section 7.
     A quoted version of MLSF simple form is defined by the MLSF-
     SIMPLE-QUOTED rule.

     Note that MLSF is not compatible with UTF-8.  A program which uses
     MLSF MUST downconvert it to UTF-8 prior to using it in a context
     where UTF-8 is required.  Sample code for this down conversion is
     included in Appendix B.


3. MLSF alternative form

     A MLSF alternative form string may contain alternative
     representations of the same text in different primary languages.
     The octet with hexadecimal representation of FE is used to
     introduce a new alternative.  This MUST be followed by a MLSF
     language tag for the primary language of the alternative.



Newman                                                          [Page 2]


Internet Draft        Multi-Lingual String Format              June 1997


     The component of the MLSF string prior to the first FE octet is
     considered the "preferred" representation for the string.  This is
     the version which will be displayed by MLSF clients which choose
     not to support alternative representations.  The preferred
     representation MAY be prefixed by a MLSF language tag.

     MLSF alternate form is defined by the MLSF-ALT rule in section 7.
     A quoted version of MLSF alternate form is defined by the
     MLSF-ALT-QUOTED rule.

     Note that MLSF alternate form is not compatible with UTF-8.  A
     program which uses MLSF MUST downconvert it to UTF-8 prior to using
     it in a context where UTF-8 is required.  Sample code for this down
     conversion is included in Appendix B.


4. MLSF MIME character sets

     The character set label "XXXX-simple" will be registered to
     indicate the use of MLSF simple form.  The character set label
     "XXXX-alt" will be registered to indicate the use of MLSF alternate
     form.

     MLSF may be used in conjunction with MIME header [MIME-HDR]
     encoding to permit language tagging and alternative representations
     in header fields.  A work in progress [MIME-LANG] will propose a
     mechanism for language tagging in headers which is not dependent on
     the use of UTF-8.

     For single language MIME body parts, the UTF-8 character set with
     an appropriate Content-Language [LANG-TAG] header SHOULD be used
     instead of MLSF.  Text/enriched [ENRICHED] or HTML with language
     tags [HTML-I18N] are preferred to using MLSF for MIME bodies when
     possible.


5. Security Considerations

     Multi-Lingual String Format is not believed to have any security
     considerations beyond those for simple US-ASCII strings.  In
     particular, unfiltered display of certain US-ASCII control
     characters by a terminal emulator may result in modifying the
     behavior of the terminal emulator (e.g. by redefining function
     keys) such that security can be breached.  Programs which display
     text to a potentially insecure terminal emulator channel are
     encouraged to remove control characters to avoid these problems.





Newman                                                          [Page 3]


Internet Draft        Multi-Lingual String Format              June 1997


6. Formal Grammar

     This section defines the formal grammar for MLSF using Augmented
     BNF [ABNF] notation.

     MLSF-ALT           = [[MLSF-LANG-TAG] MLSF-COMPONENT
                           *(MLSF-ALTERNATE MLSF-COMPONENT)]

     MLSF-ALT-QUOTED    = <"> [[MLSF-LANG-TAG] MLSF-COMPONENT-Q
                           *(MLSF-ALTERNATE MLSF-COMPONENT-Q)] <">

     MLSF-ALTERNATE     = %xFE MLSF-LANG-TAG

     MLSF-COMPONENT     = UTF8-NON-NUL *([MLSF-LANG-TAG] UTF8-NON-NUL)

     MLSF-COMPONENT-Q   = UTF8-QUOTED *([MLSF-LANG-TAG] UTF8-QUOTED)

     MLSF-LANG-TAG      = *MLSF-LANG-5 (MLSF-LANG-1 / MLSF-LANG-2 /
                          MLSF-LANG-3 / MLSF-LANG-4 / MLSF-LANG-5)
                          ;; Encoded version of Language-Tag from RFC 1766
                          ;; characters converted to uppercase, with
                          ;; A0 added and broken into MLSF-LANG components

     MLSF-LANG-CONT     = %xCD / %xE1..FA

     MLSF-LANG-1        = %xC0 MLSF-LANG-CONT

     MLSF-LANG-2        = %xE0 2MLSF-LANG-CONT

     MLSF-LANG-3        = %xF0 3MLSF-LANG-CONT

     MLSF-LANG-4        = %xF8 4MLSF-LANG-CONT

     MLSF-LANG-5        = %xFC 5MLSF-LANG-CONT

     MLSF-SIMPLE        = [[MLSF-LANG-TAG] MLSF-COMPONENT]

     MLSF-SIMPLE-QUOTED = <"> [[MLSF-LANG-TAG] MLSF-COMPONENT-Q] <">

     QUOTED             = "\" QUOTED-SPECIAL

     QUOTED-SPECIAL     = "\" / <">

     US-ASCII-SAFE      = %x01..09 / %x0B..0C / %x0E..21
                          / %x23..5B / %x5D..7F
                         ;; US-ASCII except QUOTED-SPECIALs, CR, LF, NUL

     UTF8-NON-NUL       = UTF8-SAFE / CR / LF / QUOTED-SPECIAL



Newman                                                          [Page 4]


Internet Draft        Multi-Lingual String Format              June 1997


     UTF8-QUOTED        = UTF8-SAFE / QUOTED

     UTF8-SAFE          = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
                          / UTF8-4 / UTF8-5

     UTF8-CONT          = %x80..BF

     UTF8-1             = %xC0..DF UTF8-CONT

     UTF8-2             = %xE0..EF 2UTF8-CONT

     UTF8-3             = %xF0..F7 3UTF8-CONT

     UTF8-4             = %xF8..FB 4UTF8-CONT

     UTF8-5             = %xFC..FD 5UTF8-CONT


7. References

     [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications:
     ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt

     [ENRICHED] Resnick, Walker, "The text/enriched MIME Content-type",
     RFC 1896, Qualcomm, InterCon, February 1996.

         <ftp://ds.internic.net/rfc/rfc1896.txt>

     [HTML-I18N] Yergeau, Nicol, Adams, Duerst, "Internationalization of
     the Hypertext Markup Language", RFC 2070,  Alis Technologies,
     Electronic Book Technologies, Spyglass, University of Zurich,
     January 1997.

         <ftp://ds.internic.net/rfc/rfc2070.txt>

     [IAB-CHARSET] Weider, Preston, Simonsen, Alvestrand, Atkinson,
     Crispin, Svanberg, "The Report of the IAB Character Set Workshop
     held 29 February - 1 March, 1996", RFC 2130, April 1997.

         <ftp://ds.internic.net/rfc/rfc2130.txt>

     [IMAP4] Crispin, "Internet Message Access Protocol - Version
     4rev1", RFC 2060, University of Washington, December 1996.

         <ftp://ds.internic.net/rfc/rfc2060.txt>






Newman                                                          [Page 5]


Internet Draft        Multi-Lingual String Format              June 1997


     [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
     Requirement Levels", RFC 2119, Harvard University, March 1997.

         <ftp://ds.internic.net/rfc/rfc2119.txt>

     [LANG-TAGS] Alvestrand, H., "Tags for the Identification of
     Languages", RFC 1766.

         <ftp://ds.internic.net/rfc/rfc1766.txt>

     [MIME-HDR] Moore, "MIME (Multipurpose Internet Mail Extensions)
     Part Three: Message Header Extensions for Non-ASCII Text", RFC
     2047, University of Tennessee, November 1996.

         <ftp://ds.internic.net/rfc/rfc2047.txt>

     [MIME-IMB] Freed, Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
     2045, Innosoft, First Virtual, November 1996.

         <ftp://ds.internic.net/rfc/rfc2045.txt>

     [MIME-LANG] Freed, Moore, "MIME Parameter Value and Encoded Words:
     Character Sets, Language, and Continuations", work in progress,
     March 1997.

     [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
     ISO 10646", RFC 2044, Alis Technologies, October 1996.

         <ftp://ds.internic.net/rfc/rfc2044.txt>


8. Acknowledgements

     Special thanks to Mark Crispin for the idea of using unused UTF-8
     codes for this purpose.   Thanks are also due to participants of
     the ACAP WG mailing list who helped review this proposal.


9. Author's Address

     Chris Newman
     Innosoft International, Inc.
     1050 East Garvey Ave. South
     West Covina, CA 91790 USA

     Email: chris.newman@innosoft.com




Newman                                                          [Page 6]


Internet Draft        Multi-Lingual String Format              June 1997


Appendix A.  Client advice

     A simple UTF-8 client is likely to find the source code in Appendix
     B useful.  A simple Latin-1 based client is likely to find the
     source code in Appendix C useful.

     A more sophisticated client will allow the user to select a
     preferred language and use something like the source code in
     Appendix E to find the best alternative in an MLSF string.  Such
     clients should also be aware that sometimes the client's preferred
     language is misconfigured, and the user may wish to have the last
     few messages repeated after they have changed languages.  For this
     reason, such a client may wish to cache the last few MLSF strings
     displayed to the user.





































Newman                                                          [Page 7]


Internet Draft        Multi-Lingual String Format              June 1997


Appendix B.  Sample code to convert to UTF-8

Here is sample C source code to convert from MLSF to UTF-8.

#include <stdio.h>
#include <ctype.h>

/* a UTF8 lookup table */
#define BAD 0x80
#define SEP 0x40
#define EXT 0x20
static unsigned char utlen[256] = {
        /* 0x00 */ BAD,   1,   1,   1,   1,   1,   1,   1,
        /* 0x08 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x10 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x18 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x20 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x28 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x30 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x38 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x40 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x48 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x50 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x58 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x60 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x68 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x70 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x78 */   1,   1,   1,   1,   1,   1,   1,   1,
        /* 0x80 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT,
        /* 0x88 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT,
        /* 0x90 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT,
        /* 0x98 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT,
        /* 0xA0 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT,
        /* 0xA8 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT,
        /* 0xB0 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT,
        /* 0xB8 */ EXT, EXT, EXT, EXT, EXT, EXT, EXT, EXT,
        /* 0xC0 */   2,   2,   2,   2,   2,   2,   2,   2,
        /* 0xC8 */   2,   2,   2,   2,   2,   2,   2,   2,
        /* 0xD0 */   2,   2,   2,   2,   2,   2,   2,   2,
        /* 0xD8 */   2,   2,   2,   2,   2,   2,   2,   2,
        /* 0xE0 */   3,   3,   3,   3,   3,   3,   3,   3,
        /* 0xE8 */   3,   3,   3,   3,   3,   3,   3,   3,
        /* 0xF0 */   4,   4,   4,   4,   4,   4,   4,   4,
        /* 0xF8 */   5,   5,   5,   5,   6,   6, SEP, BAD
};






Newman                                                          [Page 8]


Internet Draft        Multi-Lingual String Format              June 1997


/* Down conversion from NUL terminated MLSF string to UTF-8.
 *  this strips the language tags and only keeps the preferred
 *  representation.
 * It returns the length of the final string.
 * The destination string will not be longer than the source string.
 *  dst and src may be the same for in-place conversion.
 */
int MLSFtoUTF8(unsigned char *dst, unsigned char *src)
{
    unsigned char *start = dst;
    int len;

    for (;;) {
        len = utlen[*src];
        if (len > 6) break;
        /* skip language tags */
        if (len > 1 && src[1] > 0xC0U) {
            while (len && *src != '\0') {
                ++src;
                --len;
            }
            continue;
        }
        /* copy UTF8 character */
        while (len && *src != '\0') {
            *dst = *src;
            ++dst;
            ++src;
            --len;
        }
    }
    *dst = '\0';

    return (dst - start);
}
















Newman                                                          [Page 9]


Internet Draft        Multi-Lingual String Format              June 1997


Appendix C. Sample code to convert to Latin-1

/* Down conversion from NUL terminated MLSF string to 8859-1
 * The destination string will not be longer than the source string.
 *  fillc is used to fill untranslatable characters,
 *  if fillc is NUL, untranslatable characters are ignored.
 * returns 0 if source only contained latin-1, returns -1 otherwise.
 */
int MLSFtoLatin1(unsigned char *dst, unsigned char *src, int fillc)
{
    int len, result = 0;

    for (;;) {
        len = utlen[*src];
        /* copy US-ASCII */
        if (len == 1) {
            *dst = *src;
            ++dst;
            ++src;
            continue;
        }
        /* stop at illegal character or end of string */
        if (len > 6) break;
        /* skip non-latin1 glyphs and language tags */
        if (*src > 0xC3U || src[1] > 0xC0U) {
            if (src[1] <= 0xC0U) {
                /* non-latin1 glyph found */
                result = -1;
                if (fillc) {
                    *dst = fillc;
                    ++dst;
                }
            }
            while (len && *src != '\0') {
                ++src;
                --len;
            }
            continue;
        }
        /* copy latin 1 character */
        *dst = ((src[0] & 0x03) << 6) | (src[1] & 0x3F);
        ++dst;
        src += 2;
    }
    *dst = '\0';

    return (result);
}



Newman                                                         [Page 10]


Internet Draft        Multi-Lingual String Format              June 1997


Appendix D. Sample code for encoding/decoding language tags

/* encode a language tag
 *  the destination must have a size of least (counting terminating NUL):
 *        (6 * strlen(src) + 9) / 5
 *  returns the length of the destination.
 */
int MLSFlangencode(unsigned char *dst, unsigned char *src)
{
    static unsigned char prefix[] = { 0xC0, 0xE0, 0xF0, 0xF8, 0xFC };
    unsigned char *start = dst;
    int len;                    /* source length */
    int complen;                /* component length */
    int i;

    for (len = strlen(src); len > 0; len -= complen) {
        /* find maximal component length */
        complen = len;
        if (len >= 5) {
            complen = 5;
        }
        /* look up component prefix */
        *dst = prefix[complen - 1];
        ++dst;
        /* copy and map characters in component */
        for (i = 0; i < complen; ++i) {
            *dst = (islower(*src) ? toupper(*src) : *src) + 0xA0U;
            ++dst;
            ++src;
        }
    }
    *dst = '\0';

    return (dst - start);
}
















Newman                                                         [Page 11]


Internet Draft        Multi-Lingual String Format              June 1997


/* decode a language tag
 *  the destination will not be longer than the source
 *  dst and src may be the same for in-place conversion
 * returns the length of the destination
 */
int MLSFlangdecode(unsigned char *dst, unsigned char *src)
{
    unsigned char *start = dst;
    int complen;

    while (src[0] >= 0xC0U && src[1] > 0xC0U) {
        for (complen = utlen[*src++]; complen > 1; --complen) {
            *dst = *src - 0xA0U;
            ++dst;
            ++src;
        }
    }
    *dst = '\0';

    return (dst - start);
}


Appendix E. Sample code for selecting the "best" alternative

/* select the "best" language match from an MLSF string
 *  assume input language tag has been converted to upper case
 *  assume language tags in string won't exceed 256 characters
 *  "best" is calculated by matching RFC 1766 language tag components
 * returns a pointer to the start of best matching component
 */
unsigned char *MLSFselect(unsigned char *str, unsigned char *tag)
{
    unsigned char ltag[256];
    unsigned char *best, *match1, *match2;
    int bestlen, mlen;

    /* start with match on preferred alternative */
    best = str;
    bestlen = 0;

    /* skip test if no language tag */
    if (tag != NULL && *tag != '\0') {
        do {
            /* get language tag for this component */
            MLSFlangdecode(ltag, str);





Newman                                                         [Page 12]


Internet Draft        Multi-Lingual String Format              June 1997


            /* calculate match length of language tags */
            match1 = ltag;
            match2 = tag;
            mlen = 0;
            while (*match1 != '\0' && *match1 == *match2) {
                ++match1, ++match2;
                /* save length of partial match */
                if (*match2 == '-'
                    && (*match1 == '-' || *match1 == '\0')) {
                    mlen = match1 - ltag;
                }
            }

            /* finish on exact match */
            if (*match2 == '\0'
                && (*match1 == '-' || *match1 == '\0')) {
                best = str;
                break;
            }

            /* remember best match */
            if (mlen > bestlen) {
                best = str;
                bestlen = mlen;
            }

            /* skip to next MLSF component */
            while (*str != '\0' && *str++ != 0xFEU)
                ;
        } while (*str != '\0');
    }

    return (best);
}

Appendix F. Background and Alternate Solutions

     MLSF was designed to deal with language tagging in the context of
     the ACAP protocol, but is believed to be useful in other contexts.
     Specific scenarios cited during discussion were human names in
     address books, system administrator alert error messages, and error
     messages which include identifiers potentially in a different
     language from the client's preferred error message language.  Since
     ACAP is an arbitrary attribute-value protocol, it is impossible to
     imaging all possible scenarios in advance, so a general purpose
     mechanism was needed.

     There have been several attempts to solve language tagging in



Newman                                                         [Page 13]


Internet Draft        Multi-Lingual String Format              June 1997


     attribute value protocols.  RFC 822 poses a particularly
     troublesome scenario, since headers must be 7-bit.  The MIME
     solution to label character sets [MIME-HDR] and languages [MIME-
     LANG] in headers is thus a necessary evil.  The result of this is
     to make header searching services such as those provided by IMAP
     [IMAP4] massively more complex.  If 8-bit headers were permitted a
     solution like MLSF would have been far simpler and more efficient.

     Another approach taken is demonstrated by the current vCard,
     iCalendar, and LDAPv3 proposals (all works in progress).  These
     proposals overload the attribute namespace to provide language
     tagging and creates a concept roughly described as attributes of
     the attribute.  The result of this is that clients have to deal
     with a multiple attribute response to a query where each attribute
     may have multiple values.  The additional complexity this adds to
     client processing was deemed unacceptable for ACAP where client
     simplicity was an important design goal.

     Another possible approach is the use of a markup language such as
     text/enriched [ENRICHED].  While this is certainly a suitable
     language tagging solution for large text objects such as MIME
     bodies, it is unsuitable for the attribute-value model where
     searching is a primary function.




























Newman                                                         [Page 14]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/