Subject: Re: CALSCH Action Items - - Error

From: [email-masked]
Date: Mon, 10 Apr 2000 14:16:37 -0400

>As I recall, it was discovered by informal interop testing between
>Lotus and Microsoft. And it was seen as a flaw in iCal.

Yes, but to be clear it was informal interop testing of iMIP.
This is an iMIP issue, not an issue with the iCalendar spec.
-- Frank

---

From: [email-masked]
Date: Mon, 10 Apr 2000 14:52:31 -0400

Doug:
The support for multipart comes in when we begin to talk about 
interoperability of the scheduling semantics over email. This is where we 
ran into the problem between Lotus Organizer and Microsoft Outlook. I was 
the one who reported it.
At one of the IETF meetings we addressed this under the discuss of errata 
against iMIP, not iCalendar. It was decided there that a change was needed 
to the iMIP spec.
Please change it in your "Action Items" document to an iMIP related bug. 
The iCalendar spec interoperates fine without it, but the iMIP spec 
doesn't.
The fact that the ATTACH property and the ALTREP parameter _can_ specify a 
CID or MID URI (as specified only in examples) for the URI based value 
doesn't mandate that an iCalendar implement MUST support multipart MIME 
entities. Indeed, the MID URI for an ATTACH property could specify an 
message identifier external to the current message. The standard specifies 
that the value is either a URI (which could be other URI types than a CID 
or MID) or an inline binary value. ALTREP is a URI value. Most probably 
NOT a CID or MID URI but more likely a HTTP URI.
In fact, an iCalendar CUA is very likely to support inlined attachments 
and HTTP type URIs for alternate representation of text content.
It is a big jump to say that all iCalendar implementations MUST support 
multipart. In fact an implementation that is using iCalendar for 
import/export won't be doing this. The point is that many implementations 
will conform to the RFC2445 just as a content definition.
-- Frank

---

From: [email-masked]
Date: Mon, 10 Apr 2000 16:36:45 -0400

Frank proposed:
>ALTREP is a URI value. Most probably NOT a CID or MID URI but more likely 
a HTTP URI. 

Actually the converse is probably true here.  If I have DESCRIPTION with 
an ALTREP Im VERY LIKELY going to put it into the same message as another 
MIME body part, NOT in a separate email that may get there in a different 
order (where it could be a non-sequeteur to the recipient!). 

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 12 Apr 1988 12:17:58 -0400

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

---

From: [email-masked]
Date: Tue, 12 Apr 1988 12:42:19 -0400

Doug Royer wrote, in part:
>And I agree with Bruce's email where he states that a CID or MID
>is very likely be the way to include attachments to appointments.

This may be a very narrow view on the use of iCalendar. Certainly, for 
usage outside of email, the attachment may be specified as an external 
entity in a local file system (i.e., with a FILE type URL), as a network 
entity (i.e., with a HTTP type URL) or even passed inline (e.g., with 
usage over Bluetooth or IrDA).
iCalendar, as a data dictionary, specified the semantics clearly. The 
ATTACH value can either be an inline BINARY value or a URI value. In the 
latter case, the attachment content is somewhere external to the iCalendar 
object.
But to mandate that it be in a multipart content is clearly too 
restrictive.

---

From: [email-masked]
Date: Wed, 12 Apr 2000 13:25:06 -0400

Frank fired:
>This may be a very narrow view on the use of iCalendar.

Not presently.  Given that we are doing CalConnect NOW and have yet to 
finalize CAP (which will have a longer window for implementation than say 
this year) I think the VAST majority you will find in the near term WILL 
be CID.  Otherwise we can expect greater interop problems when dealing 
with firewalls, Intranet vs Internet and other classic problems.   Id 
prefer to get a MIME stream w/ALL the data in it rather than an iCalendar 
message that requires my CUA to go out and try to retrieve the data (from 
potentially inaccessible URIs!!).

Besides, thats how MHTML (RFC 2557) and other rich content schemes work. 
Are you claiming that they too have too narrow a view?

>Certainly, for usage outside of email, the attachment may be specified as 
an external entity in a >local file system (i.e., with a FILE type URL), 
as a network entity (i.e., with a HTTP type URL) >or even passed inline 
(e.g., with usage over Bluetooth or IrDA). 

For example #1, thats just an access problem waiting to happen!  I grant 
0% access to my local disk for both personal and work reasons.  Just not a 
good example to even THINK about.

Example #2 is good for intranets and possibly for some internet cases but 
it hand waves on the access problems that CAP is still mulling over.  What 
are the odds that Microsoft would send you an HTTP URL to an internal 
server for you to read??

Example #3 is currently there but its ONLY usable for data types of URI 
like ATTACH but its totally off base WRT the example I used originally of 
DESCRIPTION;ALTREP=... where INLINE is NOT available!!  VALUE=INLINE is 
NOT available for ALTREP= parameters last I checked.

restrictive. 

We are too far afield from the original comment context.  If I have a 
DESCRIPTION;ALTREP=, is it unreasonable to have it in another MIME body 
part that is sent w/this Content-Type: text/calendar?  Hardly.  Is it 
unreasonable to have it stored externally to the MIME stream and have the 
CUA retrieve it?  Hardly.  Which would be a more functional (or usable) 
way to convey my HTML alternate representation of DESCRIPTION: a URL that 
may or may not be accessible at any given time to those who need it or to 
have it in the same data stream as the entry that references it?  Id bet 
the latter.

(BTW: NOONE ever claimed that we mandated it be in multipart only.  Where did you see 
that??)

Bruce

---

From: [email-masked]
Date: Wed, 12 Apr 2000 15:51:44 -0400

<CAVEAT>
This started as a short msg but it grew long.  Some technical tubbing 
happens so be forewarned!
</CAVEAT>

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

This is a misuse of multipart/mixed.  From RFC 2387, 3.  Intended usage

   The Multipart/Related media type is intended for compound objects
   consisting of several inter-related body parts.

In your example, the proper MIME type should have been 
multipart/alternative instead.  From RFC 2046:

5.1.4.  Alternative Subtype

   The "multipart/alternative" type is syntactically identical to
   "multipart/mixed", but the semantics are different.  In particular,
   each of the body parts is an "alternative" version of the same
   information.

I hope that the current and past editors have properly used the right 
multipart/* subtypes in their drafts.

>The issue is that iMIP currently only mandates that a conforming 
implementation support a >text/plain "singleton" MIME entity.

Actually it has no such mandate.  Check out 4.2 Using Multipart Alternative for Low Fidelity Clients

   This example shows how a client can emit a multipart message that
   includes both a plain text version as well as the full iCalendar
   object.  Clients that do not support text/calendar will still be
   capable of rendering the plain text representation.

This is strictly an example of HOW to do lower fidelity invites using 
multipart/alternative and text/plain.  There is 0 requirement in iMIP for text/plain support.  That kind of conformance is really a MIME 
compliance issue (best deferred to Chris Newman or some other MIME guru).

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

To KISS, Ill assume no alternate representation of the text/calendar. 
Checking RFC 2046 yeilds the following:

5.1.3.  Mixed Subtype

   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.
   Any "multipart" subtypes that an implementation does not recognize
   must be treated as being of subtype "mixed".

Since our example is closer to the mixed world Id propose we clearly call 
this out and not cause further confusion with multipart/related.  Chris 
can slap me silly if I have it backwards.

In any case, the example nows boils down to:

Content-Type: multipart/mixed
        Content-Type: text/calendar
            [The meeting invitation]
        Content-Type: image/jpeg
            [The attached map]

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

Do you mean that there is a lower fidelity text/plain in the stream?  That 
would simply change the structure to:

Content-Type: multipart/mixed
        Content-Type: multipart/alternative
                Content-Type: text/plain
                    [Low fideltiy description of meeting invitation]
                Content-Type: text/calendar
                    [The meeting invitation]
        Content-Type: image/jpeg
            [The attached map]

If your CUA wanted to get really really fancy then it could also include 
other alternative renderings in the Content-Type: multipart/alternative in 
the proper place (ie: application/ms-tnef, application/x-lotus-rtf, etc). 
This does not make the outer wrapper more complex.  Adding ALTREP data to 
the DESCRIPTION does make it a bit nastier.  My take on the MIME RFCs is 
that the structure for including ALTREP data would become:

Content-Type: multipart/mixed
        Content-Type: multipart/related
                Content-Type: multipart/alternative
                        Content-Type: text/plain
                            [Low fideltiy description of meeting 
invitation]
                        Content-Type: text/calendar
                            [The meeting invitation]
                Content-Type: text/html
                    [The HTML ALTREP for the DESCRIPTION property]
        Content-Type: image/jpeg
            [The attached map]

Ok, so this KISS example is now definitely NOT KISS.    Since this complex 
layout is what could be generated for even the most simplest of cases (an 
invite with an attachment) Id like to see A) the MIME wrappering 
confirmed/fixed by Chris Newman (or Paul H.) and B) added to the proper 
RFC updates!

>Saying how the text/calendar content can be further (and secondarily) 
encapsulated is a transport >wrapper matter. 

Given that this affects all transports that convey the data, Id suggest 
that this belongs at the iTIP level rather than at the iMIP level. 
Otherwise it may get ignored or overlooked in other bindings of iTIP or 
not even considered when other transport methodologies are defined in the 
future.   I do agree with Frank in that its probably not apropo for the 
iCalendar RFC since iCalendar is just the language definition, not a 
definition of HOW it is used.

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

It may be obvious to others but its not to me so Ill ask: Just how did the 
attachment get to the file system?  Did it get magically put there when I 
selected "Save as" in response to bringing down the iCalendar?  There are 
also assumptions that the file path is kept intact and that it will work 
on all platforms that the user has (ie: Mac, BeOS, Un*x w/ and w/o GUIs, 
Win32, etc).  Lots of room for error or simple actions to break the 'link' 
between the file and the iCalendar data in this scenario.

From an end users perspective, Id like to be able to do 1 action 
(Drag/Drop, File->Export, etc) and have my entry saved as a local file. 
This file would have all that I need to send the full notice to someone 
(ie: IrDA, File uploade in a browser, FTP, etc).   End users (David Madeo 
can correct me if Im wrong here) do NOT want to have to keep track the 
files on their drives and any relationship between them: "I need to keep 
m12345.zip around since I still have Frank.ics on my drive but I deleted 
Hockey.ics so I can remove both NHL2000.doc and 7326345.zip".  From an end 
users perspective I seriously suspect 1 file MUCH easier to deal with than 
separate ones!  It may not be easier on us as implementors but users dont 
care about our pains just THEIRS!!

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

Its always nice to end on a good note and while I disagree on iMIP being 
the place to make the additions, I do agree that iCalendar would benefit 
from said addition.

Bruce

---

From: [email-masked]
Date: Wed, 12 Apr 2000 16:24:32 -0400

Bruce:
But isn't the common fallback to multipart/alternative and 
multipart/related a multipart/mixed?
-- Frank

---

From: [email-masked]
Date: Tue, 12 Apr 1988 16:01:52 -0400

I still disagree that this should be part of iCalendar. It should be a 
change to iMIP.
-- Frank