[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Eudora VS Mime RFC (continued)
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.
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
>> As Steve, form Qual Comm, has pointed out; a confusion has resulted
>> 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
>> their boundaries are not explicitly unique.
>It depends on what you mean by "unique". If you mean that they don't
>substrings of other possible strings then yes, they are not unique.
>was not intended to be a condition of uniqueness to the best of my
>However, I don't especially care which way this goes. All I care about
>consistency at this stage of the game. Thus far prevailing opinions
>that the Eudora approach is legal. But had things gone otherwise in
>the group's opinion I could have lived with that too.
>The bottom line is that there's an unintentional ambiguity in the
>and now there are uncompatible implementations out there. And
regardless of how
>we resolve this (and rest assured this will be resolved), something
>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
>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
>implement such a change in the many thousands of copies of Eudora