Subject: Re: MIME encapsulation of multipart responses

From: George Babics <[email-masked]>
Date: Tue, 10 Sep 2002 11:34:22 -0400

[I sent this about an hour ago. It does not seem to have
gotten through. Perhaps my new e-mail address was recognized.
I resubscribed to the list with my new e-mail address.
Sorry if this message ends up appearing in duplicate.]

  I also agree that we need a compelling reason.

  I feel that the simpler the better. Furthermore, we should
try to agree on a specific format rather than having multiple
possibilities. This will make co-existence much easier. (We
had interoperability problems during calconnect due to the
many different ways one can put an iCalendar into a MIME
object.)

  The only reason I see that one may want to support multipart is
for attachments. However, they can also be put inline into the
icalendar object. 

George

Andrea Campi wrote:
> 
> On Tue, Sep 10, 2002 at 10:38:04AM +0100, Mark Davidson wrote:
> > >>In any case I think we all seem to agree that multipart support is
> > >>necessary (if not implicitly mandated),
> > >
> > >No, we do not.  The thread you cite was an related to iMIP, which
> > >inherits MUA-based requirements from MIME.  It does *not* mean that
> > >every iCalendar-based application must support multipart.
> >
> > I agree with John. I see no reason why a CUA needs to use multipart
> > anything when talking to a CAP server. It just adds another wrapping of the
> > data that adds nothing and making parsing harder.
> >
> 
> I agree that we don't HAVE to support multipart. Now, if there was
> a compelling reason, or a real advantage, then we can decided
> whether to make it mandatory or optional.
> 
> Bye,
>         Andrea
> 
> --
> Andrea Campi                              mailto:[email-masked]
> I.NET S.p.A.                              http://www.inet.it
> Direzione Tecnica - R&D                   phone: +39 02 32863 ext 1
> v. Darwin, 85 - I-20019                   fax: +39 02 32863 ext 7705
> Settimo Milanese (MI), Italy

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 10:31:59 -0600

> many different ways one can put an iCalendar into a MIME

MIME already specifies how a MIME objects are formed (and there
is not one way). So do you mean with respect to VQUERY replies?
As in how many VCALENDAR objects per MIME object? And how
many MIME objects?

Each text/calenendar MIME object is parsable now. If it
contains one or multiple VCALENDAR objects and if it contains
(or is part of) one or multiple body parts. What do we need to
specify?

If any iCalendar object is part of any MIME object, for the
purpose of parsing and storing the iCalendar object, each
text/calendar object is the root of its view. Start from
that point and extract and store all CIDs and MIDs.
If there are multiple text/calendar objects, each gets
its view from its self. This is not unique to iCalendar.
Its what MIME is. That's why they invented CID's and MIDs.

MIME and iCalendar allow for alternate representations now.
If one CUA does not store all of it - that is fine. But
I see no reason to break implementations when is all a CUA
or CS has to do is ignore representations that it can not
handle - and pass back a status code.

If a CUA or CS passes back an empty MULTIPART capability,
then don't send it any and inform the user they need to
select another vender or implementation. If that is something
that some users will never use or need - fine.

> for attachments. However, they can also be put inline into the

That's implying that CAP needs to redefine 2445 and limit
it to inline only.

---

From: George Babics <[email-masked]>
Date: Tue, 10 Sep 2002 13:52:25 -0400

> As in how many VCALENDAR objects per MIME object? And how

  Yes, with respect to replies.

> (or is part of) one or multiple body parts. What do we need to

  We need to specify if we should use text/calendar or
multipart or some other format. If we allow for more than one,
it can lead to problems with interoperability.

> handle - and pass back a status code.

  Break what implementations? CAP is only a draft. At this
point we do not care about breaking implementations of CAP.

> That's implying that CAP needs to redefine 2445 and limit

No such implication was made. It simply stated that without multipart 
the only way to send attachments would be to send them inline.

George

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 13:31:49 -0600

> it can lead to problems with interoperability.

The problems with iMIP interoperability is that some decided
not to fully support CIDs and MIDs and others did.

2445 Does not specify, so both are valid. So I think
in CAP we have to accomidate both.

> point we do not care about breaking implementations of CAP.

Break iCalendar implementations that already exist and
that already use multipart.

> the only way to send attachments would be to send them inline.

There is no such restriction in 2445, so it would be a redefined.

---

From: [email-masked]
Date: Tue, 10 Sep 2002 16:04:36 -0400

> many different ways one can put an iCalendar into a MIME

I think that being more explicit in CAP WRT multipart data is something we 
mostly agree on.  I think that having 10+ different ways to represent the 
same data is going to lead us to another interop nightmare with different 
implementors taking different approaches to represent the same data and 
neither is 'compatable'.

Part of the multipart issues are previous CalConnects was that some 
vendors didnt support it at all (nor did they support ALTREP and ATTACH; 
they simply ignored them).  Others did but in different ways or only 
partially.  We should learn from this and correct the issue in CAP before 
we RFC, not repeat it because noone wants to face the issues!

> for attachments. However, they can also be put inline into the

What about ALTREPs?

I personally think that putting ATTACHments inline is a poor idea. 
Frank/Derik added that relatively late in the game with the intent that it 
was intended for small amounts of data; not for massive 1M or larger 
attachments.  I for one would love to be rid of inline data as it requires 
my iCalendar parser to scan and parse data that the it really shouldnt 
care about.  Its much faster to parse the text/calendar block and render 
it if I dont have to parse over (or skip over) inlined binary...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Sep 2002 09:06:41 -0400

>in CAP we have to accomidate both.
2445 does not specify, so both are invalid.

>that already use multipart.
Those are not iCalendar implementations.  They are MUAs with integrated 
iCalendar functionality.  In effect, they took iCalendar and created 
their own extensions by integrating MIME features that are not required 
by 2445; that's a reasonable thing to do, but anyone who does it has to 
accept that it limits their interoperability.

>There is no such restriction in 2445, so it would be a redefined.
No, it would be a profile of 2445.

-- 
/===========================================\
|John Stracke      [email-masked]  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/