Thanks Jacob -- Next question...
I gather that via EMail, we might deal with the negotiation
requirement by just sending all the alternatives. This of course
could lead to sending grossly large messages of which one small
portion is really wanted.
I suppose that we might need a new MIME type, perhaps called
perhaps with negotiation information in registered parameters?
I wonder how hard it would be to to develop this in concert with the
HTTP negotiation protocol efforts?
From Jacob's message Sun, 3 Aug 1997 11:35:14 +0200:
}At 13:57 -0700 97-07-29, Einar Stefferud wrote:
}> What possible interactions or relationships exist between this
}> HTTP version of "Multipart/Alternative" and the MIME verion of
}> Is there any straight forward way for someone trying to send a copy of
}> such content using MIME Multipart/Alternative?
}> Or is this just not possible, and thus a dead issue?
}Yes, this is allowed, see the following quote from RFC 2110:
} The root body part of the multipart/related SHOULD be the start
} object for rendering the object, such as a text/html object, and
} which contains links to objects in other body parts, or a
} multipart/alternative of which at least one alternative resolves to
} such a start object. Implementors are warned, however, that many
} mail programs treat multipart/alternative as if it had been
} multipart/mixed (even though MIME [MIME1] requires support for
}A discussion of techniques for using multipart/alternative is included in
}There is an issue of how to specify the "type" parameter to
}"Multipart/related" when it refers to a "Multipart/alternative"
}body parts, which will be discussed in Munich.