[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
What do you think?