Subject: Re: iMIP

From: Doug Royer <[email-masked]>
Date: Thu, 19 Sep 2002 10:27:01 -0600

[may be a resend - I hit send before I was done typing ...]

 >... IMIP-VERSION     1     Version(s) of IMIP, comma separated list. To
 > specify RFC-2447 support the list MUST include at least 2447. Alternatively,
 > in can be set to NONE.
 >
 > If an endpoint specifies RFC2447 it MUST implement all of RFC2447, including
 > support for multipart, and respect any restrictions.

I do not think that multipart is a MUST in iMIP. We would still need something
like a MULTIPART property in GET-CAPABILITY in order to determine if the other
endpoint supported multipart. That was one of the points that Bruce has
been pointing out.

iMIP requires the 'From:' and other 822 headers. I don't think
we want to add that to CAP. Do we care?

---

From: Andrea Campi <[email-masked]>
Date: Thu, 19 Sep 2002 20:44:01 +0200

> I do not think that multipart is a MUST in iMIP. We would still need 

I'm not sure, either.

> endpoint supported multipart. That was one of the points that Bruce has

Yes, and I wrote that in my proposal, you cut it in your response.

> we want to add that to CAP. Do we care?

No, of course not. Headers are not part of the payload. Only the 
payload of CAP and iMIP messages would need to be compatible.

Sorry, I didn't understand if you dislike the idea as a whole or if you 
only find the wording unclear or misleading. If the latter, I could 
rewrite the proposal to address your objections, no problem.

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Thu, 19 Sep 2002 13:14:05 -0600

> No, of course not. Headers are not part of the payload. Only the payload 
> of CAP and iMIP messages would need to be compatible.

At this point - it would not be iMIP compliant. So no, I do not
think that we should make CAP an iMIP binding. I think that iTIP
is the correct breaking point for the bindings.

In addition, iMIP mandates that ATTENDEE values me e-mail addresses (2.3).
In CAP they can be 'cap' URIs.

In addition iMIP says:

    Compliant applications MUST support signing
    and encrypting text/calendar attachments using a mechanism based on
    Security Multiparts for MIME [RFC-1847] to facilitate the
    authentication the originator of the iCalendar object.

Do we want to mandate that ALL CS's implement S/MIME to facilitate
the authentication of the originator? No, we have SASL and TLS for
that in CAP.

---

From: Andrea Campi <[email-masked]>
Date: Thu, 19 Sep 2002 22:05:50 +0200

> is the correct breaking point for the bindings.

OK, I appreciate your points, I had not considered some of those. So I 
drop my proposal.

So this means we needn't forbid more than one METHOD per text/calendar 
;-)

Bye,
	Andrea