Hello David,
As I stated to you and I say again on behalf of all the people that are working
on RFC1154bis that I welcome comments and suggestions on our effort. Please
feel free to make comments....
PLEASE, I must stress this, I really do welcome any comment anyone might have
but they must be constructive.... Thank You!
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.
David I must say, I thought I explained that the draft is being written now,
it is -NOT- complete and is growing daily. The work and R&D is not yet
fully explained or documented. It is not ready to be released -yet-.
PLEASE DO NOT BE LET DOWN. ITS NOT DONE and INPUT IS WELCOME!!!
It still:
- uses line counts for body parts.
There is absolutely nothing wrong with using line count. It works.
show me a mailer that will have a problem with line count and I will
consider a change...
- has a small number of body parts types and no way to register new ones.
Boiler plate info explaining how to add/register parts has not been added
yet because the doc is still being updated...
- mixes the concepts of body part type and encoding type into one
pile of names.
This is an important concept. If you see a problem with this please be more
specific. The "pile of names" are keywords, these word define what a body
is encoded as. The type of encoding may have a seperate set of keywords that
further define a part or section of a part. This allows one keyword or
nested keywords suffice in the "Encoding:" header field.
- uses HEX and UUENCODE encodings (with each's known problems)
It will support HEX and UUENCODE with their known problems. The two
encodings of choice are LZJU90 and FS. A -Great- deal of work has gone
into these two encoding types.
- only supports the "full range of the ASCII character set"
What is the problem here?
- has no way to support lines of more than "reasonable length" (i.e. 1000
octets)
Please elaborate on the problem.
- has no body part structuring other than `message' body parts
Please show me a need and I will consider it.
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 ...
Hmmm. It would be more like: postscript lzju90
- no mention is made anywhere of RFC-934 (943?) (unlike 1154 does).
So?? Elaborate please.
- 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.
YES! FS Encoding _IS_ worth reading. Please send me comments when ready.
FS encoding was born on a Prime 50 Series. It is now much different in this
doc than the FS format now used. Would you like more examples? What OSes?
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.
------------------------------------------------------------------------------
Life is what happens while your making other plans.....
------------------------------------------------------------------------------