At 11:37 AM 9/3/98 -0700, Jon Callas wrote:
Ummm, I'm not sure I understand. My reading of printing UTF-8 in human
readable form means that you should apply whatever print transform is
needed to make it look like text.
Ah, I see what you're saying. Yes, then UTF-8 is "human-readable" in the
same sense that hexadecimal is human-readable. I thought you meant "a
normal human could look at this string and read it", which is not true for
UTF-8 (or hex...).
The only other place where there is text is in the
user id packets, and those are defined to have essentially no format. By
convention they are RFC822 names, but they can be X.500 names or anything
else. It's reasonable to qualify a name with a RFC1766 language tag there
if you don't want to use romaji.
No, it is *not* reasonable to use an RFC1766 tag there since there is
nothing to differentiate the tag from the body. Inline tagging as specified
in the new draft clearly differentiates what is a language tag from the
content. It also allows more than one language tag per string, which is
something that some Asians need if their two names are from different
languages.
I'm willing to put something quick in for IETF last call if it will solve
the problem. I'm willing to say, "we do it the way they do it" for some
suitable they. But I don't want to stop progress.
I don't think any change is needed. Freel free to take out the
"human-readable" thing above, but leaving it in won't cause undue damage.
--Paul Hoffman, Director
--Internet Mail Consortium