From: Bruce Lilly (blilly@erols.com)
Date: Fri Sep 27 2002 - 16:56:55 CDT
Charles Lindsey wrote:
> In <8XAw21jZcDC@3247.org> list-ietf-wg-apps-usefor@faerber.muc.de (Claus Färber) writes:
>
>
>>This is not the answer to my question. There are a lot of mail<->news
>>gateways _today_. Will they correctly convert a header with unencoded
>>UTF-8, as it is proposed for news, to RFC 2047/2231, which is needed for
>>email?
>
>
> The current Email and News standards do not permit 8bit in headers at
> all. So there is no reason whatsoever to expect (let alone require) that
> existing gateways should immediately cope with the new regime.
Which is precisely why the next step should be MUST NOT generate, SHOULD
accept.
> We are proposing a brand new feature for Netnews, namely UTF-8 in headers.
> We do not expect it to work perfectly in the existing network from Day 1,
> but we must concern ourselves with whether or not it will break anything
> that is already working. I think we have pretty well assured ourselves
> that it will not.
>
> So what will an existing gateway be likely to do? I can see several
> possibilities:
>
> 1. It will collapse in a heap.
> 2. It will attempt to transmit the 8bit characters.
Not acceptable. That is a violation of RFC 2821.
> 3. It will truncate to 7bit. The header in question will certainly appear
> munged at the far end.
> 4. It will reject the entire article (with or without informing the
> sender).
> 5. It will recognize it as UTF-8 and convert to RFC 2047.
>
> I think (1) is pretty unlikely. I daresay 'gnus' might be smart enough to
> manage (5), but I doubt many other systems would be.
>
> I think any of the other behaviours in the middle would be acceptable in
> the short term.
We should protect against 1 by MUST NOT generate for the first
stage of the transition.
In addition to the email issue, #2 raises a fundamental question:
Are we dealing with news articles as RFC 2822/MIME messages (as
was the case with 1036 (though it predated MIME)) or not?
A. If so, we should adhere to that format, which means no 8-bit codes
in headers -- and there's no reason that we can't achieve our
technical objectives within that framework.
B. If not, then we would be far better off with a clearly separate
format which would require an explicit conversion, as described
in, and for the reasons mentioned in
http://www.imc.org/ietf-822/mail-archive/msg01923.html.
Of course that effectively means the end of combined
news/mail user agents, which constitute what the vast majority
of Usenet users use.
B loses by a wide margin.
#3 and #4 are acceptable but it is unlikely that most existing
gateways would do so -- and that is what Claus' question was.
#5 is also unlikely for _current_ gateways.
In reality, that leaves us with the most likely scenarios falling
into #1 and/or #2, which are not acceptable.