Subject: [Ietf-calsify] ALTREP and ATTACH

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Thu Aug 19 15:02:45 2004

Skipped content of type multipart/alternative

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Thu Aug 19 15:18:24 2004

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" <[email-masked]> 
Sent by: [email-masked]
08/19/2004 06:01 PM

To
<[email-masked]>
cc

Subject
[Ietf-calsify] ALTREP and ATTACH

Section 4.2.1 of RFC2445 contains this example:
 
Example:

     DESCRIPTION;ALTREP="CID:<[email-masked]>":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 portion.

     Content-Type:text/html
     Content-Id:<[email-masked]>

     <html><body>
     <p><b>Project XYZ Review Meeting</b> will include the following
     agenda items:<ol><li>Market
     Overview</li><li>Finances</li><li>Project Management</li></ol></p>
     </body></html>

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
events?
 
cameron
 
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Aug 20 08:52:53 2004

>complex multipart/related content?
Yes, and it directly relates to one of your questions about VCARD.  By
referencing a URL. A URL can also be a CID URL or MID URL. They refer
to message content of a MIME message.

So in effect your can send an iCalendar object as an attachment and
include in the email other attachments that are referenced by URL in
or not in the same MIME object.

It is BINARY so that any charset data can be included. Simply decode it
and it is what ever they sent, plain text or UTF-32 or ...

>And, am I the only one interested in storing HTML descriptions of
Why not just send multipart alternate?

iCalendar is an exchange format for exchanging calendar information.
And that format can be saved in an .ICS file. However most implementations
only use that format for import and export. As in you read in the MIME 
object
(including other related parts of the MIME message) and store them any way
you want. The iCalendar MIME object is simply the way to transfer the 
information.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040820/5651b722/smime.bin