From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Fri Sep 13 2002 - 16:11:32 CDT
In <3D80D661.5060803@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>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.
There is no need for implementation of application/news-transmission. The
default behaviour provided by application/octet-stream is already
sufficient to get started. And it doesn't need to be standardized because
it is already accepted under the procedures laid down in RFC 2048.
>> 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
A SHOULD NOT means that you do not break it unless you have special reasons,
know what you are doing, and understand the consequences.
>(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.
And either his solution works (or works sufficiently often) or he gets
flamed until he stops it. That how real life works out on Usenet. "Clever"
developers are no new phenomenon.
> 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.?
I dunno. They all come within the scope of that SHOULD NOT. You have made
proposals for change in those areas. I am waiting to see hands raised in
your support. I haven't seen any yet.
For a start, they will all get transported correctly (because RFC 821 does
not look at the headers inside a message, except for CTE). So the question
to ask is what a MUA is likely to do if one turns up. For sure, it is not
going to bounce them - it will try to display them the best it can. In the
case of Keywords, it is unlikely anything will actually break (does anyone
know of an email user agent that actually parses and acts on the Keywords
header?) Date will probably display OK, but agents that try to sort things
into date order could conceivably be confused. Likewise Message-ID, but it
might do something funny in the References-header of a followup.
So by all means let us discuss them, but it needs more people in the
discussion than just you and I, which is why I am still waiting for other
hands to show up.
>> ... 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.
But not if some prior decision has ruled out what would otherwise have
been the best solution. These parameters are an investment for the future.
The payoff may well be years away, but they were put there after much
discussion on this WG.
We have carefully arranged that their syntax follows that of MIME, so that
existing bits of software that deal with MIME headers can be reused.
>> 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?
So all the Korean spammers who currently violate the mail standards by
sending me Subject lines in raw Korean are being antisocial? Well, yes
they are, but not for that reason. Implementors will do whatever they find
works. I do not condone that, but neither to I necessarily condemn it.
Even Russ has just pointed out that an implementor who checks for
characters in the range 0x80-9f will almost certainly get his mail
transported correctly if those are absent. The implementor's prime concern
then is what is likely to happen at the far end. If he knows that it is
destined for news (as when mailing to a moderator) he may decide that is
sufficient. Or me may decide that an occasional User-Agent header that
gets mangled at the far end can be tolerated. If he gets it wrong and gets
flamed, we point out that our standard provided the proper means (RFC
2047) and it was his choice and his risk not to use them.
>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...
He is free to do what he likes. But in that particular case his articles
will never arrive in the proper group, because the News transport
mechanism will never recognize them.
>There ought to be some measure of reciprocity; no progress will be
>made if this WG insists on dumping incompatible headers into email
Quite so, but the WG is not insisting on any such thing. But neither is it
insisting that implementors do not break standards, because it has no
power to prevent that.
>yet primly insists that under no circumstances may MIME encoding
>be used for newsgroup names.
Because there exists no MIME encoding that will work for newsgroup-names.
There is nothing "prim" in telling people not to do something which is
impossible anyway. That is just a tautology.
>.... 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.
It requires no such thing, except in the case of newsgroup-names, to which
case 1 is inapplicable. Yes, it requires that UTF-8 be accepted, but not
that it be generated.
>> Not so. The MIME standard explicitly restrict themselves to mail.
>You're going to have to substantiate that in light of:
The title of RFC 2045 is "Multipurpose Internet Mail Extensions", and its
subtitle is "Format of Internet Message Bodies", where "Internet Message"
is defined in RFC 2822 (and in RFC 822 before it) as relating to
"electronic mail". RFC 2047 explicitly describes itself as extending RFC
822. Nowhere do any of those standards claim to apply to anything other
than mail.
>1. existing MIME standards that address voice messaging, fax, etc.
Quite so. The fax standard (I presume) explicitly states that they have
adopted/incorporated the basic MIME standards, with or without such
caveats as they see fit. Likewise the HTTP standard, which in facts mauls
the MIME protocols far more than we do.
>2. RFC 1036 which explicitly uses the same "text message" format
> for news (and which the draft repeats)
But that of itself does not cause MIME to become a part of Netnews.
>3. The fact that the base MIME standards explicitly state that
> they are "largely orthogonal to [...] RFC 822".
Which is what makes them so suitable for adoption by other standards that
_choose_ to do so.
>4. verbiage in the draft "the MIME standards [RFC 2045] et seq which, though
> designed with Email in mind, are mostly applicable to Netnews"
And so, finally, we now propose to adopt them into Netnews. But observe
that word "mostly" in the bit you have just quoted.
>> ..., 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.
The you clearly do not understand the meaning of the term "modulo".
>When transmitted via email -- as required by the draft -- the meaning
>is what the email standards specify.
The meaning relates to how they are to be interpreted by the user agent at
the far end. The transport in between is blind to the MIME headers, except
for CTE (and sufficient of the multipart structure to know where CTE
headers are to be found).
So will you please indicate whereabouts in our draft we specify some
behaviour that will fail to be observed by a conforming email agent at the
far end?
-- 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