Dan.Oscarsson writes:
Part 2: Content-Type header
There are to many of them.
There should be a few general ones, internation standards if possible.
Why have scribe,tex,troff,dvi,pbm,pgm,ppm? They are very special.
Why not then FrameMaker?
I am not sure that the pbm, p... are the best standard for images.
We should use an international standard (no fax standard, please) for
images.
There ought to be a few iso character set standards defined.
ISO 8859-1 and ISO 10646.
And MAILASCII, ISO 8859-1 and ISO 10646 should be the recommended
types for text bodies.
I think anything that makes sense to interchange should be eligible for
its own content-type (see my recent posting on this issue).
There's no reason not to do FrameMaker. But I'm not competent to write down
the details of the representation. If you are and you want to do it, by all
means write it up in a companion RFC. I'd love to see a bunch of these
RFCs in the future.
About the postscript type:
Why talk about laserpreps? This is something Apple is using?
Each postscript body should be self-containd. It may not depend on some
separate code having been loaded into the printer.
Like it or not, laserpreps are a fact of life, and it is hard to ignore the
fact that a majority of PostScript use is NOT self-contained because of
laserprep (Macs accounts for the majority of PostScript use the last time I
researched it -- it may not be true these days). I don't like it. In fact, I
hate it, since it is a real mess to deal with in printer software. But my not
liking it does not make the problem go away, and the bottom line is that this
information is often vital to the correct interpretation of a document.
Omitting it because of its inelegance merely forces people to put it back
in using a nonstandard mechanism, and now our purity has caused a loss
of interoperability.
If you think by specifying that PostScript must be self-contained and
cannot depend on laserpreps, I encourage you to espouse this view in the
Mac community. You ain't seen hostile till you do something like this...
Part 3.1: Quoted-Printable
Why use hexadecimal in Style #1?
If style #1 is used for readability I prefer octal codes.
If style #1 is for efficiency each 4 bits could be coded as "A"+value,
this gives faster encoding/decoding.
Yes, and if I fill out my tax return in base -36, I have to write a lot
less (using a negative base lets you write any integer without
a sign) ;-) But then nobody can read it, and I get in a lot of trouble. There
are real advantages to sticking with a format that's readily comprehensible. I
could have figured out style #1 without ever having seen the RFC. And who
cannot afford a 16-byte lookup table and the time to consult it?
Dan
Ned