[Ietf-calsify] ALTREP and ATTACH
camerost at exchange.microsoft.com
Thu Aug 19 15:41:03 PDT 2004
This discrepancy seems broken to me, and it seems to be very unclearly
stated in the document. The MIME structure in particular is left to our
Just so that I understand the Notes implementation - is this correct?
Or am I misunderstanding you?
From: ietf-calsify-bounces at osafoundation.org
[mailto:ietf-calsify-bounces at osafoundation.org] On Behalf Of
Robert_Ransdell at notesdev.ibm.com
Sent: Thursday, August 19, 2004 3:18 PM
To: ietf-calsify at osafoundation.org
Subject: Re: [Ietf-calsify] ALTREP and ATTACH
Notes has implemented ALTREP and ATTACH features.
The ALTREP cid value points to a text/html in the same MIME stream as
the text/calendar but in a multipart/related section.
In ATTACHMENT cid value points to a attachment in the same MIME stream
but in a multipart/mix section.
The iCalendar spec allows the ATTACH to be encoded directly into the
iCalendar stream. Notes code does not use that option.
I don't think the ALTREP parameter has any provisions for inserting the
image within the iCalendar data.
"Cameron Stillion" <camerost at exchange.microsoft.com> Sent by:
ietf-calsify-bounces at osafoundation.org
08/19/2004 06:01 PM
<ietf-calsify at osafoundation.org>
[Ietf-calsify] ALTREP and ATTACH
Section 4.2.1 of RFC2445 contains this example:
DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000 at host.com>":Project
XYZ Review Meeting will include the following agenda items: (a)
Market Overview, (b) Finances, (c) Project Management
The "ALTREP" property parameter value might point to a "text/html"
Content-Id:<part3.msg.970415T083000 at host.com>
<p><b>Project XYZ Review Meeting</b> will include the following
I haven't found any clients that actually support this, but if they did
- it isn't clear from the context of this example where the "content
portion" mentioned above actually lives. possibility #1) Is the .ics
file contained in a multipart/related MIME portion of a message that
also contains this text/html body part? OR - possibility #2) Is this
"content portion" actually inside of the iCal itself? The example isn't
quite clear, but I'm guessing that #1 is the answer, and the rest of
these details are simply left out. If I'm reading this correctly, there
doesn't seem to be any means of specifying the format of the DESCRIPTION
text. Does this mean it is limited to plain text? BioCity seems to
generate DESCRIPTIONS with ENCODING parameter and with actual inline
HTML content. I suppose clients could parse the description, discover
HTML-like tags, guess it's HTML, and do the right thing... but that
seems flimsy to me. Shouldn't we specify the format if it is not plain
text? What do other clients do?
The second half of this question concerns attachments. There is a very
direct mechanism for inlining content, but only if it is BINARY. It
also has an ENCODING parameter (this time, it's in the spec) and
apparently, a way to refer to another "content portion" - again,
non-specific if this is referring to a mechanism of referencing sibling
attachments in a MIME structure, or simply referencing something in the
iCal itself. Again, my assumption is that it is related to a MIME
structure. But, does anyone actually generate or read this kind of
complex multipart/related content?
My gut feeling is that these concepts are closely related and that there
should be very similar mechanisms for inlining or outlining content,
specifying format, etc. for both attachments and the body of the event.
And, am I the only one interested in storing HTML descriptions of
Ietf-calsify mailing list
Ietf-calsify at osafoundation.org
More information about the Ietf-calsify