RE: [Ietf-caldav] xCal - resubmitted.

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