Don't want to get into a long pro/con on iMIP but there is some weakness in the following posting about iMIP weaknesses:
>I would suggest that it also list the limits of an iMIP only
>implementation. Off of the top of my head:
>
> (1) Scaleability. Piping all request through email
> will only increase the delay for scheduling request and
> incress the likehood of failed requests.
I have worked both on a client/server and email based C&S product team. The issue of failed requests is common to both implementation approaches. The server is often down for what ever reason. Mail can get lost due to bad email addresses, down MTAs etc. This argument is a wash. There is nothing here related to "scalability". It is more of an issue of "availability".
> (2) Hit and miss approach to scheduling (lets send the request
> and see if we get that time slot). If not lets send
> another one (see #1).
Assuming the deployment of CAP is impacted by enterprise "comfort" with giving CREATE access rights to "strangers", I would guess that even with CAP, you will be left with issuing iTIP REQUEST commands through CAP. This would make this issue a wash too.
> (3) iMIP Spam. If iMIP is the only or best way to schedule
> mail, you can get a whole new level of SPAM. (Go to
> the we sell you something meeting - iCalendar attached).
See above. You are going to get calendar SPAM, no matter whether your calendar address is an iMIP or a CAP form of URI.
> (4) CAP address authentication and access lists. iMIP does not.
Right. Some would call this a "pro" for iMIP ;-)
-- Frank