Re: multipart/alternative extension

On 5/7/01 at 2:53 PM -0400, Keith Moore wrote:

>With multipart/choices there is still potential for information loss,
>because some clients fail to follow the specs regarding treatment
>of multipart/unknown.

I've never known any implementation that actually throws away pieces 
of a multipart/unknown. But even if there were such a beast, one or 
two occurrences of actively broken software would not prevent any 
server from trying to send multipart/unknown when the vast majority 
of clients out there deal perfectly reasonably with it as 
multipart/mixed.

>Even with multipart/mixed, if the desired content is presented as an
>attachment, this can effectively cause information loss if the recipient
>doesn't understand that the version he/she understands is in that
>attachment, and/or he/she doesn't know how to read that attachment.

That certainly leads to information *obscuration*, but it doesn't 
lead to information *loss*. I'm not sure if you exactly understand 
the extent of the problem. Eudora, for instance, if it receives a 
multipart/alternative with text/plain and text/html, will 
*irretrievably throw away* the text/plain on the assumption (as the 
spec implies) that the HTML is higher fidelity and therefore no 
information was actually in fact lost (a rather bold assumption, 
eh?). This makes multipart/alternative way too scary for someone to 
send if they know that the recipient might need to see the other 
parts. With a multipart/mixed or multipart/foobar, you at least have 
pretty good odds that the user will see something reasonable.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Received on Monday, 7 May 2001 15:04:53 UTC