From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Thu Sep 12 2002 - 07:09:38 CDT
In <3D7F8136.5080103@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
> > Essentially, we took a conscious decision to place
>> the burden, if any, on the gateways, in order to achieve a cleaner product
>> within the news environment (which is our primary concern).
>Gateways are irrelevant to post-and-mail. And the "news environment"
>*requires* use of email, so the incompatibility must be resolved.
For the non-gatewaying situations, encapsulation is the proper answer,
except that it resulted in screams from the moderators' lobby. But even
the loudest screamers could see that it was the best way out if you really
had to send something incompatible with mail.
>>>The incompaibility arises whenever such a header might be injected
>>>into its native domain, viz. email....
>>>1. post-and-mail
>>>2. incoming gateways from email (also when a proto-article is sent
>>> to a moderator via email w/o encapsulation)
>>>3. outgoing gateways
>>>4. via intermediate files. A usenet article may be saved as a file
>>> and subsequently forwarded as email (or some software (e.g. combined
>>> news reader/email program) might do so w/o an intermediate file)
>>
>>
>> Yes, these cases all need to be taken care of in the proper places
>> (gateways, for example). The draft draws attention to what needs to be
>> done. Actually, I don't think there is much problem with (2), and (4) is
>> simply a complicated way of going gatewaying. He who hacks around with
>> files bears the responsibility for doing it right.
However, on second thoughts, I can see that a paragraph is needed in 8.8.1
to warn gatewayers to look out for this problem.
>If the MIME-style parameters are permitted in article headers which
>are adapted from email, where those parameters are not permitted,
>case 2 poses a problem; it requires that *every* injection agent be
>capable of parsing and removing the MIME-style parameters when emailing
>to a moderator without encapsulation. There *are* injection agents
>without that capability, and they cannot all be changed overnight.
Which is why it is a SHOULD NOT introduce yet. "Overnight" may well turn
out to be a year or more, but it will happen eventually.
>> The following cases are the ones you have asked to be changed. They need
>> to be decided on an individual basis, but so far I have heard no support
>> for your request. So hands up, please, anyone who wants to exclude
>> MIME-style parameters in these cases (or from anyone who wants to retain
>> them, for that matter).
>>
>>
>>>>So there is an arguable case for Sender.
>>>
>>>>We have already removed it from Message-ID.
I apologise for the confusion over this. The change we recently made to
Message-ID was for forbid comments, not to forbid MIME-style parameters,
so this one is back on the agenda.
>>
>>
>>>>There is an arguable case for Date.
>>>
>>>>I am not convinced there is a serious problem wuth Keywords.
>>>
>>>>And I am not convinced about References.
>>>
>>
>>>And Supersedes is defined in RFC 2156 ...........
So that is the list of cases to be considered.
But so far I see no hands at all raised in support of changing any of
them. Until I do so, there is not much I can do beyond making sure all the
proper warnings are in place.
>> No, we make it clear in 6.15.that our Supersedes header has no connection
>> with that defined in RFC 2156 (which is provided purely for use with
>> gateways from X-400 mail). The semantics are totally different. We
>> discussed and resolved this issue several months ago.
>Saying so doesn't make it so. If the field name is the same (it is),
>there is a connection. If Suersedes ever appears in email, it is
>interpreted in accordance with RFC 2156. And the semantics are
>not "totslly different"; boith provide for the message containing
>the header to supersede previous message(s) with the msg-id(s)
>given in the header content. If there's no pressing need for
>MIME-style parameters, they should be removed from the syntax for
>Supersedes in the draft, which will resolve the incompatibility.
Actually, there could well be a case for them in the future. Supersedes is
essentially a Netnews header, with regular use for frequently posted
articles. There are all sorts of proposals flying around for "named"
articles, and for mechanisms to be able to refer to a series of reposted
articles by a common URL. If and when these proposals come to be developed
further, it may very well be useful to have the ability to have extra
parameters in the Supersedes header.
It is a well-known fallacy that, because you cannot foresee a future need
it is not going to happen. "Who could possibly want more than 640K of
RAM?"
>> It is generally the case that our draft allows either UTF-8 OR RFC
>> 2047/2231 in all relevant places (with no bias either way - it is a matter
>> for the market place). Of course, in the case of posted and mailed and
>> similar situations, the sensible approach might well be to use RFC
>> 2047/2231 for both, but that is up to the implementor.
>It's not merely a matter of what's "sensible"; if the headers appear
>in email, they MUST comply with the email RFCs (2822, MIME, and
>relevant extensions) which means no UTF-8. That cannot be left up
>to the implementor; it is a matter of compliance with the email
>protocols as established by the relevant RFCs.
The implementor has three choices:
1. Use 2047/2231 for both the news and mail copies.
2. Use UTF-8 for the news copy and 2047/2231 for the mail copy.
3. Use UTF-8 for both.
The third case may well violate some mail standard, but this does not
alter the fact that many implementors can do and do do exactly that. The
pros and cons are fully set out in 8.8.1. Essentially, it is the
implementors' problem, not ours.
>Moreover, if the draft, as it states, incorporates MIME, then the
>MIME standards must be incorporated as they exist, not with
>unofficial (w.r.t. the cognizant MIME WG) extensions or exceptions --
>it is not within the Usefor WG's charter to tinker with the MIME
>standards.
Not so. The MIME standard explicitly restrict themselves to mail.
We can define the same headers to have any meaning we like in Netnews. Of
course, it would be foolish wilfully to define them to be totally
different, which is why we actually incorporate them as they stand, modulo
a few caveats.
>There are no proposed uses for the MIME-style parameters in the
>draft for the headers mentioned above. Therfore the situation
>is that the draft as it now stands introduces a new incompatibility
>with email via those parameters *and* imposes requirements on news
>software which is known not to be implemented by some (most) current
>software, yet yields no real or potential benefit.
On the contrary, the potential benefits are unquantifiable. The whole
purpose of introducing this extension was to facilitate future
developments (we are talking years ahead, perhaps). We have seen too
many cases where people have invented notations which are so constructed
that they leave no scope for future extension. Those who do not learn from
history are condemned to repeat it.
To take just one simple example, there is a current thread in this list
which suggests the use of such parameters in the Approved-header. It may or
may not come to fruition, but the fact that we are able to consider it all
(rather than having to create yet-another-header) indicates that it was a
sound decision.
-- 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