ietf-822
[Top] [All Lists]

Re: RFC 2047 and gatewaying

2003-01-14 07:23:45

Charles Lindsey wrote:
In <3E22AF5D(_dot_)3000405(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> writes:


Charles Lindsey wrote:

In <3E1F4614(_dot_)70105(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> writes:



....  Drop the raw utf-8 nonsense and move on to somthing that has
a non-zero chance of baing (a) standardized and (b) implemented.


The chances of getting it standardized may or may not be zero. But the
chances of it being implemented are certainbly non-zero, because
implementations already exist.

No, for the comparatively minor problem of gateways from particular
newsgroups to mailing lists, implementations do not yet exist

OK, I'll take that as a retraction of your earlier claim of existing
implementations.

> The problems are certainly
soluble

No, as currently formulated in the Usefor draft, they cannot be (except
of course by addressing the root problem of untagged raw 8-bit header
field content, which simultaneously addresses backwards compatibility
(with good-faith IMAP 1036-compliant implementations as well as
existing gateways and other software, such as used by moderators) and
interoperability issues with email (as required for moderation)).
Simply requiring user agents to continue to comply with the existing
standard (RFC 1036), i.e. use RFC 2047 / 2231 for non-ASCII and/or
language-tagged header field data, will solve most of the problems in
the current Usefor draft.

but corners will have to be cut. The question is which corners? I
have suggested some possibilities, but you seem unwilling to discuss them.

Those horses have been flogged to death.  Gateways cannot pluck charset
and language information from thin air; the only viable solution is as
described above -- viz. to continue to require compliance with RFC 822
as extended by MIME.




<Prev in Thread] Current Thread [Next in Thread>