Subject: Intolerant iMIP receivers

From: John Stracke <[email-masked]>
Date: Mon, 15 Mar 1999 22:10:12 +0000

An issue raised in the WG meeting today was whether an iMIP-based CUA
really needs to recognize multipart/mixed and multipart/alternative
MIME messages.  RFC-2049 ("MIME Conformance Criteria and Examples") says
(section 2) that a mail user agent that is MIME-conformant MUST handle
multipart/mixed and multipart/alternative.  So I think the answer is
that, yes, an iMIP-based CUA must recognize multipart/mixed and
multipart/alternative.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: "Frank Dawson" <[email-masked]>
Date: Tue, 16 Mar 1999 19:16:43 -0500

On Tuesday, March 16, 1999 7:03 PM John Stracke wrote, in part:

>My view is that the iMIP
>message is received by an MUA, which passes the iCalendar to the CUA

Ah, nope. Not necessarily. That is certainly not what Lotus Organizer 5.1
does. You can set it up to go directly to your POP3 or IMAPv4 server.

I think that you are generalizing too far. A CUA is not a MUA. Hence the
MIME conformance requirement is not the same.

- - Frank

---

From: "John Stracke" <[email-masked]>
Date: Tue, 16 Mar 99 23:29:59 EST

>does. You can set it up to go directly to your POP3 or IMAPv4 server.

This is what I meant when I referred to "a single 
application which is an MUA with an integrated CUA".

(And you'd better not point it at a POP3 server which doesn't
grok UIDL.  :-)

>MIME conformance requirement is not the same.

I believe that you are wrong.  Any application which sends or
receives email messages is, by definition, an MUA.  Further,
RFC-2447 defines that iMIP runs over MIME.  From Section 1:

 This binding document provides the transport specific information
 necessary convey iCalendar Transport-independent Interoperability
 Protocol (iTIP) over MIME as defined in [RFC-822] and [RFC-2045].

This precludes the option of saying that we're using MIME constructs
but we aren't really MIME.

---

From: Doug Royer <[email-masked]>
Date: Thu, 18 Mar 1999 17:27:26 -0800 (PST)

> From: "Frank Dawson" <[email-masked]>
> Date: Tue, 16 Mar 1999 18:38:55 -0500
> 
> On Tuesday, March 16, 1999 11:32 AM, John Stracke wrote, in part:
> 
> >RFC-2049 ("MIME Conformance Criteria and Examples") says
> I would agree with your suggestion that CUAs conforming to RFC 2447/iMIP
> should be able to receive all the various type of iCalendar encapsulation
> outlined in the spec. However, are we making a jump when we ask a CUA to
> adhere to the same conformance as a MIME conferment MUA? Aren't they
> different beasts?

I hope NOT. Otherwise we would be defining that we only support
a subset of MIME, that exists today. And for what gain?

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Thu, 18 Mar 1999 17:30:50 -0800 (PST)

> Date: Tue, 16 Mar 1999 23:58:59 +0000
> From: John Stracke <[email-masked]>
> 
> Frank Dawson wrote:
> 
> > are we making a jump when we ask a CUA to
> > adhere to the same conformance as a MIME conformant MUA? Aren't they
> > different beasts?
> 
> ...
> So...I guess the "must" I was speaking about before impacts the behavior of
> the whole system, but is irrelevant to the CUA per se.
> 
> (Note that not all of the encapsulations in 2447 rely on mandatory MIME
> features.  In particular, 4.3 and 4.6 use multipart/related, which is
> optional.)

Yet the iCalendar object uses MID's and CID's requiring multipart/related.
So we would be MIME++-- compatible :-) Yuck ether way.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Thu, 18 Mar 1999 17:38:12 -0800 (PST)

> From: "John Stracke" <[email-masked]>
> Date: Tue, 16 Mar 99 23:29:59 EST
> 

I don't agree - If a application it sends iMIP then it might be
be called an MUA, however iCalendar objects are MIME object that
can be transported outside of email, SMTP, or a MUA. Example:

	I could FTP an iCalendar MIME object to my CUA.

And I think the CUA that FTP'd the iCalendar data would need to support 
multipart/related, multipart/mixed, and multipart/alternate.
I would not expect the FTP-client or client-library to do that for me.

-Doug

---

From: [email-masked]
Date: Thu, 18 Mar 1999 15:02:02 GMT

(Attempt to re-reply...)

Frank asked:
>However, are we making a jump when we ask a CUA to

That depends on your architecture.  There may be separate MUA and CUAs (as
John later described as his view of the iTIP/iMIP world) or a hybrid
critter.

If you go the route of the MUA and CUA are separate beasts then the CUA has
the issue of dealing with ATTACHMENT= and ALTREP= property parameters.
While any ATTACHMENT= value is _likely_ not to be a multipart MIME body
part, an ALTREP= one has a much greater possibility of being multipart (ie:
text/html & application/ms-tnef).  So, if your distinct CUA plans to try
and use the ALTREP= property parameter then I think full MIME conformance
is a must for it.   Cutting corners and just designing your CUA to expect
ALTREP= to be just, say, text/html is a very very poor design that
customers will soon give up on.

If you got the route of a hybrid MUA/CUA then you already have some kind of
MIME engine designed so you can properly handle the MIME data you retrieve
via IMAP, POP3, etc.  One would hope that your engine would be MIME
conformant in this case; or at least know how to skip over multiparts
entirely so they are opaque.  (This then assumes your CUA wont be able to
do 'full' ALTREP= handling too).

Being the volunteered co-scribe for the meeting I missed part of this
original thread while revising some of the notes.  Could someone explain to
me and the list just how this issue w/iMIP came up?

Bruce

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 22 Mar 1999 08:32:06 -0500

On Thursday, March 18, 1999 8:27 PM, Doug Royer responded to my append on

>a subset of MIME, that exists today. And for what gain?

We are talking about an implementation to RFC 2427, iMIP. By definition, I
only expect conformance to apply to what is specified directly or through
reference in RFC 2427. That means that I only have to support those parts of
MIME that are specified in the iMIP spec. No where that I read did it say
that a mail-enabled application that conformed to iMIP had to be a full MIME
compliant MUA.

Certainly, Lotus and other PIM vendors might implement a product that
supported iMIP but that for business reasons was not a MUA, but rather was a
CUA.

Let me repeat:     CUA <> MUA

These are different beasts. Certainly, you could implement a MUA that also
had CUA functions. But to infer from this product strategy that all CUAs had
to be conformant MIME MUAs is a false assumption. The iMIP spec's statement
of conformance should clarify this, right?

- - Frank