To my mind, the only negative thing that RFC-XXXX has is this looming threat
of nested encodings.
I am willing to consider PEM to be an independent issue. It's important, but
it's an option. What's more, it is something that will happen on an end-to-
end basis, not by some agent(s) in the middle. Nested encodings are not an
option for an RFC-XXXX implementor. Unless they are banned now, then
everybody is forced to implement them.
The only way nesting happens in RFC-1154 is with a MESSAGE segment. I found
that it is considerably easier to parse an RFC-1154 message than it is to
parse an RFC-XXXX. My RFC-XXXX support code is much larger than the late (and
unlamented) RFC-1154 support code. The main nasties in RFC-1154, as far as
I'm concerned, are its obsession with "lines" as something that is meaningful
to count (remember my "what is a line?" series of message) and its non-
addressing of the encoding issue (by assuming it can all be dealt with in the
MTA).
Other than that, RFC-1154 is quite simple and straightforward. This is
something that I feel certain people (not you Ned!) have lost sight of. I was
able to implement message attachments using RFC-1154 in a very short period of
time. I was disturbed by RFC-1154's bug in terms of applying a meaning to a
meaningless concept (line as something you can count). But I had a working
implementation in production use. I wish I could say the same thing after
spending three times as much time on RFC-XXXX, much of it dealing with this
nested encoding issue.