From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed Sep 18 2002 - 07:10:28 CDT
In <3D879179.4070003@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
>> In <3D80C64C.3030407@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>> No, we carefully arranged that normalization was not essential in user
>> agents (though there is no harm in it). You expect cutting and pasting not
>> to introduce anomalies (and hopefully to correct them if found) and you
>> expect keyboard drivers and editors to produce normalized output. But
>> those are usually OS functions, not specially coded into the user agent.
>How can you guarantee that an OS configured for some national
>character set will produce normalized Unicode from its keyboard?
>You can't. That means that either the user agent must be
>capable of converting from such a national characters set to
>Unicode, with normalization, ad/or that the injection agents
>and gateways do so (much more difficult, since there's no hint
>available as to the character set that the user used). Not all
>OS' have native Unicode support; moreover, those that do have
>some support may also support national character sets, and any
>given user of such a system might have it configured to use
>such a national character set.
If the OS is working internally in some form of Unicode, then for sure its
keyboard should be generating it in normalized form. It should be
extremely hard for a user to be able to generate anything that is not
normalized.
If the OS is working internally in some other charset, then presumably it
will provide library routines (such as 'iconv') to convert to Unicode, and
these also should produce it in normalized form.
A user agent should rely on one or other of these facilities rather than
trying to do it itself.
I recommend you to read draft-duerst-i18n-norm-04.txt, and particularly
the concept of "Early Uniform Normalization" described there. Essentially,
it says that you get all data into normalized form as early as you can,
and then keep it in that form throughout all further processing.
>Aside from that, as the user agent will have to have 5.5.2
>encode/decode support as well (for post-and-mail and for
>followups to poster),
Agents designed to handle news, and especially those designed to handle
I18N newsgroup-names, would need to be able to generat 5.5.2 encoding.
But I would not expect user agents in general, especially those designed
for mail, to be able to decode it automatically in the way they currently
do for RFC 2047.
>>
>> Moderators with suitable user agents should be able to construct a
>> suitable news-transmission plug-in.
>You are implying that moderators should accept any old
>application/octet-stream (not to mention any unrecognized
>media types, such as application/here-is-a-virus-for-you)
>willy nilly as if they were undoudtedly news articles. I'm
>not sure that would be popular with many moderators...
I am saying that there are zillions of application types registered with
IANA, and I doubt that common user agents are able to recognise more than
half a dozen of them. What they do, when they meet an unknown one, is the
minimal behaviour provided for application/octet-stream. That behaviour is
designed to be "safe" in that it generally allows you to do little more
than store the object to a file.
Now someone who is especially interested in handling a particular
application type (and that might be a mpderator wishing to automate the
handling of application/news-transmission) will likely write (or obtain) a
plug-in for his browser to handle that case.
I doubt anyone will bother to write a plug-in for
application/here-is-a-virus-for-you, so the "safe" behaviour of
octet-stream will apply to that case.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5