I was looking for a definition of the MIME text/plain subtype.
In MIME I found:
7.1.2 The Text/plain subtype
The primary subtype of text is "plain". This indicates
plain (unformatted) text. The default Content-Type for
Internet mail, "text/plain; charset=us-ascii", describes
existing Internet practice, that is, it is the type of body
^^^^^^^^^^^^^^^^^^^^^^
defined by RFC 822.
^^^^^^^^^^^^^^^^^^
In RFC-822 I found:
From RFC 822
A general "memo" framework is used. That is, a message con-
sists of some information in a rigid format, followed by the main
part of the message, with a format that is not specified in this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
document. The syntax of several fields of the rigidly-formated
^^^^^^^^
("headers") section is defined in this specification; some of
these fields must be included in all messages.
I entirely fail to see what the problem is here. Perhaps you need to read both
specifications in their entirety, rather than quoting isolated and incomplete
passages? RFC822 also says:
Messages consist of lines of text. No special provisions
are made for encoding drawings, facsimile, speech, or structured
text. No significant consideration has been given to questions
of data compression or to transmission and storage efficiency,
And:
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
There's more but I won't bother with it here.
This collectively defines how the body of a message is structured, and is what
RFC1341 is talking about. The "format" of the body, in RFC822 parlance, is
*explicitly* left undefined. This lack of defined format in the case of
text/plain is explicitly reiterated by RFC1341.
The lack of defined format means that you cannot assume that the material in
the body is FORTRAN, C, TeX, nroff, a Haiku, a Sonnet, in English, Spanish,
French, German, in any single language, in any language whatsoever, etc. etc.
etc. It could be all of these things, none of them, something else, or some
hybrid.
Since the format of a text/plain body is not defined all we are concerned about
is structure. And RFC822 gives us all the structure we need: A message body
consists of sequences ASCII characters with CRLF delimiters between them. We
call these sequences "lines".
In comp.mail.mime, Steve Dorner, Qualcomm Inc said:
The MIME spec probably ought to say that RFC 821 defines existing Internet
practice so far as message bodies go. It's the one that specifies things
like 7 bits only and lines <1000 characters (pp 41-43).
You appear to be confusing format and structure. Format defines some sort of
semantics for the object and may impose syntax limitations. The structure is
purely syntactic; no semantics are implied by it. (This is stretching things a
bit, since the use of ASCII imposes some restrictions on syntax as implying
some semantics. But it isn't that much of a stretch, as base64 encoding shows.)
In any case, the omission of the RFC821 rules from RFC1341 was the subject of
considerable discussion and is quite intentional. These are RFC821's own
restrictions. They are not MIME restrictions and imposing them on MIME would be
a really terrible idea. MIME is designed so it can be used in conjunction with
pure binary transports -- places where there are no line length limits, no
character set restrictions, no 7bit restrictions, etc. etc. etc. And MIME is
being using in such environments today.
Restrictions like these are transport issues and nothing more. MIME is designed
to work in environments that impose such restrictions but is in no way
dependent on the restrictions. This is what transport neutrality is all about.
All in all, it is amazing how cleanly it all fits together.
Ned