Excerpts from transarc.system.ietf-822: 24-Sep-91 Re: Question on
encapsulation Timo Lehtinen(_at_)sti(_dot_)fi (893)
| The algorithm I use is very simple -- I combine a variety of pieces of
| information (including parts of the current message, the local system
| name, the current date/time string, etc.) and feed the resulting very
| long string into a digital signature algorithm.
....
| The resulting key is encoded into a printable form that's
| roughly 40 characters long.
No offense, but to me this sounds ridiculous. I really don't see
any reason to not use the boundary marking concept from RFC-934.
(I know RFC-XXXX hasn't had that for a long time).
To recap, the reason not to use the RFC 934 concept was line folding of
messages in transport. Such line folding (by existing mail-handling
agents) could corrupt the RFC 934 method.
Ned's selection of a digital signature algorithm as a method of choosing
a boundary marker is simply a matter of taste. If you don't like it,
you're welcome to use a much simpler method for choosing a boundary
marker, as long as your choice isn't used anywhere in the message. You
can be optimistic in how you choose the marker, so that you can pick a
marker and then write the assembled message, without first scanning the
message parts. Still, I'd recommend that if you're being optimistic,
that you nonetheless have some mechanism to check whether your selected
marker really is unused in the message pieces, and some mechanism to
handle the situation wherein the marker turns up to be used: unwind,
pick a new marker, and try again.
I'm not trying to dispute Ned's argument that he'll never have to
unwind/retry with his particular marker choice, at least not in this
message.
Craig