Charles Lindsey wrote:
In <3E088D4B(_dot_)5050508(_at_)alex(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
Charles Lindsey wrote:
It receives an article with UTF8-xtra-chars in some unrecognized header.
For sure it was not a header known to the Netnews protocol, so it was
superfluous for news propagation.
Not necessarily; it may be one of the newfangled Usefor "headers" and the
"gateway" may be one operating according to the current specification which
does not define such a "header".
Naturally, a gateway that has not been upgraded to conform to the new
standard will not conform to the new standard. Do you really expect such
tautologies to be included in IETF standards?
I expect IETF standards which update or replace earlier standards to
address compatibility issues. As discussed on the Usefor list, the
current draft expresses requirements which are diametrically
opposed to what the current standard (RFC 1036) requires (e.g. 1036
makes processing of articles with Subject: cmsg ... as a control
message, whereas the current draft forbids such processing). Failure
to provide for a graceful transition is a recipe for disaster.
Or it may be an experimental "header", the
syntax of which is only known to those participating in the experiment [in
email, such expermental headers would begin with "X-", but current practice
in Usenet articles appears to be to make up some tag without consideration
of collisions with existing standards (e.g. Supersedes)].
Experimental headers are, by definition, those beginning with "X-". They
are always treated as unstructured by RFC 2047, which is also what my text
says.
RFC 2047 encoding is used for parts of message header fields which are
used for display, i.e. they are not interpreted as part of the message
protocol -- display name phrases used with mailboxes and named groups,
comments, and unstructured headers (Subject: and Comments: among the
standard headers). In all cases, the header text remains unaltered; UAs
may decode the text *for display*. 2047 does not directly address gateway
transformations; the only mention of gateways in 2047 is in reference to
the design of the encoding. 2047 does not provide for altering header
fields, unstructured or not, unlike your text.
In RFC 822/2822 Internet text messages, by definition no [experimental]
header field can contain any non-ASCII octet. So under the current standard
(RFC 1036), Usenet gateways need not be concerned with experimetal headers
as 1036 uses the 822 Internet text message format. If the Usenet article
format is to be changed to include non-ASCII octets, then all Usenet
gateways to email will have to be modified. And unless experimental
Usenet headers are forbidden non-ASCII content, that means that those
gateways will need to be able to provide appropriate encoding, which
in turn means that all gateways will need to be able to determine the
syntax of all experimental headers in advance -- clearly impractical.
There are only a few practical options:
1. stay with the Internet text message format, which avoids the problem.
As there is then no relevant change from 1036 w.r.t. gateway
transformations, there are no transition issues w.r.t. those gateway
transformations.
2. deviate from the Internet text message format only for a specific,
well-defined set of Usefor headers which must be recognized by all
news->mail gateways (a graceful transition plan will be required).
3. standardize processing of unrecognized Usefor headers which
contain non-ASCII octets in such a way as to guarantee that the
resulting mail message fully complies with all relevant mail
standards -- and a gracful transition plan will be required.
You are presuming (incorrectly) that there are no other possible options.
Well you have failed to provide any others that were not already in my
text.
I have indeed provided others, quoted below.
> And you have failed to answer the question. Which would you
recommend?
"Answer the question: have you stopped beating your wife -- yes or no?"
I have in fact answered that your item #1 is unacceptable and that #4
cannot be implemented. That leaves #2, #3, and other possiblites such
as I described.
The best solution would be to continue the RFC 1036 practice of using the
Internet text message format, i.e. there would be no untagged, unencoded
illegal octets or superfuous "parameters",
Yes, but the Rough Consensus on the Usefor Group is not to do that.
As noted by Russ, that is in large measure because those who are not
raw-untagged-utf-8 chauvinists have stopped wasting thier time patiently
explaining the issues to the latter, and/or have tired of the seven-plus
year project which was supposed to address several "urgent" issues...
Returning to your four suggestions:
#1 would violate Internet RFCs (822 / 2822 and probably 2821), so is
unacceptable.
So you have never seen a violation of RFC 2822? Lucky you! No Korean spam!
Spammers violating technical standards as well as ethical ones is one
matter (and in fact at least *some* Asian spam *does* use properly encoded
and tagged header content), but an IETF draft that encourages violation of
IETF technical standards is an entirely different matter.