Re: RFC-XXXX Boundary Marking

["Ned Freed, Postmaster" <NED@xxxxxxxxxxxxxxxxxxxx>]

> I think one of the difficulties you are having in firming up RFC-XXXX's
> boundary-marking scheme is that:

>     o  On the one hand, it is a goal to be insensitive to the gratuitous
>        addition of <EOL>s (end-of-line - CR/LF in SMTP) by mailers along
>        the mail path.

>     o  On the other hand, you are trying to use <EOL> as the start of
>        your boundary-mark sequence.

> These goals would (at least theoretically) appear to conflict.

I don't see why they conflict. Can you present an example?

True, if an EOL is inserted in the middle of a boundary marker, it will mess 
things up. But in general, insertion of enough EOLs in a message will mess up 
everything -- headers, body, you name it. We're operating from a practicum 
point of view here, which says that people don't insert EOLs for the hell of 
it, they do it because they have a line length restriction or some such. 80 
characters is probably a reasonable guess of the largest generally tolerable 
line that won't get wrapped. Boundary markers should be tolerant of wrapping at 
lengths down to 40, so there's ample margin for error.

I have no practical experience with mailers removing EOLs, which would
definitely cause problems with boundary markers defined to begin at a line
boundary. If such mailers exist and instances can be cited, it would be
an argument against the requirement limiting boundary markers to the beginning
of lines. The primary reason for this requirement is that it makes them
easier to spot on a lot of systems. Markers will work even if they're not
limited in this way.

I was opposed to boundary markers myself because I had not experienced line 
wrapping that did not indent wrapped portions of lines. I didn't think
boundary markers were worth the effort since I had not seen an instance
proving them to be useful. However, instances were cited of mailers that did 
wrap without indenting, which causes significant problems with the simple 
RFC934 scheme. This convinced me that boundary markers were a good idea after 
all and that the extra work needed to spot them was worth it. (It was also
made clear to me that they're not as hard to spot as I thought, which
helped.) 

It has been pointed out that line counting will work if you wrap all lines
to some minimally acceptable point. This is certainly true, and if we adopt
the idea of wrapping everything unconditionally to fit within, say 64 character
limits (to be on the safe side), I could live with line counting (the need
for two passes or back-patching still bothers me, but I can live with it).
However, I do feel that line-wrapping is the exception, not the rule, and
while I think any encapsulation scheme chosen must be resistant to this sort of 
behavior in a mailer, I'm not convinced that we should force ourselves to
deal with this problem to the extent of garbling all messages to cater to
these systems.

					Ned