Subject: [Ietf-calsify] iMip and ALTREP and ATTACH

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Fri Aug 20 10:56:28 2004

Ah, I see.  :)  Forgive my impertinence earlier...

I wonder if we should extend this discussion in to the realm of iMip and
iTip, but actually we already have.  Removing the other schema elements
already impacts these standards, I see.

I don't see anything in iMip that reflects the Lotus implementation.
And I don't see a PUBLISH example with attachments and rich bodies.
This might be worth adding.  Who's working on this?

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, August 20, 2004 9:36 AM
To: [email-masked];
[email-masked]
Subject: RE: [Ietf-calsify] ALTREP and ATTACH

I thought the iMip RFC 2447 did that.
http://www.faqs.org/rfcs/rfc2447.html

The reason I have the multipart/mixed as the outer layer is so that all
the multiplart/alternatives get assess to the attachment.

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked]
08/20/2004 12:13 PM

To
<[email-masked]>
cc

Subject
RE: [Ietf-calsify] ALTREP and ATTACH

At the very least I think the ALTREP and ATTACH methods should use
similar syntax and have equivalent representation of inline/outline
bodies/attachments. They are so very similar, after all.

Speaking of MIME and transport... Is it just me, or is it strange to mix
the standards for the standalone schema type and the MIME structure that
can be used to transport the format? Perhaps there is precedence for
this method of specification. 

I understand the need to include links to other MIME parts in the
specification for the format, but perhaps this highlights the need to
have another (perhaps informational?) RFC which details the methods used
to transport iCal and its parts via MIME. 

In the crypto world, it seems that things were done this way - one
document specifying the format in great detail, and another document to
describe how the format is transported via MIME.  Interoperability, it
seems to me, will be a serious problem without at least some word on the
MIME structure that should be used.  For example: How many iCal readers
will understand the aforementioned Lotus implementation with its
hierarchy of combined multipart/related and multipart/mixed?  Your
suggestion to use multipart/alternative only highlights the problem.  We
can all think of reasonable and completely different ways to do this. I
cringe at the possible combinations each vendor will invent to do the
same thing.  If indeed iCal is simply the import/export format as you
say, then it seems to me that specifying more formally the MIME
structure to be used in transport is equally important.

Thoughts?

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Friday, August 20, 2004 8:53 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] ALTREP and ATTACH

Cameron Stillion wrote:

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

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

_______________________________________________
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 11:57:42 2004

Does not RFC-2447 section "2.4 Content Type" cover that?

Rich bodies as in multipart/alternate?

Examples, yep more would help.

-- 

-------------- 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/eee9ae7d/smime.bin