iCalendar Stuff
===============
You can either have the value for the content be in the event definition (i.e., inline BINARY value content) or it can be external to the event definition (i.e., a URI value content). In the latter case, the URI could be a FTP, HTTP, FILE, CID, MID or whatever type of appropriate URI to specify an external content information.
iCalendar is complete in specifying this semantic.
iMIP Stuff
==========
The issue came up when Lotus Organizer was testing with Microsoft Outlook. Lotus Organizer sent an invitation to Microsoft Outlook as a multipart/mixed message containing, first, a pretty text/plain description of the invitation and, second, a text/calendar iCalendar encoding of the invitation. The issue is that iMIP currently only mandates that a conforming implementation support a text/plain "singleton" MIME entity. In one of the IETF meetings, we discussed and later confirmed (I believe) a general WG consensus that the iMIP specification should be changed to mandate support for not only text/calendar content, but also text/calendar within a multipart MIME content type.
What you are suggesting is that the iCalendar object includes a related attachment content (e.g., image/jpeg) with a map of the meeting venue. For argument sake, let's say this was passed as an attachment. This would probably be MIME encoded as a multipart/mixed or a multipart/related MIME entity consisting of the text/calendar and image/jpeg components. BUT, note that this could further be encapsulated into a multipart/mixed containing a short text/plain text note and also the multipart/mixed (or multipart/related) compound iCalendar component.
My debate with Doug is his assertion that this support for "multipart" should be in the definition of the text/calendar content type, the iCalendar specification. I strongly disagree. Saying how the text/calendar content can be further (and secondarily) encapsulated is a transport wrapper matter.
So, it belongs in the iMIP specification.
Indeed, folks will be referencing the iCalendar standard as a standalone content definition. It should NOT be encumbered by a requirement to support MIME multipart wrapping of the text/calendar content. This is an issue for how you want to transport it.
For example, for an operating system clipboard "binding" of iCalendar, we would probably say that the ATTACH property value would be a FILE type URI, pointing to the attachment within the operating system's file system. There would be absolutely no need to have the overhead of the additional support for the multipart form.
BTW, within the iMIP specification, if we make this change happen, then we also need to state just how many levels of nesting we expect an iMIP recipient to parse the content. Right? I can fathom mandating support for the text/calendar being embedded one level, but farther down seems problematic.
SO...Net-net: The change needs to be made to the iMIP, not iCalendar specification. We could, however, add some text to the iCalendar spec that says that text/calendar objects _can_ be further encapsulated into multipart MIME entities. But this is just an informative comment.
-- Frank