iMIP

[Andrea Campi <a.campi@xxxxxxx>]

Hi all,

more than once we have discussed whether full iMIP support is required 
for CAP compliance; in particular,  this has to do with multipart 
support, as iMIP compliance implies multipart support.

This is my proposal: add an IMIP-VERSION property to GET-CAPABILITY (by 
the way, I noticed a typo in ITIP-VERSION, 2447 should be 2446):


      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. Notably, 
it MUST use separate text/calendar body parts for iCalendar objects 
with different methods. The exact MULTIPART support MUST still be 
specified using the MULTIPART property. [note: I'm open for discussion 
on this last sentence]
If an endpoint specifies NONE it is not bound by any requirement in 
RFC2447. In particular, it can send multiple iCalendar objects with 
different METHODs inside one text/calendar body part. Any MULTIPART 
support SHOULD be specified using the MULTIPART property, or MULTIPART 
can be left out if the endpoint can't use MULTIPART.



I think this proposal allows for maximum freedom of implementation 
while still being precise enough. The only downside I see is that an 
iMIP compliant endpoint needs to handle non-iMIP compliant contents. 
But this simply means not enforcing a restriction, so I guess it's not 
a problem.


What do you think?


Bye,
	Andrea