From: Bruce Lilly (blilly@erols.com)
Date: Thu Sep 12 2002 - 13:01:05 CDT
Charles Lindsey wrote:
> In <3D7F8136.5080103@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
> 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.
That ignores the "chicken-and-egg" problem; there's currently no
standard way to encapsulate (message/rfc-822 still requires the
header to be compliant with the RFC 822 character set). The
draft proposes one, but it won't be widely implemented until
some considerable time after it is standardized. One way
around that difficulty would be to split out the application/news-transmission
bit as a separate RFC and get that moving so that it is already
in place when the rest of the draft is ready for standardization.
>>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.
SHOULD NOT is a recommendation against, not a prohibition
(N.B. I originally suggested a change to MUST NOT). Which means
that somewhere, some "clever" developer will put a parameter in
and things will break, and his perfectly plausible defense will be
that it's not prohibited. How much existing news or mail software
can deal with
Date: 13 Sep 2002 12:34:56 -0700; foo=bar
Message-ID: <xyz123@example.domain.invalid>;fribble=blurfl
Keywords: compatibility, interoperability; reality=NOT
etc.?
> 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.
Future requirements for which there are no current concrete, tested
solutions are best dealt with after the issues have been clearly identified,
possible solutions are proposed, their pros and cons enumerated, and
experiments undertaken to ensure interoperability. Rather than
incompatible parameters to an unparameterized common header, one
solution would be a separate header field name, avoiding the compatibility
issue. That might not be a bad idea now (at least a transition period
where Supersedes is accepted but an alternative is also accepted, and
in future Supersedes becomes deprecated in news) -- "interesting"
things might happen if a moderator gets a submission with a Supersedes
header and that moderator happens to be using a combined mail/news
user agent...
There is also the issue of maintaining compatibility into the future;
there is no guarantee that even if parameters are supported for those
headers in the future in email, that the syntax will be exactly as
now in our draft. As there is no current need for the parameters,
they would seem to constitute a gratuitous divergence from compatibility
with email.
>>>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.
There is no question that case 3 violates mail standards. There's
no enforcement per se of RFCs, so what's your point? -- that you
consider antisocial behaviour acceptable? -- that it shouldn't be
proscribed?
If it's acceptable to ignore the email standards in email, then by
the same argument it must be acceptable to ignore the news standards
on Usenet, and so an implementor is free to use 5.5.2-style encoding
(or raw untagged 8-bit codesets) in newsgroup names on Usenet...
There ought to be some measure of reciprocity; no progress will be
made if this WG insists on dumping incompatible headers into email
yet primly insists that under no circumstances may MIME encoding
be used for newsgroup names.
The Unicode canonicalization rules are quite complex; cases 2 and 3
require all that overhead in gateways and injection agents as well
as in user agents (where it's unavoidable, at least for those who
care about Unicode). If you really mean what you say about
implementors being free to use case 1 *for news*, the draft needs
substantial revision, as it currently doesn't say that; per contra
it *requires* raw UTF-8.
> Not so. The MIME standard explicitly restrict themselves to mail.
You're going to have to substantiate that in light of:
1. existing MIME standards that address voice messaging, fax, etc.
2. RFC 1036 which explicitly uses the same "text message" format
for news (and which the draft repeats)
3. The fact that the base MIME standards explicitly state that
they are "largely orthogonal to [...] RFC 822".
4. verbiage in the draft "the MIME standards [RFC 2045] et seq which, though
designed with Email in mind, are mostly applicable to Netnews"
> 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.
"as they stand" and "modulo a few caveats" are mutually exclusive.
When transmitted via email -- as required by the draft -- the meaning
is what the email standards specify.
>>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.
Address them when there is a *quantifiable* benefit, then. Until
such time, the incompatibilities introduced are gratuitous.
> 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
[...]
Non sequitur. "Approved" is not an email-defined header, and is
therefore not under discussion in *this* thread. If there are
concrete requirements for parameters in the headers which *are*
under discussion here, that's another matter.