Jeff,
Thanks for your courteous response, I haven?t gotten any of those from
Qual Comm. I do agree that the problem arose from an unforeseeable
difference in the interpretation of the MIME RFC. I still think that
the simplest solution and the best fix would be to assure boundaries
are completely uni
que. Unique boundaries would guarantee that there could not be any
possible confusion in decoding mail; the ultimate goal of the RFC.
From our standpoint fewer products would have to be modified to
implement the change and the quickest fix could have been provided by
Qual Comm (which without a
ny cooperation hasn?t been the case).
Thanks again for taking an objective view of the issue.
Doug Sanborn
Rome Labs/SC, 1-315-330-7258
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