In <9303052036(_dot_)AA02941(_at_)wilma(_dot_)cs(_dot_)utk(_dot_)edu>, Keith
writes:
Brief, unique codes are *great* for machine use. It's not a cop-out. MIME
software will be more robust if implementors don't have to account for all
of the variant ways to spell a language name.
It's no harder to switch on a unique longer name than it is to
switch on a unique two-character abbreviation (unless you're
thinking of using 26*26 or 52*52 lookup tables). I stand by my
criticism of two-character abbreviations as being promulgated for
the convenience of implementors or standards bodies, not users or
persons interested in extensibility. (John's point about the
unrepresentability of language names in their own language is
well taken, although here too the two-letter abbreviation is much
more of a least-unacceptable compromise than an ideal solution.)
For human use, we can suggest that an appropriate comment
follow the language parameter. Something like:
content-type: text/plain;charset=us-ascii;language=20 (English)
Not using the current grammar. (The grammar for Content-Type
parameters could use augmentation; I'd like to see it permit a
list of more than one token, separated by commas, for reasons I
haven't mentioned yet.)
P.S. I also like using a number because it's a clue to an implementor to
actually READ THE SPECIFICATION to see what the number means.
That's a much more reasonable argument. (Though I happen to
disagree with it, because I am concerned, perhaps too much, about
the recipient who has access to neither a MIME mailreader nor the
documents which define the language name encodings.)
Steve Summit
scs(_at_)adam(_dot_)mit(_dot_)edu