Hello,
On Thursday, 2. August 2001 20:20, Michael T. Babcock wrote:
> > > Yes, actually, his message was perfectly MIME compliant. Read the
> > > source.
> >
> > <snip>
> >
> > OK, please show me the RFC that defines application/ms-tnef :-)
>
> You might want to be silent instead of sounding foolish.
>
> application/ms-tnef is the type of data within a segment of the MIME
> message.
> The message is MIME compliant -- perfectly so. It began and ended with
> proper MIME separators and defined the data types of each of the sections
> of the message, including the plaintext version your mail reader should
> have presented you with. If I'm not mistaken, the ms-tnef section may have
> even been
> labelled as alternative content; not as an attachment.
As far as I get ist, what Marc (and others) is complaining about is the
message <NBBBJHKIOKPKOGOEPEDPCEFCDMAA.stuart@xxxxxxxxxxx>, sent on "Fri, 27
Jul 2001 21:43:58 -0700". That one was of type "multipart/mixed".
The "application/ms-tnef"-section therefore was not (and also should not have
been) "labelled as alternative content".
The question of this message being MIME-compliant or not is not exactly the
point. But when I read RFC 1341, it says:
The
process of defining new content-subtypes, then, is not
intended to be a mechanism for imposing restrictions, but
simply a mechanism for publicizing the usages. There are,
therefore, two acceptable mechanisms for defining new
Content-Type subtypes:
1. Private values (starting with "X-") may be
defined bilaterally between two cooperating
agents without outside registration or
standardization.
2. New standard values must be documented,
registered with, and approved by IANA, as
described in Appendix F. Where intended for
public use, the formats they refer to must
also be defined by a published specification,
and possibly offered for standardization.
As I would guess (but don't exactly know) that MS has not taken step 2, the
second (binary) part of the message schuld have had the
application/octet-stream content type and have the MS-specific stuff done in
a private header field, as stated in:
7.8 Experimental Content-Type Values
A Content-Type value beginning with the characters "X-" is a
private value, to be used by consenting mail systems by
mutual agreement. Any format without a rigorous and public
definition must be named with an "X-" prefix, and publicly
specified values shall never begin with "X-".
Most important and entirely independent of the MIME-compliancy of the message
is the fact that you simply cannot send your data (source code in this case?)
encoded in a proprietary format only readable with proprietary software to a
list that deals with aspects of an operating system for which _no_ software
exists that can read the format. You should really stick to the usual way of
distributing code - make (compressed) tarballs. Which the sender did in a
second message(see <NBBBJHKIOKPKOGOEPEDPGEGDDMAA.stuart@xxxxxxxxxxx> ).
Another thing is that it would have been much better to upload the tarball to
some place in the WWW and simply point interested parties to its URL.
Distributing binary data of whichever size to a whole bunch of people of
which you can tell that a maximum of five to ten percent will one day
possibly look into it. Although 7 kb is not too much, I personally would
consider it impolite. As says RFC 1855:
| Don't send large files to mailing lists when Uniform Resource Locators
| (URLs) or pointers to ftp-able versions will do. If you want to send it as
| multiple files, be sure to follow the culture of the group. If you don't
| know what that is, ask.
Regards,
David Gümbel
--
"UNIX is basically a simple operating system, but you have to be a genius to
understand the simplicity."
-- Dennis Ritchie
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
