Re: Eudora VS MIME RFC

[Ned Freed <[e-mail]>]

> MIME Authors,

> This is an explanation of the difficulties some of our mail products
> are having interrupting MIME encoded attachment being sent using
> Eudora.

> As Steve, form Qual Comm, has pointed out; a confusion has resulted in
> determining and reading boundary definitions in regards to the MIME
> RFC.  Your last supplement does a lot to clarify the problem,
> unfortunately, it doesn’t help us remedy the conflict that already
> exists.  There are several a
> pplications that can not correctly locate Eudora’s boundaries because
> their boundaries are not explicitly unique.

It depends on what you mean by "unique". If you mean that they don't appear as
substrings of other possible strings then yes, they are not unique. But this
was not intended to be a condition of uniqueness to the best of my knowledge.

However, I don't especially care which way this goes. All I care about is
consistency at this stage of the game. Thus far prevailing opinions have been
that the Eudora approach is legal. But had things gone otherwise in terms of
the group's opinion I could have lived with that too.

The bottom line is that there's an unintentional ambiguity in the specification
and now there are uncompatible implementations out there. And regardless of how
we resolve this (and rest assured this will be resolved), something somewhere
is going to have to change to fix the problem.

You seem to want Eudora to be the one to "correct" this. I agree that it
should be easy for Eudora to be changed as stated. But this doesn't
mean that Eudora should be changed this way, nor does it do anything to
implement such a change in the many thousands of copies of Eudora already
in use.

				Ned