From: Bruce Lilly (blilly@erols.com)
Date: Tue Sep 17 2002 - 15:32:57 CDT
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.
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), if one *were* to assume magical normalization,
there would be no penalty in having the header format be the
1036/822/2822 compatible 7-bit form, with the user agent
handling human I/O appropriately. In fact that would simplify
matters, as separate versions of a message would not be
required for post-and-mail.
>>c) encode/decode for human I/O in the user agent. Content in
>> headers in a format compatible with email (MIME
>> encoding where applicable, draft sect. 5.5.2 encoding for
>> newsgroup names). There are no encode/decode requirements
>> for gateways or injection agents. There is no incompatibility
>> with existing news software.
>
>
> Yes, but you don't have to do it just in your user agents. You also have
> to do it in your killfiles, your spam filters, and your general
> administration scripts. That is the real pain of all encoded-on-the-wire
> solutions.
Killfiles and spam filters *are* user agent issues, but there
is no need for encode/decode under the conditions noted; the
user agent puts the appropriate entry in the file (or checks
file entries vs. article content) and it just works. there's
no display or direct I/O issue necessarily involved. Likewise
for administration scripts; the newsgroup name *is* the compatible
form, and there's no need to recognize any 8-bit keyboard
codes (which in any event might not be available on all systems,
particularly legacy ones) or to draw any partcular glyphs on
a display. And that's the point; gateways and injection agents
also have no need for keyboard/display conversion, so should
not be burdened with the encode/decode issues that arise solely
from desire for human I/O niceties. The pain is putting that
encoding and decoding in those places where it need not be
required, and that includes gateways, injection agents,
servers, and the files and scripts that you mention.
>>there *isn't* application/news-transmission.
>
>
> Yes there is. It has been an official part of MIME for 6 years or more
> (look it up on www.iana.org).
My oversight. Duly noted.
> In any case, even if few agents currently recognize it as such, that is
> no problem because treating it as application/octet-stream does near
> enough the right thing.
>
> 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...