[ I have set the REPLY-TO the xcal@xxxxxxxxxxxxxxxxxxx mailing list - This is of interest to CALSIFY and CALDAV users, but not really 'on topic' - Join at http://inet-consulting.com/mailman/listinfo/xcal ]
Anyway, is there anyone else who feels as I do that enforcing both xcal and ical as multipart alternative is overkill? Or is this also beyond the scope of this proposal?
When Frank, Surendra, and I did the first XCAL, we were told by the AD's at the time that they would not endorse ANOTHER calendar data format, unless it was an alternate view of iCalendar data. So the agreed solution was that xCal objects would be attached as an alternate view to iCal objects.
Currently iMIP requires that people use S/MIME. I do not recall seeing many S/MIME iCalendar emails.
The danger here is that we re-invent the wheel breaking things. The purpose of CALSIFY is to simplify and make a set of objects and procedures that will enable iCal and vendors to have standard calendaring objects. If we open up the debate to XML 'IS calendaring' then all that is compatibility that we already have is lost.
There are many XML parsers out there and XML can be transformed back into iCal (see my posting of the XSLT translation on the xCal mailing list).
Doug Royer | http://INET-Consulting.com -------------------------------|-----------------------------
begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:Doug@xxxxxxxxx title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@xxxxxxxxxxxxxxxxxxx=0D=0A= Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature