[Ietf-calsify] xCal - time to submit?
dave at cridland.net
Sun Oct 23 06:57:39 PDT 2005
On Sun Oct 23 13:28:11 2005, Aki Niemi wrote:
> ext Doug Royer wrote:
>> What move?
> As in stop using the current format and start using the new one.
>> What transition?
> As in how to cope with the co-existance of applications that
> support the new format and the old format, and applications that
> only support the old format.
I think the problem with xCal is not that it's an irrelevant and
pointless format, because it isn't - I think it's potentially very
useful. But it's nothing to do with this WG, which is why reaction is
pretty hostile. Here, the WG is trying to get decent interoperability
between calendaring applications. XML doesn't help that in the
slightest, and as you point out, if anything, it hurts that.
However, many existing systems work "better" with XML, and so I can
fully understand that a neat method of producing iCal objects in XML
is valuable. No, I don't want to see iMIP capable CUAs start to send
out xCal, as that'd be pointless, but yes, a web-based calendaring
system might well be capable of spitting out xCal if requested, and
some simple front-ends may even require that - and that's fine.
So essentially, I think xCal as a concept is fine, just that care
should be taken to define its scope a little better.
I *haven't* read the draft, incidentally, but I still can tell the
scope is obviously not clearly defined, because otherwise the threads
going on in this WG about xCal would presumably be very different.
If xCal is actually presented as "a better format", then it's
over-egging itself (I think a child of four could make a better
format than iCal, but the deployed base renders this a waste of
time). If xCal presents itself as a format more suited to XML-centric
environments, than I'm all for it.
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw
More information about the Ietf-calsify