Subject: RE: MIME Multiple body parts (Was Re: uid...) + iCalendar as data standard

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 8 Nov 2001 17:37:14 -0600

Robert,

I agree that Outlook's implementation is not complete - however that said if
iCalendar, iTIP, iMIP, CAP and other future standards are to become
standards then ideally they should be easily implemented by all calendar
user agents and calendar servers - that is after all the goal of
interoperable systems.

I think that the point that using iCalendar to store a calendar store for a
specific user raises some very serious questions.

IF iCalendar is a DATA standard - then why is it "very complicated" and
"needs careful thought" to use it to store an entire calendar for a given
user?

It seems to me, both as a vendor and as a user, that something called
"iCalendar" - implies an ability to deal with CALENDARS - i.e. that it is
something that can be used to encapsulate and deal with a calendar as a data
unit. I suspect that I am not alone with this reading of the intention of
the standard.

It has always struck me as curious that within the iCalendar standard it is
not at all clear how to talk about a "USER" - i.e. how to talk about in a
logical manner "a user's calendar"

I think the differentiation between thinking of iCalendar as a means to
store data for ONE transaction - i.e. for one meeting, for one task vs. the
thinking of "Calendaring" in general and dealing with a user's calendar is a
major one - and one that we may need to address head on.

thanks,

Shannon
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of [email-masked]
  Sent: Thursday, November 08, 2001 5:30 PM
  To: Shannon J. Clark
  Cc: [email-masked]
  Subject: RE: MIME Multiple body parts (Was Re: uid...)

  Outlook did not do a complete implementation so should not be used as a
standard.

  Your  second case if very complicated and needs careful thought so that
the export/import completely captures and restores the calendar store.  I
have deferred using iCalendar to implement export/import into my product at
this time.

       "Shannon J. Clark" <shannon
        11/08/2001 06:06 PM

                To:        "Robert Ransdell/Iris" <[email-masked]>
                cc:
                Subject:        RE: MIME Multiple body parts (Was Re:
uid...)

  Robert,

  I agree - what I am looking at is whether it is clearly spelled out in the
various standards documents that supporting these cases (and others) is a
MUST requirement for interoperability.

  At present I believe that Outlook, at least in some versions will not
accept or deal with importing or receiving an iCalendar attachment or file
that has multiple vEvents - it claims "invalid file format" in that
situation.

  I am also VERY interested in the use case of using iCalendar to dump to an
interchange format an entire calendar for a given user - in this case the
resulting vCalendar will contain MANY vEVENT, vTODO, vTIMEZONE objects.

  Shannon

  (can I share our conversation with the rest of the working group?)

  -----Original Message-----
  From: Robert_Ransdell/Westford/IBM%IRIS%LOTUS
[mailto:Robert_Ransdell/Westford/[email-masked]]On Behalf Of
Robert Ransdell/Iris
  Sent: Thursday, November 08, 2001 5:11 PM
  To: [email-masked]
  Subject: RE: MIME Multiple body parts (Was Re: uid...)

  There are at least two cases for multiple vEvents.
  1. Simple case of a show.  The multiple VEVENTS show all the possible
events at the show.
  2. Now for the more complicated case.  When you invite a new person to an
already scheduled repeating meeting.  If any of the individual dates have
been modified, the easiest way to show this is to send the original meeting
request with additional events to show changed items such as attendee,
description, etc.

       "Shannon J. Clark" <shannon
        Sent by: [email-masked]
        11/08/2001 05:20 PM

               To:        "John Stracke" <[email-masked]>,
<[email-masked]>
               cc:        (bcc: Robert Ransdell/Westford/IBM)
               Subject:        RE: MIME Multiple body parts (Was Re: uid...)

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

  >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: Doug Royer <[email-masked]>
Date: Fri, 09 Nov 2001 15:39:00 -0700

> "Shannon J. Clark" wrote:

> "needs careful thought" to use it to store an entire calendar for a given

iCalendar is complicated because that the nature of calendering
and scheduling. Calendaring only is easy.

CAP is storage and iCalendar can (and is) used with out iTIP and CAP.

> logical manner "a user's calendar"

That is because a user may be a program. So rather than say
a person, we say a CU (calendar user). That is spelled out
in iCalendar and CAP.

> store data for ONE transaction -

iCalendar CAN NOT STORE DATA - that's what CAP is for.
iTIP can not store data.
iMIP can not store data.

> i.e. for one meeting, for one task vs. the
> thinking of "Calendaring" in general and dealing with a user's
> calendar is a major one - and one that we may need to address head on.

iTIP is for scheduling - for which much was added to iCalendar
to represent the scheduling. (and MUCH debate).

>      From: [email-masked] [mailto:[email-masked]]On

> 
>      I am also VERY interested in the use case of using iCalendar to
>      dump to an interchange format an entire calendar for a given user
>      - in this case the resulting vCalendar will contain MANY vEVENT,
>      vTODO, vTIMEZONE objects.

It CAN do that now.

-Doug

---

From: "Shannon J. Clark" <[email-masked]>
Date: Fri, 9 Nov 2001 17:54:10 -0600

Doug,

I am puzzled by what you mean when you say "iCalendar CAN NOT STORE DATE -
that's what CAP is for"

What puzzles me is that people talk about iCalendar as a "Data format" - and
pardon my simple interpretation of the words - but I would tend to think of
a "data format" as being capable of storing data....

On the other hand, CAP was as I understood it "Calendar Access Protocol" -
i.e. it describes how to communicate with a piece of software termed a
"Calendar Server" - i.e. how to access a calendar on a calendar server.

iCalendar is described as being the data format for the communications with
the Calendar Server, the format for the data ON the calendar server - how is
this not a "data storage" standard???

I think that something very important, more than mere semantics is involved
here - quite possibly we are confusing many people as to what is covered in
which standard; how they work together; and what they do/do not apply
towards.

For example - what I really want from iCalendar is a coherent and
interoperable means of encapsulating Calendar information - either one event
at a time, or more usefully for me a "Calendar" at a time - where a
"Calendar" is a collection of entities - which I will deem either as being
for one human user or for a group of human users.

I then want a means of exchanging this information with many other software
applications - for the purposes I am currently using the calendaring systems
SCHEDULING between individuals is not in the domain of my systems - BUT my
systems MUST work with other calendaring servers for whom scheduling IS in
the domain - i.e. I want to be able to store and/or forward scheduling
related requirements - but my systems at present won't be generating
scheduling workflow requests.

So - do I look for this in iCalendar? in CAP? or in neither place at all?

thanks - these conversations are very helpful in illuminating both what the
documents SAY and what was intended by them... which are frequently
different.

thanks!

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Friday, November 09, 2001 4:39 PM
To: [email-masked]
Subject: Re: MIME Multiple body parts (Was Re: uid...) + iCalendar as
data standard

It CAN do that now.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Fri, 09 Nov 2001 18:24:18 -0700

"Shannon J. Clark" wrote:
> What puzzles me is that people talk about iCalendar as
> a "Data format" - and pardon my simple interpretation of the
> words - but I would tend to think of

I can store a TV, but that not what it is for :-)

It is simply the common nomenclature used to describe these things.
The 'wire format' (or data format) is iCalendar. However there
is no requirement that I store the object in iCalendar format.
The only requirement is that when I transport the data on the wire,
that I use iCalendar format.

> "Calendar Server" - i.e. how to access a calendar on a calendar server.

Yes. How a server serves up iCalendar objects on the wire.

> this not a "data storage" standard???

In my (toy) implementation - I store the data using MySQL.
The data storage standard I use is SQL. However when I pull up
the data and send it over the wire, I transform it to/from iCalendar.

> for one human user or for a group of human users.

Yes - that is what iCalendar is for: how to represent any single
item to an entire calendar - on the wire.

> scheduling workflow requests.

That is why iTIP exists. It explains how to use the iCalendar object
to schedule with one or more CUs.

> So - do I look for this in iCalendar? in CAP? or in neither place at all?

If you want to know what an iCalendar entry looks like:

	Read iCalendar.

If you want to know how to schedule with people using iCalendar object

	Read iTIP.

If you want to know how to email both calendar entries and scheduling
requests/replies:

	read iMIP.

If you want your CUA to be able to manipulate iCalendar objects
and talk to some one else's calendar store:

	Read CAP.

The pain in the butt part is that as we evolve the work that
was started years ago. We discover new properties, parameters,
and restrictions. That is where most of the confusion comes from.

-Doug