From: Bruce Lilly (blilly@erols.com)
Date: Mon Feb 10 2003 - 17:08:18 CST
Charles Lindsey wrote:
> In <3E3EC4E0.7080801@Sonietta.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>> Maintaining the
>>tags not only requires a Unicode editor, it requires an editor which
>>properly handles the 3.1/3.2 language tags when modifying text -- I
>>am not aware of any such editor.
>
>
> You don't need a Unicode Editor to display Unicode (with or without
> language tags).
Do you understand the difference between "maintaining" while "editing"
and "display"?
>>In the sense of character sets as used in RFC 2231, there is no language
>>lebeling provided by any character set; Unicode 3.1 is not a character
>>set in that sense -- utf-7 is, but utf-7 (nor any other charset) does
>>not provide language labeling.
>
>
> Eh? UTF-7, UTF-8 and UTF-16 are all charsets, and they _all_ provide
> language tagging
The utf-8 charset is defined in RFC 2279. Can you qoute the appropriate
text from RFC 2279 which discusses language tagging? No, of course you
cannot, just as you cannot cite an email RFC that encourages reordering
message header fields or provide a proof that parsing an RFC 2231
extended-initial-value requires either arbitrary lookahead or
backtracking. Because all of those are figments of your imagination.
> So? I rather doubt whether the language tagging for parameters defined by
> RFC 2231 has actually happened yet. Have you ever seen an example in the
> wild?
Yes.
>>>Effectively, one would say "It will usually be unnecessary to use language
>>>tagging within headers but, if it is considered necessary, then the
>>>language tagging defined for Unicode MAY be used" (note that the
>>>contexts where this would be applicable are all for human consumption).
>
>
>>That is not applicable in message or MIME-part header fields and
>>would not comply with the requirements of RFC 2277 for those
>>fields.
>
>
> But you seem to be agreeing that it would be applicable in top-level
> headers.
Do you understand what "message [...] header fields" means? Apparently
not.
> As to whether it would be applicable in part header fields, that
> depends on what happens to part level fields in Netnews, which is an issue
> yet to be addressed.
No, you've already been told that you cannot redefine either message
or multipart media types.
>> Because the Unicode documents expressly forbid use of the
>>language tags with MIME, they would be inappropriate for body text
>>in a MIME message, and there is no way to get body content other
>>than plain text in US-ASCII with a 7bit transfer encoding except
>>via MIME.
>
>
> And yes, that is true for bodies, but we were discussing headers, in case
> you had forgotten.
No, we were discussing language tagging; see the Subject header field.
And since MIME-part header fields appear after the the empty line
which delimits message header from body, the same applies to them; they
only exist in the presence of MIME (non-MIME-compliant software
treats them as body text, which (in the absence of MIME) is plain text
in US-ASCII with a 7-bit transfer encoding.