[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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:sman@xxxxxxxxxxxx]
Sent: Thursday, November 08, 2001 5:45 PM
To: Shannon J. Clark
Cc: John Stracke; ietf-calendar@xxxxxxx
Subject: Re: MIME Multiple body parts (Was Re: uid...)


"Shannon J. Clark" wrote:
>
> 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???)

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.

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

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.

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

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

-Steve