- From: Cameron Stillion <camerost@exchange.microsoft.com>
- Date: Tue, 9 Aug 2005 02:35:09 -0700
- To: "Doug Royer" <Doug@royer.com>
- Cc: <xcal-dev@inet-consulting.com>, "Calsify" <ietf-calsify@osafoundation.org>, "CalDAV DevList" <ietf-caldav@osafoundation.org>, <www-rdf-calendar@w3.org>, <ietf-calendar@imc.org>
2.2.1 Are you minimizing the difference between the inherent unicode capabilities of XML and the rather esoteric encoding requirements of iCal? Simply wrapping the data in tags is not really enough... 2.2.2 isomeric - I think you mean "isometric". Ah, the difference one character can make... also - why is it required to send an alternate MIME body part in normal iCal format? Is this format designed to replace the old format? Ultimately? If so, why should both be required? iCal readers of old can read xcal via transform, and new applications can easily parse using a standard xml parser... Why limit all uses of this to also implement the old way of doing things? This seems counter productive to me. 2.11 why not simply use "text/xcal" ? again, why the restriction for backwards compatability? This sounds like you are enforcing client functionality. How about you allow the MTA or client application to determine whether or not to send a downlevel representation? 2.12 how about using a double extension - <filename>.xml.xcs This is reminiscent of tar files for those who are ancient enough to remember those - anytime to add another layer of schematization over a file, you add an extension. Why don't we follow the same pattern? I can't think of a good reason not to. While you're at it - why not go another step further and specify file extensions for the different types of iCals (which the ical standard unfortunately failed to do) - for instance, a meeting request "method='request'" might have an extension of .xrc while a published calendar "method='publish'" might have an extension of .xcs - this gives everyone a much more tangible understanding of the data without having to crack it and parse it first. There's a thought.
Received on Tuesday, 9 August 2005 10:46:06 UTC