Subject: RE: MIME Multiple body parts (Was Re: uid...)

From: "John Stracke" <[email-masked]>
Date: Thu, 8 Nov 2001 16:02:57 -0500

>1 - are we discussing a MULTIPART composed of iCalendar related objects?
>(some encrypted, some not perhaps?)

Only if we adopt Bruce's suggestion of having some fields encrypted and 
others not (this could be done by the multipart/alternative approach I 
mentioned).

>2 - are we discussing a MULTIPART composed of a text or text/html object 
+
>an iCalendar object?

I think so.  For example, it will probably be common to send a 
multipart/mixed containing a text/plain and an text/calendar.  (Less 
common, because it's broken, is the approach taken by Microsoft Entourage: 
a multipart/alternative containing first the text/calendar and then the 
text/html.  A recipient that understands text/html will never see the 
text/calendar.)

>Also - if the iCalendar object has say an Attachment - are we considering
>allowing that ATTACHMENT to be bundled as part of the MULTIPART message,
>and/or for that ATTACHMENT to be encrypted in some manner?

Strictly speaking, it's permitted by RFC-2445; the ATTACH is specified by 
a URL, so you can use a cid: to reference bodyparts.  Whether a CAP server 
would deal with it is another question.

As a practical matter, sending an iMIP message with a cid: attachment is 
probably risky.  It's easy for a recipient's MUA to take the text/calendar 
and pass it off to the CUA for processing; but permitting the CUA to go 
back to the MUA to resolve the cid: URL requires more integration.  It'd 
be trivial for an app that combines the CUA and the MUA (e.g., Evolution, 
Outlook, Notes), but not for independent apps.

/================================================================\
|John Stracke                    |Principal Engineer             |
[email-masked]   |Incentive Systems, Inc.        |
|http://www.incentivesystems.com |My opinions are my own.        |
|================================================================|
|"The struggle is always worthwhile, if the end be worthwhile and|
|the means honorable; foreknowledge of defeat is not sufficient  |
|reason to withdraw from the contest." -- Adron e'Kieron, by     |
|Steven Brust                                                    |
\================================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 8 Nov 2001 16:20:05 -0600

John,

Thanks - helps clarify matters.

Something else I realized -

There is a common trend to associate ONE MIME object holding an iCalendar
object with ONE vEVENT (and perhaps a vTimezone object). In fact I think
some vendors may ONLY deal with iCalendar objects that contain only one
vEVENT.

However it is clearly valid to have a vCalendar with multiple vEVENT objects
(or else what are we doing here???)

How would you encode a iCalendar object holding multiple vEVENTS that were
in DIFFERENT languages (and required DIFFERENT character encodings - say a
calendar with meetings in Tokyo and Singapore - requiring Japanese and
Chinese character encodings...)?

In general how are "full calendar" objects intended to be handled - much of
the standards we are writing seem to treat individual events as the primary
unit for work - associating with them perhaps a vTimezone object, but other
objects such as vTODO or even multiple vEVENT objects seem to be perhaps
more complex to deal with?

For that matter should it be possible to send multiple vCalendar objects?

thanks,

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Thursday, November 08, 2001 3:03 PM
To: [email-masked]
Subject: RE: MIME Multiple body parts (Was Re: uid...)

+

---

From: Steve Mansour <[email-masked]>
Date: Thu, 08 Nov 2001 15:44:30 -0800

> (or else what are we doing here???)

you'd think it would be clearly valid wouldnt you?  Actually, there was
a very persuasive group of folks that wanted text/calendar mime parts to
only contain components with a single UID.  And they won :-)  Have a
look at the restriction tables in iTIP. For VEVENTs, where the presence
value is 1+, the text specifies that all components must have the same
UID.

> Chinese character encodings...)?

While I am not a fan of limiting the iCalendar objects in iTIP to a
specific UID, it does seem to mitigate this problem.  I think it would
be very unlikely to have a recurring event where different instances of
the same event have different character encodings.

> more complex to deal with?

iTIP doesn't handle this.  CAP probably should. Any suggestions?  Worst
case, we require multiple sends.

-Steve

---

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 8 Nov 2001 18:06:05 -0600

Steve,

This does explain something - I have spent the least time looking over iTIP
so I had missed that section - but it is a clear indication of the different
viewpoints on what use is intended for iCalendar objects.

Simple and VERY common use case I have a question about:

Calendar User Agent connects to Calendar Store for the FIRST TIME.

Use case is - How does the CUA obtain the full calendar for that USER from
the Calendar store?

"multiple sends" - seems like a very ugly solution.

I believe this is an EXACT use case from our documents - it is implied that
Calendar User Agents will maintain a LOCAL Calendar Store - to me at least
this implies a means to obtain the FULL calendar for that user from the
remote store to a local store.

thanks,

Shannon

-----Original Message-----
From: Steve Mansour [mailto:[email-masked]]
Sent: Thursday, November 08, 2001 5:45 PM
To: Shannon J. Clark
Cc: John Stracke; [email-masked]
Subject: Re: MIME Multiple body parts (Was Re: uid...)

-Steve

---

From: Doug Royer <[email-masked]>
Date: Fri, 09 Nov 2001 15:28:26 -0700

> others not (this could be done by the multipart/alternative approach I

Currently multipart/related objects could be encrypted, but
they would not be text/calendar.

> probably risky.

Yes - now. But we should encourage implementors to understand all
of MIME and not limit themselves.

>  It's easy for a recipient's MUA to take the text/calendar

They just need to forward the entire MIME message if they
don't look inside.

We also did not limit them to CID/MID. Any including (but not
limited to) ftp, imap, file, ... URL schemes could be used.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Fri, 09 Nov 2001 15:31:44 -0700

> Chinese character encodings...)?

Each in their own body part.
Each with the "lang" and "charset" values set for their body part.

> more complex to deal with?

YES!

> For that matter should it be possible to send multiple vCalendar objects?

Yes, you can do it in one body part:

	BEGIN:VCALENDER
	...
	END:VCALENDAR
	BEGIN:VCALENDER
	...
	END:VCALENDAR

Or each in a separate body part.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Fri, 09 Nov 2001 15:55:36 -0700

(I think Steve was sleeping when he sent his reply :-)

> value is 1+, the text specifies that all components must have the same

No:  You can have multiple VEVENTS in one VCALENDAR each with
its own UID.

	BEGIN:VCALENDAR
	...
	BEGIN:VEVENT
	UID:1
	...
	END:VEVENT
	BEGIN:EVENT
	UID:2
	...
	END:VEVENT
	END:VCALENDAR

The restriction is per VEVENT, not PER VCALENDAR.

> the same event have different character encodings.

I agree, but you could send it.

> case, we require multiple sends.

Steve - you are sleeping - yes it can.

We allow multiple VEVENT (or any component) per VCALENDAR now.
There is no such restriction in iTIP.
I think you are thinking of the VEVENT restriction table,
there is no VCALENDAR restriction table in iTIP.

	BEGIN:VCALENDAR
	VERSION:...
	...
	BEGIN:VEVENT
	...
	END:VEVENT
	BEGIN:VEVENT
	...
	END:VEVENT
	BEGIN:VJOURNAL
	...
	END:VJOURNAL
	...
	BEGIN:VTIMEZONE
	...
	END:VTIMEZONE
	BEGIN:VTODO
	...
	END:VTODO
	...
	END:VCALENDAR

-Doug

---

From: Doug Royer <[email-masked]>
Date: Fri, 09 Nov 2001 16:01:11 -0700

"Shannon J. Clark" wrote:
> so I had missed that section - but it is a clear indication of the
> different viewpoints on what use is intended for iCalendar objects.
> 

(syntax may be a little off...)

VQUERY:SELECT * FROM VEVENT,VTODO,VJOURNAL WHERE OWNER=self

The results come back as ONE VCALENAR object per TARGET calendar.

> "multiple sends" - seems like a very ugly solution.

No you do not have to.

> Calendar User Agents will maintain a LOCAL Calendar Store 

Or just the results, or current month, or current day, or ...

>- to me at least

---

From: [email-masked] (Steve Mansour)
Date: Fri, 09 Nov 2001 21:35:09 -0800

> (I think Steve was sleeping when he sent his reply :-)

that could be true, but see below...

> The restriction is per VEVENT, not PER VCALENDAR.

Hmm... that's not the way I read RFC2446.  Have a look at 3.2.2 REQUEST.  The
restriction table says

    VEVENT              1+      All components MUST have the same UID

I take this to mean that in a REQUEST you can have 1 or more VEVENTs but they all
must have the same UID.  How do others read this?

-Steve

---

From: Doug Royer <[email-masked]>
Date: Wed, 14 Nov 2001 14:41:22 -0700

Steve Mansour wrote:

> I take this to mean that in a REQUEST you can have 1 or more VEVENTs
> but they all  must have the same UID.  How do others read this?

That's per METHOD. And iMIP (or iTIP) restricted all VCALENAR objects
to the same METHOD per MIME body part. - So if you have to
send multiple METHOD's, send one MIME object with multiple 
MIME body parts. 

There no restriction on non-iTIP METHODs. In fact that
what (whoever it was)'s question. How to represent an entire
calendar in iCalendar format for the purpose of copying or
synchronizing calendars.

And if someone placed that restriction in CAP - lets rip it out as
there is not reason you can not do that.

	BEGIN:VCALENDAR
	METHOD:CREATE
	...

You should be able to create multiple VEVENTS, VTODO, and VJOURNAL
components in one CUA -> CAP transfer. 

With iTIP one of the problems was with scheduling, replying to parts
of a MIME body part. CAP METHOD:{CREATE,DELETE,...} would not have
the same issues as we have included in the CAP replies, the information
to know the problem or success results.

-Doug

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 14 Nov 2001 16:39:10 -0600

Doug,

I believe it was I who posed the initial question:

How to encapsulate an entire calendar for sync or copying purposes?

In particular I noted that this appears to inherently assumed by the
discussions about "local calendar store" vs. "remote calendar store" -
unless it has been assumed that every entry in a calendar would be sent one
entry at a time...???

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Wednesday, November 14, 2001 3:41 PM
Cc: [email-masked]
Subject: Re: MIME Multiple body parts (Was Re: uid...)

	BEGIN:VCALENDAR
	METHOD:CREATE
	...

-Doug

---

From: [email-masked] (Steve Mansour)
Date: Wed, 14 Nov 2001 20:43:40 -0800

> send multiple METHOD's, send one MIME object with multiple

yes. exactly. you just have to send multiple mime parts.  But again, that means
only one UID per VCALENDAR object in iTIP.

> There no restriction on non-iTIP METHODs. In fact that what (whoever it was)'s
> question. How to represent an entire calendar in iCalendar format for the purpose
> of copying or synchronizing calendars.
>

agreed.  There is no such restriction in CAP as far as I know.

> components in one CUA -> CAP transfer.

yep

-Steve