From: Claus Färber (list-ietf-wg-apps-usefor@faerber.muc.de)
Date: Sat Nov 06 1999 - 08:10:00 CST
Russ Allbery <rra@stanford.edu> schrieb/wrote:
>> 7.1.3. Initial Articles
>
> This is rather weird. It also requires that the server parse MIME,
> although I guess this whole new implementation of article bodies for
> control messages does in theory. I'm still sort of unsure what I think
> about that.
The original idea was to have a format that is compatible with existing
software and the way control messages are handled today.
As other-than-identity encodings (i.e. other than 8bit, 7bit, binary)
are prohibited for multipart/* messages and for the "parsable" parts,
leagacy software will still be able to handle these control messages.
And human admins will have no additional problems extracting relevant
parts (such as charters).
What is actually added is some structure that restricts the originally
more or less free-form text in a way that makes it machine-parsable.
>
> We're going to an awful lot of work to support a fundamentally broken
> syntax that relies on interpretation of a phrase,
Nope, it does not. It relies on the correct Content-Type of the
individual parts. The part containing the "magic phrases" is no longer
free-form text, but a restricted part that can contain only these
phrases. This body part is actually very similar to message headers: It
contains a "name" ("For your newsgroups file:") and a content (the
newsgroups line) -- only the record separators are different.
> and a language-specific phrase to boot, in the body of an article.
... a body part that has been labelled to contain exactly this and
nothing else using MIME. Compare it to multipart/report, which also uses
body parts that contain machine-parsable information.
> And I have to admit that the idea of doing a full MIME multipart parse in
> server software doesn't particularly appeal. This has historically been
> the sole domain of client software; servers have always been able to treat
> the body as a blob of bytes they just throw around.
That's not true for the scripts handling control messages. They have
always been interpreting the contents of control messages.
Also, any other "non-broken" protocol would require a parser for that
too. Why invent a new format?
-- Claus Andre Faerber <http://www.faerber.muc.de> PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC