ietf-822
[Top] [All Lists]

Re: A spec for showing language in MIME headers

1993-11-08 10:12:46
For example, how can you measure the difference between en-cockney, en-au,
current en-gb and en-gb 300 years ago?

When it is important, this is exactly the sort of question that I think
should drive us toward TEI-like techniques.  Those techniques are
clearly internal to a content type and below the level of a MIME content
type (unless we needed, e.g., text/tei-sgml to indicate that level of
encoding was taking place).

Since the original message has not yet caught up with me, I don't have a
clear picture of what problem this proposal is intended to fix.

That is my problem too. If ISO is revising 639, why can't we use the
revised one as is?

Let me restate this, but I'm assuming that we are in substantial
agreement:

  -- For the indentification of major languages that are likely to be
used in "plain text" email, 639 (or 636bis) probably suffices.

  -- For major languages that are used in email but that don't appear in
639, we may be better off encouraging registration in 639, rather than
inventing an Internet-specific (e.g., IANA) mechanism.

  -- For very complex cases, requiring the specific identification of
dialect, location, time, etc., nothing with the granularity of "body
part" is likely to suffice, and we need coding techniques that can
identify the origins/context of particular words.

The question then becomes whether there are cases that are (i)
relatively simple, (ii) not covered by 639 or appropriate for
registration, (iii) likely to be used in "plain text" email.  If so, we
should pursue Ole's suggestion.  If not, it is solving a problem with a
null set of cases.

  john