First off ... PLEASE move discussion to the ietf-822 list. I believe
the shouting currently happening on `ietf' is not necessary and also
damaging.
In any case, in the interest of finding out some truth, I asked Al for
a copy of his new 1154 spec. It arrived here (side note: marked
as `text' even though 1154 has a PostScript body part type ;-)) and
printed nicely enough. But is a big let down considering all the
shouting and noise he is making.
It still:
- uses line counts for body parts.
- has a small number of body parts types and no way to register new ones.
- mixes the concepts of body part type and encoding type into one
pile of names.
- uses HEX and UUENCODE encodings (with each's known problems)
- only supports the "full range of the ASCII character set"
- has no way to support lines of more than "reasonable length" (i.e. 1000
octets)
- has no body part structuring other than `message' body parts
The new things are:
- you can now combine many type names into one. it isn't completely
clear what some of the combinations might be (TEXT + EDI seems questionable
for instance) (this is a side effect of mixing types and encodings
together). but you do get to say "postscript tar lzju90" all in
one breath ...
- no mention is made anywhere of RFC-934 (943?) (unlike 1154 does).
- they have defined LZW and LZJU90 compression.
- there is something called `File System Object Encoding' which I haven't
read closely enough to understand but which looks interesting. it appears
capable of encoding complex file formats into a byte stream. this means
things like VMS's RMS, and other `segmented' or `record oriented'
formats from other systems. many of the examples are specific to things
I recall from my exposure (which I try to forget about) to PR1MOS.
The last two are things we might could borrow for use in MIME. The first
because it is a specification for a compression format. The last to support
our friends who live on systems with (uhm) interesting file systems.
But then it isn't clear if these specifications are very rigorously defined.
<- David Herron <david(_at_)twg(_dot_)com> (work)
<david(_at_)davids(_dot_)mmdf(_dot_)com> (home)
<-
<- "That's our advantage at Microsoft; we set the standards and we can change
them."
<- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial.