Eudora VS Mime RFC (continued)

[sanbornd@xxxxxxxxx]

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
>
>