Excerpts from TODO: 23-Mar-93 multipart/alternative and c.. Gabe
Begeddov(_at_)hpcvxgo(_dot_)cv (1687*)
Lets say I've got a networked home directory across my work and home
environments. At home I've got a 1 plane display and at work a color
display. I
read the message at home and my UA acesses the xbm version and caches it
using
the "shared-id" content-id. The next day I reread the message at work
and can't
get at the color image due to the caching. If the content-id for
message/external-body were associated with the encapsulated headers there
wouldn't be a problem, but as it stands there is a conflict between the use
of
content-id in multipart/alternative and message/external-body.
This is indeed a potential problem. I suppose one answer is to try to
limit the usage of the cache, perhaps by associating each cache entry
with a notion of the environment in which it was obtained. That is, it
works fine if the cache is at the UA level, but not if the cache is at
the MS level.
The other possible answer, of course, is to change the semantics of
Content-ID for multipart/alternative, which were left unspecified in
RFC 1341, and which therefore have presumably not been considered
standardized by anyone. I'm certainly open to alternative semantics --
I just think that they should be made clear. Perhaps we can discuss
this, too, in Columbus. -- Nathaniel