• To: IETF SMTP list <IETF-SMTP@xxxxxxxxxxxxxxxxxx>
• From: Robert Ullmann <ARIEL@xxxxxxxxxxxxxxx>
• Date: Thu, 07 Feb 91 15:49:44 EST
• Comment: Created using PRIMAILPLUS Version 1.0 Alpha 5e
• Encoding: 42 message (from R Kankkunen), 34 text (note by ARIEL)

Date: Thu, 7 Feb 91 20:51:01 +0200
From: kankkune@cs.helsinki.fi (Risto Kankkunen)
In-Reply-To: Robert Ullmann's message as of Feb  7, 11:59
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: IETF SMTP list <IETF-SMTP@dimacs.rutgers.edu>

Robert Ullmann:
> > Within the content type, a few simple rules would apply:  All "\"
> > characters are escaped by themselves ("\\").  All lines are printable
> > ASCII.  All non-printable ASCII characters are represented by escape
>
> Perhaps you'd care to comment on what happen when something is
> included (i.e. recursively encapsulated) 5 or 6 times? This is
> _not_ an uncommon experience.

Maybe you can give us an example. As I understand it, RFC 1154 doesn't
even have a way to recursively include body parts, only to catenate. How
can you manage with RFC 1154 then?

And you don't have to take Nathaniel's suggestion as the only
alternative. You could double only the \begin and \end lines, for
example. If a line begins with \begin, you double it to \begin\begin.

> We put a LOT of thought into this, and it is hard to beat the
> idea that there is NO transform applied to the text, just an
> out-of-band count of the "session data units" (read: "lines" :-)
> used in the transport protocol.

David Robinson (04 Feb 91):
> We never really seriously considered "boundary markers".

Maybe this isn't the same we, or you can put a lot of thought into the
matter without considering it?

Risto

--
Risto Kankkunen                   kankkune@cs.Helsinki.FI (Internet)
Department of Computer Science    kankkunen@finuh          (Bitnet)
University of Helsinki, Finland   ..!mcsun!uhecs!kankkune   (UUCP)

--- Annotation added by ARIEL :

Hi,

this is an example of an included message, check out the header.
Of course this could be copied again, etc. (I used copy-append,
copy-prepend is often better).

We did think about boundary markers, but never seriously considered
them. (make sense? Of course not, except that "never seriously
considered" is idiomatic English; and doesn't mean quite what
it seems :-) The meaning is closer to: "it didn't come close to
what we wanted to accomplish".)

e.g.
"Negotiating with Saddam Hussein was Never Seriously Considered."

-- of course it _was_ seriously considered, the meaning is:
"we knew that negotiating never really had a chance of working".

*sigh*
----
'twould be nice if English was a little more precise; I never
dreamed that "apparently blank line" could possibly be ambiguous :-)

One strong objective was that a human user, with only a text
editor, could reasonably interpret a message, regardless of
the OS environment. Breaking out /shar/ files and the like
is a Royal Pain with an editor (even a smart one); I wanted
to avoid that sort of thing.

Rob